Hallo Dominik, Am 13.09.2014 um 07:10 schrieb Dominik Förderer: > Hallo Thomas, > > danke für die Antwort! > >> mit Einführung des Parameters -p hat sich die Bedienlogik von >> linbo-remote entscheidend geändert. Das muss in der Doku noch besser >> herausgestellt werden. >> Versuch mal mit eingeschaltetem Autostart >> linbo-remote -p <Befehlsliste> -w 0 -i <Host> >> Damit werden die Befehle abgearbeitet bevor die start.conf ausgewertet wird. > > OK klar, das funktioniert! Ein wirklich entscheidender Nachteil am > Paramter -p ist jedoch, dass es z.B. keine screensession für den > Remote-Befehl auf dem Server mehr gibt/geben kann und man daher von zu > Hause dem Client nicht mehr "zuschauen" kann; das wird doch häufig zum > Debuggen benutzt, bzw. bei sehr vielen Clients kann man schnell sehen, > wenn alle fertig sind...klar man könnte die Clients jetzt mit -p + > fake-Befehl aufwecken und dann mit -c die gewünschten Befehle absetzen > aber das ist ja nicht sehr komfortabel...
ist bei -p technisch nicht möglich, dafür hat dieser Parameter andere Vorteile. > >> -c ist eigentlich nur noch bei Clients sinnvoll, die schon online sind >> und nicht mehr aufgeweckt werden müssen. Deshalb habe ich die >> Manipulation der start.conf rausgenommen, da dies auch zu Fehlern >> führte, wenn ein linbo-remote-Aufruf aus irgendeinem Grund abgebrochen >> wurde. > > Ok, das habe ich kapiert...es ist aber schon eine wirklich krasse > Fehlerquelle für Leute wie mich, die linbo-remote (mit -c) in den > letzten Jahren exzessiv benutzt haben...bei mir war wie gesagt die > Arbeit von einigen Stunden weg, weil die Befehle von -c ignoriert > wurden. Ich würde wirklich vorschlagen, dass entweder -w nicht mehr > zusammen mit -c funktionieren darf oder noch viel lieber, dass es einen > weiteren Parameter (was weiß ich -s) gibt der die Manipulation an der > start.conf auch mit -c vollzieht...damit hätten wir auch wieder die > Screensessions, d.h. das alte Verhalten von linbo-remote > -c funktioniert wie bisher, mit der einzigen Einschränkung, dass er nun mit einem etwaigen autostart ins Gehege kommt. Auch wenn es bei dir meist geklappt hat, so hatten andere immer wieder tote Links zu reparieren. Um das gewünschte Verhalten zu erreichen erstellst du einfach für die Rechnergruppe eine zusätzliche start.conf ohne Autostart und rufst linbo-remote über ein Shellskript auf, das folgendes tut: 1. sichere originale start.conf 2. kopiere start.conf ohne Autostart 3. setzte linbo-remote ab 4. warte ein Weilchen 5. kopiere originale start.conf zurück Das ist flexibler, da du eine für deine Zwecke angepasste temporäre start.conf verwenden kannst. > Nur fürs Protokoll: bei mir gab es bei bestimmt einigen zehntausenden > abgesetzten linbo-remote Befehlen mit -c in den letzten Jahren nur ein > einziges Mal das Problem, dass eine start.conf zerschossen war... > >>> - bei ausgeschaltetem Autostart gibt es weitere Probleme; die >>> Remote-Befehle partition und initcache werden komplett ignoriert; per >>> linbo_wrapper direkt auf dem Client gestartet funktionieren sie aber. >>> Ganz toll, wenn man z.B. an einer postsync-Datei etwas ändert und sich >>> wundert einen halben Tag lang wundert, warum nach einem initcache noch >>> alles beim Alten ist... >> >> Das kann ich hier nicht nachvollziehen. > > Ok! Nach genauerem Test: das Problem tritt nur auf (bei ausgeschaltetem > Autostart), wenn ich folgenden Befehl absetze: linbo-remote -i <Host> -w > <Wartezeit> -c partition oder initcache oder beides. > > Entweder dieses Problem haben also nur Wilfried und ich...oder es ist > einfach nicht mehr sinnvoll -c mit -w zu benutzen s.o. > > Wo kann ich denn ggf. bei der Problemsuche anfangen? > Erhöhe mal die Wartezeit. Wenn nicht partitioniert wird, muss doch auf der Konsole eine entsprechende Meldung erscheinen. >>> 4. import_workstations - pxe-Bootconfig >>> >>> - bei import_workstation werden nicht für alle Hardwareklassen >>> pxe-Bottkonfigs in /var/linbo/pxelinux.cfg/<Hwkname> aus der >>> Defaultkonfiguration erzeugt. Und wenn doch, dann werden bei einigen >>> HWK's Änderungen in der start.conf.<Hwkklasse> an den Kernel-Options für >>> linbo nach einem import_workstations nicht in die pxe-Bootkonfig >>> geschrieben... >>> >> >> Hier erzeugt import_workstations für alle Rechnergruppen, für die >> PXE-Boot vorgesehen ist PXE-Boot-Konfigurationsdateien, wenn noch keine >> vorhanden ist. Kernel-Optionen werden nur angepasst, wenn in der >> PXE-Boot-Konfigurationsdatei der Rechnergruppe die Zeile >> ### managed by linuxmuster.net ### >> vorhanden ist (siehe http://is.gd/HJjlHY). > > Habe/Hatte ich kapiert. Es funktioniert bei mir nur einfach nicht für > alle HWk's! Es wird leider für genau eine Gruppe keine > PXE-Boot-Konfigurationsdatei erzeugt, wenn sie nicht da ist. Ich muss > per Hand eine hinschieben...z.B. die default-Konfig. In der steht die > Zeile ### managed by linuxmuster.net ###. Trotzdem werden eben > Änderungen an den Kernel-Optionen nicht übernommen. > > Wo soll ich denn bei der Fehlersuche hinschauen? Auffällig ist, dass bei > import_workstation für alle Rechnergruppen eine Meldung kommt wie: > > LINBO-Group precise-esprimo keeping pxe config > (bei eigener pxe-Datei) oder > > LINBO-Group precise-testing writing pxe config > (bei ### managed by linuxmuster.net ### pxe-Datei) > > bis eben auf eine Rechnergruppe. Da kommt keine solche Meldung und > folglich wird also überhaupt nichts erzeugt oder behalten. Die Links auf > die Gruppe unter /var/linbo/pxelinux.cfg (z.B. 0A110566 -> trusty) > werden aber korrekt erzeugt. > Nenn die Gruppe testweise mal anders. VG, Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
