Если logrotate для файла access.log у squid настроен на маленький размер файла и стоит дискретная обработка логов через длительный период времени, то возможна ситуация когда access.log будет ротирован дважды в этот установленный период и часть трафика не будет учтена.

Схожая ситуация Допустим, файл ротируется каждый час, а обработчик логов запускается каждые 40 минут тогда имеем примерно следующее: 00:00 запущена вся система с нуля, файл access.log нулевой обработчик логов обрабатывает информацию за период до 00:00 00:40 обработчик логов обрабатывает информацию за период 00:00-00:40 01:00 файл access.log ротируется 01:20 запускается обработчик логов и должен обрабатывать информацию за период 00:40-01:20, но данные в интервале времени 00:40-01:00 еще не обработаны, но уже в архиве, и не попадают в статистику

частичное решение проблемы: в настройках logrotate для файла access.log вставить строку prerotate /путь/к/файлу/samsparser endscript

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

Во избежание этой проблемы можно добавить опцию --wait-myself при которой обработчик не заканчивает работу если обнаружил уже запущенную копию, а ждет ее завершения и, дождавшись, выполняет порученное задание.

для обнаружения утечек памяти можно использовать valgrind --show-reachable=yes --log-file=samsparser.valgrind --leak-check=full ./samsparser

Таблица reconfig, возможные значения proxy/shutdown - Выполняется команда SHUTDOWNCMD из файла sams2.conf samsdaemon/shutdown - Завершается работа демона samsdaemon samsdaemon/reload - Обновляются настройки и данные из файла sams2.conf и базы данных squid/reconfig - Обновляются настройки и данные из файла sams2.conf и базы данных, обновляется конфигурационный файл squid с последующим его перезапуском. database/export - Содержимое таблицы squidcache записывается во внешний файл. Используется только для тестов(!)

Для того чтобы заработали плагины получения системной информации необходимо: 1) make -f Makefile.cvs 2) mkdir test 3) cd test 4) ../configure 5) make 6) su тут пароль 7) make install 8) mv /usr/local/lib/sams2/libloadavg.1.0.0 /usr/local/lib/sams2/libloadavg.so 9) /usr/local/bin/samsdaemon 10) exit (выход из рута) 11) mysql -u SAMSпользователь -p SAMSбаза_данных тут пароль CREATE TABLE sysinfo ( s_proxy_id INT NOT NULL , s_name VARCHAR( 50 ) NOT NULL , s_version VARCHAR( 10 ) NOT NULL , s_author VARCHAR( 30 ) NULL DEFAULT 'anonymous', s_info VARCHAR( 1024 ) NOT NULL DEFAULT 'not available', s_date DATETIME NOT NULL , s_status INT NOT NULL ); UPDATE websettings SET s_version='2.9.9'; 12) Дождаться когда пройдет время анализа access.log, если все прошло без ошибок, то в таблице sysinfo должна появится запись о подключенном плагине Этот плагин нужно активировать. update sysinfo set s_status=1; 13) Если поле s_date в данной записи меняется, значит плагин загружен и активен. Сам плагин тестовый и на самом деле всегда выдает одну и ту-же информацию. Его можно деактивировать: update sysinfo set s_status=0; 14) Выгрузить плагин пока можно только остановив демон, удалив файл плагина и снова запустив демон. 15) При возникающих проблемах рекомендую устанавливать уровень отладки 5 /usr/local/bin/samsdaemon -v -d5 -l file:/var/log/samsdaemon --fork 6й уровень еще выдержать можно, а выше это уже перебор PS Если не трогать структуру БД и оставить ее версию 1.9.9, но подключить плагин и включить режим verbose, то в сообщениях можно увидеть какой плагин подключен и что он сообщает

Как работает замена (перенаправление) адресов 1) Для начала необходимо убедится что структура БД позволяет это использовать, для этого нужно проверить существование поля s_dest в таблице redirect, и при необходимости добавить: ALTER TABLE redirect ADD s_dest VARCHAR( 128 ) NULL ; 2) Создаем группу перенаправления INSERT INTO redirect ( s_redirect_id , s_name , s_type , s_dest) VALUES ( NULL , 'GroupName', 'replace', 'http://www.ru'); 3) Заполняем группу шаблонами INSERT INTO url ( s_url_id , s_redirect_id , s_url) VALUES ( NULL , '12', '*.mail.ru\b'), ( NULL , '12', 'http://www.pisem.net/'); 12 - это значение s_redirect_id, полученное в п.2 4) Привязываем группу к шаблону INSERT INTO samsdb.sconfig ( s_shablon_id , s_redirect_id) VALUES ( '1', '12'); 12 - это значение s_redirect_id, полученное в п.2 1 - идентификатор шаблона 5) Перечитываем конфигурацию в редиректоре squid -k reconfig 6) Теперь при попытке набрать адрес http://www.pisem.net/ или mail.ru, www.mail.ru и т.д. Редиректор перенаправит на http://www.ru

Изменение шаблона пользователя при блокировке 1) Проверяем структуру БД и при необходимости подправляем ее ALTER TABLE shablon ADD s_shablon_id2 BIGINT( 20 ) UNSIGNED NULL ; 2) В существующем шаблоне в поле s_shablon_id2 прописываем идентификатор СУЩЕСТВУЮЩЕГО шаблона. 3) Пересобираем демонов, останавливаем, обновляем, стартуем. 4) Теперь работать это будет так: Если у шаблона, которому принадлежит пользователь, вторичный шаблон прописан (т.е. не NULL и не -1) То вместо блокировки у пользователя меняется статус на "Временно в другом шаблоне", и все параметры берутся из вторичного шаблона. Если же вдруг пользователь превысил лимиты и вторичного шаблона, то статус становится "Неактивный". Для того чтобы в таких случаях корректно работали ограничения по трафику, необходимо чтобы у самого пользователя стояло ограничение -1 (означающее что лимиты брать из шаблона). По окончанию периода лимита счетчики пользователя очищаются и статус меняется на активный. 5) Какие могут быть проблемы и неувязки: Q1) Разный тип авторизации основного и вторичного шаблона. A1) Сам дурак, думай что делаешь. Q2) Пользователи, временно находящиеся во вторичном шаблоне, так и не вернулись в основной, хотя период ограничения основного шаблона закончился. A2) Значит во вторичном шаблоне установлен другой период, они вернутся когда закончится период вторичного шаблона. Q3) Пользователя переместили в другой шаблон, а он игнорирует настройки нового шаблона. A3) Видимо, его переместили когда у него был статус "Временно в другом шаблоне", и у нового шаблона установлен вторичный. Поменяйте статус пользователя на "Активный".

В web интерфейсе можно выбрать скрипт, который нужно выполнить при отключении пользователей. Этот скрипт должен находится вместе с файлами web интерфейса. Однако демоны могут быть установлены на другой машине и не будут иметь доступа к этому скрипту. В свою очередь, из web интерфейса нет возможности получить список таких скриптов, если они находятся вместе с файлами демонов. Таким образом, единственный вариант получить этот список - это составлять его с помощью демона и складывать в БД. К тому-же на каждом прокси сервере этот список может отличатся. Следующая дополнительная таблица может решить эту проблему. CREATE TABLE udscripts ( s_proxy_id INT NOT NULL , s_name VARCHAR( 50 ) NOT NULL , ); Заполняется таблица при старте демона и при получении команды на перечитывание настроек (или реконфигурировании squid). Так-же возможен вариант заполнения (проверки актуальности) таблицы при парсинге лог файлов squid.

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

Коды в samslog 10 - служебные сообщения от демонов (samsdaemon, samsparser, sams2redir) 04 - сообщения от администраторов (устарело) 03 - сообщения об изменении базы записей squid 02 - сообщения, связанные с изменением групп адресов 01 - сообщения, связанные с изменением состояния пользователей