Ранее мы рассматривали процедуру пересборки пакета Squid 3.3 из исходных файлов для отключения поддержки IPv6. Желание внедрить собственную систему сборки логов Squid подталкивает нас на новую задачу – обновление используемого пакета Squid 3.3.8 до последней стабильной версии 3.4.8, доступной на официальном сайте. Делать это будем на сервере c Ubuntu Server 14.04.1 LTS с уже установленным и работающим Squid 3.3.8.
Обновляем список пакетов и устанавливаем пакеты, необходимые для сборки squid3:
sudo apt-get update sudo apt-get build-dep squid3 sudo apt-get install quilt
Загружаем исходные файлы пакета в текущий каталог (по умолчанию используем домашний каталог пользователя):
apt-get source squid3
Проверяем то, что исходные файлы загружены и распакованы в текущем каталоге в подкаталог ~/squid3-3.3.8:
ls -l total 2984 drwxr-xr-x 20 petya domain users 4096 Sep 24 13:50 squid3-3.3.8 -rw-r--r-- 1 petya domain users 52699 Aug 28 07:38 squid3_3.3.8-1ubuntu6.1.debian.tar.gz -rw-r--r-- 1 petya domain users 2351 Aug 28 07:38 squid3_3.3.8-1ubuntu6.1.dsc -rw-r--r-- 1 petya domain users 2992708 Aug 14 2013 squid3_3.3.8.orig.tar.bz2
Скачиваем архив Squid 3.4.8 с официального сайта:
wget http://www.squid-cache.org/Versions/v3/3.4/squid-3.4.8.tar.bz2
Переходим в каталог со старыми исходными файлами и выполняем их обновление из загруженного архива новыми исходными файлами:
cd squid3-3.3.8 uupdate -v 3.4.8 ../squid-3.4.8.tar.bz2 New Release will be 3.4.8-0ubuntu1. Symlinking to pristine source from squid3_3.4.8.orig.tar.bz2... -- Untarring the new sourcecode archive ../squid-3.4.8.tar.bz2 Unpacking the debian/ directory from version 3.3.8-1ubuntu6.1 worked fine. Remember: Your current directory is the OLD sourcearchive! Do a "cd ../squid3-3.4.8" to see the new package
Переходим в каталог с обновлёнными исходными файлами:
cd ../squid3-3.4.8
Работа с патчами от старого пакета. Экспортируем путь к каталогу с патчами для quilt:
export QUILT_PATCHES=debian/patches
Удаляем из списка патчей, те которые не могут быть применены к новым исходным файлам
quilt delete fix-pod2man-config.test quilt delete CVE-2014-3609 quilt delete fix-distribution
Применяем к обновлённым исходным файлам оставшиеся патчи:
while quilt push; do quilt refresh; done
Просматриваем вывод команды и убеждаемся что нет явных ошибок наложения патчей.
Фиксируем изменения в changelog пакета
dch --release ""
При необходимости вносим изменения в в файл ~/squid3-3.4.8/debian/rules (параметры с которыми будет собран squid 3.4.8), по аналогии с тем, как это было описано ранее в заметке Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 10. Отключаем IPv6. Не забываем, на всякий случай, перед редактированием сохранить исходный файл:
cp ~/squid3-3.4.8/debian/rules ~/squid3-3.4.8/debian/rules.default sudo nano -Y sh ~/squid3-3.4.8/debian/rules
Запускаем процесс сборки бинарных файлов новой версии пакетов squid.
cd ~/squid3-3.4.8/ debuild
Операция займёт продолжительное время и после её завершения в каталоге верхнего уровня (в нашем примере это домашний каталог пользователя) появятся deb-пакеты:
ls -l ~/ | grep .deb$ -rw-r--r-- 1 petya domain users 2045506 Sep 24 15:47 squid3_3.4.8-0ubuntu1_amd64.deb -rw-r--r-- 1 petya domain users 107248 Sep 24 15:48 squid_3.4.8-0ubuntu1_amd64.deb -rw-r--r-- 1 petya domain users 259664 Sep 24 15:47 squid3-common_3.4.8-0ubuntu1_all.deb -rw-r--r-- 1 petya domain users 9438338 Sep 24 15:48 squid3-dbg_3.4.8-0ubuntu1_amd64.deb -rw-r--r-- 1 petya domain users 132364 Sep 24 15:48 squid-cgi_3.4.8-0ubuntu1_amd64.deb -rw-r--r-- 1 petya domain users 129684 Sep 24 15:48 squidclient_3.4.8-0ubuntu1_amd64.deb -rw-r--r-- 1 petya domain users 123596 Sep 24 15:48 squid-purge_3.4.8-0ubuntu1_amd64.deb
Смотрим какие пакеты Squid3 старой версии были установлены в системе:
dpkg -l | grep squid3 hi squid3 3.3.8-1ubuntu6 amd64 Full featured Web Proxy cache (HTTP proxy) hi squid3-common 3.3.8-1ubuntu6 all Full featured Web Proxy cache (HTTP proxy) - common files
Устанавливаем новые версии этих же пакетов собранных пакетов:
cd ~/
sudo dpkg -i squid3-common_3.4.8-0ubuntu1_all.deb squid3_3.4.8-0ubuntu1_amd64.deb
(Reading database ... 156614 files and directories currently installed.)
Preparing to unpack squid3-common_3.4.8-0ubuntu1_all.deb ...
Unpacking squid3-common (3.4.8-0ubuntu1) over (3.4.8-0ubuntu1) ...
Preparing to unpack squid3_3.4.8-0ubuntu1_amd64.deb ...
Unpacking squid3 (3.4.8-0ubuntu1) over (3.4.8-0ubuntu1) ...
Setting up squid3-common (3.4.8-0ubuntu1) ...
Setting up squid3 (3.4.8-0ubuntu1) ...
Configuration file '/etc/squid3/squid.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** squid.conf (Y/I/N/O/D/Z) [default=N] ? N
squid3 start/running, process 40531
Skipping profile in /etc/apparmor.d/disable: usr.sbin.squid3
Processing triggers for ureadahead (0.100.0-16) ...
ureadahead will be reprofiled on next reboot
Processing triggers for ufw (0.34~rc-0ubuntu2) ...
Processing triggers for man-db (2.6.7.1-1) ...
По ходу выполнения нам будет задан вопрос о том, как поступить с конфигурационным файлом. Выбираем “N”, чтобы оставить настроенный нами ранее основной конфигурационный файл squid.conf от предыдущей версии Squid.
В процессе установки службы Squid будут перезапущены и приступят к работе уже в виде новой версии. Посмотрим ещё раз версию установленных пакетов:
dpkg -l | grep squid3 ii squid3 3.4.8-0ubuntu1 amd64 Full featured Web Proxy cache (HTTP proxy) ii squid3-common 3.4.8-0ubuntu1 all Full featured Web Proxy cache (HTTP proxy) - common files
Готово.
PS: Отдельное Спасибо Владимиру Леттиеву (aka crux) за предоставленную пошаговую инструкцию.
Update 29.09.2014
При эксплуатации Squid 3.4.8 под хорошей нагрузкой выяснилось, что в новой версии есть серьёзные проблемы с потреблении ресурсов хелперами. Попросту говоря возможны ситуации 100% нагрузки на процессор, в результате чего прокси перестаёт отвечать клиентам. По этой причине использовать данную версию в продуктивной среде я бы не рекомендовал.
RSS - Записи
Под хорошей нагрузкой, это насколько хорошей? Я как раз таки используя Ваши статьи ставил 3.4.8, в сети у меня порядка 250 пользователей. Хотел бы знать какая у Вас нагрузка что вы сделали такое вывод касательно производительности. Спасибо
Больше сотни одновременных подключений с попыткой аутентификации и авторизации (клиенты ломанулись на прокси с утра). Основной процесс squid при этом тут же сожрал все процессорные ресурсы системы. Сразу стало очевидно, что хелпер ext_ldap_group_acl в новой версии под такой нагрузкой ведёт себя несколько иначе и пришлось добавлять ему параметры описывающие количество холостых процессов при запуске и максимально возможное количество процессов, чего по дефолту не требовалось в предыдущей версии squid. После перезапуска нагрузка Squid на CPU несколько упала, но спустя какое-то время снова выросла и по логам стало понятно, что есть проблемы с negotiate_wrapper_auth / negotiate_kerberos_auth. В общем весёлый утренний кавардак в конечном итоге закончился откатом виртуальных машин на состояние до обновления. После отката, как и ожидалось, ситуация нормализовалась. Наш местный эксперт по Linux покурил тему и пришёл к выводу, что в новой версии Squid управление хелперами изменилось, и пожалуй не в лучшую для нас сторону. Вот и получилось, что хотели поднять версию, чтобы использовать обновлённый функционал отправки access.log во внешний источник, а "отгребли" в итоге совсем в другом месте. Но так как инструкция по обновлению к этому моменту уже была написана и дважды проверена, было решено всё-таки её опубликовать, хотя бы в качестве примера обновления Squid из исходников.
Спасибо за столь развернутый ответ, у меня стоит авторизация черезе kerberos (при подключении второго способа авторизации kerberos почему-то отказывается отрабатывать, все время используется авторизация basic) и по статистике мониторинга видно постоянно большая нагрузка на ЦП притом что squid с авторизацией использует всего 8 человек. Надо попробовать поставить 3.3.13 и посмотреть на результаты. Кстати как сама скорость работы squid. у меня впечатление что 3.4 довольно медленно отдает инет, вечером буду пробовать ставить 3.3. Еще раз спасибо.
Эта проблема известна разработчикам и прогресс в её решении можно отслеживать здесь http://bugs.squid-cache.org/show_bug.cgi?id=3997
Поставил в production серверс настройками из этой статьи, с небольшими отличиями - squid запущен в SMP режиме (10 workers) - "из коробки" squid в SMP не заработает, нужно внести исправления в файл /etc/init/squid3.conf:
1. Перед строкой
respawn
вставить строку
expect fork
2. После строки
pre-start script
добавить пару строк:
mkdir -p -m0755 /var/run/squid3
chown proxy:proxy /var/run/squid3
3. В строке
exec /usr/sbin/squid3 $SQUID_ARGS -N -f $CONFIG
убрать ключ -N:
exec /usr/sbin/squid3 $SQUID_ARGS -f $CONFIG
В squid.conf добавлены строки:
workers 10
cpu_affinity_map process_numbers=1,2,3,4,5,6,7,8,9,10 cores=1,2,3,4,5,6,7,8,9,10
По аутентификации: при использовании Кerberos загрузка процессоров повышается очень серьезно: load average в top с использованием Kerberos подпрыгивает до 5-6, при откате на NTLM падает до 1-2.
Виртуалка сконфигурирована с 10 ядрами, 8 гигов оперативки статикой, аутентифицирующихся пользователей (Kerberos/NTLM) около 800, всего пользовалей около 2000, нагрузка в пике около 500 запросов/сек.
В результате оставили следующую работающую схему аутентификации не грузящую процессоры:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 200 startup=40 idle=10
auth_param ntlm keep_alive off
auth_param basic program /usr/bin/ntlm_auth -d --helper-protocol=squid-2.5-basic
auth_param ntlm children 40 startup=5 idle=5
auth_param basic realm SU155.RU
auth_param basic credentialsttl 4 hours
auth_param basic casesensitive off
Интересная информация. В предыдущем комментарии В.Леттиева есть ссылка на описание проблемы на Squid Bugzilla (Bug 3997) и там в комментах есть информация о том, что увеличение количества workers не влияет положительно на проблему загрузки. С другой стороны полностью отказываться от Kerberos как-то обидно.
Да, я видел описание этого бага, в общем, чтобы проверить так или нет как раз Kerberos и настроил, спасибо Алекей за подробное руководство. А количество workers выбрано без связи с аутентификаторами, а чтобы раскидать нагрузку по ядрам и остался небольшой запас - в пике загрузка (load average) подскакивает 8-9 по top, соответственно, выбрана 10 ядерная конфигурация - небольшой запасец есть. И все шевелится весьма и весьма шустро. Версия из портов тормозила - аналогичные конфиги, ставишь/запускаешь - открываешь Яндекс карты - и загрузка кусками, с тормозами. 3.4.9 шустро. Проверял на Centos/Ubuntu - разницы нет.
Насчет Kerberos согласен, но уж больно разительная загрузка по процам - на Kerberos и на NTLN - c NTLM в тор (по загрузке проца) хелперы где-то внизу (на рабочей нагрузке 300 запросов/сек), вверху сквиды, как обычно стройненько. А с Kerberos - вверху один/два сквида, вперемешку с хелперами, которые, частенько что и на первое место вылезают. Рисковать не стал до пика - Kerberos заремил и откатил на NTLM, тем более, что баг известный - поправят, проверим :) Тем более, что прокси, имхо, самый используемый сервер в конторе, судя по загрузке ))
Дальше в планах организовать кластер.
Я тоже хочу кластер, но руки пока не добрались :)
О, Алексей, ваш кластер будет намного полезней - ведь с ним появится новый мануал! Пожалуй, это будет самое полное и точное руководство по использованию Squid.
Прошу прощения, что поздно вклинился в обсуждение. А как после этих хаков работает service restart/reload?
Так же как работал или не работал )) Если память мне не изменяет, в ubuntu касательно squid в /etc/init.d ничего не предвиделось. А через upstart все работает
sudo stop squid3
sudo start squid3
В инструкции есть такой пункт:
"Удаляем из списка патчей, те которые не могут быть применены к новым исходным файлам"
А как понять список патчей, которые не могут быть применены?
Беру исходники другой версии, не 3.4.8, и всё, инструкция теряет свою полезность.
Прошу, раскройте алгоритм, по которому можно понять, какие патчи не могут быть применены?
Универсальной инструкции нет. Как тут уже написали, надо проверять патч на применимость с помощью команды
quilt push
Поправить патч под новую версию, в принципе, не сложно, так как формат патча текстовый. Можно создать копию исправляемого файла, внести руками изменения по образцу существующего патча, и потом сгенерировать новый патч с помощью команды
diff -u старый_файл новый_файл > патч
Но если изменения нетривиальные, или вобще невозможно найти место, которое исправлялось, то тут уже интуиция не поможет, нужно разбираться в исходном коде.
Как только выйдет исправленая версия, можно будет обновить инструкцию и приложить архив с содержимым каталога debian, чтобы избежать заморочек с патчами.
Сложного с патчами нет ничего - таки, я предпочитаю генерить новые не с помощью diff а с помощью quilt, но не суть. А логику я предпочитаю такую - если патч правил конфиги, пути и прочее - можно взяться и поправить, сложного ничего нет. А вот если правились исходники - лично я пас )) и такой патч безопасней удалить (при возникновении косяков).
Для проверки применяйте патчи по одному:
quilt push
Если патч накатился нормально, выполните refresh:
quilt refresh
Продолжайте дальше.
Если патч вылетает с ошибкой - можно поправить патч или удалить его.
Собственно, все.
http://packaging.ubuntu.com/ru/html/patches-to-packages.html
(Только с поправкой на нашу реальность, bzr мы здесь не используем).
У меня сейчас на 3.5.1
удалены вот такие патчи:
quilt delete fix-pod2man-config.test
quilt delete CVE-2014-3609
quilt delete fix-distribution
quilt delete fix-icmp-pinger-icmp4-6.patch
Следующие, если поправить руками, можно использовать
01-cf.data.debian.patch
02-makefile-defaults.patch
15-cachemgr-default-config.patch
Если не исправлять - работать не будут, сами увидите, на некоторых hunk обломятся.
> У меня сейчас на 3.5.1
Squid 3.5.1 при сборке хочет версию libecap >= 1.0, < 1.1
В Ubuntu 14.10 сейчас есть только версия 0.2, поэтому наверно придётся отключать ecap.
Я собирал для теста 3.4.11 вместе с патчем исправлющим баг #3997. Но наверно лучше дождаться 3.4.12, чтобы туда включили это исправление и не пришлось бы танцевать с патчами.
Пересобрать ecap - по той же схеме, что и squid, дел на 5 минут.
Можно скриптом (только поправить сборочные директории)
#!/bin/bash
sudo rm -rf /home/user1/libecap*
sudo apt-get -y build-dep libecap
cd /home/user1/
sudo apt-get -y source libecap
until test -f libecap-1.0.0.tar.gz
do
wget http://www.measurement-factory.com/tmp/ecap/libecap-1.0.0.tar.gz
done
cd /home/user1/libecap-0.2.0/
uupdate -v 1.0.0 ../libecap-1.0.0.tar.gz
cd /home/user1/libecap-1.0.0/
dch --release ""
debuild -us -uc
cd /home/user1/
sudo dpkg -i libecap2_1.0.0-0ubuntu1_amd64.deb libecap2-dev_1.0.0-0ubuntu1_amd64.deb
Но там еще кой-чего придется поправить в дебианизации и ключах сборки, иначе пакет с 3.5.1 не соберется
Баг #3997 исправлен в патче squid-3.4-13210.patch, текущий релиз squid-3.4.11-20150124-r13214, не надо ждать - берите и ставьте.
расскажите как до 5,2 обновится, пакет не хочет собираться не в какую =//
Пожалуйста.
Обратная ссылка: Обновляем Squid 3.3.8 до версии 3.5.3 из исходных файлов на Ubuntu Server 14.04.2 LTS | Блог IT-KB /
Обратная ссылка: Снижение нагрузки на процессорные ресурсы при использовании хелпера Kerberos-аутентификации (negotiate_kerberos_auth) для прокси-сервера Squid 3 | Блог IT-KB /
Любопытно, а на текущий момент, спустя три года, изменилось ли что-то? Т.е. рекомендовали бы Вы сейчас переходить на доступную сегодня крайнюю версию Сквида - 3.5.27?