1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Linux-Userspace: Systemd bekommt…

systemd ist cool.

  1. Thema

Neues Thema Ansicht wechseln


  1. systemd ist cool.

    Autor: lyom 22.08.16 - 18:36

    Wollte das nur sagen.

    Ist openVPN beim Boot gestartet worden? (mit Consolen-Output und PID)
    systemctl status openvpn

    Welche Dienste gibt es, und wie sind die Stati?
    systemctl status

    Welche Dienste konnten nicht gestartet werden?
    systemctl --state=failed

    Welche Dienste laufen?
    systemctl --status=running

    openVPN starten:
    systemctl start openvpn

    Deaktiviere den Auto-Start von openVPN
    systemctl disable openvpn

    Logdateien von openVPN
    journalctl -u openvpn

    So sieht die Konfiguration eines Dämons aus (in diesem Fall Seafile, Skripte unter /lib/systemd/system):

    > [Unit]
    > Description=Seafile
    > Requires=mysql.service
    > After=mysql.service
    >
    > [Install]
    > WantedBy=multi-user.target
    >
    > [Service]
    > Type=forking
    > User=seafile
    > Group=seafile
    > PermissionsStartOnly=true
    > ExecStart=/usr/sbin/start_seafile
    > TimeoutSec=600
    > Restart=on-failure

    Und so sieht ein Skript aus, das nur beim Booten ausgeführt werden soll (wie rc.local):

    > [Unit]
    > Description=Work around a network interface BUG
    > Requires=network.target
    >
    > [Install]
    > WantedBy=multi-user.target
    >
    > [Service]
    > Type=oneshot
    > User=root
    > Group=root
    > ExecStart=/usr/sbin/reconfigure_network_interfaces
    > TimeoutSec=600
    > Restart=no
    > RemainAfterExit=no

    Abhängigkeiten werden alle von systemd aufgelöst. Und einfache Bedienung darüber hinaus.
    Deshalb: systemd ist cool.

  2. Re: systemd ist cool.

    Autor: Wallbreaker 22.08.16 - 19:02

    Würde auch sagen das es eine deutliche Verbesserung darstellt. Doch viele Leute haben nun mal Probleme mit Veränderungen, und können auf Teufel komm raus, nicht von alten Verfahrensweisen abweichen. Es ist ja grundsätzlich alles schlecht was neu ist, und sowieso aus Prinzip unbrauchbar. Und dann wird allen Ernstes noch darauf herumgeritten, dass hier Gegebenheiten missachtet werden, die in den späten 60er Jahren einmal definiert wurden. Zu einer Zeit in der das Internet noch nicht einmal in Gedanken existierte, noch Irgendwer eine Vorstellung davon hatte, was heutzutage erforderlich ist.

  3. Re: systemd ist cool.

    Autor: kosst.amojan 22.08.16 - 19:04

    lyom schrieb:
    --------------------------------------------------------------------------------
    > Wollte das nur sagen.
    > systemd ist cool.

    #Ironie : Hilfe ein Troll, ein Troll

    :D

  4. Re: systemd ist cool.

    Autor: thorben 22.08.16 - 19:23

    hier, ich mag es auch.
    nachdem ich die letzten ööööhm sagen wir mal 15 ajhre diverses an linux distris hatte via dualboot, webserver oder vm. nutze ich seit dem we auf meinem sehr leistungssschwachen uralt notebook arch als single boot (wennschon dennschon ;-)).
    wenn man mich fragen würde, dann ist das sehr intuitiv und gut zu handlen. mit init.d hab ich da schon mehr rumgekotzt als ich es die letzten tage hier auf dem laptop gemacht habe ;-)

  5. Re: systemd ist cool.

    Autor: hum4n0id3 22.08.16 - 19:46

    Ich wechsle zwischen Debian Server und OpenSuSE Workstation hin und her und dank systemd wird die Administration vereinheitlicht und vereinfacht.

    SystemD finde ich ebenfalls super!



    1 mal bearbeitet, zuletzt am 22.08.16 19:47 durch hum4n0id3.

  6. Re: systemd ist cool.

    Autor: ratti 22.08.16 - 19:47

    Unix/Linux hat(te) ein Problem: Es kommt historisch aus einer bestimmten Ecke.

    In dieser Ecke laufen Daemons auf einem 24-Stunde-eingeschaltet-Gerät. Nutzer dürfen sich anmelden, aber natürlich haben sie in dieser heiligen Umgebung weder am Netzwerk rumzudrehen, noch Festplatten anzuschliessen, noch überhaupt irgendwas mit Hardware.

    Diese Denke zog und zieht sich komplett durch die Entwicklungsgeschichte. Man sieht das an ganz simplen Dingen: Cron holt keine Jobs nach, wenn der Rechner aus war.

    Nun sieht ein Einsatzszenario heutzutage aber oft so aus: Der Nutzer klappt in der Firma den Laptop zu. Bumm. Und zieht den Monitor raus. Im Monitor war eine Bridge Thunderbold<>Ethernet.
    Zuhause klappt er die Kiste wieder auf. Der Rechner soll bitteschön automatisch ins WLAN, ausser der Nutzer stöpselt eine USB-Ethernet-Bridge ein. Der Rechner soll sich bitte das schnellste raussuchen. Dann startet der Anwender ein VPN, um wieder auf den FIrmenserver zu kommen, und ausserdem läuft eine VMWare-Maschine, in der irgendwas mit Windows virtualisiert ist — und von dieser VM wird erwartet, dass sie von zuklappen, einschlafen, Netzwerkwechsel WLAN, Netzwerkerweiterung VPN in keinster Weise beeindruckt ist. Und während des Abendessens soll die Kiste bitte einpennen und danach wieder aufwachen. Normaler Arbeitsalltag für mich.

    Und weil das noch nicht ausreicht, laufen manchmal sogar VMware, VIrtualbox, Docker für Virtualbox und Docker nativ für OSX parallel. Der Akku soll natürlich lange halten, zum Entwickeln läuft trotzdem ein Apache parallel.

    Das ist mit „Ein Tool für eine Aufgabe“ nicht zu bewältigen. Oder genauer gesagt: die Linux-Community hat viel zu spät begriffen, was genau die „eine Aufgabe“ heutzutage ist: Das komplette Setup des Environments, Hardware, Software, Netzwerk, Energieeinstellungen ist EINE große Aufgabe. Man kann 2016 nicht mehr EIN Programm für zeitgesteuerte Aufgaben verwenden und ein ANDERES für die Energieverwaltung — alles, was Environment ist, hängt zusammen.

    Als Apple anfing, auf Unix zu setzen, haben sie sukkzessive alles rausgeschmissen, was traditionell genutzt wurde. Von cron bis samba. Ich fand das Anfangs affig und ärgerlich, inzwischen muss ich sagen: Das war genial. Man kann von Apple halten, was man will, sie haben einen grossartigen Systemkern zusammengebaut — viele der Ideen kommen mit bei systemd bekannt vor. Die Ansprüche von heutigen Systemen und heutigen Usern sind mit dem alten Kram nicht implementierbar, die Software war nicht schlecht, sie war aber ganz anders konzipiert.

    Die Kritik an systemd kommt deswegen auch mehrheitlich von Leuten, die in Bereichen arbeiten, in denen man eher die „alten“ Konzepte braucht: EIn Fileserver wird nicht „zugeklappt“, ein Webserver soll nicht „einschlafen“, ein FTP-Server muss nicht möglichst rasend schnell booten, und niemand hat an einem Print-Server „mal eben“ eine mobile Festplatte anzustöpseln. In diesen Bereichen ist eine feste IP in /etc/networking eine gute Idee und keine Katastrophe.

    Ich kann nur sagen: Ich habe meinen privaten Webserver vor einem Jahr mit Jessie/systemd aufgesetzt und merke schlicht keinen Unterschied. Weil man schlicht und ergreifend in „der Ecke“ sowieso kaum rumschraubt. „service apache restart“, fertig, war früher so, ist heute so, „tiefer“ kommt man eh nie.

  7. Re: systemd ist cool.

    Autor: RipClaw 22.08.16 - 19:54

    Leider weichen viele nicht gerne von ihren Gewohnheiten ab. Ich war auch kritisch gegenüber systemd und finde an einigen Stellen das sie es vielleicht zu weit getrieben haben aber viele der Features die es mitbringt machen mir die Arbeit um einiges einfacher.

    Eines der Features die ich sehr an systemd mag ist das man die Konfiguration von einem Service File einfach überschreiben bzw. erweitern kann ohne die Ursprüngliche Datei anzufassen.

    Das geht sehr einfach indem man entweder ein Verzeichnis z.B. /etc/systemd/system/seafile.service.d/ anlegt und in diesem dann eine Datei z.B. security.conf mit einem Inhalt wie z.B.

    [Service]
    PrivateTmp=yes
    PrivateDevices=yes
    ProtectSystem=full

    anlegt und systemctl daemon-reload aufruft und dann den Dienst neu startet.
    Leider machen das viele falsch und bearbeiten stattdessen die Datei unter /lib/systemd/system/seafile.service oder machen eine Kopie davon unter /etc/systemd/system und packen da nochmal alle mit rein.
    Stattdessen kann man auch in die /etc/systemd/system/seafile.service schreiben:

    .include /lib/systemd/system/seafile.service

    und dann eben so erweitert wie bei dem Beispiel vorhin.
    Der Vorteil ist das man nicht ständig gegen die Änderungen vom Distributor ankämpfen muss.

    Ein anderes Feature von systemd habe ich schon in dem Beispiel angeschnitten. Man kann sehr einfach sein System zusätzlich absichern. Das waren nur ein paar einfache Maßnahmen aber die können schon einiges bringen.

    "PrivateTmp=yes" erzeugt ein eigenes /tmp Verzeichnis für einen Dienst und bindet es via Namespace ein
    "PrivateDevices=yes" macht das gleiche mit /dev und reduziert die Devices auf gerade mal das nötigste.
    "ProtectSystem=full" mountet in einem Namespace /usr, /boot und /etc ReadOnly so das hier vom Prozess nichts geschrieben werden kann selbst wenn er normalerweise die Rechte dazu hätte. Dazu kommen noch andere Möglichkeiten wie z.B. Capabilities und Systemaufrufe auf das nötigste zu beschränken.

    Klar kann man das auch AppArmor oder SELinux erreichen aber die sind wesentlich komplizierter als diese einfachen Konfigurationsoptionen.



    1 mal bearbeitet, zuletzt am 22.08.16 20:02 durch RipClaw.

  8. Re: systemd ist cool.

    Autor: RipClaw 22.08.16 - 20:01

    ratti schrieb:
    --------------------------------------------------------------------------------

    > Die Kritik an systemd kommt deswegen auch mehrheitlich von Leuten, die in
    > Bereichen arbeiten, in denen man eher die „alten“ Konzepte
    > braucht: EIn Fileserver wird nicht „zugeklappt“, ein Webserver
    > soll nicht „einschlafen“, ein FTP-Server muss nicht möglichst
    > rasend schnell booten, und niemand hat an einem Print-Server „mal
    > eben“ eine mobile Festplatte anzustöpseln. In diesen Bereichen ist
    > eine feste IP in /etc/networking eine gute Idee und keine Katastrophe.

    Da wäre ich mir an deiner Stelle nicht so sicher.

    Ich habe so einige Interviews mit Pöttering gelesen / gehört und die packen viel von Kram da nicht rein weil sie es selber so gut finden sondern eher weil sie Anfragen bekommen ob man nicht dies und das machen könnte.

    Man muss sich nur mal die Vorträge der systemd.conf ansehen. Da waren einige Bereiche mit dabei die überrascht haben wie z.B. Embedded Devices.

  9. Re: systemd ist cool.

    Autor: menno 22.08.16 - 20:41

    Hey, Danke für das Posting.
    Hätte nicht gedacht, dass ích heute Abend noch so viel lerne!
    Erstmal gebookmarkt für später.

  10. Re: systemd ist cool.

    Autor: Wallbreaker 22.08.16 - 20:58

    ratti schrieb:
    --------------------------------------------------------------------------------
    > Diese Denke zog und zieht sich komplett durch die Entwicklungsgeschichte.
    > Man sieht das an ganz simplen Dingen: Cron holt keine Jobs nach, wenn der
    > Rechner aus war.

    Eigentlich startet Cron standardmäßig beim Systemstart Anacron, was dann letztlich all das abarbeitet, was in der Zwischenzeit nicht gestartet werden konnte.

    > Das ist mit „Ein Tool für eine Aufgabe“ nicht zu bewältigen.

    Für viele Abläufe ist ein Programm was genau eine Sache richtig abbarbeitet, genau das Richtige und mindert Komplexität. Und Komplexität führt zu hohem Wartungsaufwand, und vielfach zu Sicherheitsproblemen. Daher muss man das klug angehen, was wirklich separiert und was besser zusammengeschlossen werden sollte.

    > Oder genauer gesagt: die Linux-Community hat viel zu spät begriffen, was
    > genau die „eine Aufgabe“ heutzutage ist: Das komplette Setup
    > des Environments, Hardware, Software, Netzwerk, Energieeinstellungen ist
    > EINE große Aufgabe. Man kann 2016 nicht mehr EIN Programm für
    > zeitgesteuerte Aufgaben verwenden und ein ANDERES für die Energieverwaltung
    > — alles, was Environment ist, hängt zusammen.

    Es geht hier nicht darum das die Community etwas nicht begriffen hätte, sondern all das ist letztlich ein Prozess. Und dieser wird dadurch bestimmt was zu gegebener Zeit benötigt wird. Entwicklungen wie Systemd oder Wayland kommen ja nicht ohne Grund, wenn man mit bestehenden Lösungen schlicht ein Limit erreicht hat, welches zu nichts mehr führt. Vergessen darf man auch nicht den Fokus von damals, zumal hier ganz andere Gegebenheiten vorlagen. Selbst Linux sollte ursprünglich gar kein Desktop-Betriebssystem sein. Ebenso der X-Server der für heutige Anwendungensformen nie angedacht war.

  11. Re: systemd ist cool.

    Autor: Ass Bestos 22.08.16 - 21:16

    thx, mehr solcher postings wie dieses.

  12. Re: systemd ist cool.

    Autor: yoyoyo 22.08.16 - 21:30

    systemd macht halt viele nicht triviale Dinge sichtbar, die man frueher faktisch hingehackt hat, gerade was race conditions angeht. Das ist dann auch mit systemd nicht ganz einfach, aber man kann es sauber loesen.

    Und Dinge wie die socket activation (vom Apfel kopiert) sind einfach besser als alles andere.

  13. Re: systemd ist cool.

    Autor: ratti 22.08.16 - 22:43

    Wallbreaker schrieb:
    --------------------------------------------------------------------------------
    > ratti schrieb:


    > > Das ist mit „Ein Tool für eine Aufgabe“ nicht zu bewältigen.
    >
    > Für viele Abläufe ist ein Programm was genau eine Sache richtig
    > abbarbeitet, genau das Richtige und mindert Komplexität. Und Komplexität
    > führt zu hohem Wartungsaufwand, und vielfach zu Sicherheitsproblemen. Daher
    > muss man das klug angehen, was wirklich separiert und was besser
    > zusammengeschlossen werden sollte.

    Ja, bin ich ganz deiner Meinung.

    Es ist nur so: Manchmal ist ein einfaches Tool die richtige Antwort auf eine einfache Anforderung.

    Und dann dreht sich die Welt weiter, und plötzlich ist die Anforderung nicht mehr einfach, sondern schwierig.

    Ich bin Webentwickler, und daraus ergibt sich teilweise eine recht skurrile Problematik. Ein Tool wie Apache ist plötzlich damit konfrontiert, dass der Laptop, auf dem es läuft, einschläft, und im Meeting-Raum mit anderer IP wieder aufwacht. Niemand hat den Apache je für einen Laptop konzipiert. Das ist ein Alptraum für einen Daemon, in dessen Configfile potentiell IP-Adressen hart verdrahtet sind — und auch dann muss erstmal „jemand“ dem Apache „Bescheid sagen“, dass sich gerade sein Environment geändert hat. Wir reden hier von einer Software, die eigentlich darauf ausgelegt ist, bitteschön Verbindungen keinesfalls zu kappen, weil dann ein Download im Ar…gen ist.

    Es gab in den letzten Jahren viele Antworten auf solche Anforderungen. Die meisten sahen so aus, dass irgendein Tool irgendein Ereignis überwacht und dann irgendwas neu startet, indem es eine neue Config generiert und dem zugehörigen Programm einen Arschtritt verpasst. Brachial.

    Die immerhin etwas besseren Lösungen abstrahieren die „neuerdings“ veränderlichen Bestandteile über zwischen-gezogene Meta-Ebenen. Das große, dumme Tool merkt dann nichts von der Veränderungen im Environment, weil es eh mit einem Proxy spricht, der sich „kümmert“. Das ist dann die Gerüstbauer-Lösung: Funktioniert, ist hässlich, darf der Architekt nicht sehen, sonst gehen wir alle in den Bau.

    Der letzte Stand der Anforderungen ist aber inzwischen ein einziger Alptraum: Linux läuft auf den meisten Smartphones, lustig trägt man LTE durch Tunnel und UMTS in Kellern, an wechselnden kostenlosen HotSpots vorbei durch Funklöcher ins heimische WLAN. Gleichzeitig ist plötzlich, was vorher noch nie der Fall war, Energie knapp— das Tool, das darauf reagiert, soll das Problem nicht nur lösen, es soll es auch energiesparend lösen. Und im schlimmsten Fall ist die Energie auch noch „alle“, und der ganze Krempel fährt ungebremst runter und geht aus.

    Das klassische init.d System hat darauf so reagiert: Wenn dies, dann mach das, das und das. Das ist auf einem Webserver im Maschinenraum großartig, weil es mit einem Minimum an Komplexität die Aufgabe löst.
    Einen REST-Service auf einem Handy stellt man sich aber anders vor. Etwa so, dass der Netzwerk-Stack dem Daemon „Bescheid sagt“, er möge die bestehende Verbindung zartfühlend auf einer neuen Ressource weiterführen.

    Neben allen anderen anderen technischen Fragen, die sich damit verbinden, heisst das zunächst mal: Man muss sich von Anfang konzeptionell davon lösen, irgendwas an Ressourcen hart zu verdrahten.

    Auf einem Handy kann man auf nichts verlassen: Nicht auf die IP, nicht auf vorhandenen „Platten“platz, nicht darauf, dass laufende Prozesse nicht einfach gekillt werden, nicht auf Stromversorgung und dass man seine offene Datei noch in Frieden schließen darf.

    Wir müssen dazu die Aufgabenstellungen anders bündeln als früher. Unter OS X heisst das, dass Energiesteuerung, Events, Ressourcenverwaltung, Netzwerk etc. sehr viel enger miteinander verwoben sind als unter Linux — teilweise ist ein Programm für mehrere Sachen zuständig, wo man traditionell sagen würde, die haben nichts miteinander zu tun. Aber wenn dein cron (oder der cron-Ersatz) mit dem Akku über den Tag kommen soll, dann musst Du den Akku im gleichen Programm verwalten, das auch die zeitgesteuerten Prozesse ausführt. Und cron kennt kein „mach das alle 10 Minuten, aber nur, wenn der Rechner wach ist. Falls nicht, hole nur einen einzigen der ausgefallen Prozesse nach, nicht alle. Aber nicht alle gleichzeitig beim Aufwachen. Oh, ich sehe gerade, wir brauchen also Prioritäten, Abhängigkeiten und Bedingungen“.

    Ich denke, systemd ist da auf dem richtigen Weg, auch wenn es nicht perfekt ist, die _Denke_ ist die richtige.

  14. Re: systemd ist cool.

    Autor: hum4n0id3 22.08.16 - 23:26

    Es ist zwar für (open)SuSE, aber der Nicht-Yast-Part gilt für andere auch.

    SystemD
    http://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.systemd.html

    JournalCtl
    http://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.journalctl.html

  15. Re: systemd ist cool.

    Autor: longthinker 23.08.16 - 09:25

    ratti schrieb:

    > Das ist mit „Ein Tool für eine Aufgabe“ nicht zu bewältigen.
    > Oder genauer gesagt: die Linux-Community hat viel zu spät begriffen

    Viel zu spät begriffen? Wann wäre denn der richtige Zeitpunkt gewesen? Wie macht man überhaupt den Zeitpunkt fest, an dem eine Community etwas begriffen hat?

    Ich finde solche Aussagen doch eher seltsam - eher eine diffuse Andeutung von "ich hab's ja schon immer gewusst". Systemd gibts jetzt schon eine Weile; vorher gabs Upstart - d.h. da läuft seit einer Weile ein Prozess, das Altbekannte abzulösen. Und zu diesem Prozess gehören auch die Nachteile und Gegenargumente - denn diese sind valide, auch wenn sie am Ende den Änderungsprozess nicht aufhalten können und sollen. Altbekanntes durch neues zu ersetzen kostet Zeit und Geld - und nicht immer steht dem direkt ein Vorteil gegenüber. Insofern sind bei einem solchen Prozess Widerstände genauso normal und wichtig wie Fehlversuche, Übers-Ziel-Hinausschießen etc. Wenn eine Community etwas neues "spät begreift", dann war wohl einfach der Bedarf (noch) nicht da, Schließlich ist es nicht Aufgabe einer solchen Community einen Bedarf zu generieren, um etwas zu verkaufen, wie das Apple, MS & Co tun.

  16. Re: systemd ist cool.

    Autor: Der braune Lurch 23.08.16 - 10:21

    Lies doch mal die Seiten über systemd in Arch Wiki. Da steht auch vieles.

    ------------------------------
    Der Molch macht's.
    ------------------------------

  17. Re: systemd ist cool.

    Autor: robos 23.08.16 - 10:56

    Für mich als Admin (auf div. Systemen) sind folgende Punkte - unabhängig davon, welches Tool es macht - wichtig:
    - im Fehlerfall gibt es eine Fehlermeldung
    - Tools sind nie so flexibel und intelligent wie ein Mensch - wenn so definiert müssen die die gesetzte Einstellung übernehmen und nicht meinen, der Automatismus geht über die Einstellung
    - eingängige Syntax
    - solide/abgehangen damit bei der Fehlersuche eines Problems nicht noch das Tool zum Starten/Stoppen auch noch diagnostiziert werden muss
    - Konfig-Files wo man die findet. Ich kenne von x Distros die config files - warum liegen nicht alle !anzupassenden! unter /etc/? Nicht anzupassende können meinetwegen sonstwo liegen - aber die von mir anzupassenden oder genereller - die die umgeschrieben werden von mir oder von einem Tool - unter /etc
    - gute Doku!!
    - da die Welt nicht von heute auf morgen plötzlich alle Einstellungen umschreibt gute legacy Tools oder Konvertierungstools

    Welches Tool das macht ist mir latte. Ob systemd cool ist interessiert mich nicht. Die Bedingungen oben müssen passen und was der OP geschrieben hat - openvpn starten ginge so - ist (meiner mehrfachen Erfahrung nach) falsch. Bau einen Fehler in die Konf ein und dann guckste mal ob eine Fehlermeldung beim Start kommt.

  18. Re: systemd ist cool.

    Autor: xUser 23.08.16 - 17:59

    robos schrieb:
    --------------------------------------------------------------------------------
    > Für mich als Admin (auf div. Systemen) sind folgende Punkte - unabhängig
    > davon, welches Tool es macht - wichtig:
    > - im Fehlerfall gibt es eine Fehlermeldung

    Check

    > - Tools sind nie so flexibel und intelligent wie ein Mensch - wenn so
    > definiert müssen die die gesetzte Einstellung übernehmen und nicht meinen,
    > der Automatismus geht über die Einstellung

    Check

    > - eingängige Syntax

    Check

    > - solide/abgehangen damit bei der Fehlersuche eines Problems nicht noch das
    > Tool zum Starten/Stoppen auch noch diagnostiziert werden muss

    Definiere abgehangen ... Ich hatte noch nie in Problem mit systemd oder einer der Tools aus der Toolsammlung.

    > - Konfig-Files wo man die findet. Ich kenne von x Distros die config files

    Check

    Alles nach FHS
    * Package Defaults für das System in /usr/lib/systemd/system
    * Package Defaults für alle User in /usr/lib/systemd/user/
    * Lokale Änderungen und Einstellungen für das System in /etc/systemd/system
    * Lokale Änderungen und Einstellungen für alle User in /etc/systemd/user
    * Package Defaults pro User in ~/.local/share/systemd/user/
    * Lokale Änderungen pro User in ~/.config/systemd/user/


    > - warum liegen nicht alle !anzupassenden! unter /etc/? Nicht anzupassende
    > können meinetwegen sonstwo liegen - aber die von mir anzupassenden oder
    > genereller - die die umgeschrieben werden von mir oder von einem Tool -
    > unter /etc

    Check (Vermutlich machst du es einfach nur falsch, weil du nicht verstanden hast, wie Units angepasst werden sollen.)

    > - gute Doku!!

    k.A. Es fehlt der offiziellen Doku definitiv an Beispielen. Dafür gibt es aber im Wiki von Arch und Gentoo, sowie von den anderen Distributionen schnelle Abhilfe.

    > - da die Welt nicht von heute auf morgen plötzlich alle Einstellungen
    > umschreibt gute legacy Tools oder Konvertierungstools

    Check (Die alten Wege werden so weit es geht noch unterstützt, d.h. voller Legacy Support.)

    > Welches Tool das macht ist mir latte. Ob systemd cool ist interessiert mich
    > nicht. Die Bedingungen oben müssen passen und was der OP geschrieben hat -
    > openvpn starten ginge so - ist (meiner mehrfachen Erfahrung nach) falsch.

    Was hat ggf. falsches Verhalten von openvpn mit systemd zu tun. Wenn es Fehler gibt (Meldungen oder Return > 1), dann teilt systemd dies mit. Mehr geht halt nicht. Information raten kann auch systemd nicht.

    > Bau einen Fehler in die Konf ein und dann guckste mal ob eine Fehlermeldung
    > beim Start kommt.

    Ja (getestet mit MariaDB und Apache) -> Unit failed to start
    $ systemctl status UNIT -> letzte Logzeilen


    Die Doku ist zum Teil noch etwas mau, ansonsten kann ich deine "Kritik" nicht nachvollziehen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. NÜRNBERGER Versicherung, Nürnberg
  2. Endress+Hauser Conducta GmbH+Co. KG, Gerlingen (bei Stuttgart)
  3. Bundesamt für Soziale Sicherung, Bonn
  4. über POLZIN GmbH Personalberatung, Backnang

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 24,29€
  2. 12,99€
  3. 16,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


MX Anywhere 3 im Test: Logitechs flache Maus bietet viel Komfort
MX Anywhere 3 im Test
Logitechs flache Maus bietet viel Komfort

Die MX Anywhere 3 gefällt uns etwas besser als Logitechs älteres Mausmodell, das gilt aber nicht für jeden Einsatzzweck.
Ein Test von Ingo Pakalski

  1. MK295 Logitech macht preisgünstige Tastatur-Maus-Kombo leiser
  2. G915 TKL im Test Logitechs perfekte Tastatur braucht keinen Nummernblock
  3. Logitech Mechanische Tastatur verzichtet auf Kabel und Nummernblock

Todesfall: Citrix-Sicherheitslücke ermöglichte Angriff auf Krankenhaus
Todesfall
Citrix-Sicherheitslücke ermöglichte Angriff auf Krankenhaus

Ein Ransomware-Angriff auf die Uniklinik Düsseldorf, der zu einem Todesfall führte, erfolgte über die "Shitrix" genannte Lücke in Citrix-Geräten

  1. Datenleck Citrix informiert Betroffene über einen Hack vor einem Jahr
  2. Shitrix Das Citrix-Desaster
  3. Perl-Injection Citrix-Geräte mit schwerer Sicherheitslücke und ohne Update

IT-Freelancer: Der kürzeste Pfad zum nächsten Projekt
IT-Freelancer
Der kürzeste Pfad zum nächsten Projekt

Die Nachfrage nach IT-Freelancern ist groß - die Konkurrenz aber auch. Der nächste Auftrag kommt meist aus dem eigenen Netzwerk oder von Vermittlern. Doch wie findet man den passenden Mix?
Ein Bericht von Manuel Heckel

  1. Selbstständiger Sysadmin "Jetzt fehlen nur noch die Aufträge"