Ich habe bisher vor der Erstellung eines neuen images in der start.conf einen neuen Namen (mit datum im Namen) gegeben, so dass bei der Neuerstellung und Hochladen eines Images ein neues cloop erstellt wurde.
Dabei wurde das alte postsync nicht kopiert. Verstehe ich auch, woher sollte linbo das auch wissen.
Jetzt habe ich den Dateinamen belassen (wg. anderer Problematik Linbo - autoinitcache löscht die alten Images nicht ) und daher wird der Dateiname des Images + der weiteren Dateien behalten, die vorherige Version wird ja umbenannt mit dem Erstellungsdatum des neuen Images versehen.
Aber: das postsync wird umbenannt und nicht behalten. Das ist doch doof und könnte mir viel Arbeit ersparen, an das kopieren des postsyncs zu denken.
Sehe ich da was falsch, oder kann ich getrost ein Ticket / feature request erstellen?
Jetzt habe ich den Dateinamen belassen (wg. anderer Problematik Linbo -
autoinitcache löscht die alten Images nicht https://ask.linuxmuster.net/t/linbo-autoinitcache-loescht-die-alten-images-nicht/1213/1
) und daher wird der Dateiname des Images + der weiteren Dateien
behalten, die vorherige Version wird ja umbenannt mit dem
Erstellungsdatum des neuen Images versehen.
Aber: das postsync wird umbenannt und nicht behalten. Das ist doch doof
und könnte mir viel Arbeit ersparen, an das kopieren des postsyncs zu
denken.
Sehe ich da was falsch, oder kann ich getrost ein Ticket / feature
request erstellen?
da muss bei dir was schief laufen. Bei mir bleibt der Postsync seit
Jahren erhalten.
Welche linbo Version hast du?
Vorsicht: die Rechte vom postsync sind falsch: so würde er nicht
ausgeführt werden, auch wenn er richtig hieße.
644 ist korrekt.
Falsche Rechte bei der postsync Datei habe ich diese Woche auf zwei
Systemen beobachtet: zweimal bei der Hotline.
Da scheinen irgend wann die Rechte mal falsch gesetzt zu werden…
Das sage ich seit einiger Zeit, dass die Postsync-Dateien irgendwann die falsche Rechte erhalten.
Mein Problem ist : ich habe immer noch keine Regel / Grund gefunden warum es so ist.
Ich habe wieder im Sommer alles mit 644 gemacht. Da ich neugierig bin, schaue gerade an und :
… das könnte es erklären: wenn linbo das alte Image verschiebt und den
postsync kopiert (ebenso wie die reg), dann ändert es die Rechte.
Kopiert man aber mal ein Image zurück hat man den Salat…
22:41/0 server /var/linbo # ls -lart xenialmate1710-1*
-rw-r--r-- 1 root root 124 Oct 20 15:47 xenialmate1710-1.cloop.desc
-rw-r--r-- 1 root root 3743711015 Oct 20 15:50 xenialmate1710-1.cloop
-rw-r--r-- 1 root root 151 Oct 20 15:50 xenialmate1710-1.cloop.info
-rw-r--r-- 1 root root 285852 Oct 20 15:50 xenialmate1710-1.cloop.torrent
-rw-r--r-- 1 root root 177 Oct 20 15:52 xenialmate1710-1.cloop.macct
-rw-r--r-- 1 root root 15039 Oct 21 10:28 xenialmate1710-1.cloop.postsync~
-rw-r--r-- 1 root root 15121 Oct 21 10:51 xenialmate1710-1.cloop.postsync
22:48/0 server /var/linbo # linbo-remote -i r202-pc02 -c create_cloop:1,upload_cloop:1
###
### linbo-remote (31006) start: Sun Oct 22 22:49:53 CEST 2017
###
Sending command(s) to:
10.16.18.2 ... Uploading secrets ... Ok!
###
### linbo-remote (31006) end: Sun Oct 22 22:49:53 CEST 2017
###
22:49/0 server /var/linbo # ls -lart xenialmate1710-1*
-rw-r--r-- 1 root root 124 Oct 20 15:47 xenialmate1710-1-2017-10-22-2254.cloop.desc
-rw-r--r-- 1 root root 3743711015 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop
-rw-r--r-- 1 root root 151 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop.info
-rw-r--r-- 1 root root 285852 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop.torrent
-rw------- 1 root root 177 Oct 20 15:52 xenialmate1710-1-2017-10-22-2254.cloop.macct
-rw-r--r-- 1 root root 15039 Oct 21 10:28 xenialmate1710-1.cloop.postsync~
-rw-rw-r-- 1 root root 15121 Oct 21 10:51 xenialmate1710-1.cloop.postsync
-rw-r--r-- 1 root root 15121 Oct 21 10:51 xenialmate1710-1-2017-10-22-2254.cloop.postsync
-rw-rw-r-- 1 root root 203 Oct 22 22:49 xenialmate1710-1.cloop.desc
-rw-rw-r-- 1 root root 3742677079 Oct 22 22:52 xenialmate1710-1.cloop
-rw-rw-r-- 1 root root 151 Oct 22 22:52 xenialmate1710-1.cloop.info
-rw-rw-r-- 1 root root 285772 Oct 22 22:53 xenialmate1710-1.cloop.torrent
-rw------- 1 root root 177 Oct 22 22:54 xenialmate1710-1.cloop.macct
So einfach ist des Rätsels Lösung nicht.
Zu beginn habe ich auf dem Server alles auf 644 gechmodded.
Ah, ich machte noch weiter:
22:59/0 server /var/linbo # linbo-remote -i r202-pc02 -c create_cloop:1:testmessage,upload_cloop:1
###
### linbo-remote (29492) start: Sun Oct 22 23:02:54 CEST 2017
###
Sending command(s) to:
10.16.18.2 ... Uploading secrets ... Ok!
###
### linbo-remote (29492) end: Sun Oct 22 23:02:54 CEST 2017
###
23:02/0 server /var/linbo # ls -lart xenialmate1710-1*
-rw-r--r-- 1 root root 124 Oct 20 15:47 xenialmate1710-1-2017-10-22-2254.cloop.desc
-rw-r--r-- 1 root root 3743711015 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop
-rw-r--r-- 1 root root 151 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop.info
-rw-r--r-- 1 root root 285852 Oct 20 15:50 xenialmate1710-1-2017-10-22-2254.cloop.torrent
-rw------- 1 root root 177 Oct 20 15:52 xenialmate1710-1-2017-10-22-2254.cloop.macct
-rw-r--r-- 1 root root 15039 Oct 21 10:28 xenialmate1710-1.cloop.postsync~
-rw-rw-r-- 1 root root 15121 Oct 21 10:51 xenialmate1710-1.cloop.postsync
-rw------- 1 root root 15121 Oct 21 10:51 xenialmate1710-1-2017-10-22-2307.cloop.postsync
-rw-r--r-- 1 root root 15121 Oct 21 10:51 xenialmate1710-1-2017-10-22-2254.cloop.postsync
-rw-rw-r-- 1 root root 203 Oct 22 22:49 xenialmate1710-1-2017-10-22-2307.cloop.desc
-rw-rw-r-- 1 root root 3742677079 Oct 22 22:52 xenialmate1710-1-2017-10-22-2307.cloop
-rw-rw-r-- 1 root root 151 Oct 22 22:52 xenialmate1710-1-2017-10-22-2307.cloop.info
-rw-rw-r-- 1 root root 285772 Oct 22 22:53 xenialmate1710-1-2017-10-22-2307.cloop.torrent
-rw------- 1 root root 177 Oct 22 22:54 xenialmate1710-1-2017-10-22-2307.cloop.macct
-rw-rw-r-- 1 root root 245 Oct 22 23:02 xenialmate1710-1.cloop.desc
-rw-rw-r-- 1 root root 3741862633 Oct 22 23:05 xenialmate1710-1.cloop
-rw-rw-r-- 1 root root 151 Oct 22 23:05 xenialmate1710-1.cloop.info
-rw-rw-r-- 1 root root 285712 Oct 22 23:06 xenialmate1710-1.cloop.torrent
-rw------- 1 root root 177 Oct 22 23:07 xenialmate1710-1.cloop.macct
und siehe da: die letzte verschobene postsync-Datei hat auf einmal die Rechte 600.
Interessanterweise bekommen die neuen Dateien 664 statt 644.
Vor dem ersten create_cloop habe ich ein sync:1 laufen lassen. Vor dem zweiten allerdings nicht mehr.
Auf dem client sehen die Dateien so aus:
~ # ls -lart /cache/xenialmate1710-1.cloop*
-rw-r--r-- 1 root root 15121 Oct 21 08:51 /cache/xenialmate1710-1.cloop.postsync
-rw-r--r-- 1 root root 245 Oct 22 21:02 /cache/xenialmate1710-1.cloop.desc
-rw-r--r-- 1 root root 3741862633 Oct 22 21:05 /cache/xenialmate1710-1.cloop
-rw-r--r-- 1 root root 151 Oct 22 21:05 /cache/xenialmate1710-1.cloop.info
-rw-rw-r-- 1 root root 0 Oct 22 21:05 /cache/xenialmate1710-1.cloop.complete
-rw-rw-r-- 1 root root 285712 Oct 22 21:06 /cache/xenialmate1710-1.cloop.torrent
Hallo,
das Problem der “verschwindenden postsync-Datei” verfolgt mich seit Jahren. Das Problem hat, wie ihr schon festgestellt hat, zwei Komponenten:
Beim Hochladen einer neuen Image-Version wird die Postsync-Datei nicht mitkopiert. – Hierfür hatte ich im Linuxmuster-Bugtracker (firefly) vor langer Zeit bereits ein Ticket geschrieben, und ich meine mich zu erinnern, es wurde als gefixt geschlossen – leider ist die Änderung bislang nich nicht in LML 6.2 angekommen. (Zudem finde ich den Bugtracker nicht mehr, habt ihr den abgestellt? Wenn ja, was ist aus den Tickets geworden?)
Die postsync-Datei bekommt beim kopieren manchmal die falschen Rechte, sie ist dann nur noch für root lesbar und wird daher beim Linbo-Sync gar nicht erst mitkopiert.
Beides ist sehr ärgerlich, weil die postsync bei uns wesentliche Aufgaben im Lehrernetz erfüllt und ich möchte mich einfach darauf verlassen können, dass sie auch ausgeführt wird. Momentan muss ich vor jedem Image-Rollout manuell prüfen, ob die postsync auch wirklich da ist und die richtigen Rechte hat.
Sagt man, muss auf der .postsync-Datei das execute-Flag gesetzt sein?
Gerade habe ich das aus Verzweilflung gesetzt und nun wird meine .postsync klaglos abgearbeitet.
(Rechte rwx r-x r-x, oktal 755).
Sagt man, muss auf der .postsync-Datei das execute-Flag gesetzt sein?
Gerade habe ich das aus Verzweilflung gesetzt und nun wird meine
.postsync klaglos abgearbeitet.
(Rechte rwx r-x r-x, oktal 755).
wovon reden wir den: von der normalen postsync Datei
imagename.cloop.postsync
oder von der rsync Image postsync Datei.
Ich verwende die „normale“ postsync Datei (also ohne das rsync Image)
schon so viele Jahre und hatte nie ein Problem damit: deswegen wundere
ich mich ein wenig.
wir reden von der “normalen” postsync-Datei, also imagename.cloop.postsync. Da, wo ich oben “rsync” geschrieben habe, meinte ich “postsync” – sorry, das kommt davon, wenn man im Konferenzstress schnell zwischen Tür und Angel einen Bugreport schreibt.
Mich wundert es dann umgekehrt, dass Du damit nie Probleme hast? Bei uns ist es gang und gäbe, dass die .postsync immer wieder verschwindet – praktisch bei jedem neuen Image-Upload. Wie gesagt hatte ich dazu im Bugtracker ein Ticket erstellt und irgend jemand hat es auch bearbeitet – was ist aus dem Bugtracker denn geworden? Ich finde ihn nicht mehr.
Nachdem heute morgen der Sync wieder mal durchgelaufen war, ohne dass das Skript abgearbeitet wurde, habe ich einfach mal direkt im lokalen Cache die execute-Rechte auf dem Skript gesetzt – und siehe da, beim nächsten Sync wurde es abgearbeitet. Also habe ich das auch auf dem Server getan und nun gerade etwa 15 Rechner gesynct: Hat überall geklappt.
Ob es nun allerdings wirklich am “x”-Flag lag, oder an was anderem, keine Ahnung.
Ich hab’s gefunden (wenn man einfach nach dem richtigen Namen sucht, klapt es auch * seufz, ferienreif *): https://www.linuxmuster.net/flyspray/task/585
(siehe auch #495 und #443)
Das Ticket bezog sich allerdings auf die Schulkonsole. Die spielt ja beim Hochladen eines Images eigentlich nicht mit. Doch vielleicht ist die Fehlerursache gleich.
Ich verwende die “normale” postsync Datei (also ohne das rsync Image)
schon so viele Jahre und hatte nie ein Problem damit: deswegen wundere
ich mich ein wenig.
Und wie machst du deine cloop ? Mit linbo-remote oder mit der Oberfläche
direkt auf dem Client ?
Mich wundert es dann umgekehrt, dass Du damit nie Probleme hast? Bei uns
ist es gang und gäbe, dass die .postsync immer wieder verschwindet –
praktisch bei jedem neuen Image-Upload. ner gesynct: Hat überall geklappt.
Ob es nun allerdings wirklich am “x”-Flag lag, oder an was anderem,
keine Ahnung.
die Rechte sind bei mir (bei über 15 Images in drei Einrichtungen)
-rw-rw-r-- 1 root root 3776 Mai 31 2016
xenial-lmg.cloop.postsync
Wie heißt den euer Image?
Vielelicht ist was besonderes im Namen: und da stolpert ein Script drüber …
So könnten wir erklären, weswegen nur wenige betroffen sind, während es
bei allen anderen ohne Probleme läuft (das vermute ich, weil ich sonst
hier in der Liste schon vorher oder vermehrt davon lesen würde).
meine .cloop.postsync, hat -rw-rw-r-- und funktioniert klaglos.
evtl. lohnt es sich, innendrin ein paar logs zu schreiben und mal zu schauen, ob es innendrin nicht fehler gibt…
also so:
echo "##### trusty-linuxmuster POSTSYNC BEGIN #####" 2>&1 > postsync.log
date 2>&1 >> postsync.log
echo "Hostname: ${HOSTNAME}" 2>&1 >> postsync.log
usw. Die Datei liegt dann auf dem Client (wird nicht auf den Server kopiert), man kann aber danach auf der cache-Partition nachgucken, was da reingeschrieben wurde.
Sinnvoll ist es, die erste Pipe mit > zu machen, alle folgenden mit >> (append).