AdminTool AdminTool Evolution & Troubleshooting (Part 1)

Status
Für weitere Antworten geschlossen.

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Firmwarebackup

unter Backup/Restore gibt es den Punkt Firmwarebackup, den ich offenbar bisher etwas missverstanden hatte. Ich dachte, es werden Dateien von der Systemplatte gesichert, die nach einem Firmwarebackup evtl. wichtig sind, um den alten Zustand auch unter der neuen Firmwar wieder herzustellen.
Heute habe ich gesehen, dass unter /var/services/ Links zu den Dateien auf Volume1 liegen, wo die ganzen Photos, Musik ... geparkt sind. Das bedeutet praktisch, wenn ich mit so ein "Firmwarebackup" auf eine externe Platte kopiere, dann habe ich dort die ganzen Userdateien von Volume1 mit drauf.
Ist es notwendig, die Ordner unter /var/services/ mit in dieses Firmwarebackup zu packen?

Danke für den Hinweis, das werde ich anschauen. Es sollte eigentlichlich an den Grenzen des sys-Dateisystems ausgebremmst werden.

Itari

PS. Es werden bei mir nur die symbolischen Links kopiert, aber nicht die Daten ... Mach mal einen du in einer Sicherung und schau die Blöcke an.

Bei der Sicherung wird der rsync mit der Option -x verwendet, d. h. 'don't cross filesystem boundaries' und mit der Option -K, d. h. 'keep-dirlinks - treat symlinked dir on receiver as dir'
 
Zuletzt bearbeitet:

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Ich habe mir heute mal die Version 0.9f drauf getan und einen schnellen Blick rauf geworfen.

- auch ich würde es schön finden, wenn die Funktionsleiste sich die letzte Position (links/rechts) merken würde, oder die Startposition einstellbar ist
- unter Disk/smart ist jetzt nicht mehr die SEite mit dem Diagramm als erstes zu sehen, sondern die SMART Daten. Das finde ich für User, die keinen cron laiufen lassen, um die Temp. Daten abzufragen besser
- Admin Toll ist auch im Browser Chrome gestartet. Zufall, oder Änderung, oder Update bei Chrome?

Einige Sachen auf der ToDo Liste könnten auch für mich sehr interessiant sein.

Wieder mal Danke -> Itari

Man kann jetzt die Position durch den Zusatz ?left im URL-Aufruf steuern (steht im Change-Log); ich denke, dass das komfortabel ist. Ich bin nicht so sehr ein Freund, sowas in Cookies unterzubringen ...

Das mit den SMART-Daten (und auch noch an ein paar anderen Stellen) habe ich gemacht, damit man beim Starten nicht auf das Erstellen der Diagramme warten muss ... ist also eine Beschleunigungsmaßnahme.

Chrome ging bei mir eigentlich schon immer ... manchmal verschluckt er sich halt an der Authentifizierung ... aber ansonsten ist Chrome eigentlich immer nett zum AdminTool gewesen.

Schön, dass die das AdminTool immer noch gefällt und danke für die 'Blumen' :)

Itari
 

Herbert_Testmann

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
1.114
Punkte für Reaktionen
1
Punkte
64
PS. Es werden bei mir nur die symbolischen Links kopiert, aber nicht die Daten ... Mach mal einen du in einer Sicherung und schau die Blöcke an.

Bei der Sicherung wird der rsync mit der Option -x verwendet, d. h. 'don't cross filesystem boundaries' und mit der Option -K, d. h. 'keep-dirlinks - treat symlinked dir on receiver as dir'

In den Firmwarebackups selbst, sind symbolische Links. Ansonsten würde die Erstellung des ersten Backups ja auch ewig dauern.
Nun klicke ich im Admintool unter Firmwarebackup (oder Tools/Explorer - ist egal) mit der rechten Maustaste auf einen Ordner und wähle "kopieren" (cp -r ??). Dann geht ein Fenster mit dem Ziel auf. Dort trage ich /volumeSATA/firmwarebackup/namedesBackupOrdners ein. Dann werden nicht die symbolischen links kopiert, sondern die wirklichen Dateien.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
In den Firmwarebackups selbst, sind symbolische Links. Ansonsten würde die Erstellung des ersten Backups ja auch ewig dauern.
Nun klicke ich im Admintool unter Firmwarebackup (oder Tools/Explorer - ist egal) mit der rechten Maustaste auf einen Ordner und wähle "kopieren" (cp -r ??). Dann geht ein Fenster mit dem Ziel auf. Dort trage ich /volumeSATA/firmwarebackup/namedesBackupOrdners ein. Dann werden nicht die symbolischen links kopiert, sondern die wirklichen Dateien.

Das mit dem cp -r ist richtig. Soll ich da ein cp -xr einbauen? (x = stay on this file system). Oder was schlägst du vor?

Itari
 

Herbert_Testmann

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
1.114
Punkte für Reaktionen
1
Punkte
64
Das mit dem cp -r ist richtig. Soll ich da ein cp -xr einbauen? (x = stay on this file system). Oder was schlägst du vor?

Itari

Ich weiss nicht, was bei -xr passiert.

Ich denke mal, die symbolischen Links sollen auch solche bleiben beim kopieren.

Wenn ich das 6. Firmwarebackup auf eine externe Platte sichere, sollen aber alle ini Dateien wirklich da sein, auch wenn die sich seit dem 2.Backup nicht geändert haben. Das wird wohl nicht gehen?? Entweder - oder.

Kann man das betroffene Verzeichnis /var/services/ mit den Links zu /volume1/... nicht ausnehmen? Sicher schwierig ...
 

Neverland

Benutzer
Mitglied seit
28. Mrz 2010
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
!adm verweist auf nicht mehr vorhandenes Volume1

Hi Itari,

ich versuchte nach Festplattenaufrüstung und Umstellung auf RAID5 das Admin-Tool auf meiner DS 409 erneut zu installieren.
Die Installation läuft anscheinend ohne Fehler ab, die Admin-Tools werden aber unter "Thirt-party applictions" nicht mehr angezeigt (Angezeigt wird nur PHP-Info).
Die installieren Tools liegen auf dem einzig vorhandenen Volume (Volume3). Der Eintrag !adm im Dateiverzeichnis verweist aber auf Volume1 "adm -> /volume1/@appstore/adm". Im Volume1 waren die Tools früher mal installiert.
De- und wiederholte Neuinstallation brachten keine Änderung. Wie kann ich diesen Verweis erfolgreich ändern bzw. erfolgreich neuinstallieren ?

Gruß
Neverland
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
14
Punkte
84
Du kannst einen neuen Eintrag anlegen, zuvor den alten Eintrag löschen.
Dann auf der Shell mit
ln -s /volume3/@appstore/adm /usr/syno/synoman/webman/3rdparty/adm
den neuen Eintrag anlegen. Dieser sollte nun auf dein installiertes AdminTool-Paket auf volume3 verweisen und nach einem Refresh des DSM auch unter 3rdparty angezeigt werden.
Du soltest aber vermeiden, im Paketmanager Start/Stop auszuführen, denn dann wird das was im Script definiert ist eingestellt und das ist leider zur Zeit immer /volume1. Evtl. ändert itari das ja wieder ab.

*EDIT*
@itari
für dein Problem mit den verschiedenen volumes im Start/Stop-Script hab ich eine Idee, wie du den Pfad ohne die Installationsvariablen rausbekommst:
Rich (BBCode):
#!/bin/sh
LOG="/var/packages/adm/log"
PACKAGEDEST=`/bin/ls -l /var/packages/adm/target | /usr/bin/cut -d ">" -f 2`
case $1 in
start) ln -s $PACKAGEDEST /usr/syno/synoman/webman/3rdparty/adm; date +'%c started' >> $LOG ;;
stop)  rm /usr/syno/synoman/webman/3rdparty/adm; date +'%c stopped' >> $LOG ;;
status)    if tail -1 $LOG | grep stopped; then exit 1; else exit 0; fi ;;
log) echo "$LOG" ;;
esac
/var/packages ist immer gleich und dort liegt der symbolische Link target. Dieser zeigt auf /volume(x)/@appstore/adm ;)
In postinst musst dann natürlich wieder variabel mit $SYNOPKG_PKGDEST arbeiten.
 
Zuletzt bearbeitet:

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Hi ihr beiden,

das Problem ist erst vor kurzem (Firmware 9xx oder 10xx ???) aufgetreten, dass die bislang zur Verfügung gestellen Umgebungsvariabeln nicht mehr richtig greifen. Deswegen hatte ich beschrieben, dass ich das Installations-Skript mit festen Pfaden ausgestattet hatte. Und bislang hat das ja auch nicht zu einem Problem geführt. Aber nun soll es wohl sein, dass ich mich um das Problem kümmern muss ... :(

Anscheinend arbeitet der neue Paketmanager anders als früher und macht einige Dinge selbstständig. Hat jemand ein Analyse der Skripte schon durchgeführt, wie Synology das jetzt handhabt? Mail-Package oder was anderes Intelligentes? Hat jemand eine Auflistung aller Shellvariablen? Muss man die Links noch alles selbst setzen?

Itari
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Ich kann Version 0.9f nicht mehr deinstallieren?!? Erst steht da ziemlich lange "Verarbeitung läuft" und dann bekomme ich ein "Vorgang fehlgeschlagen".
Woran kanns liegen?
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Ich kann Version 0.9f nicht mehr deinstallieren?!? Erst steht da ziemlich lange "Verarbeitung läuft" und dann bekomme ich ein "Vorgang fehlgeschlagen".
Woran kanns liegen?

Die 0.9f nicht deinstallieren !!!
Auf weitere Anweisungen warten. Verlust von Mediendateien möglich !!!

Itari
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0

Die 0.9f nicht deinstallieren !!!
Auf weitere Anweisungen warten. Verlust von Mediendateien möglich !!!

Itari

Problembeschreibung:

Wenn in das AdminTool in das Verzeichnis /volume1/@appstore/adm installiert wurde, dann legt die Version 0.9f ein Verzeichnis var an und verlinkt dort auf das Verzeichnis /var/services:
Rich (BBCode):
Synology> ll /volume1/@appstore/adm/var
drwxrwxrwx    2 root     root         4096 Apr 14 08:22 .
drwxrwxrwx    8 root     root         4096 Apr 13 16:22 ..
lrwxrwxrwx    1 root     root           13 Apr 14 08:22 services -> /var/services
Der Grund hierfür ist, auf die Mediendateien zugreifen zu können, um einen Preview zu ermöglichen.

Um auf eventuelle im AdminTool angelegte Konfigurationsdateien auch nach der Deinstallation zugreifen zu können, wurde ab der Version 0.6a eine Kopie des Verzeichnisses /volume1/@appstore/adm nach /volume1/@appstore/adm.bak eingeführt. Durch den Link auf die /var/services werden dabei auch alle Dateien von /var/services kopiert und dies kann sehr lange dauern und dabei auch die Platte zu müllen. Ich habe schlicht vergessen in dem Deinstallation-Skript vorher den Link zu entfernen.

Lösung:


Durch diese Tatsache ergeben sich jetzt 2 Möglichkeiten (es ist jetzt sehr wichtig, das zu verstehen, denn es geht um viele Daten):

1] der Kopiervorgang bei der Deinstallation konnte nicht vollständig durchgeführt werden, weil zu wenig Platz auf der Platte war und die Deinstallation ist abgebrochen. Dann müssten im Verzeichnis /var/services noch alle Unterverzeichnisse vorhanden sein und man kann seine Platte wieder 'entleeren', in dem man die Dateien im Verzeichnis /volume1/@appstore/adm.bak/var/services löscht. Bevor man das allerdings tut, sollte man sich auch wirklich vergewissern, ob die Mediendateien, Webdateien, Datenbanken usw. auch wirklich noch vollständig vorhanden sind.

2] der Kopiervorgang bei der Deinstallation konnte vollständig durchgeführt werden. Dann steht im Verzeichnis /volume1/@appstore/adm.bak/var/services eine komplette Kopie des Verzeichnisses /var/services. Möglicherweise sind allerdings vorhandene Links (symbolische Links und Hardlinks) aufgelöst worden und statt dessen stehen da normale Datendateien.

Da nach dem Kopiervorgang das Verzeichnis /volume1/@appstore/adm durch die Deinstallation gelöscht wird, sind damit durch den oben beschriebenen Link auch alle Dateien von /var/services mit gelöscht worden. (Nachschauen !!!)

Wenn die Dateien unter /var/services gelöscht wurden, dann existieren sie immer noch im Verzeichnis /volume1/@appstore/adm.bak (!!!) und man könnte sie jetzt zurück kopieren. Wenn man von seinen Benutzerdaten eine Sicherung hat, kann man alternativ auch die Firmware neu einspielen und einen Restore durchführen. Wer vor dieser Entscheidung stehen sollte, kann mir aber auch eine IM schicken und wir beratschlagen das.

Alle andere, die die Version 0.9f (oder auch die 0.91) haben, müssen vor der Deinstallation (und nur dann !!!), den potentiell gefährlichen Link via telnet oder ssh manuell löschen. Dabei darf das AdminTool nicht aufgerufen sein, denn es rekonstruiert diesen Link sofort wieder. Und natürlich darf auch das AdminTool nach der Löschung des Links auch nicht mehr aufgerufen werden.

Rich (BBCode):
rm /volume1/@appstore/adm/var/services

Ich werde im Laufe des Tages eine neue Version des AdminTools zum Download einstellen, die dann jeder, der die 0.9f oder 0.91 installiert hat, installieren sollte, damit die 0.9f bzw. 0.91 dann keine Probleme mehr für die Zukunft darstellen.

Sorry für die Unannehmlichkeiten.

Itari
 
Zuletzt bearbeitet:

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Hmm - obwohl die Deinstallation bei mir die Meldung "Vorgang fehlgeschlagen" produziert hat (wahrscheinlich wurde die maximale Skriptlaufzeit überschritten) liefen die copy-Prozesse im Hintergrund noch weiter. Ich muss jetzt mal nachsehen, was da genau passiert ist...

UPDATE: So. Ich hab meine DS mal neu gestartet und damit die copy-Prozesse beendet. Glück gehabt - er war noch nicht ganz durch. Hat aber wohl nicht mehr viel gefehlt. Ich bin jetzt beim Löschen...
 
Zuletzt bearbeitet:

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Hmm - obwohl die Deinstallation bei mir die Meldung "Vorgang fehlgeschlagen" produziert hat (wahrscheinlich wurde die maximale Skriptlaufzeit überschritten) liefen die copy-Prozesse im Hintergrund noch weiter. Ich muss jetzt mal nachsehen, was da genau passiert ist...

UPDATE: So. Ich hab meine DS mal neu gestartet und damit die copy-Prozesse beendet. Glück gehabt - er war noch nicht ganz durch. Hat aber wohl nicht mehr viel gefehlt. Ich bin jetzt beim Löschen...

Hast dich aber auch vergewissert, dass die Daten unter /var/services (und da sind symbolische Links drinne, denen man natürlich folgen muss) noch alle vorhanden sind, oder?

Itari
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Package-Skripte update

Ich habe auch die Idee von QTip eingebaut (ein paar Posts weiter oben). Vielleicht kann ja noch jemand drüberschauen ... ist ja recht sensibel.

start-stop-status:

Rich (BBCode):
#!/bin/sh
LOG="/var/packages/adm/log"
PACKAGEDEST=`ls -l /var/packages/adm/target | awk '{print $11}'` # mostly /volume1/@appstore/adm
case $1 in
start) ln -s $PACKAGEDEST /usr/syno/synoman/webman/3rdparty/adm; date +'%c started' >> $LOG ;;
stop)  rm /usr/syno/synoman/webman/3rdparty/adm; date +'%c stopped' >> $LOG ;;
status)	if tail -1 $LOG | grep stopped; then exit 1; else exit 0; fi ;;
log) echo "$LOG" ;;
esac

preuninst:

Rich (BBCode):
#!/bin/sh
PACKAGEDEST=`ls -l /var/packages/adm/target | awk '{print $11}'` # mostly /volume1/@appstore/adm
rm $PACKAGEDEST/var/services
cp -Rf $PACKAGEDEST $PACKAGEDEST.bak
exit 0

postinst:

Rich (BBCode):
#!/bin/sh
LOG="/var/packages/adm/log"
PACKAGEDEST=`ls -l /var/packages/adm/target | awk '{print $11}'` # mostly /volume1/@appstore/adm
ln -s $PACKAGEDEST /usr/syno/synoman/webman/3rdparty/adm
date +'%c installed' >> $LOG
date +'%c started' >> $LOG

postuninst und preinst:

Rich (BBCode):
#!/bin/sh
exit 0

Itari
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Hast dich aber auch vergewissert, dass die Daten unter /var/services (und da sind symbolische Links drinne, denen man natürlich folgen muss) noch alle vorhanden sind, oder?
Klar. Hab ich. Und zur Not ist ja eh noch ein Backup vorhanden...
 

der-krueger

Benutzer
Mitglied seit
13. Apr 2010
Beiträge
25
Punkte für Reaktionen
0
Punkte
0
Hi Itari,

hatte gestern die Version 0.91 installiert und abends wieder deinstalliert. Dabei trat der selbe Effekt auf wie Du ihn für die Deinstallation der Version 0.9f beschrieben hast. Nur zur Info das sich dieses Problem nicht nur bei der 0.9f auftrifft sondern auch bei der 0.91.

Gruss,
UKr
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Hi Itari,

hatte gestern die Version 0.91 installiert und abends wieder deinstalliert. Dabei trat der selbe Effekt auf wie Du ihn für die Deinstallation der Version 0.9f beschrieben hast. Nur zur Info das sich dieses Problem nicht nur bei der 0.9f auftrifft sondern auch bei der 0.91.

Gruss,
UKr

Richtig. Das Problem ist erst mit der 0.91a behoben.

Itari
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
14
Punkte
84
Hi ihr beiden,

das Problem ist erst vor kurzem (Firmware 9xx oder 10xx ???) aufgetreten, dass die bislang zur Verfügung gestellen Umgebungsvariabeln nicht mehr richtig greifen. Deswegen hatte ich beschrieben, dass ich das Installations-Skript mit festen Pfaden ausgestattet hatte. Und bislang hat das ja auch nicht zu einem Problem geführt. Aber nun soll es wohl sein, dass ich mich um das Problem kümmern muss ... :(

Anscheinend arbeitet der neue Paketmanager anders als früher und macht einige Dinge selbstständig. Hat jemand ein Analyse der Skripte schon durchgeführt, wie Synology das jetzt handhabt? Mail-Package oder was anderes Intelligentes? Hat jemand eine Auflistung aller Shellvariablen? Muss man die Links noch alles selbst setzen?

Itari
Hier meine Ergebniss nach einem SPK Test. Die Variablen wurden zur Laufzeit einer Installation, Aktualisierung, Deinstallation und Neustart der DS geschrieben.
Zu sehen sind die Variablen und wo man sie verwenden kann bzw. wo sie Inhalt haben. Die Reihenfolge entspricht der Ausführung der Skripte. Man kann so sehr schön sehen, in welcher Reihenfolge die Skripte abgearbeitet werden.
Für den Start/Neustart Test habe ich mal meinen Lösungsansatz (PACKAGEDEST=`/bin/ls -l /var/packages/spktest/target | /usr/bin/cut -d ">" -f 2`) eingebaut.

Erklärung:
1. Segment ist der volle Pfad/Name des Scripts
2. Segment ist der Variablenname
3. Segment ist der Inhalt der Variable (wenn verfügbar)

Installation:
Rich (BBCode):
/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_PKGNAME = spktest
/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_PKGDEST = 
/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy

/var/packages/spktest/scripts/postinst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postinst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postinst - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy

/var/packages/spktest/scripts/postupgrade - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postupgrade - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postupgrade - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy
Aktualisierung:
Rich (BBCode):
/volume1/@tmp/pkginstall/scripts/preupgrade - SYNOPKG_PKGNAME = spktest
/volume1/@tmp/pkginstall/scripts/preupgrade - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/volume1/@tmp/pkginstall/scripts/preupgrade - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy

/var/packages/spktest/scripts/preuninst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/preuninst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/preuninst - SYNOPKG_TEMP_LOGFILE = 

/var/packages/spktest/scripts/postuninst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postuninst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postuninst - SYNOPKG_TEMP_LOGFILE = 

/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_PKGNAME = spktest
/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_PKGDEST = 
/volume1/@tmp/pkginstall/scripts/preinst - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy

/var/packages/spktest/scripts/postinst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postinst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postinst - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy

/var/packages/spktest/scripts/postupgrade - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postupgrade - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postupgrade - SYNOPKG_TEMP_LOGFILE = /volume1/@tmp/mufoxvytboszrjsy
Deinstallation:
Rich (BBCode):
/var/packages/spktest/scripts/preuninst - preuninst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/preuninst - preuninst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/preuninst - preuninst - SYNOPKG_TEMP_LOGFILE = 

/var/packages/spktest/scripts/postuninst - postuninst - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/postuninst - postuninst - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/postuninst - postuninst - SYNOPKG_TEMP_LOGFILE =
Start:
Rich (BBCode):
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_TEMP_LOGFILE = 
/var/packages/spktest/scripts/start-stop-status - PACKAGEDEST =  /volume1/@appstore/spktest
Stop:
Rich (BBCode):
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_TEMP_LOGFILE =
Status:
Rich (BBCode):
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGNAME = spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_PKGDEST = /volume1/@appstore/spktest
/var/packages/spktest/scripts/start-stop-status - SYNOPKG_TEMP_LOGFILE =
Neustart der DS:
Rich (BBCode):
/usr/local/etc/rc.d/spktest.sh - SYNOPKG_PKGNAME = 
/usr/local/etc/rc.d/spktest.sh - SYNOPKG_PKGDEST = 
/usr/local/etc/rc.d/spktest.sh - SYNOPKG_TEMP_LOGFILE = 
/usr/local/etc/rc.d/spktest.sh - PACKAGEDEST =  /volume1/@appstore/spktest
@itari
Der symbolische Link wird übrigens nicht automatisch erzeugt.
Schau dir mal mein ddnsupdater.spk an, dann kannst dir dort mal angucken, wie ich das mit der Aktualisierung mache.
Mir ist nochwas aufgefallen: Du wolltest doch bei deinem AdminTool, dass man mittels Start/Stop den Link zu dem 3rdparty Baum setzen und entfernen kann, stimmts? Da ist aber noch ein Haken: Der Paketmanager merkt sich nicht, welches Skript gestartet wurde. Deshalb muss man dies selber im Start-Stop-Skript erledigen. So wie du es eingebaut hattest/hast wird der Link bei jedem Hochfahren erstellt, egal ob das Skript vorher gestartet wurde oder nicht. Auch dieses Problem habe ich im ddnsupdater behoben, siehe Start-Stop-Skript.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Mir ist nochwas aufgefallen: Du wolltest doch bei deinem AdminTool, dass man mittels Start/Stop den Link zu dem 3rdparty Baum setzen und entfernen kann, stimmts? Da ist aber noch ein Haken: Der Paketmanager merkt sich nicht, welches Skript gestartet wurde. Deshalb muss man dies selber im Start-Stop-Skript erledigen. So wie du es eingebaut hattest/hast wird der Link bei jedem Hochfahren erstellt, egal ob das Skript vorher gestartet wurde oder nicht. Auch dieses Problem habe ich im ddnsupdater behoben, siehe Start-Stop-Skript.

Hi, das sind interessante Infos :)

Ich wusste gar nicht, dass es jetzt auch den Upgrade gibt. Wie aktiviert man den?

Die Datei 'enabled' in den jeweilgen Package-Verzeichnissen (/var/packages) wird bei mir jeweils beim Starten erzeugt und beim Stoppen wieder gelöscht. Kann man die irgendwie in die Ein-/Ausschaltlogik des Start-Stop-Skripts einbeziehen?

Itari
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
14
Punkte
84
ja klar, schau in mein ddnsupdater Paket, da hab ich das ebenfalls so realisiert.
Kurz ausgedrückt, du musst beim starten das Vorhandensein der Datei "enabled" abfragen und entsprechend reagieren.
Auszug:
Rich (BBCode):
#!/bin/sh
LOG="/var/packages/${SYNOPKG_PKGNAME}/log"
DDNSEnabled="/var/packages/ddnsupdater/enabled"

case $1 in
start)
     if [ ! -f "$DDNSEnabled" ]; then
    exit;
     fi
     date +'%c started' >> $LOG
     cd /usr/syno/synoman/webman/3rdparty/ddnsupdater
    ./ddnscmd.sh start
;;
stop)
     if [ -f "$DDNSEnabled" ]; then
        exit;
     fi
     date +'%c stopped' >> $LOG
     cd /usr/syno/synoman/webman/3rdparty/ddnsupdater
     ./ddnscmd.sh stop
;;
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat