> > deswegen gibt's ja die 3.1r0a oder wie die heisst, die ein Paar Tage > > nach dem Release peinlicherweise nachgeschoben wurde. > > 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)
> >>> Apt-proxy ist ja auch nicht explizit als transparenter Proxy > >>> entwickelt worden. > > eher als Cache, wie der Name es schon sagt => die Clients holen sich > > die Pakete *vom* apt-proxy, nicht *über* den apt-proxy > > Naja, darüber könnte man jetzt disktutieren. Eigentlich ist apt-proxy > ja eher ein http-mirror, der eben on-demand/on-the-fly Pakete > nachladen kann. Wenn es wirklich ein Proxy wäre, dann würde man sich > 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 ? (aber jetzt wird's wirklich zu philosophisch für mich) > Aber du hast natürlich recht: Durch den TCP-Redirect vergewaltige ich > die dahinterliegenden Mechnismen ein bißchen und ich kann nicht genau das wollte ich sagen > 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 > > ganz pragmatisch, wieso kannst Du nicht : > > foreach host (my domain) > > ssh host search&replace sources.list > > end > > Naja, dafür gibts mehrer Gründe: > > a) Ich bin nicht auf allen Rechnern Root ist natürlich ein Grund > 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. > d) Load-Balancing/Failover... ich könnte die Anfragen in der Firewall > auf mehere Proxies verteilen bzw. Umverteilen, wenn der Proxy mal > nicht geht. Im aktuellen Fall hat es gereicht, den TCP-Redirect in > der Firewall rauszunehmen und schon konnten alle 50 Rechner wieder > ihre Updates holen und ich konnte mir in Ruhe das Problem mit dem > Proxy ansehen. Hätte ich überall feste sources.list-Zeile in den > Rechnern gehabt, hätte ich jetzt ein mittleres Problem gehabt, wenn > der fest hinterlegte Proxy-Server nicht einsatzbereit ist. oder Du änderst den DNS eintrag für apt-proxy.my.domain, dass eine andere Maschine zeitweise übernimmt. > 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 ?) :-) > > machen, um die passende Zeile an die v2 anzupassen, sprich, ein > > Backend Name einfügen ? ist m.E. die einfachste Lösung neben apache- > > Umleitung und Python-Patching > > ich habe mir jetzt wieder den alten 1.3er-Apt-Proxy installiert und > der läuft wieder einwandfrei. Damit kann ich erstmal leben. oder so :-) Joel