Najlepszy sposób na buforowanie apt pobrań w sieci LAN?

Mam wiele komputerów Ubuntu w domu i dość wolne połączenie internetowe, a czasami wiele maszyn wymaga aktualizacji na raz (szczególnie podczas nowych wersji Ubuntu).

Czy istnieje sposób, w jaki tylko jedna z moich maszyn musi pobierać pakiety, a pozostałe maszyny mogą korzystać z pierwszej maszyny, aby uzyskać debaty? Czy wiąże się to z utworzeniem własnego lokalnego serwera lustrzanego? Lub serwer proxy? Czy można to uprościć?

Przeszukałem kilka rozwiązań, a niektórzy programiści Ubuntu wymyślili konfigurację proxy (opartą na Squid) dla wersji 10.04 i późniejszych. To się nazywa squid-deb-proxy. Wymaga tylko komputera działającego jako serwer. Duże organizacje zwykle prowadzą własne pełne kopie lustrzane, ale dla większości ludzi wystarczy kopia lustrzana na żądanie.

Dlaczego Squid-Deb-proxy?

• Brak edycji plików po stronie klienta.
• Użyj zeroconf, aby klienci mieli „zerową konfigurację”
• Użyj istniejącego, solidnego rozwiązania proxy zamiast pisać nowe narzędzie.
• Łatwy w konfiguracji dla typowego administratora systemu Linux.

Konfiguracja serwera

Na komputerze, który ma działać jako serwer, zainstaluj narzędzie za pomocą:

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

Teraz uruchom bity usługi:

 sudo start squid-deb-proxy

I bity avahi (Nie potrzebujesz tego, jeśli masz 12.04+):

 sudo start squid-deb-proxy-avahi

Spowoduje to zainstalowanie serwera proxy (który domyślnie nasłuchuje na porcie 8000) oraz narzędzi avahi potrzebnych do tego, aby serwer zareklamował się w sieci za pośrednictwem zeroconf.

Konfiguracja klienta

Na każdym komputerze , z którego chcesz korzystać z pamięci podręcznej (klienci i sam serwer, aby również mógł korzystać z pamięci podręcznej), musisz zainstalować narzędzie po stronie klienta, które pozwoli nam automatycznie wyszukać serwer, niech klikną tutaj :

lub za pomocą wiersza poleceń:

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

Opcjonalnie : Aby uzyskać maksymalną wydajność, należy ustawić jeden komputer na automatyczne pobieranie aktualizacji, aby gdy inne maszyny tego potrzebowały, znajdował się już w pamięci podręcznej. Możesz to zrobić, przechodząc do System-> Administracja-> Menedżer aktualizacji, a następnie kliknij przycisk „Ustawienia ...”, w zakładce Aktualizacja ustaw automatyczne pobieranie wszystkich aktualizacji.

Buforowanie źródeł zewnętrznych

Domyślnie pamięć podręczna jest skonfigurowana do buforowania tylko oficjalnych repozytoriów Ubuntu. Aby dodać więcej, musisz dodać je do listy źródeł w /etc/squid-deb-proxy/mirror-dstdomain.acl. Tutaj możesz dodać ppa.launchpad.net lub inne usługi, z których możesz skorzystać. Po wprowadzeniu zmian w tym pliku należy uruchomić sudo restart squid-deb-proxy, aby zmiany były skuteczne.

Konfiguracja ręczna

Jeśli z jakiegoś powodu nie chcesz używać zeroconf (z powodów sieciowych itp.), Możesz ręcznie ustawić klienta do korzystania z proxy, edytując /etc/apt/apt.confi dodając następującą sekcję (zamień 0.0.0.0 na adres IP serwera ):

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

Zapora ogniowa

W przypadku korzystania z zapory, avahi używa adresu 5353 w odniesieniu do adresów 224.0.0.0/4 i wymaga reguły, która wygląda następująco:

# 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

Następnie należy otworzyć port TCP 8000 dla faktycznej komunikacji przez proxy. Coś mniej więcej takiego:

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

Te zasady mają ci tylko pomóc. Prawdopodobnie nie będą pasować do twojej konfiguracji jeden do jednego. (tj. zły interfejs, złe adresy IP sieci prywatnej itp.)

Potwierdzenie, że działa

Najpierw sprawdź dziennik na serwerze, abyś mógł na niego spojrzeć: tail -F /var/log/squid-deb-proxy/access.loga następnie uruchom aktualizację na dowolnym komputerze, na którym jest zainstalowany klient; dziennik powinien zacząć się przewijać z następującymi wpisami:

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

Co oznacza, że ​​klienci widzą pamięć podręczną, ale jej brakuje, co jest oczekiwane, ponieważ niczego jeszcze nie buforował. Każde kolejne uruchomienie powinno pokazywać się jako TCP_HIT. Możesz znaleźć same pliki pamięci podręcznej kałamarnic /var/cache/squid-deb-proxy.

Użyj tego

Od tego momentu wszystkie maszyny w twojej sieci sprawdzą pamięć podręczną przed wejściem do sieci zewnętrznej w celu pobrania pakietów. Jeśli dostępne są nowe pakiety, pierwsza maszyna pobierze je z sieci, po czym kolejne żądania dotyczące tego pakietu będą wysyłane z serwera do klientów.

DO ZROBIENIA

Nadal musimy włączyć apt, aby po prostu używał reklamowanej pamięci podręcznej w sieci po wyjęciu z pudełka i domyślnie nie trzeba instalować klienta. Musimy także naprawić błąd polegający na tym, że deb 403 nie znajduje się na liście kopii lustrzanych.

apt-cacher-ngjest dla mnie odpowiedzią - nie spotkałem żadnych problemów w małych środowiskach (ok. 20 klientów), więc przypuszczam, że problemy, o których wspominały @MagicFab, zostały rozwiązane w aktualnej wersji (zainstalowanej na Ubuntu 10.04 i 10.10). Serwer nie wymaga konfiguracji i musisz tylko poinstruować klientów, aby używali serwera jako serwera proxy menedżera pakietów.

Serwer jest całkowicie zainstalowany i skonfigurowany przez zainstalowanie apt-cacher-ngpakietu.

Klientów należy skonfigurować, konfigurując serwer proxy APT - dodając plik /etc/apt/apt.conf.d/01proxyzawierający ten plik (gdzie „twój-apt-server” to nazwa lub adres IP twojego serwera):

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

Gotowe - teraz pakiety będą buforowane przez serwer, bez względu na to, jakich źródeł używasz lub jakiej wersji systemu posiadasz (np. Serwer 10.04 może być używany przez klientów 9.10, 10.04 i 11.04 bez żadnych problemów lub konfliktów).

Jeśli masz laptop (y) klienckie, które wędrują między sieciami, staje się to trochę bardziej złożone - stworzyłem skrypt, który ustawia właściwy serwer proxy w zależności od adresu sieciowego; skrypt jest wykonywalny i działa w trybie /etc/network/if-up.d/apt-proxy. Po otrzymaniu adresu IPv4 z serwera DHCP skrypt ustawi odpowiedni serwer apt-cacher dla odpowiedniej sieci:

#!/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

Jednym z najprostszych rozwiązań jest skonfigurowanie apt-proxy.

Przeczytaj dokumentację ubuntu tutaj: https://help.ubuntu.com/community/AptProxy

Zdecydowanie wolę skonfigurować lokalne dublowanie za pomocą tego debmirrornarzędzia.

Oto przykładowa inkantacja.

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

Uruchamiam to mniej więcej raz w tygodniu i używam go jako podstawy do ustanowienia jednego lub więcej „poziomów poprawek”. Na przykład...

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

To tworzy połączoną kopię drzewa (zajmuje prawie zero miejsca na dysku), którą mogę skierować na każdy z moich lokalnych serwerów w apt sources.list

W małych sieciach (takich jak dom / małe biuro) korzystałem z apt-cacher-ng z dobrymi wynikami. Nie sprawdzałem najnowszych wersji, ale wiem, że wymaga starannej konfiguracji zarówno serwera, jak i klientów, i najlepiej nadaje się dla klientów, którzy będą otrzymywać aktualizacje tylko z sieci lokalnej.

Próbowałem kałamarnicę rozwiązanie oparte powyżej, ale to wymaga stosowania kilku obejścia i konfiguracji klienta więcej niż chciałbym, żeby nie czuć się jeszcze jak to mogło zastąpić apt-Cacher-ng w małych konfiguracjach.

apt-cacher nie był najłatwiejszy do skonfigurowania i nie przetrwa aktualizacji.

Zainstaluj squid-deb-proxyna serwerze, squid-deb-proxy-clientna klientach. Używa zeroconf Avahi, więc nie jest wymagana konfiguracja.

Jeśli chcesz buforować coś więcej niż tylko debaty, nie zawracałbym sobie głowy Squidem. Serwer ruchu Apache to kolejna wielka rzecz. http://trafficserver.readthedocs.org