technik:administration:policy

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
technik:administration:policy [24.03.2019 - 18:00] – nrbtechnik:administration:policy [14.09.2026 - 14:36] (aktuell) – Docker Adrian Reyer
Zeile 2: Zeile 2:
 ===== Präambel ===== ===== 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. 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.
- 
 ===== Leitfragen zur Entscheidungsfindung ===== ===== Leitfragen zur Entscheidungsfindung =====
   * Was muss ich beachten um den Dienst die nächsten 3-5 Jahre auf dem sicherheitstechnisch aktuellen Stand zu halten?   * Was muss ich beachten um den Dienst die nächsten 3-5 Jahre auf dem sicherheitstechnisch aktuellen Stand zu halten?
Zeile 16: Zeile 15:
   * ssh-Zugriff bevorzugt mit ssh-Keys statt Passwort   * ssh-Zugriff bevorzugt mit ssh-Keys statt Passwort
   * Applikationszugriff möglichst über verschlüsselte Methoden, http sollte vermieden werden   * 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. 
 ==== Installation ==== ==== 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.   * Bevorzugt werden Installationen auf virtuellen Instanzen auf von uns betriebener Hardware, d.h. wir können die virtuellen Instanzen vom Host aus notfalls warten.
Zeile 31: Zeile 28:
     - wenn die benötigte Applikation nur für andere Systeme automatisch aktualisiert wird auch andere     - wenn die benötigte Applikation nur für andere Systeme automatisch aktualisiert wird auch andere
 ==== Software ==== ==== Software ====
-  - deb-basiert aus Repository automatisch aktualisierbar+  - deb-basiert aus Debian Distributions Repository automatisch aktualisierbar 
 +  - deb-basiert aus Herstellerrepository
   - snap (Ubuntu)   - snap (Ubuntu)
   - rpm-basiert aus Repository automatisch aktualisierbar   - rpm-basiert aus Repository automatisch aktualisierbar
Zeile 39: Zeile 37:
   - andere Formate   - andere Formate
   - 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'   - 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'
 +=== Docker und andere fertige Images ===
 +Das ist an sich weder gut noch schlecht. Es muss allerdings klar sein wie Updates erfolgen und ob die vollständig sind. Gut ist, wenn der Hersteller das Docker-Image auf jeweils aktuellem Softwarestand auch der Basis darunter anbietet. Wenn jemand mal eben die immer aktuelle Softwareversion auf ein veraltetes Basisimage legt hilft das nichts.
 +
 +Bestenfalls verträgt es die Software auch noch immer ein :latest-Image zu nutzen das über watchtower o.ä. aktualisiert wird.
 ==== Betriebsstandort ==== ==== Betriebsstandort ====
   * bevorzugt im FFS, IP-Bereich 10.191.255.0/24 in Absprache mit gw-admins/backbone   * bevorzugt im FFS, IP-Bereich 10.191.255.0/24 in Absprache mit gw-admins/backbone
Zeile 53: Zeile 55:
   * allgemeines Systemmonitoring, z.B. Netzerreichbarkeit, Plattenplatz   * allgemeines Systemmonitoring, z.B. Netzerreichbarkeit, Plattenplatz
   * Applikationsspezifisches Monitoring   * Applikationsspezifisches Monitoring
- 
-==== Dokumentation ====  
-Jeder Host, Dienst und IP-Adresse muss in [[https://netbox.readthedocs.io/en/stable/ netbox]] dokumentiert werden. 
- 
 ===== Anforderungen an den Verein ===== ===== Anforderungen an den Verein =====
 Der Verein muss dazu Dinge bereitstellen, direkt oder als Auftrag Der Verein muss dazu Dinge bereitstellen, direkt oder als Auftrag
  • technik/administration/policy.1553450453.txt.gz
  • Zuletzt geändert: vor 8 Jahren
  • (Externe Bearbeitung)