[gelöst] root Script vor Anmeldung ausführen

[joe2017]

Schönen guten Tag zusammen,

ich möchte gerne ein Script mit ROOT Rechten vor der Anmeldung ausführen. Ich habe bereits einen Service erstellt, welcher ein Script mit ROOT Rechten während des Starts ausgeführt. Dieses liegt in dem Verzeichnis /ect/systemd/system/. Ich befürchte jedoch, dass einige Dinge zu früh ausgeführt werden. Gibt es die Möglichkeit, ein Script auszuführen sobald das Netzwerk zur Verfügung steht und der Anmeldebildschirm angezeigt wird. Jedoch bevor ein Benutzer geladen wird. Ich glaube, dass ich hier in den Verzeichnissen /etc/rc0.d/ /etc/rc1.d/ /etc/rc2.d/ /etc/rc3.d/ /etc/rc4.d/ /etc/rc5.d/ /etc/rc6.d/ /etc/rcS.d/ richtig bin. Bin mir da aber nicht ganz sicher. Das Thema ist etwas komplex und ich bin relativ neu in der Linux Welt.

Oder ist doch /etc/rc.local der richtige Weg?

Ich wäre für einen kleinen Tipp dankbar.

[MSfree]

Ich habe bereits einen Service erstellt, welcher ein Script mit ROOT Rechten während des Starts ausgeführt. Dieses liegt in dem Verzeichnis /ect/systemd/system/.

Was liegt in /ect/systemd/system/?

In das Verzeichnis gehören nur die .service-Dateien, mit denen man beliebige Programme/Skripte starten lassen kann. Skripte haben dort nichts zu suchen.

Ich befürchte jedoch, dass einige Dinge zu früh ausgeführt werden. Gibt es die Möglichkeit, ein Script auszuführen sobald das Netzwerk zur Verfügung steht und der Anmeldebildschirm angezeigt wird.

Schau dir doch einfach mal den Inhalt von /ect/systemd/system/rc-local.service an:

Code: Alles auswählen

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
SysVStartPriority=99

Die Zeile After=network.target besagt doch, daß der Befehl, der in ExecStart gegeben ist, erst gestartet wird, nachdem das Netzwerk steht.

Auf die gleich Art kannst du auch deine eigenen .service-Dateie erstellen.

Jedoch bevor ein Benutzer geladen wird.

Das ist bei systemd immer der Fall, wie übrigens unter SysVInit auch. Schließlich sollen die Dienste auch dann zur Verfügung stehen, wenn gar keiner sich einlogt. Für benutzerabhängige Dinger gibt es andere Mechanismen, z.B. /etc/profile, ~/.profile usw.

Ich glaube, dass ich hier in den Verzeichnissen /etc/rc0.d/ /etc/rc1.d/ /etc/rc2.d/ /etc/rc3.d/ /etc/rc4.d/ /etc/rc5.d/ /etc/rc6.d/ /etc/rcS.d/ richtig bin.

Nein, da bist du komplett auf dem Holzweg. Systemd wurde vor ca. 5 Jahren eingeführt und seitdem dienen die von dir genannten Verzeichnisse nur noch dazu, Dienste zu starten, die noch nicht vollständig für Systemd fit gemacht wurden. Das sind sozusagen Altlasten, die mehr und mehr abgeschaft werden.

Oder ist doch /etc/rc.local der richtige Weg?

Mir rc.local macht man nicht viel falsch. Einerseits gab es rc.local auch schon unter SysVInit und es steht auch unter systemd zur Verfügung. Für Kleinigkeiten ist das der richtege Ort, wenn du aber "richtige" Dienste starten willst, solltest du dich in systemd und seine .service-Dateien einlesen und ggfls. eigene .service-Dateien erstellen.

[joe2017]

Natürlich liegt in dem Verzeichnis /etc/systemd/system/ nur meine Service Datei
MyServiceFile.service

Code: Alles auswählen

[unit]
Description=blablabla Service
[Service]
ExecStart=/pfad/to/Script/script.sh
[Install]
WantedBy=multi-user.target

Dann hab ich ja eigentlich schon alles richtig gemacht. Ich glaube ich habe auch gerade herausgefunden, weshalb das nicht funktioniert hat.
Ich hatte ein mount -a in meinem Script eingetragen. Jedoch habe ich in der FSTAB folgendes angepasst:

Code: Alles auswählen

server.domain:/folder1 /home/users		nfs4	sec=krb5i,rw,sync,users,_netdev,noauto,x-systemd.automount	0	0
server.domain:/folder2 /local-mount-folder/	nfs4	sec=krb5i,rw,sync,users,_netdev,noauto,x-systemd.automount	0	0

Ich befürchte, dass durch den Eintrag noauto,x-systemd.automount kein mounten mit mount -a möglich ist. Ist das korrekt?
Ich habe meinen Befehl (mount -a) im Script einfach ausgetauscht.

Code: Alles auswählen

mount server.domain:/folder1 /home/users -o sec=krb5i,rw,sync,users
mount server.domain:/folder2 /local-mount-folder/ -o sec=krb5i,rw,sync,users

Jetzt fragt Ihr euch sicherlich, weshalb ich in der FSTAB überhapt den Befehl noauto,x-systemd.automount eingetragen habe. Ich hatte immer Probleme, dass beim Booten die mountpoints nicht immer gemountet wurden. Mit diesem Eintrag hab ich es einfach umgangen. Jedoch werden nach der Installation während der ersten Anmeldung meine Mountpoints nicht geladen. Das wollte ich jetzt einfach mit diesem Script umgehen.

[MSfree]

Wenn es dir nur um das Mounten von NFS geht, hätte es gereicht, "noauto" in der fstab in "auto" zu ändern. Da hättest du gar keine .service-Datei gebraucht, denn alles, was in der fstab steht, wird vollautomatisch gemountet, es sei denn, es wird durch noauto verhindert.

[joe2017]

Da meine mounts aus der FSTAB eben zu 50% nicht gemountet wurden und während dem Starten eine Fehlermeldung angezeigt wurde, hab ich dies unterbunden.
Aber es scheint jetzt alles zu funtionieren.

[DeletedUserReAsG]

OT: wenn du die Leute nicht zusätzlich verwirren willst, schreibst du am besten nur tatsächliche Akronyme durchgängig groß. Root und fstab sind keine Akronyme. Wenn du es in Beiträgen hervorheben möchtest, könntest du stattdessen lieber z.B. [​b]text[/b] nehmen, was dann als text dargestellt wird.

No offense intended.