Seit einiger Zeit hab ich Probleme mit “import_workstations”. Das Programm hängt bei “* Reloading external firewall …
…failed!”.
Auch das Freigeben des Internet in den Computerräumen geht nicht mehr. Die Ursache dürfte die selbe sein - ABER WELCHE???
Über ssh komme ich ohne Passwort vom Server auf den IPFire.
Ein Neustart des Server löst das Problem kurzzeitig (für ein paar Stunden). Das kann aber auch keine Lösung sein.
Meine Serverversion ist 6.2, IPFire 124 (aber auch schon bei 123 hatte ich das Problem)
In den logfiles auf dem IPFire hab ich diese Zeilen ausfindiggemacht, die alle 15 Minuten erscheinen:
Nov 20 07:34:51 ipfire sshd[18063]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Nov 20 07:34:51 ipfire sshd[18063]: Accepted publickey for root from 10.16.1.1 port 54763 ssh2: ECDSA SHA256:blablahierstandeincodeblabla
Nov 20 07:34:51 ipfire sshd[18063]: Received disconnect from 10.16.1.1 port 54763:11: disconnected by user
Nov 20 07:34:51 ipfire sshd[18063]: Disconnected from user root 10.16.1.1 port 54763
Die erste Zeile find ich seltsam, aber dann schein ja die Anmeldung doch zu klappen - komisch?!?
und Plattenbelegung ist auch kein Problem (/var bei 19% auf dem Server und 60% auf ipfire)
Das war auch meine erste Vermutung.
Die Meldung im ipfire-logfile (userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]) hängt wohl mit einer veralteten Schlüsselversion zusammen. Soll ich mal auf dem Server einen neuen erzeugen? Aber DAS geht ja!?!
Zwischenzeitlich hatte ich heute dann noch ein weiteres Problem mit import_workstations, nachdem ich einen neuen Rechner in einen neuen Raum gestellt habe ging “Setting up acls for room groups on /home/share …” nicht mehr. Vielleicht gibt’s einen Zusammenhang?
Alles ziemlich mysteriös…
Ich hab ähnliche Fehlermeldungen bei meinem problemlos funktionierenden IPfire, ich denke diese Meldung hat im praktischen Alltag nichts zu bedeuten liebe Grüße Christoph
Ich lese das so, dass Du den linuxmuster-Server UND IPFire neu startest? Ja, probier mal nur den IPFire neu zu starten. Wenn das hilft: ich würde ihn neu aufsetzen (vorher Backup machen, damit Du es einspielen kannst und zusätzlich noch alle Firewallregeln notieren, falls es nach dem Re-Backup immer noch nicht geht, falls der Fehler im Backup „gespeichert“ ist).
Hab gerade die Datei /tmp/.linuxmuster.lock gefunden, die zeitlich im Zusammenhang mit cron.daily erzeugt wurde. Die scheint Teil des Problems zu sein. Nach dem Neustart der LMN ist die natürlich weg und blockiert das “Reloading external firewall …” nicht mehr.
Bleibt die Frage, wo die Lock-Datei herkommt, d.h. was da “cron.daily” schief läuft.
Ich such weiter…
Demnach wird die Lock-Datei von internet-on-off, intranet-on-off, urlfilter-on-off, import_printers, ggf.- auch über die Schulkonsole angelegt. Offenbar wird sie aber nicht mehr gelöscht.
Ich würde einmal die Befehle nacheinander ausführen und sehen, wann die Lock-Datei übrig bleibt. Bei der Ausführung von der Konsole könnte ich mir vorstellen, dass wer das Fenster schließt, nachdem der Befehl abgesetzt wurde. Das würde erklären warum die Lock-Datei erhalten bleibt.
Gelöst!
Die Datei /etc/cron.daily/linuxmuster-schulkonsole brach mit Fehler ab und hat seine Lock-Datei stehenlassen.
Der Fehler war, dass das Projekt “p_wifi” nicht mehr existierte.
Hab’s neu angelegt und jetzt läuft wieder alles.
wer hat denn das Projekt gelöscht? Das Projekt ist nötig, wenn man das WLAN via Schulkonsole freischalten will. Die freigeschalteten User landen in der Gruppe p_wifi und dürfen damit das WLAN nutzen.
Hallo Markus
vielleicht wäre das etwas , was man an die Entwickler melden sollte, damit sie verhindern, dass solch merkwürdige Fehler weiterhin passieren können. Denkbar wäre z.b., dass man ein grundsätzlich notwendiges Projekt keinesfalls löschen dürfen sollte, jedenfalls nicht, ohne dass man auch den dazugehörigen Logfile-Mechanismus entschärft.
Liebe Grüße Christoph