systemd: Ein einfaches Script ausführen beim Systemstart

[MrScoville]

Hallo,

ich habe ein paar Debian vRoots, die die dumme Eigenschaft haben, dass sie die /etc/resolv.conf beim Start überschreiben. Ich habe den Support angeschrieben, und man sagte mir, dass ließe sich nicht ändern, ich könne ja aber ein Script ausführen, das die Datei wieder so hinbastelt, wie ich es gerne hätte. In den alten Zeiten hätte ich ein Script in rc3.d geschrieben, und fertig.

Hat jemand Lust mir zu sagen, wie das mit systemd geht, ohne dass ich gleich einen Daemon dafür schreiben muss?

... manche von euch kennen das ja schon von mir: Es ist bestimmt wahnsinnig spannend, sich in all die tollen Fähigkeiten von systemd, systemctl, dbus und Co einzubasteln, aber ich will kein perfekter Linux-Admin werden, sondern nur meine verteilte Haussteuerung in Gang bringen. Bei sicherheitsrelevanten und performancerelevanten Themen bin ich sofort ganz Ohr, aber ich möchte einfach nicht wie mein alter Latein-Lehrer enden, der bei jeder zweiten neuen Vokabel ins rythmische Hopsen verfiel, um uns die Lautwandlungen vom Ursprung an vorzutanzen, während wir Schüler einfach nur ein "Ausreichend" wollten

LG
Carsten

[DeletedUserReAsG]

Von alleine überschreibt sich die resolv.conf nicht → gucken, woher das kommt und deaktivieren/deinstallieren/umkonfigurieren. Wenn’s wirklich Rumdoktorn an den Symptomen werden soll: Script schreiben und über entsprechendes *.service-File starten. Doku in der Manpage. Dabei damit rechnen, dass es später wieder vom dhcpcd o.ä. überschrieben wird.

OT: ich hoffe, das war nun nicht zu herablassend. Zugegebenermaßen fällt’s mir bei „ich hab’n paar vServer, aber keine Ahnung davon und auch keinen Bock, mich mal einzulesen – ich bin sogar zu faul mitzuteilen, was für’n System ich da überhaupt fahre, stattdessen erzähle ich lieber Anekdoten aus der Jugend“ ziemlich schwer ….

[rendegast]

Du kannst Dich an ein Beispiel halten
/lib/systemd/system/rc-local.service
/lib/systemd/system/rc-local.service.d/

Das dann als
/etc/systemd/system/meins.service
/etc/systemd/system/meins.service.d/

[MSfree]

ich habe ein paar Debian vRoots, die die dumme Eigenschaft haben, dass sie die /etc/resolv.conf beim Start überschreiben.

Das mit einem Skript zu lösen, ist schlicht der falsche Ansatz.

/etc/resolv.conf wird z.B. die den dhcp-Client jedesmal frisch angelegt, wenn der Lease für die IP-Adresse erneuert wird, also beim Systemstart und danach alle paar Stunden. Den dhcp-Client kann man durch die Datei /etc/dhcp/dhclient.conf anpassen und verhindern, daß die Datei überschrieben wird. Auch das Paket resolvconf kann dafür verantwortlich sein.

[MrScoville]

Ich stimme allem zu, was ihr geschrieben habt und danke für die Vorschläge.

Ein paar Anmerkungen dazu: Viel wollte der Support nicht herausrücken, wie genau die ganze Maschinerie funktioniert. Mir scheint beinahe, die haben das mit einem Patch an irgendeine Stelle eingeschmuggelt, die man nicht finden soll. Ein dhcpd läuft jedenfalls nicht auf den Systemen, das war auch mein erster Verdacht. Mir wäre es auch viel lieber, ich könnte die Ursache finden und abschalten, statt mit Heftpflaster, Holzleim und Brecheisen durchs System zu marschieren.

Insofern eine Anschlussfrage: Gibt es eine Art "File System Watch Daemon", den man bereits während des Systemstarts darauf ansetzen kann zu protokollieren, welche Prozesse eine bestimmte Datei verändern?

Die Argumentation der Hotline ging übrigens in etwa so: "Wir müssen dafür sorgen, dass die Server auch bei einer eventuellen Fehlkonfiguration für die Kunden erreichbar sind." Ist eigentlich Nonsense, weil Datensicherung im Preis inklusive ist und man die Server über ein Webinterface resetten kann, aber mei, wenns denn so ist... Bisher ist diese Geschichte hier das erste Problem mit dem Hoster, das nicht ich verursacht habe. Anfangs habe gerne auch mal den falschen Knopf gedrückt, und der Support war jedes Mal super schnell und hilfreich. Insofern kann ich mich nicht beschweren, im Gegenteil habe ich eigentlich nur Lob für die Leute übrig -- bis eben auf diese Kleinigkeit, die es eklig macht, seine eigenen Nameserver für die eigenen Domains aufzusetzen.

Was übrigens passiert, das hätte ich wohl gleich von Anfang an mal in meine Frage schreiben sollen, ist, dass die /etc/resolv.conf so geändert wird, dass die bekannten Google-Nameserver eingetragen werden, also 8.8.8.8 und Konsorten. Vielleicht gibt es da irgendeinen Deal mit Google -- i.d.k.

[MrScoville]

Du kannst Dich an ein Beispiel halten
/lib/systemd/system/rc-local.service
/lib/systemd/system/rc-local.service.d/

Das dann als
/etc/systemd/system/meins.service
/etc/systemd/system/meins.service.d/

Auch wenn mir eigentlich klar ist, dass ich das gar nicht so recht will, ists eine perfekte Antwort auf meine ursprüngliche Frage. Dankesehr!

[MrScoville]

Gibt es eine Art "File System Watch Daemon"

Neu formuliert... Gibt's "inotify" auch von Ratiopharm? Also simpel, günstig und gut verträglich für Amateure? Natürlich nehme ich gerne eine "canonical" Lösung aus den Tiefen von apt-get!

[cosmac]

Gibt's "inotify" auch von Ratiopharm?

Da gibt's gleich zwei: inotifywait aus dem Paket inotify-tools und fatrace aus dem Paket fatrace. Leider sind beide nicht ideal, inotify kann einzelne Files beobachten, gibt aber den "Angreifer" nicht aus und fatrace beobachtet immer eine komplette Partition, gibt aber Name und PID aus. Evt. muss man die Ausgabe mittels ein paar --ignore-pid= etwas reduzieren.

Code: Alles auswählen

inotifywait --monitor /etc/resolv.conf

Code: Alles auswählen

cd /etc
fatrace --timestamp --current-mount --filter=W --ignore-pid $(pidof Xorg) | grep resolv

Code: Alles auswählen

cd /etc
fatrace --timestamp --current-mount --filter=W --output=/tmp/foo
grep resolv /tmp/foo