Was meinst du mit „da“? Die liegen ja in
/var/lib/samba/private/tls/<DOMAIN>.lan.pem obwohl das Script sie in
/var/lib/samba/sysvol/<DOMAIN>.lan/tls/cacert.pem erwartet. Das ist schon ein Unterschied 
Wer hat Recht? Und warum geht das bei dir?
Ich denke, ich sollte hier ansetzen. Was heisst veraltet und wie komme ich an ein aktuelles?
Ich habe ein apt upgrade gemacht aber das trifft natürlich nicht Dateien, die gar nicht paket-system-kontrolliert sind und einfach so ins System geschrieben wurden (darum ist das ja auch so unschön, das zu tun ). Muss ich also damit rechnen, immer mal wieder das image (oder cloop wie ihr es nennt) updaten zu müssen, wenn sich solche Dateien ändern?
Verstehe ich nicht… unser Workflow geht so: In 99% der Fälle starten die Clients einfach un-/synchronisiert. Wenn sich auf dem Master aber gravierende Änderungen ergeben (z.B. neues Firefox, neues LibreOffice, neues VirtualBox), erstelle ich ein neues Image (die Bezeichnung .cloop gab es meines Wissens schon vorher – ist das nicht von K. Knopper so eingeführt worden??).
Dieses Image wird dann neu ausgerollt und auf alle Clients der gleichen HWK verteilt. Wenn einzelne Dateien geändert werden, tue ich das tunlichst NUR auf dem Master-Client und notiere es auch im Installations-Logbuch. Sonst ist so eine Information ziemlich sicher verloren.
Natürlich kann man gezielte Änderungen auch mit dem universellen Postsync-Script erledigen lassen. Das ist manchmal eine Frage, was gerade besser passt bzw was „bequemer“ ist.
Jetzt klar – oder verstehe ich die Frage nicht??
Hier ist z.B. mal eine Änderung, die ich mir selbst zusätzlich in meine .postsync-Datei geschrieben habe, damit ich jederzeit sehen kann, wann der Client zuletzt synchronisiert wurde:
# Last-Sync auf Client loggen:
LOGFILE=/mnt/last-SYNC.log
echo "$(date) - $(hostname) der Gruppe $(hostgroup) wurde synchronisiert!" > $LOGFILE
Hallo Michael,
Ich denke, ich sollte hier ansetzen. Was heisst veraltet und wie komme
ich an ein aktuelles?
… ich lad es gerade hoch: link gibt es nachher.
Ich habe ein |apt upgrade| gemacht aber das trifft natürlich nicht
Dateien, die gar nicht paket-system-kontrolliert sind und einfach so ins
System geschrieben wurden (darum ist das ja auch so unschön, das zu tun
cloop wie ihr es nennt) updaten zu müssen, wenn sich solche Dateien ändern?
nein.
In der früheren Version war das wohl noch nicht so glatt gebügelt…
LG
Holger
Das ist alles klar. Ich meine die Dateien, die auf dem Image sind, die nicht unter Paketkontrolle stehen und linuxmuster ausmachen und nötig sind für die korrekte Funktion. Wenn linuxmuster davon eine neue Version herausbringt in den Cloops (oben wurde ja erwähnt, ich hätte eine veraltete Version) - wie komme ich dann da dran, wenn apt update && apt upgrade die garnicht updaten können?
Klar mache ich Änderungen auf dem Image und lade es auf den Server. Und genau da ist ja das Problem: Alles was ich manuell in das Image pflege für uns hier geht ja verloren, wenn ich eine nicht mehr veraltete Version herunterlade und synce.
Erklärt das meine Sorge?
Hi.
… ach solche Änderungen meintest du. Ja, die mag es geben aber die hatte ich gar nicht auf dem Schirm. Und zwar aus einem einfachen Grund: Nach meiner Erfahrung bestehen solche Änderungen am laufenden System oft aus einzelnen geänderten Dateien oder zu treffenden minimal anderen Einstellungen. Sehr selten kommt dabei ein ganz anderes Paket zum Einsatz; noch seltener (nie?) ein eigens kompiliertes Paket, das nur über ein neues Image verteilt werden könnte. Daher ist auch das nachträgliche, eigenständige Einpflegen meistens keine allzu große Sache. Und daher hält sich meine Sorge auch in Grenzen… (So wie zB im Moment im Parallelthread: Bionic Client Download - #5 von Michael)
(Natürlich kann es geschehen, dass man nicht alles mitbekommt, wenn man nicht regelmäßig hier mitliest. Aber meistens erinnert sich dann irgendwer daran, dass solche Anfragen schon mal kamen … zumindest kommt es mir so vor).
Hinzu kommt, dass auf dem Client ja durchaus eigene Linuxmuster-Pakete installiert sind, die sehr wohl der apt-Paketverwaltung unterliegen. Somit bleiben auch diese Pakete aktuell und der Fall tritt meiner Meinung nach nicht wirklich ein.
Es kann natürlich passieren, dass man unbedingt etwas in sein eigenes Image einbauen will, weil es an der eigenen Schule unverzichtbar ist. Das kann schon mal ärgerlich sein … kommt aber nur alle Jubeljahre vor…
Schöne Grüße,
Michael
Hallo Michael,
du hast, denke ich, eine alte Version des default.cloops
die aktuelle Version ist hier:
https://web.semgym-karlsruhe.de/owncloud/index.php/s/GsQy9PfDWWiSGCT
LG
Holger
Darum benenne ich sie. Ich denke, solche Dateien sollte es in einem finalen, stabilen Image nicht geben. So kommt man zu einem stabilen Gesamtsystem, bei dem die Pflege wenig Zeit in Anspruch nimmt.
Oder wir machen wieder Slackware 
Die anderen Dinge, die du anspricht kritisiere ich ja garnicht. Das linuxmuster Pakete hat oder man individuelle Dateien für die lokale Installation braucht - keine Frage. Aber eben anderes Thema.
Ok, dann sind wir uns ja einig 
Was immer wirklich Arbeit erzeugt ist ein Versionssprung. Wir haben in unseren Computerräumen z.B. noch Ubuntu 16.04 LTS laufen. Das funktioniert zwar immernoch gut – aber ein Upgrade auf 18.04 ist nicht so ohne weiteres möglich. Zudem wäre ja die Anbindung von v6.x --> v7 zu ändern, was so imho nicht vorgesehen ist und ziemlich kompliziert wäre…
Hallo,
funktioniert zwar immernoch gut – aber ein Upgrade auf 18.04 ist nicht
so ohne weiteres möglich. Zudem wäre ja die Anbindung von v6.x → v7 zu
ändern, was so imho nicht vorgesehen ist und ziemlich kompliziert wäre…
genau.
Das kann man schon machen, aber dann muss man sich warm anziehen …
Deswegen empfehlen wir lieber: für die lmn7 den neuen 18.04 default
Client zu nehmen und sich an zu passen.
LG
Holger
Ich muß hier nochmal ein Lob loswerden, es macht wirklich Spaß mit dem LMv7, es ist tolle Arbeit gemacht worden. Da ich hier immer nur herumkritisiere möchte ich das betonen: Generell ist es wirklich toll was da geht!
Ich Automatisiere gerade den LINBO-Ablauf und das flutscht nur so - Prima! Und Danke.
Ok, ich hatte mich am WE ausgesperrt: Hatte den Client im LINBO stehen lassen und dann mein walkthrough angeworfen. Danach kam ich nicht mehr auf den Client (klar: Der Server generiert einen neuen Key sodass ich per ssh nicht mehr autorisiert bin - klasse, wenn man 25km weit weg ist 
). Aber sowas ist eben „selber Schuld“.
2 „Gefällt mir“
So, ich habe die aktuelle Version heruntergeladen, das walkthrough durch LINBO-Automatisierung erweitert und stoße auf dieselben Probleme:
Es gibt noch alte Zertifikate in dem Image:
# find /var/lib/samba -name \*.pem
/var/lib/samba/private/tls/bzpf.lan.pem
/var/lib/samba/private/tls/linuxmuster.windeck-gymnasium.de.pem
/var/lib/samba/private/tls/lmn.lan.pem
Beim Versuch das Zertifikat zu kopieren, mounted das Script ein cifs Laufwerk. Das schlägt fehl:
Installing server certificate ... mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
cp: Aufruf von stat für '/var/lib/samba/sysvol/fsmw.lan/tls/cacert.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden
umount: /var/lib/samba/sysvol: nicht eingehängt.
Failed!
Das Script behandelt keinerlei Fehler und rennt einfach weiter. Nach dem fehlgeschlagenen mount schlägt cp fehl, danach das umount. Ein Fehler wird dubioser Weise dann aufgrund der Existenz der Datei gemeldet…
Der initiale Fehler scheint mir „Required key not available“ zu sein. Ist das nicht ein Henne & Ei Problem? Wenn ich den Key kopieren will vom Server und für den Mount den Key brauche?
Ich habe den Key auf dem Server gefunden und per scp manuell an die richtige Stelle kopiert. Auch das hilft aber nicht den mount auszuführen.
Hi.
Ich habe zwar keine Lösung aber ich habe die Dateien gerade verglichen:
Das cert auf dem Server unter
/var/lib/samba/sysvol/linuxmuster.meine-domain.de/tls/cacert.pem
und das cert auf dem Client unter
/var/lib/samba/private/tls/linuxmuster.meine-domain.de.pem
sind hier jedenfalls identisch.
Wo die nun aber herkommen bzw wer da was von wo kopiert, müssten die Entwickler beantworten…
Wenn du auf dem Client in die Datei /usr/sbin/linuxmuster-client-adsso-setup ab Zeile 194 schaust, steht eigentlich alles da … das cert wird als global-admin rüberkopiert
Schöne Grüße,
Michael
Genau. Dafür mounted der eine Freigabe vom Server. Dafür braucht er einen Key, den er nicht hat. Aber der Key, den er gerade kopieren will ist es nicht, ich hab ihn ja per scp dahinkopiert. Beim mounten gibts denselben Fehler.
Dies ist der mount-Befehl, den er abfeuert (vorher ein kinit global-admin:
mount -o sec=krb5,user=global-admin //fsmw.lan/sysvol /var/lib/samba/sysvol
Was tut/sagt der bei dir?
Hallo,
Das cert auf dem /Server/ unter
/var/lib/samba/sysvol/linuxmuster.meine-domain.de/tls/cacert.pem|
und das cert auf dem /Client/ unter
/var/lib/samba/private/tls/linuxmuster.meine-domain.de.pem|
sind hier jedenfalls identisch.
die Frage ist, weswegen das cert bei MDT auf dem Server fehlt.
Es scheint ja kein Client, sondern ein Serverproblem zu sein.
Wurde linuxmuster-setup schon ausgeführt?
LG
Holger
Ja, im walkthrough-Flow ist das dabei.
Welches cert fehlt? Das mount vermisst einen key…
Der Server hat keine log-Ausgaben zu dem Fall.
Der Client schon:
Mar 5 08:44:20 bw-nb01 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=server.fsmw.lan;ip4=10.0.0.1;sec=krb5;uid=0x0;creduid=0x0;user=global-admin;pid=0x83e
Mar 5 08:44:20 bw-nb01 kernel: [ 5446.331394] CIFS VFS: Send error in SessSetup = -126
Mar 5 08:44:20 bw-nb01 kernel: [ 5446.331424] CIFS VFS: cifs_mount failed w/return code = -126
Mar 5 08:44:20 bw-nb01 cifs.upcall: ver=2
Mar 5 08:44:20 bw-nb01 cifs.upcall: host=server.fsmw.lan
Mar 5 08:44:20 bw-nb01 cifs.upcall: ip=10.0.0.1
Mar 5 08:44:20 bw-nb01 cifs.upcall: sec=1
Mar 5 08:44:20 bw-nb01 cifs.upcall: uid=0
Mar 5 08:44:20 bw-nb01 cifs.upcall: creduid=0
Mar 5 08:44:20 bw-nb01 cifs.upcall: user=global-admin
Mar 5 08:44:20 bw-nb01 cifs.upcall: pid=2110
Mar 5 08:44:20 bw-nb01 cifs.upcall: get_cachename_from_process_env: pid == 0
Mar 5 08:44:20 bw-nb01 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_0
Mar 5 08:44:20 bw-nb01 cifs.upcall: krb5_get_init_creds_keytab: -1765328203
Mar 5 08:44:20 bw-nb01 cifs.upcall: Exit status 1
Hallo Michael,
in die Datei |/usr/sbin/linuxmuster-client-adsso-setup| ab Zeile 194 schaust, steht eigentlich alles da … das cert wird als >global-admin| rüberkopiertGenau. Dafür mounted der eine Freigabe vom Server. Dafür braucht er
einen Key, den er nicht hat.
nein: er hat beim adsso Lauf natürlich noch keinen passenden Key: aber
er bekommt ja die credentials des global-admin: und mit denen mountet er
das sysvol und kopiert dann den key.
Liegt bei dir auf dem Server der key?
hast du bei der initialen Aufnahme des Clients folgendes gemacht:
- er ist in der workstations auf dem server und importiert
- die /etc/k3b.keytab (oder so) wurde gelöscht
- die /etc/fstab ist korrekt gepatched: Domain und Rechnernamen stimmen
- wenn das alles OK ist, dann kannst du linuxmuster-client-adsso laufen
lassen.
LG
Holger
Hallo Michael,
Mar 5 08:44:20 bw-nb01 cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=server.fsmw.lan;ip4=10.0.0.1;sec=krb5;uid=0x0;creduid=0x0;user=global-admin;pid=0x83e
/etc/krb5.keytab vor Domänenaufnahme am Client gelöscht?
Vielelicht versucht er den Key, wenn die Datei da ist.
Also erst löschen, dann nimmt er die Credentials.
nur so eine Idee
LG
Holger
Nein, genau das schlägt ja fehl wie ich schrieb.
Ja.
Das verstehe ich nicht. Ich habe die MAC in eine devices.csv aufgenommen - meinst du das?
Ja.
Die Datei enthält bei mir keine Rechner oder Domainnamen, nur lokale Geräte.
Gerade nochmal gemacht, keine Änderung.
Für uns alle zum merken:
Wenn die Uhrzeit nicht stimmt, geht nix mit Kerberus!
Die Uhr lief vor: 05.03.2020 09:16:16 statt 2020-03-04T22:22. Das mag der Höllenhund garnicht … puh! Danke für eure Hilfe
Apropos: Das Readme erwähnt /srv/linbo/linuxmuster-client/bionic/common/etc/systemd/timesync.conf die ich nicht habe… auch auf dem client nicht. Sie heisst …syncd…