Re: apt-proxy-v2 als transparanter Proxy
> > 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
Reply to: