Frage zu linbo-remote

Michael · 7. April 2017 um 11:16

Hi, die nächste.
Nachdem ich heute einen Raum mit linbo-remote bestückt habe, bin ich auf ein seltsames Problem gestoßen. EIGENTLICH wollte ich benutzen:

linbo-remote -i 10.20.100.1 -c format,initcache:torrent,sync:1,sync:2,start:1

Das scheiterte daran, dass manchmal Windows auf der 2. Partition NICHT synchronisiert wurde. Danach habe ich es umgedreht und zunächst NUR:

linbo-remote -i 10.20.100.1 -c initcache:torrent,sync:2

Das erneute Formatieren war ja nicht mehr notwendig. Das scheitert dann aber seltsamerweise daran, dass ich nach dem ersten Befehl jetzt nicht mehr mit linbo-remote auf den client gelange: “ssh pubkey denied” oder so ähnlich. Nach dem nächsten reboot ging das aber wieder. Aber dazu war natürlich dann Turnschuh-Administration notwendig, da der Reboot ja nicht mehr remote ausgelöst werden konnte.

Nächster Versuch so:

linbo-remote -i 10.20.100.1 -c initcache:torrent,sync:2,sync:1,reboot

Dabei wurde das reboot aber ebenfalls nicht ausgeführt

Alles in allem läßt sich also sagen, dass ich mich heute bei mehreren Befehlen hintereinander nicht 100%ig darauf verlassen konnte, dass auch alle abgearbeitet werden. Mir kommt es fast so vor, als würde der letzte Befehl in der Reihe nicht mehr abgesetzt?!? Ist das ein gängiges Problem? Ich meine, dass wir das irgendwann schon mal diskutiert hatten…

Hier: Linbo 2.2.16 mit V.6.1

baumhof · 7. April 2017 um 13:40

Hallo Michael,

Alles in allem läßt sich also sagen, dass ich mich heute bei mehreren
Befehlen hintereinander nicht 100%ig darauf verlassen konnte, dass auch
alle abgearbeitet werden. Ist das ein gängiges Problem? Ich meine, dass
wir das irgendwann schon mal diskutiert hatten…

ja: das hatten wir schon mal.
Damals war das Image defekt: bei dir wohl das der zweiten Partition.
Einmal fscheck und neu erstellen hat das Problem behoben.

Was steht den in den linbo logs eines betroffenen CLinets?

LG

Holger

Michael · 7. April 2017 um 13:54

Hmmmm, wenn das .cloop der winXP-Partition defekt gewesen wäre, hätte die Synchronisation aber gar nicht klappen dürfen, oder? Das funktionierte aber letztlich schrittweise, wenn man nur einen Befehl abgesetzt hat.

Was die Log-Files angeht: die habe ich schon gesucht aber nicht (mehr) gefunden. Wo sind sie geblieben?
(unter /var/log/linuxmuster/linbo/ jedenfalls nicht)

… ich sehe gerade, dass wir das Problem kürzlich schon mal hatten: der passwortlose Zugang ist hier nicht das Problem. Die Datei, um die es da ging, ist auch auch da. Es fehlen aber auch hier die Client-Log-Dateien. Vermutlich hängt das mit dem Update 6.0 --> 6.1 zusammen, das wir erst vor nicht allzu langer Zeit gemacht haben.

@Freie-Bildung Wie habt ihr das gelöst?

Michael · 7. April 2017 um 15:39

[…etwas später…]
Gerade habe ich nochmal einen Client ein Image anlegen und hochladen lassen. Das kleine LINBO-Fenster meldet:

und

Sieht alles normal aus. Nach dieser Meldung habe ich mich per linbo-ssh auf dem Client eingeloggt und remote unter /tmp/ die Datei linbo.log gefunden. Und was soll ich sagen: Sie ist 0 Byte groß! Normal? Allerdings ist fast alles andere, was da liegt, ebenfalls 0 Byte groß…!!!

Auf dem Server ist weiterhin nichts zu finden.
Übrigens habe ich schon gesehen, dass die Log-Dateien offenbar über das Mail-System abgewickelt werden. Daher der naheliegende Gedanke, ob vielleicht da da der Hase im Pfeffer liegt?

Was passiert bei euch, wenn ihr den Befehl

/usr/share/linuxmuster-linbo/mail2log.sh

einfach in einer Shell laufen lasst? Hier wurde maximal serverseitig die Datei
/var/log/linuxmuster/linbo/_.log
mit dem Inhalt

### New session started at Fri, 07 Apr 2017 17:28:42 +0200 ###

erzeugt und das war’s. Der Befehl /usr/share/linuxmuster-linbo/mail2log.sh läuft aber nicht erfolgreich durch und gibt die Shell nicht wieder frei. Also irgendwas ist da faul … Wer hat eine sinnvolle Idee? Auf die LINBO-Logs würde ich nur ungerne verzichten…

baumhof · 7. April 2017 um 21:19

Hallo Michael,

Hmmmm, wenn das .cloop der winXP-Partition defekt gewesen wäre, hätte
die Synchronisation aber gar nicht klappen dürfen, oder?

… ist WinXP dein zweites System?
Die Probleme waren doch bei sync:2, also nicht bei XP…

LG

Holger

baumhof · 7. April 2017 um 21:20

Hallo Michael,

Sieht alles normal aus. Nach dieser Meldung habe ich mich per linbo-ssh
auf dem Client eingeloggt und remote unter /tmp/ die Datei linbo.log
gefunden. Und was soll ich sagen: Sie ist 0 Byte groß! Normal?
Allerdings ist fast alles andere, was da liegt, ebenfalls 0 Byte groß…!!!

da scheint das Cachedateisystem auf dem Cleint defekt: hat wohl jemand
während des laufenden Linbos den Netzwstecker gezogen …

Neu Partitionieren und nochmal versuchen: dann klappt es auch mit den
Logs wieder.

Auf dem Server ist weiterhin nichts zu finden.
Übrigens habe ich schon gesehen, dass die Log-Dateien offenbar über das
Mail-System abgewickelt werden
http://lml.support-netz.de/trac/wiki/LINBO-Workaround-Logging-abschalten.
Daher der naheliegende Gedanke, ob vielleicht da da der Hase im Pfeffer
liegt?

… der BUG ist sehr alt … den hast du nicht.

LG

Holger

Michael · 8. April 2017 um 05:50

Bei uns liegt Ubuntu auf sda1 und XP auf sda2 (alles ext4 Partitionen) – also ja: XP ist hinten.

Den Bug nicht … aber das Script mail2log.sh gibt es ja weiterhin und stellt die Log-Datei zu, wenn ich das richtig deute?! So wie es aussieht, wird die linbo.log-Datei lokal auf den Clients erzeugt und am Ende übertragen? Ansonsten müsste der Linbo-Client ja von außen Schreibrechte auf /var/log/linuxmuster/linbo haben, was ich nicht glaube?!?

Nein, das kann es nicht sein, da ich KEINE einzige Log-Datei mehr von LINBO habe. Ich hatte ja einen kompletten Raum neu aufgesetzt. Ich vermute, dass das Problem eher an völlig unerwarteter Stelle liegt, nämlich am Mail-Server. Mit dem Upgrade auf 6.1 wollte ich eigentlich auch die Umstellung auf einen externen Domainnamen machen. Ich vermute mal, dass es da irgendwo klemmen könnte. Und tatsächlich habe ich gerade unter

server /var/log # tail mail.err
mehrfach so eine Meldung entdeckt:
server cyrus/chk_cyrus[4381]: user.administrator uid 2 rediscovered - appending

Ich kenne mich nicht gut genug mit dem Mailserver aus, um den Fehler da einkreisen zu können. Aber mail2log sollte eigentlich alles richtig zustellen??!

Ok, der Thread hat sich jetzt in eine völlig andere Richtung entwickelt als das, was ich eigentlich klären wollte. Das linbo-remote-Problem von oben bleibt leider unabhängig (?) von den nicht mehr vorhandenen Log-Dateien bestehen…