freebsd-update hinter proxy mit auth

nevotheless

Member
Ahoy,

ich bin gerade mal wieder dabei ein wenig mit Freebsd herumzuspielen (zu Evaluationszwecken versteht sich) und stoße dabei mal wieder auf Proxy Konfigurations seltsamkeiten an.

Ich habe als von Linux kommender Freebsd neuling versucht direkt die ENV Vars HTTP_PROXY, HTTPS_PROXY und HTTP_PROXY_AUTH zu setzen, was bei "pkg" auch wie erwartet funktioniert. Möchte ich aber "freebsd-update" nutzen, was (laut debug message) auf /usr/libexec/phttpget zurückgreift, funktioniert hier nichts mehr da dieses kleine in C geschriebene Programm keine Proxy Behandlung enthält (Laut Source auf Github).

Zu meinem Entsetzen habe ich nun auch noch ein 8 Jahre altes Issue gefunden, was exakt die Thematik aufgreift, aber halt 8 Jahre lang unbearbeitet ist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153211

Da ich nicht glaube, dass ich der erste Mensch auf dem Mond bin (in diesem Falle wohl Freebsd Nutzer hinter einem Proxy) frage ich mich, ob ich hier irgendwas übersehe, das freebsd-update tool überhaupt gar nicht mehr genutzt wird und was überhaupt los ist :D

Würde mich sehr auf erleuchtende Beiträge freuen.
 
Jau, danke für die Antwort aber damit habe ich das Problem nicht.

Zurzeit habe ich bereits die Umgebungsvariablen in der cs.cshrc Datei eingetragen, die werden auch korrekt geladen und in der einen oder anderen Schreibweise von z.B. pkg (was meines wissens nach fetchlib nutzt) respektiert.

Schreibweise A
Bash:
setenv HTTP_PROXY http://proxyserver:port
setenv HTTPS_PROXY http://proxyserver:port
setenv HTTP_PROXY_AUTH "basic:*:username:password"

Schreibweise B
Bash:
setenv HTTP_PROXY http://username:password@proxyserver:port
setenv HTTPS_PROXY http://username:password@proxyserver:port

Bei Freebsd-update jedoch.... Je nachdem welche Schreibweise ich wähle, erhalte ich, dem code von phttpget nach, eine etwas andere Fehlermeldung, welche sich auf nicht Respektierung der Proxy Umgebungsvariablen Rückschließen lassen. (Was sich mit dem bereits 8 Jahre offenen Issue decken würde.)

Mich wunderte nur wie andere nutzer damit umgehen und ob ich da grundlegend was übersehe :D
 
Frag mal Colin Percival <cperciva@freebsd.org> direkt.
Soweit ich sehe, steht der immer noch als Autor in freebsd-update.sh und setzt dort PHTTPGET=/usr/libexec/phttpget.

Früher war freebsd-update ein eigener port, nun ist es Bestandteil des Systems. Vielleicht gibt es trotzdem die Möglichkeit, einen Ersatz für phttpget zu setzen.
 
Hi,

Bei Freebsd-update jedoch.... Je nachdem welche Schreibweise ich wähle, erhalte ich, dem code von phttpget nach, eine etwas andere Fehlermeldung, welche sich auf nicht Respektierung der Proxy Umgebungsvariablen Rückschließen lassen.

nach Überfliegen des Quelltextes denke ich, dass sowohl HTTP_PROXY als auch HTTP_PROXY_AUTH gesetzt sein müssen. Also deine Variante A. HTTPS_* kannst du weglassen, diese werden gar nicht ausgewertet.

In HTTP_PROXY darf nur der Host und Port drinstehen (führendes http:// wird übergangen).

Welche Fehlermeldung erhältst du denn genau?

Rob
 
Mit Schreibweise 2 erhalte ich folgendes

Bash:
~ # freebsd-update fetch --debug
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 12.0-RELEASE from update.FreeBSD.org...
latest.ssl                                             512  B 5165 kBps    00s
done.
Fetching metadata index...
fetch: http://update.FreeBSD.org/12.0-RELEASE/amd64/t/7961cd62a917d4964dd91afd0eadf2268151a187810382de71fdb70b0fdbd0bd: size of remote file is not known
7961cd62a917d4964dd91afd0eadf2268151a187810382         225  B 2935 kBps    00s
done.
Fetching 2 metadata files...
/usr/libexec/phttpget update.FreeBSD.org 12.0-RELEASE/amd64/m/59c0d6fa39c377858817e07090f84a926987d9a6ab5e28700569f814db9ba415.gz 12.0-RELEASE/amd64/m/b6cd2f212f25c30c7296b9222c2c98b56d6180f7c9708f214d835fb10742b19b.gz
phttpget: host = username, port = password@proxyserver:80: servname not supported for ai_socktype
failed.

Hier rechnet er einfach nicht mit der Angabe von Username und Passwort und parst dementsprechend den Servernamen nicht korrekt.

Mit Schreibweise 1

Bash:
~ # freebsd-update --debug fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 12.0-RELEASE from update.FreeBSD.org...
latest.ssl                                             512  B 5203 kBps    00s
done.
Fetching metadata index...
fetch: http://update.FreeBSD.org/12.0-RELEASE/amd64/t/9c9b7f0dd3b209c63cee2c28838d4e26d68091b1a53dc020d4ea05b98ca043ea: size of remote file is not known
9c9b7f0dd3b209c63cee2c28838d4e26d68091b1a53dc0         225  B 2412 kBps    00s
done.
Fetching 2 metadata files...
/usr/libexec/phttpget update.FreeBSD.org 12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz 12.0-RELEASE/amd64/m/7fd9b731453c9ad3707e657c26f738de93365b8b348807f5fbb7cf42fb46c4a5.gz
http://update.FreeBSD.org/12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz: 407 Error (ignored)
http://update.FreeBSD.org/12.0-RELEASE/amd64/m/7fd9b731453c9ad3707e657c26f738de93365b8b348807f5fbb7cf42fb46c4a5.gz: 407 Error (ignored)
failed.

Hier hätte ich gedacht dass es funktioniert, was es aber leider nicht tut.
 
Versuche doch mal (mit den korrekten Angaben und alles eine Zeile):

Code:
$ env HTTP_PROXY="http://proxyserver:port" HTTP_PROXY_AUTH="basic:*:username:password" 
/usr/libexec/phttpget update.FreeBSD.org 12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz

Und als Vergleich:

Code:
$ env HTTP_PROXY="http://proxyserver:port" HTTP_PROXY_AUTH="basic:*:username:password" 
fetch -v http://update.FreeBSD.org/12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz

Rob
 
Versuche doch mal (mit den korrekten Angaben und alles eine Zeile):

Code:
$ env HTTP_PROXY="http://proxyserver:port" HTTP_PROXY_AUTH="basic:*:username:password"
/usr/libexec/phttpget update.FreeBSD.org 12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz

Und als Vergleich:

Code:
$ env HTTP_PROXY="http://proxyserver:port" HTTP_PROXY_AUTH="basic:*:username:password"
fetch -v http://update.FreeBSD.org/12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz

Rob

Bei Beispiele schlagen fehl. Der phttpget Befehl verabschieded sich mit einem "failed to connect to proxyserver:port" und der fetch befehl zeigt mir an dass er keine Route zum Host findet, was dafür spricht dass die Proxyverbindung nicht zustande kommt.

@nevotheless
Deine Schreibweise B ist nicht korrekt!
Code:
export HTTP_PROXY_AUTH="basic:*:username:password"
export HTTP_PROXY=http://proxy:port

Verstehe ich nun nicht so ganz, dass ist doch der Ansatz von Schreibweise A. Also wie ich die HTTP_PROXY_AUTH Variable definiere. Schreibweise B ist die Variante wo ich die Credentials direkt in HTTP_PROXY mitgebe ohne eine HTTP_PROXY_AUTH Variable zu definieren
 
export - ist dann bash - oder?

Spätestens hier rächt es sich oftmals, wenn FreeBSD-Anfänger reflexartig die bash als system-Shell einstellen, weil sie es oftmals von Linux so kennen.

Die sh kennt dann plötzlich export - aber kein setenv, wie es in den dokus steht:-(
 
Danke für eure Hilfen, aber ja export hilft mir hier nicht da ich kein Bash nutze aber daran hapert es ja eigentlich auch nicht. Wenn ich die Umgebungsvariablen einsehe, sehe ich ja dass sie vorhanden und auch meiner Meinung nach, wie oben schonmal geposted, auch nicht falsch angegeben sind. Irgendwas anderes ist da im Busch aber ich werd' bislang nicht schlau daraus.
 
freebsd-update nutzt ja fetch
und man fetch(3) sagt ganz klar:
Code:
....
EXAMPLES
     To    access a proxy server on proxy.example.com port    8080, set the
     HTTP_PROXY    environment variable in    a manner similar to this:

       HTTP_PROXY=http://proxy.example.com:8080

     If    the proxy server requires authentication, there    are two    options    avail-
     able for passing the authentication data.    The first method is by using
     the proxy URL:

       HTTP_PROXY=http://<user>:<pwd>@proxy.example.com:8080

     The second    method is by using the HTTP_PROXY_AUTH environment variable:

       HTTP_PROXY=http://proxy.example.com:8080
       HTTP_PROXY_AUTH=basic:*:<user>:<pwd>
...

Und wenn das nun -warum auch immer- mit oder bei Deinem Proxy nicht funktioniert,
dann würde ich den einfach tunneln, bevor ich da nun unendlich viel Zeit und Energie
hier rein stecke;-)
 
Der phttpget Befehl verabschieded sich mit einem "failed to connect to proxyserver:port"
Das ist komisch, die Meldung (failed to connect) ist so im Quelltext nicht zu finden, ist das die originale vollständige Fehlermeldung?
Mal ganz doof gefragt: du ersetzt proxyserver und port aber schon mit den konkreten Angaben?

Rob
 
Das ist komisch, die Meldung (failed to connect) ist so im Quelltext nicht zu finden, ist das die originale vollständige Fehlermeldung?
Mal ganz doof gefragt: du ersetzt proxyserver und port aber schon mit den konkreten Angaben?

Rob
Ich bin mir nicht mehr ganz sicher wo ich die "failed to connect to proxyserver:port" her hatte, aber das war zu der Zeit als ich versucht habe die von Ihnen in diesem Beitrag enthaltenen Commandos zu testen. Was allerdings nicht funktioniert hat. Bzw. kam ich so nicht mal bis zum 407 Error.

Zurzeit habe ich ja die Umgebungsvariablen gesetzt. Und mittels Fetch kann ich auch ganz normal herunterladen. Sowohl per oben stehender Schreibweise A und Schreibweise B (also mit HTTP_PROXY_AUTH seperat und Authentifizierungskennung in HTTP_PROXY integriert) der download mittels phttpget funktioniert aber auf keine Art und Weise.

Ich kann, sofern fetch funktioniert (was es ja auch tut, da ich mit fetch und dem pkg tool alles mögliche herunterladen kann) ja davon ausgehen dass phttpget die Variable HTTP_PROXY_AUTH nicht respektiert, bzw. sie nicht korrekt handhabt, da ich ja einen 407 Fehler erhalte, den ich nicht bekommen würde wenn HTTP_PROXY auch einfach nicht respektiert werden würde.

---

Um kurz Zusammenzufassen:
  • Umgebungsvariablen werden korrekt gesetzt.
  • Download via Fetch funktioniert.
  • Download via phttpget funktioniert nicht
    • Fehler resultiert in 407 Error. HTTP_PROXY_AUTH wird also nicht korrekt gelesen oder gar nicht respektiert.
    • HTTP_PROXY wird respektiert, da sonst ein "hostname nor servname provided, or not known" fehler kommen würde.
    • HTTP_PROXY=http://username:password@proxyserver:port Schreibweise resultiert in "random" Socketfehler, da der Parser aufgrund des doppelt vorkommen des Doppelpunktes durcheinanderkommt > Unterstützt diese Schreibweise also grundsätzlich nicht.
Ich werde sonst mal den Autoren von phttpget, wie eingangs Vorgeschlagen, einmal kontaktieren. Danke soweit für eure Hilfsversuche.
 
Download via Fetch funktioniert.
Dann verstehe ich aber nicht, warum das Kommando bei dir nicht geklappt hat:

Code:
$ env HTTP_PROXY="http://proxyserver:port" HTTP_PROXY_AUTH="basic:*:username:password" \
fetch -v http://update.FreeBSD.org/12.0-RELEASE/amd64/m/369488997755ac12791fafe6984b83e6d6eeb31d94f7067c541171459921b225.gz

Rob
 
Ich habs nochmal mit env probiert, nun funktioniert das auch. Vermutlich habe ich mich da nur vertippt. Mit phttpget erhalte ich weiterhin auch mit dieser direkten Angabe der Umgebungsvariablen 407.
 
Habe das Problem tatsächlich gefunden. In phttpget.c ist die Funktion zum Encodieren des Username & Passwords in Base64 um einen gültigen Proxy-Authorization Header zu erstellen fehlerhaft. Dort gibt es ein Problem mit dem Filling (die komischen = am ende von Manchen Base64 Strings) das bei gewissen Längen von zu Base64 encodierenden Strings genutzt wird.

Interessanterweise tritt dieses Problem halt nur bei bestimmten Passwortlängen auf. Alle Username:Password kombinationen welche in der Länge ein mehrfaches von 3 ergeben funktionieren ohne Probleme. (Aufgrund des Fillings).

Als Beispiel:
Hey:Base64 sollte zu SGV5OkJhc2U2NA== werden.
phttpget macht aber daraus ein SGV5OkJhc2U2NAA= wodurch der Proxy-Authorization Header natürlich falsch befüllt wird.


Auch interessant: Ein solches Problem ist seit 10 Jahren bekannt :D

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129431 hier habe ich mal meinen Senf dazu gegeben und den Entwickler darauf hingewiesen.
 
Hi nevotheless, die Welt ist klein. Ich habe den Bugreport vor "einiger Zeit" eröffnet.
Leider wurde der nicht so richtig ernst genommen/bearbeitet. Wie auch immer.
Ich habe seinerzeit einen weiteren Squid im Netz installiert, der als nachgelagerter Proxy bestimmten Maschinen ohne User und Passwort Zugang zum Internet gegeben hat. Der Squid hat nach oben zu seinem Parent keine Probleme, wenn der Parent Usernamen und Passwort benötigt bzw. voraussetzt.
Das ist nicht wirklich schön und leider etwas aufwändiger. Aber es funktioniert technisch sehr gut.

Grüße
Mario
 
Hio Mario, jau sowas hab ich mir auch schon gedacht, wäre für uns eigentlich auch nicht verkehrt damit wir nicht jeden Client einzeln anpassen müssen aber hey, unser AWX Server soll ja auch was zu tun haben ;D
 
... man könnte jetzt natürlich auch aufgrund Marios Forschungen - die Passwörter in ihrer Länge so anpassen, dass Stringlänge von User+Passwd ein ganzzahliges Viefaches von 3 wird;-)
 
Zurück
Oben