@roesslerrr und ich haben die ausgezeichnete Vorarbeit von @thomas aufgegriffen und am vergangenen Wochenende einen „Linux-Client-Projekttag“ gemacht.
Das linuxmuster-client-adsso Paket wurde dabei um die bislang fehlende Profilfunktionalität erweitert.
Die Dokumentation im Github Wiki wurde entsprechend angepasst:
Eckpunkte:
Alles wie bisher: lokaler Vorlagenbenutzer, dessen Profil an die AD User kopiert wird.
Es gibt nur noch ein Paket, die Aufteilung in shares, profile und auth fällt weg.
Anpassungen beim Login über Skripte möglich wie bisher (Einstellungen auf Server, Links). Dabei haben wir die wesentliche Syntax der Konfigurationsdateien beibehalten.
Ein direkt vom Server gemountetes Homeverzeichnis und die gecachte Anmeldung wird vom Profilmechanismus derzeit nicht unterstützt.
Man kann sich nicht mehr direkt nach dem Herunterladen eines Cloops aus dem Internet beim ersten Start an der Domäne anmelden. Der Client muss zunächst vom Benutzer root in die Domäne aufgenommen werden und dann ein neues Image erzeugt werden. Dieses kann dann wie gewohnt verteilt werden.
Das aktualisierte cloop kommt mit einigen Anpassungen:
apt remove unattended-upgrades
Auto-Updates in /etc/apt/apt-conf.d/20-auto-upgrades ausgeschaltet.
Altes Passwort eines Lehrers: “veraltet” — musste neues eingeben in der login maske
noproxy - Empfehlung für den Masterclient (zumindest temporär)
dann fällt auf, dass nach dem turnkey das Setzen bzw. Nichtsetzen des Proxys für den linuxadmin funktioniert, davor aber nicht (vorher ist http_proxy gesetzt…)
Hallo zusammen,
ich habe jetzt sowohl das cloop von
://download.linuxmuster.net/client-cloops/v7/ubuntu1804basisClient.tbz am laufen
als auch ein eigenes Ubutnu 18 mit dem paket linuxmuster-client-adsso versehen.
Anmelden als Domänennutzer klappt bei beiden.
Jetzt habe ich eine Verständinsfrage:
Warum ist firefox jetzt über den proxy geschaltet, ist dies notwendig für die pädagogischen Funktionen?
In /etc/linuxmuster-client-adsso.conf kann man den proxy ja auch ausschalten.
Wie mache ich dann Updates als linuxadmin?
Viele Grüße
Johannes
Hallo,
ich klinke mich hier mal ein. Ich bin auch gerade dabei, einen eigenen Client auf ubuntu-Basis (KUBuntu in diesem Fall) aufzubauen.
Ich hatte mir den client-addsso schon vor Eurem produktiven Wochenende heruntergeladen. Die Änderungen müssten aber über ein Systemupdate mit reinkommen, oder?
Das client-addsso funktioniert nicht mit dem kde login-manager. Stellt man diesen um auf gdm3 (was insgesamt eine schlechte Idee ist, weil der gleich ein halbes Gnome startet, was dann zusätzlich zu kde läuft), dann geht es. Mit lightdm geht es auch, nur dass da noch ein Bugfix zu machen ist (siehe Testen von v7 in Virtualbox )
Ich habe das Problem, dass Netzwerknutzer eine andere Shell bekommen als lokale Nutzer, wie kann man das in dem Nutzerprofil ändern?
Der Firefox steht bei mir auf “Systemeinstellungen” bei Proxy. Ganz selten fragt er mal nach einem proxy-Passwort, meist geht es aber ohne.
Ich hätte zu der Sache noch eine relativ dringende Frage (bei uns in NDS geht nächste Woche die Schule ja leider schon wieder los): Wie bekomme ich meinen (lokal in der virtuellen Umgebung erstellten) Client ins Schulnetz? Kopiere ich das .cloop auf eine USB-Platte und trage die irgendwie zum Server? Sorry für die dummen Fragen, ich bin kompletter Linuxmuster-Neuling (naja, seit 3 Wochen am fleißig lernen).
Die Cloop muss inklusive aller Dateien an entsprechender Stelle wieder abgelegt werden. Du kannst das ganze per USB Platte transferieren aber auch einfach per scp hochschicken. Wichtig ist dass du alles mitnimmst, also meinTollesImage.cloop*
Nutzersynchronisation: Bei meinem Testsystem ist es so, dass die Einstellungen des Nutzers “linuxadmin” beim ersten Anmelden auf einer Maschine übernommen werden, aber anschließend nicht mehr. Die gecachten Homes bleiben auch auf dem Server. Ist das Absicht, oder ein Bug, oder habe ich hier etwas zerschossen / falsch gemacht?
Ich habe ein Problem mit dem Verlinken von Einstellungen.
Ich möchte die Firefox-Einstellungen (für alle, also in userprofile.conf) verlinken.
Daher habe ich in der userprofile.conf angelegt:
.mozilla:mozilla
Das funktioniert aber nur, wenn im lokalen (also gecachten) home des Users die lokale Datei .mozilla bereits vorhanden war. Ist sie das nicht, so wird auch kein Link angelegt.
Ich bin leider kein bash-Experte, auf den ersten Blick kann ich im Skript (das müsste ja wohl 04_mandatory_settings.sh sein) keinen Fehler finden.
Alle Linbo relevanten Daten liegen unter /srv/linbo.
Wenn der Client in einer anderen Domäne beigetreten ist (Testinstallation zB.) muss dies entsprechend auf dem anderem System (Produktiv) wieder loischerweise angepasst werden.
Die Kommunikation zwischen Client und Domäne passiert über Zertifikate, diese werden bei der Installation entsprechend erstellt und gehören zur jeweiligen Installation. Ein Client kann sich nicht einfach an verschiedenen Domänen anmelden, auch wenn diese den gleichen Namen haben.
Zum Linuxclient kann ich leider wenig sagen, bisher hatte ich hier wenig Berührungspunkte.