Vorlage aus: https://wiki.freifunk-stuttgart.net/technik:administration:policy?s[]=policy
    Änderungsvorschläge bis zum Infra-WE mit Namen eintragen, Diskussion und Entscheidung dort.
    Wenn es um Toolentscheidungen geht, bitte Begründung einfügen.
    
Adminpolicy

Präambel
Ziel der Policy ist eine langfristig stabile Infrastruktur auf Basis von Vertrauen und freier Software zu haben. Das heisst für mich, dass ich eventuelle Schmerzen in Kauf nehme wenn ich Dinge reparieren muss die Leute mit entsprechenden Rechten aus Versehen kaputt gemacht haben, mehr Konfigurationsaufwand mit einer freien Software statt einer proprietären habe, oder mit einem Softwarepaket zur Distribution passend arbeite statt ein fertiges Image zu nehmen.

• - Vorschlag margau -
• Ersetzen durch:
• Ziel der Policy ist eine langfristige, stabile, effiziente und transparente Infrastruktur für den FFS zu schaffen. Basis dafür sollten sowohl Vertrauen, aber auch freie Software und "handwerklich gute" Strukturen sein.
• Dazu muss auch Mehraufwand für Absprachen, Einarbeitung in Konfigurationsmanagement, Versionsverwaltung etc., Entwickeln einer "ordentlichen" Lösung, Dokumentation und Monitoring in Kauf genommen werden.
• Gesamtziel sollte sein, die Administration in soweit zu konsolidieren, dass dieselben Dinge nicht auf viele verschiedene Arten gelöst werden, sondern auf eine ähnliche Art. Dies ermöglicht es dem FFS, die vorhandenen Ressourcen effizienter zu Nutzen und die Community so weiter zu bringen.
• ---
• - Vorschlag margau -
• Weiterhin soll versucht werden, die Administration so effizient wie möglich zu gestalten. Dazu zählt unter anderem die Vermeidung von strukturellen Redudanzen (Beispiel: Nur einen Ansatz zur Konfiguration)
• ---
• Adrian: der Änderungsvorschlag an der Präambel nimmt aus meiner Sicht wichtige Dinge raus. Die Idee hinter der Präambel war, dass allen klar wird, dass hier Menschen zusammen arbeiten die unterschiedliches Wissen und Erfahrung haben und deshalb die Einzelperson auch mal nicht die aus eigener Sicht beste Lösung bekommen kann, damit das System für mehr Leute zugänglich bleibt. Die 'so einfache Administration wie möglich' sehe ich eher als Brandherd als als hilfreich an, die Ideen was das sein könnte divergieren sehr stark. Was 'dieselben Dinge' sein könnten aus sicht eines Serviceadmins verstehe ich überhaupt nicht. Es gibt 1 Mailinglistenserver, 1 Mailrelay, 1 Ticketsystem, 1 Wiki. Zielt das darauf ab, dass z.B. die GW-Admins nicht ein anderes Wiki nutzen sollten als die Firmwarebauer? Oder dass, weil auf dem Mailinglistenserver Postfix läuft, jeder kleine Servicerechner auch einen Postfix braucht, statt z.B. nullmailer?

Leitfragen zur Entscheidungsfindung

• Was muss ich beachten um den Dienst die nächsten 3-5 Jahre auf dem sicherheitstechnisch aktuellen Stand zu halten?
• Welches Wissen ist nötig um den Dienst neu aufzusetzen?
• Was muss der Rest des Teams wissen damit ich selbst unnötig zur Problembehebung bin?
• Was muss ich beachten, damit der Zugriff von Clients und Nutzern auch nach einer Migration auf einen anderen Virtualisierungshost reibungslos möglich ist

Bereiche

Kommunikation
Wenn Dinge größer umkonfiguriert werden gibt es je nach betroffenem Publikum eine (kurze) Mail an misc@, infra@ oder gw-admins@

• - Vorschlag margau -
• Eingriff in bestehende Dienste, mit denen man nicht vertraut ist, erfolgt nur, wenn der Verantwortliche nicht erreichbar und Gefahr im Verzug ist. Die Eingriffe werden so gering wie möglich gehalten, wobei zunächst eine Kontaktaufnahme versucht wird. Negativbeispiel: unifi.freifunk-stuttgart.de 12.10 post mortem Analyse
• ---

Dokumentation
Jeder Host, Dienst und IP-Adresse muss in netbox dokumentiert werden.

• - Vorschlag margau -
• Jeder Host/VM/Dienst muss in Netbox mindestens mit Konnektivität (IPv4/IPv6), Verantwortlichem, Ort (Blech/Hoster) und, falls vorhanden, Monitoring und Backup dokumentiert sein.
• ---
• - Adrian:
• Netbox wurde nicht abgesprochen und ist mE auch nicht sinnvoll. Dokumentation sollte verteilt und offline funktionieren können. Eine Software die eine Datenbank benötigt bietet das so erstmal nicht. vgl. Mail an infra@, war in der ursprünglichen und via infra@diskutierten Policy auch nicht drin.
• Thommie: hier wird netbox als Dokumentations-Tool für FFS eV impliziert. Ich würde weiterhin Dokuwiki bevorzugen, allerdings in der aktuellsten Fassung. Es ist a) schon etabliert und in der Community bekannt, b) benutzerfreundlich auch für weniger-IT-affine Leute, c) sehr leicht administrierbar, d) Datenbank-frei und leicht zu sichern e) hat eine grosse Entwickler Community und zahllose Schnittstellen/Plugins usw.. Alle für eine langfristige technische Dokumentation relevanten Funktionen sind vorhanden. Netbox ist nur für den engen Bereich des Datacenter Inventory Management und IP Address Management sinnvoll, ggf. in Verbindung mit einer Automatisierung. Ob das speziell für die Gateway Verwaltung Sinn macht, kann ich nicht beurteilen. Für den Rest der FFS Infrastruktur sehe ich den Bedarf eher nicht.

Zugriff
Die Partei die für den Server haftet, bestimmt wer darauf Zugriff hat. Für Systeme die der Verein betreibt wird ein breites Adminteam angestrebt in dem technisch alle dieselben umfassenden Berechtigungen haben, diese aber verantwortungsvoll nutzen.

• Zugriff erfolgt nach Möglichkeit über individuelle Zugangsdaten und entsprechende Berechtigungen, z.B. via sudo
• ssh-Zugriff bevorzugt mit ssh-Keys statt Passwort
• Applikationszugriff möglichst über verschlüsselte Methoden, http sollte vermieden werden

In der Regel sollten Dienste mit einem Konfigurationsmanagementtool, z.B. Salt oder Ansible, verwaltet werden.

• - Vorschlag margau -
• In der Regel sollten Dienste mit dem Konfigurationsmanagementool X verwaltet werden. Dies gilt insbesondere, wenn Dienste von einer größeren Personengruppe verwaltet werden (Verein).
• Produktive Dienste sollten ausschließlich über das Konfigurationmanagementtool aufgesetzt werden, sodass ein manueller Eingriff nur im Fehlerfall notwendig ist. Hierbei sollte nur eine "Single source of truth" (git) zum Einsatz kommen, mit der alle Arbeiten. Konfiguration (Templates) und Daten (wie Rollen, IP's etc.) werden hierbei getrennt.
• ---

• --- Vorschlag margau ---
• Als Konfigurationsmanagement kommt aufgrund seiner Verbreitung im Freifunkumfeld Saltstack zum Einsatz.
• ---
• - Adrian zu beiden Punkten: ich bin von Salt und Konfigurationsmanagement für unsere Infrastruktur als ganzes nicht überzeugt. Ich sehe sinnvolle Einsatzgebiete nur in Teilbereichen. Auch die Salt-Informationen anderer Freifunk-Communities betreffen eigentlich nicht die Infrastruktur sondern vor allem die Gateways. Konfigurationsmanagement war in der auf infra@ abgestimmten Policy auch nicht drin.

Thommie: sehe ich ähnlich. Wieso muss man jeden mail und DHCP Server zwangsweise mit Salt administrieren? Das macht Sinn bei einer großen Zahl gleichartiger Systeme (>> Gateways). Bei allem anderen "drumrum" sehe ich den Bedarf nicht ...
    
Installation

• Bevorzugt werden Installationen auf virtuellen Instanzen auf von uns betriebener Hardware, d.h. wir können die virtuellen Instanzen vom Host aus notfalls warten.
• Hardware wird bevorzugt mit Virtualisierungslayer betrieben der auch ohne speziellen Client wartbar ist, z.B. Webfrontend
• virtuelle Instanzen sind bevorzugt auf Kontainerbasis, die sind deutlich Resourceneffizienter, wenn das nicht geht KVM.

Thommie virtuelle Instanzen sind a) virtuelle Maschinen, b) Docker-Container. Containerlösungen sind sinnvoll bei dynamisch skalierenden Last-Anforderungen oder für schnelle Testaufbauten oder für komplexe multi-container-Aufbauten (docker compose). In allen anderen Fällen sind klassisch virtuelle Maschinen meistens der bessere Weg.

Basissysteme

• Hardware: bevorzugt mit (serieller) Konsole und Proxmox als Virtualisierungsschicht

- Vorschlag margau -

• Provider: bevorzugt mit Option auf BGP-Upstream

---

• Kontainer/Instanzen:

1. 1. Debian stable, wenn testing nötig ist den Distributionsnamen verwenden, nicht 'testing', unstable kann durch apt-preferences fast immer vermieden werden
   2. NixOS (Vorschlag Jo)
   3. Ubuntu LTS
   4. DPKG-basiert
   5. RPM-basiert
   6. wenn die benötigte Applikation nur für andere Systeme automatisch aktualisiert wird auch andere

Thommie: ich rate zu Distributionen, die weit verbreitet und langfristig gepflegt und hinreichend gut dokumentiert sind. Also Debian oder Ubuntu LTS. NixOS ist eine Nische, ich kenne niemand, der das im professionellen Umfeld nutzt. 

Software

1. deb-basiert aus Repository automatisch aktualisierbar
2. nixpkgs in NixOS automatisch aktualisiert (Vorschlag Jo)
3. snap (Ubuntu)
4. rpm-basiert aus Repository automatisch aktualisierbar
5. automatisch aktualisierbares in anderen Formaten
6. .deb manuell installiert
7. nixpkgs manuell installiert (Vorschlag Jo)
8. .rpm manuell installiert
9. andere Formate
10. manuell installiert aus Sourcen, möglichst nur unter Verwendung eines Tools zur automatischen Paketierung a la „checkinstall“ in dafür vorgesehene lokale Pfade, explizit nicht '/usr/bin'

Betriebsstandort Konnektivität

• bevorzugt im FFS, IP-Bereich 10.191.255.0/24 in Absprache mit gw-admins/backbone
• offizielle/externe IPs werden für Dienste nicht direkt verwendet und sollten im FFS zum Betrieb nicht notwendig sein
• extern sind nur wirklich notwendige Ports erreichbar, z.B. über selektives DNAT, eventuell über vorgeschaltete Proxies für https/http

• - Vorschlag margau -

• • Management des externen Zugriffes und Routing über das Konfigurationsmanagement.
  • Management der DNS-Auflösung über Zonefiles im git
  • Für externe Zugriffe sollte IPv6, soweit möglich, bereits implementiert werden. Im internen Backbone sollte IPv6 spätestens dann implementiert werden, wenn IPv6-Exit aktiviert wird. Weitere Details bezüglich IPv6 bedarf besonderer Planung.

• --
• - Adrian: auch hier sehe ich ein Konfigurationsmanagement nicht als zielführend an. Die Konfigrationsdateien für die Firewall sind einfach strukturiert und z.B. git-fähig. Es macht mE keinen Sinn da Komplexität darüber zu stülpen.
• DNS-Zonefiles im git sind fehleranfällig und andere Bereiche müssten dafür Parser entwickeln, z.B. das Lastmanagment der Gateways. Das macht wenig Sinn. Wenn ein allgemeiner Überblick über den Zustand und die Änderungshistoprie gewünscht wird, ist ein regelmäßiger Export in ein git denkbar.
• Grundsätzlich ist es keine gute Idee den DNS-Server auf derselben Infrastruktur wie die Zielserver zu haben. Im Notfall kann dann nicht mal eben per DNS auf eine andere Maschine gewechselt werden.
• Nichts dagegen, dass IPv6 in den Diensten vorgesehen ist, die IPv6-Adressen würde ich nach aussen allerdings eher sparsam verwenden. Z.B. Mailversand mit IPv6 geht regelmäßig aufgrund von falsch konfigurierten Resolvern auf der Gegenseite schief. Die announcen zwar IPv6 für ihre Domain, bekommen dann aber den Reverse-Lookup für unsere Seite nicht auf die Reihe und lehnen Mail von uns entdprechend ab.

Applikationszugriff

• bevorzugt über Namen statt IP-Adressen

Backup

• will der Verein haben für alle Dienste die der Verein für relevant hält, d.h. eine eigene Instanz hat, dieses Backup können auch andere im FFS-Umfeld für FFS-Dienste nutzen
• Personen mit Adminzugriff auf einen Dienst dürfen zusätzlich eigene regelmäßige Backups machen
• wer die Installation macht, sagt wie/was gesichert werden muss, damit bei einem Teil- oder Totalverlust der Betrieb möglichst rasch wieder aufgenommen werden kann, das kann ein klassisches Backup sein, aber auch ein allen Admins verfügbares Skript das einfach eine neue, identische Instanz aufsetzt und anschließend die Applikationsdaten wieder einspielt

• - Vorschlag margau -

• • Wiederherstellen von Diensten/VMs bevorzugt über das Konfigurationsmanagement, nur die Bestandsdaten aus dem Backup
  • Ein Backup ist nur dann ein Backup, wenn es getestet ist

• ---
• ein Backup hat immer vollständig zu erfolgen, sollten wir ein Konfigurationsmanagementttool tatsächlich für sinnvoll halten und uns auch noch auf eines einigen, dann kann beim Restore (und erst dann) ja selektiv vorgegeangen werden.

Monitoring

• will der Verein haben, Basis check-mk, weitere Instanzen von anderen sind willkommen
• allgemeines Systemmonitoring, z.B. Netzerreichbarkeit, Plattenplatz
• Applikationsspezifisches Monitoring

• - Vorschlag margau -

• • Monitoring wird ebenfalls über das Konfigurationsmanagement eingerichtet, Pflicht für Produktivdienste

• - Vorschlag Marvin -

• • Prometheus
  • Immer Pflicht außer für reines Lab und ?ächste Woche neu bauen

• - Vorschlag Jo:

• • netdata
  • prometheus greift auf netdata zu: https://docs.netdata.cloud/backends/prometheus/

• ---
• - Adrian: ich kenne netdata nicht, das scheint erstmal lokales Monitoring zu sein. Was sind die Vorteile gegenüber check_mk, das hat insbesondere ein funktionierendes Autodiscovery.

Anforderungen an den Verein
Der Verein muss dazu Dinge bereitstellen, direkt oder als Auftrag

• Hardware Backupsystem
• Hardware Monitoringsystem 

• - Vorschlag margau -
• (physisch getrennt, z.B. eigenständige VM)
• ---

• Hardware Dienste

---

Anforderungen an das Pad:

• Nciht ganz so vielen langen Text. Da braucht man ja Jahre das alles überflogen zu haben!
• Okay, sorry, der war echt fieß getrollt. Bitte nicht böse nehmen!

Thommie: ich bin kein Freund dieser Pads, für komplexe Texte und Kollaboration ist das zu primitiv. Dann doch lieber klassisch ein LIbreoffice Dokument mit Kommentaren und das gesynct per Owncloud oder Nextcloud.  Oder, noch besser, "echtes" Online Editing mit Collabora oder OnlyOffice.