Epoptes findet Clients nicht

Clientpflege Linuxclient
1

Hi.
Wir haben testweise einen Lehrer-Rechner und einen Schüler-Client mit Ubuntu 16.04 bestückt.
Die Epoptes-Installation habe ich nach Anleitung durchgeführt. Offenbar kann ich das Programm auch als Lehrer richtig starten, doch dann werden leider keine Clients gefunden.
Auf dem Schülerrechner müsste ja ein “ps aux |grep epoptes” irgendwas liefern, oder? Das funktioniert aber leider nicht. Entweder wurde der Dienst also gar nicht erst gestartet oder gleich wieder beendet.

Hat jemand einen Tipp, woran das scheitern kann?
Den Tipp aus dem Wiki (IP-Adresse anstelle von Hostname) habe ich schon ausprobiert – gleicher Effekt. Es ist ja nicht mehr so wie unter iTalc, dass man die Listen mit den Räumen/Clients selbst anlegen muss, wenn ich das richtig sehe?

[… etwas später …]
Mir fiel noch auf, dass man auf dem Schüler-Rechner /usr/sbin/epoptes-client zwar manuell starten kann; doch das Programm beendet sich nach kurzer Zeit wieder. Ich konnte das bisher nur per ssh ausprobieren und habe keine Fehlermeldungen gesehen.
Hier steht aber noch als Hinweis, dass man den Aufruf auch mit der IP des Lehrer-Rechners ausprobieren kann. Dieser Test steht noch aus…

Allerdings wird etwas weiter oben auch die Option sudo epoptes-client -c erwähnt. Davon ist im Wiki jedoch keine Rede?!?

2

Hallo Michael,

führt linbo postsync auf Deinen Clients richtig aus?

Gruß Jürgen

3

Ja, ich habe die Rechte der Dateien nochmal überprüft. Es ist alles so, wie es im Wiki beschrieben ist.
Seltsamerweise kann ich aber auch als root nicht “/usr/sbin/epoptes-client” starten. Ich habe das gerade nochmal ausprobiert. Es wird nicht als daemon gestartet (aber es gibt auch keine Fehlermeldung).

Nur zum Vergleich: Es sollte doch so sein, dass auf allen Clients “/usr/sbin/epoptes-client” läuft, richtig? Ich habe in dem epoptes-client-Script ein “set -x” ergänzt, um in den Debug-Mode zu gelangen.
Jetzt erhalte ich diesen Output, wenn ich das Script als root laufen lasse:

root@raum1-pc01:/etc/epoptes# epoptes-client 
+ export VERSION=0.5.7
+ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/sbin:/usr/sbin
+ [ -z de_DE.UTF-8 ]
+ basic_info
+ test -n 
+ id -u
+ UID=0
+ [ 0 -eq 0 ]
+ [ -f /usr/share/ltsp/ltsp_config ]
+ [ -n  ]
+ my_boolean_is_true 
+ return 1
+ [ -n  ]
+ TYPE=standalone
+ [ standalone = thin ]
+ chrooted
+ test -n 
+ test -n 0
+ [ 0 -gt 0 ]
+ stat -c %d/%i /
+ stat -Lc %d/%i /proc/1/root
+ [ 2049/2 = 2049/2 ]
+ chrooted=1
+ return 1
+ SERVER=server
+ PORT=789
+ export UID TYPE SERVER PORT
+ [ -f /etc/default/epoptes-client ]
+ . /etc/default/epoptes-client
+ SERVER=raum1-lehrer-pc
+ PORT=789
+ WOL=g
+ export SERVER=raum1-lehrer-pc
+ export PORT=789
+ test -n 
+ [ 0 -eq 0 ]
+ [ standalone = standalone ]
+ [ -x /usr/bin/epoptes ]
+ exit 0

Und wenn ich mit der Option “-c” starte, erhalte ich die Meldung:

depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
DONE
+ [ -s /etc/epoptes/server.crt ]
+ echo Successfully fetched certificate from raum1-lehrer-pc:789
Successfully fetched certificate from raum1-lehrer-pc:789
+ exit 0

Das sieht ja erstmal alles gut und richtig aus.
Allerdings bleibt der epoptes-client eben nicht gestartet … bzw er beendet sich sofort wieder und läuft auch nicht als Daemon.
Könnte jemand bei sich nachsehen, was ein “ps aux |grep epoptes” auf einem Client liefert?

Hier läuft übrigens auf den Clients:

epoptes-client -v
0.5.7

Offiziell freigegeben ist 0.5.10, was auch in den Repos sein sollte. Wie ist das bei Euch?

4

Hallo Michael,

bei liefert der Epoptes Client solch eine Ausgabe:

root 15369 0.0 0.0 14516 940 pts/8 S+ 16:22 0:00 grep --color=auto epoptes

Ich meine mich aber zu erinnern, ein ähnliches Problem gehabt zu haben,
dass ich durch ein automatiertes "service epoptes restart“ (oder so ähnlich) behoben habe.

Ansonsten habe ich ebenfalls die Anleitung befolgt.

Schönen Gruß,

Sebastian

5

Seltsam – wenn das alles ist, läuft bei dir ja ebenfalls der „epoptes-client“ nicht!!! Das verstehe ich nicht.
Ich habe vorhin zusätzlich nochmal die Upstart-Scripte angelegt (XDG autostart war ja default) und werde das Image Freitag nochmal synchronisieren lassen.

Kannst du das noch herausfinden, wie es genau ging? Ich sehe allerdings auch noch nicht ganz ein, warum du „epoptes“ als Service/Daemon starten willst (und nicht epoptes-client)??

6

Neuer Versuch … ich habe gerade erst gesehen, dass auf den clients eine Log-Datei unter
/var/log/epoptes.log angelegt wird :sunny:

Nach dem, was Sebastian meinte, habe ich auch auf den Clients versucht, den Dienst “epoptes” neu zu starten.

service epoptes restart
Job for epoptes.service failed because the control process exited with error code. 
See "systemctl status epoptes.service" and "journalctl -xe" for details.

Dann erhält man:

root@raum1-pc01:/etc/epoptes# systemctl status epoptes.service
● epoptes.service - LSB: Epoptes service
   Loaded: loaded (/etc/init.d/epoptes; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fr 2017-03-31 16:34:54 CEST; 20min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4722 ExecStart=/etc/init.d/epoptes start (code=exited, status=1/FAILURE)

Mär 31 16:34:54 raum1-pc01 systemd[1]: Starting LSB: Epoptes service...
Mär 31 16:34:54 raum1-pc01 epoptes[4722]:  * Starting the epoptes daemon
Mär 31 16:34:54 raum1-pc01 epoptes[4722]: An error has occurred: '[('x509 certificate routines', 'X509_check_private_key'
Mär 31 16:34:54 raum1-pc01 epoptes[4722]: Please look at log file for more information.
Mär 31 16:34:54 raum1-pc01 epoptes[4722]:    ...fail!
Mär 31 16:34:54 raum1-pc01 systemd[1]: epoptes.service: Control process exited, code=exited status=1
Mär 31 16:34:54 raum1-pc01 systemd[1]: Failed to start LSB: Epoptes service.
Mär 31 16:34:54 raum1-pc01 systemd[1]: epoptes.service: Unit entered failed state.
Mär 31 16:34:54 raum1-pc01 systemd[1]: epoptes.service: Failed with result 'exit-code'.

Dort wird also das Zertifikat angemeckert (obwohl der Test mit dem Schalter -c erfolgreich lief!)
Die Rechte von /etc/epoptes/server.key und server.crt habe ich nochmal überprüft. Die passen!

In der Log-Datei steht dann neben allerlei python-Meldungen, die ich hier nicht alle posten muss, ganz am Ende noch:

2017-03-31 16:58:48+0200 [-] OpenSSL.SSL.Error: [('x509 certificate routines', 'X509_check_private_key', 'key values mismatch')]

Das finde ich merkwürdig. da die keys ja vom Postsync-Script verteilt werden?!

7

Sooooo – das Problem ist gelöst und es lag an unerwarteter Stelle: Ich hatte epoptes schon vor Monaten eingerichtet und jetzt zwei Rechner neu synchronisiert. Nach meinem Wissen ist mit epoptes & postsync zum ersten Mal der Fall aufgetreten, dass man nicht nur .conf-Dateien oder Rechte anpasst, sondern dass man das komplette Programm unter /usr/bin/ und /usr/sbin/ durch postsync ersetzen läßt. Genau hier lag das Problem, denn auf den Clients war eigentlich Version 0.5.10 installiert – doch durch das postsync wurde immer wieder 0.5.7 drüberher gebügelt.

Das ist meiner Meinung nach zum ersten Mal ein Nachteil von Postsync, da man mit jedem Programm-Update nun daran denken muss, auch die Files unter /var/linbo/linuxmuster-client/ zu ändern.
Nach diesen Anpassungen lief es jedenfalls – und es macht einen guten Eindruck!

Wie schon unter iTalc stellt sich aber auch hier die Frage, ob man es hinbekommen kann, dass die Clients schon vom Lehrer-PC aus verwaltbar sind, BEVOR überhaupt irgendein User angemeldet ist. Das geht hier bisher nicht bzw erscheinen die Clients erst dann am Lehrer-PC, wenn irgendein User angemeldet ist.

8

Hallo Michael! (jetzt auch an de Liste) :wink:

Bei uns kann man die Schülerrechner schon steuern, wenn sie noch nicht eingeschaltet sind.
Das liegt vermutlich an den raumspezifischen Epoptes-Konfigurationsdateien, die auch
gleich per postsync auf den Lehrerrechner geschoben werden. (Ist schon eine Weile her, dass ich das eingerichtet hab.)
Damit werden dann gleich beim Start von Epoptes die Schülerrechner zu diesem Lehrerrechner angezeigt.

-> /var/linbo/linuxmuster-client/IMAGEGRUPPE/LEHRERRECHNER/home/linuxadmin/.config/epoptes/groups.json

{
“clients”: {
“0”: {
“alias”: “j1011p01”,
“mac”: “90:E6:BA:AA:BB:CC”
},
“1”: {
“alias”: “j1011p02”,
“mac”: “90:E6:BA:BB:CC:DD”
},
“2”: {
“alias”: “j1011p03”,
“mac”: “90:E6:BA:BB:AA:AA”
},
“3”: {
“alias”: “j1011p04”,
“mac”: “90:E6:BA:BB:BB:BB”
},

(...)

"16": {
  "alias": "j1011p17",
  "mac": "90:E6:BA:EE:EE:EE"
},
"17": {
  "alias": "j1011p18",
  "mac": "90:E6:BA:FF:FF:FF"
}

},
“groups”: [
{
“name”: “J10.11”,
“members”: {
“0”: {},
“1”: {},
“2”: {},
“3”: {},

   (...)

    "16": {},
    "17": {}
  }
}

]
}

und

-> /var/linbo/linuxmuster-client/IMAGEGRUPPE/LEHRERECHNER/home/linuxadmin/.config/epoptes/settings

[GUI]
messages_default_title = Nachricht von der Lehrkraft
messages_use_markup = False
grabkbdptr = False
selected_group = 1
showrealnames = False
thumbnails_width = 100
label = miClientsViewHostUser

Das landet dann im home des Vorlagenbenutzers (linuxadmin) und die
Benutzer erhalten dies bei der Anmeldung genau so nach
/home/teachers/BENUTZER/.config/epoptes/… kopiert.

Gruß - Rainer

9

:slight_smile:

Typo? Meinst du „noch nicht angemeldet“?

Ich vermute, dass man die erste Datei auf diese Art erhält: Alle Clients sollten einmal (angemeldet) unter Epoptes erschienen sein. Daraufhin wird scheinbar die .conf-Datei mit passenden Namen und MAC-Adresseen angelegt. Diese Datei kann man sich dann sichern und per Postsync an die passende Stelle kopieren. Korrekt?

So weit bin ich leider noch nicht, da ich bisher nur einen Client zum Testen aufgesetzt habe… aber die Idee ist super, da man dann ja auch zentral alle Rechner ausschalten kann.

(Übrigens noch ein Nachtrag: Wenn epoptes läuft, sollte „ps aux“ so etwas ausspucken:

/usr/bin/python /usr/bin/twistd --pidfile /var/run/epoptes.pid --logfile /var/log/epoptes.log epoptes )

10

Hallo Michael!

Kein Typo: Man kann die Rechner über Epoptes auch einschalten, per
Fernsteuerung jemanden anmelden, … und am Ende alle ausschalten. Also
Unterricht auch ganz ohne Schüler ist denkbar ohne seinen Lehrerplatz zu
verlassen. :wink:

Bestimmt kann man die Konfigurationsdatei auch von Epoptes erstellen
lassen und dann wegsichern? Vermutlich war das mein Weg zur ersten Datei
für den ersten Raum.

Korrekt? -> Korrekt!

Gruß - Rainer

11

Hallo Michael,

ich habe gerade festgestellt, dass genau das der Fall ist …

Mit ist bei einem der letzten Updates die Postsync verloren gegangen, ohne dass ich das bemerkt habe.

Bitte entschuldige die Verwirrung.

Jetzt habe ich die Ausgabe nochmal erzeugen lassen und vorher getestet, dass epoptes auch wirklich noch läuft.

Ich erhalte die folgenden Zeilen auf einem epoptes-Client:
(Tatsächlich sogar jeweils doppelt, so dass ich da noch einen Fehler drin haben muss.)

root 1448 0.0 0.0 24496 4852 ? S 12:58 0:00 socat -T 60 openssl-connect:10.16.206.1:789,cafile=/etc/epoptes/server.crt,commonname="",interval=60,forever EXEC:bash -c "exec -a epoptes-client sh"
root 2472 0.0 0.0 4508 1736 ? S 13:01 0:00 epoptes-client

———————

Den von Dir später beschriebenen Postsync-Nachteil könnte man ausgleichen:

Im Image ist der aktuelle Epoptes-Client enthalten und per Postsync wird dieser Client mit einer leeren Datei überschrieben,
wenn er nicht erwünscht ist. So gibt es dann keine Versionskonflikte.

Schönen Gruß,

Sebastian

12

Hi. wenn ich das richtig sehe, startet dieser Prozess erst, wenn jemand angemeldet ist. Zuvor läuft da nur der Client. Daher war mir das „kill“ aus dem Upstart-Script im Wiki auch nicht ganz klar!?

Super! Aber das geht wieder „nur“ via WOL, richtig? Bei uns sind an den Hauptschaltern Schütze eingebaut. Einmal komplett ausgeschaltet, geht danach nichts mehr :frowning:

Die Sache mit der .config schaue ich mir noch an. Das sieht vielversprechend aus!
Und dass man das Postsync dann ja auch vereinfachen könnte und NUR die dummy-Datei vom „epoptes-client“ synchronisieren läßt, gehört natürlich dann ins Wiki …

13

Hi. Heute habe ich einen Raum komplett auf 16.04 umgestellt. Epoptes läuft zwar jetzt; ich kann die Clients auch remote bedienen, abmelden und auch herunterfahren. Doch sobald ein User abgemeldet ist, bleibt’s dabei. Weder der Neustart noch eine neue Anmeldung klappen. Die Clients sehen hier dann so aus:

epoptes1.png955×481 75.7 KB

Die Info zeigt bei abgemeldeten/ausgeschalteten Clients auch nur noch die MAC-Adresse an:

… wohingegen bei angemeldeten Clients alle Infos stehen:

Wenn WOL klappen soll, muss diese Zuordnung offenbar erhalten bleiben?
Hast du deine config auch diesbezüglich bearbeitet? Im Moment habe ich die beiden Dateien nur gesichert und werden sie ins linuxadmin-Verzeichnis packen…

(Ansonsten kann ich übrigens das bestätigen, was auch schon andere meinten: Epoptes läuft extrem flüssig. Ein absolutes must-have bei uns!)

[… etwas später …] Idee: Kann es sein, dass dieser Zustand mit dem upstart-Script zusammenhängt, der im Wiki beschrieben wird? Ist das bei euch aktiviert oder nicht?

14

Hi.
Ich habe mir die Sache nochmal angesehen.
Der Start von epoptes-client soll laut Wiki von upstart durchgeführt werden. Daher habe ich zunächst den Eintrag unter
/etc/xdg/autostart gelöscht.

Als nächstes habe ich die An-/Abmeldung als linuxadmin beobachtet, wenn man die Upstart-Scripte aktiviert hat. Es ist ja so eingestellt, dass beim Beenden der Session (Abmeldung) der epoptes-client gekillt werden soll (wobei der angegebene kill-Befehl aus dem Wiki hier nicht richtig läuft!).

Ich möchte es aber so haben, dass die Clients auch dann noch vom Lehrer-PC fernsteuerbar sind, wenn niemand mehr angemeldet ist. Daher muss der epoptes-client (bzw der socat-Befehl) natürlich noch laufen. Daher folgende Änderungen:

Unter /home/linuxadmin/.config/upstart/ den Teil stopEpoptes.conf löschen und die
startEpoptes.conf wiefolgt ändern:

description "Desktop Start Task"
start on desktop-start
task
script
   exec pkill socat &
  /usr/sbin/epoptes-client &
end script

Nun ist es so FAST wie es sein soll: Beim der Anmeldung wird der epoptes-client gestartet – und er läuft auch weiter, wenn sich der User abmeldet. Das “kill” ist eine “Sicherheitsmaßnahme”, damit der Prozess nicht doppelt läuft. Allerdings kann der User, der sich als nächstes anmeldet, nicht einfach einen Prozess killen, der ihm gar nicht gehört. Daher müsste der pkill-Prozess mit sudo-Rechten laufen, was bisher nicht klappt.

Zum anderen wird der Prozess als USER gestartet und ist dementsprechend auch als USER killbar, was natürlich nicht sein darf. Das habe ich auch festgestellt, wenn der epoptes-client via xdg/autostart ausgeführt wird. Man kann als User den Prozess killen, da er $user gehört!

Vielleiht liest ja ein upstart-Wizzard mit: Wie bekommt man es hin, dass der epoptes-client (bzw der Prozess
"socat -T 60 openssl-connect:server:789,cafile=/etc/epoptes/server.crt,commonname="",interval=60,forever EXEC:bash -c “exec -a epoptes-client sh” ) als root beim Systemstart ausgeführt wird und nicht gekillt wird, wenn sich jemand abmeldet? Zusätzlich darf dieser Prozess natürlich nur einmal laufen, damit er im Lehrer-PC nicht x-fach angezeigt wird. Bei wem läuft das 100%ig zuverlässig?

15

Und noch eine Antwort hinterher … ich habe mittlerweile einfach den Entwickler angefunkt. Es sieht so aus:

Jetzt ist also klar, woran es liegt, dass die Verbindung hier nicht klappt, wenn niemand eingeloggt ist! Der Prozess „socat …“ muss zweifach laufen: einmal als root und einmal als user! Der root-Prozess kann aber nur dann starten, wenn die Netzwerkverbindung sofort da ist, während Ubuntu noch startet. Es ist also ein Ubuntu-Problem bzw ein bekanntes Problem auf Epoptes-Seite. Wäre aber weiterhin interessant zu wissen, warum es scheinbar bei einigen hier klappt. Habt ihr die Verbindung evtl über /etc/network/interfaces eingerichtet? Klappt bei euch „ifup eth0“?

16

Cross-Link (der Vollständigkeit halber…)

17

Damit alles zusammen bleibt, poste ich die Lösung zum Problem auch nochmal in diesem Thread!

Ok, ich habe die Lösung – der Support von Epoptes via X11VNC hat wunderbar geklappt und in Nullkommanix hat der Autor der Software das Problem gefunden :slight_smile:

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

18

Hi @Michael

ich muss den Thread noch mal aufmachen, da Epoptes seit gestern (kein neues Image gemacht, eigentlich auch sonst nichts anderes) die Clients nicht mehr findet!? Ich muss morgen nochmal schauen, ob Epoptes auf den Clients läuft, aber per Postsync sollte eigentlich alles da sein.

vG

19

Ok, ich konnte den Fehler finden. Ich hatte die IPs in dem Raum angepasst und danach vergessen die IP auch in der /etc/hosts auf den Clients anzupassen.

Dazu habe ich aber noch eine Frage (vielleicht weiß @Michael mehr). In der Anleitung steht, dass man den Lehrerrechner in der /ect/hosts eintragen soll. Warum ist das nötig? Der DNS des Servers liefert ja genau die gleiche IP, die ich in diese Datei schreibe?!

vG

20

ich bin nicht mehr sicher aber ich glaube, dass ich alles direkt über die IPs und nicht über die Rechnernamen geregelt hatte …