Re: apt-proxy-v2 als transparanter Proxy
On Sun, 3 Jul 2005, Joel HATSCH wrote:
Was mich nur wundert: Ich hatte mir nicht die 3.1 installiert,
sondern ein Distupgrade von Woody auf Sarge gemacht. Außerdem würde
ich erwarten, dass dieser Bug bei einem "apt-get upgrade" gefixed
werden würde, wenn es bereits ein gepatchtes Paket dafür gibt. Stimmt
mit meinem System etwas nicht, oder liegts wirklich daran, daß der
notwendige Patch noch nicht über die FTP-Mirrors released wurde?
gute Frage, kann sie leider nciht beantworten, da ich denselben Weg
gegangen bin (und bei mir sind nur die apt-proxy backends in der
sources.list)
Meine Vermutung ist ja, dass genau aus diesem Grund noch nicht daran
gedacht wurde, ein gepatches apt-setup-Paket zu releasen... Der Fehler ist
schlichtweg nur bei Leuten aufgetreten, die from scratch mit ner CD
installiert haben. Alle anderen hatten ja schon eine sources.list, die sie
vor dem Upgrade entsprechend händisch ändern mussten. Mir ist das auch nur
durch Zufall aufgefallen, als ich auf einer Kiste wegen den kaputten
apt-proxies an den sources.list gedreht hatte, und mir mit apt-setup eine
frische sources.list erstellen wollte.
die Pakete sehr wohl *ÜBER* apt-proxy holen. Rein technisch gesehen
ist der apt-proxy aber ein HTTP-Server und kein Proxy.
streng genommen, ja.
naja, squid wird ja auch proxy genannt, und tut genau dasselbe, oder ?
Ne, Squid fungiert nicht als HTTP-Webserver für die im Cache liegenden
Dateien. Es sei denn, man konfiguriert ihn als volltransparenten Proxy.
Dann verhält er sich wirklich wie ein Webserver und kann als solche (ohne
Proxy-Config auf der Clientseite) angesprochen werden. Aber bei einem
klassischen Proxy übermittelt der Client dem Proxy nur die URL, die er für
ihn stellvertreten holen soll.
(aber jetzt wird's wirklich zu philosophisch für mich)
aeh... ja und bringt uns auch nicht wirklich weiter. .-)
erwarten, dass das 100%ig klappt. Ich ging eben davon aus, dass es
common-practice wäre, die HTTP-Anfragen an die Debian-Mirrors auf den
Proxy umzuleiten; eben weil es eigentlich so naheliegend ist.
nichdestotrotz könntest Du ja mal entweder den Maintainer oder
zumindest die apt-proxy Mailingliste fragen, ob es eine elegante Lösung
zu deinem Problem gibt
ok, kann ich versuchen. Ich befürchte aber, dass da nur noch wenig gemacht
wird, nachdem der Programmierer von apt-proxy-v2 letztes Jahr bei einem
Verkehrsunfall gestorben ist.
b) Wenn ich einen Rechner von der Netinstall-CD neu aufsetze, dann
müsste ich da auch erst noch die sources.list ändern. Bzw. ich müsste
allen Verantworlichen in unserem RZ mitteilen, wie sie bei der
Installation vorzugehen haben.
naja... könnte noch machbar sein.
Klar, ist aber mit Mehraufwand verbunden. Man muss ne Doku schreiben und
muss dann ggf. noch Support leisten, wenn die Leute mit der Doku nicht
klarkommen. Und dann wirds garantiert auch Leute geben, die einfach zu
faul sind, ihre sources.list auf den Proxy umzustellen und dadurch dann
wieder unnötigen Traffic verursachen. Da ist ne transparente Lösung, bei
der auf der Endanwender-Seite kein Eingriff notwendig ist, wirklich
stressfreier.
oder Du änderst den DNS eintrag für apt-proxy.my.domain, dass eine
andere Maschine zeitweise übernimmt.
ja, vorausgestzt die Leute halten sich an die Vorgaben und tragen den
richtigen Hostnamen ein. Ist jedenfalls ne weitere Fehlerquelle.
d) Faulheit^H^H^H^H^H^Hease of use :-)
ok... da fehlen mir die Gegenargumente ! (obwohl : wieviel zeit hast Du
jetzt schon damit verloren^H^H^Hverbracht ?) :-)
Ich habe mir angewöhnt den Dingen einmal richtig auf den Grund zu gehen,
aber dafür wiederkehrende Zeitverschwendungen so gut es geht zu
eliminieren. Will heissen: Lieber beschäftige ich mich einmal richtig mit
Apt-Proxie und bau mir dann eine Lösung, bei der ich mich dann später
nicht mit den Admins rumschlagen muss, die mit dem Abändern der
sources.list nicht klarkommen.
Gruß,
Jörn
Reply to: