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ć?
Odpowiedzi:
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.
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.
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.
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.
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"; };
};
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.)
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.
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.
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.confpliku pod /etc/apt. Istnieje jednak mnóstwo plików z ustawieniami poniżej /etc/apt/apt.conf.d. Wyobrażam sobie, że powinniśmy teraz utworzyć tam plik?
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
squid-deb-proxyi squid-deb-proxy-client: zeroconf rzeczywiście oznacza zerową konfigurację na klientach, co jest niezwykle przydatne dla nomadycznych użytkowników - a jeśli serwer nie odpowiada, klient domyślnie pobiera bezpośrednio.
pbuilder. To zadziałało po wyjęciu z pudełka. Wygląda też na to, że istnieje wsparcie dla zeroconf(w 2016 r.), Ale nie mogłem (jeszcze) sprawić, by działało to po mojej stronie.
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