DEB-пакеты и PPA для Stargazer

[Alexey Osipov 38]

Ubuntu-репозиторий со Stargazer'ом.

https://launchpad.net/~lion-simba/+archive/stargazer

 

Новости

24.04.2011

• Собраны и выложены в репозиторий пакеты для Stargazer 2.407
  

29.08.2011

• Собраны и выложены в репозиторий пакеты для Stargazer 2.407-p1
  

 

ВНИМАНИЕ:

Для успешного обновления Stargazer должен быть остановлен. Если Stargazer будет запущен, ничего страшного не произойдет, но обновление завершится ошибкой. Подробности здесь.

 

Содержимое

В репозитории находится один исходный пакет Debian, из которого собираются 24 бинарных пакета. Пакеты представлены для серии 10.04 Lucid Lynx и для серии 10.10 Maverick Meerkat.

* freeradius-stargazer FreeRADIUS module for stargazer

* rscriptd stargazer remote script execute daemon

* sgauth stargazer authorization utility

* sgconf legacy command-line utility to configure Stargazer

* sgconf-xml command-line xml-based utility to configure Stargazer

* stargazer a powerful net billing system

* stargazer-common a powerful net billing system (common files)

* stargazer-convertor stargazer storage convertor utility

* stargazer-dev development files for stargazer

* stargazer-doc documentation for stargazer

* stargazer-mod-auth-alwaysonline Stargazer authentication module: Always Online

* stargazer-mod-auth-inetaccess Stargazer authentication module: InetAccess

* stargazer-mod-auth-radius Stargazer authentication module: Radius

* stargazer-mod-cap-ether Stargazer capture module: Ethernet

* stargazer-mod-cap-ipq Stargazer capture module: IPQ

* stargazer-mod-cap-netflow Stargazer capture module: NetFlow

* stargazer-mod-conf-rpc Stargazer configuration module: XMLRPC

* stargazer-mod-conf-sgconf Stargazer configuration module: SGConf

* stargazer-mod-ping Stargazer module: Ping

* stargazer-mod-remotescript Stargazer module: Remote Script

* stargazer-storage-files storage plugin for Stargazer based on plain files

* stargazer-storage-firebird storage plugin for Stargazer using PostgreSQL

* stargazer-storage-mysql storage plugin for Stargazer using MySQL

* stargazer-storage-postgresql storage plugin for Stargazer using PostgreSQL

 

Модули хранения данных и плагины специально разделены по отдельным пакетам, чтобы устанавливались только необходимые зависимости (скажем, зачем мне libmysqlclient, если я использую файловую БД). Кроме того, модули хранения данных снабжены скриптами конфигурации Debconf (см. ниже).

 

В пакете stargazer-doc собрана вся найденная мной в исходниках документация и примеры скриптов.

 

Пакет stargazer-common содержит общие программные библиотеки, которые используются как самим старгейзером, так и вспомогательными утилитами.

 

Для всех программ написаны man-страницы. Пока только на английском.

 

Все пакеты проверялись у меня на машине и на тестовом сервере под Ubuntu 10.04 Lucid Lynx. Сообщается также, что пакеты работают в Ubuntu 10.10 Maverick Meerkat. Отчеты о работе (в том числе в Maverick, Natty, Debian) всячески приветствуются. Предложения и пожелания рассматриваются.

 

Конфигурация

Пакеты stargazer и rscriptd снабжены файлами конфигурации Upstart, которые позволяют управлять этими демонами в современной манере:

start stargazer
stop rscriptd
status stargazer

Кроме того, Upstart обеспечивает запуск и остановку демонов при загрузке/выключении системы, а также перезапускает их в случае падения.

 

Пакеты модулей хранения (stargazer-storage-) снабжены скриптами конфигурации Debconf, что позволяет настраивать их ещё до фактического начала установки. Например, по вашему указанию установить пакет stargazer-storage-mysql, у вас будут запрошены желаемые параметры подключения к MySQL (хост, логин, пароль, имя базы), которые будут автоматически вписаны в конфигурационный файл Stargazer и, кроме того, по вашему желанию, Debconf может создать и базу данных (для этого он спросит root-пароль MySQL). Если вы выберите для установки сразу несколько модулей хранения, то Debconf вначале спросит вас о том, какой именно модуль вы хотите использовать и изменит соответствующим образом конфигурационные файлы Stargazer. Вы можете в дальнейшем свободно переключаться между модулями, используя стандартную утилиту переконфигурации пакета Debian - dpkg-reconfigure.

 

Полноценный Debconf-конфигуратор, однако, доступен только для модуля хранения MySQL, так как у меня нет опыта работы ни с PostgreSQL и Firebird, а в файловой БД и конфигурировать нечего.

 

Планируется, что после долгосрочного тестирования в Ubuntu, пакеты из этого репозитория переедут в Debian. Я старался их делать в полном соответствии с Руководством по политике Debian.

[madf 279]

Отличная работа!

Патчи еще не смотрел, но думаю часть из них можно будет внести в основную ветку.

Библиотеки dotconfpp и ibpp по сути сторонние. ibpp вполне живая и для мейнтейнеров лучше использовать внешнюю а не внутреннюю. dotconfpp, на сколько я понял, мертвая. Можно попробовать сделать ее отдельным пакетом.

Еще мне не понятно как с остальными плагинами. Так, например, mod_conf_rpc зависит от библиотеки xmlrpc-c - его можно было бы ставить отдельным пакетом чтобы не тащить по зависимостям для тех кто не использует XML RPC API.

Переход на UTF8 в планах есть. Там даже не так много работы. Основная проблема - виндовые авторизатор и конфигуратор, которые работают с cp1251 (а названия направлений вообще в koi8).

Надеюсь это начинание поспособствует пинку мне под зад и я сделаю то что давно планировал - ebuild'ы для Gentoo

[madf 279]

И, к стати, да - в dotconfpp были внесены изменения. В частности - для поддержки conf-enabled.d

[madf 279]

Про пароли и прочие Encode12: обратная совместимость. Да, правильно было бы хранить хеш, а вместо Encode12 использовать base64, а в протоколах конфигуратора и авторизатора вместо собственного шифрования использовать OpenSSL. Да и вообще вместо libstg_crypto использовать OpenSSL. Но обратная совместимость будет потеряна.

[madf 279]

Принял следующие патчи:

sgauth-not-started.patch - as-is;

sgauth-read-default-config.patch - as-is;

example-script-syntax-error.patch - as-is;

dont-change-mode-on-directories.patch - неявно (ввел дополнительную переменную DIR_MODE=0755);

absent-sgconf-conf.patch - просто убрал target install-data;

use-relative-symlinks.patch - as-is.

 

Остальные или специфичны для Debian/Ubuntu или пока нельзя применить без последствий (как, например, с UTF8).

 

Кроме этого заметил и исправил пару багов в uninstall. Все уже в Git.

[DarkSpider 36]

Большой РЕСПЕКТ за проделанную работу.

Не поленился поставить 10.04 на виртуалку(к сожалению 10.10 нет шаблонов под XEN).

root@ubuntu-test:/home/spider# uname -a
Linux ubuntu-test 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux

Добавляем репозиторий:

root@ubuntu-test:/home/spider# add-apt-repository ppa:lion-simba/stargazer
The program 'add-apt-repository' is currently not installed.  You can install it by typing:
apt-get install python-software-properties

Ставим:

apt-get install python-software-properties

И еще раз:

root@ubuntu-test:/home/spider# add-apt-repository ppa:lion-simba/stargazer
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv D3B36944BD5F7DCF1F7F4B6D60733897788E7305
gpg: requesting key 788E7305 from hkp server keyserver.ubuntu.com
gpg: key 788E7305: public key "Launchpad Hewlett Packard 2400 scanner linux drivers" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Успешно.

Пробуем:

root@ubuntu-test:/home/spider# apt-get install stargazer
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Couldn't find package stargazer

Нету ибо как не обновили информацию.

root@ubuntu-test:/home/spider# apt-get update

И теперь :

root@ubuntu-test:/home/spider# apt-get install stargazer
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
 libcurl3 libxmlrpc-c3 libxmlrpc-core-c3 stargazer-common
 stargazer-storage-files
The following NEW packages will be installed:
 libcurl3 libxmlrpc-c3 libxmlrpc-core-c3 stargazer stargazer-common
 stargazer-storage-files
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,081kB of archives.
After this operation, 3,232kB of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://ppa.launchpad.net/lion-simba/stargazer/ubuntu/ lucid/main stargazer-common 2.407~rc2-1 [80.7kB]
Get:2 http://ua.archive.ubuntu.com/ubuntu/ lucid/main libcurl3 7.19.7-1ubuntu1 [227kB]
Get:3 http://ppa.launchpad.net/lion-simba/stargazer/ubuntu/ lucid/main stargazer-storage-files 2.407~rc2-1 [65.9kB]
Get:4 http://ppa.launchpad.net/lion-simba/stargazer/ubuntu/ lucid/main stargazer 2.407~rc2-1 [469kB]
Get:5 http://ua.archive.ubuntu.com/ubuntu/ lucid/main libxmlrpc-core-c3 1.06.27-1ubuntu7 [99.9kB]
Get:6 http://ua.archive.ubuntu.com/ubuntu/ lucid/main libxmlrpc-c3 1.06.27-1ubuntu7 [139kB]
Fetched 1,081kB in 1s (610kB/s)                                
Preconfiguring packages ...
Selecting previously deselected package libcurl3.
(Reading database ... 43526 files and directories currently installed.)
Unpacking libcurl3 (from .../libcurl3_7.19.7-1ubuntu1_amd64.deb) ...
Selecting previously deselected package libxmlrpc-core-c3.
Unpacking libxmlrpc-core-c3 (from .../libxmlrpc-core-c3_1.06.27-1ubuntu7_amd64.deb) ...
Selecting previously deselected package libxmlrpc-c3.
Unpacking libxmlrpc-c3 (from .../libxmlrpc-c3_1.06.27-1ubuntu7_amd64.deb) ...
Selecting previously deselected package stargazer-common.
Unpacking stargazer-common (from .../stargazer-common_2.407~rc2-1_amd64.deb) ...
Selecting previously deselected package stargazer-storage-files.
Unpacking stargazer-storage-files (from .../stargazer-storage-files_2.407~rc2-1_amd64.deb) ...
Selecting previously deselected package stargazer.
Unpacking stargazer (from .../stargazer_2.407~rc2-1_amd64.deb) ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db ...
Setting up libcurl3 (7.19.7-1ubuntu1) ...

Setting up libxmlrpc-core-c3 (1.06.27-1ubuntu7) ...

Setting up libxmlrpc-c3 (1.06.27-1ubuntu7) ...

Setting up stargazer-common (2.407~rc2-1) ...
Setting up stargazer-storage-files (2.407~rc2-1) ...
restart: Unknown job: stargazer

Setting up stargazer (2.407~rc2-1) ...
stargazer start/running, process 855

Processing triggers for libc-bin ...
ldconfig deferred processing now taking place

Смотрим :

root@ubuntu-test:/home/spider# ps aux | grep stargazer
root       855  0.5  0.1 169120  2784 ?        S<sl 15:06   0:00 stargazer
root       875  0.0  0.0   7624   924 hvc0     S+   15:06   0:00 grep --color=auto stargazer

Пробовал конфигуратор - все работает.

Еще раз БОЛЬШОЙ респект !

Вопрос - я так понимаю для обновления достаточно будет : apt-get upgrade ?

Как поведет себя на реально работающем сервере ?

Выгрузится (у всех инета нет), потом запустится ?

Если я менял под свои нужды : /etc/init.d/stargazer - он будет заменен новым ?

[Alexey Osipov 38]

Отличная работа!

Спасибо. )

 

Библиотеки dotconfpp и ibpp по сути сторонние. ibpp вполне живая и для мейнтейнеров лучше использовать внешнюю а не внутреннюю.

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

 

Еще мне не понятно как с остальными плагинами. Так, например, mod_conf_rpc зависит от библиотеки xmlrpc-c - его можно было бы ставить отдельным пакетом чтобы не тащить по зависимостям для тех кто не использует XML RPC API.

Да, точно. Плагины тоже можно раскидать по пакетам.

 

Переход на UTF8 в планах есть. Там даже не так много работы. Основная проблема - виндовые авторизатор и конфигуратор, которые работают с cp1251 (а названия направлений вообще в koi8).

Вот о чем и речь. Чехарда с кодировками. Значит нужно править везде одновременно - и в сервере, и в конфигураторе и в авторизаторе. Кстати, если авторизатор/конфигуратор при соединении с сервером сообщают ему свою версию, можно даже обратную совместимость сохранить. Хотя в принципе я не вижу ничего плохого в том, чтобы потребовать юзверей скачать новую версию авторизатора.

 

Про пароли и прочие Encode12: обратная совместимость. Да, правильно было бы хранить хеш, а вместо Encode12 использовать base64, а в протоколах конфигуратора и авторизатора вместо собственного шифрования использовать OpenSSL. Да и вообще вместо libstg_crypto использовать OpenSSL. Но обратная совместимость будет потеряна.

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

Но опять же, я ничего плохого не вижу в том, чтобы поменять протоколы авторизатора/конфигуратора с некоторой версии Х.

А с OpenSSL вообще красиво было бы. Нужно стараться по-максимому использовать чужой код.

 

dotconfpp, на сколько я понял, мертвая. Можно попробовать сделать ее отдельным пакетом.

Оказывается, в репозиториях убунту есть dotconf, а не dotconfpp (С++'ный вариант). Так что эту тоже буду использовать внутреннюю, тем более что она доработанная.

 

Вообщем, я тут ещё провёл анализ использования библиотек старгейзера различными его компонентами и плагинами и пришел к следующим выводам:

1) Сторонние плагины для старгейзера совершенно не обязательно линковать с библиотеками старгейзера. Достаточно, чтобы при сборке плагина были доступны все необходимые заголовочные файлы (часть из папки include, а часть из папок с библиотеками stglibs/*.lib/).

2) Причиной вынесения части кода старгейзера в библиотеки (so-файлы) явилось то, что этот код используется в нескольких проектах (сам сервер, авторизатор, конфигураторы, rscriptd, ...).

 

Поэтому... так как библиотеки старгейзера фактически являются частями самого старгейзера и никаких целостных законченных функциональных возможностей не предоставляют, выносить их на общесистемный уровень (/usr/lib/), а также в отдельный пакет, смысла не имеет.

 

За исключением, пожалуй, ibpp и dotconfpp. Однако, я довольно далёк от Firebird, чтобы поддерживать его библиотеку. А что касается dotconfpp, то, раз это модифицированный вариант, опять же выносить в отдельный пакет смысла нет. Вот тут я бы тоже посмотрел, что нынче является стандартом де-факто для парсинга конфигов. Наверняка ведь есть что-то удобное.

 

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

 

PS. Ещё один мелкий патч (useless-conffiles-binding.patch):

MySQL store plugin doesn't use any external conffiles.
--- a/projects/stargazer/plugins/store/mysql/Makefile
+++ b/projects/stargazer/plugins/store/mysql/Makefile
@@ -8,7 +8,7 @@

SRCS = ./mysql_store.cpp

-STGLIBS = -lconffiles -lstg_common -lstg_crypto
+STGLIBS = -lstg_common -lstg_crypto

MYSQL_CFLAGS = $(shell mysql_config --cflags)
MYSQL_LDFLAGS = $(shell mysql_config --libs_r)

[Alexey Osipov 38]

Вопрос - я так понимаю для обновления достаточно будет : apt-get upgrade ?

Да. Как только я соберу свежую версию.

 

Как поведет себя на реально работающем сервере ?

Я думаю, вы второй человек (после меня), кто пробует этот репозиторий. Даже я его ещё на продакшн-сервере не применял (но собираюсь). Вообщем, до поры до времени, я бы относился к нему как к Beta-версии. Тем не менее, обещаю быть как можно более аккуратным при обновлении версии. Мне нужно больше отзывов.

 

Выгрузится (у всех инета нет), потом запустится ?

Сейчас в скриптах прописана перезагрузка только в случае переконфигурации (dpkg-reconfigure). При обновлении - будет продолжать работать старая версия до момента её ручной перезагрузки. Можно сделать и автоматически, но стоит ли?

 

Если я менял под свои нужды : /etc/init.d/stargazer - он будет заменен новым ?

/etc/init.d/stargazer в пакете не используется (файл такой есть, но это просто заглушка), я использую Upstart - /etc/init/stargazer.conf.

[DarkSpider 36]

Я думаю, вы второй человек (после меня), кто пробует этот репозиторий. Даже я его ещё на продакшн-сервере не применял (но собираюсь). Вообщем, до поры до времени, я бы относился к нему как к Beta-версии. Тем не менее, обещаю быть как можно более аккуратным при обновлении версии. Мне нужно больше отзывов.

Ну я тоже не на продакшене запускал.

Сейчас в скриптах прописана перезагрузка только в случае переконфигурации (dpkg-reconfigure). При обновлении - будет продолжать работать старая версия до момента её ручной перезагрузки. Можно сделать и автоматически, но стоит ли?

Думаю - не стОит. Хотя нужно еще подумать дважды, чтобы дать правильный ответ

 

Если я менял под свои нужды : /etc/init.d/stargazer - он будет заменен новым ?

/etc/init.d/stargazer в пакете не используется (файл такой есть, но это просто заглушка), я использую Upstart - /etc/init/stargazer.conf.

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

[DarkSpider 36]

Кстати - при установке ничего не спросило про то, какую базу использовать.

Я так понимаю по-умолчанию установлена база в файлах и поменять можно через dpkg-reconfigure.

Но на момент установки ничего не спрашивало, с другой стороны сервер чистый - ни мускуля, ни постгрес, ни фб там не было - может поэтому и вопросов не было ?

[Небесный 26]

По поводу авторизатора!!!

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

Я думаю, что стоит сделать в авторизаторе, уже в новом, чтобы он мог обновляться!!!

Мало ли что еще может потом меняться.

 

Конфигуратор такое дело, админ и сам может его заменить.

[Alexey Osipov 38]

/etc/init.d/stargazer в пакете не используется (файл такой есть, но это просто заглушка), я использую Upstart - /etc/init/stargazer.conf.

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

Нет, не будет. Он помечен в пакете как "файл конфигурации". Это значит, что если в нём будут локальные изменения, установщик при обновлении спросит, что с ним делать - оставить старый или поставить новый. Может даже diff показать между ними.

 

 

Кстати - при установке ничего не спросило про то, какую базу использовать.

Я так понимаю по-умолчанию установлена база в файлах и поменять можно через dpkg-reconfigure.

Но на момент установки ничего не спрашивало, с другой стороны сервер чистый - ни мускуля, ни постгрес, ни фб там не было - может поэтому и вопросов не было ?

Вопросов не было потому, что вы не установили другие модули хранения. Вы сделали

apt-get install stargazer

который по умолчанию утянул за собой модуль хранения в файлах - stargazer-storage-files.

 

Попробуйте сейчас сделать:

apt-get install stargazer-storage-mysql

и увидите вопрос.

[madf 279]

...

 

Про пароли и прочие Encode12: обратная совместимость. Да, правильно было бы хранить хеш, а вместо Encode12 использовать base64, а в протоколах конфигуратора и авторизатора вместо собственного шифрования использовать OpenSSL. Да и вообще вместо libstg_crypto использовать OpenSSL. Но обратная совместимость будет потеряна.

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

Но опять же, я ничего плохого не вижу в том, чтобы поменять протоколы авторизатора/конфигуратора с некоторой версии Х.

А с OpenSSL вообще красиво было бы. Нужно стараться по-максимому использовать чужой код.

Я про обратную совместимость с БД. Если, например, PostgreSQL и Firebird хранят внутри себя версию схемы БД то у файловой базы и MySQL такого нет. Хотя, конечно, можно попробовать сделать. Надо подумать над этим.

 

...

 

Вообщем, я тут ещё провёл анализ использования библиотек старгейзера различными его компонентами и плагинами и пришел к следующим выводам:

1) Сторонние плагины для старгейзера совершенно не обязательно линковать с библиотеками старгейзера. Достаточно, чтобы при сборке плагина были доступны все необходимые заголовочные файлы (часть из папки include, а часть из папок с библиотеками stglibs/*.lib/).

2) Причиной вынесения части кода старгейзера в библиотеки (so-файлы) явилось то, что этот код используется в нескольких проектах (сам сервер, авторизатор, конфигураторы, rscriptd, ...).

 

Поэтому... так как библиотеки старгейзера фактически являются частями самого старгейзера и никаких целостных законченных функциональных возможностей не предоставляют, выносить их на общесистемный уровень (/usr/lib/), а также в отдельный пакет, смысла не имеет.

 

За исключением, пожалуй, ibpp и dotconfpp. Однако, я довольно далёк от Firebird, чтобы поддерживать его библиотеку. А что касается dotconfpp, то, раз это модифицированный вариант, опять же выносить в отдельный пакет смысла нет. Вот тут я бы тоже посмотрел, что нынче является стандартом де-факто для парсинга конфигов. Наверняка ведь есть что-то удобное.

 

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

По поводу dev-пакета согласен. А с библиотеками штука сложная. Изначально до какой-то из 2.4* версий все библиотеки Stargazer'а были статические и в работе ему были не нужны. Ставились только бинарники программ и плагины. И с ними была связанна маленькая проблема по поводу экспорта символов. Она естественным образом решилась после того как я перевел все библиотеки на динамическую компоновку. В последствии я понял что проблему можно (и нужно!) было решить проще, оставив библиотеки статическими (их действительно не использует никто кроме самого Stargazer'а). Тем более что динамичесике библиотеки при хранении в /usr/lib/stg требуют указания rpath (ну или модификации /etc/ld.so.conf и перегенерации кеша). Там не так много кода пересекается при использовании чтобы получить какой-то существенный выигрыш от использования динамической компоновки. С тех пор это обратное преобразование у меня так и висит в задачах. Уже с год, наверное. К стати, ALT'овский контроль качества тоже ругался на rpath.

В свое время Борис специально делал конфиг Stargazer'а максимально похожим на Apache'вский, т.к. большинство админов с ним знакомы. И единственная библиотека которая такое умела была dotconfpp. Сейчас в основном используются или ini-конфиги или XML/JSON. Так что сомневаюсь что найдется соответствующая "живая" библиотека. В принципе, если не смотреть на внутренности dotconfpp (а они довольно корявы) - его можно спокойно использовать.

 

PS. Ещё один мелкий патч (useless-conffiles-binding.patch):

MySQL store plugin doesn't use any external conffiles.
--- a/projects/stargazer/plugins/store/mysql/Makefile
+++ b/projects/stargazer/plugins/store/mysql/Makefile
@@ -8,7 +8,7 @@

SRCS = ./mysql_store.cpp

-STGLIBS = -lconffiles -lstg_common -lstg_crypto
+STGLIBS = -lstg_common -lstg_crypto

MYSQL_CFLAGS = $(shell mysql_config --cflags)
MYSQL_LDFLAGS = $(shell mysql_config --libs_r)

Спасибо, принято.

[madf 279]

...

Как поведет себя на реально работающем сервере ?

Я думаю, вы второй человек (после меня), кто пробует этот репозиторий. Даже я его ещё на продакшн-сервере не применял (но собираюсь). Вообщем, до поры до времени, я бы относился к нему как к Beta-версии. Тем не менее, обещаю быть как можно более аккуратным при обновлении версии. Мне нужно больше отзывов.

 

...

Минимум третий. Один из наших админов недавно тоже задался задачей собрать DEB и положить в PPA, но далеко не продвинулся. Зато обещает поделиться переводом конфига

[madf 279]

По поводу авторизатора!!!

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

Я думаю, что стоит сделать в авторизаторе, уже в новом, чтобы он мог обновляться!!!

Мало ли что еще может потом меняться.

 

Конфигуратор такое дело, админ и сам может его заменить.

Вопрос поднимается не впервые. Год назад обновление авторизатора в нашей сети принесло много мучений и проблем. Были даже предложения переписать авторизатор на Java. Но держать JRE на машине абонента для малюсенькой утилиты - это зло за которое, по моему скромному мнению, следует пороть розгами.

Проблема с обновлением в том что в Windows стоит куча защитных межанизмов которые просто не позволят заменить бинарник. А как это сделать культурно - я не знаю. У меня очень мало опыта написание программ под Windows. В *nix'ах же обновление принято делать через репозиторий. А так как InetAccess более развиваться не будет и я продвигаю qia то надо будет в нем реализовывать раздельные механизмы обновления. Самое простое что можно сделать сегодня - уведомление о выходе обновлений.

К стати, еще совсем непонятно как должно происходить обновление в Max OS X.

[Alexey Osipov 38]

Итак, обновления в репозитории.

Будут доступны как только launchpad их соберёт.

* Исправлены некоторые ошибки конфигурации модулей хранения.

* Убрана бесполезная линковка mod_store_mysql.so с libconffiles.so.

* Новый пакет: stargazer-dev, содержащий заголовочные файлы для

разработки внешних плагинов.

* Новое поведение установщика при обновлении пакетов (см. ниже)

* Плагины старгейзера разнесены по отдельным пакетам. Часто используемые

плагины добавлены в список рекомендуемых для пакета stargazer.

Теперь общее число собираемых бинарных пакетов из одного исходного - 24.

 

Сейчас в скриптах прописана перезагрузка только в случае переконфигурации (dpkg-reconfigure). При обновлении - будет продолжать работать старая версия до момента её ручной перезагрузки. Можно сделать и автоматически, но стоит ли?

Думаю - не стОит. Хотя нужно еще подумать дважды, чтобы дать правильный ответ

Так вот, я тут подумал. Дважды.

1) Если старгейзер не останавливать при обновлении, а просто заменить все файлы новыми версиями, то это может нарушить целостность данных. Скажем, если произошло изменение в схеме БД, то старая работающая версия старгейзера рано или поздно об это споткнется и упадёт. Нехорошо.

2) Если старгейзер принудительно останавливать при обновлении, то это значит, что при любом неосторожном apt-get upgrade можно случайно выключить биллинг. 8) Незапланированный отказ в обслуживании - тоже плохо.

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

При удалении пакета биллинг останавливается автоматически.

 

 

...

 

Про пароли и прочие Encode12: обратная совместимость. Да, правильно было бы хранить хеш, а вместо Encode12 использовать base64, а в протоколах конфигуратора и авторизатора вместо собственного шифрования использовать OpenSSL. Да и вообще вместо libstg_crypto использовать OpenSSL. Но обратная совместимость будет потеряна.

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

Но опять же, я ничего плохого не вижу в том, чтобы поменять протоколы авторизатора/конфигуратора с некоторой версии Х.

А с OpenSSL вообще красиво было бы. Нужно стараться по-максимому использовать чужой код.

Я про обратную совместимость с БД. Если, например, PostgreSQL и Firebird хранят внутри себя версию схемы БД то у файловой базы и MySQL такого нет. Хотя, конечно, можно попробовать сделать. Надо подумать над этим.

Можно просто поставлять вместе с очередным выпуском старгейзера скрипты для соответствующей модификации существующей БД (а для файловой БД можно извратиться с Perl'ом, например). Я у себя в пакетах могу их автоматически запускать при обновлении.

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

 

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

По поводу dev-пакета согласен.

Проверил. Действительно, заголовочных файлов вполне достаточно. Но. Они все разбросаны по разным частям исходников. Так, например, можно было бы подумать, что все общие заголовочные файлы содержаться в папке include, однако, допустим в файле base_plugin.h мы видим следующую конструкцию:

class ADMINS;
class USERS;
class TARIFFS;
class TRAFFCOUNTER;
class SETTINGS;
class BASE_STORE;

//-----------------------------------------------------------------------------
class BASE_PLUGIN : private NONCOPYABLE
{
public:
   virtual                 ~BASE_PLUGIN(){};
   virtual void            SetUsers(USERS * u) = 0;
   virtual void            SetTariffs(TARIFFS * t) = 0;
   virtual void            SetAdmins(ADMINS * a) = 0;
   virtual void            SetTraffcounter(TRAFFCOUNTER * tc) = 0;
   virtual void            SetStore(BASE_STORE * st) = 0;
   virtual void            SetStgSettings(const SETTINGS * s) = 0;

При этом определений классов ADMINS, USERS, TARIFFS, ... в заголовочных файлах папки include нет. Они определены в заголовочных файлах проекта stargazer. А многие заголовочные файлы проекта stargazer, в свою очередь, используют заголовочные файлы библиотек старгейзера (например, admins.h включает в себя stg_locker.h, который лежит в stglibs/stg_locker.lib). Получается, я вынужден собирать заголовочники из разных мест. Появляется вопрос, в -dev пакете их валить все в кучу или как-то разбивать по подпапкам? Моё предложение: навести порядок в заголовочных файлах проекта и всё, что необходимо для разработки сторонних модулей, вынести в папку include. А всё лишнее (если оно там есть) оттуда убрать.

На данный момент в -dev пакет кладутся следующие заголовочные файлы:

include/*.h /usr/include/stargazer/
stglibs/common.lib/*.h /usr/include/stargazer/
stglibs/stg_logger.lib/*.h /usr/include/stargazer/
stglibs/stg_locker.lib/*.h /usr/include/stargazer/
stglibs/crypto.lib/*.h /usr/include/stargazer/
projects/stargazer/admin*.h /usr/include/stargazer/
projects/stargazer/user*.h /usr/include/stargazer/
projects/stargazer/eventloop.h /usr/include/stargazer/
projects/stargazer/traffcounter.h /usr/include/stargazer/
projects/stargazer/settings.h /usr/include/stargazer/
projects/stargazer/tariff*.h /usr/include/stargazer/
projects/stargazer/stg_timer.h /usr/include/stargazer/
projects/stargazer/actions*.h /usr/include/stargazer/

 

А с библиотеками штука сложная. Изначально до какой-то из 2.4* версий все библиотеки Stargazer'а были статические и в работе ему были не нужны. Ставились только бинарники программ и плагины. И с ними была связанна маленькая проблема по поводу экспорта символов. Она естественным образом решилась после того как я перевел все библиотеки на динамическую компоновку. В последствии я понял что проблему можно (и нужно!) было решить проще, оставив библиотеки статическими (их действительно не использует никто кроме самого Stargazer'а). Тем более что динамичесике библиотеки при хранении в /usr/lib/stg требуют указания rpath (ну или модификации /etc/ld.so.conf и перегенерации кеша). Там не так много кода пересекается при использовании чтобы получить какой-то существенный выигрыш от использования динамической компоновки. С тех пор это обратное преобразование у меня так и висит в задачах. Уже с год, наверное. К стати, ALT'овский контроль качества тоже ругался на rpath.

Ну понятно. В принципе-то... не должно быть сильно сложно сейчас взять и убрать везде -shared, оставив только статическую линковку.

 

Минимум третий. Один из наших админов недавно тоже задался задачей собрать DEB и положить в PPA, но далеко не продвинулся. Зато обещает поделиться переводом конфига

На английский? Это позитивно. Надо бы ещё ChangeLog перевести, да и в commit'ах git'а использование английского языка могло бы снизить барьер вхождения для не-украинских разработчиков.

[DarkSpider 36]

Так вот, я тут подумал. Дважды.

1) Если старгейзер не останавливать при обновлении, а просто заменить все файлы новыми версиями, то это может нарушить целостность данных. Скажем, если произошло изменение в схеме БД, то старая работающая версия старгейзера рано или поздно об это споткнется и упадёт. Нехорошо.

2) Если старгейзер принудительно останавливать при обновлении, то это значит, что при любом неосторожном apt-get upgrade можно случайно выключить биллинг. 8) Незапланированный отказ в обслуживании - тоже плохо.

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

При удалении пакета биллинг останавливается автоматически.

По первому вопросу - именно это и настораживает.

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

 

Довольно разумный выход, я думаю.

[Alexey Osipov 38]

В репозитории появились пакеты для Ubuntu 10.10 Maverick Meerkat. Пакеты те же, самые, что и для Ubuntu 10.04 Lucid Lynx.

[madf 279]

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

Конфиги в приложении и в git.

stg_confs.tar

[Alexey Osipov 38]

В репозитории появился быстрый NetFlow-измеритель: http://local.com.ua/forum/topic/26157-ipt-netflow-%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9-netflow-%D0%B8%D0%B7%D0%BC%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C/

[Alexey Osipov 38]

Собраны и выложены пакеты для Stargazer 2.407.

 

Изменено первое сообщение темы.

 

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

[Alexey Osipov 38]

С почти трёхмесячным опозданием собраны и выложены на ланчпаде пакеты для Stargazer 2.407-p1.

 

Проверил у себя на тестовом сервере - обновление прошло гладко.

 

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

 

PS. Я негодую по поводу функциональности нового движка форума: 1) я не могу отредактировать своё первое сообщение из этой темы, дабы актуализировать его; 2) я не могу отключить WYSIWYG редактор.

[madf 279]

Не глуши мотор, 2.408 на подходе

[yKpon 8]

madf, оффтоплю, но есть небольшой пожелание

 

копошусь в логах, неплохо бы выделить дате отдельную колонку в unixtime, не очень удобно обрабатывать по дате