Для нормальной работы MySQL с UTF-8 была проделана небольшая настройка:
[mysqld] init_connect='SET collation_connection = utf8_unicode_ci' init_connect='SET NAMES utf8' character-set-server=utf8 collation-server=utf8_unicode_ci skip-character-set-client-handshakeПроизведённые выше действия с конфигурационным файлов привели к корректной работе с кириллическими символами. Не знаю как будет у Вас, но у меня кириллица упорно сохранялась и отображалась в win1252 (latin1).
После успешной загрузки и настройки MySQL распакуем полученный архив в директорию расположения веб-страниц:
sudo tar xzf screensquid_v1_5.tar.gz -С /var/www/В связи с тем, что помимо анализатора логов ScreenSquid у меня там хранятся и другие страницы, переименую его:
sudo mv /var/www/html /var/www/screensquid/Переходим к созданию базы данных, в которой будут храниться логи, и заполнению её таблицами (отношениями).
Подключимся:
mysql -u[user_name] -p[password]и создадим новую базу данных:
CREATE DATABASE squidreport DEFAULT CHARACTER SET=utf8;после чего произведём её заполнение, воспользовавшись прилагаемым к ScreenSquid файлом createdb.sql:
SOURCE /var/www/squidreport/createdb/createdb.sqlЧтобы не подключаться и не светить права root создадим нового пользователя mysql и наделим его полными правами к созданной БД:
CREATE USER 'user_name'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON squidreport.* TO 'user_name'@'localhost';С самой сложной часть сего Марлезонского балета покончено и мы плавно переходим к редактированию конфигурации ScreenSquid. Вместо user_name и password указываем те значения, которые мы ввели выше:
sudo vi /var/www/squidreport/config.php
$db = "squidreport"; $user = "user_name"; $pass ="password"; $address ="localhost";и в скрипте заполнения таблиц БД:
sudo vi /var/www/squidreport/fetch.pl
my $user = "user_name"; my $pass = "password"; my $db = "squidreport";В завершении всего этого безобразия настроим cron для запуска скрипта, который запускает парсер:
sudo crontab -eкуда добавим следующую запись:
# запуск каждый день в 23 часа 00 23 * * * /var/www/squidreport/fetch.shСам файл представляет простейший скрипт следующего содержания:
#!/sbin/sh cd /var/www/squidreport/ perl /var/www/squidreport/fetch.plМожно, конечно же, переписать парсер, чтобы он принимал файл лога в качестве параметра вызова или прописать полный путь к нему, но я решил это не делать =)
Казалось бы всё хорошо и работу можно считать законченной, но есть нюанс. Ротация логов SQUID выполняется не с помощью squid -k rotate, а с помощью программы logrotate, запускаемой с через cron. Указанный выше logrotate работает по расписанию cron.daily. Расписание запуска можно подсмотреть в /etc/crontab, где будет написано следующее:
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )Иными словами ротация логов происходит в 6:25 ежедневно. Но мы настроили, что access.log будет парситься 23:00. В итоге получаем, что время с 23:00 по 6:25 в базу данных попадать не будет.
Меня это совсем не устраивает, поэтому было решено следующее. Т.к. после запуска logrotate к текущему access.log прибавляется 1, файл уже недоступен для SQUID для внесения в него изменений и считается сформированным, и именно по этой причине для заполнения базы данных будем использовать именно его. Для чего потребовалось внести небольшие изменения в файл парсера fetch.pl:
#open(IN, "<access.log");
open(IN, "<access.log.1");
while (my $line=<IN>) {
@item = split " ", $line;
А вот на этом работу можно считать выполненной. Можно было сделать немного иначе. Например, вызывать парсер каждые N-минут(часов), но у меня нет необходимости иметь настолько своевременный отчёт, а мгновенный отчёт получаю с помощью sqstat 1.20, который прекрасно справляется со своей задачей.
