HomeLab

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Soo nach bisschen basteln funktioniert das sogar sehr gut.
USV geht an -> Webhook wird getriggert. Nach 2 Minuten ohne Strom wird ein Ansible Playbook gestartet und die zwei DS und der Proxmox Host fahren runter. Wenn Strom vor den zwei Minuten wieder da ist, dann wird das Ansible Playbook nicht ausgeführt.
Ich bin für heute zufrieden :)
 
  • Haha
Reaktionen: ctrlaltdelete

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Sehr gut. Ich muss das auch irgendwann mal noch hinbasteln. Bisher fahren die Proxmox-Hosts wie gesagt noch nicht herunter. Die DS war erst mal das wichtigste, denn die Hosts haben ja kein RAID.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Kann dir gerne als Inspiration die Dateien schicken bzw. Screenshots was ich bei DSM angehakt habe.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Ich hab gestern noch meinen Reverse Proxy mit Keepalived ausgestattet. Bin damit auch fast zufrieden. Muss das noch optimieren. Weil das ein Docker Container ist, ist der Wechsel leider nicht ohne Ausfall möglich. Er wechselt auf die Master IP, sobald sie verfügbar ist, aber da ist noch nicht der Container vorhanden. Aber das geht wohl mit einem Script was ich noch die Tage mal einbauen muss. Eigentlich wäre K8s die bessere Lösung dafür, aber im Moment habe ich noch nicht die Zeit mich mit K8s und was dazu gehört zu befassen und es aufzusetzen.
Aber die Lösung ist besser als als vorher.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Habs gerade mal mit dem Script probiert. Das funktioniert auch super. Es wird nur auf meinem Hauptserver geprüft, ob der Container Healthy ist, wenn er x mal Healthy zurück geliefert hat, dann bekommt er die virtuelle IP. Ansonsten läuft mein Zweitserver und verteilt die Anfragen. Jetzt nur noch Notifications einbauen, dass ich weiß welcher Server gerade aktiv ist.
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Beispiel Adguard, das läuft bei mir als LXC ohne Docker. Das macht es einfacher.
Du musst auf beiden Hosts erstmal Keepalived installieren mit sudo apt install keepalived
Dann gehen wir mal von folgenden Vorrausetzungen aus:

OS:
Ubuntu Server
Adguard Host 1 IP:
192.168.22.2
Adguard Host 2 IP:
192.168.22.3
Adguard IP die vom DHCP Verteilt wird:
192.168.22.4, dabei handelt es sich um eine virtuelle IP. Es gibt dazu keinen Host.

Folgende wird in /etc/keepalived/keepalived.conf gespeichert auf Adguard Host 1:
Code:
vrrp_sync_group ADGAURD {
  group {
    ADGUARD4
    ADGUARD6
  }
}

global_defs {
  router_id adguard1
}

vrrp_instance ADGUARD4 {
  state MASTER
  interface eth0
  virtual_router_id 55
  priority 50
  advert_int 1
  unicast_src_ip 192.168.22.2
  unicast_peer {
    192.168.22.3
  }

  authentication {
    auth_type PASS
    auth_pass woiubvskvbssbvwukvbskvj
  }

  virtual_ipaddress {
    192.168.22.4/24
  }
}

vrrp_instance ADGUARD6 {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 50
  advert_int 1

  authentication {
    auth_type PASS
    auth_pass woiubvskvbssbvwukvbskvj
  }

  virtual_ipaddress {
    fd00::2820:eaff:fecd:c71e/64
  }
}

Selbe Datei und Pfad auf Adguard Host 2 mit folgendem Inhalt:
Code:
vrrp_sync_group ADGAURD {
  group {
    ADGUARD4
    ADGUARD6
  }
}

global_defs {
  router_id adguard1
}

vrrp_instance ADGUARD4 {
  state MASTER
  interface eth0
  virtual_router_id 55
  priority 50
  advert_int 1
  unicast_src_ip 192.168.22.3
  unicast_peer {
    192.168.22.2
  }

  authentication {
    auth_type PASS
    auth_pass woiubvskvbssbvwukvbskvj
  }

  virtual_ipaddress {
    192.168.22.4/24
  }
}

vrrp_instance ADGUARD6 {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 50
  advert_int 1

  authentication {
    auth_type PASS
    auth_pass woiubvskvbssbvwukvbskvj
  }

  virtual_ipaddress {
    fd00::2820:eaff:fecd:c71e/64
  }
}

Dann mit
Code:
systemctl restart keepalived
systemctl status keepalived
Keepalived neustarten und den Status sehen.

Jetzt kannst du fd00::2820:eaff:fecd:c71e/64 und 192.168.22.4 als DNS Server verteilen lassen.

Priority 30 desto höher der Wert, desto wichtiger ist der Host. Das heißt, wenn Adguard Host 1 online ist, dann wird er der Master sein, weil sein Wert ist höher. Wenn er offline geht, dann übernimmt Adguard Host 2 die virtuelle IP. Das heißt die 192.168.22.4 zeigt immer auf den Host mit der höchsten priority. Das wars auch schon.
DEIN-PASSWORT ersetzt du auf beiden durch das gleiche. Ich hoffe ich habe nichts vergessen

Falls Interesse besteht, dass mit Notifications und einem Script zum Prüfen, ob ein Docker Container läuft, müsst ihr bescheid sagen.

Edit: Die Config oben wurde angepasst, weil es zu Problemen kam zwischen IPv4 und IPv6. Es kam vor, dass IPv4 zu Adguard Host 1 und IPv6 zu Adguard Host 2 gesendet wurde. Waren also immer beide aktiv. Deshalb wurde vrrp_sync_group eingeführt. Dies sorgt dafür, dass es synchron umgestellt wird. Seit dieser Anpassung läuft es zuverlässig.
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: plang.pl

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Herzlichen Dank. Ich hatte in dem Moment eher an die Konfig-Files der USV-Timer gedacht :ROFLMAO:
Aber dennoch schreibe ich mir das mal auf. Braucht man bestimmt mal :)
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Ahh das hab ich vergessen das ich das auch gemacht habe :p Moment... Das kommt gleich
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Also bei mir läuft auf dem Ansible Host folgendes das Paket Webhooks. Damit kann ich auf URL aufrufe Scripte aufrufen.
Step 1: Benachrichtigungen auf der DS konfigurieren:
1707157222224.png
1707157245803.png
Diese Zwei Benachrichtigungen brauchen wir.

Step 2: Webhooks auf der DS konfigurieren.
1707157326066.png
Method POST und JSON.
1707157378778.png
Method POST und JSON.

Step 3: Hooks beim hochfahren ausführen
Ich gehe davon aus, dass Webhooks installiert wurde. Verbinde dich mit dem Ansible Host per SSH und führe crontab -e aus.
folgendes hinzufügen:
Code:
@reboot /usr/bin/webhook -hotreload -hooks /home/ansible/hooks.json -verbose
Den Pfad zur JSON natürlich anpassen :)

Step 4: Hooks definieren
Öffne/erstelle die hooks.json und füge folgendes ein.
Code:
[
  {
    "id": "init-shutdown",
    "execute-command": "/home/ansible/shutdown.sh",
    "command-working-directory": "/home/ansible/",
    "trigger-rule": {
        "match": {
            "type": "ip-whitelist",
            "ip-range": "192.168.22.0/24"
        }
     }
  },
  {
    "id": "cancel-shutdown",
    "execute-command": "/home/ansible/cancel-shutdown.sh",
    "command-working-directory": "/home/ansible/",
    "trigger-rule": {
        "match": {
            "type": "ip-whitelist",
            "ip-range": "192.168.22.0/24"
        }
     }
  }
]
Die ID ist das, was in der URL verwendet wird. Pfade und Whiteliste anpassen, wer es aufrufen darf.

Step 5: Shutdown initialisieren
USV Springt an und triggert den Webhook init-shutdown. Das heißt das Script shutdown.sh ausgeführt. Folgender Inhalt ist drin:
Code:
#!/bin/sh
touch .shutdown
sleep 120 && ./check-before-shutdown.sh
Also eine Datei anlegen und 2 Minuten warten und dann ein anderes Script ausführen. Wenn die zwei Minuten um sind, dann wird check-before-shutdown.sh ausgeführt. Inhalt der Datei:
Code:
FILE=./.shutdown
if test -f "$FILE"; then
  /usr/bin/ansible-playbook /home/ansible/playbooks/shutdown-usv.yml
  rm "$FILE"
fi
Hier wird geprüft, ob die Datei aus dem ersten Script noch existiert. Wenn dies der Fall ist, dann wird das Playbook ausgeführt.
Das ist das Playbook:
Code:
- hosts: usv

  become: yes
  tasks:
    - name: shutdown
      community.general.shutdown:
        delay: 60

Step 6: Strom ist innerhalb der 2 Minuten doch wieder da.
Dann wird der Webhook cancel-shutdown getriggert. Also die cancel-shutdown.sh. Folgender Inhalt
Code:
#!/bin/sh
rm .shutdown
Also es wird einfach nur die Datei wieder gelöscht. Weil wenn sie nicht da ist, dann wird das Script aus Step 5 auch nicht ausgeführt.

Auch hier, ich hoffe ich habe nichts vergessen :)
 
  • Like
Reaktionen: plang.pl

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Okay, das sieht interessant aus. Ich hatte das bisher beim grob überfliegen glaube ich anders gesehen. Insbesondere denke ich, dass in den von mir überflogenen Beirägen nicht mit Timeouts gearbeitet wurde. Wie auch immer, danke für's Teilen. Das mit dem USV-Gedöns werd ich mir mit Sicherheit noch anschauen, das mit keepalived in naher Zukunft wohl eher nicht.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Gibt bestimmt noch eine elegantere Lösung, aber ist mir gestern nicht eingefallen. Aber meine Bash Scriptingfähigkeiten sind auch nicht so besonders :D
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Alter...
Ich hab da grad mal drüber nachgedacht. Das Thema "Scripte über Webhooks" hatte ich gar nicht auf dem Schirm... Da gibt es ja mal wieder 1000ende geile Dinge, die man damit umsetzen kann.
Naja.
Wie synchronisierst du die beiden AdGuard Instanzen? Vielleicht ist da für dich der Container AdGuardHome-Sync einen Blick wert. Hab ich schon lang im Einsatz, funktioniert einfach und gut.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Bei mir hat sich seit Ewigkeiten nie was dran geändert. Ansonsten wollte ich RSync einsetzen
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Achja ich starte und stoppen über die hooks auch meinen PBS oder lasse VMs neu starten die nach Updates ein reboot wollen:)
Das ist wirklich praktisch
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Ähh ja.. muss natürlich die .4 sein :)
Danke für den Hinweis
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Ich hatte das bisher beim grob überfliegen glaube ich anders gesehen. Insbesondere denke ich, dass in den von mir überflogenen Beirägen nicht mit Timeouts gearbeitet wurde.
Was meinst du damit eigentlich genau? Wenn ich etwas optimieren kann, dann bin ich dafür immer bereit :)
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Ich weiß es nicht mehr genau. Ich meine aber, man kann im Script Timer starten, stoppen und neustarten, die der NUT-Server selbst steuert und die nicht mit einem Timeout im Script hinterlegt sind. Da spart man sich auch irgendwelche Dummy-Dateien. Wenn ich soweit bin, schreibe ich hier nochmal
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Ah ok... Ich habe mir den NUT-Server noch gar nicht angeguckt :D Der Synology USV Server kennt meinen Host durch die Hooks nichtmal.
Aber bin sehr gespannt auf die Lösung mit dem NUT-Server. Vielleicht stell ich es dann auch um.
 


 

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