Neue Patchklasse erzeugen

irrlicht · 12. März 2018 um 14:13

Tag auch, schnall mal wieder was nicht.

Wie kann ich eine neue Patchklasse festlegen/erstellen, also ich hab eine VM, die ein neues cloop ergeben soll, nennen wir es test01.cloop.

Was muss ich nach dem Erstellen des Images auf dem Server noch tun?
Moechte den ganzen postsync-Kram nutzen, das geht aber nur per Patchklasse.

Gruss Harry

zefanja · 12. März 2018 um 14:21

Hi,

wenn ich es richtig im Kopf habe:

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/)
start.conf.patchklasse anpassen (z.B. Imagename)
/var/linbo/imagename.cloop.postsync erstellen bzw. kopieren (Datei-Rechte kontrollieren, sonst klappt es nicht)
für postsync einen Ordner anlegen /var/linbo/linuxmuster-client/patchklasse/ und der Doku folgen

vG Stephan

baumhof · 12. März 2018 um 15:21

Hallo,

wenn ich es richtig im Kopf habe:

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.

Die postsyncs sind komplex: aber sehr mächtig.

LG

Holger

irrlicht · 12. März 2018 um 17:46

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.

baumhof · 12. März 2018 um 21:24

Hallo Harry,

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

Ich hoffe ich konnte ein wenig aufklären.

LG

Holger

zefanja · 12. März 2018 um 22:17

Du hast recht

irrlicht · 13. März 2018 um 17:59

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.

Cgsman · 13. März 2018 um 20:27

Hallo, Harry,

hast Du das gesehen:
http://docs.linuxmuster.net/de/latest/clients/postsync/postsync-patchclasses.html

Ich finde, da ist das gut erklärt.

L.G.
Christoph Gü

irrlicht · 13. März 2018 um 21:38

Das ist auch gut erklaert, wo aber die bestimmten Patchklassen den cloops zugeordnet werden kann ich daraus kaum entnehmen, vermute aber:

baumhof · 13. März 2018 um 21:48

Hallo Harry,

/var/linbo/linuxmuster-client/trusty/
Patchklasse “trusty” und diese wird in test01.cloop.postsync zugeordnet?

ja: ziemlich weit oben in der postsync Datei steht das drin:
Patchklasse = trusty (so in etwa).

Wenn es nicht klappt, dann konstrollier die Rechte der Verzeichnisse
unterhalb von /var/linbo/linuxmuster-client

Der Nutzer linbo muss das lesen können.

LG

Holger

irrlicht · 14. März 2018 um 13:40

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.

zefanja · 14. März 2018 um 13:44

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)

vG Stephan

irrlicht · 14. März 2018 um 13:48

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.

irrlicht · 14. März 2018 um 14:01

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.

zefanja · 14. März 2018 um 14:15

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?

vG

irrlicht · 14. März 2018 um 14:20

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

irrlicht · 15. Oktober 2018 um 11:21

Tag auch,

wieder mal’n Problem mit dem postsync, hell yeah!

Gepatcht wird common und die Einzelrechner z.B. r254pc1, was nicht tut, sind die Gruppen, z.B. r254, die darinbefindlichen Patches werden nicht realisiert.

Jemand eine Idee?

Gruss Harry

13:07/0 lmlserver /var/linbo/linuxmuster-client/mate02 # ls -la
insgesamt 36
drwxrwxrwx 9 root root 4096 Okt 15 12:19 .
drwxrwxrwx 8 root root 4096 Sep 26 13:20 ..
drw-r-xr-x 5 root root 4096 Okt 15 12:50 common
drw-r-xr-x 3 root root 4096 Okt 15 12:29 r205
drw-r-xr-x 4 root root 4096 Okt 15 12:29 r205pc34
drw-r-xr-x 4 root root 4096 Okt 11 13:11 r225
drw-r-xr-x 4 root root 4096 Okt 15 12:44 r254
drw-r-xr-x 3 root root 4096 Okt 15 12:02 r254pc1
drw-r-xr-x 3 root root 4096 Mär 14  2018 r307

Die Patches werden alle gelistet, unten sieht man, dass nur die PCs und common gepatcht werden.

ate02/r254/r254gruppe
              0 100%    0.00kB/s    0:00:00 (xfr#24, to-chk=14/59)
mate02/r254/etc/r254etc
              9 100%    4.39kB/s    0:00:00 (xfr#25, to-chk=11/59)
mate02/r254/etc/cups/printers.conf
            579 100%  282.71kB/s    0:00:00 (xfr#26, to-chk=8/59)
mate02/r254/etc/cups/ppd/Kyocera_FS-3900DN.ppd
         60,222 100%   28.72MB/s    0:00:00 (xfr#27, to-chk=6/59)
mate02/r254/etc/default/epoptes-client
            667 100%  325.68kB/s    0:00:00 (xfr#28, to-chk=5/59)
mate02/r254/root/raum254-shit
              0 100%    0.00kB/s    0:00:00 (xfr#29, to-chk=4/59)
mate02/r307/etc/fstab
            436 100%  141.93kB/s    0:00:00 (xfr#30, to-chk=1/59)
mate02/r307/etc/fstab307
            494 100%  160.81kB/s    0:00:00 (xfr#31, to-chk=0/59)
 - patching local files
   - patching common to /mnt
   - patching r254pc1 to /mnt
   - patching r254pc1 to /mnt

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

BIOS-System gefunden.
Setze Hostname -> r254pc1.
patch_fstab 1: »/dev/nvme0n1p1« 
##### POSTSYNC BEGIN #####
20181015-1212

Hostname:      r254pc1
Raum:          r254pc1
Patchcache:    /linuxmuster-client/serverpatches
Hostgruppe:    mate02_m2
Patchclass:    mate02

Sven · 15. Oktober 2018 um 12:41

Hallo irrlicht,

in der Dokumentation zum postsync steht, dass Raumname und Rechnernme durch einen „-“ getrennt sein müssen

# Raum feststellen. Dieses Skript geht davon aus
# dass die Rechner Namen der Form
# raumname-hostname haben, also z.B. cr01-pc18

Du musst also entweder deine Rechner umbennen oder das postsync-Skript anpassen.

Grüße,
Sven

irrlicht · 15. Oktober 2018 um 12:47

OK, vielen Dank - wieder mal’n Tag verschenkt.

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.

Problem geloest.

Gruss Harry