Das weiß ich nicht, ich hab nur Ubuntu. Im Prizip denke ich aber schon, dass das funktioniert. VNC ist das ja egal und das Monitor Ausschalten funktioniert glaube ich über den selben Port, kriegt also auch nix vom BS mit.
um zu sehen, was beim Postsync passiert, kannst du folgendes machen. Starte deinen Rechner in Linbo und logge dich vom Server aus mit linbo-ssh labor-01 auf dem Client ein. Dann kannst du mit linbo-wrapper sync:1 (1 steht soweit ich weiß für das 1. Betriebssystem) den Sync+Postsync anstoßen.
Dann solltest du sehen, welche Dateien kopiert werden oder ob es Fehler gab (bei mir z.B. konnte es einige Dateien auf dem Server nicht lesen wegen fehlender Berechtigungen).
Und falls der Test von @zefanja zeigt, dass gar kein Postsync funktioniert, dann überprüfe nochmal, ob das Postsync-Skript richig eingebunden ist. Also:
Liegt das Postsynk-Skript in einer Datei /var/linbo/gleicherNameWieImage.cloop.postsync ?
Und ist richtig konfiguriert (ServerIP, Patchclass…)?
Hallo und danke für die Hinweise,
komme leider erst jetz dazu zu reagieren.
werde das am Wochenden testen.
Hallo Michael mein common verzeichnis sieht anders aus
common/etc/linuxmuster-client/server.network.settings
sonst steht da nichts drin
Inhalt der Datei server-network-settings:
Du hast V6.2; ich aber V6.1 – evtl deshalb?
Die Einträge unter /raum1-lehrer-pc/home/linuxadmin/.config/epoptes/ sind die config-Dateien, die epoptes anlegt, wenn es erstmal richtig läuft. Die habe ich (nach einem Tipp von Rainer) gesichert und lasse sie jetzt mit post-syncen.
ja. Es wird nur ein Postsync ausgeführt, wenn es auch eines gibt. Wenn Du xenial3.cloop verwendest, muss es dafür auch ein postsync geben. Du kannst ja das für xenial kopieren.
Hallo an alle die mitgedacht haben, händeschütteln.
auf meinem Testsystem läuft jetzt epoptes.
Mit diesem Befehl konnte ich schön mitlesen was schief lief.
Jetzt muss ich nur noch schauen das die Clients auch ohne Anmeldung zu sehen sind, aber das wurde ja schon hier beschrieben.
Ich weiß auch leider immernoch nicht, warum ich die Clients nicht mehr verwalten kann, wenn niemand mehr angemeldet ist. Es liegt offenbar daran, dass dann nur noch einmal der Prozess „socat“ läuft. Es ist aber nicht klar, warum der Prozess als linuxadmin bei der Abmeldung beendet wird.
Ich habe allerdings mittlerweile den Autor der Software in Griechenland angefunkt. Evtl kann er in den nächsten Tagen Live-Support bieten… dann sind wir schlauer
Ok, ich habe die Lösung – der Support via X11VNC hat wunderbar geklappt und in Nullkommanix hat der Autor der Software das Problem gefunden
Es liegt ganz einfach daran, dass auf dem Client das Programm /usr/bin/epoptes nicht exitieren darf! Im Wiki fehlt also eine entsprechende Anmerkung! Da ist die Rede davon, dass auf dem Server/Master-Rechner ein Dummy-File für epoptes-client anzulegen ist … doch genauso muss man auf dem Client ein Dummyfile für /usr/bin/epoptes anlegen.
Ich habe das gerade per Postsync ausprobiert … und es funktioniert jetzt! Man kann also nun auch Clients remote kontrollieren, an denen niemand angemeldet ist. Suuuper!
d.h. im Image ist /usr/bin/epoptes nicht vorhanden und wird laut Anleitung - für Schülerrechner - auch nicht per postsync hinterlegt.
Kannst du genauer beschreiben, an welcher Stelle die Anleitung unpräzise ist? Ich ändere das dann ggf.
Wir haben nur ein Image als Vorlage für Master und Client. Und ich habe die Datei nun auf den Clients durch eine leere Dummy-Datei ersetzt, nicht auf dem Master! Ich bin mir auch ziemlich sicher, dass ich damals strikt nach Anleitung vorgegangen bin.
Auf dem Master: epoptes muss da sein aber epotes-client nicht
Auf den Clients: epoptes-client muss da sein aber epoptes nicht.
Eigentlich alles logisch…
Mir fällt gerade auf: Vielleicht ist einfach nur das Wort 'Masterclient" in diesem Zshg irreführend bzw nicht eindeutig?
Möglichkeit 1: Der Client, der als Epoptes-Master läuft
Möglichkeit 2: Der Client, der als Linbo Vorlage (“Master”) für andere Clients läuft
auch wir haben nur ein Image (für alle Rechner im Haus). Diese werden per Postsync an die unterschiedlichen Anforderungen angepasst.
Wichtig bei der Imageerstellung ist, dass dies an einem Rechner passiert, auf den beim Postsync-Prozess keine Daten kopiert werden, da diese ja sonst im Image sind.
Um Verwirrgungen bzgl. „Master“ zu vermeiden spreche ich ja bzgl Epoptes auch von Lehrerrechner und Schülerrechner.
ich verwende für Lehrerrechner und Schülerrechner ebenfalls nur ein Image, in dem epoptes und epopte-client enthalten sind.
Wie epoptes eingerichtet wird, bestimmt der Inhalt der Unterverzeichnisse auf dem Server in /var/linbo/linuxmuster-client/xenial (oder wie Deine Gruppe heißt), die per postsync auf den Client kopiert werden. Entsprechende Listen wurden hier ja bereits bereit gestellt.
Das was nach der Installation falsch oder zu viel auf dem Client sein könnte, entferne ich mit lmlcc. Anbei ein Screenshot, aus dem hervorgeht, was das sein könnte.
Wie gesagt: Das ist alles nicht mehr notwendig – es reicht sogar aus, auf den Schülerrechnern ein
chmod -x /usr/bin/epoptes
laufen zu lassen. Hauptsache ist, dass auf allen Clients lediglich /usr/sbin/epoptes-client vorhanden bzw ausführbar ist, während es auf dem Lehrerrechner umgekehrt sein muss.
Ja, geht auch ohne. Die Ansible-Geschichte habe ich noch nie probiert, nimmt dir aber wahrscheinlich den Großteil der Arbeit ab. Ich habe letztens mal aufgeschrieben, wie wir das bei uns mit Epoptes gemacht haben:
Um das Problem mit den gelöschten Links in /etc/rc*.d beim Kernelupdate zu verhindern, liegen bei mir auf jedem Client in /etc/init.d “do-nothing-Skripte” epoptes und epoptes-client mit folgendem Inhalt:
#!/bin/sh
### BEGIN INIT INFO
# Provides: epoptes
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Epoptes service
# Description: A twisted-based daemon that manages epoptes-client
# and GUI connections.
### END INIT INFO