Обновляем Squid 3.3.8 до версии 3.5.3 из исходных файлов на Ubuntu Server 14.04.2 LTS

imageВ этой заметке будет рассмотрена процедура обновления 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

***

Приступаем к работе с патчами от старого пакета. Экспортируем путь к каталогу с патчами для 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

*** 

В правилах сборки удалим хелперы 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

***

Собираем новый пакет:

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 можно считать завершённой.

***

Пошаговая инструкция и откорректированные файлы патчей предоставлены Владимиром Леттиевым (aka crux), за что ему “наше с кисточкой”.

Всего комментариев: 33 Комментировать

  1. Обратная ссылка: Снижение нагрузки на процессорные ресурсы при использовании хелпера Kerberos-аутентификации (negotiate_kerberos_auth) для прокси-сервера Squid 3 | Блог IT-KB /

  2. Андрей /

    При использовании еще 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 запросов в сек.

  3. Сергей /

    В чем суть патчей ? они специфичны для Debian или общие? Squid скомпилированный без этих патчей в чем отличается от пропатченного ? Спасибо

    1. Андрей /

      Патчи, размещающиеся в 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) — ситуация зависает, но откат патча позволяет иметь стабильную работу.

    2. vlett /

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

      1. Андрей /

        Под другим дистрибом, например, Centos тоже будут свои патчи (если пересобирать rpm) — но там используется не quilt, а просто patch — суть та же.

    3. Андрей /

      Последний вопрос остался без ответа )) — squid без патчей отличается тем, что в нем нет исправлений, сделанных в этих патчах. Это может быть функционал, доки и пути/дистрибьюция. Что-то критично, что-то нет — тут каждый решает сам. Например без исправлений в доках у вас все прекрасно скомпилится и заработает. Ошибки в путях придется править руками при запуске, функционал — если не используете, то без разницы, но могут возникнуть проблемы со следующими версиями. В апстриме (текущей версии на сайте) именно функциональные патчи приводят к удалению старых/возникновению новых ошибок. Иногда еще продвинутые пользователи предлагают свои патчи (которые по разным причинам не включают в апстрим). Для экспериментов с патчами самый простой способ — написать скрипт для компиляции сквида (на основании всех статей отсюда) и дальше экспериментировать.

      1. Сергей /

        А какая авторизация используется у Вас при таком количестве пользователей ? У меня 3.5.3 при 200 пользователях загибается при kerberos авторизации по процессорному времени. KRB5RCACHETYPE еще пока не трогал, протестирую насколько сильно он снижает нагрузку. И еще у Вас один прокси на 800 пользователей или несколько ? И какая конфигурация сервера на такое кол-во пользователей. Спасибо.

        1. Алексей Максимов / Автор записи

          Kerberos, где невозможно Kerberos — NTLM, Basic. Пока один виртуальный сервер (в планах двух-узловой кластер) на Hyper-V (8-ядер, 6GB ОЗУ, отдельный VHD — 10GB под кэш)

          1. Сергей /

            Спасибо, у меня на 200 пользователей 4 ядро 3Gb оперативки, но вот Kerberos давал нагрузку, все же надо попробовать отключить replay-кеш и посмотреть хватит ли таких ресурсов виртуалки на такое кол-во пользователей при Kerberos авторизации. Спасибо еще раз.

        2. Андрей /

          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

          Дискового кеша нет, используется только кеш в оперативной памяти.

  4. Валентин Сайков /

    Обновился до 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.

    1. Валентин Сайков /

      Они устарели я так понял. Убрал их. Подскажите лучше как верно настроить прокси, а именно кеш. У меня сервер с 5 гигами памяти и маленьким диском. Кеш настроил но что то кажется ч намудрил.

      log при запуске http://pastebin.com/8HAha9AX

  5. k3nguru /

    Для использования uupdate нужно установить данный пакет devscripts, а то иначе бубунта будет говорить, что не знает такой команды как uupdate

  6. Alexey Gagarin /

    Установил 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

  7. Alexey Gagarin /

    Порывшись в сквидовой багзилле, обнаружил, что некий доброволец запилил патч, решающий проблему с signal 6. Прямая ссылка: http://bugs.squid-cache.org/attachment.cgi?id=3133

    Добрый мэйнтейнеры не включили этот патч в основную ветку, сославшись на то, что хак, применённый в патче, приводит к возможности утечки памяти. На справедливое замечание патчера о том, что лучше стабильный сквид, _возможно_ подверженный утечке памяти, чем «железно» нестабильный во всей ветке 3.5.x, ему гордо ответили молчанием.

  8. Alexey /

    Хочу добавить, что патч энтузиаста действительно помог избавиться от signal 6, благо изменений там не много и легко можно применить их руками перед компиляцией последней сборки 3.5.4. Что касается signal 7 — пока не проявлялось, слежу дальше.
    Если при компиляции сквида после применения патча будет выпать ошибка — скорее всего, это связано с тем, что в новых версиях компилятора gcc по-умолчанию включён флаг -Wshadow. Мне помогло исключение куска кода, на который он ругается, из проверки компилятором.

  9. Alexey Gagarin /

    Увы, signal 7 никуда не пропал. Всё так же проявляется спонтанно стабильно раз в сутки и лечится только полной перезагрузкой виртуальной машины. Судя по отсутствию даже намёков на подобные проблемы у других людей, делаю предположение, что проблема связана с виртуализацией вообще и с VmWare в частности.

    1. Алексей Максимов / Автор записи

      Здесь http://bugs.squid-cache.org/show_bug.cgi?id=4249 говорят о том, что squid можно пересобрать с опцией —disable-march-native. Не пробовали это?

  10. Alexey Gagarin /

    Это тема, которую я и создал. Squid уже скомпилирован с этой опцией. Пока попробовал поотключать разные «улучшайзеры» в vCenter для этой виртуальной машины, сутки пошли. Следующий шаг — откат на 3.3.8.

    1. Алексей Максимов / Автор записи

      А почему именно на 3.3.8, а не на последнюю версию в ветке 3.4 (3.4.13)? Мы у себя тоже заметили наличие проблемы с перезапуском каждые 2 часа («killed by ABRT signal»). Сейчас думаем что делать дальше.

  11. Alexey Gagarin /

    Потому что в версии 3.4.13 проблема с signal 6 также не решена, судя по багзилле. Вообще, как заметили выше, баг с signal 6 появляется после конкретного патча, а он, насколько я понял, применяется сразу на две ветки. На 3.3.8 хочу откатиться, потому что, судя по всему, у вас с ней проблем в виртуализованной среде не наблюдается. Старовата она, конечно, но стабильность дороже.

    Отключения «улучшайзеров» не помогли. Ещё есть небольшая вероятность, что проблема в ядре (ядро нестандартное, скомпилированное под «своё» железо). Попробую раскатать свеженький Debian 8 со стандартным ядром и развернуть Squid там, прежде чем даунгрейдиться.

    Халтурят разработчики, в 2011 году поднимал подобную связку на Squid 3.1 + FreeBSD, работало как часы.

  12. Alexey Gagarin /

    Итак, пересбор последний версии Squid 3.5.4 (и правка «ручками» исходников для решения проблемы с signal 6) на свежем Debian 8.0 «Jessie» со стандартым ядром мою проблему решил. Что ж, видимо, проблема всё-таки была в кастомном ядре.

  13. Алексей Максимов / Автор записи

    Итак, в конечном итоге мы откатились на 3.3.14. Уже несколько дней работает без падений. Правда с этой версией возник ещё один нюанс — в squid.conf не воспринимаются комментарии написанные в конце строки с некоторыми директивами, например http_access…пришлось такие комментарии перенести в отдельные строки :)
    В общем ждём исправления бага с «killed by ABRT signal» и снова будем смотреть в сторону обновления.

    1. Андрей /

      Последняя использованная нами версия 3.5 линейки 3.5.10-20151001-r13933 у нас работала стабильно, без перезагрузок, отвалов и пр. То есть сервак перезагружался только при обновлении ядра.

  14. Обратная ссылка: Разворачиваем локальный apt-репозиторий пакетов на Ubuntu Server 14.04 LTS | Блог IT-KB /

  15. Андрей /

    В принципе, можно уже начинать тестировать/переползать на 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 )) ) — тогда больше никуда изменения вносить не надо, все компилится, ставится и работает.
    Если будут нужны интересны перечисленные патченные файлы — могу выложить.

  16. Dmitriy /

    Застрял на этом этапе. ЧТо там конкретно корректировать?

    Следующие патчи в каталоге ~/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

    1. Алексей Максимов / Автор записи

      Ссылка на уже отредактированные файлы патчей в статье.

  17. Falk /

    Здравствуйте Алексей,
    Squid 3.3.8, при 60 пользователей проц. играет в пределах 50-90% иногда подскакивает и до 100. Есть аут. по ntlm Kerberos. Squid 3.5.3 решит эту проблему, как думаете ??

  18. Falk /

    Алексей спасибо за ответ, это я уже сделал но в результате нагрузка на проц не упала, хочу обновиться до 3.5. и посмотреть что покажет. 3.5.3 стабильна в работе, баги есть ?

    1. Алексей Максимов / Автор записи

      Версию 3.5.3 мы в своё время использовали не долго, как проходную. Сейчас сидим на 3.5.8. Особых проблем не замечено.

Добавить комментарий