Einige Zeit funktionierte Epoptes einwandfrei. Vor ein paar Tagen ist mir aufgefallen, dass der Epoptes-Dienst nicht mehr startet. Am Lehrerrechner scheitert der Programmstart dann mit der Fehlermeldung “Ein Fehler ist beim Vebinden zum Epoptes-Dienst aufgetreten. Datei oder Verzeichnis nicht gefunden. Stellen Sie sicher, dass der Epoptes-Dienst gestartet ist”. Ergo: Der Dienst läuft einfach nicht…
Ein sudo service epoptes start kann ihn zwar starten, aber das kann man ja keinem Kollegen zumuten
Auch wenn es bei mir um epoptes (nicht um epoptes-client, wie hier) ging, hatte ich ein update als Auslöser im Verdacht und habe mit sudo apt-get install --reinstall epoptes das Ding nochmal installiert, Image geschrieben - leider erfolglos.
Wie kann ich herausfinden, woran es plötzlich scheitert, dass epoptes beim Systemstart geladen wird?
Zur Not: Kann ich automatisiert ein service epoptes (re)start beim Login/Systemstart auslösen? Wie mache ich das?
Schick mal die letzten Zeilen von
/var/log/epoptes.log – da müsste ja was zu finden sein. Die Meldung “Datei oder Verzeichnis nicht gefunden ist ja schon mal ein Anhaltspunkt”?!
Welches Update war es bei dir?
(/var/log/apt/history …)
Ich hatte die gleichen Symptome und bei mir war die Ursache der
Kernelupdate - siehe dazu der folgender Auszug aus meiner Doku:
09.12.2016:
epoptes funktioniert mit diesem Image nicht mehr. Beim Booten kann der epoptes-Dienst nicht gestartet werden.
Ursache noch unbekannt. Nach kurzer Zeit kann man den Dienst dann als root starten (# etc/inint.d/epoptes start )
→ zurück zum Image von 15.11.2016
12.12.2016:
Zweiter Versuch mit funktionierender Installation als Basis - gleiches Problem
15.12.2016:
Problem sind die fehlenden Dateien /etc/init.d/epoptes und /etc/init.d/epoptes-client
Beim Update (des Kernels?) werden diese Dateien nicht gefunden und alle Links darauf entfernt
Dadurch wird der epoptes-Dienst nicht mehr gestartet
Lösung: * postsync-Script für Image-Rechner kopiert die Dateien an den richtigen Ort
* image-Vorbereitungs-Script löscht die Dateien wieder
Hallo Rainer,
deine Analyse passt auf mein Problem. Epoptes selbst wurde im entsprechenden Zeitraum nämlich nicht upgedated - anderes schon (vermutlich auch der Kernel - bin grade nur nicht in der Schule und sehe die history des clients nicht…).
Sehe ich das richtig? Das sieht mir nach einer strukturellen Falle aus, in die früher oder später jeder mal tappen wird… Dann sollte ein Hinweis darauf in die Installationsanleitung zu epoptes, oder?
Zwei Dinge verstehe ich übrigens noch nicht ganz:
warum mein sudo apt-get install --reinstall epoptes das Problem dann nicht behoben hat.
warum die client-Anwendung weiterhin funktioniert - sobald man epoptes manuell startet, sieht man die clients wieder und kann sie steuern.
Sei’s drum.
Ich probier’s auf jeden Fall demnächst mal so, wie beschrieben: Von funktionierendem Stand ausgehen, vor Kernel-update schauen, dass der linuxadmin die nötigen init.d-Dateien hat. etc.
Hi Michael,
hast du die Sache lösen können? Falls ja, so wie Rainer es bereits beschrieben hat oder hast du einen anderen Weg genommen/gefunden?
Habe bei uns dasselbe Problem und wollte mich die kommende Woche mal dran machen.
Viele Grüße,
David
Hej David,
habe letztens schon kurz daran gedacht, dass ich an den Thread noch einen Knopf dran machen sollte.
Also: Ja, Rainers Tipp war goldrichtig. Bei uns funktioniert epoptes nun wieder.
Vorgehen:
Wir sind zurück auf ein funktionierendes Image,
haben dann die Programmdateien von epoptes und epoptes-client in den postsync-Pfad des Imagemasters (Rechner von dem das Image erstellt wird) kopiert.
Das Image-Vorbereitungsskript haben wir um die folgenden Zeilen ergänzt
danke für die schnelle Antwort.
Paar Dinge raffe ich noch nicht so ganz. Bei mir, war bei dir vermutlich auch so, wird mit dem derzeitigen Image wie in der Anleitung beschrieben einiges bereits per postsync auf die Clients kopiert, u.a. auch die init.d-Dateien. Wenn ich das richtig verstehe funktioniert dieses Vorgehen nun nicht mehr, daher die Probleme und deine Lösung.
Dazu ein paar Fragen:
Ist das der /mnt Ordner des Clients?
Dort habt ihr alle Dateien reingelegt, die auch in der Anleitung erwähnt werden, bzw. die ihr unten über das Vorbereitungsskript löschen lasst…?
Damit meinst du das, in meinem Fall, /var/linbo/xenial916.rsync.postsync Skript?
Da liegt der Knackpunkt - es geht um den Client, auf dem Du das Image erstellst (Habe ich vorhin „Imagemaster“ getauft), nicht um einen Rechner im Computerraum.
Klar: per postsync schiebst Du auf alle Schülerrechner im Computerraum die epoptes-client-Anwendung nach und auf den Lehrerrechner die epoptes-server-Anwendung.
Wir machen unsere Images immer von einem Ersatz-Schüler-Rechner. Der hat also auch nur die epoptes-client-Anwendung. Wenn man auf dem Gerät dann ein Kernelupdate durchführt, findet Linux die server-Anwendung nicht und räumt auf…
Du musst also zwei Dinge sicherstellen,
dass der Imagemaster beide Anwendungen hat: epoptes und epotes-client, bevor Du ein Kernelupdate machst
dass die Dateien wieder vom Imagemaster runter sind, bevor Du das Image schreibst.
Wir benutzen ein Shellskript, das vor dem Image-Erstellen ein paar Dateien löscht (Cache-Dateien, Firefox-Profile apt-get autoremove etc.). Das liegt bei uns auf dem Client in /usr/local/sbin und wird vom Linuxadmin vor Imageerstellung ausgeführt.
Ja, hatte ich damals schon gelesen. Ist aber ein anderes Problem…
Die Dummyfiles hatte ich auf dem Lehrerrechner angelegt und das hat soweit auch funktioniert.
Bei mir hat ja mit allerhöchster Wahrscheinlichkeit ein Kernelupdate die Verknüpfungen zur epoptes-server-Anwendung gekappt.
Wundert mich, dass noch nicht mehr Leute in die Falle getappt sind. Eigentlich müsste das früher oder später doch jedem passieren…
Ich denke das könnte es sein. Ich habe vor den Updates das Postsync deaktiviert, dann das dist-upgrade laufen lassen, geimaged und das Postsync-Skript wieder rein gehauen. Die Dateien waren nach dem syncen aber nicht da.
Versuche das morgen oder die Tage mal und gebe Rückmeldung.
Eins wundert mich allerdings auch, ähnlich wie du es schon beschrieben hast:
Wenn ich epoptes reinstalliert habe, wurden die Dateien auch nicht mehr angelegt…
Naja, wenn es so gelingt wie du geschrieben hast, dann ist alles in Ordnung.
Vielen Dank und viele Grüße,
David
PS: Werde mir auch ein „Aufräumskript anlegen“, das macht für mich ab jetzt ebenfalls Sinn. Habe bisher vor Imageerstellung immer manuell aufgeräumt
danke für den Tipp. Habe meine Dateien ins lmlcc eingetragen. Sehr komfortabel
Die Epoptes Dateien sind nach dem Update auch alle da (dann über lmlcc gelöscht), konnte aber die Funktion noch gar nicht testen, da ich nun ein dickes anderes Problem habe, das ich bisher noch nie hatte.
Nachdem ich auf dem Imagemaster alles upgedatet und ausprobiert hatte, habe ich ein neues Image erstellt und wollte das auf die anderen Rechner verteilen. Bis dahin alles gut, allerdings bekomme ich beim Start alle anderen Clients (außer dem Imagemaster, da kann ich syncen, neustarten usw. läuft einwandfrei) eine Fehlermeldung und die Rechner starten nicht mehr.
Die Rechner gehen nach dem PXE Boot ins Linbo und starten neu um das Betriebssystem (Ubuntu) zu starten. Bis dahin alles wie gehabt.
Nun kommt der erste Unterschied zu “vor dem Update”. Die Rechner starten das Grub Menü
Habe bereits versucht: Clients nochmal neu partitionieren, formaieren, syncen usw…
Lande aber immer auf dem Blackscreen mit der Fehlermeldung. Hat irgendetwas mit der UUID zu tun.
Weiß jemand wie ich das beheben kann?
Wie gesagt, der Imagemaster läuft, alle anderen Rechner nicht.
wollte ja noch kurz Rückmeldung geben. Nach einigen weiteren Problemchen konnte ich heute das Image verteilen. Obiges Problem mit den UUID’s ließ sich mit Holgers Tipp schnell lösen.
Nachdem ich das dist-upgrade laufen ließ und der Kernel 4.4.0-96 installiert wurde konnte ich keinen shutdown und reboot mehr machen, da die Clients hängen blieben. Nach downgrade auf 4.4.0-66 läuft jetzt alles wieder.
Nach Michaels (sedding) Anleitung hat alles wunderbar mit Epoptes geklappt. Per Postsync alle Epoptes Dateien auf einen Imagemaster, dist-upgrade, Aufnahme der Dateien in lmlcc (super Tool, danke für den Tipp Holger) und alles bereinigen lassen, geimaged, verteilt. --> Epoptes läuft.