Re: apt-proxy-v2 als transparanter Proxy
Hallo Joel,
On Sun, 3 Jul 2005, Joel HATSCH wrote:
naja, hier scheint apt-setup von Sarge noch einen Bug zu haben, denn
wenn ich mir unter Sarge mit apt-setup eine frische sources.list
erstellen lasse, dann steht das "testing" drin. Ich nehme an, da hat
jemand vergessen bei der Übernahme von testing -> unstable das
entsprechende Template anzupassen.
ist doch wohl reichlich diskutiert worden, oder ?
sorry, ich lese diese Liste erst seit gestern. Aber mir war so, als ob ich
auf einem News-Ticker etwas ensprechendes gelesen hätte.
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?
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.
naja... vielleicht wird das ja noch. Mit alten 1er-Apt-Proxy hat's ja
auch geklappt.
was aber nicht bedeutet, dass es dafür entwickelt wurde !
Du schreibst, es wird wohl ein Bug in v2 sein. Warum war's nicht ein
Bug in v1, der dir sowas erlaubt hat, und die haben's in der v2
korrigiert ?
Das ist eben Ansichtssache... wenn eine Funktionalität in einer neuen
Version fehlt, die in einer alten Version noch da war, dann liegt es nahe,
einen Bug zu vermuten.
Aber du hast natürlich recht: Durch den TCP-Redirect vergewaltige ich die
dahinterliegenden Mechnismen ein bißchen und ich kann nicht 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.
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
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.
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.
d) Faulheit^H^H^H^H^H^Hease of use :-)
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.
Gruß,
Jörn
Reply to: