Das default-Verhalten kannst du eine Zeile tiefer auch einstellen: DefaultAction = start # default action on automatic start: start|sync|new
Kann man nicht pauschal sagen – es liegt daran, WO du das änderst. Wenn du in der .postsync etwas machst, wird das natürlich erst im Client eingetragen, sobald du mind. einen Sync-Start gemacht hast. Wenn du auf dem Client direkt in der /etc/hosts etwas geändert hast, reicht ein reboot.
(… wobei es in dieser Konstellation natürlich auch sein kann, dass du auf dem Client etwas änderst, dann einen Sync-Start machst, und dich dann wunderst, warum deine Änderung wieder weg ist. Das geschieht natürlich genau dann, wenn in der .postsync-Datei steht, dass die Datei XY so auszusehen hat. Dann wird sie bei jedem sync-Start auch in diesen Zustand versetzt…)
Wie gesagt: Das .postsync ist einfach ein Script, das ganz am Ende der Synchronisation in Gang gesetzt wird. Damit kann man diverse Dinge nachträglich patchen/einstellen/ändern. Das ist gut dokumentiert – kennst du die Anleitung? Man kann damit auch einzelne Rechner einer Gruppe ganz unterschiedlich behandlen. Jedenfalls sind die Änderungen direkt nach dem Ende der Synchronisation aktiv. Sobald der Rechner dann durchstartet ist alles so, wie vom .postsync vorgegeben.
Naja, es ist kein Fehler, es hat mich nur die Inkonsistenz in dem
hosts-File irritiert. Ich dachte, die groß geschriebenen Wörter würden
ersetzt (gepatcht wie du sagst). Aber dem ist nicht so. Und es ist mal
mit einem Hash (#SERVERIP), mal ohne (HOSTNAME). Das is nicht
verständlich.
ja: ist doof: da hast du recht: aber irgendwie ist das schon seit Jahren
so … hat halt keiner geändert …
Und schliesslich scheinen da auch Artefakte zu sein, die
zusätzlich das Verständnis schwierig machen, dies
DOMAINmeineschule.linuxmuster (warum stehen da plötzlich zwei Level?,
und warum plötzlich meineschule) wärend an anderer Stelle, wo dasselbe
gemeint ist „DOMAINbzpf“ steht - was auch immer bzpf ist.
bzpf = Bildungszentrum Pfinztal.
bzpf.lan ist die Domain in meiner Schule: und das hat in deiner hosts
Datei nichts zu suchen.
Keine Ahnung wo das her kommt.
Ich liefere (derzeit) diese hosts Datei mit dem cloop zusammen aus:
# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem
Server."
# Pfad: ${linbodir}/${universalpostsyncdir}/${patchclass}/${HOSTS}
# HOSTNAME wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 HOSTNAME.meineschule.linuxmuster.lan HOSTNAME
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server
eingetragen sind...
#SERVERIP server.meineschule.linuxmuster.lan server
## damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
#SERVERIP server.lokal server.local
Klarer wäre
wenn klar markiert wäre „dies ist etwas das man manuell ändern muß“
entgegen „dies ist etwas, dass automatisisiert gepatcht wird“.
so hab ich das eigentlich im Readme geschrieben: sehr Ausführlic, wie
ich finde.
Anbieten tun sich spitze Klammern wie || und im Readme dann nur
ein klarer Hinweis darauf.
das ist eine gute Idee: mach ich gleich.
Die Sache mit dem Hash sollte erklärt werden oder konsistent gemacht
werden (sind das 2 verschiedene Patch-Läufe?).
besser ist es, das zu beheben: also einfach die Variable in der
.postsync Datei änndern…
Wenn ich den |Autostart = yes| setze, wie startet er dann denn? Direkt?
er macht das was als DefaultAction definiert ist in der start.conf.
und zu der Frage wann die .postsync Datei ausgeführt wird … nunja: sie
heißt postsync
Und zu deinem Client:
verwende linbo-remote
Damit kannst du syncen ohne zu starten: danach kannst du per linbo-ssh
auf den Cleint, die Partition mounten und schauen, ob alles richtig ist.
zu unterscheiden sind abei drei wichtige Schalter:
-w 55 → wecke den Rechner auf und schicke 55 Sekunden später den
hinter -c angegebenen Befehl
-c der/die Befehl/e wird/werden direkt geschickt (es sei
den es gibt einen delay durch -w)
-p hier wird eine „Falle“ gelegt, und wenn der Rechner das
nächste mal eingeschaltet wird und in linbo vorbei kommt, dann führt er
aus, was der Befehl vorgibt.
Manch einer verwendet -p und macht danach einen etherwake um die Rechner
zu wecken.
Ich bin einer von denen, die immer -w verwenden… Geschmackssache.
Ich mag -p nicht so sehr weil, wenn der Client nicht aufwach, dann hab
ich eine Zeitbombe.
Sagen wir ich hab
format,sync:1,sync:2,start:2
befohlen (mach ich manchmal) und einer wacht nicht auf: dann kommt am
nächsten Tag MOrgends ein Schüler und schaltet den Rechner ein: der
partitioniert und synct 2 Betriebsysteme: das dauert über 20 Minuten…
Kleine Schritte: Ich habe logfile-Einträge, wenn ich mich anmelden will:
Mar 2 22:34:18 nb001 lightdm: pam_unix(lightdm:auth): check pass; user unknown
Mar 2 22:34:18 nb001 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Mar 2 22:34:18 nb001 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=michaeld
Mar 2 22:34:18 nb001 lightdm: pam_sss(lightdm:auth): received for user michaeld: 10 (User not known to the underlying authentication module)
Der Benutzer mit dem Passwort wurde wunderbar importiert. An der Web-GUI kann ich mich damit auch prima anmelden. Der Client allerdings schickt nichteinmal eine LDAP-Anfrage an den Server, tcpdump zeigt keinerlei Traffic von dem Client.
Hast du denn bereits das Script linuxmuster-client-adsso-setup auf dem Client laufen lassen und anschließend ein neues Image erzeugt (so wie es im ReadMe von Holger stand)? Erst dann wird ja die .macct-Datei angelegt und ein User der Domäne kann sich erst dann anmelden…
(Ohne diesen Schritt ist der Client nicht in die Domäne aufgenommen bzw der Domain Controller „kennt“ oder besser „akzeptiert“ ihn nicht…)
… ach ja: Hier noch ein paar Background-Infos wie der Login abläuft:
Ich würde die hosts mit der client-ip ausstatten (statt auf 127.0.0.1 zu verweisen), den Server nur einmal nennen mit den entsprechenden Domains (ist das Deutsche „lokal“ wirklich korrekt?) und das Readme kürzen und sortieren (erst der minimale Installationsablauf, dann Bemerkungen).
Übrigens noch ein Wort zum Ubuntu-Client: Ich habe den Kernel unter Ubuntu hier wieder gegen einen aktuellen ersetzt – das läuft völlig problemlos. Man ist also nicht gezwungen, auf 4.15.0-60 zu bleiben. Wenn man sudo apt-get install --install-recommends linux-generic-hwe-18.04 verwendet, erhält man einen aktuellen 5.3er Kernel (zZ 5.3.0-28-generic #30~18.04.1-Ubuntu). Ich habe das gleiche auch schon auf anderen Ubuntu-18.04-VMs gemacht. Solange man also keinen Stress mit der Intel Onboard-GraKa hat, läuft das …
Ja, das hatte ich gemacht. Aber ich wiederhole das mal.
Ah, jetzt fällts mir auf: Ein Image muss ich ja pro walkthrough-Durchlauf machen, der walkthrough löscht es ja wieder und sync versetzt den Client in den alten Stand!
Oups, bekomme dann den Fehler:
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!
Übrigens noch ein Wort zum Ubuntu-Client: Ich habe den Kernel unter
Ubuntu hier wieder gegen einen aktuellen ersetzt – das läuft völlig
problemlos. Man ist also nicht gezwungen, auf 4.15.0-60 zu bleiben. Wenn
man |sudo apt-get install --install-recommends linux-generic-hwe-18.04|
verwendet, erhält man einen aktuellen 5.3er Kernel (zZ 5.3.0-28-generic
#30~18.04.1-Ubuntu). Ich habe das gleiche auch schon auf anderen
Ubuntu-18.04-VMs gemacht. Solange man also keinen Stress mit der Intel
Onboard-GraKa hat, läuft das …
auch ich bin seit einigen Wochen auf 5.3 auf dem 18.04 ubuntu Client.
Auf dem Client gibt es noch so einiges zu tun, zB ist in der sshd Konfiguration eine feste IP konfiguriert und ssh erstmal so nicht nutzbar.
Die Konsolen sind auch kaputt, da bin ich aber noch nicht dahintergekommen, warum.
Die .ssh/authorized_keys wird überschrieben mit einem ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPQgIN7XQVjT2BV7r9VhfmeP4BJhgrd4ZEbaulzq6PXrXgp5V5+4jIJ4yrlz/z2g6JmrvqH7oKtiKmZ1vPQPHCI= root@server.bzpf.lan - auch irgendwie falsch
Auf dem Client gibt es noch so einiges zu tun, zB ist in der sshd
Konfiguration eine feste IP konfiguriert und ssh erstmal so nicht nutzbar.
… das ist nicht im postsync: das muss man also noch selber eintragen.
Die Konsolen sind auch kaputt, da bin ich aber noch nicht
dahintergekommen, warum.
Die |.ssh/authorized_keys| wird überschrieben mit einem
ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPQgIN7XQVjT2BV7r9VhfmeP4BJhgrd4ZEbaulzq6PXrXgp5V5+4jIJ4yrlz/z2g6JmrvqH7oKtiKmZ1vPQPHCI=
root@server.bzpf.lan| - auch irgendwie falsch
du hast, denke ich, eine alte Version des default.cloops bei dem im
postsyncverzeichnis auf dem Server noch der Pfacd:
bionic/common/root/.ssh/
mit einer authorized-keys dabei war.
Das ist inzwischen nicht mehr dabe
Ja, die wurde neu erstellt, aber darin steht dn: @@dn@@, was nach Templating aussieht - ist das richtig?
Anyway ich kann einen weiteren Erfolgsschritt vermelden: Ich kann mich mit einem migriertem Benutzer anmelden. Der Proxyzugriff im Firefox benötigt allerdings eine weitere User/Password-Eingabe (dann geht’s allerdings), das ist für SSO eher nicht richtig, oder?
Das hängt davon ab, ob dein Client in der OPNSense Firewall unter „NoProxy“ mit aufgeführt ist oder nicht. Ein paar Clients (aus dem Gedächtnis ca 19 IPs) sind dort eingetragen. Die dürfen auch ohne Proxy-Auth. surfen.
Wenn du hier im Forum nach „Domänenbeitritt“ suchst, gibt es einige, die Probleme damit hatten – bei anderen lief es sofort. Wenn dein Script den Domänen-Zugang aber sofort mit erledigt, wären ganz sicher viele davon sehr angetan!
Steht bei mir auch drin: dn: @@dn@@ – obwohl die Anmeldung funktioniert.
Bug gefunden?
Diese Einträge stehen dort bei mir auch (clientseitig). Dazu kommt noch unser eigener Key (.pem)
Das passiert, entweder …
… wenn du per ssh auf dem Client bist und in der Konsole arbeitest (gefällt mir auch nicht, dass es dann nciht ootb funktioniert) …
… oder dein Client noch nicht unter NoProxy mit aufgeführt ist. Wenn er das ist, kannst du unter X11/Wayland (was ist es?) eine (grafische) Konsole aufmachen und der Befehl funktioniert …
