Linuxmuster-client-adsso (v7)

Clientpflege Linuxclient
1

Hallo zusammen, vor allem @baumhof, gerne aber auch @thomas und @ironiemix,

ich versuche gerade Ordnung in mein Hirn und in die linuxmuster-client Konfiguration zu bekommen. Dabei fallen mir ein paar Sachen auf, wenn ich mal den Stand von Holgers/Dominiks lmn-bionic-image (0320) hernehme und das linuxmuster-client-adsso Paket wie es momentan als Debian-Paket vorliegt und dann noch mein neues linuxmuster-client Paket hernehme:

Konfigurationen können an vier Stellen passieren:

  • durch das Installieren des Pakets linuxmuster-client-adsso, fest im Paket
  • „von außen“ durch linuxmuster-client und generische postsync.d Skripte und durch postsync-Daten, die mit paketiert ankommen.
  • dadurch, dass das Image paketiert wurde und die Konfiguration eben schon drin ist
  • LINBO (/etc/hostname)

Das sind zu viele Stellen an denen geschraubt wird. Da weiß keiner, wo man suchen soll. Gut, meistens muss man auch als Endanwender nicht suchen, nur die Supporter müssen das eben wissen.

Beispiel: ntp

  • linuxmuster-client-adsso konfiguriert bei Aufruf „chrony.conf“
  • Du, Holger, hast timesyncd.conf mit ins Paket reingenommen, was systemd-internes ntp konfiguriert.
  • Mein linuxmuster-client Paket macht das jetzt eigentlich, in dem es timesyncd.conf als template nimmt und die serverip reinschreibt.

Aber eigentlich ist nur eines dieser vier Varianten nötig (Linbo lasse ich außen vor).
Ich schlage vor, dass wir das gut trennen. Mein Vorschlag:

linuxmuster-client-adsso

  • beherbergt alle Templates, die im Paket an die jeweilige Schule angepasst werden müssen, außer es gibt einen Grund, dass sie im postsync gepatcht werden müssen.
  • konfiguriert SSO (die Domänenanmeldung), konfiguiert die lightdm-Anmeldung, konfiguriert die mounts, usw. was es eben ja schon tut
  • sollte beim ersten Mal aufgerufen werden können, sowie auch nachträglich, wenn das Paket aktualisiert wird, nicht aber der komplette client.

linuxmuster-client + postsync.d

  • beherbergt alle Templates, die an die hosts angepasst werden müssen, z.B. weil der hostname ersetzt werden muss, oder weil durch Paketupdates Dateien immer wieder im Image überschrieben werden (geogebra-Beispiel)
  • der Befehl linuxmuster-client konfiguriert das auf dem Server, einmalig nach Herunterladen eines neuen Clients oder immer wieder (wenn z.B. neue Dateien eingepflegt wurden)

An dieser Stelle: Seid ihr, die ihr das lest und versteht was ich meine, einverstanden?

Jetzt noch die konkreten Usecases:

  • timesyncd.conf: irgendwie kam im Forum auf, dass der ntp nicht stimmt und natürlich laufen müsste, daher der Vorschlag timesyncd.conf zu konfigurieren. Allerdings gibt es eigentlich schon chronyd im Image, daher mir unklar, ob es beide geben muss/darf. Das timesyncd.conf kann man schon mit dem Image im postsync mitliefern, aber das sollte temporär sein, eigentlich sollte das als Bugfix nach linuxmuster-client-adsso gehen, dann installiert man sich das neue Debianpaket und führt -setup nochmal aus. Richtig?
  • geogebra: Jemand findet eine notwendige Änderung, die den hostnamen in der Datei erfordern oder die erfordern, dass Dateien im Image bei jedem Start gepatcht werden müssen. Geogebra z.B. wird häufig upgedatet von usern, dabei wird jedes mal die analytics.google Zeile wieder reingeschrieben, welche durch postsync dann wieder rausmuss. Diese Änderungen müssen als Bugfix ins debianpaket von linuxmuster-client-servertools fließen, damit man sich das auf dem Server installiert und erneuet linuxmuster-client configure ausführt.
  • mir ist klar, dass das alles eventuell auch über die Doku bzw. das Forum gehen kann, a la : hey, du installierst im Image das Paket xy, passt yz configuration oder passt äö im postsync an und dann machst du ein neues Image. Aber jeder der neu dazu kommt, müsste dann alle diese Änderungen nachvollziehen und man weiß am Ende nicht mehr wirklich wo sie herkommen.

Wenn das akzeptabel klingt, würde ich diese Seite in die Entwickler-Doku von den obig genannten Paketen übernehmen und versuchen das zu implementieren.

VG, Tobias

Der Vollständigkeit halber, die aktuell mir bekannten, mehr oder weniger notwendigen Konfigurationsdateien, die angefasst werden sollen:

im Paket, angepasst an Schule

/etc/chrony/chrony.conf
/etc/request-key.d/cifs.spnego.conf
/etc/gdm3/greeter.dconf-defaults
/etc/krb5.conf
/etc/lightdm/lightdm.conf.d/50-linuxmuster.conf
/etc/linuxmuster-client-adsso.conf
/etc/profile.d/linuxmuster-proxy.sh
/etc/security/pam_mount.conf.xml
/etc/samba/smb.conf
/etc/sssd/sssd.conf
/etc/systemd/timesyncd.conf
- /etc/krb5.keytab
/etc/linuxmuster-client/*
/etc/systemd/system/linuxmuster-client-adsso.service
/etc/cups/client.conf
/usr/local/bin/linuxmuster-mkimage.sh
/usr/local/bin/linuxmuster-mkimage-deploy.sh

außerhalb des Pakets, angepasst an hosts

linuxmuster-client/patchclass/common/root/.ssh/authorized_keys
linuxmuster-client/patchclass/common/passwords
linuxmuster-client/patchclass/common/postsync.d/00-lcst-fix-initrd
linuxmuster-client/patchclass/common/postsync.d/01-lcst-setlocalpasswords
linuxmuster-client/patchclass/common/postsync.d/03-lcst-fix-fstab
linuxmuster-client/patchclass/common/postsync.d/04-lcst-generate-hosts
linuxmuster-client/patchclass/common/postsync.d/09-lcst-fix-permissions
... geogebrapatch...
linuxmuster-client/patchclass/common/etc/ssh/sshd_config
linuxmuster-client/patchclass/common/etc/hosts
linuxmuster-client/patchclass/common/etc/fstab
2

Hallo,

aus meiner Sicht sollte die Konfiguration so weit wie möglich in linuxmuster-client-adsso passieren.

Anpassungen die beim Rollout über das „client-server“ Paket passieren (daran arbeitest du gerade, wenn ich die Github Mails so ansehe?) können dann per Postsync dazukommen und müssen dort dokumentiert und supportet werden.

Eigene Postsync Anpassungen müssen nicht supportet werden.

Das was Holger macht/gemacht hat, nämlich auf irgendwelchen Clouds von irgendwem irgendwie angepasste Cloops zu verteilen, bei denen sich die Anpassungen praktisch nicht mehr nachvollziehen lassen, weil nicht paketiert und „irgendwo“ dokumentiert muss IMHO aufhören. Ebenso problematisch sind in diesem Zusammenhang Aussagen aus Leonberg, dass die dort auch dieses, jenes und das dritte Problem hatten, das auch lösen konnten und in ihrem internen Wiki aufgeschrieben haben, wie die Lösung ist :ok_hand:
Das sind übrigens auch wesentliche Gründe, warum ich aufgehört habe mich aktiv damit zu beschäftigen, das ist einfach viel zu ineffektiv so.

Die Entwicklung des Clients muss in dem Paket linuxmuster-client-adsso erfolgen, sonst nirgends.

Wenn es ein neues Cloop geben soll, müssen die Anpassungen z.B. über ein Skript in linuxmuster-client-adsso erfolgen und dort dokumentiert sein. Alle Änderungen müssen im Changelog des Repos ersichtlich sein.

Jeder sollte ein neues cloop bauen können, indem er auf eine dokumentierte Grundinstallation das linuxmuster-client-adsso Paket installiert und z.B. noch ein turnkey und ein firstconf Skript laufen lässt - dort muss alles passieren, vom neuen SSH Host Key bis zum abgeschalteten Screen Lock im DE.

So was würde ich in ein imgprep Skript auf dem Client (das auch im linuxmuster-client-adsso Paket mitkommt) machen, niemals in dem Server Paket. Womöglich modifizierst du sonst mit einem Serverupdate alle schon ausgerollten Linuxclients, das darf nicht passieren.

Ich habe so eins, das alle Homes löscht, eine graue Version des Hintergrunds erzeugt für den Login Screen und 1000 andere Sachen um die Vorlage des Homes klein zu halten.
Nach jedem dist-upgrade führst du das einmal aus, kannst dann unsynchronisiert starten und testen und machst dann das Image.
Man könnte das durch ein Skriptverzeichnis ergänzen/verbessern, wenn man eigene SW nachinstalliert, die auch so was braucht. Dort wäre dann auch anhand der Skriptnamen ersichtlich, was da angefasst wird, z.B.

/var/lib/imgprep.d/
                     01-delete-google-earth-cache
                     02-create-login-wallpaper
                     03-modify-geogebra-config
[...]

Im „mitgelieferten“ Postsync hat sowas nix verloren, da sollte nur rein, was für den ersten Rollout eines heruntergeladenen Images nötig ist und was der User später selbst da rein schreibt.

VG

Frank

3 „Gefällt mir“
3

Hallo Frank!

Das hört sich sehr gut an! :+1:

Ließen sich dann diese Skripte (z.B. von Leuten aus der Community) an einem Ort sammeln und so allen etwas auf einfache art und weiße verfügbar machen?

Beste Grüße

Thorsten

4

Hi Frank (@ironiemix),

danke für den Input.

Ist vielleicht oben nicht ersichtlich, aber zu dem Schluss bin ich auch gekommen und die Änderungen die ich bisher in github in linuxmuster-client-servertools gemacht habe, werde ich wieder rausnehmen (etc_fstab usw.). Daher auch diese Mail.

auch klar. Aber auch das ist ein Punkt, den wir festlegen sollten: Eigene postsync-Dateien sollten nicht mit ausgerollt werden, so wie z.B. Holger packt noch eine cups.conf über Postsync rein. Das sollte entweder im Image fest drin landen, oder, falls es wie die /etc/hosts konfiguriert werden muss, sollte das über ein generisches postsync.d-Skript im Paket von linuxmuster-client-servertools landen.
Eigene Postsync-Dateien landen nur in den eigenen Images, nicht im offiziellen.

Darüber muss ich noch genau nachdenken:
Die Geogebra-Geschichte geht tatsächlich im Image, wenn der Enduser den imgprep-Befehl nicht vergisst. Das hostname-replacement in /etc/hosts geht eben nicht über imgprep, weil das eben variable bleiben muss.
Ja, wenn es ein server-paket-update-neues-rollout geben muss, dann muss das gut durchdacht und abgefragt werden und es muss auch jedem klar sein, dass man z.B. an der /etc/hosts nicht als Enduser pfuschen sollte, weil ein server-paket-update-neues-rollout das wieder auf den ausgangszustand zurücksetzt, ebenso /etc/fstab. Am besten ich baue eine Abfrage wie bei Debian-Paketen ein (I/d/M/N) oder so ähnlich… vllt. geht das ja sogar beim debian-upgrade eines pakets, auch wenn die entsprechende Datei nicht unter /etc liegt…

Alles weitere hatte ich auch schon angedacht. Ich nannte das Skript „linuxmuster-mkimage.sh“ und habe da die 1000 Dinge getan, die der Enduser eben machen sollte bevor er ein neues Image macht. linuxmuster-imgprep wäre dann die Profi-Variante mit imgprep.d-Verzeichnis.

Super.

VG, Tobias

5

ich hab ja auch schon mit einem eigene Repo angefangen, skripte zu sammeln, die mir nützlich erscheinen und die ruhig alle verwenden können sollten.

Das zu moderieren ist aufwändiger, als zu fordern dass die community Pull requests in das Paket macht. Daher läuft es (ohne Moderation) wie immer: Holger nimmt es ins Paket auf oder es landet im Anwenderwiki oder minimal hier in ask.
Aber mit dem Verzeichnis unter /var/lib/ wäre die Basis da, damit man weiß wohin man es packt…

VG, Tobias

6
  • könnte das nicht /var/lib/image-prep.d/ und dann linuxmuster-image-prep heißen? Das Wort imgprep konnte ich beim ersten Lesen gar nicht auflösen, mein Hirn hat grep, pgrep bzw. im pgrep draus gemacht…
  • das turnkey-skript würde natürlich am Ende auch image-prep aufrufen.
  • ich würde nach einem Neustart image-prep nochmal aufrufen, damit eines der Skripte zusätzliche Kernel löscht, oder nicht?

Wo wir beim Grundsätzlichen sind: Die Skripte in /etc/linuxmuster-client/login.d/ werden im user-kontext ausgeführt, nicht im root-kontext. Ich bin mir aber sicher, dass man auch beim login im root-Kontext Dinge ausführen will, weswegen ich einem skript sudo-rechte verpasst habe. Das wiederum könnte aber auch unter /etc/linuxmuster-client/login-as-root.d/ Hook-skripte ausführen. bisher hab ich das nicht implementiert, wäre aber sinnvoll, denke ich.

VG, Tobias

7

Hi nochmal,

  • /etc/linuxmuster-client/scripts/login.sh wird von X11 unter /etc/X11/xinit/xinitrc.d/99linuxmuster.net aufgerufen - im userkontext
  • mein /etc/linuxmuster-client/scripts/login-as-root.sh kann jetzt entweder von am Ende von login.sh aufgerufen werden mit Hilfe von „sudo“ und einem „sudoers“ Eintrag.
  • Oder ich könnte es über pam_exec /etc/linuxmuster-client/scripts/login-as-root.sh machen, welches in common-session oder besser in pam.d/lightdm ausgeführt wird.

Letzteres finde ich jetzt besser, da man nur eine pam-Datei anfassen muss. Bei sudo muss man noch eine sudoers-Datei anpassen.
VG, Tobias

8

Hallo,

zum technischen Teil dieser Diskussion kann ich nichts beitragen. Aber zur Umsetzung möchte ich mich äußern.

Das notwendige Update auf V7 erfordert nicht nur einen neuen Server und eine neue Firewall, sondern auch einen neuen Linuxclient, weil der alte nicht so ohne Weiteres mit Samba 4 zusammmenarbeiten kann. Und gerade für Schulen, an denen der Linuxclient gut etabliert ist, bedeutet das einen Haufen Arbeit, wobei es den Usern so ziemlich egal ist, ob Server und Firewall schon gut funktionieren, sie wollen vor einem gut funktionierenden Desktop sitzen.

Und weil ich den Job als Netzwerkberater jetzt auch schon ein paar Jährchen mache, befürchte ich, dass selbst 6 Wochen Sommerferien da knapp werden können, wenn sie nicht nur fürs Schulnetz draufgehen sollen.

Was den LInuxclient angeht, würde ich mir wünschen - ohne einschätzen zu können, ob das mit vertretbarem Aufwand zu realisieren ist -, dass es ein „neutrales“ cloop gibt, dass mit einem lokalen linuxadmin soweit vorbereitet ist, dass man schulspezifische Anpassungen machen kann und dann die Aufnahme ins Netzwerk der V 6.2 oder später der V 7 stattfinden kann. Dann könnte ich die vielen Kleinigkeiten und Verbesserungen, die sich im Laufe der Jahre angesammelt haben, in aller Ruhe einbauen. Die Kollegen können sich außerdem frühzeitig an den neuen Client gewöhnen und ich habe Zeit auf das Feedback einzugehen, weil ich nicht noch Probleme im Serverbereich lösen muss. Außerdem habe ich mit dem alten xenial-Client eine funktionierende (und beruhigende) Fallback-Lösung im HIntergrund.

Viele Grüße

Wilfried

9

Hallo,

du kennst:

901×802 74.2 KB

und den Rest des Wikis nehme ich an?

Bisher hat man beim login nichts als Root ausgeführt, alles was als root gelaufen ist, ist beim pam_mount passiert, und das ist eh im Root Kontext. Ich habe grade keine Zeit genau zu schauen, aber sudo beim Login halte ich spontan für ungeeignet.

Der zweite Ansatz ist da IMHO besser: Ausführen wenn man eh im Root Kontext ist. Aber Achtung: Die lightdm Session ist soweit ich weiss nicht gerootet :wink:

VG

Frank

10

Hallo,

eine Migrationsmöglichkeit ist IMHO essentieell, da stimme ich dir zu.

VG

Frank

11

Hallo,

Natürlich, ist so viel besser. Ich hab halt geschriebe es bei mir unter 6.2 heißt…

VG

Frank

12

Hallo!

Da glaube ich hast du mich missverstanden. Ich meinte nicht das jemand aus der Community das irgendwie moderiert. Sondern jemand aus der Community hat ein Programm installiert und stellt so alle nötigen Anpassung in einem Script allen zur Verfügung. So eine Art „msi-Paket“ für unsere linuxmuster-clients.

Also mensch startet mit einem standard Client und kann mittels der Scripte Programme installieren ohne das jeder ein schon einmal gedrehtes Rad neu drehen muss.

Beste Grüße

Thorsten

13

Hi Wilfried,

ich habe jetzt gerade mit Bordmitteln (also mit den Befehlen aus dem linuxmuster-client-servertools Paket) ein ubuntu_vanilla (18.04) erzeugt, das nahezu „vanilla“ ist und weder in die v7 noch in die v6 eingebunden ist.

Die Einbindung in die v7 probiere ich aus. Aber die Einbindung eines 18.04 in die v6 müsste jemand anderes (du) ausprobieren.

Bereitgestellt ist das cloop noch nicht zum download, auch die Dokumentation für die v6.x müsste ich noch dementsprechend anpassen, also bitte warten…
VG, Tobias

14

Hallo Wilfried,

verstehe ich dich richtig, wie im letzten Post angenommen, dass du ausgehend von einem ubuntu-minimal dein Image zunächst nur für den linuxadmin hochziehst mit deinen schulspezifischen Anpassungen (dein Basisimage) und danach die Aufnahme in die v6.2 machst, damit deine Kollegen sich daran gewöhnen?
Und dann, wenn du auf die v7 wechselst, dann willst du von deinem Basisimage aus die aufnahme in die v7 machen, so dass die User dann gar nichts mehr merken?

Das kannst du schon so machen, aber da brauchst du von niemandem ein „neutrales“ cloop, sondern kannst einfach mit einem ubuntu von vorne anfangen. Ich sehe nicht genau, wo der Unterschied ist, ob ich dir ein cloop liefere oder du dir selbst eines bastelst.

Ich kann mir nur vorstellen, dass du meinst, dass die vielen Änderungen, die von jemand wie Holger oder Dominik an einem cloop vorgenommen wurden nochmal an einem neutralen (nicht in v6 oder v7 aufgenommenen) cloop gemacht werden sollte. Das würde doppelte Arbeit bedeuten. Ich vermute nicht, dass das jemand macht.

VG, Tobias

15

Hallo Tobias,

in dem cloop von Dominik und Holger steckt schon jede Vorarbeit, die unabhängig von V6.2 oder V7 sinnvoll ist. Und nun habe ich es für den linuxadmin weiter schulspezifisch verändert. Wie man dieses „neutrale“ cloop dann in die V6.2 aufnimmt hat Sascha gelöst:

Bislang nutze ich das cloop aber nicht in der V6.2, weil es doch einige Schwierigkeiten gibt, z. B. funktioniert Wine nicht richtig, und ich nehme an, dass es an dem Ordner /samba liegt, der evtl. für Samba 4 konzipiert ist. Außerdem sind Schwierigkeiten mit dem Firefox-Profil aufgetreten und noch ein paar Kleinigkeiten mehr.
Ich kann nicht einschätzen, wieviel Zeit ich für den Umstieg auf die V7 brauche, bin aber froh, dass ich den Linux-Client auf „linuxadmin-Ebene“ schon ein gutes Stück weit vorbereitet habe. Ein Beispiel: Im nächsten Schuljahr werden bei uns 3-D-Drucker zum Einsatz. Für das Slicer-Programm Cura gibt es Linuxversionen, aber in der Praxis hatte ich doch einige Probleme zu lösen, bis es funktioniert hat.

Viele Grüße

Wilfried

16

Hallo Wilfried,
deine Mühen und Bedenken kann ich verstehen, auch das prinzipielle Vorgehen: z.B. Holger/Dominiks cloop wieder zu „ent“-v7-nifizieren und dann als neutrales cloop zu verteilen.

Aber: Die von dir genannten Schwierigkeiten kommen ja grade davon dass man im einen oder anderen Fall schon spezielle Anpassungen vorgenommen hat, die sich nicht für beide System gleichermaßen anpassen lassen. Da wird es schwierig das als neutrales cloop zu deklarieren.
VG, Tobias

17

Hallo Tobias,

es geht bis zu einem gewissen Punkt, aber produktiv einsetzen kann ich es unter V6.2 nicht, weil ein paar grundsätzliche Dinge anders gelöst worden sind. Ein „neues“ Ubuntu 18.04 kriegt man mit V6.2 zum Laufen, das cloop für die V7 nicht. Immerhin lernt man es dabei gut kennen :wink:

Viele Grüße

Wilfried

18

Hi Frank,

käme ich auch an den Quelltext dieses Dokuments, damit ich ein paar Sachen korrigieren kann?

Ich pushe mal die momentanen Änderungen und versuche dann noch deine Vorschläge bezüglich img-prep einzubauen.

Jemand von den Entwicklern muss ich dann noch mit dem paketieren und pushen des linuxmuster-client-adsso belästigen.
VG, Tobias

19

Hallo,

Das PNG beinhaltet das XML für drwa.io. Beim speichern muss man dann eben drauf achten, dass das wieder mit dem XML drin als PNG gespeichert wird. Kurz: Du kannst das PNG mit draw.io öffnen und dort bearbeiten.

VG

Frank

20

super, danke.