Update 6.06LTS -> 804LTS - ISPConfig

[hahni]

Hallo zusammen,

seit dem Update von Ubuntu 6.06LTS auf 8.04LTS funktioniert alles (soweit ich es geprüft habe und prüfen konnte) einwandfrei. Nur die Updates von ISPConfig funktionieren definitiv nicht.

Ablauf ist folgender:
- ISPConfig.tar.gz runterladen
- tar -xzvf ISPConfig.tar.gz
- cd install_setup
- ./setup

Nach dem Aufruf kommt eine Maske mit der Sprachauswahl. Seit dem Ubuntu-Update kommt aber eine Fehlermeldung:

---
./setup2: line 76: export: `/etc/init.d': not a valid identifier
---

Diese besagte Zeile enthält "nur" einen "IMPORT $variable"-Befehl (setup2 ist ein Shell-Skript). Nun ist die Frage, ob vielleicht dem IMPORT-Befehl irgendwelche Werte fehlen.

Was könnte das sein? Unvollständige Pfadangaben? Evtl. aber auch Pakete, die in 8.04LTS nicht installiert sind, wohl aber in 6.06LTS waren?

Im Forum von ISPConfig weiß man da leider keine Antwort bzw. kommt derzeit keine. Ich bin etwas verzweifelt, weil ich schon gerne die neuesten Programmversionen von ISPConfig einsetzen wollte...

Viele Grüße

Hahni

[hahni]

IMPORt scheint wohl eine Funktion zu sein.
Hast Du schon mal mit echo ..... ausgegeben, was er da mache will?
Und dann solltest Du ggf. mal nach der funktion IMPORT im Script suchen.
_Oder gibt es bei der bunte Kuh auch noch IMPORT als Befehl?_

Der Inhalt wäre für die spätere bearbeitung ganz nützlich.
-> Vieleicht verwendest Du einfach nur die falsche shell.
Ist die shell wie in der shebang angegeben verfügbar?

Gruss Matthias

--> Ist die shell wie in der shebang angegeben verfügbar?
Das wäre ja eine interessante Option zur Prüfung. Wie finde ich denn das raus? Kann sich sowas bei einem Update verstellen?

[hahni]

Die Sache mit der Shell kann ich mir auch nicht vorstellen. Aber das ist ja leicht in "./setup" zu prüfen. Einen symbolischen Link zu setzen, wäre ja ausserdem noch möglich!

Aber was meinst du im Speziellen mit "Parametern / Umgebungsvariablen und ggf. geänderten Pfaden und libs" Dem Problem muss ja irgendwie beizukommen sein.

Interesant ist nämlich, dass ich die Version 2.2.25, die ich vorher auch schon auf dem Server hatte, ohne Fehler neukompilieren kann. Bei 2.2.26 und der neuesten Version 2.2.27 hingegen klappt das nicht.

Laut Autor ist aber nix an den grundsätzlichen Sachen in 2.2.26 und 2.2.27 geändert worden. Von daher bin ich ratlos, warum genau diese Versionen nicht mehr funktionieren????

[daemotron]

Bei Ubuntu ist /bin/sh ein Symlink, der aber seit 6.10 nicht wie bei anderen Distributionen üblich auf /bin/bash, sondern auf /bin/dash verweist. Ich würde ja darauf wetten, das die ISPConfig-Entwickler in ihrem Skript irgendwo bash-spezifische Funktionen nutzen, als Sheebang aber #!/bin/sh angegeben haben. Editiere einfach deren Shell-Skripte und ersetze #!/bin/sh durch #!/bin/bash und teste mal, ob sie sich dann fehlerfrei ausführen lassen. Wäre nicht das erste mal, dass Linux-Entwickler in diese Falle tappen - viele beachten eben leider nicht, dass /bin/bash nicht auf jedem Unix die Standard-Shell sein muss (auch wenn ich da den ISP-Config-Entwicklern erst mal nichts unterstellen will).

Link zum Thema (insbesondere die Diskussion/Kommentare beachten): http://strcat.de/blog/archives/989-bins ... engig.html

[daemotron]

Dann empfehle Ich auch ganz dringend ein vernünftiges OS einzusetzen.
Wer macht sowas?

Ausnahmsweise muss ich Ubuntu mal in Schutz nehmen. Die dash ist konform zu IEEE Std 1003.1 (POSIX) und wurde aus Performance-Gründen gewählt (korrekt geschriebene Init-Skripte laufen damit schneller als mit der Bash, was den Bootvorgang beschleunigt). Hinzu kommt, dass auf vielen anderen Unixoiden /bin/sh alles andere als die GNU Bash ist (Solaris, FreeBSD, NetBSD: Eigenentwicklungen, OpenBSD: PD-Ksh). /bin/sh auf etwas anderes (POSIX-konformes) als die Bash zu linken, ist ansich überhaupt nichts schlimmes und sollte kein Problem sein. Erschossen gehören hingegen Leute, die in ihren Skripten den falschen Interpreter angeben.

[hahni]

Bin ich dann rehabilitiert :o

[daemotron]

muss ich mich dann dazu zählen zu denen die die falsche shebang angeben?

*g* ich bin Pazifist, ich erschieße niemanden (außer vielleicht verbal)

Wenn Deine Skripte kompatibel zur Bourne Shell sind, kannst Du natürlich als Sheebang #!/bin/sh verwenden. Das ist sozusagen der kleinste gemeinsame Nenner zwischen der originalen Bourne-Shell und all ihren Kinderlein (Bash, ZSH, KSH, ASH, DASH, ...). Ein Skript, das sich auf diese Basis beschränkt, lässt sich eben auf all diesen Shells ausführen. Ich bin sogar etwas liberaler und nehme den POSIX-Standard als Maßstab (die originale Bourne Shell hat einen noch geringeren Befehlsumfang als im POSIX-Standard festgelegt - z. B. Befehlssubstitution: originale sh: nur Backticks, POSIX erlaubt zusätzlich $(...), Ausgabeumleitung stdout und stderr getrennt voneinander umleitbar, etc).

Nur wenn ein Skript eben spezifische Funktionen einer Shell benutzt (z. B. $RANDOM - gibt's nur in der Bash und der ZSH), dann sollte man auch diese spezielle Shell als Interpreter angeben. Kritisch sind dabei meist

• Auswertung mathematischer Ausdrücke: mit expr ist man auf der sicheren Seite - $((<Ausdruck>)) funktioniert nicht überall
• Schleifen, insbesondere for-Schleifen in CSH-Syntax (funktionieren zwar in der Bash, aber nicht in ash u. ä.)
• Verwendung von [ anstelle von test => setzt voraus, dass auf dem Zielsystem ein Symlink "[" auf test angelegt wurde (die doppelte eckige Klammer für test ist ZSH-spezifisch und sollte auch nur in Skripten verwendet werden, die zsh als Interpreter nutzen).
• Besondere Variablen wie $RANDOM sind nicht Teil der POSIX-Spezifikation und nur in einigen Shells verfügbar
• Escape-Sequenzen zur Ausgabesteuerung (Farbe, Fettschrift etc.) sind ebenfalls mit Vorsicht zu genießen (können heute aber von den meisten Shells korrekt ausgegeben werden - nur nicht von jedem Terminal, also besser $TERM vorher abprüfen)

Wahrscheinlich müsste ich mich in einigen Fällen selbst erschießen, weil ich Interpreter-spezifische Syntax in Shellskripten verwendet habe - wie sehr man sich an einen Interpreter gewöhnt, habe ich erst gemerkt, als ich auf FreeBSD umgestiegen bin und auf einmal die Hälfte meiner Skripte neu schreiben durfte.

Ich teste meine Skripte meist mit der FreeBSD-Implementierung der Bourne-Shell (eine Weiterentwicklung der ASH). Wer Shell-Skripte unter Linux entwickelt, kann sich ja einfach eine ash oder die Heirloom Bourne Shell installieren (je nachdem, was sich im Paketrepository gerade findet). Wenn das Skript auch damit wie gewünscht läuft, ist es höchstwahrscheinlich POSIX-konform und "verdient" #!/bin/sh als Interpreter-Angabe

P. S. und noch ein kleiner Nachschlag: Auf einigen Systemen würde ein zusätzlicher Interpreter wie die Bash nach /usr/local (FreeBSD) oder /opt (Solaris) installiert. Grundsätzlich wäre es also eine Überlegung wert, den Interpreter nicht mit absolutem Pfad anzugeben, sondern im Python-Stil env zu nutzen:
#!/usr/bin/env bash
z. B. würde auch unter FreeBSD funktionieren, sofern die Bash installiert wurde. Dummerweise gibt es aber auch Linux-Distributionen (Gentoo), die env nicht unter /usr/bin sondern unter /bin ablegen, was die ganze Sache weiter verkompliziert.
Portable Skripte zu schreiben ist halt einfach ein Graus...

[Joe User]

Ich würde POSIX-konforme Shellscripte schreiben, dann lässt sich heutzutage auch gefahrlos /bin/sh verwenden. Die wenigen OS, welche keine POSIX-konforme /bin/sh installieren, haben es verdiehnt, ignoriert zu werden. Ist wie mit XHTML 1.0 und CSS 2 bei Webseiten...

[hahni]

Hab mir vorerst einmal mit "ln -sf /bin/bash /bin/sh" beholfen und werde jetzt noch einmal versuchen, das Setup zum Laufen zu bringen...