folgendes - m.E. nicht richtiges - Verhalten legt Linbo an den Tag.
ich verändere etwas am Image eines Rechners (der, von dem ich immer Images erstelle), möchte es aber noch nicht hochladen, weil ich erst einige Änderungen zusammen kommen lassen möchte
Ich lasse Linbo ein Image auf dem lokalen Rechner im Cache erstellen um es beim versehentlichen syncen nicht zu zerstören
Ich drücke den Button “Sync” und Linbo holt das ältere Image vom Server. Das gerade im Cache erstelle Image wird überschrieben, meine Änderungen sind weg.
Hallo Alois,
das Verhalten ist zumindest logisch: Das lmage auf dem Server gewinnt.
Wenn das auf dem Client gewinnen soll, einfach den Netzwerkstecker ziehen
und offline synchronisieren.
Gruß Jürgen
klingt für mich doch ganz logisch:
Das Image im Cache stimmt nicht mit dem auf dem Server überein (warum,
kann Linbo ja nicht wissen), also wird die Version vom Server gezogen
und gesynct. So soll das sein. Die Version auf dem Server sticht die im
Cache. Wenn du das nicht willst, darfst du nicht syncen oder musst dabei
das Netzwerkkabel ziehen.
für mich wars logisch dass das Image im Cache das neuere ist und deshalb erhalten bleibt. Ich hatte mir gedacht, dass ich auf diese Weise Änderungen “sammeln” könnte und dann - z.B. am Wochenende - hochladen und verteilen könnte.
Den Netzwerkstecker ziehen würde nur Sinn ergeben, wenn ich der Einzige an dem Rechner wäre. Da aber theoretisch jeder Lehrer an dem Platz arbeiten kann wäre Stecker ziehen kontraproduktiv.
ich würde sagen: weder noch. Es liegt daran, dass Linbo für das aktuelle Image immer denselben Namen verwendet und dann das Image auf dem Server für das aktuelle gehalten wird. Dein Vorgehen ist schlichtweg nicht vorgesehen.
Ich finde das auch ungeschickt, unter anderem landet so dasselbe Image immer zweimal im Backup (einmal mit dem normalen Namen, und wenn es dann ein neueres Image gibt nochmal mit einem Zeitstempel im Namen) und hatte dafür vor längerer Zeit mal ein Ticket erstellt, das wurde aber (noch?) nicht umgesetzt.
Wir lösen Dein Problem einstweilen, indem wir immer zwei Varianten von einem Image vorhalten, z. B. win7-a.cloop und win7-b.cloop. Wenn -a aktiv ist, dann nenne ich das neue -b und kann es gefahrlos auf den Sever hochladen. Möchte ich es aktivieren und ausrollen, dann ändere ich den Imagenamen in der start.conf. Da das Ausrollen eines Image bei uns recht lange dauert, geht das auf keinen Fall während Unterricht ist, und so klappt das ganz gut.
cd /var/linbo/
mkdir aktuelles_Image
mkdir neues_Image
mv xenial* aktuelles_Image
--> jetzt neues Image erstellen lassen und hochladen
mv xenial* neues_Image
cd aktuelles_Image
mv * .. oder alternativ cp * ..
So hätte man zwar serverseitig zwei Versionen – diese aber sauber getrennt. Ok, ich gebe zu: Es ist Handarbeit angesagt…
Wer es bequemer haben will, kann sich ja mal dieses kleine Script ansehen: Damit könnte man es auf dem Server automatisieren und immer ein paar Versionen des aktuellen cloops vorhalten: http://stefan.blochberger.de/projekte/backupskript.php
Klingt für mich auch nachvollziehbar – doch ich glaube, dass LINBO nur danach schaut, ob die Größe beider Images übereinstimmt und immer das Image vom Server holt, wenn das nicht der Fall ist. Das Erstellungsdatum wird meiner Meinung hier gar nicht untersucht, oder??
Bei uns ist es so, dass die Clients nicht per default synchronisiert starten (jaaa, ich weiß – es ist anders vorgesehen ;)). Daher kann ich bei jeder Änderung des Master-Images immer alles sofort hochladen. Die Clients bekommen das dann erst nach Aufforderung verpasst…
aber was passiert wenn das Image auf dem Server das neuere ist und auf den Client geladen werden soll? Woher weiß der Client/Server welches Image das neuere ist?
Da hilft nur ein eingebauter Zeitstempel oder - so machen das manche - man hat einfach einen Rechner auf dem nur der Administrator ausschließlich am Image arbeitet. Dann kann man den Rechner offline Synchronisieren, wenn s notwendig ist und so kann man vor dem ausrollen des neuen Images mehrere Änderungen nacheinander einarbeiten.
Der wäre doch mit dem Befehl „stat -c %Y“ direkt verfügbar?!?
file1time=`stat -c %Y xenial.cloop` (Server)
file2time=`stat -c %Y xenial.cloop` (Client)
if [ "$file1time" -gt "$file2time" ];
then
scp "from Server to client"...
fi
Ich sehe den Nachteil eher darin, dass man u.U. auf den Clients unterschiedliche .cloops haben könnte, die jeweils einen aktuelleren Zeitstempel als auf dem Server besitzen, und dadurch (wenn’s schlecht läuft) in einem Raum unterschiedliche Images laufen hat, obwohl man denkt, dass alles synchron mit dem Server ist…
… unter’m Strich würde ich daher auch sagen: Kein Bug.