Wenn ich es so starte endet es mit „Failed“. Die Ausgabe davor enthält
eine dubiose Zeile:
Hostname: 3(NXDOMAIN).lmn.lan |
Namensauflösung ist falsch.
Hast du das default.cloop korrekt eingerichtet?
Von mir gibt es dazu ein ausführliches readme.
Ich habe ausserdem gesehen, dass das DNS nicht korrekt ist. Ein |dig -x
10.0.0.1| führt zu |server.DOMAINbzpf.lan|.
daran kann man erkennen, dass die Einrichtung nicht korrekt gemacht
wurde: deswegen klappt auch die Domänenaufnahme nicht.
Die Domain bzpf stammt aus meiner Schule: Bildungszentrum Pfinztal: nach
korrekter Einrichtugn ist das nciht mehr da.
Kontrollier die /etc/hosts auf dem Cleint und dann ob die
/srv/linbo/linuxmuster-client/bionic/common/etc/hosts korrekt editiert
wurde (-> siehe Readme).
postsync Datei nicht vergessen zu kontrollieren (auch die Rechte).
Ist der Client also /nicht/ allgemeingütlig, weil er Einstellungen
enthält die für die Schule individuell sind?
ein „allgemeingültiger“ Client ist nicht möglich, weil seit 14.04 das
Eintragen der Domain am Client durch die DHCP Meldung nicht mehr klappt.
Deswegen muß das gepatched werden.
Und deswegen gibt es ein umfangreiches Readme zum default cloop.
Ah, ich habe den Punkt 9,10 überlesen. Okay. Ich mache mal den ganzen flow…
Eins nervt bei den Clients: Die schalten sich aus. Erst dachte ich, die HW wär kaputt. Ich arbeite ja viel „von remote“ und der Client war, als ich zuhause arbeiten wollte immer einfach ‚weg‘ und wenn ich am nächsten Tag in der Schule war, einfach aus. Vorgestern saß ich allerdings dran, als der plötzlich meinte, er fährt gleich runter. Einfach so. Aus dem nichts. Was ist das?!? Will Ubuntu mir sagen, wann ich den Rechner runterfahren soll? Was für ein Feature ist das?
It’s not a bug – it’s a feature.
Viele hier nutzen die Linux-Clients in Computerräumen und schalten den ganzen Raum morgens remote an. Wenn dann am Nachmittag niemand dafür gesorgt hat, dass sie auch wieder heruntergefahren werden, sorgt ein Cronjob dafür, dass sich der Client automatisch beendet. Das kannst du aber schnell deaktivieren …
Du findest den Eintrag unter /etc/cron.d/linuxmuster-client – ich habe das auch temporär deaktiviert.
Vielleicht sollte man das lieber vom Server aus tun? Und nur, wenn man es aktiv einschaltet? Das macht keinen guten Eindruck, wenn die Clients einfach sang- und klanglos sterben, sobald man LM installiert hat
So lauter auch die Gründe sind, Strom zu sparen, klar.
Ja, das man müsste es vermutlich entweder dokumentieren oder aber nachträglich einschalten …
Ja, dazu habe ich ein Script, das remote einen beliebigen Befehl ausführt – so auch „poweroff“. Das Thema wurde hier schon öfter diskutiert. Es eignet sich auch hervorragend pssh dazu
„sang und klanglos“ ist das nicht: die fragen nach und warten dann auch
zwei Minuten auf Rückmeldung: es sei denn, es ist niemand angemeldet:
dann fahren sie direkt herunter.
Feb 28 20:24:06 pxeclient lightdm: pam_unix(lightdm:auth): check pass; user unknown
Feb 28 20:24:06 pxeclient lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Feb 28 20:24:06 pxeclient lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=michaeld
Feb 28 20:24:06 pxeclient lightdm: pam_sss(lightdm:auth): received for user michaeld: 10 (User not known to the underlying authentication module)
In meiner /etc/sssd/sssd.conf steht:
# ad_hostname = 3(NXDOMAIN).xxxx.lan
Da scheint also noch etwas schief zu gehen. Ok, es ist auskommentiert, zieht also wohl nicht, dennoch. In der /etc/hosts steht allerdings auch noch komisches:
# pxeclient.DOMAINwird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 pxeclient.DOMAINmeineschule.linuxmuster.lan pxeclient
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server eingetragen sind...
10.0.0.1 server.DOMAINbzpf.lan server
## damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
#10.0.0.1 server.DOMAINlokal server.local
Irgendwie scheint da ein Patchen fehlzuschlagen. Ich hab die Einträge korrigiert aber kann mich immer noch nicht anmelden.
Ich habe ein tcpdump mitlaufen lassen: Das sieht keine Pakete. Ein lookup im ldap findet also garnicht statt.
Wo könnte ich noch schauen?
Ach ja, auf der Console kann man sich nicht anmelden:
Feb 28 23:39:53 pxeclient login[1477]: PAM _pam_load_conf_file: unable to open /etc/pam.d/common-pammount
Feb 28 23:39:53 pxeclient login[1477]: PAM error loading (null)
Feb 28 23:39:53 pxeclient login[1477]: PAM _pam_init_handlers: error reading /etc/pam.d/login
Feb 28 23:39:53 pxeclient login[1477]: PAM _pam_init_handlers: [Critical error - immediate abort]
Feb 28 23:39:53 pxeclient login[1477]: PAM error reading PAM configuration file
Feb 28 23:39:53 pxeclient login[1477]: PAM pam_start: failed to initialize handlers
Feb 28 23:39:53 pxeclient login[1477]: Couldn't initialize PAM: Critical error - immediate abort
Erzeugt man die Datei (leer), kann man sich zumindestens anmelden.
pxeclient.DOMAINwird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost 127.0.0.1
pxeclient.DOMAINmeineschule.linuxmuster.lan pxeclient #Die nächste Zeile
enthält die Hostnamen so, wie sie auf dem Server eingetragen sind…
10.0.0.1 server.DOMAINbzpf.lan server ## damit CUPS zufrieden ist, muss
noch diese Zeile hier dazu: #10.0.0.1 server.DOMAINlokal server.local |
Irgendwie scheint da ein Patchen fehlzuschlagen. Ich hab die Einträge
korrigiert aber kann mich immer noch nicht anmelden.
Ich habe ein |tcpdump| mitlaufen lassen: Das sieht keine Pakete. Ein
lookup im ldap findet also garnicht statt.
Wo könnte ich noch schauen?
hast du die Verzeichisstrucktur auf den Server bewegt nach /srv/linbo/
?
Hast du nun also
/srv/linbo/linuxmuster-client/bionic/…
ISt eine
imagename.cloop.postsync Auf dem server?
ISt es die aus meinem .zip?
Stimmen die Rechte dieser Datei und die der Dateien unter
/srv/linbo/linuxmuster-client/bionic/…
Alles: „Ja“ (eins allerdings in andrem Verzeichnis: /srv/linbo/lmn-bionic.cloop.postsync). Sonst würde der Client ja garnicht booten. Ich sehe das ja bereits auf dem Client, nachdem da das Script gelaufen ist und ich syncronisiert habe.
ISt eine
imagename.cloop.postsync Auf dem server?
ISt es die aus meinem .zip?
Stimmen die Rechte dieser Datei und die der Dateien unter
/srv/linbo/linuxmuster-client/bionic/…
Alles: „Ja“ (eins allerdings in andrem Verzeichnis:
/srv/linbo/lmn-bionic.cloop.postsync|).
das ist kein Verzeichnis, sondern eine Datei (die postsync Datei).
Ist das Verzeichnis, genau so wie ich es hier schreibe, da?
/srv/linbo/linuxmuster-client/bionic/…
Dort drin gibt es dann
/srv/linbo/linuxmuster-client/bionic/common/etc/hosts und fstab
Erläuterung: wie das Verzeichnis unterhalb von
/srv/linbo/linuxmuster-client/
heißen muss, steht in der postsync Datei weit oben:
PATCHCLASS="bionic"
Das steht so in „meinem“ postsync: deswegen muss das Verzeichnis
unterhalb von
/srv/linbo/linuxmuster-client/
bionic heißen und nicht irgendwie anders.
Ich wei? ist komplex: den Hintergrund zu erklären hilft hoffentlich bei
der Fehlerfindung
Das hatte ich auch nicht gesagt, ich sagte „allerdings in andrem Verzeichnis“, da du von /srv/linbo/linuxmuster-client/bionic/… sprachst, aber die postsync-Datei nicht da zu finden ist sondern in /srv/linbo/.
Das Verzeichnis von dem du sprichst, das aber nicht die postsync-Datei enthält ist genau so da wie du es nennst. Ja.
Ja, die Dateien gibt es, wenn auch mit dubiosem Inhalt, da drin steht das
#SERVERIP server.DOMAINbzpf.lan server
was auch immer das bzpf bedeuten soll (ist ja Kommentar, wird wohl nicht genutzt). Mir kommt alerdings auch
komisch vor, da da kein Punkt zwischen DOMAIN und meineschule ist und meineschule da ja sowieso nicht hingehört, oder?
Tut es.
Finde ich gar nicht. Es ist nur (noch) mager dokumentiert Aber ich denke, wir suchen da an der falscher Stelle, da der Client ja bootet, synced, installiert und rennt. Allein er Autorisiert nicht gegen den LDAP scheint mir.
komisch vor, da da kein Punkt zwischen DOMAIN und meineschule ist und
meineschule da ja sowieso nicht hingehört, oder?
HOSTNAME wird gepatched durch den postsync: du mußt das so ändern, dass
es auf deine Domain paßt.
Sagen wir, deine Domain ist.
meineschule.lan, dann muss die Zeile lauten:
127.0.0.1 HOSTNAME.meineschule.lan HOSTNAME
Ich wei? ist komplex: den Hintergrund zu erklären hilft hoffentlich bei
der Fehlerfindung
Finde ich gar nicht. Es ist nur (noch) mager dokumentiert
… welche Fehler habe ich den in meinem Readme: was ist den da noch
nicht klar?
Das ist eine Ernste Frage: ich will das besser machen
Aber
ich denke, wir suchen da an der falscher Stelle, da der Client ja
bootet, synced, installiert und rennt. Allein er Autorisiert nicht gegen
den LDAP scheint mir.
… kann sie ja nicht, wenn die Domain nicht stimmt.
Alles Mist, was ich hier geschrieben hatte, da mein walkthrough die Datei anfasst und manches dadurch entsteht.
Muss also nochmal schauen, was mich irritiert hatte.
Dies ist das Original aus dem ZIP:
# 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.bzpf.lan server
## damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
##SERVERIP server.lokal server.local
Was auffällt ist die Inkonsistenz der Domain (meineschule.linuxmuster und bzpf.) und das Durcheinander mit ‚k‘ und ‚c‘ (bei ‚local‘ - ist das Absicht? Aber auch bei Skript). Ungut finde ich, dass gleiche IPs mehrfach vorkommen, ich sehe eine hosts als 1:n-Beziehung, nicht n:n.
Meine hosts sieht nun so aus:
127.0.0.1 HOSTNAME.<DOMAIN>.lan HOSTNAME localhost
#SERVERIP server.<DOMAIN>.lan server server.local server.local
Unschön ist ausserdem, dass HOSTNAME.<DOMAIN>.lan auf localhost zeigt, das sollte ja 10.0.0.99 (in meinem Fall) sein. Gibt es ein HOSTIP wie HOSTNAME?
Hi.
Ich bin nicht sicher, ob bei die die Pfade richtig sind – daher nur nochmal zur Sicherheit:
Unter:
[root@server:/srv/linbo]$ ls -la |grep lmn-
-rw-rw-r-- 1 root root 9939347277 Feb 16 12:54 lmn-bionic.cloop
-rw-rw-r-- 1 root root 53 Feb 16 12:09 lmn-bionic.cloop.desc
-rw-rw-r-- 1 root root 139 Feb 16 12:54 lmn-bionic.cloop.info
-rw------- 1 root root 4266 Feb 16 18:44 lmn-bionic.cloop.macct
-rw-rw-r-- 1 root root 4212 Nov 16 22:28 lmn-bionic.cloop.postsync
-rw-rw-r-- 1 root root 758526 Feb 16 13:01 lmn-bionic.cloop.torrent
(… ich muss nochmal nachsehen, warum das .cloop bei mir so riesig geworden ist … ). Die Rechte der .postsync-Datei müssen ebenfalls stimmen – sonst wird sie nicht abgearbeitet!
Dazu der Eintrag in der start.conf.bionic :
[LINBO] # global section
Server = 10.16.1.1 # linbo server ip address
Group = bionic
...
BaseImage = lmn-bionic.cloop # filename of main image (extension .cloop)
...
Damit sollte die Anmeldung funktionieren.
Die Abkürzung bzpf stammt von Holgers Schule – hatte er neulich schon mal irgendwo aufgeschrieben. Das wird aber überschrieben…
In meiner /etc/hosts-Datei auf dem Server steht lediglich:
127.0.0.1 localhost
10.16.1.1 server.linuxmuster.meine-domain.de server
10.16.1.2 ... (weitere Einträge, die auf andere VMs zeigen)
root@server:/srv/linbo# ls -la |grep lmn-
-rw-r--r-- 1 root root 7892667777 Nov 12 17:10 lmn-bionic.cloop
-rw-r--r-- 1 root root 227 Nov 12 17:10 lmn-bionic.cloop.desc
-rw-r--r-- 1 root root 139 Nov 12 17:10 lmn-bionic.cloop.info
-rw-r--r-- 1 root root 3860 Nov 12 17:10 lmn-bionic.cloop.postsync
-rw-r--r-- 1 root root 602343 Feb 23 11:49 lmn-bionic.cloop.torrent
root@server:/srv/linbo# grep -A 3 LINBO start.conf.bionic
# LINBO start.conf, example for ubuntu
# DON'T EDIT THIS FILE! MAKE A COPY AND ADAPT THE VALUES TO YOUR NEEDS!
# operating system on partition 1
# cache on partition 2
--
[LINBO] # global section
Server = 10.0.0.1
Group = bionic
# IMPORTANT: server and group will be automatically set during device import!
root@server:/srv/linbo# cat /etc/hosts
# modified by linuxmuster-prepare at 20200223113647
# /etc/hosts
#
# thomas@linuxmuster.net
# 20160902
#
127.0.0.1 localhost
10.0.0.1 server.fsmw.lan server
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@server:/srv/linbo#
Wie bei dir / gewünscht, oder?
Eine offene Frage ist: Wann wird das wie auf den Client übertragen, gepatcht und verarbeitet? Reicht ein reboot des Clients?
Und: Wenn ich den Client jetzt (ich bin nicht in der Schule ) reboote, bleibt er ja in Linbo hängen, kann ich von hier einstellen, dass er weiterbooten soll? Wie?
Das Übertragen des Cloops geschieht natürlich unter LINBO, wenn du den Punkt „Image erstellen“ wählst. Der bereitet dann zunächst alles lokal im Cache vor und übertragt anschließend das .cloop auf den Server. Dabei wird dann ganz am Ende auch die .macct-Datei erzeugt, die bei dir noch fehlt.
Die Postsync-Datei ist immer die letzte Aktion, die ausgeführt wird (daher auch der Name). Ein „normaler“ Start reich nicht aus, wenn man will, dass die .postsync-Aktion ausgeführt wird. Dazu muss man mindestens synchronisiert starten, was hier viele per default bei jedem Start machen (so ist es eigentlich auch gedacht). Wir starten diverse Clients auch unsynchronisiert – das allerdings nur aus Zeitgründen.
Wenn der Client im LINBO-Screen stehen bliebt, kannst du ihn ganz bequem per linbo-remote vom Server aus fernwarten. Du kannst aber alternativ auch in der start.conf.bionic den Parameter Autostart setzen, so dass der Client dann nach X Sekunden automatisch durchstartet. So mache ich das in unseren Computerräumen.
Autostart = yes # automatic start of os (yes|no)
AutostartTimeout = 3 # timeout in secs for user to cancel automatic start
Ich meinte nicht das cloop, sondern wann die von mir gerade geänderte hosts aktiv wird. Schon, wenn ich den client nur reboote? Oder muß ich dann wiederum das Client-setup-script laufen lassen? Oder erst nachdem ich gesynct habe? Oder erst wenn ich ein Image erzeuge und synce? Was passiert wann in dem ganzenn Flow?
Wenn ich den Autostart = yes setze, wie startet er dann denn? Direkt? Mit sync? Und wann wird das aktiv? Sofort? Oder erst nach sync? Oder Image?
Du siehst: Mir fehlt’s grundlegend Und ja, bestimmt steht das irgendwo in der Doku, aber es zu finden…
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.
Automatismen, die gegen Automatismen kämpfen…
) reboote, bleibt er ja in Linbo hängen, kann ich von hier einstellen, dass er weiterbooten soll? Wie?