Neues Image erstellen - postsync wird nicht kopiert

Hi.

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?

Viele Grüße, Tobias

Hallo Tobias,

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?

LG

Holger

Ok.
Dann muss ich das nochmal anschauen.
linbo-2.3.26
ich habe gestern den Befehl: linbo-remote -p create_cloop:1:“datum”,upload_cloop:1,halt -n

abgesetzt und heute morgen festgestellt, dass die Daten wie folgt auf dem Server lagen:

12:22/0 server /var/linbo # ls -lart xenialmate1710-1*
-rw-rw-r-- 1 root root         79 Okt 11 17:32 xenialmate1710-1-2017-10-20-1552.cloop.desc
-rw-rw-r-- 1 root root        151 Okt 11 17:35 xenialmate1710-1-2017-10-20-1552.cloop.info
-rw-rw-r-- 1 root root 3740803298 Okt 11 17:35 xenialmate1710-1-2017-10-20-1552.cloop
-rw-rw-r-- 1 root root     285632 Okt 11 17:35 xenialmate1710-1-2017-10-20-1552.cloop.torrent
-rw------- 1 root root        177 Okt 11 17:37 xenialmate1710-1-2017-10-20-1552.cloop.macct
-rw------- 1 root root      15039 Okt 13 11:42 xenialmate1710-1-2017-10-20-1552.cloop.postsync
-rw-rw-r-- 1 root root        124 Okt 20 15:47 xenialmate1710-1.cloop.desc
-rw-rw-r-- 1 root root 3743711015 Okt 20 15:50 xenialmate1710-1.cloop
-rw-rw-r-- 1 root root        151 Okt 20 15:50 xenialmate1710-1.cloop.info
-rw-rw-r-- 1 root root     285852 Okt 20 15:50 xenialmate1710-1.cloop.torrent
-rw------- 1 root root        177 Okt 20 15:52 xenialmate1710-1.cloop.macct

Ich werde, nachdem ich das über die grafische Oberfläche auch mal probiert habe, mich zurückmelden.
VG, Tobias

Hallo Tobias,

-rw------- 1 root root 15039 Okt 13 11:42 xenialmate1710-1-2017-10-20-1552.cloop.postsync

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…

LG

Holger

HI Holger,

die waren, ziemlich sicher, vorher, d.h. bevor ich mit create_cloop:1 ein neues erstellte, richtig. Vielleicht macht das linbo beim upload_cloop.

Grüße, Tobias

Hallo ihr beide,

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 :

ls -la /var/linbo/*sync
-rw-r–r-- 1 root root 1803 avril 23 2016 /var/linbo/trusty.cloop.postsync
-rw------- 1 root root 2524 août 18 15:00 /var/linbo/xenial-2017-09-10-2153.cloop.postsync
-rw------- 1 root root 2616 sept. 14 13:04 /var/linbo/xenial-2017-09-14-2209.cloop.postsync
-rw------- 1 root root 2616 sept. 14 13:04 /var/linbo/xenial-2017-09-22-0741.cloop.postsync
-rw-rw-r-- 1 root root 2616 sept. 14 13:04 /var/linbo/xenial.cloop.postsync

Manchmal mache meine cloop direkt mit linbo am Client, oft mache ich es mit linbo-remote.

Gruß

Arnaud

Hallo Arnaud,

ls -la /var/linbo/*sync
-rw-r–r-- 1 root root 1803 avril 23 2016
/var/linbo/trusty.cloop.postsync
-rw------- 1 root root 2524 août 18 15:00
/var/linbo/xenial-2017-09-10-2153.cloop.postsync
-rw------- 1 root root 2616 sept. 14 13:04
/var/linbo/xenial-2017-09-14-2209.cloop.postsync
-rw------- 1 root root 2616 sept. 14 13:04
/var/linbo/xenial-2017-09-22-0741.cloop.postsync
-rw-rw-r-- 1 root root 2616 sept. 14 13:04
/var/linbo/xenial.cloop.postsync

… 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…

LG

Holger

Hi Holger, hi Arnaud,

hier mein einfacher test:

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

vg, Tobias

VG, tobias

Hallo,
das Problem der “verschwindenden postsync-Datei” verfolgt mich seit Jahren. Das Problem hat, wie ihr schon festgestellt hat, zwei Komponenten:

  1. 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?)

  2. 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.

Könnt ihr hier mal für Abhilfe sorgen?

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).

Hallo Rüdiger,

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.

LG

Holger

Hallo Holger,

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.

Hallo Holger,

Und wie machst du deine cloop ? Mit linbo-remote oder mit der Oberfläche direkt auf dem Client ?

Gruß

Arnaud

Um zu ergänzen :

# ls -al /var/linbo/*sync
-rw-rw-r-- 1 root root 1803 avril 23  2016 /var/linbo/trusty.cloop.postsync
-rw-rw-r-- 1 root root 2778 janv. 21 18:29 /var/linbo/xenial-2018-02-20-2040.cloop.postsync
-rw-rw-r-- 1 root root 2778 janv. 21 18:29 /var/linbo/xenial-2018-04-24-2236.cloop.postsync
-rw-rw-r-- 1 root root 3110 juin  14 09:50 /var/linbo/xenial-2018-06-17-1311.cloop.postsync
-rw------- 1 root root 3497 juin  18 18:09 /var/linbo/xenial-2018-06-21-1751.cloop.postsync
-rw-rw-r-- 1 root root 3497 juin  18 18:09 /var/linbo/xenial.cloop.postsync

Das Image am 21/06 habe ich mit der Oberfläche direkt auf dem Client gemacht, der Rest mit linbo-remote.

Gruß

Arnaud

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.

Hallo Arnaud,

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 ?

mal so und mal so.

LG

Holger

Hallo Rüdiger,

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).

Welche linbo-version habt ihr den?

LG

Holger

Hallo Rüdiger,

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).

LG

Max

Dateiname: xenial-falk.cloop.postsync
Linbo: LINBO 2.3.22-0

Hallo Max,
gute Idee, werde ich mal machen!