В этой заметке будет рассмотрена процедура обновления Squid 3.3.8 до последней стабильной версии 3.5.3, которая будет несколько отличаться от описанной ранее процедуры, за счёт того, что в последней версии возникает дополнительная потребность обновления библиотек libecap. Обновление будет выполняться на сервере c Ubuntu Server 14.04.2 LTS с уже установленным и работающим Squid 3.3.8. Поехали…
Подготовка
Обновляем список пакетов и устанавливаем пакеты, необходимые для сборки squid3, если ещё они не были установлены:
sudo apt-get update sudo apt-get build-dep squid3 sudo apt-get install quilt
Sqiud ветки 3.5.x требует для своей работы новую версию библиотеки libecap 1.0.0, поэтому перед сборкой Squid потребуется собрать новую версию этой библиотеки для Ubuntu.
Установка сборочных зависимостей libecap
sudo apt-get build-dep libecap
Создаем в домашнем каталоге текущего пользователя рабочую папку для последующих манипуляций и переходим в неё:
mkdir ~/squid3-build cd ~/squid3-build
Обновление библиотек libecap
Скачиваем и разворачиваем исходные файлы libecap в текущем каталоге
apt-get source libecap
Скачиваем последнюю версию libecap
wget http://www.measurement-factory.com/tmp/ecap/libecap-1.0.0.tar.gz
Обновляем исходные файлы старой версии libecap
cd libecap-0.2.0 uupdate -v 1.0.0 ../libecap-1.0.0.tar.gz
Переходим в каталог с новыми исходными файлами
cd ../libecap-1.0.0
Тут есть небольшой сюрприз. В Debian есть такое правило как shared lib policy. У библиотек поддерживается версионирование имени, т.е. если имя файла библиотеки libecap.so.2.0.0, то и пакет называется libecap2 (хотя версия 0.2.0). У версии 1.0.0 сонейм уже будет называться libecap.so.3.0.0. Это означает, что нельзя оставлять имя пакета libecap2, т.к. при обновлении программа зависящая от libecap.so.2.0.0 окажется сломанной.
Поэтому в файле ~/squid3-build/libecap-1.0.0/debian/control мы переименуем пакет в libecap3, что позволит сохранить параллельно libecap2 и libecap3 в системе.
sed -i 's/libecap2/libecap3/' debian/control
Удалим ненужный уже файл с данными о символах в libecap2
rm -f debian/libecap2.symbols
Переименуем все файлы ~/squid3-build/libecap-1.0.0/debian/libecap2* с заменой 2 на 3
rename 's/2/3/' debian/libecap2*
Фиксируем изменения в changelog пакета
dch --release ""
Собираем пакет
debuild -us -uc
Удаляем конфликтующий пакет libecap2-dev, используемый для сборки старого Squid
sudo apt-get remove libecap2-dev
Устанавливаем новую библиотеку и пакет с заголовочными файлами
cd .. sudo dpkg -i libecap3_1.0.0-0ubuntu1_amd64.deb libecap3-dev_1.0.0-0ubuntu1_amd64.deb
Сборка Squid 3.5.3
Скачиваем и разворачиваем исходные коды пакета в текущий каталог
apt-get source squid3
Скачиваем новый тарбол Squid с официального сайта
wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.3.tar.gz
Переходим в каталог со старыми исходными файлами и выполняем их обновление из загруженного архива новыми исходными файлами:
cd squid3-3.3.8 uupdate -v 3.5.3 ../squid-3.5.3.tar.gz
Переходим в каталог с обновлёнными исходниками
cd ../squid3-3.5.3
<
p align="center">***
Приступаем к работе с патчами от старого пакета. Экспортируем путь к каталогу с патчами для quilt
export QUILT_PATCHES=debian/patches
Удаляем из списка патчей, те которые не могут быть применены к новым исходникам
quilt delete fix-pod2man-config.test quilt delete CVE-2014-3609 quilt delete fix-distribution quilt delete fix-icmp-pinger-icmp4-6.patch
Следующие патчи в каталоге ~/squid3-build/squid3-3.5.3/debian/patches потребуется немного подправить:
01-cf.data.debian.patch
02-makefile-defaults.patch
15-cachemgr-default-config.patch
Это нужно для того, чтобы они легли чисто на новую версию, они небольшие и находятся во вложении. Их можно просто заменить (каталог debian/patches). Кстати, если файлы необходимо скопировать на прокси-сервер с Windows-системы, это можно сделать, например, с помощью утилиты pscp:
C:\Tools\PuTTy\pscp "D:\DOWNLOADS\squid-3.3.8-update-to-3.5.3-debian-patches\fixed\01-cf.data.debian.patch" linux-user@linux-server:/home/linux-user/squid3-build/squid3-3.5.3/debian/patches/01-cf.data.debian.patch
Применяем и переформатируем оставшиеся патчи (текущий каталог ~/squid3-build/squid3-3.5.3)
while quilt push; do quilt refresh; done
Подправим в control-файле зависимость libecap2 на libecap3
sed -i 's/libecap2-dev/libecap3-dev/' debian/control
<
p align="center">***
В правилах сборки удалим хелперы MSNT и MSNT-multi-domain, т.к. они давно устарели и больше не поддерживаются в Squid 3.5.x
sed -i 's/MSNT,MSNT-multi-domain,//' debian/rules
Соответственно и файл конфигурации этих хелперов больше не нужен
sed -i '/msntauth.conf/d' debian/squid3.install
<
p align="center">***
Собираем новый пакет:
debuild -us -uc
Устанавливаем собранные пакеты:
cd .. sudo dpkg -i squid3_3.5.3-0ubuntu1_amd64.deb squid3-common_3.5.3-0ubuntu1_all.deb
По ходу выполнения нам будет задан вопрос о том, как поступить с конфигурационными файлами squid.conf и errorpage.css. Выбираем “N”, чтобы оставить настроенные нами ранее файлы от предыдущей версии Squid.
В процессе установки службы Squid будут перезапущены и приступят к работе уже в виде новой версии. Посмотрим ещё раз версию установленных пакетов:
dpkg -l | grep squid3 ii squid3 3.5.3-0ubuntu1 amd64 Full featured Web Proxy cache (HTTP proxy) ii squid3-common 3.5.3-0ubuntu1 all Full featured Web Proxy cache (HTTP proxy) - common files
Теперь остается только удалить временный каталог со всеми вложенными в него файлами (готовые deb-пакеты на всякий случай можно сохранить в отдельный каталог):
mkdir ~/deb-packages cp ~/squid3-build/*.deb ~/deb-packages cd ~/ rm -rf ~/squid3-build
На этом процедуру обновления Squid 3.3.8 до версии 3.5.3 можно считать завершённой.
<
p align="center">***
Пошаговая инструкция и откорректированные файлы патчей предоставлены Владимиром Леттиевым (aka crux), за что ему “наше с кисточкой”.
RSS - Записи
Обратная ссылка: Снижение нагрузки на процессорные ресурсы при использовании хелпера Kerberos-аутентификации (negotiate_kerberos_auth) для прокси-сервера Squid 3 | Блог IT-KB /
При использовании еще 3.5.1 столкнулся с багом 4190 (в текущей версии 3.5.4 еще не исправлен) -
http://bugs.squid-cache.org/show_bug.cgi?id=4190 (Через некоторое время работы - примерно, около часа - начинают перезапускаться воркеры, через некоторое время перезапуститься не удается и они отваливаются).
Мне помог откат патча http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13751.patch
Пользователей около 800 полет нормальный, типичная нагрузка от 300 до 500 запросов в сек.
В чем суть патчей ? они специфичны для Debian или общие? Squid скомпилированный без этих патчей в чем отличается от пропатченного ? Спасибо
Патчи, размещающиеся в debian/patches специфичны для debian, патч о котором упоминал я (http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13751.patch) общий для дистрибутива squid. Суть - те или иные исправления. Некоторые, типа упомянутых здесь 01, 02, 15 (кстати, у меня в числе исправленных числится и 99) скорректировать несложно - достаточно взять патч, найти в новой версии файла куда сместились исправляемые строки, внести коррективы вручную и сгенерировать новый diff файл, а вот патчи исходников требуют понимания исходника - тут сложнее. Я поступаю так - после выхода новой версии компилирую и проверяю на ошибки - если начинаются ошибки - откатываю патчи дистриба до исчезновения ошибки, потом компилю последний дистриб без этого патча - и, если ошибок нет - отписываюсь в багзиллу о появлении таких-то ошибок после такого-то патча. Если ситуация тривиальна - разработчики довольно быстро все правят - если нет (как с патчем 13751/багом 4190) - ситуация зависает, но откат патча позволяет иметь стабильную работу.
Патчи специфичны для debian/ubuntu, изменяют некоторые значения по умолчанию в конфигурации, пути к некоторым каталогам. Если собирает под другой дистрибутив, то эти патчи не нужны.
Под другим дистрибом, например, Centos тоже будут свои патчи (если пересобирать rpm) - но там используется не quilt, а просто patch - суть та же.
Последний вопрос остался без ответа )) - squid без патчей отличается тем, что в нем нет исправлений, сделанных в этих патчах. Это может быть функционал, доки и пути/дистрибьюция. Что-то критично, что-то нет - тут каждый решает сам. Например без исправлений в доках у вас все прекрасно скомпилится и заработает. Ошибки в путях придется править руками при запуске, функционал - если не используете, то без разницы, но могут возникнуть проблемы со следующими версиями. В апстриме (текущей версии на сайте) именно функциональные патчи приводят к удалению старых/возникновению новых ошибок. Иногда еще продвинутые пользователи предлагают свои патчи (которые по разным причинам не включают в апстрим). Для экспериментов с патчами самый простой способ - написать скрипт для компиляции сквида (на основании всех статей отсюда) и дальше экспериментировать.
А какая авторизация используется у Вас при таком количестве пользователей ? У меня 3.5.3 при 200 пользователях загибается при kerberos авторизации по процессорному времени. KRB5RCACHETYPE еще пока не трогал, протестирую насколько сильно он снижает нагрузку. И еще у Вас один прокси на 800 пользователей или несколько ? И какая конфигурация сервера на такое кол-во пользователей. Спасибо.
Kerberos, где невозможно Kerberos - NTLM, Basic. Пока один виртуальный сервер (в планах двух-узловой кластер) на Hyper-V (8-ядер, 6GB ОЗУ, отдельный VHD - 10GB под кэш)
Спасибо, у меня на 200 пользователей 4 ядро 3Gb оперативки, но вот Kerberos давал нагрузку, все же надо попробовать отключить replay-кеш и посмотреть хватит ли таких ресурсов виртуалки на такое кол-во пользователей при Kerberos авторизации. Спасибо еще раз.
NTLM, Basic
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 200 startup=40 idle=5
auth_param ntlm keep_alive off
auth_param basic program /usr/bin/ntlm_auth --diagnostics -d --helper-protocol=squid-2.5-basic
auth_param ntlm children 40 startup=3 idle=2
auth_param basic realm SU155.RU
auth_param basic credentialsttl 4 hours
auth_param basic casesensitive off
Прокси один, виртуалка, 8 ядер, 16 гигов (думаю, можно ужать до 4 ядер 8 гигов спокойно - за последний год аппетиты у squid изрядно уменьшились)
workers 4
cpu_affinity_map process_numbers=1,2,3,4 cores=1,2,3,4
cache_mem 4096 MB
maximum_object_size_in_memory 2048 KB
memory_replacement_policy heap GDSF
Дискового кеша нет, используется только кеш в оперативной памяти.
Обновился до 3.5.4 из-за того что на 3.4.11 кушались все ресурсы. Исправили в 3.4.12 и .3.5.4 как я понял.
После перезапуска сквида получаю ошибку, но прокси работает. Что это?
2015/05/04 20:04:21| ERROR: Directive 'hierarchy_stoplist' is obsolete.
2015/05/04 20:04:21| ERROR: Directive 'chunked_request_body_max_size' is obsolete.
Они устарели я так понял. Убрал их. Подскажите лучше как верно настроить прокси, а именно кеш. У меня сервер с 5 гигами памяти и маленьким диском. Кеш настроил но что то кажется ч намудрил.
log при запуске http://pastebin.com/8HAha9AX
Для использования uupdate нужно установить данный пакет devscripts, а то иначе бубунта будет говорить, что не знает такой команды как uupdate
Установил 3.5.4 и тоже наблюдаю "самоотвал" squid parent с signal 6. с лагом примерно в час. Кроме того, раз в сутки прокси-сервер перестаёт работать вообще, вылетая уже с signal 7 раз в минуту и в итоге сообщая мне, что "will not be restarted due to repeated, frequent failures". Баг наблюдал и в версии 3.5.3. Из отличий от типичной конфигурации разве что наличие хелпера подсчёта квоты пользователя, но он совсем простенький и там затыка быть не может, да использование ufdbGuard вместо SquidGuard.
Создал багрепорт http://bugs.squid-cache.org/show_bug.cgi?id=4249
Порывшись в сквидовой багзилле, обнаружил, что некий доброволец запилил патч, решающий проблему с signal 6. Прямая ссылка: http://bugs.squid-cache.org/attachment.cgi?id=3133
Добрый мэйнтейнеры не включили этот патч в основную ветку, сославшись на то, что хак, применённый в патче, приводит к возможности утечки памяти. На справедливое замечание патчера о том, что лучше стабильный сквид, _возможно_ подверженный утечке памяти, чем "железно" нестабильный во всей ветке 3.5.x, ему гордо ответили молчанием.
Хочу добавить, что патч энтузиаста действительно помог избавиться от signal 6, благо изменений там не много и легко можно применить их руками перед компиляцией последней сборки 3.5.4. Что касается signal 7 — пока не проявлялось, слежу дальше.
Если при компиляции сквида после применения патча будет выпать ошибка — скорее всего, это связано с тем, что в новых версиях компилятора gcc по-умолчанию включён флаг -Wshadow. Мне помогло исключение куска кода, на который он ругается, из проверки компилятором.
Увы, signal 7 никуда не пропал. Всё так же проявляется спонтанно стабильно раз в сутки и лечится только полной перезагрузкой виртуальной машины. Судя по отсутствию даже намёков на подобные проблемы у других людей, делаю предположение, что проблема связана с виртуализацией вообще и с VmWare в частности.
Здесь http://bugs.squid-cache.org/show_bug.cgi?id=4249 говорят о том, что squid можно пересобрать с опцией --disable-march-native. Не пробовали это?
Это тема, которую я и создал. Squid уже скомпилирован с этой опцией. Пока попробовал поотключать разные "улучшайзеры" в vCenter для этой виртуальной машины, сутки пошли. Следующий шаг — откат на 3.3.8.
А почему именно на 3.3.8, а не на последнюю версию в ветке 3.4 (3.4.13)? Мы у себя тоже заметили наличие проблемы с перезапуском каждые 2 часа ("killed by ABRT signal"). Сейчас думаем что делать дальше.
Потому что в версии 3.4.13 проблема с signal 6 также не решена, судя по багзилле. Вообще, как заметили выше, баг с signal 6 появляется после конкретного патча, а он, насколько я понял, применяется сразу на две ветки. На 3.3.8 хочу откатиться, потому что, судя по всему, у вас с ней проблем в виртуализованной среде не наблюдается. Старовата она, конечно, но стабильность дороже.
Отключения "улучшайзеров" не помогли. Ещё есть небольшая вероятность, что проблема в ядре (ядро нестандартное, скомпилированное под "своё" железо). Попробую раскатать свеженький Debian 8 со стандартным ядром и развернуть Squid там, прежде чем даунгрейдиться.
Халтурят разработчики, в 2011 году поднимал подобную связку на Squid 3.1 + FreeBSD, работало как часы.
Итак, пересбор последний версии Squid 3.5.4 (и правка "ручками" исходников для решения проблемы с signal 6) на свежем Debian 8.0 "Jessie" со стандартым ядром мою проблему решил. Что ж, видимо, проблема всё-таки была в кастомном ядре.
Итак, в конечном итоге мы откатились на 3.3.14. Уже несколько дней работает без падений. Правда с этой версией возник ещё один нюанс - в squid.conf не воспринимаются комментарии написанные в конце строки с некоторыми директивами, например http_access...пришлось такие комментарии перенести в отдельные строки :)
В общем ждём исправления бага с «killed by ABRT signal» и снова будем смотреть в сторону обновления.
Последняя использованная нами версия 3.5 линейки 3.5.10-20151001-r13933 у нас работала стабильно, без перезагрузок, отвалов и пр. То есть сервак перезагружался только при обновлении ядра.
Обратная ссылка: Разворачиваем локальный apt-репозиторий пакетов на Ubuntu Server 14.04 LTS | Блог IT-KB /
В принципе, можно уже начинать тестировать/переползать на 4 версию squid. Для компиляции придется поправить патчи
01-cf.data.debian.patch (не обязательно, можно заремить - там правится дистрибутивный squid.conf)
15-cachemgr-default-config.patch (править обязательно, иначе не соберется пакет)
Ну и debian/rules тоже слегка придется подправить.
Патч fix-caching-vary-header.patch надо удалить.
Если имя исполняемого файла оставить squid3 (версия у вас будет только типа 4.0.1-20151025-r14365 )) ) - тогда больше никуда изменения вносить не надо, все компилится, ставится и работает.
Если будут нужны интересны перечисленные патченные файлы - могу выложить.
Застрял на этом этапе. ЧТо там конкретно корректировать?
Следующие патчи в каталоге ~/squid3-build/squid3-3.5.3/debian/patches потребуется немного подправить:
01-cf.data.debian.patch
02-makefile-defaults.patch
15-cachemgr-default-config.patc?
Потому как при попытке собрать пакет пишет следующее:
# nothing to do
dpkg-source -b squid3-3.5.3
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building squid3 using existing ./squid3_3.5.3.orig.tar.gz
patching file src/cf.data.pre
Hunk #1 FAILED at 327.
Hunk #2 FAILED at 400.
Hunk #3 FAILED at 477.
Hunk #4 FAILED at 518.
Hunk #5 succeeded at 1143 (offset 134 lines).
Hunk #6 succeeded at 1396 (offset 202 lines).
Hunk #7 succeeded at 4410 (offset 521 lines).
Hunk #8 FAILED at 3908.
Hunk #9 succeeded at 8773 (offset 791 lines).
5 out of 9 hunks FAILED
dpkg-source: info: fuzz is not allowed when applying patches
dpkg-source: info: if patch '01-cf.data.debian.patch' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/01-cf.data.debian.patch/ --reject-file=- < squid3-3.5.3.orig.G1g93O/debian/patches/01-cf.data.debian.patch gave error exit status 1
dpkg-buildpackage: error: dpkg-source -b squid3-3.5.3 gave error exit status 2
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc failed
Ссылка на уже отредактированные файлы патчей в статье.
Здравствуйте Алексей,
Squid 3.3.8, при 60 пользователей проц. играет в пределах 50-90% иногда подскакивает и до 100. Есть аут. по ntlm Kerberos. Squid 3.5.3 решит эту проблему, как думаете ??
Здравствуйте. Посмотрите эту заметку https://blog.it-kb.ru/2015/04/30/reduction-of-high-peak-load-on-cpu-resources-by-using-kerberos-authentication-helper-negotiate_kerberos_auth-for-the-squid-3-proxy-server/
Алексей спасибо за ответ, это я уже сделал но в результате нагрузка на проц не упала, хочу обновиться до 3.5. и посмотреть что покажет. 3.5.3 стабильна в работе, баги есть ?
Версию 3.5.3 мы в своё время использовали не долго, как проходную. Сейчас сидим на 3.5.8. Особых проблем не замечено.
Доброго времени суток.
Данная статья подойдёт для выполнения обновления с 3.3.8 до 3.5.28?
П.С. А какая версия у автора статьи сейчас работает?
Здравствуйте, Сергей. Не могу точно сказать по поводу 3.5.28. В более новых версиях могут быть свои особенности с патчами. Надо изучать каждый их них и принимать решение о необходимости их наложения.