AG:Technik/Protokolle/Meeting 2012-12-11

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

Protokoll der Vorwoche im Wiki:  http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2012-12-04

Dieses Protokoll im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2012-12-11

---

Beginn: 11.12.2012 - 20:00 Uhr

Ende: 11.12.2012 - 21:45 Uhr

Anwesend:

• Considerator
• defnordic
• lava ab 20:07 mit Ton
• Zwitschi
• mschaf ab 20:08

Gäste:

• nuss
• Oesipirat

Entschuldigt:

Agendapunkte

Protokolle im Wiki 

2012-11-13 bis 2012-12-04 wurden durch Zener vom Pad übertragen, bitte zukünftig selbst mit machen

• Zwitschi: wird besser gemacht werden
• Considerator: Motivation das zu machen war im Keller
• Zwitschi: Überlegt ob nicht mehr Tickets in den öff. Bereich sollten
• cons: Wär eine Möglichkeit. Grad aktues Problem, dass das Kontakteplugin im öffentl. Bereich nicht aktiv ist, kann dann nichts zurück schicken - Helpdesk plugin
• Zwitschi: Man kanns anschalten und mailaccount auf "none" setzen, dann bekommt man keine Mails aber kann schicken
• Cons: ja wär eine option. wo die plugings nicht verfügbar sind, kann man keine mail aussenden.

• Zwitschi: hat Plugin jetzt auch für Technik-Überprojekt aktiviert.
• cons: tendenziell die tickets in den öffentlichen bereich verschieben, damit man sieht dass sie bearbeitet werden.

Transfer VMs

• von: Considerator

Transfer der VMs von Lurchlaich auf Stonekeeper

• Liquidfeedback
  • sollte technisch eher einfach sein (backup, copy, restore, reverseproxy/dns angleichen)
• Redmine
  • vergleichbar mit liquidfeedback, allerdings muss zumindest die IP angepasst werden.

• Wordpress (piratenpartei.at + LO's)
  • bereits vorbereitet auf stonekeeper. Einspielen der SQLDumps und ein rsync mit dem content folder sollte reichen + dns Anpassung
  • aktuell: stand 10.12. ~23:00, skripts vorbereitet, dns für switch optimiert. 

• Owncloud
  • VM hat eine ziemlich beschädigte owncloud installation. am besten Backup ziehen und ganze vm kopieren. Problem: sehr groß - lange downtime
  • Recovery der Owncloud Daten besser auf stonekeeper (in anderer vm?)

Allgemein: jeweils längere Downtime zu erwareten. Bei Redmine/LQFB rechne ich mit jeweils 1-4 Stunden Wordpress (Bund + 7 LO) dürfte im selben Zeitrahmen zu machen sein. (eher unter 1 Stunde) Owncloud dürfte >6 Stunden dauern.

Frage: WANN? Wie ankündigen bzw. wer muss verständigt werden?

Was ist mit den nicht ganz Standard-VMs (ichbinpirat, graz, initiative, basis)?

• Forum ? Auch nicht Standard? Da könnts Probleme geben aber mal schauen.
  • Forum ist derzeit sogar fast unmöglich - das braucht eine weitere externe IP, bzw. belegt es die Mail ports auf dem jeweiligen Server.

• Wordpress für Steiermark - gleich auf stonekeeper.

• lava: 1-4h für LQFB zu lang?
• cons: ist nur ein sicherheitspuffer.
• lava: sollen zeiten in LQFB dann verlängert werden, damit phasen gleich lang dauern. sollte das alles um die stunde downtime verschoben werden?
• defnordic: wenns schnell geht einfach machen, ja
• cons: dauert länger als es auf den ersten blick ausschaut. Backupzeiten auch schonmal >1h, allein datenübertragung dauert ein paar Minuten. LQFB und Redmine sind noch relativ einfach verschiebbar. Braucht nicht viel arbeit von außen.
• lava: Bei LQFB ists in der Nacht auch nicht so tragisch, server sind aufgrund der last dann eh schon kaum ansprechbar
• defnordic: ist mit der migration mit verbesserung der lastspitzen zu rechnen?
• cons: teilweise, weil der mailserver dann nicht mehr gemeinsam mit den VMs läuft. Wenn die Aktion stattfindet wenn der Server grad unter Last steht, wie bisher in der Nacht, dauert die ganze Migration natürlich dementspreched länger. Werden wir wohl einfach mal ankündigen müssen und dann spätnachts verschoben.
• cons: bei wordpress maschinen werden eigtl nur die daten verschoben. größtes sorgenkind ist owncloud, ist sehr groß, hat viele GiB, VM teilweise schon zerschossen, wird schwer das funktionierend zu verschieben. Allein weils da unbekannte Randbereiche gibt, die nicht-standard-VMs sind, da ist die frage was man da verschieben muss.
• lava: Initiative ist einfacher webspace
• cons: dann wohl eh relativ einfach.
• lava: graz.pp ist ein wordpress. auf unterverzeichnis liegt das spiel.
• lava: einen eigenen webspace-VM aufsetzen, für kleine unterprojekte die keine eigene root-VM brauchen.
• Zwitschi: wurde schon angedacht
• lava: gibt auch schon github repositories: https://github.com/PPOE
• Zwitschi: könnten auch ein eigenes git-repository im Redmine einhängen
• lava: sieht kein problem wenn das öffentlich ist, dürfen natürlich keine PW-dateien committed werden.
• Zwitschi: Würden ja nur das grundgerüst einchecken und keine produktive Version. Denkt es ist eh sinnvoll, dort unsere ganzen Sachen zu sammeln. eben Verbotszonenapp und was da noch so kommen mag.

• Cons: Zeitplan, wann wir verschieben wollen?
• Zwitschi: Interessant wirds wegen DAtenkbanken, weil wir DB-port uafmachen müssten und vorher umhängen, oder wir müssens pro DB machen und pro VM, einzeln die DB in den neuen DB Server einspielen
• cons: nicht ganz so kritisch, das geht per skript relativ halbautomatisch, geht innerhalb ein paar Minuten. Hat das gestern mal testweise durchlaufen lassen. die ganzen B-Seiten sind vom Stand von gestern abend. Home und Page option auf die neue domain gesetzt, damit die laufen.
• Zwitschi: Wenn wir nur eine webseite umziehen, dann die DB rüberschieben, damit www wieder d ist, dann haben wir bei der nächsten migration das problem, dass schon was geändert wurde. Lieber dass wir eine VM umziehen, dazu die Datenbank, dann erst die nächste

Umzug der Wordpress VMs (Bund, LOs) heute 24:00.
Owncloud: Zwitschi zieht VM auf Stonekeeper.

wordpress performance

• von: Considerator

caching etc. helfen nur teilweise. Derzeit frisst das Theme und die ganzen Plugins deutlich performance (site load times!).

Wir sollten einmal die ganzen derzeit genutzten Plugins durchgehen, was davon benötigt wird und ob wir teilweise unnötigen Aufwand vermeiden können oder caching/minify besser nutzen können.

cons: performance unterschied zw. leerer und normaler WP-installtion zw. 1-2s und bis zu 8s. Lässt sich tw. nicht vermeiden, aber großteils wohl einfach unnötig. Werden zT Sachen übertragen, die nichtmal einen Pixel unterschied machen im ergebnis.

Zwitschi: Stichwort für lighhtp ist mod-expire um caches zu überprüfen mschaf: varnish zum cachen Zwitschi: JS Sachen, CSS files, Wiki-Embed plugin cons: werden zum Teil nichtmal genutzt. plugins die vieles nicht genutzt wird, werden übertragen aber dann nichts bewirken. Zwitschi: ja müssen wir uns genauer anschaun. sieht aber nicht viel chancen. Cons: Dachte das schon, aber evtl ein bissl was verschieben, damit es effiizienter läuft Zwitschi: Mini-Fying könnte man sich noch anschaun, geht dann aber alles über einen anderen Server oder wir müssen zusätzlich noch ein Skript laufen lassen.

newsletter / phplist

• von: Considerator

VM soweit verwendbar. (eher noch Beta)

• Braucht BGF/TF-Newsletter noch Hilfe? Wenn ja, wobei?
• lava setzt sich mit TF Newsletter zusammen - evtl. einen gemeinsamen Termin mit dir?

cons: es gibt noch keinen tf-newsletter verteiler lava: hat einen eingerichtet cons: gibt ein plugin für wordpress, um php-list abonnement direkt in HP zu integrieren.

redmine mail read state

• imap ist ganz simpel --> ein script was mails als ungelesen markiert ist eine sache von wenigen minuten ;)
  • a001 login user password
  • a002 select inbox
  • foreach (reply "* OK [SEEN <ID>]")
    • a<i++> store <ID> -flags \Seen
  • a<i> logout

Verdopplung von Mails

• von: Defnordic

Teilweise werden (alle) Mails verdoppelt. Derzeit zB. beim redmine bgf@ Mailaccount.

Ursache zumindest Teilweise: mehrere Mailboxen hängen in diesem Alias drinnen. Den eigentlichen Auslöser ist noch nicht bekannt.

Nächste Sitzung

• Dienstag, 18.12.2012, 20 Uhr
• Pad zur Sitzung: https://ppoe.piratenpad.de/TF-Tech-2012-12-18