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

imageРанее мы рассматривали процедуру пересборки пакета 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% нагрузки на процессор, в результате чего прокси перестаёт отвечать клиентам. По этой причине использовать данную версию в продуктивной среде я бы не рекомендовал.

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

  1. Сергей /

    Под хорошей нагрузкой, это насколько хорошей? Я как раз таки используя Ваши статьи ставил 3.4.8, в сети у меня порядка 250 пользователей. Хотел бы знать какая у Вас нагрузка что вы сделали такое вывод касательно производительности. Спасибо

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

      Больше сотни одновременных подключений с попыткой аутентификации и авторизации (клиенты ломанулись на прокси с утра). Основной процесс squid при этом тут же сожрал все процессорные ресурсы системы. Сразу стало очевидно, что хелпер ext_ldap_group_acl в новой версии под такой нагрузкой ведёт себя несколько иначе и пришлось добавлять ему параметры описывающие количество холостых процессов при запуске и максимально возможное количество процессов, чего по дефолту не требовалось в предыдущей версии squid. После перезапуска нагрузка Squid на CPU несколько упала, но спустя какое-то время снова выросла и по логам стало понятно, что есть проблемы с negotiate_wrapper_auth / negotiate_kerberos_auth. В общем весёлый утренний кавардак в конечном итоге закончился откатом виртуальных машин на состояние до обновления. После отката, как и ожидалось, ситуация нормализовалась. Наш местный эксперт по Linux покурил тему и пришёл к выводу, что в новой версии Squid управление хелперами изменилось, и пожалуй не в лучшую для нас сторону. Вот и получилось, что хотели поднять версию, чтобы использовать обновлённый функционал отправки access.log во внешний источник, а "отгребли" в итоге совсем в другом месте. Но так как инструкция по обновлению к этому моменту уже была написана и дважды проверена, было решено всё-таки её опубликовать, хотя бы в качестве примера обновления Squid из исходников.

      1. Сергей /

        Спасибо за столь развернутый ответ, у меня стоит авторизация черезе kerberos (при подключении второго способа авторизации kerberos почему-то отказывается отрабатывать, все время используется авторизация basic) и по статистике мониторинга видно постоянно большая нагрузка на ЦП притом что squid с авторизацией использует всего 8 человек. Надо попробовать поставить 3.3.13 и посмотреть на результаты. Кстати как сама скорость работы squid. у меня впечатление что 3.4 довольно медленно отдает инет, вечером буду пробовать ставить 3.3. Еще раз спасибо.

    2. vlett /

      Эта проблема известна разработчикам и прогресс в её решении можно отслеживать здесь http://bugs.squid-cache.org/show_bug.cgi?id=3997

  2. Андрей /

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

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

      Интересная информация. В предыдущем комментарии В.Леттиева есть ссылка на описание проблемы на Squid Bugzilla (Bug 3997) и там в комментах есть информация о том, что увеличение количества workers не влияет положительно на проблему загрузки. С другой стороны полностью отказываться от Kerberos как-то обидно.

      1. Андрей /

        Да, я видел описание этого бага, в общем, чтобы проверить так или нет как раз Kerberos и настроил, спасибо Алекей за подробное руководство. А количество workers выбрано без связи с аутентификаторами, а чтобы раскидать нагрузку по ядрам и остался небольшой запас - в пике загрузка (load average) подскакивает 8-9 по top, соответственно, выбрана 10 ядерная конфигурация - небольшой запасец есть. И все шевелится весьма и весьма шустро. Версия из портов тормозила - аналогичные конфиги, ставишь/запускаешь - открываешь Яндекс карты - и загрузка кусками, с тормозами. 3.4.9 шустро. Проверял на Centos/Ubuntu - разницы нет.
        Насчет Kerberos согласен, но уж больно разительная загрузка по процам - на Kerberos и на NTLN - c NTLM в тор (по загрузке проца) хелперы где-то внизу (на рабочей нагрузке 300 запросов/сек), вверху сквиды, как обычно стройненько. А с Kerberos - вверху один/два сквида, вперемешку с хелперами, которые, частенько что и на первое место вылезают. Рисковать не стал до пика - Kerberos заремил и откатил на NTLM, тем более, что баг известный - поправят, проверим :) Тем более, что прокси, имхо, самый используемый сервер в конторе, судя по загрузке ))
        Дальше в планах организовать кластер.

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

          Я тоже хочу кластер, но руки пока не добрались :)

          1. Андрей /

            О, Алексей, ваш кластер будет намного полезней - ведь с ним появится новый мануал! Пожалуй, это будет самое полное и точное руководство по использованию Squid.

    2. vlett /

      Прошу прощения, что поздно вклинился в обсуждение. А как после этих хаков работает service restart/reload?

      1. Андрей /

        Так же как работал или не работал )) Если память мне не изменяет, в ubuntu касательно squid в /etc/init.d ничего не предвиделось. А через upstart все работает
        sudo stop squid3
        sudo start squid3

  3. Alexey /

    В инструкции есть такой пункт:
    "Удаляем из списка патчей, те которые не могут быть применены к новым исходным файлам"

    А как понять список патчей, которые не могут быть применены?
    Беру исходники другой версии, не 3.4.8, и всё, инструкция теряет свою полезность.
    Прошу, раскройте алгоритм, по которому можно понять, какие патчи не могут быть применены?

    1. vlett /

      Универсальной инструкции нет. Как тут уже написали, надо проверять патч на применимость с помощью команды
      quilt push
      Поправить патч под новую версию, в принципе, не сложно, так как формат патча текстовый. Можно создать копию исправляемого файла, внести руками изменения по образцу существующего патча, и потом сгенерировать новый патч с помощью команды
      diff -u старый_файл новый_файл > патч
      Но если изменения нетривиальные, или вобще невозможно найти место, которое исправлялось, то тут уже интуиция не поможет, нужно разбираться в исходном коде.

      Как только выйдет исправленая версия, можно будет обновить инструкцию и приложить архив с содержимым каталога debian, чтобы избежать заморочек с патчами.

      1. Андрей /

        Сложного с патчами нет ничего - таки, я предпочитаю генерить новые не с помощью diff а с помощью quilt, но не суть. А логику я предпочитаю такую - если патч правил конфиги, пути и прочее - можно взяться и поправить, сложного ничего нет. А вот если правились исходники - лично я пас )) и такой патч безопасней удалить (при возникновении косяков).

  4. Андрей /

    Для проверки применяйте патчи по одному:
    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 обломятся.

    1. vlett /

      > У меня сейчас на 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, чтобы туда включили это исправление и не пришлось бы танцевать с патчами.

      1. Андрей /

        Пересобрать 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 не соберется

  5. Андрей /

    Баг #3997 исправлен в патче squid-3.4-13210.patch, текущий релиз squid-3.4.11-20150124-r13214, не надо ждать - берите и ставьте.

  6. Aleksandr Gudžunas /

    расскажите как до 5,2 обновится, пакет не хочет собираться не в какую =//

    1. Алексей Максимов / Автор записи
  7. Обратная ссылка: Обновляем Squid 3.3.8 до версии 3.5.3 из исходных файлов на Ubuntu Server 14.04.2 LTS | Блог IT-KB /

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

  9. Azaka /

    Любопытно, а на текущий момент, спустя три года, изменилось ли что-то? Т.е. рекомендовали бы Вы сейчас переходить на доступную сегодня крайнюю версию Сквида - 3.5.27?

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