Лучший способ кэширования подходящих загрузок в локальной сети?
У меня дома несколько компьютеров с Ubuntu и довольно медленное подключение к Интернету, и иногда необходимо обновить сразу несколько компьютеров (особенно во время новых выпусков Ubuntu.)
Есть ли способ, когда только один из моих машинам нужно загружать пакеты, а другие машины могут использовать первую машину, чтобы получить файлы? Это включает в себя настройку моего собственного локального зеркала? Или прокси-сервер? Или это можно сделать проще?
6 ответов
Я провел некоторые исследования по ряду решений и некоторые разработчики Ubuntu придумали конфигурацию прокси (на основе Squid) на 10.04 и позже. Она называется squid-deb-proxy. Для этого требуется только машина, выступающая в качестве сервера. В больших организациях обычно работают собственные полные зеркала, но для большинства людей достаточно зеркалирования по требованию.
Почему squid-deb-proxy?
- Нет редактирования файлов на стороне клиента.
- Используйте zeroconf, чтобы клиенты были "нулевой конфиг"
- Используйте существующее, твердое прокси-решение вместо написания нового утилиты.
- Легкая настройка для типичного администратора Linux.
Server Config
На машине, которую вы хотите использовать в качестве сервера, установите утилиту с:
sudo apt-get install squid-deb-proxy avahi-utils
Теперь запустите служебные биты:
sudo start squid-deb-proxy
И биты avahi (Вам это не понадобится, если вы на 12-ом компьютере. 04+):
sudo start squid-deb-proxy-avahi
Это установит прокси-сервер (который по умолчанию прослушивает порт 8000) и инструменты avahi, необходимые серверу для рекламы себя в вашей сети через zeroconf.
Client Config
На каждом из компьютеров , которые вы хотите использовать кэш (клиенты и сам сервер, чтобы он тоже мог использовать кэш), вам нужно установить утилиту клиентской стороны, которая будет автоматически искать сервер, нажмите здесь:
или через командную строку:
sudo apt-get install squid-deb-proxy-client
Optional: Для максимальной эффективности вы должны настроить одну машину на автоматическую загрузку обновлений, чтобы, когда она понадобится другим машинам, она уже была в кэше. Вы можете сделать это, перейдя в System->Administration->Update Manager, затем нажмите кнопку "Settings...", на вкладке Update установите автоматическую загрузку всех обновлений.
Caching 3rd Party Sources
По умолчанию кэш настроен только на кэширование официальных репозиториев Ubuntu. Для добавления их в список исходников необходимо добавить их по адресу /etc/squid-deb-proxy/mirror-dstdomain.acl. Здесь вы можете добавить ppa.launchpad.net или другие сервисы, которые вы можете использовать. После внесения изменений в этот файл, вы должны запустить sudo restart squid-deb-proxy, чтобы изменения вступили в силу.
Manual Config
Если по каким-то причинам вы не хотите использовать zeroconf (по сетевым причинам или что-то в этом роде), вы можете вручную настроить клиента на использование прокси-сервера, отредактировав /etc/apt/apt. conf и добавив следующую строфу, (замените 0.0.0.0 на IP адрес сервера):
Acquire {
Retries "0";
HTTP { Proxy "http://0.0.0.0:8000"; };
};
Firewall
В случае, если вы используете брандмауэр, 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-адреса частной сети и т.д.)
Confirming it Works
First tail the log on the server so you can look at it: 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.
Используя его
С этого момента все машины в вашей сети будут проверять кэш перед тем, как попасть во внешнюю сеть для получения пакетов. Если появятся новые пакеты, то первая машина загрузит их из сети, после чего последующие запросы на этот пакет будут поступать от сервера к клиентам.
TODO
Нам все еще нужно включить apt, чтобы просто использовать рекламируемый кэш в сети из коробки и по умолчанию, чтобы вам не нужно было устанавливать клиентскую часть. Нам также нужно исправить ошибку , из-за которой 403 deb не было в списке зеркал.
В небольших сетях (таких как дом/малый офис) я использовал apt-cacher-ng с хорошими результатами. Я не проверял последние версии, но я знаю, что он нуждается в тщательной настройке и сервера, и клиентов, и лучше всего подходит для клиентов, которые будут получать обновления только из вашей локальной сети.
Я пробовал решение на основе squid выше, но оно потребовало применения нескольких обходных путей и большей конфигурации клиента, чем мне хотелось бы, так что оно не кажется пока, как будто оно может заменить apt-cacher-ng в небольших установках.
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
Одно из самых простых решений - это настройка apt-proxy.
Читайте документацию по ubuntu здесь : https://help.ubuntu.com/community/AptProxy
Я предпочитаю настраивать локальное зеркало с помощью утилиты 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-cacher не самый простой в настройке и он не выдержит перезагрузки.
Установите squid-deb-proxy на сервер, squid-deb-proxy-клиент на клиентов. Он использует zeroconf Avahi, так что никаких настроек не требуется.
Если вы хотите кэшировать больше, чем просто debs, я бы не стал беспокоиться о Squid. Сервер трафика Apache Traffic Server - следующая большая вещь. http://trafficserver.readthedocs.org