Hallo,
nach einem Jahr Version7 haben wir heute den proxy endlich scharf gestellt. Funktioniert mit dem logon.sh wunderbar im linuxclient.
Nur haben wir auch Notebooks und Lernsticks im Einsatz, d.h diese Geräte verlassen auch mal das Schulnetz. Und da sind die Proxyeinstellungen natürlich fehl am Platz.
Wie handhabt ihr das? Irgendwie müsste man die Proxyeinstellungen, wenn der server nicht erreichbar ist, wieder deaktivieren …
Viele Grüße, Helge
Hallo,
die Dokumentation scheint nicht für alle Linuxe zu passen. Bei Debian BUllseye führt
PROXY_HOST=http://firewall.$PROXY_DOMAIN
zu dem Eintrag in env mit http://http://firewal...
Es funktioniert bei uns erst mit
PROXY_HOST=firewall.$PROXY_DOMAIN
Das kann man z.B. mit
curl http://google.de
testen. (EDIT: curl meint aber dann sich authentifizieren zu müssen). Firefox geht auch mit den falschen env-Einträgen.
VG Helge
PS: Zum eigentlichen Thema: wir probieren gerade ein logoff-script zu erstellen.
das Skript logoff.sh ist beim LInuxclient gar nicht implementiert. Mein Kollege aht auf github ein issue dazu geschrieben.
Hallo,
wie ich grade auch auf Github geschrieben habe, gibt es unter Linux kein logoff script. Das liegt daran, dass es keinen einfachen Weg zu geben scheint, um vor dem Logout ein Script im Userkontext auszuführen.
Ich verstehe aber auch nicht, was ihr damit machen wollt. Wenn ihr den Proxy nur unter bestimmten Bedingungen aktivieren möchtet, baut einfach im logon Script eine Bedingung ein.
VG,
Dorian
Lehrer und Schüler haben Notebooks bzw. Lernsticks von der Schule erhalten , die im Schulnetz gestartet werden. Also wird bei diesen der proxy über das logon-script aktiviert.
Jetzt gehen die nach Hause und starten dort ihre Geräte und dann ist der Proxy immernoch aktiv. D.h. sie kommen dort nicht mehr ins Internet.
Deshalb war unser erster Gedanke über ein logoff script dwn Proxy wieder zu deaktivieren.
Jetzt überlegen wir, wie es anders geht.
Anscheinend sind wir die Einzigen mit diesem usecase.
LG Helge
Achso, also es gibt beim Logon keine Verbindung zum Server und dadurch auch kein Serverseitiges logon, verstehe…
In dem Fall könnt ihr ein lokales Logon Script benutzen, um die Einstellungen zurückzusetzen:
VG,
Dorian
Hallo,
es gibt Erweiterungen für Firefox um einfach Proxys um zu schalten
(klar: das ist nicht der Systemproxy: aber wenigstens surfen geht dann
wieder)
LG
Holger
Hallo,
ja, das ist kein Use-Case für Anmeldeskripte, weil es dafür eine andere Lösung gibt. Einfach Proxy Auto-Config – Wikipedia nutzen und auf das skriptbasierte umschalten verzichten.
Das OS bzw. die Browser schauen, ob die URL zum Proxy-Skript abrufbar ist, wenn ja, wird das JavaScript darin ausgewertet, die IP und Port des Proxy-Servers liefert. Ist die URL nicht abrufbar, wird nix ausgewertet und kein Proxy genutzt.
MfG Buster
Hallo,
wir haben nun folgende Lösung umgesetzt:
Auf dem Server wird in sysstart.sh nun eine Datei „10_proxy.sh“ nach /etc/linuxmuster-linuxclient7/onLogin.d/ kopiert. In dieser wird erst geschaut ob der Server erreichbar ist und je nachdem dann die Proxy Einstellungen gesetzt und eben aktiv abgestellt.
Aktueller Stand ist: /etc/linuxmuster-linuxclient7/onLogin.d/10_proxy.sh wird ausgeführt, wenn:
leider wird das Script aber ignoriert, wenn man in einem „fremden“ Netz ist. Das betrifft auch alle 00_example.sh scripte in den Hook-Ordnern, bis auf den onBoot.d-Hook-Ordner. Das lässt sich gut mit einer Suche nach 00_example.sh in journalctl nachvollziehen.
@dorian Danke für die Tipps, hättest Du hier auch einen?
Hier das Script:
#!/bin/bash
echo "Setting Proxy ..."
if musterstick-check-in-school; then
# We are in school so set proxy settings...
PROXY_DOMAIN=merian.lan
PROXY_HOST=firewall.$PROXY_DOMAIN
PROXY_PORT=3128
# set proxy via env (for Firefox)
lmn-export no_proxy=127.0.0.0/8,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,localhost,.local,.$PROXY_DOMAIN
lmn-export http_proxy=$PROXY_HOST:$PROXY_PORT
lmn-export ftp_proxy=$PROXY_HOST:$PROXY_PORT
lmn-export https_proxy=$PROXY_HOST:$PROXY_PORT
# set proxy gconf (for Chrome)
gsettings set org.gnome.system.proxy ignore-hosts "['127.0.0.0/8','10.0.0.0/8','192.168.0.0/16','127.0.0/12','localhost','.local','.$PROXY_DOMAIN']"
gsettings set org.gnome.system.proxy mode "manual"
gsettings set org.gnome.system.proxy.http port "$PROXY_PORT"
gsettings set org.gnome.system.proxy.http host "$PROXY_HOST"
gsettings set org.gnome.system.proxy.https port "$PROXY_PORT"
gsettings set org.gnome.system.proxy.https host "$PROXY_HOST"
gsettings set org.gnome.system.proxy.ftp port "$PROXY_PORT"
gsettings set org.gnome.system.proxy.ftp host "$PROXY_HOST"
echo "### Enabled proxy settings for school"
else
# unset proxy via env
lmn-unset no_proxy
lmn-unset http_proxy
lmn-unset ftp_proxy
lmn-unset https_proxy
# unset proxy gconf (for Chrome)
gsettings set org.gnome.system.proxy mode "none"
echo "### Disabled proxy settings for school"
fi
exit 0
Hmm, das klingt nach einem Bug. Muss ich mir aber genauer anschauen.
Hallo Zusammen!
Ich hab mal die Abfrage nach dem Server musterstick-check-in-school konkretisiert:
#!/bin/bash
echo "Setting Proxy ..."
if [ "`ping -c 1 -t 1 SERVERIP &> /dev/null`" ]
then
PROXY_DOMAIN=DOMAINNAME (z.B. "schule.de")
...Damit scheint /etc/linuxmuster-linuxclient7/onLogin.d/10_proxy.sh bei uns den proxy aus der Systemeinstellung (env) zu entfernen bzw. zu setzen.
Danke dafür.
Was mich aber überrascht ist, dass ihr kein Problem mit der Zeit des Anmeldeprozesses zu haben scheint.
Wenn die Rechner bei uns mit einem fremden Netz verbunden sind (z.B. per WLAN zu Hause), dann warten sie beim Booten („A Start job is running for linuxmuster: switch local and remote home depending on ad server connection“) und bei der Anmeldung lange Zeit auf eine Antwort vom Server und dadurch dauert der Anmeldeprozess seeeehr lange (>> 15 Min.).
Ich hatte mal mit Dorian darüber gesprochen, wo eine entsprechende Abfrage rein muss, bin aber seither nicht dazu gekommen. Und jetzt finde ich meine Notizen nicht mehr. 
Hat da jemand eine Idee zu?
Gruß - Rainer
Oh doch! Die von dir beschriebenen Probleme haben wir auch. Zu einem Teilproblem gibt es auf github auch ein issue.
Wir hatten auch mal einen Timeout eingebaut. Aber wenn ich mich recht erinnere, haben wir ihn wegen dem eben genannten Script in login.d wieder rausgenommen.
Die Ursache dieser Probleme (die ich nicht wirklich durchschaue) war damit ja auch nicht behoben.
LG Helge
Hi,
die Timeout Probleme liegen wahrscheinlich daran, dass der Rechner beim Boot und Login versucht, ein Kerberos Ticket zu holen und das Sysvol einzuhängen. Ist der Rechner offline, geht es sofort schief, ist er aber in einem anderen Netz, gehen die Pakete ins Nichts, kommen nich zurück und er wartet ewig auf eine Antwort.
Ich fixe das, wenn ich die Zeit finde. Bin momentan sehr eingespannt mit Uni, Klausuren, Training und Wettkämpfen.
VG,
Dorian
@dorian Ich wünsche Dir viel Erfolg, bei Allem was du da vorhast!
LG Helge
Hallo,
@Buster ja, das ist natürlich auch ein Ansatz.
Die beste Anleitung und Erklärung dazu habe ich bei gentoo gefunden. Incl. Warnhinweis: Das sollte man im WLAN nur verwenden, wenn den Geräten nicht erlaubt ist, sich zu sehen. Sonst ist die man in the middle Attacke vermutlich nicht so schwer zu bewerkstellingen.
Für die FestPCs und zum „erstmal vertraut machen“ finde ich die Lösung mit den Anmeldeskripten nicht verkehrt.
Übrigens verwendet unser aktueller Firefox-ESR die Einstellungen von Gnome und nicht mehr die Umgebungsvariablen.
VG, Helge
Hallo,
wir haben hoffentlich eine Lösung für dieses Problem gefunden, nachzulesen hier:
Viele Grüße