Ранее в каждой сети на прокси был sams (Squid Account Management System) для squid
На данный момент с каждого прокси информация будет отправляться на 1 центральный прокси для сводки данных и их отображения
задача, найти парсер/обработчиков/анализатор логов squid
чтобы был аналогом sarg но с записью отчетов не в HTML файла в базу mysql
написать скрипты сбора логов со squid и копирования их на 1 сервер
на сервере поднять обработчик логов (выбрать обработчик установить настроить) в базу sql и отображения в web интерфейсе
Варианты с SQL
1 ScreenSquid
У этой программы другая логика: журнал импортируется в базу данных MySQL,
затем данные запрашиваются из нее при работе в веб-интерфейсе.
База с обработанным десятидневным логом, записи 26330490, занимает 1,5 Гб.
2 Sams — использовалась раньше на старых прокси SQL
3 squid-pb — система анализа и контроля пользователей прокси-сервера squid.
Возможности: блокирование доступа при окончании средств, кредитные зоны,
система управления аккаунтом пользователя, назначение стоимости трафика
из данной сети, отчеты. Парсер лога написан на Си, web-интерфейс на PHP,
база данных хранится в MySQL.
5 SquidParser — Система управления пользователями SQUID.
Система управления пользователями работающими через Squid: учет баланса, создание, удаление пользователей, прайсы.
Используется Perl и MySQL.
6 SquidLimit — подсчёт трафика для Squid
Микроскопическая система учёта трафика (позволяет устанавливать лимиты и отображать накопленную статистику)
по пользователям и группам для Squid. Написана на Perl и использует PostgreSQL.
7 Squid2MySQL — squid accounting system
Скрипт для анализа лог файла squid и помещения данных о трафике в MySQL базу.
Присутствует web-интерфейс на php для просмотра статистики.
файл конфига nano /etc/squid/squid.conf
файл конф хранения логов nano /etc/logrotate.d/squid
/var/log/squid/access.log или бывает /usr/local/squid/log/access.log
Squid имеет мощную систему подробного логирования для контроля проходящего через прокси-сервер траффика. Логи делятся на три различных журнала:
access.log — содержит записи о запросах клиентов;
store.log — содержит записи, относящиеся к действиям с кэшем;
cache.log — содержит сообщения об ошибках, возникающих при работе Squid.
netdb.state
squidmill.log
Чаще всего используется журнал access.log. Укажем в конфигурации собственный путь для его хранения:
Основные настройки logrotate хранятся в /etc/logrotate.conf
настройки отдельных сервисов (в нашем случае Squid) хранятся в /etc/logrotate.d/squid
и эти настройки имеют приоритет над logrotate.conf.
Сама служба вызывается раз в сутки через планировщик cron.
Нас интересует ротация логов только двух файлов access.log и cache.log.
Для файла access.log мы будем раз в месяц выполнять ротацию, а для файла cache.log раз в неделю.
Откроем для редактирования файл конфигурации
nano /etc/logrotate.d/squid
Варианты копирования
Копировать логи с прокси районов на центральный прокси и уже программой забирать данные в sql
Забирать нужную информацию и подливать в один файл логов или разные файлы для каждого района свой и уже программой забирать данные в sql
Передавать логи сразу в Sql централизованную базу (репликация)
Поставить на все прокси программы с SQL и с этих баз собирать инфу в центральную базу
Какую инфу тянуть из логов районов
Проверка скопировался лог или нет (при ошибке копирования или обрыве — возобновить или начать заново повторно) если не скопировался лог . аларм на почту когда связь появится
Очистка старых логов пол года
***********
Вопросы
Какую инфу тянуть из логов районов
Какой промежуток времени хранить информацию
Проверка скопировался лог или нет (при ошибке копирования или обрыве — возобновить или начать заново повторно)
Очистка старых логов
в идеале написать баш скрипт который будет подключаться по ssh к прокси и тащить лог к себе
если куда не смог подключиться. АЛАРМу на почту
Приведем файл настройки ротации логов для Squid в вид который нам нужно.
Разберем структуру написанного выше подробнее. Первая строка указывает путь к обрабатываемым файлам логов. В данном случае обрабатываются файлы access.log и cache.log в соответствии с указанными ниже опциями:
daily — задает ежедневную ротацию
weekly — задает еженедельную ротацию
monthly — задает ежемесячную ротацию
compress — указывает сжимать архивные логи, обратная опция nocompress.
delaycompress — не сжимать текущий лог до следующей ротации, обычно используется в тех случаях, когда в лог происходит непрерывная запись.
rotate 2 — количество ротаций до удаления файла, в данном случае будут храниться два архива.
missingok — при отсутствии файла журнала указывает продолжить работу без вывода сообщения об ошибке.
nocreate — не создавать новый файл лога.
Дополнение: Еще возможна секция prerotate, она добавляется автоматически при установке анализатора логов SARG и в случае если файл /usr/sbin/sarg-reports существует и является исполняемым, запускает его. В моем случае формирование отчетов в Sarg запускается по cron, поэтому я исключил его из конфигурации.
Т.к. мы ротацию будем осуществлять исключительно службой logrotate, то поправим конфигурацию squid
sudo nano /etc/squid/squid.conf
Находим строку logfile_rotate 6 (или добавляем ее в случае ее отсутствия). И приводим к виду
Подсказка: где 6 — число ротаций, Squid хранит несколько экземпляров логов, каждый файл лога будет обрабатываться logrotate. Число 0 указывает на отключение выполнении ротации файлов силами Squid
Сохраняем Ctrl+O и закрываем Ctrl+X файл.
Перезапускаем Squid, новые настройки вступят в силу. Вот так легко и просто настраивается ротация логов.
Качаем извлекаем screensquid_v1_12
перемещаем файлы архива по такому пути
/var/www/screensquid/
nano /etc/squid/squid.conf — просмотр cachemgr_passwd
cd /var/www/screensquid
chmod u+x fetch.pl
crontab -e
# запуск каждый день в 23 часа
00 23 * * * /var/www/screensquid/fetch.pl
Сам файл представляет простейший скрипт следующего содержания:
#!/sbin/sh
cd /var/www/squidreport/
perl /var/www/squidreport/fetch.pl
chown -R www-data:www-data /var/www/screensquid/lib/pChart/pictures/
Создание отдельного
Просмотр
ls etc/httpd2/conf/sites-enabled/
Копия cp /etc/httpd2/conf/sites-available/default.conf /etc/httpd2/conf/sites-available/screensquid.conf
a2ensite screensquid.conf — включение
a2ensite screensquid
проба a2ensite squidscreen.conf
a2dissite — отключение
apt-get install apache2-mod_php5
a2enmod mod_php5
Еще
nano /etc/php5/apache2/php.ini
где меняем значение параметрка session.gc_maxlifetime на 21600по умолчанию 1440 значение:
session.gc_maxlifetime = 21600
max_execution_time=6000
max_input_time=6000
перезапускаем
service httpd2 restart
service apache2 restart
Пример еще одно инструкции по обновлению Переходим с Screen Squid 1
Переходим с Screen Squid 1.7 на 1.10
Продолжу начатую ещё с версии 1.5 инструкцию по установке и первоначальной настройке Screen Squid. Теперь рассказ будет про 1.10. Возможно в процессе что-нибудь упущу, т.к. каждый раз инструкцию пишу по памяти, а не в процессе установки. Также, в отличие от предыдущих инструкций, упомяну здесь случай переноса некоторых данных с таблиц версии 1.7, т.к. по новой создавать алиасы, группы и их соединения вряд ли захочется.
Все дальнейшие пункты установки подразумевают, что у вас уже установлены http- и mysql-сервер, как и php с модулями mysql и iconv в случае необходимости. Замечу, что версия PHP 7 не будет работать с текущей версией Screen Squid, т.к. изменился драйвер mysql на mysqli. Возможно эту проблему можно допилить настройками, но я пока этим вопросом не заморачивался.
И так, приступим к установке 1.10.
По завершении конфигурирования парсера сделаем его исполняемым, воспользовавшись командой:
sudo chmod u+x fetch.pl
После чего настроим cron для запуска этого скрипта:
sudo crontab -e
куда добавим следующую запись:
# запуск каждый день в 23 часа
00 23 * * * /var/www/screensquid/fetch.pl
С конфигурированиями закончили, поэтому можно немного расслабиться и поиграться другими очень интересными и нужными командами.
В предыдущих версиях были добавлены графики и диаграммы в Dashboard и отчёте «По времени суток». Так как архив с анализатором мы распаковывали с правами root, именно он и стал владельцем всех каталогов и файлов. Менять владельца на всё не буду, поэтому ограничусь лишь каталогом, где создаются эти самые картинки:
sudo chown -R www-data:www-data /var/www/screensquid/lib/pChart/pictures/
Также в 1.10 появился экспорт некоторых отчётов в PDF, которые создаются в каталоге output. Ему также необходимо изменить владельца, как и пунктом выше.
Не забудьте заменить текст в фигурных скобках на название своей базы данных версии 1.7.
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 13 мая 2021 года; проверки требуют 12 правок.
Эта статья — о программном обеспечении. О высокочувствительном измерительном приборе см. СКВИД.
Squid (англ. — «кальмар») — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. Разработан сообществом как программа с открытым исходным кодом (распространяется в соответствии с GNU GPL). Все запросы выполняет как один неблокируемый процесс ввода-вывода.
Используется в UNIX-подобных системах и в ОС семейства Windows NT. Имеет возможность взаимодействия с Active Directory Windows Server путём аутентификации через LDAP, что позволяет использовать разграничения доступа к интернет ресурсам пользователей, которые имеют учётные записи на Windows Server, также позволяет организовать «нарезку» интернет-трафика для различных пользователей.
Используется вместе с движками Mediawiki на wiki-хостингах. Использование кэширующего прокси-сервера для сайтов становится выгодно примерно с 2000 посетителей в сутки.
Сервер Squid развивается в течение уже многих лет. Обеспечивает совместимость с большинством важнейших протоколов Интернета, а также с операционными системами:
Схема комплекса LAMP, работающего вместе с сервером Squid. Высокопроизводительное и отказоустойчивое решение для веб-сервера во враждебном окружении.
Списки контроля доступа
Squid поддерживает несколько видов идентификации пользователей:
Ограничение доступа для групп
Этот раздел статьи ещё не написан.
Здесь может располагаться Помогите Википедии, написав его. (31 декабря 2016)
Squid имеет возможность переписывать запрашиваемые URL. Squid может быть сконфигурирован так, чтобы пропускать входящие URL через процесс редиректора, выполняемого как внешний процесс (подобно dnsserver), который возвращает новый URL или пустую строку, обозначающую отсутствие изменений.
Редиректор не является стандартной частью пакета Squid. Редиректор предоставляет администратору контроль за передвижениями пользователей. Использование редиректора в сочетании с прозрачным проксированием даёт простой, но эффективный контроль над доступом к нежелательным ресурсам (например к развлекательным ресурсам и социальным сетям в корпоративной сети, порнографии). Программа-редиректор должна читать URL (один на строку) со стандартного входа и записывать изменённые URL или пустые строки на стандартный выход. Нужно заметить, что программа-редиректор не может использовать буферизированный ввод-вывод. Squid дописывает дополнительную информацию после URL, которую редиректор может использовать для принятия решения.
SAMS (SQUID Account Management System) — программное средство для администрирования доступа пользователей к прокси-серверу Squid.
На данный момент SAMS настраивает работу редиректоров:
Написан специально для SQUID, напрямую использует информацию, содержащуюся в базе данных. Позволяет включить различное перенаправление запросов для пользователей (регулируется шаблонами пользователей). Редиректор SAMS обеспечивает:
Мощный редиректор с большими возможностями. В состав редиректора входят списки баннерных, порно- и пр. доменов.
SAMS добавляет в файл конфигурации SquidGuard squidguard.conf настройки на списки запрещённых доменов и перенаправления доступа SAMS. Настройки на списки, идущие с SquidGuard, не изменяются и не удаляются.
При использовании редиректора SquidGuard в файл squid.conf заносятся acl, разрешающие доступ всех пользователей к SQUID. Ограничение доступа пользователей организовано средствами редиректора.
Этот редиректор описан в документации на SQUID. Написан на perl. Редиректор создаётся после подачи команды на реконфигурирование SQUID на основе списков перенаправления запросов. Быстрый и лёгкий редиректор, но не различает пользователей.
Ограничение максимальной скорости соединения
Ограничение максимальной скорости получения пользователем (пользователями) в squid реализовано с помощью механизма англ. (дословно — «пулы задержки»). Механизм ограничения скорости работает по принципу бассейна (откуда и название pool (бассейн)), в который «втекает» и «вытекает» информация. Отдельные конфигурируемые подобным образом области памяти называются англ. (ведро). У ведра есть параметры: «ёмкость», «скорость наполнения». Если пользователь (пользователи) получают информацию на скорости ниже, чем «скорость наполнения», то ведро всегда полно. Если пользователь кратковременно поднимает скорость получения информации выше скорости наполнения, то до момента, пока ведро не пусто, он не ограничивается по скорости, как только ведро становится пустым, клиент получает информацию со скоростью наполнения ведра. В случае наличия групповых и индивидуальных вёдер они включаются последовательно.
Для каждого ведра указываются два параметра: ёмкость и скорость наполнения. −1 означает «без ограничения».
Попадание пользователей в то или иное ведро определяется списками доступа к вёдрам, они просматриваются в порядке упоминания в файле конфигурации до первого совпадения. Пользователи, не попадающие ни в одно из вёдер, в скорости не ограничиваются.
Одной из особенностей squid является возможность работать в режиме обратного прокси (reverse proxy), также известного как «ускоритель» («HTTP accelerator»). В этом случае вместо кэширования запросов нескольких пользователей к множеству сайтов кешируются запросы множества пользователей к нескольким сайтам. В этом режиме принятый запрос проверяется на «динамичность» (нужно ли каждый раз обрабатывать запрос с нуля) и «возраст» (актуальны ли ещё данные). Если данные ещё актуальны и не поменялись, то запрос не передаётся серверу, а отдаётся из кеша squid’а. Таким образом существенно снижается нагрузка на серверы (например, в Википедии запросы к страницам кешируются, так как от просмотра их содержимое не меняется, при этом нагрузка на серверы существенно меньше — обработка запроса к кешу много проще, чем обработка запроса к базе данных SQL, обработка вики-разметки и формирование веб-страницы).
Кроме того, «обратный прокси» способен распределять запросы между несколькими серверами, балансируя нагрузку и/или обеспечивая отказоустойчивость, то есть фактически предоставляет функциональность, аналогичную кластеру.
Режим прозрачного прокси-сервера
В сочетании с некоторыми межсетевыми экранами и маршрутизаторами squid может работать в режиме прозрачного прокси (англ. ). В этом режиме маршрутизатор вместо того, чтобы сразу пересылать HTTP-запросы пользователя HTTP-серверу в Интернете, перенаправляет их прокси-серверу, который может работать как на отдельном хосте, так и на самом маршрутизаторе. Прокси-сервер обрабатывает запрос (с возможной отдачей содержимого из кеша), это содержимое направляется к запросившему пользователю, для которого оно выглядит как «ответ» сервера, к которому адресовался запрос. Таким образом, пользователь может даже не знать, что все запросы и ответы прошли через прокси-сервер.
При таком подходе проксирования аутентификация не предусмотрена, так как прозрачность проксирования это и подразумевает.
