AutoPilot AutoPilot für externe Datenträger

[Tommes]

AutoPilot für externe Datenträger​

AutoPilot ermöglicht das Ausführen von beliebigen Shellscript Anweisungen, die nach dem Anschluss eines externen Datenträgers an deine Synology DiskStation automatisch ausgeführt werden. Vorhandene Basic Backup Aufträge sowie Hyper Backup Aufgaben (ab Version 4) werden dabei in AutoPilot übersichtlich angezeigt und lassen sich mit bereits vorkonfigurierten Shellscripts verbinden und somit ebenfalls ausführen. Nach der Ausführung kann der externe Datenträger auf Wunsch wieder automatisch ausgeworfen werden.

Einen externen Datenträger einrichten​

Zur späteren Identifizierung eines externen Datenträgers wird in einer Ersteinrichtung die UUID (Universally Unique Identifier) der ausgewählten Partition bzw. des sich darauf befindlichen Dateisystems ausgelesen. Anschließend wird eine leere Datei mit dem Namen autopilot (ohne Dateiendung) im Wurzelverzeichnis der zuvor ausgewählten Partition abgelegt. Im nächsten Schritt muss der Name und der Speicherort des auszuführenden Shellscripts angegeben werden, welches sich idealerweise in einem gemeinsamen Ordner der DiskStation befinden sollte. Abschließend wird die so ermittelte UUID mit den Angaben zum Shellscript fest miteinander verknüpft und intern gespeichert. Damit ist die Ersteinrichtung abgeschlossen.

So funktioniert AutoPilot genau​

AutoPilot nutzt, wie weiter oben bereits beschrieben, die UUID der ausgewählten Partition bzw. des sich darauf befindlichen Dateisystems eines externen Datenträgers zur eindeutigen Identifikation. Die so ermittelte UUID wird im dem, von Synology bereitgestellten AutoPilot Paketordner in Form eines Dateinamens abgespeichert und ist somit vor fremden Zugriff weitestgehend geschützt. In dieser Datei wird im Anschluss der Pfad und der Dateiname des eigentlich auszuführenden Shellscripts als Variable hinterlegt. Das Shellscript selbst sollte sich dabei innerhalb der Ordnerstruktur eines gemeinsamen Ordners der DiskStation befinden um diese ebenfalls vor fremden Zugriff zu schützen. Es besteht zwar die Möglichkeit, das Shellscript auf dem externen Datenträger selbst zu hinterlegen, jedoch wird aus Sicherheitsgründen davon abgeraten.

Der so präparierte externe Datenträger wird zukünftig beim anschließen an deine Synology DiskStation durch AutoPilot eindeutig identifiziert. Dabei durchsucht eine sogenannte UDEV-Regel in allen vorhandenen Partitionen des externen Datenträger nach der leeren Datei autopilot. War die Suche erfolgreich, wird die ermittelte UUID des extern angeschlossenen Datenträgers mit der intern gespeicherten UUID verglichen und bei Übereinstimmung mit dem damit verknüpften Shellscript verbundenen und ausgeführt. Durch dieses Vorgehen ist sichergestellt, das über den externen Datenträger kein Schadcode in Verbindung mit AutoPilot ausgeführt werden kann.

Systemvoraussetzungen​

AutoPilot wurde speziell für die Verwendung auf Synology NAS Systemen entwickelt die das Betriebsystem DiskStation Manager 7 oder höher verwenden.

Installationshinweise​

Lade dir die jeweils aktuellste Version von AutoPilot aus meinem GitHub Repository herunter. Öffne anschließend im DiskStation Manager (DSM) das Paket-Zentrum, wähle oben rechts die Schaltfläche "Manuelle Installation" aus und folge dem Assistenten, um das neue Paket bzw. die entsprechende .spk-Datei hochzuladen und zu installieren. Dieser Vorgang ist sowohl für eine Erstinstallation als auch für die Durchführung eines Updates identisch.

Nach dem ersten Start von AutoPilot wird die lokal installierte Version mit der auf GitHub verfügbaren Version verglichen. Steht ein Update zur Verfügung, wirst du innerhalb AutoPilot darüber informiert und es wird ein entsprechender Link zu dem entsprechenden Release eingeblendet. Der Download sowie der anschließende Update-Vorgang verläuft wiederum analog zur oben beschriebenen Erstinstallation.

Weitere, detailliertere Hinweise zur Installation und Konfiguration findest du in der README.md meines GitHub Repository unter dem Punkt Installationshinweise. Innerhalb AutoPilot werden dir zudem alle nötigen sowie empfohlenen Konfigurationseinstellungen in der „Systemumgebung“ angezeigt und erklärt, wie du diese aktivieren oder ggfl. auch deaktivieren kannst. Hier nochmal die zwei wichtigsten Links für dich…

AutoPilot GitHub Repository​

AutoPilot Download Link​

Versionsgeschichte​

Details zur Versionsgeschichte findest du in der Datei CHANGELOG meines GitHub Repository

Lizenz​

AutoPilot unterliegt der GNU GENERAL PUBLIC LICENCE Version 3 von 29. Juni 2007 und wird somit lizenzkostenfrei angeboten. Eine Haftung (auch bei möglichen Datenverlusten durch die Software) wird grundsätzlich ausgeschlossen. Hierzu ein Auszug aus der GPL3 (ins deutsche übersetzt)...

Dieses Programm ist freie Software. Sie können es unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 3 der Lizenz oder (nach Ihrer Option) jeder späteren Version.

Die Veröffentlichung dieses Programms erfolgt in der Hoffnung, daß es Ihnen von Nutzen sein wird, aber OHNE IRGENDEINE GARANTIE, sogar ohne die implizite Garantie der MARKTREIFE oder der VERWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK.

Weitere Einzelheiten finden Sie in der GNU General Public License. Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Falls nicht, siehe http://www.gnu.org/licenses/

Tommes

 

[plang.pl]

Sauber!
Hatte mich schon darauf gefreut. Werde ich die Tage mal testen und mein bisheriges autorun-Konstrukt evtl. dadurch ersetzen!
Danke dir schon mal für die Entwicklung!

 

[Tommes]

Das Herauslösen von AutoPilot aus Basic Backup war am Ende doch mehr Arbeit als gedacht (hab aber auch noch einige Änderungen vorgenommen, die nicht geplant waren). Für die Benutzer von Basic Backup ändert sich auch nicht wirklich viel, da an den externen Datenträgern bzw. an dem sich darauf befindlichen autopilot Script nichts geändert werden muss. Einzig die Installation und Einrichtung von "AutoPilot für externe Datenträger" ist nötig und schwupps... sollte alles weiterlaufen wie bisher.

Insider-Info: Die für die Erkennung externer Datenträger benötigte udev-Regel, die bisher auf ein internes Basic Backup Script zur Weiterverarbeitung gezeigt hat, wird nach der Installation von AutoPilot einfach umgeschrieben, so das die udev-Regel nun auf ein internes AutoPilot Script zur Weiterverarbeitung zeigt. Eigentlich keine große Sache, es ändert sich einfach nur eine Verknüpfung.

Wie auch immer... ich hoffe, das euch AutoPilot gefällt und freue mich bereits jetzt schon auf euer Feedback.

Tommes

 

[daschmidt94]

Hab mich mal heute mit der App beschäftigt aber irgendwie wirft der das sofort wieder aus weip nicht ob es auf meinem Skript ist oder an der Einstellung/App

#!/bin/bash

/usr/syno/bin/synobackup --backup 19 --type image

sleep 60
while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof synol>do
sleep 60
done

exit ${?}

 

[plang.pl]

Versuch mal, ob das Script im Aufgabenplaner durchläuft. Wie hast du das erstellt?
Stichwort: Linux Zeilenumbruch.
Außerdem fehlen da mindestens eine Klammer und ein ">" gehört da auch nicht hin. Zudem ist die Bedingung unvollständig. Siehe hier. Aber das kennst du ja

 

[daschmidt94]

sorry aus der Konsole falsch kopiert hier das richtig:

#!/bin/bash

/usr/syno/bin/synobackup --backup 19 --type image

sleep 60
while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof synolocalbkp)" -o "$(/bin/pidof synonetbkp)" -o "$(/bin/pidof updatebackup)" ]
do
sleep 60
done

exit ${?}

in der Konsole läuft es durch

 

[plang.pl]

Ok dann hab ich nix gesagt

 

[Tommes]

Ehrlich gesagt habe ich AutoPilot noch nie zusammen mit Hyper Backup benutzt. Das müsste ich mir heut Abend erstmal anschauen.

…aber irgendwie wirft der das sofort wieder aus…

Wirft „der“ das erst nach ca. 1 Minute (1x sleep 60 Anweisung vor der while-Schleife) oder erst nach min. 2 Minuten (weitere sleep 60 Anweisungen innerhalb der while-Schleife) aus, oder unmittelbar nach dem einstecken des externen Datenträgers? Wird der Hyper Backup Auftrag dabei trotzdem (evtl. im Hintergrund) ausgeführt? Wird dir im AutoPilot Protokoll irgend ein Exit-Code ausgegeben?

Nachtrag: Vielleicht habe ich das alles aber auch nicht ganz zu Ende gedacht und nicht berücksichtigt, das AutoPilot einfach mehr Berechtigungen benötigt um ein Hyper Backup Auftrag oder ein beliebiges bash Script auszuführen. Komisch dabei ist nur, das sich ein Basic Backup Auftrag, welches zwingend als root ausgeführt werden muss, über AutoPilot problemlos ausführen läßt. Das passt also irgendwie alles nicht zusammen.

Ich schau mir das heut Abend mal an! Bis dahin möchte ich mich schon mal für die Unannehmlichkeiten entschuldigen.

Tommes

 

[daschmidt94]

Hier der

Spoiler: log

-------------------------------------------------------------------------------------------------------------------
2023-08-30 19:06:34 - AutoPilot wird ausgeführt
-------------------------------------------------------------------------------------------------------------------
Externer Datenträger erkannt!
Datenträgername: usb1
Gerätename: /dev/usb1p1
UUID: 9019-1A93
Einhängepunkt: /volumeUSB1/usbshare
Suche AutoPilot-Script...

Das AutoPilot-Script wurde gefunden und wird ausgeführt

Bitte warten...

Das AutoPilot-Script wurde erfolgreich ausgeführt!

Der externe Datenträger wird ausgeworfen...
Systemrückmeldung:~# Unmount USB device usb1 succeeded.
Der externe Datenträger wurde erfolgreich ausgeworfen!
-------------------------------------------------------------------------------------------------------------------
2023-08-30 19:07:56 AutoPilot beendet
-------------------------------------------------------------------------------------------------------------------

 

[Tommes]

Danke für das Protokoll. Demnach verging nur etwas mehr als eine Minute zwischen Erkennung und Auswurf. Innerhalb AutoPilot sind auch noch ein paar kleinere sleep Anweisungen gesetzt. Demnach wird der Hyper Backup Auftrag nicht ausgeführt.

Wie gesagt… schau ich mir heut Abend an

 

[Tommes]

@daschmidt94
Kannst du mir noch sagen, ob der Hyper Backup Auftrag evtl. trotzdem ausgeführt wurde. Die while-Schleife greift ja nur, wenn nach 60 Sekunden Wartezeit eine der Bedingungen in den eckigen Klammern erfüllt wurde und somit festgestellt wurde, das der Auftrag noch läuft. Vielleicht ist bis dahin der Auftrag aber bereits durchgelaufen. Könnte theoretisch ja sein.

 

[daschmidt94]

irgendetwas macht hyperbackup weil eine Benachrichtigung kommt das der Job fehlgeschlagen ist. Kann dir erst am Abend genaueres sagen haben heute Stromabschaltung...

 

[Tommes]

Hm… dann passiert da ja auf jeden Fall schon mal etwas, was einem Berechtigungsproblem von AutoPilot widerspricht. Das macht mich echt neugierig…

 

[Tommes]

So. Endlich zu Hause. Kaffee gekocht und Laptop angeschmissen. Nun denn...

Erste Erkenntnise...
Wenn ich ein Hyper Backup Auftrag über die Konsole nach dem Schema...

/usr/syno/bin/synobackup --backup 3 --type local

... als root ausführe, wobei ich mich dabei streng an die Anleitung von @plang.pl bezüglich JOB-ID und BACKUP-TYP gehalten habe, dann erhalte ich in der Hyper Backup GUI die Meldung "Fehlgeschlagen" und im Hyper Backup Protokoll ist zu lesen...

[Network to share][DS115 Daten][Failed to run backup task.]

Führe ich den Auftrag über die GUI aus, dann läuft dieser jedoch anstandslos durch. Komisch finde in diesem Zusammenhang allerdings die Aussage von @daschmidt94...

in der Konsole läuft es durch

... wohingegen die Ausführung über AutoPilot laut seinen Aussagen jedoch fehlschlägt. Komisch ist auch, das AutoPilot bis zu diesem Punkt meines Tests noch gar nicht in Erscheinung getreten ist, womit es eigentlich nicht an AutoPilot liegen kann. Egal. Nächster Test.

Ich habe auf einem USB-Datenträger eine AutoPilot Scriptdatei mit folgendem Inhalt erstellt...

#!/bin/bash
/usr/syno/bin/synobackup --backup 3 --type local
echo ${?}
sleep 60
while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof syn>
do
echo ${?}
sleep 60
done
echo ${?}

... wobei ich mir erlaubt habe, mögliche Exit-Code-Meldungen per echo ausgeben zu lassen.

Nun ist es egal, ob ich die Scriptdatei direkt auf der Konsole ausführe oder aber den USB-Datenträger trenne, aus- und wieder einstecke, denn auch hier sagt mir die GUI von Hyper Backup wieder "Fehlgeschlagen". Ich hätte auch nichts anderes erwartet.

Führe ich die autopilot Scriptdatei direkt über die Konsole aus, dann erhalte ich zwei Exit-Code 0 Ausgaben. Wobei die erste 0 nach dem Aufruf von /usr/syno/bin/synobackup --backup 3 --type local ausgegeben wird und die zweite 0 das Resultat aus dem letzten echo nach dem done ist, da die while-Schleife gar nicht erst durchlaufen wird.

Im Ergebnis hat das erstmal nichts mit AutoPilot zu tun, sondern eher daran, wie ein Hyper Backup Auftrag aufgerufen wird. Vielleicht hat sich seit HyperBackup 4.1.0-3716 oder seit DSM 7.2 etwas geändert, was bisher noch niemandem aufgefallen ist. Im Übrigen verwende ich hier Hyper Backup 4.1.0-3716 sowie DSM 7.2 64570 Update 3.

Tommes

 

[daschmidt94]

Wenn ich bash autopilot ausführe läuft Hyperbackup durch. Wenn es über Autopilot gestartet wird, kommt es nicht.

 

[Tommes]

Dieses Verhalten kann ich bei mir nicht bestätigen, da der Hyper Backup Auftrag nur dann erfolgreich durchläuft, wenn ich diesen über die GUI auslöse. Direkt über die Konsole als einfacher Befehl, oder über das AutoPilot Script - manuell oder automatisch ausgelöst - klappt das nicht. Hören wir mal, ob @plang.pl etwas dazu sagen kann. Für den Moment bin ich überfragt.

 

[luddi]

while [ "$(/bin/pidof img_backup)" ]; do

Unabhängig von Autopilot möchte ich an dieser Stelle einen Einwand zur Abbruchbedingung der Schleife äußern.

Nehmen wir an man startet eine Task wie in diesem Beispiel mit der id No. 19 --backup 19.
Hyperbackup kann immer nur ein Task zur gleichen Zeit abbarbeiten und alle nachfolgenden gestarteten Tasks gehen in die Warteschlange. Somit werden anstehende Tasks sequentiell abgearbeitet.

Nun kommen wir zu dem folgenden Szenario, dass die per Skript angestoßene Aufgabe No. 19 läuft und währenddessen der Aufgabenplaner eine weitere Backup Task ausführen möchte. Diese landet somit zunächst in der Warteschlange und muss warten bis die vorherige Aufgabe abgeschlossen ist.

Jetzt stellen wir uns die Frage was mit unserer while Schleife passiert. Dadurch dass wir die Abbruchbedingung der Schleife alle x Sekunden (in diesem Beispiel 60 sec.) prüfen, wird uns hier weiterhin mitgeteilt dass der Backup Job noch läuft obwohl es durchaus sein kann dass unsere per Skript ausgeführte Task bereits beendet ist und schon die nächste Aufgabe läuft.
Dies passiert nur, weil die Bedingung nicht explizit ist sondern lediglich prüft ob es eine PID mit dem Namen "img_backup" usw. gibt.

Hier ein Beispiel welches verdeutlichen soll, dass das Skript weiter ausgeführt wird obwohl die Task bereits beendet ist und die nächste Aufgabe mit einer anderen PID ausgeführt wird.

Blau markiert die Aufgabe welche per Skript gestartet wurde, und rot markiert die Aufgabe welche sich durch ein zeitliches Event in der Warteschlange befindet während die andere noch läuft.


Hier sieht man, dass die blau markierte Aufgabe per Skript gestartet die PID 28064 hat, und die folgende Aufgabe welche per Scheduler gestartet wurde die PID 31506 zugewiesen wurde. Dies hat nun zur Folge, dass die Abbruchbedingung der Schleife nicht erfüllt ist solange irgendeine Prozess ID den Namen img_backup trägt.




An dieser Stelle möchte ich euch darauf hinweisen, dass hier nur eine explizite Prüfung Sinn ergibt.
Dies erreicht man am besten indem man die PID des Prozesses heraussucht und überprüft ob gneau dieser Prozess noch läuft und nicht irgendeiner mit welcher den Namen img_backup trägt.

Ich würde das Script an eurer Stelle etwa so realisieren:

#!/bin/bash

taskid=19
type=image

/usr/syno/bin/synobackup --backup "$taskid" --type "$type"

pid=$(ps aux | grep -v grep | grep -E "/var/packages/HyperBackup/target/bin/img_backup.+-k $taskid" | awk '{print $2}')
echo PID of Backup Task: "$pid"

while kill -0 $pid 2> /dev/null; do
        #echo Processing Backup...
        sleep 60
done
echo Backup with PID "$pid" finished!

exit 0

Zumindest funktioniert dies auf meiner Maschine reibungslos direkt aus der Kommandozeile. Was es nun mit Autopilot auf sich hat das wird sicher @Tommes noch klären.

 

[Tommes]

Moin @luddi und vielen Dank für dein - mal eben - aus dem Ärmel geschütteltes Script. Die Abfrage der PID ist mir an dieser Stelle auch wesentlich sympathischer, jedoch wirft mir dein Script gar keine PID aus und somit wird die while Schleife auch nicht durchlaufen. Könnte vielleicht daran liegen, das meine Aufgabe nicht den type=image, sondern den type=local trägt, da es sich hier um ein dateibasiertes, einzelversions rsync Backup auf einen Remote Server handelt. In meinem Fall muss wohl eher nach der PID von synolocalbkp als von img_backup gesucht werden.

root@DiskStation:~# . ./autopilot
PID of Backup Task:
Backup with PID  finished!

Da ich aber grade auf dem Sprung bin, kann ich das aktuell nicht weiter testen, werde das heut Abend aber mal mit einem type=image testen, oder dein Script entsprechend auf synolocalbkp umstellen. Für den Moment kann ich nur sagen, das dein Script bei mir nichts an der Tatsache ändert, das die ausgeführte Hyper Backup Aufgabe weiterhin als "Fehlgeschlagen" beendet wird. Dieses Verhalten ist, wie gesagt, völlig unabhängig von AutoPilot und der PID, auch wenn die Script-Datei in dem Fall den Namen autopilot trägt.

Tommes

 

[Tommes]

Eins noch…

Wäre es nicht sinnvoller, dieses Hyper Backup Problem in diesem Thread weiter zu diskutieren, da es nach meinem Empfinden zunächst nichts mit AutoPilot zu tun hat. Nur so eine Idee. Da es mein Thread ist, stört es mich aber auch nicht weiter, es hier weiter zu verfolgen.

 

[luddi]

In meinem Fall muss wohl eher nach der PID von synolocalbkp als von img_backup gesucht werden.

Das kann natürlich sein, denn ich habe nicht alle der bereits erwähnten Abbruchbedingungen verfolgt und in den PIDs nach den entsprechenden Namen gesucht.
Ich hatte mir eines meiner Backup tasks herausgesucht um das zu analysieren und dieses ist eben ein versioniertes remote rsync Backup und taucht unter den PIDs immer mit dem Namen img_backup auf.

Mein Script sollte nur einmal zeigen dass man sich besser auf die eindeutige PID stürzen soll anstatt auf nur einen Namen.

Natürlich müsste man mein Script erweitern für alle individuellen Einzelfälle um die korrekte PID zu bekommen.

@Tommes Beides macht wohl Sinn, das Thema entweder hier oder in einem anderen Thread zu verfolgen.

Aber eines traue ich mich jetzt schon zu behaupten und nehme hier @Tommes in Schutz dass es an dieser Stelle nichts mit dem Autopilot zu tun haben kann.
Solange eure Scripte nicht sauber funktionieren und reine Willkür zurückmelden kann Autopilot auch nur diese Information verarbeiten.