Hallo,
ich habe ein paar serverpatches im Home-Verzeichnis des linuxadmin installieren wollen. Als Eigentümer der patch-Datei auf dem Server dann mit chmod -R 1000:1000 home/linuxadmin
dafür gesorgt, dass der Eigentümer der patches auch linuxadmin ist.
Dummerweise gehörte nach einem sync auf dem Client alle patch-Dateien und sogar das linuxadmin-Homeverzeichnis root.
Ist das ein Bug oder ein Feature, dass der rsync-Befehl im universellen postsync-Skript den Dateieigentümer und die Rechte nicht mit überträgt?
rsync --delete --progress -r "${SERVERIP}::linbo/linuxmuster-client/${PATCHCLASS}" "/cache/${PATCHCACHE}" | tee -a $LOG
wäre also anzupassen zu rsync --delete -rpog ...
das Kopieren aus dem client-Cache ins Client-system: cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/common/* /mnt/
das erhält den Dateieigentümer und die Benutzerrechte.
ich habe ein paar serverpatches im Home-Verzeichnis des linuxadmin
installieren wollen. Als Eigentümer der patch-Datei auf dem Server dann mit
chmod -R 1000:1000 home/linuxadmin|
dafür gesorgt, dass der Eigentümer der patches auch linuxadmin ist.
Dummerweise gehörte nach einem sync auf dem Client alle patch-Dateien
und sogar das linuxadmin-Homeverzeichnis root.
deswegen habe ich diese Zeile am Ende des postsync scripts:
beim Einsatz des „generischen“ Postsync -Skriptes sollte man das postsync Skript nicht verändern, weil man sonst nicht mehr (halb)automatisch updaten kann.
Der Mechanismus, um eigene „skriptgesteuerte“ Änderungen, wie die der Zugriffsrechte, oder einfügen von lokalen Usern und dergleichen vorzunehmen ist, ist im generischen Postsync schon angelegt. Ziemlich am Ende im generischen Postsync steht folgende Anweisung:
# Hook, um eigene Skripte auszuführen
if [ -d /mnt/postsync.d ]; then
for SCRIPT in /mnt/postsync.d/*
do
chmod 755 $SCRIPT
echo "Executing: $SCRIPT $1 $2 $3 $4 $5 $6 $7 $8 $HOSTNAME $(hostgroup) $patchfile" | tee -a $LOG
#$SCRIPT > /dev/null 2>&1
$SCRIPT $1 $2 $3 $4 $5 $6 $7 $8 $HOSTNAME $(hostgroup) $patchfile | tee -a $LOG
echo " ...done." | tee -a $LOG
done
rm -rf /mnt/postsync.d
fi
Damit kann man eigene Skripte am Ende des Postsync-Vorgangs dadurch ausführen, indem man im Verzeichnis
linuxmuster-client/PATCHKLASSE/common/postsync.d
Skripte hinterlegt, bei mir sieht das z.B. so aus:
09:27/0 august /var/linbo/linuxmuster-client/ubuntu1710/common/postsync.d # ls -l
total 36
-rw-r--r-- 1 root root 269 Dec 11 2014 00-fix-initrd
-rw-r--r-- 1 root root 182 Sep 17 17:55 01-modify-localusers
-rw-r--r-- 1 root root 540 Dec 9 2014 01-setlocalpasswords
-rw-r--r-- 1 root root 232 Dec 9 2014 02-patch-sshd-config
-rw-r--r-- 1 root root 673 Dec 9 2014 03-fix-fstab
-rw-r--r-- 1 root root 123 Jan 20 2015 03-remove-rt8169-blacklist
-rw-r--r-- 1 root root 564 Dec 12 2014 04-generate-hosts
-rw-r--r-- 1 root root 91 Mar 3 2016 05-fixlinuxadminperms
-rw-r--r-- 1 root root 80 Oct 18 2016 06-fixhomestudentsperms
Diese Skripte werden in lexikalischer Reihenfolge abgearbeitet, und bekommen alle in Linbo vorhandenen Argumente als Optionen mit. Zuletzt löscht das Postsyncskript das postsync.d Verzeichnis auf dem synchronisierten Client, weil das nach dem Systemstart ja nicht mehr gebraucht wird.
Vorteile:
Das Postsyncskript selbst muss nicht verändert werden, bleibt also updatesicher.
Man kann die Aufgaben schön in einzelne Skripte mit spezifischen Aufgaben modularisieren
Man kann für verschiedene Rechner/Räume verschiedene „Skriptgruppen“ haben, im Beispiel oben sieht man eben die, die Skripte, die für alle Rechner gelten („common“). Ich kann jetzt aber natürlich 01-modifylocalusers für alle Rechner des raums „laptop“ einfach so per Postsync Unterverzeichnis „überschreiben“, dass auf allen Laptops ein lokaler Benutzer „laptop“ mit einem bekannten Passwort angelegt wird, so dass die Laptops offline eingesetzt werden können.
Ein letztes Wort der Warnung: Die Skripte in postsync.d müssen mit dem Shebang #!/bin/sh beginnen, da unter linbo keine Bash zur Verfügung steht.
Hallo,
das mit den halbautomatischen Updates leuchtet mir ein.
Allerdings finde ich es nicht sehr elegant auf einen fehlerhaften Patch noch einen weiteren draufzukleben.
(War das nicht einer der Gründe, warum Windows von update zu update immer fetter und fetter wurde?)
Der Fehler, dass Plötzlich /home/linuxadmin dem Benutzer root gehört liegt ja eindeutig an dem nicht ganz korrekten rsync im universellen Postsync-Skript. Wo muss ich denn diesen Fehler melden, damit das bei einem update dann nicht wieder drin ist?
Darüber hinaus will ich ja garnicht,dass sich dieses Skript durch ein update verändert, schließlich habe ich es jetzt verstanden und weiß, dass es das tut, was ich will das es tun soll. Ich würde mich ja nur ärgern, wenn dieses Skript plötzlich eine andere Funktionalität bekommt, nur weil ich ein Update eingespielt habe.
der rsync-Befehl kopiert vom Server auf den Client und zwar verbindet er sich mit dem „linbo“-share als user „linbo“ (oder so ähnlich). Die Idee ist ja, dass man ohne Passworteingabe von einem Computer im Netz Daten vom Server holt. Dass das nicht mit root-rechten auf dem Server konfiguriert wurde, leuchtet irgendwie ein. Wenn du Systemdateien wie /etc/fstab usw. in dem universellen Postsync-Skript vom Server kopieren würdest und sie würden schon die richtigen Rechte (z.B. 600 bei /etc/shadow) besitzen, dann müsste der rsync-Befehl root-Rechte auf dem Server haben.
Das ist einleuchtenderweise heikel.
Auf dem Server müssen daher die Dateien die für den Client bestimmt sind mit „chmod o+r“ lesbar für alle und damit für den rsync-Prozess sein.
Und auf dem Client muss man dann halt einen Patch nachschieben der die Dateirechte zurechtrückt.
Bevor man darüber nachdenkt, dieses Verfahren jetzt grundsätzlich zu ändern (z.B. alles in ein tar-file statt auf dem Server liegend), könnte man auch über ein Konfigurationsmanagement-Tool nachdenken.
Manche setzen „ansible“ für ähnliche dinge ein. Ich habe früher mal „cfengine2“ (nicht in der linuxmuster) verwendet und es ist ja schon OPSI integriert (vermutlich willst du das nicht)…
ich denke: am Ende sind diese Vorschläge alle overkill: Wenn man weiß, wie das postsync-skript funktioniert, dann kann man es nutzen. Viele verwenden hier KISS principle - Wikipedia und vermutlich ist es das auch: simple (und stupid), man muss nur dahinter kommen.
VG, Tobias
p.s. ich habe auch mal einen vorschlag zur änderung des postsyncs gehabt, weil ich die Idee der patch-klasse nicht verstehe, aber letztenendes - egal…
Hallo Tobias,
das ist nachvollziehbar erklärt. Wenn ich das richtig verstanden habe, wird bei meiner vorgeschlagenenen Änderung eine Datei, mit Zugriffsrechten rwx------ nicht übertragen werden können, weil der rsync-Prozess sie garnicht lesen darf. Werde ich gleich testen und dann entsprechend meine Skripte wieder anpassen.
Danke für den Hinweis und Gruß.
um Dateien per Postsync inklusive spezieller Eigentümer und/oder Zugriffsrechte zu übertragen muss man, wie Tobias erklärt hat, entweder tar-Dateien nehmen oder eben, wie ich oben erläutert habe, die Rechte/Eigentümer mit einem Skript in postsync.d nach der eigentlichen Synchronisierung setzen, wobei man im Falle des Eigentümers darauf achten muss, die UID numerisch anzugeben, da linbo natürlich die die Benutzer des Synchronisierten Systems kennt. Das ist kein Bug, sondern nicht zu vermeiden.
Das geht nicht, weil auf diese Weise beim Sync bereits gesyncte Daten nicht nachträglich gelöscht werden würden (oder nur bei vollständigen Sync mit rot) und ist aus obigen Gründen sinnlos.
das ist nachvollziehbar erklärt. Wenn ich das richtig verstanden habe,
wird bei meiner vorgeschlagenenen Änderung eine Datei, mit
Zugriffsrechten rwx------ nicht übertragen werden können, weil der
rsync-Prozess sie garnicht lesen darf.
ja, das ist so.
Ich übertrage einen ssh key, damit man vom Server aus ohne
Passwortabfrage den Client per ssh erreicht.
Das ist eine authorized_keys und deren Rechte muss ich, damit es am Ende
funktioniert, im postsync auf 600 setzen.
(vermutlich willst du das nicht)…