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

Aus Piratenwiki
Wechseln zu: Navigation, Suche
Arbeitsgruppe
Technik

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

Dieses Protokoll im Wiki:
http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-02-27

Beginn: 27.02.2013 - 19:15 Uhr Ende: 27.02.2013 - 21:00 Uhr Anwesend:

Gäste:
Entschuldigt:

Inhaltsverzeichnis

Agendapunkte

Agendapunkte (wiederkehrend von letzter Woche)

Status wordpress Comments

  • von Considerator

Wird vermutlich etwas komplizierter, vermute, dass bei dem mybb Zugriff kein postgresql berücksichtigt wurde. (zB. keine Option den Treiber/port etc. zu definieren, nur host + account/passwort)

Mailserver (Flying Dutchman)

  • von Considerator

Angeblich wird der langsam fertig.

  • 2x1TB RAID1
  • 2x2TB RAID1
  • 2x1TB RAID1 (softraid) (Desktop HD, für Backups)

Hostsystem fast fertig. Libvirt/KVM. Full disc encryption(LUKS), Mailserver: Postfiix+Dovecot(Maildir)/Postfixadmin

dev-Server

  • von Considerator

PostgreSQL Server ist jetzt auch am db-dev Server installiert und mit phppgadmin administrierbar.

Datenleck - Thema

  • von Considerator
  • Ideen wie wir/wo ggf. Einbruch nachweisen können?
  • Nachweis was noch auf dem IS Webspace war möglich
  • Andere Möglichkeit wäre noch dass das von dem alten backup/import? am POG DB server. Der war vergleichsweise etwas exponierter. Ist jetzt entfernt.

Serverausfall / Vorsorge

  • von Considerator

Ein Umzug von Stonekeeper auf einen EX4 Server wäre finanziell sinnvoll, performance sollte auch besser sein

    • Fragen dazu:
      • Derzeit hat der stonekeeper definitiv ein Problem mit der Festplatte, da verschenken wir bereits gewaltig was an möglicher Performance
        • Ich habe auch fsyncs von 3-12 gemessen, von proxmox werden da an sich 1000+ erwartet... http://www.deluxe-stylez.de/2012/05/09/proxmox-ext4-performance-probleme
          • den fix von dort probiert? relatime und/oder data=ordered ?
            • Ansatzweise ja, in einer VM, allerdings wollte ich das diese Woche fertig testen, aber ich habe von meinem anderer Laptop das Netzteil in der anderen wohnung gelassen und auf den anderen Rechnern habe ich kein passendes Testsystem drauf / einfach installierbar.
        • Es wäre also in diesem Punkt definitiv ein wichtiger Optimierungspunkt.
      • Wenn wir Ausfallssicherheit erhöhen wollen, kommen wir um ein redundantes System nicht herum. Damit stellt sich aber die Frage, wie diverse Bestandteile synchronisiert werden sollen. Ich weiss derzeit nicht, wie eine Replication zwischen mehreren Datenbanken funktionieren soll, wenn wir kein VPN zwischen den Servern aufbauen. Für ein paar Sachen wäre ein allgemeines VPN auch günstiger als viele separate ssh Verbindungen.
        • Und VPN und OpenVZ scheint ein gewaltiges Problem zu sein...
      • Ausserdem ist bei einem Umzug noch die Frage, was ist, wenn Unterstützung benötigt wird. Unnötige längere Zweigliesigkeit ist sinnlos.

OpenVPN auf host mit 10.0.0.0/16 Adresse

  • host dispatcht mit IPTABLES (ferm) auf interne 10.0.0.0/24-Adresse
  • VM erhält bei Bedarf ein weiteres Interface mit VPN-Adresse
  • write-back cache bei softraid möglich?

Da der Lurchlaich ohnehin dringend ein upgarde benötigt und mittlerweile fast alles wegmigriert wurde fängt eine etwaige Migration dort an. Wenn der Lurchlaich frei ist, empfiehlt sich erstens die Performance zu tunen (formatierunsparameter/file system/mount options). Zweitens wäre es vermutlich effizienter einen minimalen Datenverlust bei Stomausfall (trotz USV) zu tolerieren, wenn damit die Performance deutlich steigt. Es ist ohnehin geplant das System so aufzubauen, dass ein Serverausfall prinzipiell toleriert werden kann.

Wiki

  • von Considerator

Tendenzielle Frage: derzeit auf 1.18.6, was an sich das aktuelle bugfix release dieseser Version darstellt. der 1.19.x Branch wäre eine LTS Version, da dieser default bei Debian wheezy darstellt. Featuremäßig hat sich glaube ich kaum etwas zwischen 1.18 und 1.19 getan, etwas mehr zwischen 1.19 und 1.20. Die Frage ist, ob wir in Zukunft dann auf die debian Version umstellen wollen, oder weiter manuell upgraden.

  • lava: weniger (arbeit) ist mehr service... also vma auf die debian version umstellen damit sowas in zukunft (mehr) automatisch läuft
  • zwitschi: was automatisierbar ist, sollte automatisiert werden ;)
  • considerator: Ich installiere auf der dev1 VM einen mediawiki 1.19.x und teste das ganze vor dem deploy.

Lurchlaich

  • von Considerator

Upgrade und/oder Migration von Server: Was ist mit den restlichen VMs? (an sich sollten alle VMs prinzipell mit einem backup-transfer-restore auf den stonekeeper problemlos transferieren lassen. Bei den POG/PWB VMs ist die Frage, wie weit diese (temporär) transferiert werden können (zumindest Mailserver benötigt auch hier eine weitere IP, weiters hat rhinux derzeit eine eigene IP). Notdürftig wäre auch denkbar:

  • eben für ein paar Tage offline (bis Upgrade beendet).
  • Bei einem Parallellbetrieb (umzug auf neunen Server) sollten diese Probleme großteils ausfallen.

PWB VMs:

  • Planet -> file copy aus /var/www in neue VM
  • Wiki
  • Blog

Restliche Piratenpartei VMs:

  • initiative.piratenpartei.at
    • sollte überhaupt kein problem sein
    • müsste eh noch dringend auf https umgeschaltet werden
      • wer braucht da ssh zugriff?
  • dir (ldap?/obsolete?)
  • m.piratenpartei.at (monitoring lurchlaich) backup sollte reichen
  • s.piratenpartei.at (piwik)
  • graz.piratenpartei.at
    • afaik nur ein wordpress drauf
      • wer braucht da ggf. noch einen vm Zugriff.
  • ibinpirat.at
    • vorbereitet aber afaik immer noch nicht in Betrieb
  • Mailserver (3+1+1 VMs)
  • unipiraten (auf stonekeeper umgezogen)
  • proxy (gibt es ohnehin am stonekeeper...)
  • ssh
  • admin (gibt es ohnehin am stonekeeper...)
  • mailbackup (war für Effizienzsteigerung der Serversynchronisation (rsync) gedacht, noch nicht beendet - eh' nur beta)

Fazit: ausser mailserver (piratenpartei) und rhinux(piraten ohne grenzen) sind alle verbliebenen VMs überflüssig oder problemlos auf einen anderen Server migrierbar. Mailserver sollte mit einem Gateway davor (unabhängig vom flying dutchman) auch migrierbar werden.

Mail gateway

  • von Considerator

Bei meinen Recherchen hat sich herausgestellt, dass ein gateway an sich relativ einfach sein sollte, allerdings die Mailverdopplung lokaler Mailboxen etwas koplizierter wird (mögliche Lösungen habe ich schon gefunden). Ich denke im Zuge dessen die Ursache für das alte Mailverdopplungsphänomen bei mehreren Alias Adressen gefunden. Die Optionen werden in nächster Zeit getestet, wir brauchen das ganze ja auch für eine sinnvolle Lösung beim Forum (Mailinglisten) etc.

Nächste Sitzung

Von „https://wiki.piratenpartei.at/w/index.php?title=AG:Technik/Protokolle/Meeting_2013-02-27&oldid=26866“
Meine Werkzeuge
Namensräume

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