Proxmox

Der Verein betreibt mehrere Proxmox-Kisten.

Der Zugriff auf die Admin-Oberflaechen erfolgt bitte immer per HOSTNAME.pveadmin.freifunk-stuttgart.de. Hintergrund: damit kann man auch ueber den Reverse Proxy, die auf anderen Hosts laufen, zugreifen. Ausserdem bekommt man so ein ordentliches Zertifikat.

Jeder pve-Cluster hat ein lokales Netzwerk (Hetzner vSwitch/Crossoverkabel) das fuer die Kommunikation im Cluster verwendet wird. Getrennt davon gibt es L2-Netze fuer die Gaeste, die auf den Proxmox-Hosts laufen.

Die Hosts werden per PBS gebackupt, siehe /usr/local/sbin/backup_pbs.sh

Infos zum restore per proxmox-backup-client gibt es unter pbs.

Per Proxmox Backup.

In clustern bitte pro Cluster-Node extra Backup-Jobs anlegen, damit Notifcation per Healthchecks pro Node erfolgt

Es gibt per VXLAN ein Clusteruebergreifendes L2, ueber das die Gaeste miteinander kommunizieren koennen. Wird per Proxmox SDN konfiguriert.

Als L3-underlay dient der Babel-Backbone.

Es gibt ein paar Konventionen zum Setup, an die wir uns halten moechten.

• vmbr1: NAT für Gäste, Netz ist hier `10.0.CLUSTERID.0/24`. Die Mitglieder des Cluster haben die IPs 1-10. - bald alt wird auf gastnat migriert
• vmbr2: Layer 2 Freifunknetz, VLAN = Segment + 100. VLAN 255 ist Transfernetz in den Wireguard Backbone.
• vmbr999: externes Interface mit öffentlicher IP. Finger weg, bei Hetzner droht Serversperrung wenn hier unbekannte MACs oder IPs unterwegs sind!
• gastnat: Clusteruebergreifendes VXLAN fuer Gaeste-Kommunikation 10.0.3/24 - 2a0f:d607:e:1::/64 - Dualstack mit Firewall IPv4/IPv6
• services: Clusteruebergreifendes VXLAN fuer services die public IPv4/IPv6 brauchen 91.216.35.208/28 - 2a0f:d607:e:1::/64 - keine Firewall

Bei Hetzner kein Root auf ZFS, weil das Hetzner Rescue kein ZFS kann! Dann bitte mdadm RAID + LVM + ZFS (ja, wirklich).

Bitte alle IP-Adressen fuer Container und VMs im Wiki-Artikel Zentraler Backbone aus 10.191.255.0/24 reservieren. Das stellt sicher, dass alle Gaeste spaeter auch prinzipiell an den Backbone angebunden werden koennen.

Leiten sich aus dem letzten Oktett der Backbone-IP und der Cluster-ID ab:

Gast-ID = Cluster-ID * 1000 + letztes Oktett der IP

Also hat der Gast mit IP 10.191.255.123 auf Cluster 7 die IP 7123.

Es werden grundsaetzlich nur lokale Nutzeraccounts benutzt, damit die Nutzer die Proxmox-Shell verwenden koennen und ihr Passwort selbst per SSH setzen koennen.

Die Nutzerkonten auf Proxmox Hosts werden alle mit Ansible verwaltet.

Die Proxmox(!)-Gruppe ffs gibt den Nutzern Zugriff aufs Proxmox-Webinterface.

1. Nutzer im Ansible anlegen
2. Playbook all.yml laufen lassen.
3. Den Nutzer per pveum user add NUTZER@pam bei Proxmox bekannt machen. Das muss nur einmal pro Cluster und Nutzer gemacht werden.
4. Den Nutzer per pveum user modify --groups ffs nrb@pam zur Proxmox-Gruppe ffs hinzufuegen. Das muss nur einmal pro Cluster und Nutzer gemacht werden.
5. Nutzer kann sich per SSH einloggen und anschließend ein Passwort per `passwd` setzen, mit dem er sich im Proxmox einloggen kann. Das Passwort gilt jeweils nur für einen Host, nicht clusterweit.

Zum Zugriff auf Container/VMs per SSH kann der Jumphost verwendet werden

Anleitung gibt es im Infrastruktur-Ansible

Wer ein Freifunkprojekt hat, kann vom Verein einen Container bekommen. Voraussetzung ist Vereinsmitgliedschaft und/oder eine entsprechende Vereinbarung mit dem Verein. Der Vorstand kann hierzu Auskunft geben.

Ansible-Playbooks im Infrastruktur-Ansible

• create_container_z10a_gastnet.yml
  • erstellt einen LXC Container im gastnet
  • Dualstack IPv4/IPv6; IPv4 NAT
  • Inbound Firewall IPv4 und IPv6
  • ideal geeignet bspw fuer Webanwendungen
  • keine Portforwardings
• create_container_z10a_services.yml
  • erstellt einen LXC Container im services Netz
  • Dualstack IPv4/IPv6; kein NAT
  • keinerlei Firewall!

Die Playbooks reservieren autoamtisch IP-Adressen und erstellen DNS-Eintraege usw