ubuntuusers.de

Ich habe eventuell ein Problem damit, dass ich Aktionen per Cronjob durchführe und diese dann später in einer SSH nicht sehe oder vice versa. Der Grund hierfür könnte zumindest sein, dass meine Cronjobs "einfach so" laufen, also ohne das passende Environment.

Meine Suche nach der Antwort auf "linux cronjob environment" bringt zwar einige Ergebnisse, aber ich verstehe die Erklärungen nicht im Detail und frage deshalb hier konkret:

1. Wie kann ich für meine Cronjobs dafür sorgen, dass die einzelnen Befehle ein bestimmtes Environment haben, nämlich das meines Users localadmin?

2. Geschieht dies sinnvoll in der Crontab oder in jedem einzelnen Skript?

3. Die Beispiele, die ich fand, erwähnten immer eine Datei $HOME/.profile. Ich habe aber in keinem meiner Home-Verzeichnisse eine Datei dieses Namens.

4. Muss ich diese Datei erst erstellen und darin dann die benötigten Variablen setzen?

5. Oder kann ich auch irgendwie sagen: "Nimm die Umgebung des Users Pipapo"?

Hallo!

Cronjobs gibt es unter Ubuntu nicht mehr. Dafür werkelt jetzt systemd. Dort können Umgebungsvariablen in einer Konfigurationsdatei festgelegt werden. Heisst dann in etwa so: /etc/systemd/system/mein.service.d/override.conf. Alternativ kann man systemweit über pam_env eine für alle Nutzer verwendete Standardkonfiguration angeben.

Was die SSH-Verbindung angeht: Diese verbindet mit den Umgebungsvariablen des gewählten Nutzers und der angewählten Shell. Unter Ubuntu wäre das die bash als Shell und somit alles unterhalb .bashrc. Bei anderen Shells werden entsprechend deren Konfigurationen ausgeführt.

Der SSH-Server kann allerdings so eingestellt sein, dass das laden dieser Umgebungsvariablen per se verboten ist (PermitUserEnvironment). Dann funktioniert das so nicht.

ChickenLipsRfun2eat schrieb:

Cronjobs gibt es unter Ubuntu nicht mehr. Dafür werkelt jetzt systemd.

Häh? Habe ich jetzt meine Frage doof formuliert?

Ich meinte das, was ich mit crontab -l ansehen und mit crontab -e bearbeiten kann. Und mein Problem scheint zu sein, dass die dort eingetragenen Skripte nicht die Umgebung des Users nutzen, unter dem sie eingetragen sind. Konkret:

1
2
3
4
5
6

localadmin@svh-dev:~$ sudo crontab -l
no crontab for root
localadmin@svh-dev:~$ crontab -l
(...)
0 4 * * 2-6 sh /home/localadmin/backup-vm.sh svr-sql /VMs/1819 /svr-bak/day >> "/home/localadmin/backuplog.txt"
localadmin@svh-dev:~$ 

Aber es scheint so, als würden die Skripte als root ausgeführt, zumindest gibt es in dessen Verzeichnis ein Config-Verzeichnis für Virtualbox:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

localadmin@svh-dev:~$ sudo ls /root/.config/VirtualBox -la
total 76
drwx------ 2 root root  4096 Mar 25 11:16 .
drwx------ 3 root root  4096 Feb 11 07:07 ..
-rw------- 1 root root  3082 Mar 25 11:16 VBoxSVC.log
-rw------- 1 root root  3082 Mar 25 10:59 VBoxSVC.log.1
-rw------- 1 root root  3082 Mar 25 10:53 VBoxSVC.log.2
-rw------- 1 root root  3082 Mar 25 10:51 VBoxSVC.log.3
-rw------- 1 root root  3082 Mar 25 10:51 VBoxSVC.log.4
-rw------- 1 root root  3082 Mar 25 10:43 VBoxSVC.log.5
-rw------- 1 root root  3324 Feb 11 08:34 VBoxSVC.log.6
-rw------- 1 root root  3860 Feb 11 07:07 VBoxSVC.log.7
-rw------- 1 root root  1184 Feb 11 07:07 compreg.dat
-rw------- 1 root root 30001 Feb 11 07:07 xpti.dat
localadmin@svh-dev:~$ 

... und das, obwohl ich mich niemals wirklich als root angemeldet habe.

p.s.: Was wohl grundsätzlich doof ist, dass ich in meinem Skript sh als Shell stehen habe - das sollte wohl besser bash sein. Oder reicht da ein Punkt? Ich bin unsicher mit der Syntax. Aber das kann ja wohl kaum für mein Problem verantwortlich sein, oder etwa doch?

Schau doch mal in Cron.

Du kannst mal versuchen oben in der Crontab folgendes zu setzen:

SHELL=/bin/bash

Das sh würde ich auch jeden Fall auch weglassen.

Emma2 schrieb:

Häh? Habe ich jetzt meine Frage doof formuliert?

Nein. Unter dem von dir angegebenen 20.04 ist systemd.cron im Standard aktiv. Wenn du jetzt mittels crontab noch weitere Dienste/Aufgaben einträgst, kann es passieren, dass diese doppelt laufen — oder gar nicht funkionieren. Falls du also irgendwas anderes als das Standard-Ubuntu wie angegeben verwendest, schreib Bescheid. Da kann es dann wieder anders sein.

... und das, obwohl ich mich niemals wirklich als root angemeldet habe.

Kannst du unter Ubuntu auch gar nicht [1]. Aber das kann daher kommen, dass du sudo/pkexec verwendet hast, oder daran liegen, dass dein Nutzer nicht der passenden Gruppe vboxusers (siehe VirtualBox) angehört.

p.s.: Was wohl grundsätzlich doof ist, dass ich in meinem Skript sh als Shell stehen habe - das sollte wohl besser bash sein. Oder reicht da ein Punkt? Ich bin unsicher mit der Syntax. Aber das kann ja wohl kaum für mein Problem verantwortlich sein, oder etwa doch?

Umgebungsvariablen, die mit export VAR=VALUE exportiert wurden, sind im Script verfügbar, das gilt für bash und sh gleichermassen (die Konfigurationsdateien unterscheiden sich aber). Andere nicht, lassen sich aber auch da festlegen. Die Shebang (also das #!/bin/sh) kannst du theoretisch weglassen. Da gäbe es aber auch noch eine Möglichkeit Umgebungsvariablen mit #!/usr/bin/env bash zu laden.

Was genau versuchst du denn zu erreichen? Welche Variablen brauchst du im Script?

• 1: Du kannst dir allerdings eine root-shell öffnen

Emma2 schrieb:

p.s.: Was wohl grundsätzlich doof ist, dass ich in meinem Skript sh als Shell stehen habe - das sollte wohl besser bash sein. Oder reicht da ein Punkt? Ich bin unsicher mit der Syntax. Aber das kann ja wohl kaum für mein Problem verantwortlich sein, oder etwa doch?

Jetzt kommt mir ein schrecklicher Verdacht: Kann das genau doch das Problem sein? Wenn ich Skripte mit sh starte, nutzen die dann eine andere Umgebung, als wenn ich sie unter bash starte? Wenn das so ist, dann passt alles zusammen...

... alles? Nee, noch nicht ganz, denn auf zwei anderen Hosts, auf denen die gleichen Crontabs mit sh stehen, habe ich mein beschriebenes Problem nicht. Ich versteh's einfach nicht... ☹

Kommt darauf an, wie sie gestartet werden. Wenn du ein Terminalfenster öffnest und darin sh ausführst, sind alle Umgebungsvariablen vererbt. Ich würde dir zunächst raten, die oben verlinkten Wiki-Artikel zu lesen. Dann ist zumindest das schon mal klar. Danach wären dann die Informationen wichtig, welche Umgebungsvariablen gesetzt sind und welche fehlen — und wie die fehlenden normalerweise gesetzt werden.

denn auf zwei anderen Hosts, auf denen die gleichen Crontabs mit sh stehen, habe ich mein beschriebenes Problem nicht. Ich versteh's einfach nicht...

Naja, dann heißt es herauszufinden, wo der Unterschied sein mag...

ChickenLipsRfun2eat schrieb:

Kommt darauf an, wie sie gestartet werden. Wenn du ein Terminalfenster öffnest und darin sh ausführst, sind alle Umgebungsvariablen vererbt.

Nee, ich mache es genau andersherum:

1. Ich öffne eine SSH-Verbindung, und die nutzt die bash, dort starte ich meine VMs und schließe dann die SSH. 2. In der Nacht laufen meine Backup-Jobs, und dort stand bisher explizit sh drin (weil ich das mangels Kentnnissen irgendwann mal abgetippt habe).

Meine Befürchtung ist also, dass die Aufrufe aus der Crontab, die ja nun gezwungen werden, sh statt bash zu nutzen, ihre eigene Umgebung nutzen. Zumindest finde ich im Profil von root VBox-Config-Dateien, die ich selbst nicht aktiv angelegt habe. Ich habe nun meine Skripten "repariert" und werde beobachten, ob das Problem weiterhin besteht.

Doc_Symbiosis schrieb:

denn auf zwei anderen Hosts, auf denen die gleichen Crontabs mit sh stehen, habe ich mein beschriebenes Problem nicht. Ich versteh's einfach nicht...

Naja, dann heißt es herauszufinden, wo der Unterschied sein mag...

Das ist ja (zumindest für meinen Kenntnisstand) das größte Mysterium: Alle drei Hosts habe ich in einem Rutsch aufgesetzt, Ubuntu installiert, dann den Rest über SSH mit Copy&Paste installiert. Die sollten - nach menschlichem Ermessen - alle gleich eingerichtet sein. Der einzige Unterschied zwischen denen ist, dass mein Problem nur auf dem Host auftritt, der den AMD Ryzen 5 hat, nicht aber auf den Intel-Kisten. Ich weiß, dass es hanebüchen ist, denn die Shell(s) und das Abarbeiten der Crontab kann ja nicht auf AMD-Prozessoren anders ablaufen als auf Intel-CPUs - aber ich sehe sonst echt keinen Unterschied... ☹

Oder andersherum: Gibt es irgendeine Möglichkeit bzw. ein Tool, um die (Software-)"Konfigurationen" zweier Linux-Maschinen zu vergleichen?

Doc_Symbiosis schrieb:

Das sh würde ich auch jeden Fall auch weglassen.

Jau, war mir - wie berichtet - zwischendurch auch schon aufgefallen. Ich habe jetzt bash statt sh gesetzt und beobachte das Verhalten. (In manchen Beiträgen steht dort auch nur ein Punkt, aber da ich nicht dessen Bedeutung kenne, habe ich lieber explizit bash geschrieben. Könnte der Punkt bedeuten "aktuelle Shell weiterverwenden"?)

(Zur Entschuldigung: Ich beschäftige mich erst seit zwei Jahren überhaupt mit Linux, und die Systemverwaltung meines kleinen Netzes ist nicht mein Hauptjob; deshalb muss ich noch sehr viel lernen, und das sh in meiner Crontab stammt aus irgendwelchen abgetippten Beispielen... 😐 )

ChickenLipsRfun2eat schrieb:

Unter dem von dir angegebenen 20.04 ist systemd.cron im Standard aktiv. Wenn du jetzt mittels crontab noch weitere Dienste/Aufgaben einträgst, kann es passieren, dass diese doppelt laufen — oder gar nicht funkionieren. Falls du also irgendwas anderes als das Standard-Ubuntu wie angegeben verwendest, schreib Bescheid. Da kann es dann wieder anders sein.

Ich habe einen "Standard" Ubuntu 20.04 "Server" installiert. (Die Maschinen laufen ausschließlich als Host für Virtualbox.) Dienste starte ich keine, sondern es geht lediglich um meine Skripten, die die Backups meiner VMs erstellen.

ChickenLipsRfun2eat schrieb:

Aber das kann daher kommen, dass du sudo/pkexec verwendet hast, oder daran liegen, dass dein Nutzer nicht der passenden Gruppe vboxusers (siehe VirtualBox) angehört.

sudo/pkexec habe ich nicht genutzt (kenne ich gar nicht), und mein User ist Mitglied der vboxusers.

ChickenLipsRfun2eat schrieb:

Was genau versuchst du denn zu erreichen? Welche Variablen brauchst du im Script?

Wie beschrieben starte ich meine VMs "manuell" aus einer SSH (weil ich mich noch nicht mit einem "Autostart" beschäftigen konnte), danach verlasse ich die SSH mit Strg+D. Die Skripten in meiner Crontab laufen automatisch und sollen die VMs sichern (runterfahren, wenn sie laufen; sichern; wieder starten, wenn sie vorher liefen). Und dabei trat nun der Effekt auf, dass die VMs teilweise "mehrfach liefen" und ich an sie nicht mehr "rankommen" konnte... an die VMs selbst schon, aber selbst nach dem Runterfahren lief deren VBoxHeadless-Prozess weiter. Es entstand der Eindruck, dass die (wieder-)gestarteten VMs in einem anderen "Kontext" liefen. (Sie gehörten definitiv dem selben User, aber der konnte sie nicht mehr "sehen".) Deshalb kam die Idee auf, dass die Skripten aus der Crontab eine andere Virtualbox-Konfiguration nutzen würden - und so schien es auch zu sein. Ich finde zwei VBox-Konfigurationen, obwohl ich aktiv nur mit einem User arbeite. Die eine davon findet sich in /home/localadmin/.config/VirtualBox, und die andere steht in /root/.config/VirtualBox. Und tatsächlich scheint es so, als sei bei Verwendung von sh in meiner Crontab die Konfiguration in /root bedient worden (zumindest wurde dort ins Log geschrieben), während nun mit bash die gewünschte Konfiguration in /home/localadmin verwendet wird.

Deshalb jetzt ganz konkret gefragt: Ist es denkbar, dass - wenn ich nichts anderes eingestellt habe - bei Verwendung von sh die Skripten in der Crontab die Umgebung von root nutzen? 😮 Zumindest macht es so den Eindruck...

Nein, sie nutzen nicht die Umgebung von Root, aber eine sehr abgespeckte Umgebung, wo evtl. Umgebungsvariablen nicht gesetzt sind, die aber in dem Skript verwendet werden und das Skript dann auf irgendwelche Default-Werte springt oder so.

Da muss man sich genau anschauen, was das Skript so tut.

Ok, vielleicht habe ich wieder falsch gefragt: Ist es denkbar, dass mein Skript das Verzeichnis /root/.config nutzt, um "seine" VirtualBox-Konfiguration zu speichern (vielleicht als Default, weil es nichts besseres "weiß"?

Meine Crontab sieht so aus (Auszug) (außer dass dort vorher sh stand, wo jetzt bash steht):

1
2

# m h  dom mon dow   command
0 4 * * 2-6 bash /home/localadmin/backup-vm.sh svr-sql /VMs/1819 /svr-bak/day >> "/home/localadmin/backuplog.txt"

... und das Skript ist auch nicht so besonders (ich poste es aber vollständig):

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

#!/bin/bash

#check parameters
if [ $# -ne 3 ]
then
  echo "usage: $0 <vm name> <vm directory> <backup directory>"
  exit 1
fi

dateToday=`date +%Y-%m-%d`
timeStart=`date +%H-%M`

#check if VM exists at all
if ! `vboxmanage list vms | grep -iq $1`
then
  echo "$1": "$dateToday VM does not exist"
  exit 1
fi

#check if VM is running
if `vboxmanage list runningvms | grep -iq $1`
then
  isRunning=0
else
  isRunning=1
fi

#shut down VM if it's running
if [ $isRunning -eq 0 ]
then

  vboxmanage controlvm $1 acpipowerbutton > /dev/null

  #and wait until shut down
  stopped=1
  steps=60
  while [ $stopped -ne 0 -a $steps -gt 0 ]
  do
    if ! `vboxmanage list runningvms | grep -iq $1`
    then
      stopped=0
    else
      sleep 1
      ((--steps))
    fi
  done

  #if not stopped report error
  if [ $stopped -ne 0 ]
  then
    echo "$1: VM could not be not stopped"
    exit 1
  fi

fi

timeDown=`date +%H-%M`

#copy VM to a localbuffer
rsync -algo --delete "$2/$1/" "$2/$1.bak/"

#start VM if it has been running before
if [ $isRunning -eq 0 ]
then

  vboxmanage startvm $1 --type headless > /dev/null

  started=1
  steps=60
  while [ $started -ne 0 -a $steps -gt 0 ]
  do
    if `vboxmanage list runningvms | grep -iq $1`
    then
      started=0
    else
      sleep 1
      ((--steps))
    fi
  done

  #if not started report error
  if [ $started -ne 0 ]
  then
    echo "$1": "$dateToday VM could not be not started again"
  fi

fi


#wait until runnung 
timeUp=`date +%H-%M`

if [ -z "$(ls -A "$2/$1.bak")" ]
then
  echo "$1: failed to create local copy - terminate!"
  exit 1
fi

#if there is a backup already
if [ -n "$(ls -A "$3/1/$1")" ]
then

  #remove backbackup
  rm -r "$3/2/$1"

  #copy this backup to backbackup
  cp -al "$3/1/$1/" "$3/2/$1"

fi


#rsync local copy to backup
rsync -algo --delete "$2/$1.bak/" "$3/1/$1"

timeReady=`date +%H-%M`

#report result
echo "$1": "$dateToday - start $timeStart, down $timeDown, up $timeUp, ready $timeReady"

Das Skript prüft seine Parameter: $1 = VM, $2 = VM-Verzeichnis, $3 = Backup-Ziel. Wenn die VM läuft, wird versucht, sie anzuhalten (Zeile 32). Bei Erfolg wird die VM lokal kopiert (Zeile 60). Wenn sie vorher lief, wird sie neu gestartet (Zeile 66). Danach wird das ältere der beiden Backups gelöscht (Zeile 104), das neue als älteres umgehoben (Zeile 107) und zum Schluss die neue Kopie aufs Backup-Laufwerk ge-sync-t (Zeile 113). Schließlich will ich noch wissen, wie lange das alles gedauert hat (Zeile 118). Das scheint mir jetzt nicht besonders zu sein, auf gar keinen Fall bezüglich irgendwelcher Umgebungsvariablen Oder doch?

Emma2 schrieb:

Ok, vielleicht habe ich wieder falsch gefragt: Ist es denkbar, dass mein Skript das Verzeichnis /root/.config nutzt…

Nein. Du kannst nur eine VBox-Konfiguration als root haben, wenn dieser VBox ausgeführt hat. Da könnte es einen systemd-Dienst für geben (nutze VBox nicht, QEMU, bzw. libvirtd richtet sowas ein), du könntest es mal mit sudo gestartet haben, etc. Auf keinen Fall werden die Nutzerrechte bei Bedarf automatisch auf root erweitert (Ja, da gibts Ausnahmen wie sudo, die das machen; sollte man aber nicht selbst nutzen (siehe Rechte)). Kannst du prüfen mit ls -lha $(which virtualbox)

Meine Crontab sieht so aus (Auszug) (außer dass dort vorher sh stand, wo jetzt bash steht):

1 2	# m h dom mon dow command 0 4 * * 2-6 bash /home/localadmin/backup-vm.sh svr-sql /VMs/1819 /svr-bak/day >> "/home/localadmin/backuplog.txt"

Da solltest du den absoluten Pfad angeben: /usr/bin/bash. Oder gleich /usr/bin/bash --login.

... und das Skript…

Du brauchst für das Script mindestens die PATH-Variable, die auf die ausführbaren Programme zeigt, oder du gibst sie auch hier mit absoluten Pfaden an. Also /usr/bin/rsync anstatt rsync, etc.. Die Mischung aus backticks und dem aktuellen $() ist auch nicht schön, aber sollte funktionieren.
Hilfreich wäre noch die konkrete Fehlermeldung, die du bekommst.

9240413:

Ich habe einen "Standard" Ubuntu 20.04 "Server" installiert. (Die Maschinen laufen ausschließlich als Host für Virtualbox.) Dienste starte ich keine, sondern es geht lediglich um meine Skripten, die die Backups meiner VMs erstellen.

Da gibt es keinen Standard, wenn ich mich recht erinnere. Mann muss einiges schon bei der Installation festlegen. Und du startest Minimum einen Dienst zu den bereits vorhandenen: Virtualbox. Das bringt zusätzlich eigene Kernelmodule mit, ist also schon etwas relevantes. Daher wäre es auch hilfreich mal die Fehler aus journalctl rauszufiltern und ggf. zu analysieren/beheben. Die kannst du auch mit den Intel-Maschinen vergleichen.

Wie beschrieben starte ich meine VMs "manuell" aus einer SSH (weil ich mich noch nicht mit einem "Autostart" beschäftigen konnte)…

Das dürfte nicht das Problem sein. (Autostart = systemd/Units)
Was das doppelte Starten angeht: Das könnte zum einen daran liegen, dass das Script nicht die erwarteten Rückgabewerte bekommt (Ausgaben mitloggen, auch die Fehler!), zum anderen könnte es auch sein, dass sich eine systemd-Unit da einmischt. Zum letzeren kann ich mangels Verwendung nichts sagen, da müsstest du mal gucken, was da so aktiv ist ⇨ systemctl

9240408:

Oder andersherum: Gibt es irgendeine Möglichkeit bzw. ein Tool, um die (Software-)"Konfigurationen" zweier Linux-Maschinen zu vergleichen?

Du könntest die Konfigurationsdateien mit diff vergleichen. Kommt aber auch ein wenig drauf an, was du eingerichtet hast. Nicht alles liegt in /etc/.