[Erl.]SVN- und IPKG-Probleme nach Firmwareaktualisierung 3.6

  • Hallo QNAPler,


    ich habe seit mehreren Jahren einen QNAP (TS-419T) bei dem ich einen svn-Server via ipkg installiert habe. Prinzipiell ist das nach dem gleichen Schema eingerichtet, wie in Subversion auf einem QNAP TS-409 PRO.


    Seit Firmware 3.6.0 Build 0210T habe ich allerdings zwei Ungereimtheiten. Ich habe mich an den QNAP-Support gewendet und da meinte man, dass es sich womöglich um Software eines Drittanbieters handelt und man mir da nicht zufriedenstellend weiterhelfen kann (will).

    Zitat

    Bitte im Forum http://www.qnapclub.de nach weiteren Informationen stöbern.


    Hier nochmal meine Probleme:
    Ich hatte über SSH (Putty) mittels ipkg u.a. nano und svn installiert.
    Sind die durch ipkg installierten Programme eigentlich nach Firmwareaktualisierung weg?
    Bei den vorherigen Updates war ich der Auffassung, dass auch danach alles noch vorhanden war.


    Zunächst wollte ich Folgendes ausführen:

    Code
    [~] # ipkg updateDownloading http://ipkg.nslu2-linux.org/feeds/optware/tsx19/cross/unstable/PackagesDownloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gzInflating http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gzUpdated list of available packages in /opt/lib/ipkg/lists/cs08q1armelAn error ocurred, return value: 1.Collected errors:ipkg_download: ERROR: Command failed with return value 1: `wget --passive-ftp    -q -P /opt/ipkg-SlpfQH http://ipkg.nslu2-linux.org/feeds/optware/tsx19/cross/unstable/Packages'


    Pingen von Webseiten funktioniert ohne Probleme. Was ich etwas seltsam finde, in der Hilfe von wget gibt es überhaupt keine Option "--passive-ftp" sondern nur "--no-passive-ftp" und die letzte angezeigte URL gibt es nicht mehr.
    In /opt/etc/ipkg/tsx19-kmod.conf gibt es eine Zeile mit dem Link. Die Zeile habe ich einfach mal auskommentiert. Danach war zumindest die Fehlermeldung weg. Aber so wirklich sicher bin in mir nicht, ob das sinnvoll ist.
    In /opt/etc/ipkg.conf ist bei mir alles auskommentiert.


    SVN (1.6.17) konnte ich deswegen trotzdem erneut installieren:

    Code
    ipkg install svn


    Da wir den QNAP zu Hause rein privat nutzen und auch nicht täglich, schalte ich diesen meist abends aus. Der SVN-Server soll deshalb natürlich beim Einschalten automatisch starten.


    Ich hatte dafür in der /etc/config/qpkg.conf einfach noch einen Subversion-Eintrag eingefügt:

    Code
    [subversion svnserve]Name = Subversion-svnserveVersion = 1.6.17Enable = TRUEQPKG_File = -Date = 2012-02-15Shell = /share/MD0_DATA/svn/svn.shInstall_Path = /share/MD0_DATA/svnAuthor = Thomas[Optware]Name = OptwareVersion = 0.99.163Enable = TRUEQPKG_File = Optware.qpkgDate = 2012-02-22Shell = /share/MD0_DATA/.qpkg/Optware/Optware.shInstall_Path = /share/MD0_DATA/.qpkg/OptwareAuthor = QNAP Systems, Inc.


    Mein svn.sh Script sieht so aus:

    Bash
    #!/bin/shSVNSERVE=/opt/bin/svnservePARAMS="-d"PORT=""SVN_REPOS_PATH="-r /share/svn"CONFIG_FILE=""test -f $SVNSERVE || exit 0case "$1" in    start)        echo -n "Starting svnserve services: "        $SVNSERVE $PARAMS $PORT $SVN_REPOS_PATH $CONFIG_FILE        echo " svnserve started."        ;;    stop)        echo -n "Shutting down svnserve:"        /usr/bin/killall svnserve        echo " svnserve stopped."        ;;    restart)        $0 stop        $0 start        ;;    *)        echo "Usage: svn.sh (start|stop|restart)"        exit 1esacexit 0


    Anmerkungen:

    • Bei mir heißt die Datei svn.sh, hier im Forum steht bei den Anleitungen startsvn.sh. Scheint aber prinzipiell das Gleiche zu sein.
    • /share/svn bzw. /share/MD0_DATA/svn ist ein versteckter Freigabeordner, den ich mittels Weboberfläche erstellt habe und alle SVN-Repositories beinhaltet.


    Das funktionierte auch in den Firmware-Versionen zuvor reibungslos, doch seit Version 3.6 habe ich Probleme. Mit dmesg habe ich keine nützlichen Infos gefunden. Die Pfade habe ich alle zu svn.sh und svnserve kontrolliert, die passen. Laut den Prozessen (ps) wird svnserve nicht gestartet.


    Manuell starten geht:

    Code
    [~] # /share/MD0_DATA/svn/svn.sh startStarting svnserve services:  svnserve started.


    Ein Link auf svn.sh ist zusätzlich in /etc/init.d/ gesetzt (weiß gar nicht mehr warum, zu lange her...):

    Code
    [~] # ls -l /etc/init.d/svn.sh
    lrwxrwxrwx    1 admin    administ       26 Feb 23 16:39 /etc/init.d/svn.sh -> /share/MD0_DATA/svn/svn.sh*


    Auch darüber lässt sich der SVN-Server starten und ein Zugriff über die Netzwerk-Clients ist möglich (TortoiseSVN).


    Ich bin überfragt, wie ich den Autostart wieder hinbekomme. Brauche den SVN für meine Projekte ständig und ein QPKG gibt es nicht. Jedes Mal über SSH manuell starten ist sicherlich keine Dauerlösung.
    Hat sich bei der automatischen Ausführung der in der qpkg.conf eingetragenen Skripte etwas geändert?
    Habt Ihr einen Tipp, wie ich den automatischen Start wieder herstellen kann, sodass das auch nach Firmware-Updates funktioniert? Oder gibt es eine Log-Möglichkeit, was da beim Start schief läuft?


    Gruß
    Thomas

  • Hallo Thomas,


    ich stehe mittlerweile vor dem gleichen Problem. Ich habe das Script zum Autostart aus dem Forum genutzt aber es klappt nicht nur wenn ich das manuell starte, geht es. Hast du eine Lösung?


    Gruß


    Malte

  • Hallo zusammen,


    sorry Malte, dass ich deinen Beitrag nicht mehr gelesen habe. Leider habe ich auch 2013 noch keine Lösung.


    Da mich jemand drauf angesprochen hat, habe ich nochmal Optware deinstalliert und anschließend svn neu installiert.
    Das svn.sh Script habe ich noch etwas angepasst. Ich bin kein Script-Profi und vom Qnap-System habe ich kaum Ahnung, aber zumindest wird jetzt was ins Systemprotokoll (Weboberfläche) geschrieben.


    Bash
    #!/bin/shSVNSERVE=/opt/bin/svnservePARAMS="-d"PORT=""SVN_REPOS_PATH="-r /share/svn"CONFIG_FILE=""#Wait for svnservecounter=1while truedo    if [ -f $SVNSERVE ];    then        break    elif [ $counter -gt 5 ];    then        /sbin/log_tool -t 1 -a "Subversion could not be found"        exit 0    fi    counter=$((counter+1))    sleep 5donecase "$1" in    start)	echo -n "Starting svnserve services: "        $SVNSERVE $PARAMS $PORT $SVN_REPOS_PATH $CONFIG_FILE        echo " svnserve started."	/sbin/log_tool -t 0 -a "Subversion started"        ;;    stop)        echo -n "Shutting down svnserve:"        /usr/bin/killall svnserve        echo " svnserve stopped."	/sbin/log_tool -t 0 -a "Subversion stopped"        ;;    restart)        $0 stop        $0 start        ;;    *)        echo "Usage: svn.sh (start|stop|restart)"        exit 1esacexit 0


    Wenn ich das manuell per SSH (Putty) starte, funktioniert alles reibungslos. Es erscheint "Subversion started" bzw. "Subversion stopped".
    Beim Neustart vom Qnap bekomme ich auch eine Ausgabe, allerdings nur "Subversion could not be found".
    Aus irgendeinem Grund findet der /opt/bin/svnserve nicht.


    Auf dieser Seite habe ich etwas über "Fix the $PATH in /etc/profile" gelesen. Das klingt plausibel. Wie dort beschrieben habe in der Optware.sh folgendes geändert:

    Code
    [ $? -ne 0 ] && /bin/echo "export PATH=$PATH":/opt/bin:/opt/sbin >> /etc/profile


    ersetzt durch:

    Code
    [ $? -ne 0 ] && /bin/echo "export PATH=/opt/bin:/opt/sbin:\$PATH" >> /etc/profile


    Nachdem ich allerdings den Qnap neu gestartet habe und mir mit echo $PATH die Umgebungsvariable angeschaut habe, stellte ich fest, dass die Änderung nicht funktioniert hat. Scheinbar wird da beim Start die Optware.sh wieder überschrieben.


    Aus heutiger Sicht stellt sich mir die Frage: Gibt es einen Trick, damit beim Systemstart /opt/bin/svnserve wieder gefunden wird?


    Eigentlich bin ich stinksauer, weil das mal funktioniert hat und die Probleme erst mit der damals genannten neuen Version los gingen. Der Qnap-Support ist in meinen Augen ein schlechter Scherz, man wird ja fast als Depp hingestellt bzw. erhält nutzlose Kommentare "...bezieht sich womöglich auf Settings oder die Konfiguration der Software eines Drittanbieters...".
    Sorry man kann halt nicht alles wissen, zumal mal die Interna des Qnap-Systems nicht kennt. Bzgl. der Logging-Möglichkeiten schrieb man mir damals

    Zitat

    Sie können einen Monitor an den VGA-Anschluss Ihres NAS schließen und so das Bootszenario mitlesen


    Es hat sich scheinbar zum Support nicht rumgesprochen, dass der TS-419T gar keinen solchen Anschluss hat (peinlich...)! Mittlerweile habe ich das mit der log_tool-Möglichkeit im Internet entdeckt.


    Naja egal, sei wie es ist. Ich hoffe die Community hat vielleicht noch ein paar Tipps für mich ;)


    Viele Grüße
    Thomas



    ---Edit---



    Guten Abend,


    nachdem ich meine Qnap-Kiste gerade von Version 3.8 auf 4.0.2 aktualisiert und Optware nochmal neu installiert habe, funktionierte der automatische Start des SVN-Server leider immer noch nicht.


    Mir ist dann jedoch aufgefallen, dass in der qpkg.conf der [Optware] Eintrag wieder ganz unten angefügt wird und mein manuell eingefügter [Subversion] Eintrag weiter oben steht. Ich habe das jetzt einfach mal rumgedreht und den Qnap mehrfach neugestartet. Jetzt scheint es zu funktionieren. :mrgreen:


    Somit nehme ich an, dass ab Version 3.6.0 die Reihenfolge von Optware und Subversion in der qpkg.conf entscheidend ist. Scheinbar muss zuerst die Optware.sh ausgeführt werden. In den älteren Versionen spielte das definitiv keine Rolle.


    Gruß
    Thomas

    2 Mal editiert, zuletzt von bladekiller () aus folgendem Grund: Editierfunktion nutzen und doppelte Beiträge vermeiden, siehe Forenregeln!