1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Subject: Наш проект версии v1.1.1 обновлён на сервере 'testing'

user1 выложил следующие обновления на сервер 'testing':

Коммиты по задачам:
http://jira.local/browse/PROJECT-1234

Полный список коммитов с предыдущего обновления:
4392a53 Thu Aug 18 17:50:32 2011 +0700 user1 / [PROJECT-1234] сделал полезное
f2fcfe2 Thu Aug 18 17:37:53 2011 +0700 user1 / сделал страшное
cb1fcbe Wed Aug 17 15:18:10 2011 +0700 user2 / зарефакторил

Изменения по файлам:
 file1                 |    4 ++--
 file2                 |    8 ++++----
 file3                 |    8 ++++----
 3 files changed, 10 insertions(+), 10 deletions(-)

Такое решение помогло нам избавиться от вопросов тестеров “Ну что, выложили уже исправление бага XXX?”, “Что нового на тестовом сервере?”. Так же - все члены команды, отдел внедрения и руководство в курсе, что происходит с кодом на серверах. Для работы используется git, capistrano (+ multistage), php, bash (+ некоторые консольные утилитки). Если интересно - заходим под кат.

Алгоритм работы

• Обновляем код на сервере testing (cap testing deploy)
• После deploy:restart срабатывает хук, создающий тег в репозитории. Тег формируется на основе версии проекта (хранится в конфиге, в репозитории), названии staging-сервера и названии релиза
• В репозитории срабатывает хук. Если пришёл не тег - игнорируем, если же тег:
  • Распиливаем его на компоненты: версия, сервер
  • Определяем предыдущий тег на этом же сервере
  • Если тега нет - значит эта первая установка и генерировать различия не стоит, там может быть несколько тысяч коммитов
  • Если же есть тег - генерируем список различий, выдёргиваем из них список задач; составляем список изменённых файлов
  • Отправка сгенерированного письма

Создание тега

Про настройку capistrano и capistrano-multistage уже где только не написано, поэтому я только расскажу, как у нас добавляется тег.

Будем считать, что у нас в корне репозитория есть файл configs.ini, который содержит ключ runtime.version. За основу был взят gist#381852.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

namespace :deploy do

  after "deploy:restart", "deploy:git:push_deploy_tag"
  namespace :git do
    desc "Place release tag into Git and push it to server."
    task :push_deploy_tag do
      user = `git config --get user.name`.strip
      email = `git config --get user.email`.strip
      version = `git cat-file -p #{real_revision}:configs.ini | fgrep runtime.version | awk -F '[ =]+' '{print $2}'`.strip
      puts `git tag v#{version}-#{stage}-#{release_name} #{real_revision} -m "Deployed by #{user} <#{email}>"`
      puts `git push --tags`
    end
  end
end

Что здесь происходит:

• Извлекаем данные текущего пользователя (имя и почту) из конфига гита
• Берём файл configs.ini из устанавливаемой ревизии и выдёргиваем версию
• Создаём аннотированный тэг. В аннотации указываем, кто и когда задеплоил
• Публикуем теги

Обрабатываем обновление репозитория

Хуку pre-receive на вход (stdin) подётся 3 значения: предыдущая и текущая ревизии, refname. Читаем входящие параметры и убеждаемся, что пришёл тег:

1
2
3
4
5
6
7
8
9

while read oldrev newrev refname
do
    rev_type=$(git cat-file -t $newrev 2>/dev/null)

    case "$refname","$rev_type" in
        refs/tags/*,tag)
        ;;
    esac
done

Выделяем название тега, разбиваем его на части, ищем предыдущий тег для этого сервера:

1
2
3
4
5

tag=${refname##refs/tags/}

version=`echo $tag | cut -d- -f1`
server=`echo $tag | cut -d- -f2`
prevtag=$(git describe --tags --abbrev=0 --match="*-$server-*" $newrev^ 2>/dev/null)

Если в $prevtag пусто - значит это первая установка на сервер. Если версия у нового и старого тега совпадает - это обновление, если же нет - установка новой версии. Таким образом мы генерируем корректный заголовок письма.

Начнём формировать тело письма. Сперва - определим кто осмелился задеплоить:

1
2
3
4
5

eval $(git for-each-ref --shell --format='
          tagger=%(taggername)
          tagged=%(taggerdate)' $refname
        )
echo "$tagger выложил следующие обновления на сервер '$server':" > msg

Теперь разберём коммиты по задачам. Последние в Jira именуются по маске <алиас проекта>-<id задачи>, все разработчики в обязательном порядке указывают алиас задачи (uppercase) в коммите. Если задача крупнее чем на 30 минут и требует более 1 коммита - создаётся ветка, по алиасу задачи, и тогда в коммитах эту самую задачу мы уже не упоминаем. Итого, чтобы достать список задач нам нужно выполнить не сложную обработку регуляркой:

1
2
3
4
5
6
7
8
9
10
11

git log $rev_range --abbrev-commit --pretty="format:%s" > tmpfile
php >tickets <<END
<?php
\$f = file_get_contents("$tmp");
if (preg_match_all("#([A-Z.]+-\d+)#", \$f, \$matches)) {
    \$matches[1] = array_unique(\$matches[1]);
    foreach (\$matches[1] as \$match) {
        echo '$JIRA_HOST/browse/', \$match, PHP_EOL;
    }
}
END

Если в итоге файл tmpfile не пуст - добавляем его к телу письма. Дальше идёт информация, которая интересует только разработчиков проекта: списки коммитов и изменённых файлов:

1
2
3
4
5

echo "Полный список коммитов с предыдущего обновления:" >> msg
git log $rev_range --no-merges --abbrev-commit --pretty="format:%h %ad %an / %s" >> msg

echo -e "\n\nИзменения по файлам:" >>msg
git diff --stat=140,110 $rev_range >>msg

Ну и, наконец, тупая отправка письма:

1

cat msg | mail -s "$subject" $MAIL_TO

Все файлы можно взять на гитхабе: https://github.com/zvirusz/git-deploy-notify

P.S. Если кто-нибудь поможет переписать кусок кода, выдёргивающий имена задач, на perl/bash - я буду очень рад.

Спустя ещё несколько месяцев в сети стали появляться фэйки - это когда, например, скачиваешь Шрэка, а там вовсе даже не Шрэк, а красная шапочка и трое непонятных мужиков… Некоторое время боролись своими силами, но душа поэта не выдержала - и я решил улучшить бота.

1. В код dctc (v0.85.9) была добавлена обработка и хранение IP-адреса пользователя, проверка пользователя на online\offline, возможность отправки сырых команд на сервер. Обмен файлами в современных сетях по-прежнему невозможен - клиент не дружит с TTH.
2. В бота, находящегося на стороне сервера, добавлена функция отсылки “уведомлений” пользователям - человеку в общий чат и в ЛС отправляется указанное сообщение, после чего пользователь перенаправляется на несуществующий хаб. Т.о. если человек повторно зашёл на хаб - можно с достаточной долей уверенности сказать, что человек прочитал уведомление.
3. Так же - при появлении пользователя на хабе к нему автоматически отправляются запросы на поиск нескольких самых распространённых TTH.
4. В контекстном меню файлов добавилась функция “сообщить о фейке” - при использовании которой отправляется сообщение модераторам хаба с указанием TTH файла.
5. Полностью переписан мой бот: функции для работы с DCTC вынесены в отдельный класс и этот класс расширяется функциями, специфичными для нашего хаба.
6. Скрипт поиска решено было разбить на 2 части - одна из них лишь отправляет запросы на поиск, а вторая - занимается анализом ответов на эти самые запросы.
7. Из-за того, что скрипт был внедрён спустя некоторое время, а не сразу же после возникновения проблемы - количество банов за фейки у пользователя ищется через общую таблицу банов, а не через отдельную.
8. Перед баном - пользователю отсылается уведомление о наличии у него некорректных файлов и только если такое уведомление уже отсылалось - применяется бан на период, зависящий от количества подобных нарушений.

При работе всей системы используются следующие таблицы:

• bans: Глобальное хранилище банов
• fake_check: Лог поиска фейков
• fake_list: Список зарегистрированных фейков
• fake_names_order: Списки файлов с запрещёнными и разрешёнными именами для каждого фейка
• fake_bans: Баны за фейки, используется только для логирования
• fake_notifies: Уведомления о наличии фейков, используется только для логирования
• fake_counter2: Количество файлов, не отнесённых ни в разрешённый, ни в запрещённый списки

Архив со всеми (кажется) необходимыми файлами: dctc.tar.bz2.html. Файлы:

• dctc.patch: Патч, который нужно наложить на dctc версии 0.85.9
• dctc.sh: Скрипт, которым я запускаю dctc. Он так же меняет права на доступ к сокету, т.о. всё члены группы dctc смогут с ним работать.
• dctcController.php: Базовый класс для работы с сокетом dctc
• dctcController_tech.php: Класс с настройками и дополнительными функциями для нашего хаба
• fakes.php: Страница для управления базой фейков
• reply_analizer.php: Анализатор ответов поиска - ведёт различные логи, уведомляет и банит пользователей
• search.php: Инициирует поиск 20 произвольных фейков
• tables.sql: Дамп структуры таблиц

Накладываем патч: Скачиваем http://ac2i.homelinux.com/dctc/dctc-0.85.9.tar.gz, распаковываем, командуем patch -p1 -ddctc-0.85.9 < dctc.patch. Основная цель патча - добавить в dctc поддержку команды $UserIP - дабы мы могли узнавать IP-адрес пользователя, которого хотим банить. Самое интересное так это то, что dctc нормально работает после моего патча - c/c++ я знаю только по университетскому курсу. Всё как-то на php больше быдлокожу…

Компилируем, устанавливаем, запускаем dctc. Как его запускать - смотрим в dctc.sh.

Дальше нужно поправить класс dctcController_tech - команды на бан и уведомление у вас, скорее всего, другие. Да и hubCharset, возможно, тоже отличается. В переменной $_socketPathFile лежит путь до файла, в котором сохраняется путь до сокета. Вот такое вот извращение. Для ограничения частоты поиска используется shared memory - дёшево и сердито. Убедитесь, что ваш php это умеет.

Инициализируем БД и через fakes.php записываем всякие нехорошие TTH в базу.

Затем в фоне (или в скрине, кому как больше нравится) запускаем скрипт reply_analizer.php - он будет молча делать свои грязные делишки.

Дальше настраиваем периодический запуск search.php и наслаждаемся массовыми расстрелами.

Надеюсь кому-нибудь в чём-нибудь да поможет.

Так вот, почему бы вам, господам принимающим оплату через SMS не упростить жизнь пользователю и не добавить небольшую картинку рядом с информацией о платеже? Благо делается это предельно просто — например код по ссылке chart.apis.google.com/…/ сгенерирует сообщение на номер 01 с текстом abcdef123. Да и существуют готовые решения для генерации QR-кодов для популярных языков программирования, если у вас нет желания зависеть от гугла.

Реализовать не сложно (разве что в дизайн вписать), а пользователю — приятно.

Весь код MCS находится в файле monopoly.1255614067.js. Если посмотреть firebug’ом, что происходит в процессе покупки здания — мы увидим, что используются 2 функции — MCS.BUILD.showLocations() (для отображения маркеров доступных мест) и MCS.BUILD.buyBuilding() (для, собственно, покупки здания). После размышлений у меня получился следующий код:

Перед началом работы скрипт проводит несколько проверок: наличие класса MCS (в противном случае мы точно не на сайте игры), наличие авторизации у пользователя, а так же проверяется текущая выделенная улица. Далее выдаётся запрос для выяснения типа здания — список последних берётся из кода игры. Проверяется наличие денег у игрока и наличие свободных мест на улице. Затем выясняем количество домов для постройки и приступаем к этому увлекательному занятию. Чтобы пользователь не скучал — не забываем отобразить «песочные часы» в верхней панели. И, наконец, выводится количество построенных домов.

Чтобы преобразовать этот скрипт в 1 строку — используем javascriptcompressor.com/, в результате у нас почти есть букмарклет — остаётся только добавить ‘javascript:’ в начало полученной строки.

P.S. В качестве бонуса — букмарклет для отображения стоимости текущей улицы без зданий:

1

javascript:if(typeof MCS != "undefined"&&MCS.STREET.getStreetData().data)alert(MCS.STREET.getStreetData().data.p*1000);

UPD Букмарклет для пакетного удаления зданий:

Параметры:

XFERLOG - путь до файла xferlog (в vsftpd - нужно включить генерацию оного в конфиге, в proftpd - это параметр TransferLog конфигурации) в Вашей системе

MATCH_FILES - список исследуемых имён файлов (без расширений)

EXCLUDE_LIST - список игнорируемых файлов

Сохраняем скрипт, выставляем права на исполнение, добавляем в крон.

Всем спасибо за внимание, надеюсь кому-нибудь будет полезно.

Повествование будет вестись на примере всё той же ОС — Debian (так что пути и команды у вас могут отличаться). Для начала — поставим tftp-сервер. Смотрим доступные варианты (apt-cache search tftp | fgrep server):

• atftpd
• dnsmasq
• tftpd
• tftpd-hpa

Сначала я поставил tftpd-hpa, т.к. о нём рассказывалось в мануале, с которого я начинал создание сервера. Затем я перешёл на atftpd, т.к. мне потребовалось логирование. Рассмотрим оба варианта:

• tftpd-hpa:
  Устанавливаем пакет, редактируем файл /etc/default/tftpd-hpa, дабы демон знал, что ему стоит жить:

  #Defaults for tftpd-hpa
  RUN_DAEMON="yes"
  OPTIONS="-l -s /var/lib/tftpboot"

  Создаём нужный каталог: mkdir /var/lib/tftpboot, и стартуем сервис invoke-rc.d tftpd-hpa start

• atftpd:
  После установки обнаруживаем, что по-умолчанию этот сервис работает через inetd. Я, почему-то, не фанат этого метода, поэтому первым делом закомментировал соответствующую строку в /etc/inetd.conf. Затем редактируем /etc/default/atftpd:

  USE_INETD=false
  OPTIONS="--daemon --tftpd-timeout 1500 --no-multicast --retry-timeout 20 --logfile /var/log/atftpd.log --maxthread 100 --verbose=5 /var/lib/tftpboot"

  --tftpd-timeout — время жизни потока, при отсутствии запросов
  --retry-timeout — таймаут отдачи файла
  у меня установлены большие таймауты, т.к. сервис транслируется в городскую локальную сеть, которая периодически прогибается от обилия абонентов, и не справляется с потоком запросов.
  Ну и, как и в предыдущем пункте, — создаём нужный каталог: mkdir /var/lib/tftpboot, и стартуем сервис invoke-rc.d atftpd start

Теперь у нас есть tftp-сервер. Один шаг мы сделали :) Далее — настройка dhcp:

• dhcp3:
  В конфигурационный файл /etc/dhcp3/dhcpd.conf добавляем информацию о загрузке:

  filename "pxelinux.0";
  next-server ;

  Если tftpd установлен на том же сервере, что и dhcpd — директиву next-server можно опустить. И перезапускаем dhcp3-server: invoke-rc.d dhcp3-server restart

• dnsmasq:
  В конфиг /etc/dnsmasq.conf дописываем:

  dhcp-boot=pxelinux.0,<tftp-server-hostname>,<tftp-server-ip>

  Опять же, если сервера tftp и dhcp совпадают — последние 2 атрибута можно не заполнять. Перезапускаем: invoke-rc.d dnsmasq restart

Шаг второй пройден. Дальше — непосредственно настройка pxe-boot. Идём на ftp.debian.org, выбираем каталог installer-*, соответствующий необходимой архитектуре. Затем переходим в директорию current/images/netboot внутри мы найдём файлы netboot.tar.gz и gtk/netboot.tar.gz — это файлы текстовой и графической установки соответственно. Выбираем понравившийся, качаем и распаковываем в /var/lib/tftpboot. Осталось убедиться, что зазрешён доступ на 69 UDP порт, и можно пользоваться прелестями сетевой установки.

В качестве бонуса прилагаю меню, которое получилось у меня в результате нескольких дней издевательств. В текущей конфигурации возможна установка нескольких ОС (установка Debian возможна как в текстовом, так и в графическом режиме), загрузка xUbuntu (через nfs), SystemRescueCD (через http-boot), memtest86 (через tftp). Установка всех ОС возможна для 2 архитектур — x86 и x64. Т.к. у меня лежит внутрисетевое зеркало репозиториев Ubuntu 8.10 и Debian 5.0, то установщики не предлают выбор репозитория, а автоматически сливают всё с него.

Архив /var/lib/tftpboot (без малого 200мб), а так же — файлы конфигурации для установщиков Ubuntu и Debian: в них указаны репозитории + Ubuntu разбивается на Ubuntu, kUbuntu, xUbuntu, edUbuntu.

В этой конфигурации есть один большой минус, который мне лень исправить: при открытии меню подгружается порядка 70 файлов, бОльшая часть из которых не нужна пользователю. Что бы избавиться от этого — отображение подменю нужно перевести из подключения меню инклудами в их вызов через ядро vesamenu.c32, которое идёт с pxeboot. Так же — не помешает очистить каталоги меню от дубликатов — большая часть конфигов для меню x64 и x86 совпадает.

Дано:

• 2 физических фаервола, по совместительству являющихся шлюзами (192.168.1.10 и 192.168.2.10)
• 2 сетевых интерфейса (lan1 — 192.168.1.101 и lan2 — 192.168.2.101)
• желание заставить это добро работать так, как нужно нам

Чтож… приступимс.

• Windows
  • Управление приоритетом сетевых подключений:
    Необходимо создать 3 маршрута:

    route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.10 metric 1
    route -p add 10.0.0.0 mask 255.0.0.0 192.168.1.10 metric 1
    route -p add 10.0.0.0 mask 255.0.0.0 192.168.2.10 metric 1

  Далее идём в Сетевые подключения -> Дополнительно -> Дополнительные параметры, перемещаем lan2 вверх, чтобы это соединение оказалось выше lan1. Готово.

  • Приоритет в таблице маршрутизации: Опять же — создаём 3 маршрута. Только изменим метрики

    route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.10 metric 1
    route -p add 10.0.0.0 mask 255.0.0.0 192.168.1.10 metric 2
    route -p add 10.0.0.0 mask 255.0.0.0 192.168.2.10 metric 1

    И никаких танцев с приоритетом интерфейсов. Считаю этот метод оптимальным.
    UPD: метрика интерфеса, приоритет которого выше (см. предыдущий пункт) не должна быть наименьшей.
• Linux
  • Приоритет в таблице маршрутизации:
    Тут почти тоже самое, что и в предыдущем пункте (только синтаксис чуток различается)

    route add default gw 192.168.1.10 metric 0
    route add -net 10.0.0.0/8 gw 192.168.1.10 metric 1
    route add -net 10.0.0.0/8 gw 192.168.2.10 metric 0

  • iproute2:
    Собственно, для этого решения необходимо наличие установленного пакета iproute2. В дебиане — apt-get install iproute.
    В этом случае нам понадобится 2 маршрута

    route add default gw 192.168.1.10 metric 0
    route add -net 10.0.0.0/8 gw 192.168.2.10 metric 0

    Создадим 2 таблицы маршрутизации:

    echo '10 lan1' >> /etc/iproute2/rt_tables
    echo '11 lan2' >> /etc/iproute2/rt_tables

    Добавляем в эти таблицы правила маршрутизации:

    ip route add default via 192.168.1.10 table lan1
    ip rule add from 192.168.1.101 table lan1
    ip route add 127.0.0.0/8 dev lo table lan1
    ip route add default via 192.168.2.10 table lan2
    ip rule add from 192.168.2.101 table lan2
    ip route add 127.0.0.0/8 dev lo table lan2

    Последние правила — для того, чтобы пакеты с локального интерфейса не терялись.
    Так же не стоит забывать, что линукс при перезагрузки очищает таблицы и правила маршрутизации, потому рекомендую создать хитрый скрипт в папке /etc/network/if-up.d. У меня там лежит скрипт такого содержания:

    #!/bin/sh -e
    case "$IFACE" in
    eth1)
    ip route add default via 192.168.1.10 table lan1
    ip rule add from 192.168.1.101 table lan1
    ip route add 127.0.0.0/8 dev lo table lan1
    ;;
    eth2)
    route del default gw 192.168.2.101
    route add -net 10.0.0.0/8 gw 192.168.2.10 1
    ip route add default via 192.168.2.10 table lan2
    ip rule add from 192.168.2.101 table lan2
    ip route add 127.0.0.0/8 dev lo table lan2
    ;;
    esac

Выбор за вами. Скажу лишь что было решено остановиться на вторых вариантах для обоих систем (изменение метрики на windows и iproute2 на debian).

Кому интересна тема маршрутизации в линуксе — рекомендую почитать вот эту вещь lartc.org/howto/ Надеюсь, кому‐ нибудь эта информация окажется полезной.

И ещё раз, коллеги — с праздником :)

Для опытов нам потребуется:

1. 1 сервер с установленным на нём squid’ом + ещё какой-нибудь проксёй (если хотите, чтобы этот сервер был не только центральным, но и делился инетом). я расскажу про поднятие кластера на базе дебиана, 2 интернет-каналов и 3 сквидов (сквиды для родительских проксе выбраны по 2 причинам: из-за возомжности предоставления статистики по текущим соединениям; из-за лени искать альтернативу)
2. Любое количество компьютеров, с любыми ОС и любыми http-проксями
3. Опционально — апач, пхп и скрипт SqStat — для просмотря активности прокси

Будем считать что у нас есть 2 машины — 192.168.1.1 (у неё так же есть 2й ип, со 2м провайдером — 192.168.2.1) и 192.168.1.2.

Немного погуглив — я нашёл заметку без малого 5летней давности — Squid 2 chans. Из неё было выцеплено 2 момента — как, собственно, организовать кластер и как проксировать на разных интерфейсах.

Для начала — создадим дополнительные сервисы squid’a. Сперва — немного подправим конфиг сервера (/etc/squid/squid.conf). Т.к. кэш мне не нужен — я его отрубил. Делается это установкой параметра cache_dir следующим образом:

1

cache_dir null /var/spool/squid

Т.к. отключили кэш — отрубаем и лог записи в кэш

1

cache_store_log none

Откроем доступ к прокси для всех (нужно вставить до записи http_access deny purge):

1
2

acl all src 0.0.0.0/0.0.0.0
http_access allow all

Откроем доступ к прокси по протоколу cache_mgr с локалхоста (я не помню, какие параметры указаны в дефолтном конфиге — так что не помешает перед вставкой проверить, что уже есть):

1
2
3

acl manager proto cache_object # это строка, скорее всего, уже есть в конфиге
http_access allow manager localhost
http_access deny manager

Слушать порт 8080 (по дефолту — 3128):

1

http_port 8080

Для ограничения доступа к прокси — я предпочитаю использовать iptables (по-умолчанию — все пакеты отбрасываются), а не аутентификацию, поэтому прокся из конфига открыта для всех:

1
2
3
4

iptables -N proxy
iptables -A proxy -j REJECT
iptables -I proxy -s 192.168.1.2 -j ACCEPT
iptables -I INPUT -p tcp --dport 8080 -j proxy

Теперь добавим родительские прокси (говорю сразу — с приведённой ниже конфигурацией — ничерта не заработает. но дальше, по ходу повествования — ошибка будет найдена и исправлена :)):

1
2
3

cache_peer 127.0.0.1 parent 8081 0 no-query no-digest round-robin weight=4
cache_peer 127.0.0.1 parent 8082 0 no-query no-digest round-robin weight=1
cache_peer 192.168.1.2 parent 8080 0 no-query no-digest round-robin weight=4

Итого — 3 родительских прокси, с которых не будет запрашиваться кэш (no-query) и cache-digest (no-digest), родители будут циклически переключаться (round-robin). Ну и разный weight — ибо 2й канал у меня слабый. Запрещаем сквиду ходить напрямую (не через родителей):

1

never_direct allow all

Создаём 2 копии конфига — /etc/squid/squid_2.conf и /etc/squid/squid_3.conf. Удаляем из них строки, начинающиеся на cache_peer, never_direct. Изменяем значение параметра http_port на 8081 и 8082 соответственно. Изменяем пути до логов (здесь и далее по тексту — изменения будут указываться только для squid_2, для squid_3 — изменения аналогичны):

1
2

access_log /var/log/squid_2/access.log
cache_log /var/log/squid_2/cache.log

Так же не помешает создать этот путь и сменить владельца, дабы сквид мог писать логи:

1
2

mkdir /var/log/squid_2
chown proxy:proxy /var/log/squid_2

Указываем расположение pid-файла:

1

pid_filename /var/run/squid_2.pid

Расположение кэша я не менял — все 3 прокси спокойно работают с 1 каталогом. Но squid -z (инициализировать кэш) перед первым запуском сделать не помешает.

Теперь приступим к созданию init-скриптов. В файле /etc/init.d/squid комментируем код, ответственный за инициализацию кэша (т.к. скрипт не рассчитан на null-кэш):

1
2
3
4
5

# if [ -d "$cdr" -a! -d "$cdr/00" ]
# then
# log_warning_msg «Creating squid spool directory structure»
# $DAEMON -z
# fi

Копируем /etc/init.d/squid => /etc/init.d/squid_2. Изменяем squid_2:

1
2
3

NAME=squid_2
...
SQUID_ARGS="-D -sYC -f /etc/squid/squid_2.conf"

Так же, для душевного равновесия, можно изменить сообщения, которые выдаёт скрипт:

1
2
3
4
5

log_daemon_msg «Starting Squid HTTP proxy» «squid_2»
...
log_daemon_msg «Stopping Squid HTTP proxy» «squid_2»
...
log_daemon_msg «Restarting Squid HTTP proxy» «squid_2»

Для следующего фокуса — в начале инит-скрипта должны быть примерно следующие строки:

1
2

# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6

Настраиваем запуск свеже созданного сервиса с системой:

1

update-rc.d squid_2 defaults

Запускаем дочерние прокси:

1
2

invoke-rc.d squid_2 start
invoke-rc.d squid_3 start

Вот он, момент истины — запускаем центральный прокси

1

invoke-rc.d squid start

и…

1

FATAL: ERROR: cache_peer 127.0.0.1 specified twice

… и нас жестоко обламывают.

Немного подумав (руки до гугля не доходят) — заменяем в одной записи 127.0.0.1 => localhost. Запускаем, и вот оно — счастье. Сквид на 2й машине можно настроить копированием /etc/squid/squid.conf и удалением оттуда упоминаний о cache_peer и never_direct + поправить права доступа по протоколу cache_mgr. Для тестирования — настроить любимый браузер на использования прокси и открыть любую страницу. Смотрим /var/log/squid/access.log, там должны быть примерно следующие строки:

1
2
3
4

1214499645.364 15335 89.189.176.111 TCP_MISS/206 214755 GET ru.download.nvidia.com/Windows/177.41/177.41_geforce_winxp_64bit_international_whql.exe — ROUNDROBIN_PARENT/192.168.1.2 application/octet-stream
1214499646.148 11138 89.189.176.111 TCP_MISS/206 534572 GET ru.download.nvidia.com/Windows/177.41/177.41_geforce_winvista_64bit_international_whql.exe — ROUNDROBIN_PARENT/127.0.0.1 application/octet-stream
1214499650.695 3564 89.189.176.111 TCP_MISS/206 370947 GET ru.download.nvidia.com/Windows/177.41/177.41_geforce_winvista_64bit_international_whql.exe — ROUNDROBIN_PARENT/localhost application/octet-stream
1214499658.899 52092 89.189.176.111 TCP_MISS/206 1115575 GET ru.download.nvidia.com/Windows/177.41/177.41_geforce_winvista_64bit_international_whql.exe — ROUNDROBIN_PARENT/192.168.1.2 application/octet-stream

Далее по плану — SqStat. Скачиваем архив, распаковываем в любую www-папку, переименовываем config.inc.php.defaults => config.inc.php и правим:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

$squidhost[0]=«localhost»;
$squidport[0]=8080;
$cachemgr_passwd[0]="";
$resolveip[0]=false; # для красоты — можно и true поставить :)
$hosts_file[0]=«hosts.txt»;
$group_by[0]=«host»;

$squidhost[]=«localhost»;
$squidport[]=8081;
$cachemgr_passwd[]="";
$resolveip[]=false;
$hosts_file[]=«hosts.txt»;
$group_by[]=«host»;

$squidhost[]=«localhost»;
$squidport[]=8082;
$cachemgr_passwd[]="";
$resolveip[]=false;
$hosts_file[]=«hosts.txt»;
$group_by[]=«host»;

$squidhost[]=«localhost»;
$squidport[]=8081;
$cachemgr_passwd[]="";
$resolveip[]=false;
$hosts_file[]=«hosts.txt»;
$group_by[]=«host»;

$squidhost[]=«192.168.1.2»;
$squidport[]=8080;
$cachemgr_passwd[]="";
$resolveip[]=true;
$hosts_file[]=«hosts.txt»;
$group_by[]=«host»;

Открываем браузером sqstat.php и наблюдаем за активностью.

Так же выкладываю немного изменённую версию SqStat — дополнительно отображает суммарную скорость\объём по параметру группировки — sqstat.class.php, файл нужно положить в папку с оригинальным sqstat, заменив оригинал.

В пассивном режиме 3 сквида жрут 2.3% памяти, что в пересчёте на МБ составляет 14,72.

P.S. # squid -v

Squid Cache: Version 2.6.STABLE5

UPD: все же, надеюсь, понимают, что при скачивании в 1 поток через такую прокси — увеличения скорости не будет? для увеличения скорости необходимо запустить закачку с n потоками, где n — количество проксей в кластере (если веса одинаковы).