Ubuntu-Client für lmn7

#1

Hallo zusammen!

Es gibt jetzt ein Paket mit dem man einen Ubuntu-Client mit Single-Sign-On an den lmn7-AD anbinden kann.
Infos gibt es hier.
Was noch fehlt ist ein Mechanismus für die Anwendung eines Default-Profils. Das wäre eine noch zu vergebende Aufgabe.

Viel Spaß beim Ausprobieren.

Viele Grüße
Thomas

1 Like
Default Cloop für LMNv7
#2

Hallo,

das sind ja gute Neuigkeiten…

Verstehe ich das richtig, dass das Home des Benutzers direkt vom Server gemountet wird? Also nicht wie bislang beim Linux-Client ein lokales Home existiert, in dem dann die Servermounts erreichbar sind?

Was meinst du mit “einlesen” in dem Zusammenhang?

Automatik, um dem User ein Defaultprofil zu verpassen.
Könnte man z. Bsp. auf dem Server unter /var/lib/samba/sysvol/profile/linux/ ablegen und beim Anmelden von dort einlesen. Dann müsste man bei einer Profiländerung kein Image erzeugen und ausrollen.
Wäre eine zu vergebende Aufgabe.

Was muss da passieren?

VG

Frank

#3

Steht denn schon fest, welcher Client (bzw welcher Desktop) es wird oder kann man “frei” wählen?
Ich frage nur deshalb, weil sich einige ja nicht besonders gut mit dem aktuellen Ubuntu-Default-Desktop anfreunden können…
Schönen Gruß
Michael

#4

Hallo,

ich glaube, in diesem Beitrag gehts jetzt erst mal eher um die technische Seite. Die (technische) Kompatibilität ist in Thomas Minidoku ja auch dargestellt, Abschnitt “Läuft mit:”. Daraus geht nach jetzigem Stand hervor, dass vanilla Ubuntu wegen Nautilus nicht gehen wird, du muss also mindestens den Filemanager ersetzen.

Damit läufts wieder in die Richtung, die schon im anderen Thread diskutiert wurde: Xubuntu 18.04
Ubuntu Mate Edition 18.04, Mint.

Dort sollten wir diesbezüglich auch weiter sprechen: Default Cloop für LMNv7

VG

Frank

#5

Moin!

[ironiemix] ironiemix https://ask.linuxmuster.net/u/ironiemix
Entwickler
6. November

Hallo,

ich glaube, in diesem Beitrag gehts jetzt erst mal eher um die
technische Seite. Die (technische) Kompatibilität ist in Thomas
Minidoku ja auch dargestellt, Abschnitt “Läuft mit:”. Daraus geht nach
jetzigem Stand hervor, dass vanilla Ubuntu wegen Nautilus nicht gehen
wird, du muss also mindestens den Filemanager ersetzen.

Damit läufts wieder in die Richtung, die schon im anderen Thread
diskutiert wurde: Xubuntu 18.04
Ubuntu Mate Edition 18.04, Mint.

genau, mit ging es nur darum die technischen Voraussetzungen für die
Anbindung an das AD zu machen. Alles weitere hängt vom Engagement
weiterer Leute ab.

VG, Thomas

#6

Hallo Thomas,

hast auch noch Antworten auf meine Fragen?

VG

Frank

#7

Hallo Frank,

  • Ja, das gesamte Schulshare wird direkt vom Server gemountet. Lokales Home gibt es nur, wenn ohne Serververbindung gebootet wird.
  • einlesen heißt sourcen eines Shellskripts, müssen also nicht ausführbar sein.
  • Bzgl. Profil: Ja, da muss noch was passieren.

BTW, das Readme habe ich noch ergänzt. Hinweise zum Onboot-Dienst fehlten noch.

VG, Thomas

#8

Hallo Thomas,

Dann wäre das folgende Vorgehen doch praktikabel:

  • Auf dem Linuxclient gibt es wie bisher einen Vorlagenbenutzer, mit dem ich alles wie gewünscht einrichte.
  • Da das eigentliche Home jetzt vom Server kommt, kann ich jetzt natürlich nicht mehr alles einfach überbügeln, mache Dinge (.gvfs u.ä) müssen ja sowie so beim Login angelegt werden. Also erzeuge ich mit einem “Skript” auf dem Client das eigentliche Profil. Dabei kann man auch festlegen, welche Einstellungen im Profil fixiert sind und welche die Benutzer selbst verändern dürfen. Dieses aus dem eigentlichen Profil des Vorlagenbenutzers erzeugte “Vorlagenprofil” lege ich dann auf den Server.
  • Beim Anmelden wird nun dieses Profil ins Serverbasierte Homeverzeichnis des Benutzers kopiert (gesourctes Shellskript?) und überschreibt damit die Einstellugen des Benutzers durch die Vorgaben.

Weitere Fragen:

  • Wo wird das gesourcte Shellsript ausgeführt und unter welcher Benutzerkennung (Server/Client - Root/Benutzer?)
  • Der Knackpunkt beim diesem Setup ist IHMO, dass das Profil nicht “übers Netz” kopiert werden darf, denn sonst hast du ziemlich sicher Probleme, wenn sich 30 SuS gleichzeitig anmelden. Entwender Samba kann das inzwischen und blickt, dass der Kopiervorgang von Server auf Server ist oder man benötigt einen Mechanismus, der das Profil direkt auf dem Server kopiert?

Ich schreib hier mal @roesslerrr hin, denn das ist fürs BSZ wahrscheinlich auch von Bedeutung.

VG

Frank

#9

Hallo,

ich möchte mich an dieser Stelle der einen Frage von Frank anschliessen, bzw. meine Bedenken äussern!

Wir hatten beim alten linuxmuster-client Paket bis ubuntu 10.04 genau dieses Vorgehen mit einem serverbasierten Profil und das hatte viele unschöne Nebeneffekte und hat sich überhaupt nicht bewährt. Hauptproblem waren kurze Timeouts bei hohem Netzwerktraffic, die dafür sorgten, dass die Clients vollständig einfroren. Aus diesem Grund sind die neueren linuxmuster-client Profilgeschichten nahezu komplett Clientbasiert. Das ist erstens für die Admins wesentlich einfacher zu durchschauen und rock solid, da beim Ausfall des Netzwerks maximal die Freigaben nicht funktionieren, der Rest aber schon. Weiterhin fällt mir auf, dass bei neueren Ubuntus immer mehr gecacht wird…in $HOME/.cache kommen in einer Sitzung schnell mal 1GB zusammen…das in einem Rechneraum * 30 verursacht schon unschönen Traffic. Nachteil beim lokalen Profil ist, dass man bei Änderungen im Profil ein neues Image machen muss, wobei man vieles über einen Postsync regeln kann.

Ich würde dafür plädieren, falls möglich bei diesem bewährten System zu bleiben, d.h.:

  1. Es gibt einen Vorlagenbenutzer
  2. Ein User meldet sich an, bekommt das Vorlagenprofil lokal kopiert, die Serverfreigaben werden per pam-mount irgendwo hin gemountet
  3. User bezogene Einstellungen, die persistent bleiben sollen (z.B. Firefoxsettings, usw.) werden initial vom Vorlagenbenutzer auf eine Freigabe kopiert und dann bei jeder weiteren Anmeldung verlinkt.

Vielleicht kann @thomas sich kurz dazu äußer, ob das mit seiner Vorgehensweise vereinbar ist oder ob ein reines Remoteprofil sein muss.

Gruß

Dominik

1 Like
#10

Hallo,

das muss, soweit ich den Code verstehe, kein reines Remoteprofil sein. Entscheidend ist, wohin das $HOME des Benutzers zeigt, das wird bei lokalem Boot mit gecachten Credetials ja auch angepasst. Von dort kann ich dann letztlich linken wohin ich mag.

Das mit dem .cache hatte ich nicht auf dem Schirm, ist aber auch zu bedenken. Allerdings könnte man so was bei einem, serverbasierten Profil auch (via Link) umbiegen auf die lokale Platte. Der Vorteil von serverbasiert ist halt, dass man keine Dateien mehr vergisst.

Für mich ist auch der Vorlagenbenutzer alternativlos: Man könnte ja durchaus das Profil aus einzelnen Einstellungen “zusammenbauen”, indem man Dateien mit Einstellungen für Programme kopiert oder mit gconf Settings entsprechend anpasst und dergleichen. Damit ändert man aber die grundlegende (KISS-)Philosophie “ich richte es ein und verteile es dann”. Das will ich eigentlich nicht machen (ich habe sowieso schon den Eindruck, dass die 7 sich relativ weit von KISS entfernt hat).

Was man festhalten kann, ist dass es wahrscheinlich eine gute Idee ist, da erst mal noch ein bissle drüber zu schreiben…

VG

Frank

#11

Hallo Frank,

[ironiemix] ironiemix https://ask.linuxmuster.net/u/ironiemix
Entwickler
7. November

Hallo Thomas,

thomas:

  * einlesen heißt sourcen eines Shellskripts, müssen also nicht
    ausführbar sein.
  * Bzgl. Profil: Ja, da muss noch was passieren.

Dann wäre das folgene Vorgehen doch praktikabel:

  • Auf dem Linuxclient gibt es wie bisher einen Vorlagenbenutzer, mit
    dem ich alles wie gewünscht einrichte.

Yep.

  • Da das eigentliche Home jetzt vom Server kommt, kann ich jetzt
    natürlich nicht mehr alles einfach überbügeln, mache Dinge (.gvfs
    u.ä) müssen ja sowie so beim Login angelegt werden. Also erzeuge
    ich mit einem “Skript” auf dem Client das eigentliche Profil.
    Dabei kann man auch festlegen, welche Einstellungen im Profil
    fixiert sind und welche die Benutzer selbst verändern dürfen.
    Dieses aus dem eigentlichen Profil des Vorlagenbenutzers erzeugte
    “Vorlagenprofil” lege ich dann auf den Server.

Yep.

  • Beim Anmelden wird nun dieses Profil ins Serverbasierte
    Homeverzeichnis des Benutzers kopiert (gesourctes Shellskript?)
    und überschreibt damit die Einstellugen des Benutzers durch die
    Vorgaben.

Yep.

Weitere Fragen:

  • Wo wird das gesourcte Shellsript ausgeführt und unter welcher
    Benutzerkennung (Server/Client - Root/Benutzer?)

Auf dem Client im User-Kontext bei der X11-Anmeldung
(/etc/X11/xinit/xinitrc.d/99linuxmuster.net sourct
/var/lib/linuxmuster-client-adsso/login.d/).

  • Der Knackpunkt beim diesem Setup ist IHMO, dass das Profil nicht
    “übers Netz” kopiert werden darf, denn sonst hast du ziemlich
    sicher Probleme, wenn sich 30 SuS gleichzeitig anmelden. Entwender
    Samba kann das inzwischen und blickt, dass der Kopiervorgang von
    Server auf Server ist oder man benötigt einen Mechanismus, der das
    Profil direkt auf dem Server kopiert?

Da muss ja IMO nicht viel kopiert (gersynct?) werden, ein Paar kb
Desktopeinstellungen und ein Paar kb configfiles, oder? Falls man das
vermeiden will, kann man ins lokale Userhome /home/user syncen und ins
Serverhome verlinken.

Serverside copy mit Samba funktioniert glaube ich noch nicht (Rüdiger
weiß da evtl. mehr).

In der aktuellen Version 6.2 nutzen wir in der Tat einen
Samba-Mechanismus, der es ermöglicht bei der Verbindung mit einem Share
serverseitig Skripte mit Root-/User-Rechten auszuführen (Environment:
%U: Username, %I: Hostname , %H: Homedir):
root preexec = script --parameter
root postexec = script --parameter
preexec = script --parameter
postexec = script --parameter
Könnten wir auch machen wenn sich ein User z. B. mit der Sysvolfreigabe
verbindet und so den Schlamassel serverseitig kopieren lassen.

Mr sodd des halt mol älles ausprobiera.

BTW, Readme nochmal aktualisiert: Elementary OS 5 wird auch ohne
Einschränkungen unterstützt.

#12

Samba unterstützt das Server-Sode-Copy, nicht aber jeder Dateimanager. Sophomorix unterstützt das SSC beim Austeilen/Einsammeln.

@thomas Danke für die Arbeit am Linux-Client-Paket. Schön, dass du dir das vorgenommen hast.

PS: Wir sollten uns mit den Pfaden noch abstimmen. Ich habe für die GPOs schon ein Schema erstellt und dan die Linux-Cients dabei gedacht. Vielleicht mach ich gleich einen Thread dazu.

#13

N’Abend,

ich möchte mich an dieser Stelle der einen Frage von Frank anschliessen, bzw. meine Bedenken äussern!

ich weiß nicht, ob das noch Sinn macht, aber auch ich möchte mich dem anschließen - die Umstellung von einem Serverhome zu einem Home auf dem Clientrechner vor einigen Jahren hat bei uns eine deutliche Verbesserung gebracht - ich war froh über diese Designentscheidung. Eine Rückkehr zu einem $HOME direkt auf dem Server lässt mich eine Rückkehr zu stockenden Rechnern befürchten :scream:
In einer gemischten Umgebung (Windows und Linux-Clients) heißt $HOME als Serververzeichnis außerdem, dass man den ganzen Konfigurationskram, den Linux so ins Home legt dann auch unter Windows rumliegen hat.

Gruß
Sascha

1 Like
#14

Hi Thomas,

ich gebe zu bedenken, dass “einen Ubuntu-Client” heißen sollte: einen neuen Ubuntu-client (nicht der mit lmn6.2 funktioniert). Dein Vorgehen bedeutet, dass auch ein Cut beim Client gemacht wird.

Mir ist das egal - ich gebe bloß zu bedenken, dass mal angesprochen wurde: lasst uns doch den Client lassen und die lmn7 nur serverseitig durchziehen. ABer vermutlich geht das nicht oder ist mit Krücken nur zu machen.

VG, Tobias

#15

Hallo Thomas,

ich hab dein Paket jetzt mal mit Mate 18.04.1 und ubuntu 18.04 ausprobiert: bei beiden INstallationen gibt es die selbe Fehlermeldung beim Installieren (siehe Bild).
Nach dem reboot kann ich mich als Domänennutzer anmelden, es sind aber keine ServerLaufwerke verbunden.
Ich finde den Server und seine Freigaben in der Netzwerkumgeung (Sysvol und noch andere).
Diese kann ich öffnen und reinbrowser (ein paar Unterordner, auch /home/teachers und /home/students) sie sind aber alle leer.

SSO geht nicht. Ich hab im Firefox den Proxy: firewall.lmn.lokal:3128 eingetragen: damit geht es in der gleichen VM mit Windows. Reicht es den Proxy im Browser ein zu tragen, oder muss der Systemweit rein?

Was mir auch noch aufgefallen ist: unter Windows geht eigentlich alles: aber Netzlaufwerke sind da auch nicht verbunden.
Ich hab diese Woche die neuen VMs genommen, prepare gemacht und dann das Setup über die webui aufgerufen.
Wie kann ich den rausbekommen, ob der samba die Laufwerke “anbietet”?

LG

Holger

#16

Hallo Holger,

zu den Proxy-Einstellungen:
Bislang habe ich weder in Windows noch in Linux gesehen, dass Firefox
die “Einstellungen des Systems” übernommen hätte … Google Chrome macht
es dagegen problemlos.
Besser finde ich jedoch - wenn man den Proxy nicht transparent haben
möchte - Firefox die Einstellungen automatisch finden zu lassen. Spart
auch Hilfeleistungen für KollegInnen mit privaten Notebooks.
http://www.kai-hildebrandt.de/tutorials/wpad.html
(Habe ich hier schon mal geschrieben.)

zu den fehlenden mounts:
Hast Du darauf geachtet, dass die mountpoints vorher leer waren?
(lmlcc ist Dein Freund :wink:

Gruß Jürgen

#17

Hallo,

wenn man beim booten des Servers schnell schaut, dann sieht man die Meldung, dass NMB nicht gestartet wird: könnte es daran liegen?

LG

Holger

#18

Hallo Dominik,

die aktuelle Vorgehensweise ist mit meinem Paket weiterhin möglich. Das Vorlagenprofil muss nicht auf dem Server liegen. Es ist jetzt halt zusätzlich möglich, das Vorlagenprofil auf den Server ins sysvol share zu legen. Bei Clients, die nicht mobil genutzt werden, erspart das das Imaging, wenn man nur eine Vorlagenänderung ausrollen will.

VG, Thomas

#19

Hallo Sascha,

es gibt keine Designentscheidung hin zu einem Serverhome. Mein Paket ist in jeder Hinsicht maximal flexibel. Da das Samba-Protokoll und auch die Netzwerke in der Zwischenzeit performanter geworden sind, kann es bei entsprechender Infrastruktur durchaus Sinn machen, das Serverhome nochmal auf den Prüfstand zu stellen. Zumal ich bei der entwicklungsbedingten Recherche gesehen habe, dass heutzutage ein cifs-Serverhome nicht selten produktiv genutzt wird. Erspart halt das auch nicht immer schmerzfreie Verfahren, mit dem man bestimmte Ordner und Einstellungsdateien lokal zur Verfügung stellen muss.
Außerdem, wenn ich z.B. das Firefoxprofil aus dem Serverhome ins lokale Home verlinkt habe und mir bricht das Netzwerk weg, dann habe ich auch ein Problem.

Im Moment ist es möglich durch auskommentieren der Zeile
[ -d “$UNIXHOME” ] && export HOME="$UNIXHOME"
in /var/lib/linuxmuster-client-adsso/login.d/01_environment.sh das lokale Home in jedem Fall zu erzwingen. Das werde ich der nächsten Paketversion konfigurierbar machen.
Sowieso ist es möglich die unter /var/lib/linuxmuster-client-adsso/login.d/ während des Setups verlinkten Paketskripte komplett durch eigene zu ersetzen. Ein Paketupdate ist in der HInsicht unkritisch.

VG, Thomas

#20

Hallo Tobias,

naja, die Anbindung an lmn7 geht halt nicht ohne dass man es am Client anders macht als vorher. Hier ist die Entwicklung auch weitergegangen. Die Anbindung von Linux-Clients an verschiedene Authentifizierungssysteme lässt sich heutzutage sehr flexibel mit sssd erledigen.

VG, Thomas