Hallo!
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.
LG
Max
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.
Guten Start in die kurze Woche
Wolfgang
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 
Hallo Michael super,
aus Griechenland hört man ja sonst nur Krise.
MfG
Wolfgang
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!
Im Wiki ist das leider nicht vollständig beschrieben und wie schon öfter gilt: Ich habe dort keine Schreibrechte und kann es demzufolge auch nicht ändern. Wer kann das übernehmen?
https://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:epoptes
Hallo Michael,
in der Anleitung steht:
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.
Grüße,
Sven
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
Hallo Michael,
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.
Grüße,
Sven
Ja, das kann schon sein, dass das bei uns das Problem war. Aber umso besser, dass es nun geklärt ist …
Hallo Michael,
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.
Gruß Jürgen
P.S.: Die letzten beiden Einträge können fatal sein, wenn unter /media noch etwas eingehängt ist …
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.
Ich grab mal diese Leiche aus, zwei Fragen zu Epoptes:
- Wie spricht man das aus? Eben gefunden, grnsu wie man es auf deutsch spricht: http://www.epoptes.org/
- Wozu die Ansible role im Wiki? Die Anleitung im Wiki scheint ja ohne Ansible auszukommen oder hab ich da einen Denkfehler?
https://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:epoptes
Hi,
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:
vG Stephan
2 „Gefällt mir“
Hallo Stephan,
schöne Anleitung!
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
Viele Grüße
Andreas
3 „Gefällt mir“