Развитие проекта

[shark3d 1]

Все мы уже долгое время используем данный проект под свои нужды (сам использую около 3-х лет).

Некоторых функций хватает, некоторых - нет, кто-то дописывал дополнительные компоненты для себя сам.

 

По-этому, я считаю, что настало время вывести Старгейзер на новый уровень, значительно его расширив и переработав.

Вот мое предложение:

 

1. Перевод проекта под хостинг Google Code, что позволит использовать централизованное хранилище (SVN, Git), с соответствующим контролем и управлением; Google Groups - для поддержки.

2. Для обсуждения процесса разработки, новых функций, алгоритмов, для общения разработчиков - использовать Google Wave (инвайты предоставлю).

3. Переход на систему сборки CMake.

4. Добавление поддержки нескольких аккаунтов для клиента (на основе виртуальных счетов, к которым будут привязываться реальные адреса, логины, пароли, услуги ).

5. Отказ от файловой базы и переход полностью на СУБД.

6. Как следствие п. 5 - доступ плагинов к БД (возможность выполнения SQL запросов), доступ к ядру биллинга.

7. Дополнения биллинга новыми функциями, такими, как несколько услуг на клиента (WiFi, скидки, VPN, почта, FTP).

8. Добавление услуги VoIP через Radius (есть опыт подобного решения), либо как модуль к Asterisk'у.

9. Полная переработка конфигуратора под новые нужды, перевод его QT-фреймворк.

10. Прочие фичи...

 

Все это можно организовать в 3-ю ветку Старгейзера.

Интересует мнение как непосредственно разработчиков, так и всех, кому так или иначе не безразлична судьба проекта.

 

Добавлено:

Вопрос с CMake уже обсуждался, но все же...

[nightfly 1 239]

Дык делайте - кто ж вам мешает?

[SilentBob 0]

Развитие и новые фичи это хорошо, но больше интересна стабильность. Файловую БД есть смысл оставить (опционально), не всегда необходима тяжеловесная БД, особенно когда кол-во клиентов едва доходит до 10.

[shark3d 1]

Дык делайте - кто ж вам мешает?

 

Сделать простое ответвление проекта не составит труда, но вопрос не в этом. Одно дело, когда проектом начинает заниматься абсолютно новый человек и другое - когда над ядром продолжают работу разработчики, которые все это начали.

 

Развитие и новые фичи это хорошо, но больше интересна стабильность. Файловую БД есть смысл оставить (опционально), не всегда необходима тяжеловесная БД, особенно когда кол-во клиентов едва доходит до 10.

 

для 10 пользователей, думаю, и старые версии вполне останутся актуальными... а вот если их уже больше 100...

[Kucher2 122]

Я тоже против того что выкидывать файловую БД. Мне так удобнее, переходить на подобие MySQL не собираюсь.

Почему-то Stargazer не считается серьёзным биллингом, годным для большого провайдинга. Во всяком случае мнения разделяются. Конечно тому есть причины. Основная - его бесплатность.

Большой плюс: функционал при желании легко дописать самому на банальном шелле или php.

 

То что Вы предлагаете - сеьёзное вмешательство в код.

Где гарантия, что СТГ не превратится в очередного платного монстра после таких передвижек?

[shark3d 1]

Почему-то Stargazer не считается серьёзным биллингом, годным для большого провайдинга. Во всяком случае мнения разделяются. Конечно тому есть причины. Основная - его бесплатность.

Лично я считаю его вполне пригодным для использования в крупных масштабах (знакомый провайдер использует его вполне удачно на своей базе в 2500 пользователей).

Бесплатность биллинга никогда не была отрицательной чертой.

 

Большой плюс: функционал при желании легко дописать самому на банальном шелле или php.

Можно, но производительность от таких дополнений значительно снижается для больших масштабов.

 

То что Вы предлагаете - сеьёзное вмешательство в код.

Я знаю, но это также и значительный скачек вперед...

 

Где гарантия, что СТГ не превратится в очередного платного монстра после таких передвижек?

А где гарантия что он сейчас таким не станет? Что разработчики не сменят лицензию?

[Kucher2 122]

А где гарантия что он сейчас таким не станет? Что разработчики не сменят лицензию?

Сейчас по крайней мере нет к этому предпосылок.

 

> Большой плюс: функционал при желании легко дописать самому на банальном шелле или php.

 

Можно, но производительность от таких дополнений значительно снижается для больших масштабов.

 

Насколько существенно? Мне например очень интересно какая разница в быстродействии между файловй БД и SQL-подобной и на каком кол-ве юзеров это чувствуется.

 

Вы предлагаете весь функционал для юзера запихать в конфигуратор?

[shark3d 1]

Вы предлагаете весь функционал для юзера запихать в конфигуратор?

Что значить весь функционал для юзера?

Статистика для пользователя всегда будет отдельной, но такие вещи как телефония, VPN, WiFi всегда удобней и легче распределять и настраивать в одном месте, а не переключатся на разные интерфейсы, программы и прочее.

[nightfly 1 239]

А где гарантия что он сейчас таким не станет? Что разработчики не сменят лицензию?

какие гарантии? это опынсорц детка (С)

 

Можно, но производительность от таких дополнений значительно снижается для больших масштабов.

Обоснуйте (С)

 

Возможно просто нужно уметь нормально писать?

 

Мне например очень интересно какая разница в быстродействии между файловй БД и SQL-подобной и на каком кол-ве юзеров это чувствуется.

поверьте чувствуется на любых непионерных размерах сети

Проверьте сколько у вас будет парситься из текстовок детальная стата по 2-3к пользователей вместо SELECT * с индексами по нужным полям.

[nightfly 1 239]

shark3d

Стараюсь понять мотивацию вашего стартового поста но как-то не получается. Толи это призыв взять и написать это все вместо вас (вестимо же бесплатно), толи это освещение ваших наполеоновских планов которые вы возможно уже начали реализовывать (вау)?

А знаете ли вы что форкнуться либо принять участие в проекте вам как бы никто не препятствует на данный момент - и откуда столько драмы про то что ничего нет да еще и лицензию сменят?

 

На данный момент старгейзер предоставляет разработчику весь необходимый функционал для наращивания функциональности рандомными средствами и что главное дает уникальную возможность полностью абстрагироваться от его внутренних механизмов что я считаю наиболее сильной чертой данного решения.

[madf 279]

Все мы уже долгое время используем данный проект под свои нужды (сам использую около 3-х лет).

Некоторых функций хватает, некоторых - нет, кто-то дописывал дополнительные компоненты для себя сам.

 

По-этому, я считаю, что настало время вывести Старгейзер на новый уровень, значительно его расширив и переработав.

Все к этому в конце концов приходят.

Вот мое предложение:

 

1. Перевод проекта под хостинг Google Code, что позволит использовать централизованное хранилище (SVN, Git), с соответствующим контролем и управлением; Google Groups - для поддержки.

2. Для обсуждения процесса разработки, новых функций, алгоритмов, для общения разработчиков - использовать Google Wave (инвайты предоставлю).

3. Переход на систему сборки CMake.

4. Добавление поддержки нескольких аккаунтов для клиента (на основе виртуальных счетов, к которым будут привязываться реальные адреса, логины, пароли, услуги ).

5. Отказ от файловой базы и переход полностью на СУБД.

6. Как следствие п. 5 - доступ плагинов к БД (возможность выполнения SQL запросов), доступ к ядру биллинга.

7. Дополнения биллинга новыми функциями, такими, как несколько услуг на клиента (WiFi, скидки, VPN, почта, FTP).

8. Добавление услуги VoIP через Radius (есть опыт подобного решения), либо как модуль к Asterisk'у.

9. Полная переработка конфигуратора под новые нужды, перевод его QT-фреймворк.

10. Прочие фичи...

 

Все это можно организовать в 3-ю ветку Старгейзера.

Интересует мнение как непосредственно разработчиков, так и всех, кому так или иначе не безразлична судьба проекта.

 

Добавлено:

Вопрос с CMake уже обсуждался, но все же...

1. Тут есть ряд вопросов, но принципиально возможно.

2. Я против. Почты и Jabber хватает. Если разработчиков будет больше 2 можно будет организовать конференцию в Jabber или канал в IRC.

3. На FreeBSD, как я понял, с этим не очень хорошо. Особенно на старых версиях.

4. Тут поподробнее, пожалуйста.

5. Против. Stargazer всегда славился тем что его можно проинсталлить и он уже сразу работает и каши не просит. Кроме того файловая база вполне себе работает на 2000/5000 клиентах.

6. Доступ плагинов к БД ядра, я считаю, должен быть только через API ядра. А дополнительную инфу можно получать из собственных таблиц по отжельным соединениям с базой.

7. Это уже на 90% готово еще с версии 2.401 (или 402, не помню уже). Нужно просто допилить реализацию "сервисов".

8. Тут много вопросов архитектурного характера.

9. Начинал. Времени не хватает

 

Мне, как одному из главных разработчиков, совсем не безразлична судьба проекта. Мнение - выше

[madf 279]

Почему-то Stargazer не считается серьёзным биллингом, годным для большого провайдинга. Во всяком случае мнения разделяются. Конечно тому есть причины. Основная - его бесплатность.

Лично я считаю его вполне пригодным для использования в крупных масштабах (знакомый провайдер использует его вполне удачно на своей базе в 2500 пользователей).

Бесплатность биллинга никогда не была отрицательной чертой.

На 6000 работает

Просто 6-10к юзеров это, по моему, не очень серьезный провайдинг.

Большой плюс: функционал при желании легко дописать самому на банальном шелле или php.

Можно, но производительность от таких дополнений значительно снижается для больших масштабов.

 

То что Вы предлагаете - сеьёзное вмешательство в код.

Я знаю, но это также и значительный скачек вперед...

Где гарантия, что СТГ не превратится в очередного платного монстра после таких передвижек?

А где гарантия что он сейчас таким не станет? Что разработчики не сменят лицензию?

Такие мысли были года 3-4 назад. Ничего из этого не вышло. Я не вижу смысла менять лицензию или делать биллинг платным.

[shark3d 1]

shark3d

Стараюсь понять мотивацию вашего стартового поста но как-то не получается. Толи это призыв взять и написать это все вместо вас (вестимо же бесплатно), толи это освещение ваших наполеоновских планов которые вы возможно уже начали реализовывать (вау)?

А знаете ли вы что форкнуться либо принять участие в проекте вам как бы никто не препятствует на данный момент - и откуда столько драмы про то что ничего нет да еще и лицензию сменят?

 

На данный момент старгейзер предоставляет разработчику весь необходимый функционал для наращивания функциональности рандомными средствами и что главное дает уникальную возможность полностью абстрагироваться от его внутренних механизмов что я считаю наиболее сильной чертой данного решения.

Это не призыв написать все за меня, а желание узнать мнение (главным образом разработчиков) о дальнейшем развитии проекта.

Я не утверждал, что ничего нет и драмы никакой не вижу.

Как раз наоборот, на данный момент старгейзер для чистого интернет-провайдинга является полнофункциональным и законченным решением. Но повторюсь еще раз, для чистой раздачи интернета. Но попробуйте сейчас привязать какому-то клиенту дополнительные услуги (телефонию, телевидение), да еще и на одну учетную запись с одним денежным счетом.

[madf 279]

А где гарантия что он сейчас таким не станет? Что разработчики не сменят лицензию?

какие гарантии? это опынсорц детка (С)

 

Можно, но производительность от таких дополнений значительно снижается для больших масштабов.

Обоснуйте (С)

 

Возможно просто нужно уметь нормально писать?

 

Мне например очень интересно какая разница в быстродействии между файловй БД и SQL-подобной и на каком кол-ве юзеров это чувствуется.

поверьте чувствуется на любых непионерных размерах сети

Проверьте сколько у вас будет парситься из текстовок детальная стата по 2-3к пользователей вместо SELECT * с индексами по нужным полям.

Wrong!

Файловая система со структурой каталого - это уже прообраз таких индексов. Быстродействие примерно равное, но для БД еще нужны индексы. Без них БД работает медленнее.

Даже нет, не так. Для БД еще нужен DBA

[madf 279]

shark3d

Стараюсь понять мотивацию вашего стартового поста но как-то не получается. Толи это призыв взять и написать это все вместо вас (вестимо же бесплатно), толи это освещение ваших наполеоновских планов которые вы возможно уже начали реализовывать (вау)?

А знаете ли вы что форкнуться либо принять участие в проекте вам как бы никто не препятствует на данный момент - и откуда столько драмы про то что ничего нет да еще и лицензию сменят?

 

На данный момент старгейзер предоставляет разработчику весь необходимый функционал для наращивания функциональности рандомными средствами и что главное дает уникальную возможность полностью абстрагироваться от его внутренних механизмов что я считаю наиболее сильной чертой данного решения.

А по моему мотивация вполне очевидна. Stargazer был хорош в том виде в котором он есть сейчас лет 5-10 назад. Сегодня его функционала не хватает. Обвязки внешними скриптами решают только простейшие проблемы. Если делать что-то более серьезное - приходится отказываться от внутренних механизмов Stargazer'а и прибегать к написанию внешних эквивалентов. Таким образом Stargazer из биллинговой системы вырождается в обычную считалку трафика (ну еще плюс классификатор).

 

У меня тоже зреют наполеоновские планы, но силами одного разработчика их реализовать невозможно. Я периодически делаю призывы включиться в разработку тут на форуме, но пока желающих не видно. Видимо сказывается специфика проекта: большинство его пользователей сисадмины а не программисты.

[shark3d 1]

madf

4. Добавление поддержки нескольких аккаунтов для клиента (на основе виртуальных счетов, к которым будут привязываться реальные адреса, логины, пароли, услуги ).

Относительно этого мое предложение следующее:

 

Реализованный на данный момент счетчик трафика очень хорошо зарекомендовал себя в работе, аналогично и авторизатор. Но они работают с одной записью логин-пароль-ip.

Если создать отдельную таблицу, в которой будет храниться основной логин и пароль и прочее описание учетной записи. Так мы получаем виртуальную клиентскую запись.

К этой записи привязываем денежный счет, который клиент и будет пополнять, не задумываясь на какие услуги пойдут деньги в дальнейшем.

К этой виртуальной учетке привязываем столько логинов и паролей (то есть конкретных ПК или прочее оборудование) сколько потребуется. Именно эти записи будет контролировать старгейзер как и раньше, то есть считать по ним трафик, отключать в нужный момент. Деньги на эти учетки будут распределятся равномерно или разными частями с виртуального счета, который пополняет пользователь. Если, скажем в течении месяца на какой-то из реальных учетных записей заканчиваются средства и на виртуальном счету есть еще остаток средств, то они переносятся на этот реальный счет. Если денег не будет на - рельная учетная запись блокируеться как и раньше до пополнения.

 

Думаю для подобной реализации изменения потребуются минимальные, а самое главное не нужно менять счетчик трафика и авторизатор.

[shark3d 1]

shark3d

Стараюсь понять мотивацию вашего стартового поста но как-то не получается. Толи это призыв взять и написать это все вместо вас (вестимо же бесплатно), толи это освещение ваших наполеоновских планов которые вы возможно уже начали реализовывать (вау)?

А знаете ли вы что форкнуться либо принять участие в проекте вам как бы никто не препятствует на данный момент - и откуда столько драмы про то что ничего нет да еще и лицензию сменят?

 

На данный момент старгейзер предоставляет разработчику весь необходимый функционал для наращивания функциональности рандомными средствами и что главное дает уникальную возможность полностью абстрагироваться от его внутренних механизмов что я считаю наиболее сильной чертой данного решения.

А по моему мотивация вполне очевидна. Stargazer был хорош в том виде в котором он есть сейчас лет 5-10 назад. Сегодня его функционала не хватает. Обвязки внешними скриптами решают только простейшие проблемы. Если делать что-то более серьезное - приходится отказываться от внутренних механизмов Stargazer'а и прибегать к написанию внешних эквивалентов. Таким образом Stargazer из биллинговой системы вырождается в обычную считалку трафика (ну еще плюс классификатор).

 

У меня тоже зреют наполеоновские планы, но силами одного разработчика их реализовать невозможно. Я периодически делаю призывы включиться в разработку тут на форуме, но пока желающих не видно. Видимо сказывается специфика проекта: большинство его пользователей сисадмины а не программисты.

 

Вот для этого я и поднял эту тему, так как мне самому не безразлична судьба проекта, и с некоторым новым функционалом я могу помочь в плане разработки.

[nightfly 1 239]

Таким образом Stargazer из биллинговой системы вырождается в обычную считалку трафика (ну еще плюс классификатор).

Ну кроме считалки и классификатора, еще снималка денег и авторизалка =)

 

Кажись как бескрайнее поле для писательства внешнего обвеса, причем заточенного под конкретную специфику. Все универсальные решения обречены на монструозность и негибкость.

[nightfly 1 239]

Wrong!

Файловая система со структурой каталого - это уже прообраз таких индексов. Быстродействие примерно равное, но для БД еще нужны индексы. Без них БД работает медленнее.

Даже нет, не так. Для БД еще нужен DBA

да, DBA нужен, а индексы в отличии от фс всегда висят в памяти а не ищуться хз где. Благо CMS на текстовках уже понаписывался - быстродействие равное/выше только на очень незначительных количествах данных с вложеной папочной структурой. Когда приходиться вызвать рекурсивный и не самый быстрый по своей сути scandir() плюс сделать несколько тысяч fopen()/fclose() как бы нормальная бд с нормальными индексами получается значительно в выигрыше

[madf 279]

madf

4. Добавление поддержки нескольких аккаунтов для клиента (на основе виртуальных счетов, к которым будут привязываться реальные адреса, логины, пароли, услуги ).

Относительно этого мое предложение следующее:

 

Реализованный на данный момент счетчик трафика очень хорошо зарекомендовал себя в работе, аналогично и авторизатор. Но они работают с одной записью логин-пароль-ip.

Если создать отдельную таблицу, в которой будет храниться основной логин и пароль и прочее описание учетной записи. Так мы получаем виртуальную клиентскую запись.

К этой записи привязываем денежный счет, который клиент и будет пополнять, не задумываясь на какие услуги пойдут деньги в дальнейшем.

К этой виртуальной учетке привязываем столько логинов и паролей (то есть конкретных ПК или прочее оборудование) сколько потребуется. Именно эти записи будет контролировать старгейзер как и раньше, то есть считать по ним трафик, отключать в нужный момент. Деньги на эти учетки будут распределятся равномерно или разными частями с виртуального счета, который пополняет пользователь. Если, скажем в течении месяца на какой-то из реальных учетных записей заканчиваются средства и на виртуальном счету есть еще остаток средств, то они переносятся на этот реальный счет. Если денег не будет на - рельная учетная запись блокируеться как и раньше до пополнения.

 

Думаю для подобной реализации изменения потребуются минимальные, а самое главное не нужно менять счетчик трафика и авторизатор.

Т.е. несколько учеток и один общий кошелек? Тогда это тоже на 80% реализовано. Т.н. "копрорации", которые пока только существуют в базе и никак себя не проявляют.

[madf 279]

Таким образом Stargazer из биллинговой системы вырождается в обычную считалку трафика (ну еще плюс классификатор).

Ну кроме считалки и классификатора, еще снималка денег и авторизалка =)

 

Кажись как бескрайнее поле для писательства внешнего обвеса, причем заточенного под конкретную специфику. Все универсальные решения обречены на монструозность и негибкость.

Ну зачем же сразу монструозность. Просто сделать нормальное управление пользователями, сервисами, систему событий и т.д. И все будет классно

[madf 279]

Wrong!

Файловая система со структурой каталого - это уже прообраз таких индексов. Быстродействие примерно равное, но для БД еще нужны индексы. Без них БД работает медленнее.

Даже нет, не так. Для БД еще нужен DBA

да, DBA нужен, а индексы в отличии от фс всегда висят в памяти а не ищуться хз где. Благо CMS на текстовках уже понаписывался - быстродействие равное/выше только на очень незначительных количествах данных с вложеной папочной структурой. Когда приходиться вызвать рекурсивный и не самый быстрый по своей сути scandir() плюс сделать несколько тысяч fopen()/fclose() как бы нормальная бд с нормальными индексами получается значительно в выигрыше

Это если поиск по содержимому файлов. А тут у нас структура каталогов дает сразу индекс по логину и дате. И никакого scandir и поиска по содержимому - сразу попадаем к нужным данным.

[shark3d 1]

Т.е. несколько учеток и один общий кошелек? Тогда это тоже на 80% реализовано. Т.н. "копрорации", которые пока только существуют в базе и никак себя не проявляют.

Да, именно так, но с возможностью привязывать еще и дополнительные услуги к этому кошельку, скидки...

Плюс привязывать учетки к сервисам (VPN, прямой доступ, VoIP), чтобы один логин/пароль не использовался для нескольких сервисов одновременно.

 

Эти "корпорации" заметил и долго думал для чего они нужны...

 

Было бы очень удобно иметь репозиторий SVN и размещение проекта где-то на SF или Google. Лече было бы следить за изменениями и помогать развитию...

[nallien 3]

как давнейший пользователь стара могу подтвердить что его уникальность и неоспоримый плюс перед многими другими аналогичными системами - обвязка сомописными приложениями. и мне кажется нет необходимости пытаться функции этих приложений включить в сам СТГ, пусть они по прежнему будут внешними.

 

а сосредоточить внимание - таки да - на возможности более широкого учета, мультилогинов, виртуальных счетов, скидкам и прочем ну и отладкой всего этого добра. я так понимаю технических тут ничего особо сложного нет. а в плане чего хотелось бы на вырост - это таки да - четко, ясно и стабильно работающая связка с sql БД. ну и самое основное (как по мне) - альтернативный конфигуратор, имхо - не нужно изобретать велосипед а сделать единое веб-решение, поддерживаемое авторами (пусть и разработанное не ими) и работающее с любой поддерживаемой БД.

 

и да - даже в текущем состоянии стг прекрасно справляется с базой абонентов около 2-4 тысяч.

[Serjio 19]

Было бы очень удобно иметь репозиторий SVN и размещение проекта где-то на SF или Google. Лече было бы следить за изменениями и помогать развитию...

 

Дык, помогайте и следите на форуме.

Если Вам прям так уж хочется сделать svn co http://stg.dp.ua/svn/stg-2.406, то так прямо и попросите разработчиков