Лучший способ кэширования подходящих загрузок в локальной сети?

У меня дома есть несколько машин с Ubuntu и довольно медленное интернет-соединение, и иногда нужно обновить сразу несколько машин (особенно во время новых выпусков Ubuntu).

Есть ли способ, когда только одна из моих машин должна загружать пакеты, а другие машины могут использовать первую машину, чтобы получить дэбы? Включает ли это настройку моего локального зеркала? Или прокси-сервер? Или это можно сделать проще?

6 ответов

Решение

Я провел некоторое исследование по ряду решений, и некоторые разработчики Ubuntu придумали конфигурацию прокси (на основе Squid) для 10.04 и более поздних версий. Это называется squid-deb-proxy, Это только требует, чтобы машина действовала как сервер. Крупные организации обычно используют собственные полные зеркала, но для большинства людей достаточно зеркалирования по требованию.

Почему squid-deb-proxy?

  • Нет редактирования файлов на стороне клиента.
  • Используйте zeroconf так, чтобы клиенты были "нулевым конфигом"
  • Используйте существующее твердое решение для прокси вместо написания нового инструмента.
  • Легко настроить для типичного администратора Linux.

Конфигурация сервера

На компьютере, на котором вы хотите действовать как сервер, установите инструмент с:

sudo apt-get install squid-deb-proxy avahi-utils

Теперь запустите сервисные биты:

 sudo start squid-deb-proxy

И биты авахи (вам это не нужно, если вы используете версию 12.04+):

 sudo start squid-deb-proxy-avahi

Это позволит установить прокси-сервер (который по умолчанию прослушивает порт 8000) и инструменты avahi, необходимые серверу для рекламы себя в сети через zeroconf.

Конфиг клиента

На каждом из компьютеров, на которых вы хотите использовать кеш (клиенты и сам сервер, чтобы он тоже мог использовать кеш), вам необходимо установить инструмент на стороне клиента, который позволит автоматически искать сервер, чтобы они щелкнули здесь:

Установить через центр программного обеспечения

или через командную строку:

sudo apt-get install squid-deb-proxy-client

Необязательно: Для максимальной эффективности вы должны настроить один компьютер на автоматическую загрузку обновлений, чтобы, когда это требуется другим вашим машинам, он уже находился в кэше. Вы можете сделать это, зайдя в "Система-> Администрирование-> Диспетчер обновлений", затем нажмите кнопку "Настройки...", на вкладке "Обновление" установите его для автоматической загрузки всех обновлений.

альтернативный текст

Кэширование сторонних источников

По умолчанию кеш настроен только на кеш официальных репозиториев Ubuntu. Чтобы добавить больше, вам нужно добавить их в список источников на /etc/squid-deb-proxy/mirror-dstdomain.acl, Здесь вы можете добавить ppa.launchpad.net или другие сервисы, которые вы можете использовать. После внесения изменений в этот файл, вы должны запустить sudo restart squid-deb-proxy для того, чтобы изменения были эффективными.

Ручная настройка

Если по какой-либо причине вы не хотите использовать zeroconf (по сетевым причинам или как-то еще), вы можете вручную настроить клиент для использования прокси, отредактировав /etc/apt/apt.conf и добавив следующий раздел (замените 0.0.0.0 на IP-адрес сервера):

 Acquire { 
   Retries "0"; 
   HTTP { Proxy "http://0.0.0.0:8000"; };
 };

Брандмауэр

В случае, если вы используете брандмауэр, avahi использует 5353 по адресам 224.0.0.0/4 и требует правила, которое выглядит следующим образом:

# Specifically port 5353 which avahi uses
-A INPUT -i eth2 -d 224.0.0.0/4 --dport 5353 -j ACCEPT

# OR

# Wide open so all local broadcasting works
-A INPUT -i eth2 -d 224.0.0.0/4 -j ACCEPT

Далее вам нужно открыть TCP-порт 8000 для фактической связи через прокси. Что-то более или менее подобное:

-A INPUT -i eth2 -p tcp -m tcp --dport 8000 -d 192.168.0.1 -s 192.168.0.0/24 --syn -j ACCEPT

Эти правила только для того, чтобы помочь вам. Они, вероятно, не будут соответствовать вашим настройкам один к одному. (т.е. неправильный интерфейс, неправильные IP-адреса частной сети и т. д.)

Подтверждая это работает

Сначала подключите журнал на сервере, чтобы вы могли посмотреть на него: tail -F /var/log/squid-deb-proxy/access.log и затем запустите обновление на любой машине, на которой установлен клиент; журнал должен начать прокручиваться с такими записями:

1307310795.647     32 192.168.1.106 TCP_MISS/302 768 GET http://us.archive.ubuntu.com/ubuntu/dists/natty-proposed/universe/i18n/Translation-en.xz - DIRECT/141.210.26.10 text/html
1307310795.683     34 192.168.1.106 TCP_MISS/302 752 GET http://us.archive.ubuntu.com/ubuntu/dists/natty/main/i18n/Translation-en_US.lzma - DIRECT/141.210.26.10 text/html
1307310795.716     32 192.168.1.106 TCP_MISS/302 746 GET http://us.archive.ubuntu.com/ubuntu/dists/natty/main/i18n/Translation-en.lzma - DIRECT/141.210.26.10 text/html
1307310795.750     32 192.168.1.106 TCP_MISS/302 764 GET http://us.archive.ubuntu.com/ubuntu/dists/natty/multiverse/i18n/Translation-en_US.lzma - DIRECT/141.210.26.10 text/html
1307310795.784     32 192.168.1.106 TCP_MISS/302 758 GET http://us.archive.ubuntu.com/ubuntu/dists/natty/multiverse/i18n/Translation-en.lzma - DIRECT/141.210.26.10 text/html
1307310795.817     32 192.168.1.106 TCP_MISS/404 657 GET http://us.archive.ubuntu.com/dists/natty-proposed/multiverse/i18n/Translation-en_US.xz - DIRECT/141.210.26.10 text/html

Это означает, что клиенты видят кеш, но пропускают его, что ожидается, поскольку он еще ничего не кешировал. Каждый последующий запуск должен отображаться как TCP_HIT. Вы можете найти сами файлы кеша squid в /var/cache/squid-deb-proxy,

Используй это

С этого момента все машины в вашей сети будут проверять кэш, прежде чем отправлять пакеты во внешнюю сеть. Если будут доступны новые пакеты, то первая машина загрузит их из сети, после чего последующие запросы на этот пакет будут поступать с сервера на клиенты.

СДЕЛАТЬ

Нам по-прежнему нужно разрешить apt просто использовать объявленный кеш в сети из коробки и по умолчанию, чтобы вам не нужно было устанавливать клиентскую часть. Нам также нужно исправить ошибку, из-за которой у 403-го deb нет в списке зеркал.

apt-cacher-ng это ответ для меня - я не сталкивался с какими-либо проблемами в небольших средах (около 20 клиентов), поэтому я предполагаю, что проблемы, о которых упоминал @MagicFab, были решены в текущей версии (установленной в Ubuntu 10.04 и 10.10). Для сервера не требуется никаких настроек, и вам нужно только указать своим клиентам использовать сервер в качестве прокси-сервера менеджера пакетов.

Сервер полностью установлен и настроен путем установки apt-cacher-ng пакет.

Клиенты должны быть настроены путем настройки прокси-сервера APT - путем добавления файла /etc/apt/apt.conf.d/01proxy, содержащий это (где "your-apt-server" - это имя или IP-адрес вашего сервера):

Acquire::http { Proxy "http://your-apt-server:3142"; };

Готово - теперь пакеты будут кэшироваться сервером, независимо от того, какие источники вы используете или какая у вас версия системы (например, сервер 10.04 может использоваться клиентами 9.10,10.04 и 11.04 без каких-либо проблем или конфликтов).


Если у вас есть клиентские ноутбуки, которые перемещаются между сетями, это становится немного сложнее - я создал скрипт, который устанавливает правильный прокси в зависимости от сетевого адреса; скрипт исполняемый и в /etc/network/if-up.d/apt-proxy, Получив IPv4-адрес от DHCP-сервера, скрипт установит правильный сервер apt-cacher для соответствующей сети:

#!/bin/sh

set -e
# Don't bother when lo is configured.
if [ "$IFACE" = lo ]; then
    exit 0
fi
# Only run from ifup.
if [ "$MODE" != start ]; then
    exit 0
fi
# currently only cares about IPv4
if [ "$ADDRFAM" != inet ] && [ "$ADDRFAM" != NetworkManager ]; then
    exit 0
fi
# only run for DHCP-assigned addresses
if [ "$DHCP4_IP_ADDRESS" = "" ]; then
    exit 0
fi

# we're matching on network *broadcast* address,
#  not the specific IP address we were assigned
case "$DHCP4_BROADCAST_ADDRESS" in
    10.3.141.255)
        PROXY='Acquire::http::Proxy "http://my-home-server:3142";';
        ;;
    192.168.154.255)
        PROXY='Acquire::http::Proxy "http://work-server.foo.bar.example.com:3142";';
        ;;
    # add as needed
    *)
        # unknown, no proxying
        PROXY=""
        ;;
esac

# set the proxy
FNAME="/etc/apt/apt.conf.d/01proxy"
echo -n "$PROXY">$FNAME

exit 0

Я предпочитаю настраивать локальное зеркало, используя debmirror полезность.

Вот пример заклинания.

debmirror --progress --verbose --nosource --method=ftp --passive \
 --host=ftp.osuosl.org --root=pub/ubuntu \
 --dist=lucid,lucid-updates,lucid-security,lucid-backports \
 --section=main,restricted,universe,multiverse --arch=amd64 \
 /d2/ftp/mirror/ubuntu-lucid

Я запускаю это примерно раз в неделю и использую его как основу для установления одного или нескольких "уровней исправлений". Например...

 cd /d2/ftp/mirror/
 cp -al ubuntu-lucid ubuntu-lucid-20100908

Это создает связанную копию дерева (использует почти нулевое дисковое пространство), на который я могу указать каждый из моих локальных серверов в apt sources.list

Одним из самых простых решений является настройка apt-proxy.

Прочитайте документацию по Ubuntu здесь: https://help.ubuntu.com/community/AptProxy

В небольших сетях (например, дома / в небольшом офисе) я использовал apt-cacher-ng с хорошими результатами. Я не проверял последние версии, но я знаю, что требуется тщательная настройка как сервера, так и клиентов, и он лучше всего подходит для клиентов, которые будут получать обновления только из вашей локальной сети.

Я попробовал решение на основе squid выше, но для этого потребовалось применить несколько обходных путей и больше конфигурации клиента, чем хотелось бы, поэтому пока не ощущается, что он может заменить apt-cacher-ng в небольших установках.

apt-cacher не было проще всего настроить, и он не переживет dist-upgrade.

устанавливать squid-deb-proxy на сервере, squid-deb-proxy-client на клиентов. Он использует Zeroconf Avahi, поэтому нет необходимости в настройке.

Если вы хотите кешировать больше, чем просто дэбы, я бы не стал беспокоиться о Squid. Apache Traffic Server - следующая большая вещь. http://trafficserver.readthedocs.org/

Другие вопросы по тегам