neue Patchklasse in |/etc/linuxmuster/workstations| bei deiner VM
angeben
|import_workstations| laufen lassen
dann sollte eine |/var/linbo/start.conf.patchklasse| da sein (falls
nicht eine aus dem Beispielordner kopieren unter |/var/linbo/examples/|)
du hast patchklasse und hardwareklasse durcheinander gebracht.
In der workstations Datei wird die Hardwareklasse definiert.
Patchklasse ist immer Image (cloop) bezogen, weil sie in der zum cloop
gehörigen .postsync Datei drin steht.
Willst du eine neue Patchklasse, dann mußt du ein neues Image schreiben
(neuer Name) und dann kannst du in der postsync Datei eine andere
Patchklasse definieren.
Aber: wenn du ubuntu verwendest brauchst du das eigentlich nicht, da das
postsync Script einzelne Rechner und auch Räume unterscheiden kann: so
kannst du also auch ohne neue Patchklasse Recher unterschiedlich behandeln.
Jetzt kommst Du…
Ich muss doch in den Unterordnern der Patchklasse z.B. die /etc-Ordner fuer Gruppen, Rechner…ablegen, wo liegen die, wenn ich das postsync-Skript nutze?
So ganz klar ist mir das alles noch nicht, ich arbeite daran.
Ich muss doch in den Unterordnern der Patchklasse z.B. die /etc-Ordner
fuer Gruppen, Rechner…ablegen, wo liegen die, wenn ich das
postsync-Skript nutze?
Struktur bei mir:
/var/linbo/linuxmuster-client/trusty/
in dem Verzeichnis liegen die Verzeichnisse:
common für alle
r003 nur Raum r003
r004pc01 nur pc01 in r004
Unterhalb dieser Ordner steht logisch das Dateisystem des Cleints.
Für etc/fstab (für alle) also:
/var/linbo/linuxmuster-client/trusty/common/etc/fstab
Aber achtung: du kannst nicht alle Rechte so setzen, wie du magst.
Die Rechte werden schon so auf dem Client abgebildet: aber nur für root.
Und die Rechte dürfen nuicht zu restriktiv sein.
Beispiel: ich patche die authorized_keys für ssh, damit ich die Cleints
vom Server passwortfrei fernsteuern kann.
Die Datei benötigt aber 600.
Mit den Rechten kann sie linbo aber garnicht “anfassen” während des
postsyncs (keine Rechte da der Nutzer linbo ist und nicht root).
Also kopiere ich sie mit 666 (glaub ich) und setzte im postsync script
dann die Rechte nachträglich auf 600
So ganz klar ist mir das alles noch nicht, ich arbeite daran.
… hätte mich auch gewundert: das ist schon ein mächtiges Werkzeug: da
braucht auf der geneigte Leser ein Weilchen
Patchklasse “trusty” und diese wird in test01.cloop.postsync zugeordnet?
Das hat bei mir heute nicht funktioniert, das mit den Logdateien ist ja auch nochmal so’n Ding.
Wenn ich das richtig sehe, dann brauche ich im Patchordner doch eigentlich nie fstab-Dateien ablegen, es gibt doch ein postsync-Script im Patchordner /common/postsync.d/03-lcst-fix-fstab , welches die fstab passend zur start.conf umschreibt, macht es auch, aber nur halb.
SWAP bleibt bei der m.2-SSD auf sda2 und das ist schlecht.
Davon abgesehen werden Dateien in /common/etc/ nicht “gepostsynct”, also nicht in das Image kopiert, schwerschwer…ich weiss nichtmal genau, was ich fragen soll.
Wie genau meinst du das? Kannst du mal den Output von deinem Postsync schicken? Per linbo-ssh am Client anmelden und dann mit linbo_wrapper den Postsync machen.
linbo-wrapper sync:1 (falls es das erste OS ist, ich weiß grad nicht um linbo-wrapper oder linbo_wrapper)
Vielen Dank, “linbo-wrapper” gleich notiert. Der Client findet den Server nicht, damit kann ich weitersuchen, da geht wohl was mit der Namensaufloesung schief.
- getting patchfiles
rsync: failed to connect to 10.16.1.253 (10.16.1.253): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(128) [Receiver=3.1.1]
- patching local files
##### POSTSYNC END #####
10.16.1.253 ist unser Nameserver, ich hab im Moment nur die halbe Musterloesung im Einsatz, jetzt muss ich suchen wo da der falsche Server zugeordnet wird.
Danke Stephan, das war’s. Nach bestimmt 5 verheizten Stunden war das der entscheidende Tipp.
Wir haben noch eine uralte Musterloesung am Start, von der wir eigentlich nur Sophomorix mit Samba nutzen und sonst nix, der Rest ist Eigenbau und ich zieh jetzt parallel die “neue” hoch.
Edith: Hatte in der dhcp.conf noch unseren Nameserver (10.16.1.253) eingetragen, der Linboserver haengt auf der 10.32.1.1 und vermutlich (?) nimmt das Clientscript einfach an, dass auf dem Nameserver auch Linbo laeuft. Bin mir nicht ganz sicher ob das ein eleganter Weg ist.
Anders herum: Der Client nimmt an, dass auf dem Linbo-Server auch ein DNS läuft. Der Server bei linuxmuster.net vereint viele Dienste in sich. Vielleicht wird das in der neuen Version 7 modularer?
Nach der DNS-Aenderung in der dhcpd.conf hat er linbo gefunden, denke also dass er schon davon ausgeht, dass auf dem Nameserver auch Linbo sitzt. Namesaufloesung braucht er fuer Linbo ja eigentlich nicht.
Edith: Vielleicht doch, eine Namensabfrage schlaegt beim postsync dort auf
Gepatcht wird common und die Einzelrechner z.B. r254pc1, was nicht tut, sind die Gruppen, z.B. r254, die darinbefindlichen Patches werden nicht realisiert.
Edith, eben gefunden, linbo nimmt Raum r254pc1 als Raumname und fuer diese “Gruppe” gibt’s keine Patches.
Muss wohl das Skript angepasst werden?
Unsere Rechner heissen z.B. r254pc1, also Raum 254 PC1
Ich hab das jetzt mal getestet und mit dem “-” tut’s einwandfrei, im postsync-Skript aendere ich nix, mach das lieber an den Namen, auch wenn ich das “-” eigentlich fuer obsolet halte.