Ein Script für notify-send das den Benutzer darüber informiert, das ich per Fernwartung drauf zugreife habe ich schon. Einige Leute ignorieren die Meldung leider, aber einfach die Usersitzung killen will ich auch nicht.

  • Bearbeitet

Noch eine Idee, jedoch noch recht unfertig.
Plasma spricht über dbus mit systemd. Dafür sind spezielle services definiert z.B. gibt es den /usr/share/dbus-1/services/org.kde.Shutdown.Service und den /usr/share/dbus-1/services/org.freedesktop.systemd1.service.
Wenn es dir gelingt für die Dauer deiner ssh Sitzung diese services stillzulegen dann kann dein User über die GUI das System auch nicht mehr herrunterfahren.
Wahrscheinlich werden Änderungen aber erst wirksam wenn du dann auch dbus neu startest.

5 Tage später

Gerade mal mit LXDM und LightDM ausprobiert, genau das selbe wie bei SDDM. Bei aktiven systemd-inhibit auf tty4, kann der Benutzer zwar nicht direkt aus der Sitzung eine Neustart usw machen, er landet in der Loginmaske, aber daraus ist eine Neustart ohne Probleme möglich.
Bin wieder bei "ich verstehe es nicht"
Funktioniert das Tool denn bei euch? Muss dafür noch irgendwas konfiguriert werden oder sollte es per default-config funktionieren?

@tuxnix
P.S. Danke für die Idee, aber irgendwie möchte ich doch systemd-inhibit zum laufen bringen, nagt an mir.

  • GerBra hat auf diesen Beitrag geantwortet.
    • Bearbeitet

    Andy@Arch Bin wieder bei "ich verstehe es nicht"
    Funktioniert das Tool denn bei euch? Muss dafür noch irgendwas konfiguriert werden oder sollte es per default-config funktionieren?

    Bei meinem kurzen Test ist es ähnlich wie bei dir.
    Es ist - wie so vieles in Poetterings Universum - ggf. technisch gut gedacht, aber nicht konsequent.

    Zuviele (D)Busse+PAMs+KITs machen IMHO alles undurchsichtig und kompliziert.

    Mein Vorschlag: Versuche nicht soziale Probleme (Reboot trotzt angekündigter Wartung) mittels unzulänglicher Werkzeuge zu lösen. Wenn den Betreffenden das Problem nicht klar ist, dann stelle die Wartung ein oder hinterlasse mal (testweise) ein nichtbenutzbares System ("Das habt ihr nun von eurem Reboot/Ausschalten").

    Ansonsten bliebe @tuxnix Vorschlag, die user-session zu locken/pausieren, daß hilft aber nicht gegen erzwungenen Poweroff/Reboot.

    Beim Test kam ich dann weiter:
    Wenn root den dbus.service stoppt. Dann ist bei mir kein (Software)-Reboot mittels DisplayManager/Windowmanager-Reboot-Option mehr möglich. Das Arbeiten für den User ist dann ggf. nur rudimentär möglich (der user-dbus ist ja auch funktionsuntüchtig). Es ist dann auch ein Aus/Wiedereinloggen des Users nötig nach einem Neustart des system-dbus.
    Alles suboptimal...

    //Edit:
    Ich hatte (alles zusätzlich zu systemd-inhibit) auch nochmal den Ansatz versucht, diverse shutdown/reboot Services+Targets während der "Wartung" zu maskieren, um Reboot-Versuche zu unterbinden. Bin aber auch nicht wesentlich weiter gekommen (auch aus Mangel an Interesse).
    Es müßte (und das müßte dann wohl im Kernel-Ring angesiedelt sein) etwas adäquates zu z.B: pam_nologin geben, also im wesentlichen: Existiert eine Datei z.B. /etc/noreboot dann funktioniert nur noch der physikalische Weg. Im Zuge dieses noreboot dürften dann logischerweise auch keine vorhergehenden Units (umount etc) versucht werden.

    Mein Ansatz wäre wohl:
    Ich erstelle für wichtige Dinge ein eigenes Wartungs.target und boote für die Wartung in dieses target/runlevel. Dort kann dann zum sshd ein X/Wayland oder wie auch immer gestartet sein mit deutlichem Hinweis(-Bild, feh z.B.) das Wartung läuft, nicht ausschalten usw.
    Kein User == Kein Problem <g>

    • Bearbeitet

    @GerBra hat völlig recht.
    Für zwischenmenschliche Missverständnisse gibt es keine Softwarelösung.
    Vielleicht hilft es wenn du langsam machst. Damit gibst du der anderen Seite die Gelegenheit etwas von dir zu wollen.

    Was hältst du von Debian?
    Damit entfällt das Problem des häufigen updates.

    Zwischenmenschliche Missverständnisse hin oder her, meiner Meinung nach ist das Ding (systemd inhibit) dafür gemacht einen unerwartete Reboot, Shutdown usw zu verhindern.
    Wollte da jetzt auch mal einen Bugreport schreiben, kann mich leider nicht mehr im Archbugtracker anmelden. Läuft so ein Account nach 5 Jahren Inaktivität ab?

    • Dirk und tuxnix haben auf diesen Beitrag geantwortet.

      Sind denn die Konto vom alten Bugtracker migriert worden?

      • Martin-MS hat auf diesen Beitrag geantwortet.

        Andy@Arch Sind denn die Konto vom alten Bugtracker migriert worden?

        Nein, du müsstest dich neu registrieren, was aber lt. Hinweis auf der Seite zur Zeit nicht möglich ist, bzw. nur per Mail an accountsupport@archlinux.org
        Ich bezweifele aber, dass der Arch-Bugtracker überhaupt der richtige Adressat ist, weil in deren Zuständigkeit nur Kompilierungs- oder Paketierungsfehler fallen, aber keine Programmfehler; die müsstest du Upstream direkt bei den Entwicklern melden. Wobei du erst einmal genau klären müsstest, in welcher der Systemkomponenten der Fehler tatsächlich auftritt.
        Um auszuschließen, dass es sich um ein Arch-Problem handelt, könntest du dasselbe mal mit einer anderen Distribution testen (kein Arch-Derivat). Wenn bei gleichem Versionsstand das Problem da auch auftritt, ist es mit ziemlicher Sicherheit ein Programmproblem, tritt es dort nicht auf, könnte man mit den Informationen das Problem an die Arch-Emtwickler melden.

        • Bearbeitet

        Andy@Arch ...meiner Meinung nach ist das Ding (systemd inhibit) dafür gemacht einen unerwartete Reboot, Shutdown usw zu verhindern. Wollte da jetzt auch mal einen Bugreport schreiben...

        Das folgende dürfte dazu interessant sein:
        https://www.man7.org/linux/man-pages/man5/logind.conf.5.html

        A different application may disable logind's handling of
        system power and sleep keys and the lid switch by taking a
        low-level inhibitor lock ("handle-power-key",
        "handle-suspend-key", "handle-hibernate-key",
        "handle-lid-switch", "handle-reboot-key"). This is most
        commonly used by graphical desktop environments to take over
        suspend and hibernation handling, and to use their own
        configuration mechanisms. If a low-level inhibitor lock is
        taken, logind will not take any action when that key or
        switch is triggered and the Handle*= settings are irrelevant.

        Auch interssant:

        https://www.freedesktop.org/wiki/Software/systemd/inhibit/
        https://man.archlinux.org/man/extra/man-pages-de/loginctl.1.de

        Ich hab mir erstmal die deutschsprachige Manpage rausgesucht siehe hier.

        Steuert, wie Logind die System-Einschalt-, Neustart- und -Schlaf-Tasten sowie den Deckelschalter behandeln soll, um Aktionen wie Ausschalten, Neustarten oder Suspendierung auszulösen. Kann eines von »ignore«, »poweroff«, »reboot«, »halt«, »kexec«, »suspend«, »hibernate«, »hybrid-sleep«, »suspend-then-hibernate«, »lock« und »factory-reset« sein. Falls »ignore«, wird systemd-logind diese Tasten niemals behandeln. Falls »lock« werden alle laufenden Sitzungen mit Bildschirmschonern gesperrt, andernfalls wird die festgelegte Aktion in dem jeweiligen Ereignis vorgenommen. Es werden nur Eingabegeräte mit der Udev-Markierung »power-switch« auf Tasten-/Deckel-Schaltereignisse überwacht.

        HandlePowerKey= ist standardmäßig »poweroff«, HandleRebootKey= ist standardmäßig »reboot«. HandleSuspendKey= ist standardmäßig »suspend«, HandleHibernateKey= ist standardmäßig »hibernate«, HandlePowerKeyLongPress= ist standardmäßig »ignore«, HandleRebootKeyLongPress= ist standardmäßig »poweroff«, HandleSuspendKeyLongPress= ist standardmäßig »hibernate«, HandleHibernateKeyLongPress= ist standardmäßig »ignore«. HandleLidSwitch= ist standardmäßig »suspend«. HandleLidSwitchExternalPower= wird standardmäßig komplett ignoriert (für Rückwartskompatibilität) — es muss ein expliziter Wert gesetzt werden, bevor er für die Verhaltensbestimmung verwandt wird. HandleLidSwitchDocked= ist standardmäßig »ignore«. Falls das System in eine Docking-Station eingeschoben wird oder falls mehr als ein Monitor angeschlossen wird, tritt die in HandleLidSwitchDocked= festgelegte Aktion ein. Falls das System von Extern Strom bekommt tritt die durch HandleLidSwitchExternalPower= festgelegte Aktion (falls vorhanden) ein, andernfalls tritt die Aktion HandleLidSwitch= ein.

        Eine andere Anwendung kann das Behandeln der Einschalt- und Schlaftasten sowie des Deckelschalters durch Logind deaktivieren, indem es eine systemnahe Unterdrückungssperre (»handle-power-key«, »handle-suspend-key«, »handle-hibernate-key«, »handle-lid-switch«, »handle-reboot-key«) erlangt. Dies wird am Häufigsten von graphischen Desktop-Umgebungen verwandt, um die Suspendierungs- und Ruhezustände-Handhabung zu übernehmen und ihren eigenen Konfigurationsmechanismus zu verwenden. Falls eine systemnahe Unterdrückungssperre erlangt wird, wird Logind keine Aktionen ergreifen, wenn die Taste oder der Schalter ausgelöst wird und die Einstellungen Handle*= sind irrelevant.

        Wenn ich das richtig verstehe behandelt das die Hardwaretasten und nicht die Softwaretaste in einem DE oder DM.
        Es bietet aber eine Erklärung für das beobachtete Verhalten. Auch wenn ich die Logik dahinter nicht verstehe, dachte bisher das Linux hierarchisch aufgebaut ist. Befehl von DE => Systemd => Linux Kernel und umgekehrt Output von Linux Kernel => Systemd => DE.
        Wenn jetzt das DE an Systemd vorbei das Kommando direkt an den Kernel weiterreicht, ist das irgendwie kontraproduktiv, denn das System wird doch mit Systemd administriert. Oder habe ich da einen Denkfehler?

        Wie dem auch sei praktisch bring mich das jetzt auch nicht weiter.

        • tuxnix hat auf diesen Beitrag geantwortet.

          Andy@Arch Es bietet aber eine Erklärung für das beobachtete Verhalten.

          Also vielleicht doch kein bug!

          Andy@Arch Wenn jetzt das DE an Systemd vorbei das Kommando direkt an den Kernel weiterreicht, ist das irgendwie kontraproduktiv, denn das System wird doch mit Systemd administriert. Oder habe ich da einen Denkfehler?

          Der user muss normaler weise auch sein System runterfahren können und das tut er für gewöhnlich über die DE.

          @tuxnix das soll er auch tun dürfen, aber in der hierarchisch Reihenfolge DE => Systemd => Linux Kernel. Und wenn ich als Bofh Systemd sage du darfst nicht runterfahren dann soll das auch nicht passieren.

          Ich weiß das der Linux Desktop eine Randerscheinung ist, und das Linux Server mit WinVMs verbreiteter sind, aber was machen denn Admins mit einigen Hundert oder mehr Linux Systemen? Updaten und Beten das keiner die Kiste ausmacht kann ja keine Lösung sein.

          Ich kenne jetzt deinen genauen Use case nicht. Ich hab Updates mal eine zeitlang damit erschlagen:
          https://github.com/ch3paz/update-on-boot/tree/master

          Ist Overkill und sicher nicht schön, funktioniert aber ganz leidlich. Nachteil: wenn man den reboot erzwingt kann es einem User die Session unterm Hintern wegziehen 🙂 Und manchmal muss man halt Dinge von Hand nachziehen.