Hi, früher (tm, ich weiß ...), gab es doch mal das Werkzeug SuSEConfig. Das baute die Änderungen aus dem YaST in die Konfig.-Dateien ein. Was ist denn nun der Nachfolger? Bzw. Wie ist der Ablauf wenn ich eine Konfiguration im YaST ändere? (Keine Bange ist alle si.O. Ich will nur verstehen wie das abläuft. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Hallo Bernd, hallo zusammen, Am Montag, 20. Dezember 2021, 11:06:48 CET schrieb Bernd Nachtigall:
Auf die Gefahr, wie ein Anwalt zu klingen: Es kommt drauf an ;-) Für Postfix gibt es config.postfix (mehr oder weniger ein umbenanntes SuSEConfig.postfix [1]), für viele andere Programme wurden die SuSEConfig-Scripte ausgemustert oder durch andere Mechanismen (z. B. direktes Bearbeiten der "echten" Config-Datei statt Umweg über /etc/sysconfig/*) ersetzt. Einige sysconfig-Dateien werden auch in Systemd-Units eingebunden.
Bzw. Wie ist der Ablauf wenn ich eine Konfiguration im YaST ändere? (Keine Bange ist alle si.O. Ich will nur verstehen wie das abläuft.
Auch wenn wir die Frage auf /etc/sysconfig/* beschränken, gilt: Es kommt drauf an ;-) Bei manchen Optionen in /etc/sysconfig/* gibt es spezielle Kommentare, die Aktionen auslösen, z. B. ## ServiceRestart: xyz - nach Änderungen Service xyz neu starten ## ServiceReload: xyz - ähnlich, aber reload statt restart ## Command: /bin/foo - nach Änderungen /bin/foo aufrufen Allerdings haben die meisten Dateien in /etc/sysconfig/ keine solchen Kommentare. In diesen Fällen wird auch nichts neu gestartet. Viele Dateien in /etc/sysconfig/ werden in Systemd-Units eingebunden: EnvironmentFile=-/etc/sysconfig/unbound Änderungen werden dann natürlich erst beim nächsten Neustart des jeweiligen Service wirksam. Eine Einbindung in Scripten kann natürlich auch sein - früher[tm] wurde das gern bei den Initscripten genutzt, heutzutage können das auch via Systemd-Units aufgerufene Startscripte sein. Diese Liste ist vermutlich unvollständig ;-) dürfte aber die wichtigsten Varianten abdecken. Gruß Christian Boltz [1] zumindest als ich vor Jahren mal reingeguckt habe - keine Ahnung, ob/was sich inzwischen geändert hat ;-) --
Hallo Bernd, hallo zusammen, Am Sonntag, 2. Januar 2022, 15:01:48 CET schrieb Bernd Nachtigall:
Ich würde behaupten, dass es bei den sysconfig-Dateien nie wirklich eine Einheitlichkeit gab ;-) Die Auflistung, wie die sysconfig-Dateien eingebunden wurden, wäre vor Jahren vielleicht etwas anders ausgefallen als heute (z. B. Einbindung in Initscripte statt Systemd-Units), aber kürzer wäre sie wohl nicht. Wirklich schlimm finde ich das übrigens nicht - solange die Syntax einheitlich ist, ist mir eher egal, wie genau die sysconfig-Dateien eingebunden werden ;-) Und dass YaST heutzutage eher mal die "richtigen" Config-Dateien direkt ändert statt den Umweg über SuSEConfig zu gehen, ist IMHO eher eine Verbesserung. Gruß Christian Boltz -- Yes we do CI/CD. Contineous irritation and disappointment. [http://nitter.actionsack.com/ProgrammerDude/status/1426139313784381441]
Hallo Bernd, hallo zusammen, Am Montag, 20. Dezember 2021, 11:06:48 CET schrieb Bernd Nachtigall:
Auf die Gefahr, wie ein Anwalt zu klingen: Es kommt drauf an ;-) Für Postfix gibt es config.postfix (mehr oder weniger ein umbenanntes SuSEConfig.postfix [1]), für viele andere Programme wurden die SuSEConfig-Scripte ausgemustert oder durch andere Mechanismen (z. B. direktes Bearbeiten der "echten" Config-Datei statt Umweg über /etc/sysconfig/*) ersetzt. Einige sysconfig-Dateien werden auch in Systemd-Units eingebunden.
Bzw. Wie ist der Ablauf wenn ich eine Konfiguration im YaST ändere? (Keine Bange ist alle si.O. Ich will nur verstehen wie das abläuft.
Auch wenn wir die Frage auf /etc/sysconfig/* beschränken, gilt: Es kommt drauf an ;-) Bei manchen Optionen in /etc/sysconfig/* gibt es spezielle Kommentare, die Aktionen auslösen, z. B. ## ServiceRestart: xyz - nach Änderungen Service xyz neu starten ## ServiceReload: xyz - ähnlich, aber reload statt restart ## Command: /bin/foo - nach Änderungen /bin/foo aufrufen Allerdings haben die meisten Dateien in /etc/sysconfig/ keine solchen Kommentare. In diesen Fällen wird auch nichts neu gestartet. Viele Dateien in /etc/sysconfig/ werden in Systemd-Units eingebunden: EnvironmentFile=-/etc/sysconfig/unbound Änderungen werden dann natürlich erst beim nächsten Neustart des jeweiligen Service wirksam. Eine Einbindung in Scripten kann natürlich auch sein - früher[tm] wurde das gern bei den Initscripten genutzt, heutzutage können das auch via Systemd-Units aufgerufene Startscripte sein. Diese Liste ist vermutlich unvollständig ;-) dürfte aber die wichtigsten Varianten abdecken. Gruß Christian Boltz [1] zumindest als ich vor Jahren mal reingeguckt habe - keine Ahnung, ob/was sich inzwischen geändert hat ;-) --
Hallo Bernd, hallo zusammen, Am Sonntag, 2. Januar 2022, 15:01:48 CET schrieb Bernd Nachtigall:
Ich würde behaupten, dass es bei den sysconfig-Dateien nie wirklich eine Einheitlichkeit gab ;-) Die Auflistung, wie die sysconfig-Dateien eingebunden wurden, wäre vor Jahren vielleicht etwas anders ausgefallen als heute (z. B. Einbindung in Initscripte statt Systemd-Units), aber kürzer wäre sie wohl nicht. Wirklich schlimm finde ich das übrigens nicht - solange die Syntax einheitlich ist, ist mir eher egal, wie genau die sysconfig-Dateien eingebunden werden ;-) Und dass YaST heutzutage eher mal die "richtigen" Config-Dateien direkt ändert statt den Umweg über SuSEConfig zu gehen, ist IMHO eher eine Verbesserung. Gruß Christian Boltz -- Yes we do CI/CD. Contineous irritation and disappointment. [http://nitter.actionsack.com/ProgrammerDude/status/1426139313784381441]
participants (2)
-
Bernd Nachtigall -
Christian Boltz