Unterstützung für Hook Skript wie bei PVE

[hasechris92]

Hallo zusammen,

weiß jemand ob es im PBS Support für Hooks Skripts wie beim PVE gibt? Ich würde gerne Hook Skripts benutzen, um meinem Healthchecks (healthchecks.io) Service den Trigger zu schicken, dass der Backup Job entweder gestartet hat oder beendet ist.

Viele Grüße
Christian Hase

 

[Dunuin]

PBS nutzt die selben Hooks wie VZDump: https://git.proxmox.com/?p=pve-mana...e70a4a9775438ab658da2191;hb=refs/heads/master
Nicht vergessen dein Hook Script unter /etc/vzdump.conf einzutragen.

Also ja, damit kannst du deine Backup Jobs zum PBS triggern lassen.

 

[hasechris92]

hm, ich habe mich, glaube ich, schlecht ausgedrückt.

Stand heute:
Für den PVE habe ich einen Backup Job, der meine VMs auf den PBS sichert. Normal über die GUI eingerichtet.
Zusätzlich habe ich, wie von dir beschrieben, in dem File /etc/vzdump.conf mein Hook Script hinterlegt.

root@mgtsrv001:~# cat /etc/vzdump.conf

# vzdump default settings

#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#prune-backups: keep-INTERVAL=N[,...]
#script: /opt/vzdump_hook_homelab-automation.sh
#exclude-path: PATHLIST
#pigz: N

Hier noch mein Hook Script für den PVE

root@mgtsrv001:~# cat /opt/vzdump_hook_homelab-automation.sh 
#!/bin/bash

echo -e "HOOK: $@"
#- job-start
#- backup-start stop <VMID>
#- backup-end stop <VMID>
#- log-end stop <VMID>
#- job-end

case "${1}" in
    job-start)
        # send generall information that vm backup was started
        su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=backup_vms\"; ansible-playbook main.yml -e \"jobaction=start\"" homelab-automation
    ;;
    backup-abort)
        shift
        shift
        su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=backup_vms\"; ansible-playbook main.yml -e \"vm=${1} healthcheckaction=2 jobaction=backup-abort\" " homelab-automation
    ;;
    backup-start)
        # send info which vm backup job is now running
        shift
        shift
        su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=backup_vms\"; ansible-playbook main.yml -e \"vm=${1} healthcheckaction=log jobaction=backup-start\"" homelab-automation
    ;;
    backup-end)
        shift
        shift
        case "${1}" in
            106) su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=univention-cryptfs\"; ansible-playbook main.yml" homelab-automation;;
        esac
    ;;
    job-end)
        su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=backup_vms\"; ansible-playbook main.yml -e \"jobaction=success\"" homelab-automation
    ;;

Das funktioniert auch wunderbar. Damit bekomme ich die Info, ob und mit welchem Status der Backup Job PVE -> PBS funktioniert hat.

Zusätzlich habe ich im PBS einen Backup Job, der den Datastore-Content auf ein Tape Laufwerk speichert. Und an dieser Stelle hätte ich gerne den Hook Skript Support.

 

[Dunuin]

Ah ok. Dachte du meinst die Backups zum PBS.

 

[hasechris92]

Ja, nein, leider nicht :-D Danke dir trotzdem schon mal.

Schauen wir mal, ob vielleicht noch jemand anderes eine Info hat.

 

[dcsapak]

nein sowas gibt es noch nicht, wäre aber vielleicht eine sinnvolle ergänzung. wenn du möchtest kannst du einen 'enhancement request' in unserem bugtracker aufmachen: https://bugzilla.proxmox.com

 

[duff]

@hasechris92: Was genau machst du in deinen ansible Skripten, die im Skript /opt/vzdump_hook_homelab-automation.sh aufgerufen werden?

 

[hasechris92]

nein sowas gibt es noch nicht, wäre aber vielleicht eine sinnvolle ergänzung. wenn du möchtest kannst du einen 'enhancement request' in unserem bugtracker aufmachen: https://bugzilla.proxmox.com

Ist erstellt. Ich habe leider keine Info per Mail über deine Nachricht hier bekommen und heute erst wieder aktiv hier reingeschaut.

https://bugzilla.proxmox.com/show_bug.cgi?id=5155

 

[hasechris92]

@hasechris92: Was genau machst du in deinen ansible Skripten, die im Skript /opt/vzdump_hook_homelab-automation.sh aufgerufen werden?

Das ist mein Automation Framework, welches ich mir für meine IT angefangen habe zu schreiben. Ist leider sehr "persönlich" aka genau nur das, was ich eben brauche . Ich weiß nicht ob du irgendwas mit meinem Geschwafel anfangen kannst, ich versuchs aber mal.

---

Grundlegend informiere ich hiermit meine selbstgehostete healthchecks.io Instanz. Diese Instanz hat die Info, wie lange und in welchem Rhythmus solche Jobs laufen sollten und kann mich bei Problemen per Telegram informieren.

Informieren kann man die healthchecks.io Instanz so:


Info an die Instanz für Error:


Info an die Instanz für generelle Log-Einträge:

Die Log sieht dann so aus:


Einzelner Eintrag für so eine Log-Meldung (wie Punkt 2 in der Liste)


Einzelner Eintrag für einen Fehler

Im Telegram sieht das dann so aus (sind jetzt verschiedene Zeitpunkte, aber es geht ja nur ums Prinzip)

---

Erklärung zu meinem Hook Script
Schau dir die Ansible-Zeilen an:

[...] ansible-playbook main.yml -e \"jobaction=start\"" homelab-automation

Diese Zeile informiert die healthchecks.io Instanz, dass der Backupjob gestartet wurde. Da ich nur einen Backupjob für meine wenigen VMs habe brauche ich hier keine Info, welcher Job gestartet wurde. Dies kann man aber einfach erweitern.

 […] ansible-playbook main.yml -e \"vm=${1} healthcheckaction=2 jobaction=backup-abort\" " homelab-automation

Diese Zeile informiert die Instanz, wenn es einen Abbruch in einem Job gibt. hier wird zusätzlich noch die Variable "vm" mit übergeben. Diese Info sehe ich dann in meinem Telegram (ist ja ein Error).

 […] ansible-playbook main.yml -e \"vm=${1} healthcheckaction=log jobaction=backup-start\"" homelab-automation

Diese Zeile informiert die Instanz, wenn ein Backup pro VM startet. Dies ist für bessere Nachverfolgbarkeit in der healthcheck-Instanz (also quasi eine Debug-Info).

    backup-end)
        shift
        shift
        case "${1}" in
            106) su -s /bin/bash -P -c "source ~/.bashrc; ansible-playbook inventory_setup.yml -e \"env=univention-cryptfs\"; ansible-playbook main.yml" homelab-automation;;
        esac
    ;;

Dies ist der eine Sonderfall, den ich habe. Eine VM hat eine Festplattenverschlüsselung, würde also bei einem Backup nicht wieder sauber hochfahren (da ich meine VMs fürs Backup sauber herunterfahre). Hier prüfe ich zusätzlich auf die VM Nummer (der zweite switch-case). Wenn die passende VM mit dem Backup fertig ist wird ein Ansible Code gestartet, der sich per SSH auf eine minimale Dropbear Instanz verbindet, die aus der Initramfs gestartet wird. Damit bekomme ich automatisch meine VM mit LUKS Verschlüsselung entsperrt.

Das müsste wahrscheinlich als Erklärung reichen. Ich hab aber einfach mal die Ansible Rolle als Listung hier angehängt, die die Infos an die healthchecks.io Instanz weiterleitet.

Viele Grüße
hasechris

---

Listing Ansible Rolle:

---
################################
# This role is a meta role. It is used inside the vzdump backup hook script in proxmox_mgtsrv001/templates/vzdump-script.sh
#
# it either expects to be run without vm + jobaction variable or with the following variables:
#
# - vm: Specify the proxmox vm number
# - healthcheckaction: define which API Target to use
# - jobaction
#
- name: "{{ env }}: Ping the healthcheck for Action: start"
  ansible.builtin.uri:
    url: "https://<URL>/ping/{{ healthcheck_uuid }}/start"
    method: POST
    body_format: raw
    body: "Status Backup_vms: {{ jobaction }}"
  when:
    - vm is not defined
    - jobaction == "start"
    - healthcheckaction is not defined

- name: "{{ env }}: Ping the healthcheck for Action: {{ healthcheckaction }}"
  ansible.builtin.uri:
    url: "https://<URL>/ping/{{ healthcheck_uuid }}/{{ healthcheckaction }}"
    method: POST
    body_format: raw
    body: "Status backup_vms: {{ jobaction }}     vm id: {{ vm }}"
  when:
    - vm is defined
    - healthcheckaction is defined
    - jobaction is defined

- name: "{{ env }}: Ping the healthcheck, we are finished"
  ansible.builtin.uri:
    url: "https://<URL>/ping/{{ healthcheck_uuid }}"
    method: POST
    body_format: raw
    body: "job was finished. seems like everything worked :-)"
  when:
    - vm is not defined
    - jobaction == "success"
    - healthcheckaction is not defined
...

 

[hasechris92]

nein sowas gibt es noch nicht, wäre aber vielleicht eine sinnvolle ergänzung. wenn du möchtest kannst du einen 'enhancement request' in unserem bugtracker aufmachen: https://bugzilla.proxmox.com

Hm. Siehe https://bugzilla.proxmox.com/show_bug.cgi?id=5155. Weiß gerade nicht was ich jetzt hiervon denken soll. Es gibt es schon mehrere Bug Einträge, die das gleiche Thema in der Vergangenheit schon angesprochen haben. Die sind alle wieder geschlossen worden als "Duplicate - WONTFIX" mit Verweis auf einen Eintrag.
Zusammengefasst aus den verlinkten Einträgen: Es sprechen technische Gründe dagegen, dass Proxmox so eine Script-Integration auf dem PBS einbauen kann; hier kristallisiert sich das grundlegende Design des PBS als Hindernis heraus.

Einerseits verstehe ich hier Proxmox, dass Thema ist ein Problem. Rein schon von der notwendigen Arbeitsstunden um eine grundlegende Änderung in der Softwarearchitektur einfließen zu lassen. Außerdem muss man bezüglich Kundenorientierung einwerfen, dass der Wunsch nach diesem Feature auch wahrscheinlich relativ klein ist - siehe die Anzahl der Einträge zu diesem Thema im Forum und auch im Bugtracker. Herr Grünbichler hat den ursprünglichen Bug als Duplicate verlinkt. Das zeigt nicht gerade viel Interesse auf Kundenseite.

Andererseits finde ich es sehr schade, dass Proxmox hier einfach keine Lösung parat hat und scheinbar auch kein interesse an irgendwas hat (so interpretiere ich die Klassifizierung "Wontfix"). Könnte man hier nicht für die Enthusiasten unter uns eine Plattform bieten, auf deren Basis so eine Automationslösung zusammen erarbeitet und für alle möglichen User zur Verfügung gestellt wird?

Momentan scheinen schon mindestens eine Hand voll Personen dieses Problem in der Vergangenheit gehabt zu haben; diese Personen scheinen für sich eine Lösung gefunden zu haben, diese Lösungen sind aber "verloren", da Proxmox hier keine zentrale Stelle zur Wissenssammlung und -verteilung scheinbar darstellen möchte.

Das Handling finde ich insgesamt sehr unglücklich. Ich werde mir jetzt eine Lösung erarbeiten, die generell das Task Scheduling in meinem Proxmox Cluster und dem PBS übernimmt. Falls Proxmox hieran Interesse haben sollte können wir hierzu gerne weiter sprechen und ich kann den Code dann auch gerne besser aufarbeiten und modularer bauen, sodass auch andere diesen Code benutzen können. Gerne können wir das Git Repo vielleicht sogar unter Proxmox aufhängen, sodass das ganze dann nicht an mir als Einzelperson irgendwann einschläft. Mir ist hier keine "Schirmherrschaft" des Repos wichtig.

Viele Grüße
hasechris92

 

[fabian]

@hasechris92 es sind hier ein paar dinge vermischt

1. der technische punkt im bug handling - wir wollen nicht mehrere diskussionen parallel fuer dasselbe thema, deswegen werden neue eintraege als duplicates markiert (unabhaengig davon welchen status der "erste" bug hat)
2. wir wollen keine hook scripts die dann selber wieder pbs tasks starten, hierfuer gibt es zwei "bessere" loesungen:
- direkt die tasks selber starten/schedulen (dafuer gibts ja das CLI/API interface!)
- den task scheduler im PBS erweitern um solche dependencies abbilden zu koennen
=> deswegen ist der bisherige bug auf WONTFIX
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 - bitte entsprechend den ersten bugzilla eintrag (https://bugzilla.proxmox.com/show_bug.cgi?id=4639 - der der derzeit auf WONTFIX steht) erweitern, wenn die argumentation nachvollziehbar ist wird er dann REOPENED

der hauptgrund warum nicht "einfach" hook points eingefuegt worden sind ist dass die dann ja auch ueber einen langen zeitraum stabil gehalten werden muessen - wir (als entwickler:innen) haben ja keinen einfluss darauf was die hook scripts dann machen..

 

[hasechris92]

Hi @fabian,

@hasechris92 es sind hier ein paar dinge vermischt

1. der technische punkt im bug handling - wir wollen nicht mehrere diskussionen parallel fuer dasselbe thema, deswegen werden neue eintraege als duplicates markiert (unabhaengig davon welchen status der "erste" bug hat)

Dies wollte ich nicht als komischen oder diskutablen Teil darstellen; Ich muss mich hier wohl falsch ausgedrückt haben. Ich bitte hierfür um Entschuldigung.

Aus meiner Sicht "komisch" an der ganzen Sache fand ich den Vorgang als Ganzes:
1. dcsapak lädt mich ein, einen Enhancement Bug zu eröffnen, da es so eine Funktion anscheinend noch nicht gibt. Es gab hierbei keinen Hinweis, dass es schon Bug Einträge dazu gibt.
2. Bug von mir eröffnet
3. @fabian schließt mit "Duplicate - Wontfix" mit Verweis auf mehrere andere Bug Einträge.

Meine Interpretation aufgrund der Aussage von @dcsapak war, dass die Entwickler diese Funktion noch nicht vorgeschlagen bekommen haben und das eigentlich ganz gut klingt. Dann kommt aber nur ein Verweis auf alte Bug Einträge und die Klassifizierung "Wontfix". Ich habe daher die Antwort in den alten Bugeinträgen negativ interpretiert aka "Jop, wir haben drüber nachgedacht, werden wir nicht einbauen (können?)". Das Stichwort "Necrobump" kommt mir auch noch in Kopf - die Reaktionen auf einen Necrobump sind auch immer wieder sehr heftig.

Hier möchte ich noch anmerken: Meiner Erfahrung nach wird es als unhöflich bzw. teilweise sogar als anmaßend/grenzüberschreitend erachtet, einen bereits geschlossenen Bug mit einem "Wontfix" einfach nochmal zu eröffnen. Auf vielen Platformen hat man heutzutage auch gar keine Möglichkeit mehr, einen geschlossenen Bug aus Sicht des Users einfach wieder zu öffnen (siehe Github/Gitlab etc).

Daher danke @fabian für die Klarstellung und auch die weitere Möglichkeit einer technischen Diskussion über diese mögliche Funktion (falls ich das jetzt richtig verstanden habe).

2. wir wollen keine hook scripts die dann selber wieder pbs tasks starten, hierfuer gibt es zwei "bessere" loesungen:
- direkt die tasks selber starten/schedulen (dafuer gibts ja das CLI/API interface!)
- den task scheduler im PBS erweitern um solche dependencies abbilden zu koennen
=> deswegen ist der bisherige bug auf WONTFIX


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 - bitte entsprechend den ersten bugzilla eintrag (https://bugzilla.proxmox.com/show_bug.cgi?id=4639 - der der derzeit auf WONTFIX steht) erweitern, wenn die argumentation nachvollziehbar ist wird er dann REOPENED

Hm, ich glaube mein Englisch ist einfach nicht gut genug für das notwendige Verständnis der Bugeinträge. Können wir in der Unterhaltung einfach nochmal neu starten?

Ich hätte gerne eine Funktion im PBS wie die Hook-Script-Funktion im PVE. Damit könnten Administratoren dann irgendwelche Befehle (Wichtig: Ich meine hier Non-PBS Tasks) ausführen. Ich spreche hier von Bash-Skripten, die zusätzlich notwendige Tasks abschießen und dann wieder an den PBS-Job zurückgeben. Bei mir wäre es als Erstes die Integration meiner Healthcheck Instanz, aber da könnte in Zukunft natürlich noch mehr dazukommen.

Einen Overhaul des Task Schedulers im PBS klingt ziemlich anstrengend und zeitaufwändig; der Invest müsste sich ja auch in irgendeiner Weise für euch als Firma auszahlen. Kundenorientierung ist ja schon wichtig; wenn keiner der Kunden dieses Feature braucht macht das gar keinen Sinn.

Direkt die Tasks selber triggern würde bedeuten, ich baue einen eigenen Task Scheduler.. Hilfe, wo ist meine Freizeit hin

Zu Punkt 3: Guter Use-Case für hook script auf PBS... Puh. Das ist so eine absolut nicht-technische Definitionssache. Was ich als Hobby-Enthusiast super gut und wichtig erachte ist den zahlenden Kunden wahrscheinlich vollkommen egal Das ist meiner Meinung nach keine gute Bewertungsbasis, auf der ein Wontfix oder ein Reopen entschieden werden kann. Was wäre für dich denn ein ausreichend guter Use-Case, der die Entwicklung rechtfertigen könnte?

der hauptgrund warum nicht "einfach" hook points eingefuegt worden sind ist dass die dann ja auch ueber einen langen zeitraum stabil gehalten werden muessen - wir (als entwickler:innen) haben ja keinen einfluss darauf was die hook scripts dann machen..

War das denn ein Problem beim PVE mit dem vzdump script? Ja, hierzu besteht natürlich das Risiko. Aber ich wüsste bei diesem Argument schon gerne, ob nur von einem theoretischen Szenario oder von echten Wartungsproblemen gesprochen wird.

Sorry für die Wall of Text, vielen Dank für die Diskussionsmöglichkeit

hasechris92

 

[dcsapak]

Meine Interpretation aufgrund der Aussage von @dcsapak war, dass die Entwickler diese Funktion noch nicht vorgeschlagen bekommen haben und das eigentlich ganz gut klingt.

nur dass ich mich auch mal dazu melde:

Mea culpa. ich habs vorgeschlagen weil ich nicht am schirm hatte dass es dazu schon Diskussionen bugs gab. Generell ist es wohl gut immer zuerst nach einem bug zu suchen bevor man einen aufmacht, je nach wording schlägt bugzilla einem sogar schon offene bugs vor die dazu passen können, ist natürlich etwas beschränkt und kommt auf die genauen Worte an.

Ich hätte gerne eine Funktion im PBS wie die Hook-Script-Funktion im PVE. Damit könnten Administratoren dann irgendwelche Befehle (Wichtig: Ich meine hier Non-PBS Tasks) ausführen. Ich spreche hier von Bash-Skripten, die zusätzlich notwendige Tasks abschießen und dann wieder an den PBS-Job zurückgeben. Bei mir wäre es als Erstes die Integration meiner Healthcheck Instanz, aber da könnte in Zukunft natürlich noch mehr dazukommen.

[...]

Direkt die Tasks selber triggern würde bedeuten, ich baue einen eigenen Task Scheduler.. Hilfe, wo ist meine Freizeit hin

naja nicht wirklich, ich glaube @fabian hat eher gemeint man baut sich ein skript das folgendes tut:

# execute pre backup tasks
[...]
# execute backup via vzdump/pvesh/curl/etc...
# execute post backup tasks
# e.g. notify/trigger verify/etc.
[...]

also quasi anstatt es im pbs zu code, an der stelle wo auch die backups gemacht werden

und dieses dann zb via cron oder systemd-timers zu starten (das dann das eigentliche 'task scheduling' macht)

Zu Punkt 3: Guter Use-Case für hook script auf PBS... Puh. Das ist so eine absolut nicht-technische Definitionssache. Was ich als Hobby-Enthusiast super gut und wichtig erachte ist den zahlenden Kunden wahrscheinlich vollkommen egal Das ist meiner Meinung nach keine gute Bewertungsbasis, auf der ein Wontfix oder ein Reopen entschieden werden kann. Was wäre für dich denn ein ausreichend guter Use-Case, der die Entwicklung rechtfertigen könnte?

das können wir im vorhinein nicht wirklich beantworten. wenn uns bereits ein guter use-case einfallen würde, würden wir das feature wohl eher implementieren anstatt nach feedback zu fragen
also am besten einfach schreiben und dann können wir das evaluieren

War das denn ein Problem beim PVE mit dem vzdump script? Ja, hierzu besteht natürlich das Risiko. Aber ich wüsste bei diesem Argument schon gerne, ob nur von einem theoretischen Szenario oder von echten Wartungsproblemen gesprochen wird.

warum das bei vzdump so ist kann ich nicht wirklich sagen, war schon länger so, aber zb ein argument gegen solche skripte ist dass es sich so gar gut nicht mit dem permission system integrieren lässt, da es wohl als root (oder sehr privilgierter) user laufen muss.
da will man das zb nicht per api oder gui erlauben, damit hilft es aber auch nur denjenigen die es in der Dokumentation oder in Anleitungen finden.

oder was meinst du @fabian ?

 

[Falk R.]

Ich hätte gerne eine Funktion im PBS wie die Hook-Script-Funktion im PVE. Damit könnten Administratoren dann irgendwelche Befehle (Wichtig: Ich meine hier Non-PBS Tasks) ausführen. Ich spreche hier von Bash-Skripten, die zusätzlich notwendige Tasks abschießen und dann wieder an den PBS-Job zurückgeben. Bei mir wäre es als Erstes die Integration meiner Healthcheck Instanz, aber da könnte in Zukunft natürlich noch mehr dazukommen.

Hi, mal für mich zum Verständnis, bei welchen Jobs willst du das denn anhängen? An die GC oder Prune Jobs? Ich versuche für mich die Benefits zu erkennen um vielleicht auch auf neue Ideen zu kommen. Bisher hatte ich nirgendwo den Bedarf gesehen. Vielleicht führst du deine Ideen mal detaillierter aus um uns alle abzuholen und eventuell erkennen dann auch andere Leute die Benefits. (z.B. die in Wien sitzen )

 

[fabian]

Hier möchte ich noch anmerken: Meiner Erfahrung nach wird es als unhöflich bzw. teilweise sogar als anmaßend/grenzüberschreitend erachtet, einen bereits geschlossenen Bug mit einem "Wontfix" einfach nochmal zu eröffnen. Auf vielen Platformen hat man heutzutage auch gar keine Möglichkeit mehr, einen geschlossenen Bug aus Sicht des Users einfach wieder zu öffnen (siehe Github/Gitlab etc).

klar, einen uralt bug der schon mal "rejected" worden ist einfach wieder auf zu machen (oder noch schlimmer, bug status ping pong zu spielen ) kann bloed rueberkommen. auf einen alten bug mit neuen infos zu antworten (in etwa: "hey, hier waer mein (neuer ) use case fuer dieses feature - koenntet ihr eure entscheidung nochmal ueberdenken?") wird im normalfall ernstgenommen werden. kann natuerlich immer noch damit enden dass wir das feature nicht oder nicht sofort implementieren (z.b. weil technische gruende dagegen sprechen, weil noch irgendwelche blocker existieren die erst angegangen werden muessen, weils derzeit nicht weit genug oben auf der prioritaetenliste steht, ..). im zweifelsfall einfach freundlich nachfragen, dann beissen wir eigentlich nicht

 

[fabian]

Ich hätte gerne eine Funktion im PBS wie die Hook-Script-Funktion im PVE. Damit könnten Administratoren dann irgendwelche Befehle (Wichtig: Ich meine hier Non-PBS Tasks) ausführen. Ich spreche hier von Bash-Skripten, die zusätzlich notwendige Tasks abschießen und dann wieder an den PBS-Job zurückgeben. Bei mir wäre es als Erstes die Integration meiner Healthcheck Instanz, aber da könnte in Zukunft natürlich noch mehr dazukommen.

der teil ist mir schon klar soweit ichs verstanden hab haettest du gern den hook point fuer den healtcheck, weil du dort sowohl start als auch ende/status eines tasks deponieren willst, nicht nur das ergebnis wie bei den regulaeren notifications? eventuell liesse sich das naemlich auch in den notifications einbauen (optional).

Einen Overhaul des Task Schedulers im PBS klingt ziemlich anstrengend und zeitaufwändig; der Invest müsste sich ja auch in irgendeiner Weise für euch als Firma auszahlen. Kundenorientierung ist ja schon wichtig; wenn keiner der Kunden dieses Feature braucht macht das gar keinen Sinn.

das allermeiste laesst sich ohnehin auch ueber regulaere, zeitbasierte schedules erledigen. manchmal waere es halt optimaler, die genau abfolge abzubilden (beispiel: backup => prune => gc + tape sync, immer in dieser abfolge). aber ja, sowas sinnvoll zu designen ist nicht einfach, daher ist es auch noch nicht passiert.

Direkt die Tasks selber triggern würde bedeuten, ich baue einen eigenen Task Scheduler.. Hilfe, wo ist meine Freizeit hin

so wie @dcsapak oben beschrieben hat, meinte ich eher das einfache implementieren der gewuenschten "abfolge" in einem skript oder das triggern durch ein vzdump hookscript.

Zu Punkt 3: Guter Use-Case für hook script auf PBS... Puh. Das ist so eine absolut nicht-technische Definitionssache. Was ich als Hobby-Enthusiast super gut und wichtig erachte ist den zahlenden Kunden wahrscheinlich vollkommen egal Das ist meiner Meinung nach keine gute Bewertungsbasis, auf der ein Wontfix oder ein Reopen entschieden werden kann. Was wäre für dich denn ein ausreichend guter Use-Case, der die Entwicklung rechtfertigen könnte?

der grund warum ich hier so genau nachfrage ist dass uns bis jetzt kein wirklich guter use case eingefallen ist

die backups werden ja nicht vom server gesteuert, d.h. dort sollte der hook point auf client seite sitzen (was ja bei PVE/vzdump der fall ist, bei direkter verwendung des clients sowieso vollkommen frei was davor/danach passiert). gleiches gilt auch fuer restores, PBS ist heir ja nicht der aktive teil, sondern liefert nur die daten.

neben notifications aller art (wo wir lieber die luecken im notification system auffuellen wollen) gibts sonst noch die klassischen "setup/teardown" und "post processing" use cases - bei vzdump z.b.
- aufwecken/runterfahren des backup ziels (oder mount/unmount des backup storages)
- verschluesseln, weiterschieben, .. des backup archivs (bei "klassischem" vzdump)

mir fallen keine (oder sehr wenige) solchen aktionen fuer GC/prune/verify/sync auf PBS server seite ein. deswegen frag ich so "dumm" beim tape koennt ich mir z.b. vorstellen, dass es irgendwelche seltsamen setups geben kann die irgendwas spezielles beim tape wechsel ausfuehren muessen, aber bis jetzt ist (meines wissens nach) noch niemand mit einem konkreten beispiel daher gekommen.

War das denn ein Problem beim PVE mit dem vzdump script? Ja, hierzu besteht natürlich das Risiko. Aber ich wüsste bei diesem Argument schon gerne, ob nur von einem theoretischen Szenario oder von echten Wartungsproblemen gesprochen wird.

ja, wir haben z.b. extra job-init eingefuehrt weil wir nicht job-start anpassen konnten ohne eventuell bestehende hook scripts kaputt zu machen. in der praxis ist jedes stable interface eine einschraenkung fuer zukuenftige entwicklungen - natuerlich laesst sich meistens drum rum arbeiten, aber das endresultat ist dann nicht unbedingt immer das optimalste/schoenste. u.a. deshalb muss der tradeoff zwischen nutzen und aufwand (in der entwicklung, in der wartung, in der erhoehung der komplexitaet, ..) stimmen.

 

[nlsschmdt]

Da ihr explizit darum gebeten habt beim auftreten "neuer" Informationen Leichen auszugraben, mache ich das hier einmal. Da ich nicht sicher bin, ob es für mein Problem vielleicht eine ganz simple Lösung gibt, will ich aber nicht direkt den Bug vollschreiben.

Also mein Szenario ist folgendes:
Ich betreibe zwei PBS. Ich möchte gerne einen Sync Job einrichten, der die Backups von PBS-A nach PBS-B zieht. Dazu muss sich PBS-B per Wireguard mit PBS-A verbinden. Wie stelle ich es an, dass die Wireguard-Verbindung quasi bei sync-init aufgebaut und bei sync-end abgebaut wird? Genauso müsste vermutlich auch das Remote enabled/disabled werden (im PVE verfahre ich zumindest mit dem pbs-storage so).
Bei meinen Backups habe ich das gleiche Problem mit vzdump hook scripts gelöst...

 

[Dunuin]

Kannst du wegen Wireguard nicht einfach mit Systemd-Services arbeiten? Der Tunnel kann doch permanent bestehen bleiben und muss nicht nur da sein wenn der Sync läuft. Das wird man sicher irgendwie so einstellen können, dass da einfach alle paar Minuten versucht wird einen Tunnel aufzubauen, falls da dein zweiter PBS nur zeitweise an ist.

Fehlschlagende Sync-Tasks sind natürlich unschön in der 30-Tage Task-Übersicht. Aber du kannst ja einstellen, zu welchen Tagen/Uhrzeiten immer der Sync stattfinden soll und dann halt gucken dass der andere PBS immer dann auch an ist. So mache ich das jedenfalls hier.

 

[nlsschmdt]

Das einfachste ist aus meiner Sicht mittels cron oder ähnlichem dafür zu sorgen, dass der Tunnel aufgebaut wird, kurz bevor der Sync-Job stattfindet. Ich finde das aber äußerst unschön. Die Hooks sind aus meiner Sicht der sehr viel bessere Weg.

Ob ich bei meinem Szenario mit ständig wechselnden IPs den Wireguard-Tunnel einfach laufen lassen kann, weiß ich nicht. Ich fürchte er wird einfach ins Leere laufen und "niemand" merkt, dass er nicht mehr funktionieren kann. Hier kann man natürlich auch herumtricksen, den Tunnel permanent auf Funktion überwachen und ihn im Zweifel einreißen, aber schön ist das in meinen Augen auch nicht.

 

[Dunuin]

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.