Administration

Johannes Rudolph
Webanwendungen
Zuständig für Webanwendungen
Stefan Dunkel
Server Backend
Administration von Hoods Puppetentwicklung
Simon Kurka
Administration von Hoods Puppetentwicklung
Björn Franke
Serveradministration
Clemens John
Anwendungs-Administration

 

Das Team kümmert sich um die Administration der Severlandschaft und um die Wartung und Instandhaltung der Community-Tools

Das Team

  • Ansprechpartner: Simon Kurka

  • Mitglieder: Simon, bjo, Tarek, Floh1111, stefan6, Kaspar, picardEikeBaran, Adrian Heeren, Jens Ellerbrock 

  • Kommunikation: öffentlichen Mailingliste des Admin Teams

  • Git-Repository: https://git.nordwest.freifunk.net/ffnw/admin-team

  • Tätigkeiten 
    • Planung und Beschaffung von Serverkapazitäten 
    • Installation, Konfiguration und Wartung 
      • Webserver mit allen erdenklichen Tools vom Blogsystem über Monitoring und VPN bis zum Warenwirtschaftssystem 
      • Routing mittels verschiedener Routingprotokolle 
      • Supernodes 
      • ICVPN 
      • Exit-Gateways 
    • Rechtliches

Server

Grundsätze

Systeme mit konstanter Last sollten auf dedicated Servern laufen um das Fair-Use Prinzip von geteilten Ressourcen auf VMs nicht zu untergraben (Beispiele: Supernodes, Netmon-Datenbank, Build-Server) Systeme mit unregelmäßiger Last sollten aus Kostengründen auf virtuellen Systemen laufen (Beispiele: Webkram, Testserver, Monitoring) Kritische Ressourcen sollten nicht auf dem selben Hostsystem laufen (bspw. sollten Web, Supernode und Monitoring nicht auf dem selben Hostsystem laufen. Wenn Web ausfällt (Hadware kaputt, Angriff, Fehlkonfiguration), sollten wir im Monitoring schauen können woran das liegt, wenn ein Supernode ausfällt, sollten wir per Web veröffentlichen können das etwas kaputt ist und im Monitoring schauen könne woran das liegt usw… Supernodes sollten im Sinne der Dezentralität mehrheitlich von privaten Teilnehmern gehostet werden. Hierbei geht es um demokratische Fragen, aber auch um das Problem, dass wir bei der Bündelung von Netzwerk-Teilnehmern (z.B. DHCP-Leases) auf der Juristischen Person des Vereins möglicher Weise Gefahr laufen unter Regelungen wie die VDS oder Überwachungsmaßnahmen zu fallen und dem sollten wir vorbeugen indem wir Supernodes kapseln. Wir müssen wirtschaftlich planen. Die Grundsätze stellen ein Ideal dar, dass sich nicht zu 100% erfüllen lässt. Gute Kompromisse auf kurze Sicht, Anstrebung des Ideals auf lange Sicht ist das Ziel. 

Anforderungen Supernode

2 Cores (1 für Router-Peers (Fastd), 1 für Supernode-Transit (Tinc)) 1GB RAM (es geht auch mit 500MB, aber 1GB wäre gut für Puffer) 20GB Festplatte Traffic 

Anforderungen Web

Min. 6GB RAM 

Account-Management

Verantwortliche Accountmanager sind picard und Hilko. Diese beiden Personen sind berechtigt und beauftragt die Zugangsdaten des Freifunk Nordwest Netzwerks zu verwalten. Administratoren sind verpflichtet neue Passwörter dem Accountmanagement bekanntzugeben. 

Zugriff und Speicherort

Zum Zugriff sind Notwendig 

  • Vertrauenswürdigkeit 
  • Datenschutzerklärung 
  • Emailadresse und PGP-Key 
  • Zugriff auf das Admin-Git 
  • Zugriff auf das KeepassX Masterpasswort 

Zugangsdaten werden in einer KeepassX-Datei (Version 2.x) in unserem Admin-Git gespeichert: 

Passwörter eintragen

Jeder, der Zugriff auf die Passwort-Datei hat, darf und soll Passwörter in die Datei eintragen. <!> Dabei ist zu beachten, dass Git die Passwort-Datei nicht mergen kann. Daher ist vor jeder Änderung ein Git-Pull und nach jeder Änderung unbedingt ein Git Push auszuführen. 

Wer keinen Zugriff auf die Datei hat, kann einzutragende Passwörter mit einer GPG verschlüsselten Email an picard senden. 

Fehlende Passwörter (BITTE NACHTRAGEN)

Dokumentation

Alle Administratoren sind dringend angehalten die von ihnen betreuten Dienste technisch zu dokumentieren. 

Technische Dokumentation

Liste aller technischen Dokumentationen für die vom Admin-Team begleiteten Dienste siehe Technik/Dokumentation

Benutzerdokumentation

Liste aller Dokumentationen für Benutzer der vom Admin-Team begleiteten Dienste siehe Benutzer/Dokumentation.