Heiko Schlittermann wrote:
Die DU brauchst, ok. der TO hat aber bereits 20 Debian-Rechner im Einsatz. D. h. er installiert öfter mal einen Debian-Rechner. Mit einem Mirrior spart das Zeit (unser Mirror liegt im Gigabit-Netz) und traffic nach aussen. Zumal dieser auch noch Untrust-Leitung unabhängig installiert werden kann. Wie konfiguriert ihr euren Squid, wann verlieren die .deb die Gültigkeit im Cache? Wie stellt ihr sicher, dass ein manuelles update eines Paketes im Cache erfolgen kann? Wie kann ich Pakete im Squid zurück stellen lassen? Klar geht das bei den Clients, aber das will ich einmal tun, nicht 20 mal. Zumal ich noch den Vorteil habe, selbst gebaute Pakete besser verteilen zu können.Björn Meier <bjoern.meier@googlemail.com> (Do 28 Mai 2009 14:46:11 CEST):Florian Zagler wrote:Die enfachste und beste dürfte wohl ein entsprechend konfigurierter Squid sein. Das macht am wenigsten Arbeit und funktioniert hervorragend - ich habs auch so im Einsatz. Das ist eine "Install, configure, test and forget"-Lösung.WTF? Du installierst lieber einen großen Proxy - den man nicht eben so mal zwischendurch (zumindest NICHT wenn man es richtig machen will) konfiguriert, anstatt ein popliges Script auszuführen, dieses dann in Cron einzufügen?Extra einen lokalen Spiegel aufsetzen wär mir dafür eindeutig zuviel Arbeit.Auch ich nehme da gerne den Squid - der ist schnell installiert und die 3..4 angepassten Zeilen sind ziemlich schnell erledigt. Und ich muß mir einen lokalen Mirror von Dingen anlegen, die ich nicht brauche.
Ich würde mich freuen, wenn jemand mir die wirklichen Vorteile nennen könnte, den Squid gegenüber einem Mirror hat. Plattenplatz kann es nicht sein, da ich bei einem Mirror mit einem (fast) konstantem Wert rechnen kann. Während bei einem Cache-Proxy das variiert (Wenn ich den schon habe, kann ich ja gleich als Web-cache und /oder cache für windows-updates (habe ich auch schon eine anleitung für gesehen *grusel*) nutzen).
Ein immer vnoch leicht verwirrter Björn