systemd: Ein einfaches Script ausführen beim Systemstart

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
MrScoville
Beiträge: 93
Registriert: 09.09.2016 17:20:59
Lizenz eigener Beiträge: MIT Lizenz

systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von MrScoville » 07.11.2016 21:40:47

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
Man mag gar nicht glauben, wie sehr ein 4096-bittiger RSA-Schlüssel einem den Tag vermiesen kann...^^

Der so genannte "Teufel im Detail" hat einen Namen: Tight coupling :evil:

DeletedUserReAsG

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von DeletedUserReAsG » 07.11.2016 22:15:43

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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von rendegast » 08.11.2016 09:26:58

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/
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von MSfree » 08.11.2016 09:42:39

MrScoville hat geschrieben: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
Beiträge: 93
Registriert: 09.09.2016 17:20:59
Lizenz eigener Beiträge: MIT Lizenz

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von MrScoville » 10.11.2016 18:02:20

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.
Man mag gar nicht glauben, wie sehr ein 4096-bittiger RSA-Schlüssel einem den Tag vermiesen kann...^^

Der so genannte "Teufel im Detail" hat einen Namen: Tight coupling :evil:

MrScoville
Beiträge: 93
Registriert: 09.09.2016 17:20:59
Lizenz eigener Beiträge: MIT Lizenz

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von MrScoville » 10.11.2016 18:03:46

rendegast hat geschrieben: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!
Man mag gar nicht glauben, wie sehr ein 4096-bittiger RSA-Schlüssel einem den Tag vermiesen kann...^^

Der so genannte "Teufel im Detail" hat einen Namen: Tight coupling :evil:

MrScoville
Beiträge: 93
Registriert: 09.09.2016 17:20:59
Lizenz eigener Beiträge: MIT Lizenz

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von MrScoville » 10.11.2016 18:39:29

MrScoville hat geschrieben: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!
Man mag gar nicht glauben, wie sehr ein 4096-bittiger RSA-Schlüssel einem den Tag vermiesen kann...^^

Der so genannte "Teufel im Detail" hat einen Namen: Tight coupling :evil:

cosmac
Beiträge: 4573
Registriert: 28.03.2005 22:24:30

Re: systemd: Ein einfaches Script ausführen beim Systemstart

Beitrag von cosmac » 13.11.2016 23:20:55

MrScoville hat geschrieben:Gibt's "inotify" auch von Ratiopharm?
Da gibt's gleich zwei: inotifywait aus dem Paket Debianinotify-tools und fatrace aus dem Paket Debianfatrace. 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
Beware of programmers who carry screwdrivers.

Antworten