0 Mitglieder und 1 Gast betrachten dieses Thema.
tmux has-session -t kbdemuif [ $? != 0 ]; then tmux new-session -s kbdemu -n os -d tmux split-window -h -t kbdemu tmux split-window -v -t kbdemu:os.0 tmux split-window -v -t kbdemu:os.1 tmux split-window -v -t kbdemu:os.3
tmux
Bei mir passiert da irgendwie garnix.
tmux attach
TW, wenn Du Script-Code postest, dann solltest Du keinen fehlerhaften resp. unvollständigen Abschnitt posten, sondern vom Shebang angefangen bis zur letzten Zeile alles. Der hier gezeigte Code ist definitiv fehlerhaft, weil die if-Condition nicht geschlossen wurde. Wie soll man denn bei solchen Voraussetzungen bei der Fehlersuche helfen, damit es nicht nur rätselraterei sein wird?
dann verschiebt sich tmux in den Vordergrund und Du siehst, dass alles korrekt eingerichtet wurde.
So ganz check ich den Code aber immer noch nicht. Gibt es irgendwo eine Aufschlüsselung, was diese ganzen Optionen bedeuten?
man tmux
Aber was bedeutet -s -n
und was bedeutet der Doppelpunkt hinter der target session kbdemu:os.0
Dort werden anschließenden noch Befehle an die einzelnen panes gesendet.
Diese erfordern jedoch root Rechte, sodass diese bei der Passworteingabe stecken bleiben. Gibt es eine Möglichkeit die panes beim erstellen mit root-Rechten auszustatten, sodass das Skript einmal durchlaufen kann? Bzw. das Skript in einem Terminal mit root-Rechten zu starten?
Steht auch bei 'man tmux'
Komm bloß nicht auf die bekloppte Idee, die Script-Befehle dann mit diesem sudo-Schwachsinn auszustatten.... das ist ein NoGo. Wenn das Script root-Rechte benötigt, dann solltest Du es so starten, dass es selber unter UID 0 (root) läuft. Der schlechte Weg ist es, das Script unter Normal-User-Rechten zu speichern, es dann aber mit 'sudo' zu starten. Das funktioniert, aber es bedeutet faktisch die Deaktivierung jeglicher Betriebssystem-Sicherheit. Korrekt wäre es, das Script direkt durch root zu starten, nicht mit 'sudo', sondern entweder nach einem Kontextwechsel mit "su -" oder -wenns beim Systemstart passieren soll- mithilfe einer Service-Unit.
Wenn ich mich im Terminal mit su anmelde …
user@debbie-x1:~$ su Passwort: su: Fehler bei Authentifizierung
Wenn ich mich im Terminal mit su anmelde und dann das Skript mit ./skriptname.sh ausführe - wo ist da der Unterschied? Die Berechtigungen sind doch dann dieselben, oder? Was genau verhindert diese Variante?
Default-sudo-Konfiguration
user@deb11-X1:~$ sudo -k apt clean[sudo] Passwort für user: user@deb11-X1:~$ sudo apt update[sudo] Passwort für user:
-k, --reset-timestamp Wenn diese Option ohne Befehl verwendet wird, werden die zwischengespeicherten Anmeldeinformationen des Benutzers ungültig. Mit anderen Worten, wenn sudo das nächste Mal ausgeführt wird, ist ein Kennwort erforderlich. Diese Option erfordert kein Kennwort und wurde hinzugefügt, um es einem Benutzer zu ermöglichen, sudo-Berechtigungen aus einer .logout-Datei zu entziehen.Wenn diese Option in Verbindung mit einem Befehl oder einer Option verwendet wird, die möglicherweise ein Kennwort erfordert, führt sie dazu, dass sudo die zwischengespeicherten Anmeldeinformationen des Benutzers ignoriert. Infolgedessen wird sudo nach einem Passwort fragen (falls ein solches in der Sicherheitsrichtlinie verlangt wird) und aktualisiert die zwischengespeicherten Anmeldeinformationen des Benutzers nicht."sudo -k" wirkt auch, wenn es ohne verbundenes Kommando eingegeben wird.
Technisch versteh ich das nicht ganz, warum das so ist, aber das ist wahrsch auch nicht in drei Sätzen erklärt, oder?
Du kannst natürlich auch sudo besser (?) konfigurieren, in dem Du den Timeout abschaltest...