Hallo Forengemeinde! Ich bin hier seit Jahren angemeldet und eigentlich nur stiller Mitleser. Jetzt brauch ich aber mal Euer geballtes Wissen, da ich mit meinen Linux-Kenntnissen nicht mehr weiterkomme und Google nicht viel bringt. Folgender Sachverhalt: Ich habe im Ort N. einen Server stehen. Darauf läuft Opensuse 15.5 und dient als Dateiserver für eine kleine Firma. Funktioniert soweit seit 15 Jahren (fast) perfekt. Dieser Server hängt über eine Fritzbox 7590 am Internet, VPN mittels wireguard ist eingestellt und funktioniert. Nun möchte ich von mir zuhause im Ort W. täglich abends per rsync ein differentielles Backup erstellen. Der Server hierfür läuft auch wieder unter Opensuse 15.5, wireguard ist installiert und der Zugriff auf den Server in die Firma funktioniert einwandfrei. Für das tägliche Backup habe ich ein bash-script erstellt, welches einen wireguard-VPN Tunnel öffnet, alle Daten synchronisiert, danach dann den Tunnel schließt sowie nach getaner Arbeit den Server zuhause wieder herunterfährt. Nach einigem Rumprobieren läuft das script einwandfrei durch, sichert alles wie gedacht. Nun kommt das Problem: Das script funktioniert nur, wenn ich es als root in der Konsole unter bash direkt starte. Ich habe das script in die crontab eingetragen. Es wird auch zum richtigen Zeitpunkt aufgerufen, bricht aber immer mit dem Fehler: "[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 /usr/bin/wg-quick: line 32: sysctl: command not found" ab. Siehe Bild. Habe lange nach diesem Fehler gegoogelt. Andere sind auch betroffen, haben aber auch keine Lösung gefunden. Deswegen: könnt Ihr weiterhelfen? Würde mich riesig freuen. Vielen Dank im Voraus für Eure Beiträge! PS: Bild im Anhang zeigt die Fehlerausgabe
:
Bearbeitet durch User
Der Cron Scheduler läuft mit anderen Umgebungsvariablen, als eine interaktive root Sitzung. Du könntest sue mit dem env Befel ausgeben und vergleichen. Vielleicht scheitert es ganz banal am PATH.
Hans M. schrieb: > Ich habe das script in die crontab eingetragen. Es wird auch zum > richtigen Zeitpunkt aufgerufen, bricht aber immer mit dem Fehler: "[#] > sysctl -q net.ipv4.conf.all.src_valid_mark=1 > /usr/bin/wg-quick: line 32: sysctl: command not found" ab. Klingt nach falschem Suchpfad. Fehlt /sbin?
Hans M. schrieb: > sysctl: command not found" sysctl ist im (/usr)/sbin Verzeichnis, nicht (/usr)/bin. Also für Nicht-Root nicht im Pfad, für cron evtl. auch nicht, wenn die crontab das nicht per PATH=... definiert. Also: Einfach im script den vollen Pfad zu sysctl angeben.
Εrnst B. schrieb: > Hans M. schrieb: >> sysctl: command not found" > > sysctl ist im (/usr)/sbin Verzeichnis, nicht (/usr)/bin. Also für > Nicht-Root nicht im Pfad, für cron evtl. auch nicht, wenn die crontab > das nicht per PATH=... definiert. > > Also: Einfach im script den vollen Pfad zu sysctl angeben. Hallo Zusammen! Vielen Dank für die ersten Meldungen. ich habe jetzt folgendes gemacht: In der Konsole geprüft: nasathome:~ # which sysctl /sbin/sysctl habe in mein script folgendes eingetragen: PATH=$PATH:/sbin/ export PATH und nochmals mittels webmin den cronjob gestartet Ergebnis: die gleiche Fehlermeldung erscheint. Also der Pfad war es wohl schonmal nicht :-(
Hans M. schrieb: > ,,, wenn ich es als root in der Konsole unter > bash direkt starte. Hat "root" keine eigene crontab? Evtl. braucht dein Script tatsaechlich root-Rechte. Da huelft ein Patheintrag dann natuerlich ueberhaupt nicht.
Beitrag #7605982 wurde vom Autor gelöscht.
Hans M. schrieb: > das script wird als root gestartet. siehe Bild. Dann solltest du mit einem "whoami >/tmp/blablupp;set >>/tmp/blablupp" im script einmal kontrollieren was da gespielt wird.
Das sieht mir eher nach "direkt eingetippt und gestartet" als nach crontabjob aus. Wenn alles richtig ist, muss es ja funktionieren.
tut es eben nicht! sonst würde ich hier nicht um Hilfe bitten!
Wird das Programm in der systemübergreifenden Crontab -> /etc/crontab oder einer benutzereigenen Crontab gestartet? Zeig mal Deine Datei /etc/crontab als Code
Hemm, ein sbin steht im Pfad und er findet sysctl nicht. Da findet er dann wohl ein passendes ld-linux.so.* nicht. Warum auch immer. Ein /sbin/sysctl sollte dann auch einen Fehler erzeugen. Der LD_LIBRARY_PATH ist auch "leer". Ob das in deiner Umgebung richtig ist, kann ich dir nicht sagen. Du solltest es aber in einer interaktiven shell pruefen.
und zeig mal bitte das Ergebnis von
1 | ls -la /usr/bin/wg-quick |
das script wird gestartet aus der root crontab unter /var/spool/cron/tabs/root
Hans M. schrieb: > /sbin/sysctl findet er > siehe Bild Dann schreib das doch auch einfach so in dein Skript.
probier mal in der crontab statt
1 | bash ... |
-->
1 | /bin/bash ... |
oder
1 | /usr/bin/bash ... |
also, das hat das ganze etwas vorangebracht!!!! DER SYSCTL Fehler ist überwunden, dafür ist jetzt der nächste Fehler da...
> dafür ist jetzt der nächste Fehler da...
Du solltest jetzt selber wissen wie du den beheben kannst. :)
MotoPick! Super vielen Dank! das war der richtige Hinweis! Jetzt läuft alles perfekt! Ich habe in der /usr/bin/wq-quick vor die Befehle sysctl und iptables-restore den jeweils richtigen absoluten Pfad geschrieben. also /sbin/sysctl und /usr/sbin/iptables-restore und schon werden die Befehle gefunden! Nochmals RIESENDANK für die Hilfen von Euch allen!!! Trotzdem ist unklar, warum trotz der Pfade in der Umgebungsvariable die Befehle nicht gefunden werden....
Hans M. schrieb: > Trotzdem ist unklar, warum trotz der Pfade in der Umgebungsvariable die > Befehle nicht gefunden werden.... > PATH=$PATH:/sbin/ > export PATH Weil die Shell die neuen Kommandos unter /sbin noch nicht kennt. Das naechste Mal also besser so: PATH=/sbin:$PATH export PATH hash -r
...wieder was gelernt "hash -" kannte ich noch nicht ich habe dafür immer "history" verwendet
Hans M. schrieb: > ...wieder was gelernt > "hash -" kannte ich noch nicht > > ich habe dafür immer "history" verwendet hash -r hat mit history genau nichts zu tun. Es gibt noch viel zu lesen.
oh ja, und das werde ich auch tun! habe halt doch nur ein gesundes Halbwissen :-|
Hans M. schrieb: > habe in mein script folgendes eingetragen: > PATH=$PATH:/sbin/ > export PATH Irgendwie sieht der "/" am Ende komisch aus. Mal weglassen.
Also ich habe den "hash -r" eigentlich noch nie benutzen müssen, selbst wenn ich in einem Shellskript den PATH verändert habe. Also gerade auch in cron scripts hat es immer so funktioniert. Und so auch in diesem einfachen Beispiel:
1 | [root@acme blub]# crontab -l |
2 | * * * * * /root/blub/bla.sh |
3 | [root@acme blub]# cat bla.sh |
4 | #!/bin/sh |
5 | exec >/tmp/debug.txt 2>&1 |
6 | set -x |
7 | mytest |
8 | export PATH=$PATH:/root/blub |
9 | mytest |
10 | [root@acme blub]# cat mytest |
11 | #!/bin/sh |
12 | echo "hallo!" |
13 | [root@acme blub]# cat /tmp/debug.txt |
14 | + mytest |
15 | /root/blub/bla.sh: line 4: mytest: command not found |
16 | + export PATH=/usr/bin:/bin:/root/blub |
17 | + PATH=/usr/bin:/bin:/root/blub |
18 | + mytest |
19 | hallo! |
Anderes Thema... Dir ist bekannt, dass rsync verschlüsselt über ssh arbeitet und man da einfach nur einen offenen SSH-Server braucht und nicht mit wireguead usw. Umwege machen muss? rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/ Baut automatisch einen SSH Tunnel auf remotemachine auf, startet dort einen rsync Server, erledigt die Arbeit, stoppt den rsync Server und schließt die ssh-Session.
Markus M. schrieb: > Und so auch in diesem einfachen Beispiel: Wie du am einfachen Beispiel des TO gesehen hast, war es bei ihm wohl erforderlich. Noetig ist es allgemein immer dann, wenn $PATH geaendert wurde, und die Shell die Liste der darueber ausfuehrbaren Kommandos aktualisieren muss. Es reicht z.B. auch, ein Binary in ein Verzeichnis zu kopieren, dass Bestandteil von $PATH ist. Auch das wuerde nicht gefunden. Also nicht nur in Cronjobs. Du kannst derweil ja herausfinden, warum es bei dir ohne "hash -r" funktioniert.
Peter D. schrieb: > Anderes Thema... > Dir ist bekannt, dass rsync verschlüsselt über ssh arbeitet und man da > einfach nur einen offenen SSH-Server braucht und nicht mit wireguead > usw. Umwege machen muss? > > rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/ > > Baut automatisch einen SSH Tunnel auf remotemachine auf, startet dort > einen rsync Server, erledigt die Arbeit, stoppt den rsync Server und > schließt die ssh-Session. ...nein, das war mir so nicht bekannt. Und so macht man (hier: ich) aus Unwissenheit über Jahre eben was falsch...
Hans M. schrieb: >> rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/ Nee, das muss so aussehen (-e gibt die remote shell an):
1 | rsync -av -e ssh /some/src/dir/ user@remotemachine:/some/path/to/go/ |
sonst wäre das unverschlüsselt
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.