Diese Tage hatte ich ein ganz verzwicktes Problem zu lösen. Eigentlich wollte ich nur ein Treiber-Repository für die proprietären nVidia-Treiber in den SUSE Linux Enterprise Desktop einbinden damit ich von dort installieren kann, aber irgendwie wollte das nicht funktionieren.

Um das Problem zu verstehen müsst ihr wissen, dass wir in der Firma nur via Proxy in die große weite Welt des Internet rauskommen. Und eben dieser Proxy lieferte beim Versuch das zu tun immer einen „HTTP 400“ (Bad request) zurück.

Ich habe dann in meiner Verzweiflung mal den Bugzilla von SUSE nach Proxy-Problemen mit der libzypp durchforstet und auch einen gefunden, der sich auch über „malformed requests“ auslies, aber geschlossen war. Also habe ich mir die neueste Version der libzypp geholt und es half aber trotzdem nix.

Beim Anschauen der Requests via strace sah dieser in etwa so aus:

GET ftp://anonymous:yast@9.11.7@download.nvidia.com/…/repomd.xml;type=i

Versuche mich via telnet mit dem Proxy zu unterhalten zeigten dann schnell, dass der Proxy zunächst von den beiden „@“ im Request verwirrt wird, der erste sollte nämlich mit „%40“ ersetzt werden. Die Stelle wo das in der Bibliothek so zusammengebaut wird war schnell gefunden und gestern abend hatte ich dann noch die glorreiche Idee, dass man ja in der URL auch einen anderen usernamen bzw. ein anderes Passwort für den anonymous User vorgeben könnte. Also habe ich das mal geändert, so dass das FTP-Passwort keinen Klammeraffen mehr enthält.

Der Erfolg war, dass aus den ursprünglichen „HTTP 400“-Meldungen des Proxy nun „HTTP 404“ (not found) wurden. Ein Blick auf das Antwortpaket zeigte dann, dass hier der Suffix „;type=i“ zum Dateinamen hinzugerechnet wurde und so eine Datei gibts natürlich nicht.

Zuerst dachte ich, dass dieser Suffix Nonsense wäre, aber ein Kollege mit dem ich das diskutierte merkte dann an, dass bei FTP-URLs das durchaus seine Daseinsberechtigung hat. Ich habe dann mal versucht, diese FTP-URL via wget oder curl zu holen, klappt mit meinem Proxy problemlos. Ein Mitschnitt des Datenverkehrs mit dem Proxy zeigt aber, dass der Suffix mit der type-Angabe hier im GET-Request nicht mehr auftaucht, das wird also von curl oder wget rausgefiltert wenn sie sich mit dem Proxy unterhalten.

Trotzdem glaubte ich mittlerweile schon nicht mehr an einen echten Fehler in der libzypper, denn wenn so was im Enterprise-Umfeld eingesetzt wird dann werden die Proxy-Funktionen doch wohl häufiger benutzt worden und so ein Fehler wäre aufgefallen. Nichtsdestoweniger habe ich natürlich einen Bug in Bugzilla aufgemacht um dort das Problem zu diskutieren.

Um den Proxy auszuschließen habe ich dann auf einem Testgerät mal den squid Proxy installiert der bei vielen Linux-Distributionen dabei ist. Ein wenig konfiguriert und schon konnte ich von meinem Labor-FTP-Server Dateien holen, auch dann wenn im GET-Request am Ende der URL der type-Suffix stand. Damit war klar, dass Nutzer die einen Squid-Proxy haben dieses Problem das ich hatte womöglich gar nicht nachvollziehen können, was dann auch der Bearbeiter des Bugs im Bugzilla bestätigte.

Also nächster Versuch, Proxy-Server kann man ja kaskadieren und so habe ich meinen Firmen-Proxy als „parent“ für meinen Squid konfiguriert. Das ging zunächst nur mit HTTP, FTP führte dazu, dass der Squid sich immer direkt verbinden will, aber das kann man mit ein paar Zeilen in der Konfig abstellen:

Damit geht der Proxy bei FTP-Anfragen zum parent-Proxy. Soweit so gut, bzw. schlecht, denn in diesem Fall wird der GET Request den er bekommen hat einfach 1:1 durchgereicht. Und damit habe ich dann wieder den „HTTP 400“ weil der Firmen-Proxy eben den Request nicht versteht.

Das Gute an Squid ist aber, dass man URLs im Proxy auch umschreiben lassen kann.Ich habe also folgende Zeilen für den URL-Rewrite eingebaut:

Die Umschreiberei übernimmt ein kleines Perl-Skript welches bei FTP-URLs die einen Typ-Suffix haben genau diesen einfach entfernt:

Die eigentliche Arbeit macht hierbei die Regex. Und mit diesem Skript auf dem Squid klappt dann auch das holen der Repository-Daten mit Yast bzw. zypper.

Morgen werde ich vielleicht noch einen Rewrite für den Klammeraffen im FTP-Passwort einbauen und testen. Und versuchen rauszufinden, welche Proxy-Software in unserer Firma läuft, Squid scheint es jedenfalls nicht zu sein.

[ratings]