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]

  В 04.02.2011 в 09:20, madf сказав:

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

Спасибо. )

 

  В 04.02.2011 в 09:20, madf сказав:

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

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

 

  В 04.02.2011 в 09:20, madf сказав:

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

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

 

  В 04.02.2011 в 09:20, madf сказав:

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

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

 

  В 04.02.2011 в 10:41, madf сказав:

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

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

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

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

 

  В 04.02.2011 в 09:20, madf сказав:

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]

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

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

 

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

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

 

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

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

 

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

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

[DarkSpider 36]

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

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

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

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

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

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

 

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

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

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

[DarkSpider 36]

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

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

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

[Небесный 26]

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

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

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

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

 

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

[Alexey Osipov 38]

  В 05.02.2011 в 18:50, DarkSpider сказав:

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

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

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

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

 

 

  В 05.02.2011 в 18:53, DarkSpider сказав:

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

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

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

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

apt-get install stargazer

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

 

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

apt-get install stargazer-storage-mysql

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

[madf 279]

  В 05.02.2011 в 17:37, Alexey Osipov сказав:

...

 

  В 04.02.2011 в 10:41, madf сказав:

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

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

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

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

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

  В 05.02.2011 в 17:37, Alexey Osipov сказав:

 

...

 

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

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 (а они довольно корявы) - его можно спокойно использовать.

 

  В 05.02.2011 в 17:37, Alexey Osipov сказав:

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]

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

...

  В 05.02.2011 в 13:21, DarkSpider сказав:

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

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

 

...

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

[madf 279]

  В 05.02.2011 в 20:03, Небесный сказав:

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

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

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

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

 

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

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

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

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

[Alexey Osipov 38]

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

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

  Цитата

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

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

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

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

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

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

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

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

 

  В 05.02.2011 в 18:50, DarkSpider сказав:

  В 05.02.2011 в 17:46, Alexey Osipov сказав:

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

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

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

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

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

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

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

 

 

  В 06.02.2011 в 10:36, madf сказав:

  В 05.02.2011 в 17:37, Alexey Osipov сказав:

...

 

  В 04.02.2011 в 10:41, madf сказав:

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

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

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

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

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

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

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

 

  В 06.02.2011 в 10:36, madf сказав:

  Цитата

Итого получается, что для разработчиков сторонних плагинов требуется создать -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/

 

  В 06.02.2011 в 10:36, madf сказав:

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

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

 

  В 06.02.2011 в 10:38, madf сказав:

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

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

[DarkSpider 36]

  В 08.02.2011 в 11:52, Alexey Osipov сказав:

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

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, не очень удобно обрабатывать по дате