Skript wird nicht ausgeführt unter Ubuntu 9.10, unter 14.04 schon

eXTA

Enthusiast
Thread Starter
Mitglied seit
19.10.2007
Beiträge
5.127
Ort
Rostock!
Moin, es geht um diese Geschichte hier: https://github.com/fukawi2/procurve-bup

Das Skript liegt auf einem CIFS Share, beide Maschinen führen dasselbe Skript aus mit derselben Config.

Ubuntu 14.04 Server:
R6Z6sbu.png


Ubuntu 9.10 Server
mi68KMC.png


Auf der alten Maschine passiert nichts, wenn das Skript ausgeführt werden soll. Habt ihr eine Idee, wieso?
Sind beides frische minimal-Installationen, bis auf openssh-server ist nichts nachinstalliert.

Firewall und tcpdump zeigen auch keinerlei Netzwerk-Aktivitäten.

Es scheint so als würde der alten Kiste zum Interpretieren des Skripts irgendwas fehlen.
Ein Vergleich von dpkd -l zeigt zwar einen Unterschied von über 200 Paketen an, aber mir fiel nichts Wesentliches auf.

Ansätze sind gern gesehen, danke :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ruf das Skript mal so auf, dann siehst du wo es stehen bleibt (ohne die Gänsefüßchen): "bash -x /mnt/Backup/procurve-bup-master/procurve-bug.sh -o /mnt/Backup/main-switch/"
 
Einfach mal das Script editieren und an verschiedenen Stellen ein "echo 'doing foobar now...'" o.ä. einbauen um zu schauen, ob es überhaupt etwas tut. Es bietet sich auch immer mal an, ein solches Script durch strace zu schicken: "strace bash /mein/tolles/script.sh", falls du den Output nicht selbst deuten kannst, dann pack ihn einfach hier mit rein.

An dieser Stelle möchte aber auch darauf hinweisen, dass Ubuntu 9.10 hoffnunglos veraltet und schon einige Jahre aus dem Support raus ist. Ich würde dir *dringend* dazu raten, das System abzuschaffen (was hoffentlich der Sinn der neuen 14.04 Maschine ist).


:wink:
 
Hier erstmal Output von bash -x
root@ubuntu:/etc# bash -x /mnt/Backup/procurve-bup-master/procurve-bup.sh -o /mn - Pastebin.com

Und strace bash:
root@ubuntu:/etc# strace bash /mnt/Backup/procurve-bup-master/procurve-bup.sh -o - Pastebin.com

kann das sein, dass das oben schon losgeht mit Problemen? (access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory))


Naja, das ist nicht meine Maschine.
Auf dem Ding läuft noch ein Nagios. Ich weiß auch nicht, wieso Ubuntu nicht geupdated wird. :d
 
Zuletzt bearbeitet:
kann das sein, dass das oben schon losgeht mit Problemen? (access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory))
Ne, strace is totaler Overkill in dem Fall, mach dir da mal keinen Kopf drüber.

+ grep -P '^\s*[^#;]' /etc/procurve-bup.conf
+ read name addr user method value
+ [[ -z '' ]]
+ log_err 'ERROR: no name specified'
+ log2syslog err 0 'ERROR: no name specified'
+ local _priority=err
+ local _quiet=0
+ local '_msg=ERROR: no name specified'
+ local _logger_args=
+ [[ -n 0 ]]
+ _logger_args=-it
+ logger -it procurve-bup -p user.err -- ERROR: no name specified
+ exit 1
Sieht für mich so aus, als ob er nach der Variablen "name" in der Datei /etc/procurve-bup.conf sucht und diese nicht findet? Übrigens scheint das Skript Fehlermeldungen nach /var/log/syslog oder /var/log/messages auszugeben, das lohnt sich auch anzuschauen.
 
Mach mal "grep -P '^\s*[^#;]' /etc/procurve-bup.conf" auf beiden Ubuntu Maschinen und vergleiche das Ergebnis. Auf der 14.04 Maschine findet er da einen Eintrag, auf der 9.10 Maschine nicht.
 
Ubuntu 9.10
Code:
root@ubuntu:/etc# grep -P '^\s*[^#;]' /etc/procurve-bup.conf

#
main-switch     192.168.0.88            root   password  password

#

#

Ubuntu 14.04
Code:
root@ubuntu:/etc# grep -P '^\s*[^#;]' /etc/procurve-bup.conf
[COLOR="#FF0000"]m[/COLOR]ain-switch     192.168.0.88            root   password  password
 
Sieht so aus, als ob der Regex auf dem alten grep von der Ubuntu 9.10 Maschine nicht richtig läuft, der sollte wohl nur eine einzige Zeile ausgeben und nicht noch den Murks drumrum.

Wenn da wirklich nur die eine Zeile rauskommen soll, könntest du das grep auch so umbauen:

Code:
grep '^main' /etc/procurve-bup.conf

Kannst ja vergleichen, ob das dann das gleiche Resultat liefert, wie auf der 14.04 Maschine.


:wink:
 
Ich vermute, dass das alte grep mit der "-P" Option nicht so ganz zurande kommt. Wenn ich das richtig verstehe, ist das -P da, damit grep das \s* im Ausdruck versteht. Ohne das jetzt ausprobiert zu haben, evtl. würde das funktionieren: "grep -E '^[:space:]*[^#;]' /etc/procurve-bup.conf"

Edit: Zuerst könntest du mal schauen, ob in Ubuntu 9 pcre installiert ist und das evtl. nachinstallieren. Das wird von grep -P benutzt.
 
Zuletzt bearbeitet:
Alles klar, danke schonmal.
Mit dem abgeänderten grep von euch beiden gibt er nur die eine Zeile korrekt aus.

Nachinstalliert habe ich jetzt noch libpcre3-dbg, libpcre3-dev, libpcre3.

Läuft natürlich immer noch nicht. :(
Muss ich in dem Skript irgendwas ändern mit der Erkenntnis vom geänderten grep?

ah, klar, die Stelle im Skript mit grep abändern. Es startet jetzt zumindestens, erstellt den Ordner, Inhalt aber leer. Muss mal weiterschauen, so ein Verhalten hatte ich bei 14.04 auch anfangs
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Da stimmt etwas mit der Hostadresse nicht. In deinem pastebin steht:
Code:
sshpass -f /tmp/tmp.T2Y0weqarr scp -q -o PubkeyAuthentication=no -o PasswordAuthentication=yes root@192.168.0.8                    8:/cfg/running-config .switchbup-1740

Da wurde die 192.168.0.88 in zwei Teile getrennt. Vielleicht etwas noch falsch mit dem grep?

Oder ist die Zeile einfach umgebrochen worden und du hast das falsch gepasted? In dem Fall probiere, was passiert wenn du das hier direkt von der Kommandozeile ausführst:
Code:
scp -q -o PubkeyAuthentication=no -o PasswordAuthentication=yes root@192.168.0.88:/cfg/running-config .switchbup-1740
 
Das fiel mir im Output auch auf, dachte da an Zeilenende usw.. aber du hast recht, ich habe den grep Befehl nochmal geändert (auf deine Version von oben) und nun geht's! :)

Schon seltsam, weil ja beide greps dieselbe Ausgabe geliefert haben
 

Ähnliche Themen

Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh