AG:Technik/Protokolle/Meeting 2013-02-12

Arbeitsgruppe
Technik
Übersicht Zuständigkeiten Protokolle Diskussion Geschäftsordung

Protokoll der letzten Sitzung im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-02-05 Dieses Protokoll im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-02-12

---

Beginn: 12.02.2013 - 20:00 Uhr
Ende: 12.02.2013 - 22:45 Uhr
Anwesend:

• Salsabor
• considerator
• Paddy
• lava

Gäste:
Entschuldigt:

• zwitschi

Agendapunkte

Newsletter

• von Salsabor

Wir brauchen ein hübschere Design für das Newsletter System

• Aufruf für ein Design? (bisher nur auf Funktion optimiert)

Status wordpress Comments

• von Considerator
• Das passende Plugin dürfte dafür sein: http://wordpress.org/extend/plugins/mybb-cross-postalicious/
• Auf Dev1 ( https://dev1.piratenpartei.at/piratenkleider/ bzw. http://dev1.piratenpartei.at/testforum/webroot/ ) läuft esjetzt. Eigentlich ist das Plugin recht komfortabel. Ein paar Kleinigkeiten sind vielleicht nicht ganz perfekt (keine pretty permalinks? Funktionalität mit Postgresql noch nicht getestet)
  • eventuell den Post auch in Forum duplizieren
    • bis nächste Woche testen, dann ggf. ausrolen.
• Wordpress-Plugin - automatisches Posten von Artikeln im Forum als Ersatz der Kommentarfunktion:
• von Paddy

http://wordpress.org/extend/plugins/wordbb/

Forum

• von Paddy
• Forum: aktive AGs/nicht mehr existente AGs, welche brauchen noch Forenbereiche, welche nicht?

Neuer Bereich "weitere AGs" mit Unterforen für die inaktiven/weniger aktiven AGs

scapegoat Theme

• von Considerator
  • Mal ein paar Instanzen davon am devserver aufgezogen (derzeit noch default)

Mailserver (Flying Dutchman)

• von Considerator
  • Angeblich wird der langsam fertig.

dev-Server

• von Considerator
  • Dev1 ist am Samstag fertig geworden, Dev2 nach dem selben Prinzip aufgebaut, noch nicht gündlich getestet. Accountvergabe sollte mit dem Script recht simpel sein (siehe dokuwiki)
    • statt Rewrite wäre Alias besser

app-Server (Produktiv-Instanz)

• von Considerator
  • Minimalinstanz, aber sonst wie Dev1.

Datenleck - Thema

• von Considerator
  • Letzte Woche gab es ziemliche Spekulationen, auch im Zusammenhang mit dem Serverausfall.
• Ideen wie wir/wo ggf. Einbruch nachweisen können?
  • keine weitergehenden Ideen, wir können nur ein paar Details ausschliessen.
• Ideen zur Verbesserung:
  • Angriffsflächen des Hostsystems minimieren
    • Zugang zu ssh/vnc etc. begrenzen.
      • ports geschlossen halten (erledigt)
      • ungenutzte User entfernen
      • remote logging?
      • public key authentication
      • ACL / user zentral verwalten / Datenbank
    • Patchlevel aktuell halten
    • ssh nur über proxy
    • sudo statt root/su?
    • verschlüsselte Partition?
    • verschlüsselte Backups?
  • IDS?

Serverausfall / Vorsorge

• von Considerator
• Ideen zur Vorsorge:
  • Redundante Server & Clustering.
    • Pro: Ausfallssicherheit, zumindest für alles hinter dem Arbiter. Performance scaling sollte besser sein (load balancing).
    • Contra: synchronisation der cluster notwendig, Extra Kosten, besonders wenn HA gefordert (minimum bei hetzner 15+5€/Server? für die fast reassign IP)
    • Rootserver unter EX4 wenig sinnvoll (>=49€/Monat), mehrere Addieren sich da rasch auf, vor allem zusätzlich zu flying dutchman etc. Wie viel Budget haben wir?
  • Wordpress: sollte M/S Replication und rsync ausreichen, schreibender Zugriff muss auf MasterDatenbank Server begrenzt sein. Derzeit wegen der Kommentare nicht möglich -> weiterer Grund für Forum!
  • VPN zwischen den verschiedenen Servern vermutlich notwendig.
  • Forum: (Was ist in dem Sync-Forum eigentlich das Mastersystem? OS ? Ubuntu, war wegen Reddit so, sollte irgendwann mal auf Debian umgestellt werden)
    • Datenbank: vermutlich pgpool-II Replication/HA für die Datenbank am Sinnvollsten.
    • Mailinglisten: parallelle mailmans mit sync über das forum möglich? Alternative?
    • Newsserver: nntp sollte das ja eigentlich eine synchronisation implizit unterstützen.
    • grundsätzlich newsserver und mailinglisten in eigene VMs trennen, die Schnittstellen sind ohnehin nicht intern, dann wäre ein switch auf dns Ebene "automatisch korrekt".
  • Wiki: Mediawiki unterstützt prinzipiell replizierte Datenbanken, Memcached kann auch serverübergreifend sein.
  • Mail: jeder Server sollte an sich einen primären Mailserver und einen Backup-MX haben.
    • Fragen dabei:
      • Greylist bei mehreren Servern teilweise problematisch
      • Ich tendiere dazu den "primären" Mailserver als reinen Verteiler zu konzipieren.
      • wie synchronisieren wir die Mailserver - wichtig bei einem Ausfall.
        • simpel: rsync der maildirs (ist-stand). Problem dabei ist nur, dass das eigentlich nur ein reines Backup ist.
          • sauber synchronisieren nach dem ausfall ist praktisch unmöglich.

Allgemeines

• Ideen was noch verbessert werden könnte:
  • Update/upgrade Termin festlegen (Termin an der es downtimes geben könnte)
    • Strategie für synchronisation der cluster (so vorhanden) bei upgrades. Nach Ausfällen.
  • Frage auch welchen Arten von Ausfällen vorgebeugt werden soll (wie unabhängig müssen die nodes sein, wie stark automatisiert?).
    • Hardwareausfall (wie 5.2.)
    • Stromausfall
    • Netzausfall
    • Beschlagnahmung
    • DoS / Einbruch
  • IDS?
  • Technischen Fortschritt nutzen
    • zumindest laut der veröffentlichten Eckdaten (Hetzner) wäre ein leistungsfähigerer Server mittlerweile billiger zu haben (EX4, sogar EX4S / EX5 wäre billiger)
      • grundsätzlich positiv: Considerator, Lava, Salsabor
  • Mailserver ist ziemlich am Limit
    • Seit der Umstellung von Redmine verteilt sich die Last etwas besser.
    • langsame Reaktion / timeouts
      • flying dutchman (wäre weniger durch Festplatten begrenzt, gizmo wollte filesystem dahingehend optimieren) - nicht fertig?
      • optimierung Filesystem
        • optimale mount options?
        • Dateien auf mehr Verzeichnisse verteilen.
        • Teile der User / subdomains auf andere Server auslagern
        • Trennen von Versand/Empfang und Speicherung
• Eine Grundsatzfrage ist auch wohin wir das System in der Zukunft hin entwickeln wollen?
  • vernetzt
  • hierarchisch, zumindest bei der Account/Rechtevergabe
    • Single Sign On
  • Datenschutz
  • Datensicherheit
  • Ausfallssicherheit
  • Datensparsamkeit
  • Kosten

Nächste Sitzung

• Dienstag, 05.02.2013, 20 Uhr
• Pad zur Sitzung: https://ppoe.piratenpad.de/AG-Tech-2013-02-19