ich habs. Das chown -R 1000:1000 /mnt/home/linuxadmin im postsync-Skript ist das Problem. Ich habe das mal im Skript kommentiert und dann ist das „permission-denied“ Problem weg und alles funktioniert wie es soll, d.h. auch der Schalter „-c“ in linbo-remote funktioniert und der Client startet.
Jetzt stellt sich mir aber die Frage, warum das so ist und warum es mit Linbo < 4.1 immer funktioniert hat. Was hat das chown bitte mit der ssh-Sitzung zu tun? Der chown-Befehl an sich ist schon sehr nützlich, weil es mir schon oft passiert ist, dass beim Image basteln Rechte falsch waren.
Hi nochmal,
die Lösung für das Problem folgt auch gleich. Der Befehl im Postsync-Skript muss jetzt heißen: chown -Rh 1000:1000 /mnt/home/linuxadmin .
Der Schalter -h sorgt dafür, dass keine Symlinks verfolgt werden…irgendwie liegt wohl da das Problem.
LG
Dominik
@thomas: vergiss es also, das hat nichts mit Linbo zu tun, das scheint einfach nur ein neues Verhalten zu sein…muss man halt wissen.
Mich würde noch als Unwissender interessieren, was das chown -Rh 1000:1000 /mnt/home/linuxadmin im Postsync genau bringt. Sollte ich das auch in meinen Postsync machen? Ist das irgendwo dokumentiert?
Mich würde noch als Unwissender interessieren, was das |chown -Rh
1000:1000 /mnt/home/linuxadmin| im Postsync genau bringt. Sollte ich das
auch in meinen Postsync machen? Ist das irgendwo dokumentiert?
unter ubuntu installieren wir unsere Software als der lokale Nutzer
„linuxadmin“.
Und wenn da mal die Rechte im Verzeichnis des linuxadmins falsch sind,
dann geht was beim Defaultprofil kopieren schief (da wird ja das
linuxadmin Profil verwendet).
Es war halt einfach sehr bequem die Rechte im postsync gerade zu ziehen:
so vergißt man es nicht.
Wenn du das nciht hast und du bisher keine Problmee hattest, dann ist es
ja gut.
Solltest du in zukunft mal komische Problem beim defaultprofil kopieren
haben (Anmelden der Nutzer), dann denk an diesen Tread
Hallo!
Das braucht man z.B. wenn man per Postsync Dateien ins linuxadmin-Home (also auch ins Vorlagenbenutzer-Home) synchronisiert. Die müssen dann halt die lokalen linuxadmin-Rechte bekommen, sonst funktioniert es nach der Anmeldung als LDAP-Nutzer nicht.
„Sicherheitshalber“ haben das die meisten wohl im Postsync, ob das in den neuen Vorlagen auch noch drin ist, weiß ich nicht, sinnvoll fände ich es schon.
LG
Max
Das braucht man z.B. wenn man per Postsync Dateien ins linuxadmin-Home
(also auch ins Vorlagenbenutzer-Home) synchronisiert. Die müssen dann
halt die lokalen linuxadmin-Rechte bekommen, sonst funktioniert es nach
der Anmeldung als LDAP-Nutzer nicht.
„Sicherheitshalber“ haben das die meisten wohl im Postsync, ob das in
den neuen Vorlagen auch noch drin ist, weiß ich nicht, sinnvoll fände
ich es schon.
ich will Heute Nacht mal meinen postsync als Beispiel rausgeben.
Da soll das dann noch immer drin sein, da es ja normalerweise nicht
schadet: Dank Dominik geht es ja nun auch wieder
Hallo nochmal.
Ich habe heute ein Ubuntu Jammy nochmal mit dem gelben Button (Sync + Start) und qcow2- und qdiff-Image hochgefahren. Laut Postsync-Script unter /srv/linbo/images/jammy/jammy.postsync soll am Ende (zur Kontrolle) dies geschehen:
Nachdem die VM gestartet ist, habe ich nachgesehen und festgestellt, dass die Postsync-Datei offenbar nicht abgearbeitet wurde, denn die Datei .lastsync steht nicht auf dem Datum von heute. Daher kann ich bestätigen, dass das Postsync unter v7.2 auch hier noch irgendwo klemmt … nur wo?
[etwas später]
Dazu gleich zwei Fragen hinterher: In der Postsync-Datei steht hier:
# Das Verzeichnis, in dem die Serverpatches
# im lokalen Clientcache synchronisiert werden.
PATCHCACHE=/linuxmuster-client/serverpatches
Das Verzeichnis gibt’s hier aber nicht – wodurch wird das angelegt?
Ich habe auf die Cache-Partition der Jammy-VM geschaut. Da liegen alle jammy.*Files mit aktuellem Zeitstempel aber die .postsync-Datei fehlt. Dann kann sie natürlich auch nicht ausgeführt werden …
Bleibt die Frage: Warum?
Auf dem Server ist die Postsync-Datei also vorhanden.
Der Inhalt der Datei sieht hier so aus (ist eine 1:1 Kopie vom fossa-Image):
echo "##### POSTSYNC BEGIN #####"
LOG=/mnt/var/log/postsync.log
export LOG
echo "##### POSTSYNC BEGIN #####" > $LOG
NOW=$(date +%Y%m%d-%H%M)
export NOW
echo $NOW | tee -a $LOG
# IP-Adresse des Servers
#SERVERIP=$(nslookup dummy 2> /dev/null | head -n 1 | awk -F: '{print $2}' | sed "s/\s*//g")
SERVERIP=${siaddr}
export SERVERIP
# Die Hostgruppe des aktuellen Rechners
HOSTGROUP=$(hostgroup)
export HOSTGROUP
# Raum feststellen. Dieses Skript geht davon aus
# dass die Rechner Namen der Form
# raumname-hostname haben, also z.B. cr01-pc18
RAUM=${HOSTNAME%%-*}
# wenn der string leer ist, raum auf unknown setzen
if [ "x${RAUM}" == "x" ]; then
RAUM="unknown"
fi
export RAUM
# Unterverzeichnis für die Patches auf dem Server. Mit dieser Variablen
# kann man verschiedene Patches, z.B. für unterschiedliche
# Linux-Versionen bereitstellen.
# Wenn man hier $HOSTGROUP einträgt, erhält jede Rechnerklasse
# ein eigenes Patchklassenverzeichnis auf dem Server.
# Damit kann man verschiedene Patchklassen mit derselben cloop-Datei
# bedienen, wenn man das benötigt.
PATCHCLASS="jammy"
export PATCHCLASS
# Das Verzeichnis, in dem die Serverpatches
# im lokalen Clientcache synchronisiert werden.
PATCHCACHE=/linuxmuster-client/serverpatches
export PATCHCACHE
echo "" | tee -a $LOG
echo "Hostname: ${HOSTNAME}" | tee -a $LOG
echo "Raum: ${RAUM}" | tee -a $LOG
echo "Patchcache: ${PATCHCACHE}" | tee -a $LOG
echo "Hostgruppe: ${HOSTGROUP}" | tee -a $LOG
echo "Patchclass: ${PATCHCLASS}" | tee -a $LOG
echo "" | tee -a $LOG
# -----------------------------------------
# Patchdateien auf das lokale Image rsyncen
# -----------------------------------------
echo " - getting patchfiles" | tee -a $LOG
# RAUM -> Raumname
# HOSTNAME -> Rechnername
# Verzeichnis anlegen, damit es sicher existiert
mkdir -p /cache/${PATCHCACHE}
rsync --delete --progress --exclude "- *~" -lr "${SERVERIP}::linbo/linuxmuster-client/${PATCHCLASS}" "/cache/${PATCHCACHE}" | tee -a $LOG
echo " - patching local files" | tee -a $LOG
# common: Bekommen alle clients der Patchklasse
# files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/common ]; then
echo " - patching common to /mnt" | tee -a $LOG
## copy all files in common/*
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/common/* /mnt/ | tee -a $LOG
## rsync (with delete) all postsync.d-files
rsync --delete -lr /cache/${PATCHCACHE}/${PATCHCLASS}/common/postsync.d/ /mnt/postsync.d/ | tee -a $LOG
fi
# tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/common/tarpacks ]; then
echo " - unpacking tarpacks from common/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/common/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi
# Raum: Nur die Clients des Raums
# files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM} ]; then
echo " - patching ${RAUM} to /mnt" | tee -a $LOG
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/* /mnt/ | tee -a $LOG
fi
# tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/tarpacks ]; then
echo " - unpacking tarpacks from ${RAUM}/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi
# Host: Nur der Rechner
# files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME} ]; then
echo " - patching ${HOSTNAME} to /mnt" | tee -a $LOG
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/* /mnt/ | tee -a $LOG
fi
# tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/tarpacks ]; then
echo " - unpacking tarpacks from ${HOSTNAME}/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi
# 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" | tee -a $LOG
#$SCRIPT > /dev/null 2>&1
source $SCRIPT | tee -a $LOG
echo " ...done." | tee -a $LOG
done
rm -rf /mnt/postsync.d
fi
# wenn es /mnt/tarpacks gibt - löschen
rm -rf /mnt/tarpacks
# Zeitstempel letzter sync hinterlegen
echo $NOW > /mnt/.lastsync
# Hostgroup hinterlegen
echo ${HOSTGROUP} > /mnt/.hostgroup
# /mnt/.linbo wurde von Linbo hinterlegt
image=$(cat /mnt/.linbo)
# Image Beschreibung hinterlegen
cp /cache/${image}.cloop.desc /mnt/.description
echo "##### POSTSYNC END #####" | tee -a $LOG
Steckt der Fehler vielleicht in der Zeile PATCHCLASS="jammy" ?
Viele Grüße,
Michael
Hallo Thomas – ok … aber selbst wenn das Script nicht richtig funktioniert, muss es doch zunächst mal auf den Client gelangen, oder? Das funktioniert hier schon nicht.
Es muss doch einfach jammy.postsync heißen, oder wäre hier jammy.qcow2.postsync richtig?
Ok – mit den geänderten Optionen und einem zwischenzeitlichen Partitionieren/Formatieren des Clents funktioniert das Postsync nun wieder. Besten Dank!
Ich hatte nicht mehr auf dem Schirm, dass die Postsync-Datei nur nach dem Formatieren übertragen wird. Nur aus Interesse: Ist das sinnvoll? Wäre es nicht besser, wenn die auch bei Sync+Start vom Server geholt wird?
Ich hätte das auch gerne als Default-Verhalten. Ich habe mir diese Funktionalität durch die Hintertür eingebaut. Die letzte Zeile in meinem Postsyncskript lautet:
Ist nicht schön, funktioniert aber seit Jahren prima. Eine Änderung am Skript auf dem Server landet also beim nächsten Postsync auf dem Client-Cache…ist irgendwie auch witzig wenn sich ein Skript selber rsynct.
