Das stimmt so nicht.Revod hat geschrieben:Mit dem was Du schreibst bestätigst meine Vermutungen, worüber ich unsicher war.scientific hat geschrieben:...
Soweit so gut. Ich hoffe, ich konnte dir gute Anregungen zum Weiterforschen geben. Ich helf auch gerne mit Rat und Tat weiter.
Aber in einem anderen Thread.
lg scientific
Ok, den Vorteil habe ich durch Deine Beispiele verstanden und doch, Du musstest sehr viel Zeit investieren bis Du die Benutzer ... §HOME/ soweit mit einer einfache Ausführung einrichten konntest um auch alle Prozesse des ausgeloggten Benutzer zu beenden ( Ginge auch mit einen Neustart, ok, der etwas mehr Zeit braucht ).
Genau in dieses Sinn rede ich über meine, für mich Überforderung. Solche essentielle Grundfunktionen über einen Dienst den wenn man es schon einbaut auch mit bedenken und mit der Benutzbarkeit fertig entwickeln sollte. Und nicht nur unzählige Dienste, die einige dann entweder ins leere führen, oder nur halbwegs funktionieren, weil das Anfang bis zum Ende des Kreises nicht geschlossen ist ( Ich kann es nur auf diese Ableitung Art erklären ), und dann wie Du beschrieben hast noch das fehlende Teil selber programmieren musst, wir Benutzer es müssen.
Als "normaler" User müsste ich überhaupt nix programmieren.
Ich hab mich in systemd eingearbeitet, weil es mich interessierte, weil ich schon zuvor meinen fvwm ziemlich gepimpt habe und Spaß an der Freude habe, das Zeugs zu verstehen und zu verbessern.Wenn Software neu ist, fehlt natürlich noch dies und das, und das und das andere ist noch nicht entwickelt, weil der Bedarf noch nicht aufgetaucht ist. Systemd hat gerade für die "Übergangszeit" Generatoren mitgebracht, um die alten sysV-Init-Skripte, um die Mounts aus /etc/fstab usw. nahtlos übernehmen zu können, was auch im Großen und Ganzen gut funktioniert. Meine Erfahrung ist, dass mit systemd native Units oft schneller und einfacher sind, als ein sysv-Skript zu starten bzw. wie die programmiert sind. Was im Shellskript oft in vielen Zeilen abgefragt wird (z.B. den Stromversorgungsstatus) wird mit systemd in einer einzigen Zeile gelöst. (Hab mir auch einige init-Skripte angeschaut um daraus dann bisher noch fehlende native Units zu bauen, weil es sie vom Paketbetreuer noch nicht gibt). Das hab ich selber programmiert - war aber einfach eine Fleißaufgabe.
Nun, du hast gelernt, wie du GTK-Dialoge programmierst, fühlst dich aber von systemd überfordert... das erstaunt mich jetztUnd bei solche Fälle wie bei mir wird es schon " relativ " umständlich mit dem VPN und SSH, was ich nicht sooo gerne einrichten möchte, wegen meine Bedenken über eine weitere, mögliche Sicherheitslücke wegen eines zusätzliche Remote Anbindung Anwendung. Und jepp, es ist richtig, Systemd kam erst lange nach meinen beiden genannte Rechner als erste Version heraus. Gebe zu, im ersten Moment war es für mich schon sehr ärgerlich, als plötzlich Blackscreen eintrat, doch alles getestet kann man auch nicht, weil die Rechner nicht mehr im Handel sind und bin schon tollerant gegenüber. Nur wie schon gesagt, altes Belangloses für neue HW, die noch alte HW unterstützen würde nicht einfach aus dem Kernel und Systemd raus schneiden. Wenn man bedenkt, dass neue HW Generation Zyklus im Schnitt alle 3 Jahren ist wären es für bis zu 21 jährige Rechner durchaus machbar ( 21 : 7 mal mehr Implementationen für ältere HW, ich denke so wären bis zu 21 jährige Rechner abwärts kompatibel und natürlich mit der Berücksichtigung der bit Version 32 bit ).
Ich denke bevor Deine Hilfe greifen kann muss der Benutzer erst Mal sich selber mit Systemd beschäftigen und Schritt für Schritt erst ab dem Punkt wo man selbst wirklich nicht weiter kommt um Hilfe anfragen ( Mich überfordert es wegen meiner Zeit, keine englische Sprache, meine Schwäche Befehl Ausdrücke und dessen Sequenzen zu behalten daher auch meine Schwäche mit dem Terminal usw. Z. B. für wiederkehrende Befehle habe ich mir GTK-Dialog UI Scripte gebastelt, die funktionieren und die Knöpfe entsprechend betitelt und dort wo der Titel zu lange würde, nicht genügt unmittelbar unterhalb des Knopf eine kurze, klare Ausführung Beschreibung geschrieben ( Erst später habe ich gelernt wie das mit dem Tooltipp im GTK-Dialog funktioniert ). Syntax des GTK-Dialog Code habe ich mir abgeguckt und mit den Reiter sicher 2 Wochen lang geübt, bis ich die UI einheitlich hinbekommen habe ).
Pöttering behauptet ja oft, dass Software "falsch" programmiert wäre, und sie machen es richtig. Bei screen hab ich das verstanden, wie das gemeint ist.
Die Geschichte, dass Prozesse, die vom User gestartet werden, mit dem Logout auch zuverläsig wieder beendet werden ist durchaus ein Sicherheitsmerkmal. Blöd nur, dass screen aber genau das nicht soll. Es soll weiterlaufen, damit ich mich an anderer Stelle wieder einloggen kann - obwohl ich zwischendurch ausgeloggt war... Schließt sich also gegenseitig aus.
Im Zuge der Recherche habe ich dann gelernt, dass das mit den Userprozessen seit 40 Jahren tatsächlich falsch gemacht wird. Auf großen Servern ließ der Admin offenbar einmal die Woche ein Skript laufen, das alle Prozesse von Usern beendet, die eigentlich gar nicht eingeloggt sind.
Ein Beispiel ist der Zeitgeist Datahub, das hplip Systemtray und andere Prozesse, die per xdg-autostart gestartet werden, die aber beim Ausloggen nicht beendet werden und einfach weiterlaufen.
Seit kurzem ist bei systemd eine Default-Einstellung, dass Userprozesse beim letzten Ausloggen gekillt werden.
Die Einstellung findest du in der Datei /etc/systemd/logind.conf als "KillUserProcesses=yes"
Diese Einstellung hat aber zur Folge, dass auch screen oder tmux beim Logout gekillt wird und ein relogin in die bestehende Session nicht mehr möglich ist... Gab ein großes Bahö und Debian hat die Einstellung wieder auf "no" gestellt.
Dabei wäre es so einfach... eine Unit für den System-systemd, welche eine screen-Session für den User startet, die außerhalb des User-systemd läuft. Die wird nämlich von root verwaltet, läuft aber als der User und wird NICHT gekillt, wenn sich der User ausloggt.
Das sind aber Feinheiten, die erst beim "tun" an die Oberfläche kommen. Das fördert auch tradierte schlechte Gewohnheiten und unsystemisches Verhalten zu Tage und stößt natürlich jene vor den Kopf, die diese schlechten Gewohnheiten seit Jahrzehnten pflegen... Und damit durchaus auch eine Sicherheitslücke aufreißen.
Jetzt kann man natürlich auch diskutieren, ob screen so gestartet nicht auch eine Sicherheitslücke darstellt... aber das ist eine Lücke und nicht 10 Lücken wenn 10 Prozesse ohne mein Wissen nach dem Logout weiterlaufen. Ich war sehr erstaunt, was da noch alles weiterläuft, nachdem ich mich ausgeloggt habe...
Von der Registry sind wir aber weit entfernt... systemd stellt eine einfache, skriptingfähige Schnitstelle zur Verfügung. Ich kann systemd skipten, und ich kann Skripte in System verwenden... das geht in der Registry so nicht... Ich hab da immer wieder mit irgendwelchen cryptischen Einträgen zu tun die nicht dokumentiert sind, und eine Art Magie darstellen... Systemd ist gut dokumentiert (ja, Englisch sollte man derzeit dazu schon können) und bei Weitem nicht so kryptisch wie die Registry...Und so wie Du es beschreibst erinnert es mich, so fern es auch sein mag, an die " registry " des... und ich war so froh das Teil durch Linux los zu werden.... Kann mir vorstellen, man muss nochmal die " Schulbank " drücken....
Joa, soweit so gut Du hast Recht, es ist in der Tat ein ganz anderes Thema. Ich danke Dir sehr für Deinen Angebot.
lg scientific
