Script wirft mal Fehler aus, mal nicht

  • Hey,


    ich stehe zwar aktuell auch mit dem Support in längerer Rücksprache, jedoch eröffne ich mal diesen Thread, da es vielleicht ja auch andere Kunden mit ähnlichen Problemen gibt, die auch nicht weiterkommen oder das ganze schon durch haben und wissen, woran es liegt. Hat man dann den Grund gefunden, wird dies sicherlich auch anderen Kunden behilflich sein.


    Ich habe aktuell ein Script, in welchem öfters ein Wert eines Strings mittels bash rematch aus einer Quelldatei gezogen wird. Auf meinem Rootserver gibt es keine Probleme, auf dem Webhosting schon, daher habe ich diesen Teil, an dem es liegt einmal komplett nachgestellt und liefere gleich die Beispieldateien mit. Das Script sieht wiefolgt aus und liegt jeweils im Stammpfad.





    Auf dem Rootserver:

    Code
    user@hostname:/# ./test001.sh
    
    fund.txt  quelle.txt
    user@hostname:/# cd /testdir001 && cat fund.txt
    gefunden1234

    -------------------------------------------------------------------------------------------------------------------

    Auf dem Webhosting (Direkter Login via winSCP/putty)

    Code
    bash-4.3$ ./test001.sh
    ./test001.sh: line 15: /testdir001/fund.txt: No such file or directory
    
    quelle.txt

    -------------------------------------------------------------------------------------------------------------------


    Auf dem Webhosting (Login auf dem Rootserver, von dessen terminal auf das Webhosting verbunden)

    Code
    user@hostname:~# ssh hostingXXXXXX@46.XX.XXX.XXX
    hostingXXXXXX@46.XX.XXX.XXX's password:
    [...]
    bash-4.3$ cd /
    bash-4.3$ ./test001.sh
    
    fund.txt  quelle.txt
    bash-4.3$ cat /testdir001/fund.txt
    gefunden1234

    -------------------------------------------------------------------------------------------------------------------

    Auf dem Webhosting (via cronjop/"geplante Aufgabe": Befehl ausführen > jetzt ausführen)


    Konfiguration: pasted-from-clipboard.png

    Ausführung: pasted-from-clipboard.png






    Ebenso hat es beim Support geklappt, der sich auch via SSH auf dem Webhosting eingeloggt hat. Ob dies "direkt" oder auch über einen Server war, weiß ich nicht. Jedenfalls scheint mir all dies ein wenig komisch...



    Simon

  • Hi, aufklappen, um meine Anmerkungen zu sehen:

    Ich schätze, es liegt an dem Regex-Vergleich. Kannst du mal mit locale ausgeben lassen, welcher locale jeweils aktiv ist?

    Evtl. Zusammenhang mit Deaktivierung von PAM? -> https://serverfault.com/questions/626346/ssh-locale-wrong

    Du kannst ja auch mal komponentenweise die markierte Zeile debuggen, z. B. jede Komponente einzeln prüfen und direkt Ausgaben auf den stdout erzeugen um nachzuvollziehen, was dort vor sich geht, was true ist und was nicht!

  • Ich habe das Script auf meinem NAS eben zweimal ausgeführt. Einmal erfolgreich, einmal mit Fehler.

    Der Unterschied: Die ausführende Shel!

    mit der /bin/bash funktioniert es, mit der /bin/sh nicht.

    Die eingeschränkte shell vom Webhosting wird also das Problem sein.

  • Erstmal zum echo: Ja gut, da hab ich wohl was vertauscht, ist aber für das eigentliche ergebnis nicht relevant. Die Datei wird ja unabhängig davon erstellt und nachher aufgelistet.


    Locale: Ähm naja das Webhosting kennt den Command „locale“ nicht.


    Den direkten stdout kann ich morgen mal ausprobieren.


    Naja so falsch kann die Zeile/chrooted Bash ja theorethisch nicht sein, immerhin funktioniert sie ja. Halt nur nicht immer...


    Am Rande: Auf einem uralt Expert Light Webhosting (ganz altes Plesk/2015 steht im Footer) konnte ich ein ähnliches Verhalten reproduzieren, JEDOCH funktioniere (!) hier der Aufruf via Cronjob und es lag nachher die fund.txt im Ordner mit korrektem Inhalt.

    Ich würde erstmal stark Putty verdächtigen, hier klappt es nie mit dem direkten Login und dem Webhosting. Weiß irgendjemand zufällig, ob/was Plesk beim Cronjob geändert hat? Irgendwas wird (vermute ich zumindest) ja anders sein.


    Danke schonmal für die Hilfe und auch nochmal den Support, der nochmal geantwortet hat.

  • Naja so falsch kann die Zeile/chrooted Bash ja theorethisch nicht sein, immerhin funktioniert sie ja. Halt nur nicht immer...

    Wenn ich das richtig verstehe, verhält sich das je nach Konfiguration immer gleich. Also, wenn du es auf deinem root server ausführst, geht es immer und woanders geht es nie. Oder willst du sagen, es ändert sich mit der Zeit?


    Ich würde wie DoubleT darauf wetten, dass es an der Shell liegt. Vielleicht ist auf dem Webhosting keine "richtige" Bash installiert und /bin/bash auch nur eine weiterleitung?


    Vielleicht hilft dir bei der Fehlersuche ja:

    echo $0

    (gibt aktuelle shell aus)

    cat /etc/shells

    (verfügbare shells)


  • Naja die Sache ist die, echo $0 wirft „–“ aus. cat /etc/shells läuft darauf hinaus, dass die Datei nicht gefunden wird.


    Nein, es ist _nicht_ so, dass es auf dem Server immer geht (also da schon), aber auf den WebhostingS nicht.

    Wie gesagt: Der Server zickt nie rum.

    Neues Webhosting: Zickt beim Cronjob rum, bei direktem Login (via Putty, anstatt via ssh user@webhost vom Rootserver aus ausgeführt.)

    Altes Webhosting: Zickt nur beim direkten Login rum, die Cronjobs gehen hier.

  • Hallo,


    hab das Skript infrastrukturell leicht geändert, da ich es in meinem Stretch nicht als root laufen lassen wollte.

    Die Ausführungen auf meinem Stretch und auf meinem Webhosting Expert waren beide erfolgreich:

    Code
    /tmp$ ./test.sh 
    gefunden1234
    fund.txt  quelle.txt

    Die Umgebungsvariablen und die bash im Webhosting:

    Eingeloggt habe ich mich per ssh von meiner lokalen Konsole aus!

    Vielleicht wirklich der Putty?


    Viele Grüße


    PS: Noch ein Gedanke: Läuft der CronJob auch im chroot?

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

  • Habe das Script, um alle möglichen Fehlerquellen auszuschließen, nochmal drastisch gekürzt:

    Bash
    #!/bin/bash
    str='"<gesucht="gefunden1234" />"'
    regex='<gesucht="([0-9a-zA-Z._-/:]*)" />'
    [[ $str =~ $regex ]] && echo ${BASH_REMATCH[1]}

    Die Ergebnisse sind absolut identisch...


    Hat jemand eine Idee, wie man bei ssh user@host das Passwort mitliefern kann bzw. das über ein Script regeln kann? Sonst würde ich mich via ssh vom webhosting erneut aufs webhosting verbinden, soweit das geht, in der Hoffnung, dass es sich dann wie beim Rootserver+webhosting verhält...

  • SSH mit Schlüsseln?


    https://www.debian.org/devel/passwordlessssh

    • Rufen Sie ssh-keygen(1) auf Ihrem Rechner auf und geben Sie nur Enter ein, wenn Sie nach einem Passwort gefragt werden.
      Dies wird einen privaten und einen öffentlichen Schlüssel erzeugen. Mit älteren SSH-Versionen werden diese in ~/.ssh/identity und ~/.ssh/identity.pub gespeichert; mit neueren in ~/.ssh/id_rsa und ~/.ssh/id_rsa.pub.
    • Als Nächstes fügen Sie den Inhalt des gerade erzeugten öffentlichen Schlüssels (~/.ssh/id_rsa.pub) in Ihre ~/.ssh/authorized_keys-Datei auf dem entfernten System ein (die Datei sollte mode 600 gesetzt sein).

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

  • Keys sind mir durchaus bekannt, nur setzt das mal beim Webhosting ein. Da ist einfach kein Zugriff auf die sshd_config möglich, sodass man die ssh Einstellungen anpassen kann. Ich denke nicht, dass von Grund auf, Keys für alles und jeden gehen.

  • Ich setze es beim Webhosting (Expert S) ein (rein zur Bash und raus zu meinem SVN). Was hat das mit der sshd_config zu tun? Wieso soll das nicht gehen?

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

  • Es wäre ja möglich, dass netcup von Haus aus diverse Dinge schonmal von Grund auf abstellt, ich dachte Keys würden dazugehören, da nirgends darauf hingewiesen wird. Dann werde ich das mal einrichten, danke für den Hinweis!

  • Update: Der Support konnte mir letztlich nicht mehr weiterhelfen, es wäre auch echt zu viel verlangt gewesen, alles durchzugehen, wobei ich dauz absolut kein Experte im Umgang mit bash bin. Da aber nun die Migration des alten Webhostings auf die neue Infrastruktur ansteht und somit meine Ausweichlösung (auf dem alten WCP gings ja) wegfallen wird, hab ich mich nochmal drangesetzt.


    Es lag wohl an den vom Cronjob oder auch von Putty verwendeten locales, so wie ich das verstanden habe. Mit LANG=en_US.UTF-8 bash script.sh funktioniert alles! Eventuell wäre es hilfreich, den Command locale zu erlauben.

  • Hay,


    ist ja interessant. Ich wäre nie auf den Gedanken gekommen, dass dies ein Lokalisierungsprobem sein könnte (bzw alleine schon die Frage "Wie kommt man denn da drauf?").


    Nur rein aus persönlicher Neugier - ist es hinreichend eine lokale Sprache zu setzen ("überhaupt eine") oder muss es in diesem Fall tatsächlich en_US sein? D.h. läuft das Script auch mit LANG=de_DE.UTF-8?


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Ich hatte mal ein ähnliches Problem. Auf einem Container lief mein Skript ohne Probleme, auf einem vServer nicht. Ich habe dann festgestellt, dass die Container standardmäßig mit LANG=C angelegt werden, der vServer war auf LANG=de_DE.UTF-8.

    Seitdem laufen alle meine Maschinchen auf LANG=C, nie Probleme damit.

  • Via LANG=C ging es bei mir bspw. gar nicht.


    Habe es dann nachdem es mit en us utf8 geklappt nicht mehr weiter probiert, es funktioniert ja auch so.