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

Aus Piratenwiki
Wechseln zu: Navigation, Suche

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:

Gäste:
Entschuldigt:

Inhaltsverzeichnis

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

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

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Pirat*innenpartei
Mitmachen im Wiki
Werkzeuge
Drucken/exportieren