Unterstützung für Hook Skript wie bei PVE

[fabian]

du kannst doch einfach selber ne timer unit schreiben, die

- tunnel aufbau
- sync (via proxmox-backup-manager oder API)
- tunnel abbau

triggert (als eine unit, oder als mehrere)?

die sync tasks siehst du dann ja trotzdem in der UI, sind normale tasks.. einzig die schedule musst dann du selber einrichten, aber unsere schedules und systemd timer sind sich sehr aehnlich

 

[nlsschmdt]

DynDNS ist keine Option wegen den wechselnden IPs? Hier wechseln die IPs ja auch, aber dann baut der Wireguard-Client halt den Tunnel zur neuen IP neu auf, sobald die DynDNS aktualisiert wurde.

Selbstverständlich nutze ich DynDNS. Das Problem muss ich ja ganz unabhängig davon lösen. Es bleibt dabei, dass ich erkennen muss, wann sich die IP ändert und ich einen neuen Tunnel aufbauen muss.

 

[nlsschmdt]

du kannst doch einfach selber ne timer unit schreiben, die

- tunnel aufbau
- sync (via proxmox-backup-manager oder API)
- tunnel abbau

triggert (als eine unit, oder als mehrere)?

die sync tasks siehst du dann ja trotzdem in der UI, sind normale tasks.. einzig die schedule musst dann du selber einrichten, aber unsere schedules und systemd timer sind sich sehr aehnlich

Danke für den Hinweis!
Das Thema Timer Unit werde ich mir anschauen! Das ist aus meiner Sicht weniger elegant, als wenn man direkt einen Sync-Job einrichten könnte, der tut was er soll, aber immerhin liest es sich so, als sei es sonst vollständig integriert.

 

[nlsschmdt]

Noch einmal zurück zu den Timer Units: Ich bin heute auf die Suche gegangen und habe in den PBS Docs nichts dazu gefunden. Verstehe ich dich jetzt richtig, dass ganz normale Systemd Timer gemeint sind, ohne jegliche Integration in die Proxmox Umgebung? Das wäre sehr enttäuschend! Ich war davon ausgegangen es gäbe im PBS ein allgemeines Framework für Timer, das ich über die API konfigurieren kann. So muss ich einen Sync-Schedule anlegen, der aber nie von alleine laufen darf und dann noch versteckt einen Systemd-Timer (oder cronjob), der den deaktivierten Sync-Job anstößt. Das Ergebnis ist potenziell sehr irreführend.
Wenn ich nichts falsch verstanden habe, bin ich quasi wieder am Ausgangspunkt: Ein Hook-Skript für Sync-Jobs ist äußerst wünschenswert!

 

[fabian]

Noch einmal zurück zu den Timer Units: Ich bin heute auf die Suche gegangen und habe in den PBS Docs nichts dazu gefunden. Verstehe ich dich jetzt richtig, dass ganz normale Systemd Timer gemeint sind, ohne jegliche Integration in die Proxmox Umgebung? Das wäre sehr enttäuschend! Ich war davon ausgegangen es gäbe im PBS ein allgemeines Framework für Timer, das ich über die API konfigurieren kann. So muss ich einen Sync-Schedule anlegen, der aber nie von alleine laufen darf und dann noch versteckt einen Systemd-Timer (oder cronjob), der den deaktivierten Sync-Job anstößt. Das Ergebnis ist potenziell sehr irreführend.
Wenn ich nichts falsch verstanden habe, bin ich quasi wieder am Ausgangspunkt: Ein Hook-Skript für Sync-Jobs ist äußerst wünschenswert!

ja, ich meinte ganz normal systemd units. die konfiguration (und logs usw) des syncs liegt dann immer noch auf PBS seite, nur die schedule (und der hook teil) liegt bei systemd.

 

[uiffiu]

mir fallen keine (oder sehr wenige) solchen aktionen fuer GC/prune/verify/sync auf PBS server seite ein.

Hallo!
Ich habe remote PBS, welches von meinem lokalen PBS die Daten lesend holt. Wollte hier nun einen hook für selfhosted healthchecks einbauen, statt Mailbenachrichtigung. Es kommen doch einige Mails zusammen, wenn mal 1-2h keine Verbindung zwischen den PBS war...
(lokal gehosteter Mailserver wird alle 10min auf einen lokalen PBS gesichert und von 2 offsite PBS geholt)

 

[duff]

Bin auf der gleichen Suche. Wenn du was gefunden hast, dann gerne hier posten. Gleiches gilt auch für mich

 

[uiffiu]

Bin auf der gleichen Suche. Wenn du was gefunden hast, dann gerne hier posten. Gleiches gilt auch für mich

Habe ein Script für Crontab gebastelt. Ist für 2 sync jobs, einer alle 10min und einer alle 1h.
Zum einfachen herausfinden der worker id, am Ende der Funktion check_criteria die Zeile echo "Worker $worker_id mit Status $status" auskommentieren und das Skript ausführen.
worker_10min und worker_60min mit den entsprechenden ID befüllen

Code:

#!/bin/bash
MAX_AGE_10MIN=20
MAX_AGE_60MIN=110
HEALTHCHECK="" #hier kommt die komplette Ping URL von Healthchecks rein
OK_10MIN="-1"
OK_60MIN="-1"
worker_10min=""
worker_60min=""
AGE_10MIN="0"
AGE_60MIN="0"

json_response=`/usr/sbin/proxmox-backup-manager task list --all --limit 20 --output-format json`


# Funktion zur Überprüfung der Kriterien
check_criteria() {
    worker_id="$1"
    endtime_seconds="$2"
    status="$3"

    # Aktuelle Zeit in Sekunden
    current_seconds=$(date +%s)

    # Berechnung der Differenz in Minuten
    age_minutes=$(( (current_seconds - endtime_seconds) / 60 ))

    # worker_10min
    if [[ $age_minutes -le $MAX_AGE_10MIN && "$status" == "OK" && "$worker_id" == "$worker_10min" ]]; then
        echo "Job für Worker $worker_id ist innerhalb der letzten $MAX_AGE_10MIN Minuten erfolgreich abgeschlossen."
        if [[ $OK_10MIN == "-1" ]]; then
            OK_10MIN="0"
            AGE_10MIN=$age_minutes
        fi
#    else
#        echo "Job für Worker $worker_id ist entweder zu alt oder nicht erfolgreich."
    fi

    # worker_60min
    if [[ $age_minutes -le $MAX_AGE_60MIN && "$status" == "OK" && "$worker_id" == "$worker_60min" ]]; then
        echo "Job für Worker $worker_id ist innerhalb der letzten $MAX_AGE_60MIN Minuten erfolgreich abgeschlossen."
        if [[ $OK_60MIN == "-1" ]]; then
            OK_60MIN=0
            AGE_60MIN=$age_minutes
        fi
#    else
#        echo "Job für Worker $worker_id ist entweder zu alt oder nicht erfolgreich."
    fi
#    echo "Worker $worker_id mit Status $status"
}

# Befehl zum Parsen des JSON (anpassen, falls du ein anderes Tool verwendest)
mapfile -t array < <(jq -r '.[] | "\(.worker_id),\(.endtime),\(.status)"' <<< "$json_response")

# Schleife über alle Elemente im Array
for line in "${array[@]}"; do
    # Extrahiere die Werte aus der Zeile
    IFS=, read -r worker_id endtime status <<< "$line"

    # Übergebe die Werte an die Prüfungsfunktion
    check_criteria "$worker_id" "$endtime" "$status"
done

if [[ $OK_10MIN == "0" && $OK_60MIN == "0" ]]; then
    echo alles top!
    curl -fs -m 10 --retry 5 -o /dev/null $HEALTHCHECK
else
    echo ein fehler ist passiert
    curl -fs -m 10 --retry 5 --data-raw "ein Fehler ist vorhanden 10min: $OK_10MIN AGE_10MIN: $AGE_10MIN 60min: $OK_60MIN AGE_60MIN: $AGE_60MIN" -o /dev/null $HEALTHCHECK/fail
fi

Crontab root:
*/10 * * * * /root/checksyncjobs.sh > /dev/null

In Healthchecks habe ich Period 10m und Gracetime 10m eingestellt.
Sollte das Script fehlschlagen (zB aus irgendeinem Grund nicht laufen), timed einfach Healthchecks aus und schickt eine Meldung.

 

[Julius Glatz GmbH]

@hasechris92
3. wenns einen guten use case fuer hook scripts auf PBS seite gibt der nicht unter punkt 2 faellt, und sich auch nicht durch verbesserungen im notification system handlen laesst, dann laesst sich das sicher technisch implementieren

Hmm... vllt. hätte ich einen "use case".
Wir würden gerne nach erfolgreichem Backup das Band gleich in den Mailslot ausspucken lassen, damit man es direkt entnehmen kann.
Über den "eject" des PBS geht das nicht. Der Wechsler brauch dazu wohl einen Webaufruf, z.B.:
http://IP.OF.YOUR.LOADER/move.cgi?from=xxx&to=yyy
und ich denke, so etwas würde nur per Hookskript funktionieren. Ich lasse mich aber auch gern eines Besseren belehren

 

[fabian]

das liesse sich potentiell mit dem geplannten web-hook notification feature ganz gut loesen?

https://bugzilla.proxmox.com/show_bug.cgi?id=5078 (bug fuer PVE, aber patches sind auch fuer PBS )

 

[Julius Glatz GmbH]

das liesse sich potentiell mit dem geplannten web-hook notification feature ganz gut loesen?

https://bugzilla.proxmox.com/show_bug.cgi?id=5078 (bug fuer PVE, aber patches sind auch fuer PBS )

Ja. Das könnte gut passen. Stimmt! Danke!
Wann wird es offiziell drin sein? Wir würden das gerne nutzen.

 

[dcsapak]

Hmm... vllt. hätte ich einen "use case".
Wir würden gerne nach erfolgreichem Backup das Band gleich in den Mailslot ausspucken lassen, damit man es direkt entnehmen kann.
Über den "eject" des PBS geht das nicht. Der Wechsler brauch dazu wohl einen Webaufruf, z.B.:
http://IP.OF.YOUR.LOADER/move.cgi?from=xxx&to=yyy
und ich denke, so etwas würde nur per Hookskript funktionieren. Ich lasse mich aber auch gern eines Besseren belehren

das sollte potentiell mit dem 'export' feature vom tape backup job funktionieren, vorraussetzung ist dass der mail-slot auch als slot sichtbar und als export slot in der config markiert ist

 

[Julius Glatz GmbH]

das sollte potentiell mit dem 'export' feature vom tape backup job funktionieren, vorraussetzung ist dass der mail-slot auch als slot sichtbar und als export slot in der config markiert ist

Genau das ist er leider nicht. Sonst hätten wir es so schon gemacht. Sichtbar sind nur die Slots der beiden Magazine 1-16 und das Drive.
Eine Möglichkeit, dass auch der Mailslot im PBS angezeigt wird, haben wir beim "Superloader 3" leider nicht gefunden.
Daher der "Umweg" über die URL.

 

[dcsapak]

ah ok, dann macht der hook Ansatz natürlich sinn.

 

[Falk R.]

Genau das ist er leider nicht. Sonst hätten wir es so schon gemacht. Sichtbar sind nur die Slots der beiden Magazine 1-16 und das Drive.
Eine Möglichkeit, dass auch der Mailslot im PBS angezeigt wird, haben wir beim "Superloader 3" leider nicht gefunden.
Daher der "Umweg" über die URL.

Hier mal ein Statement von Quantum:
"The Superloader is not a tape library but a tape loader device.
There is no SCSI command available for loaders for import / export. This is only available with tape libraries. ( different device class)
So your assumption that this is not possible is right. "