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

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-06-25 (vorwoche entfallen)

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

---

Beginn: 02.07.2013 - 20:00 Uhr

Ende: 02.07.2013 - 21:40 Uhr

Anwesend:

• Considerator
• lava

Gäste:

Entschuldigt:

Agendapunkte

Wordpress

• considerator

• Ignitiondeck benutzt facebook api - tracking

defnordic: hab alle social media settings von ignitiondeck installiert - hats geholfen?

• • facebook api ist jetzt scheinbar inaktiv (paypal wir noch immer eingebunden - ist vermutlich nicht sinnvoll zu umgehen)

• varnish plugin hatte ein Problem mit https wordpress siteurls, behoben, jetzt sollten wieder die üblichen Änderungen den cache invalidieren.
• Bei der Gelegenheit hat sich gezeigt, dass derzeit deutlich zuwenig threads vom fpm erzeugt werdem, jetzt solten dadurch verursachte timeouts deutlich seltener sein. Zusammen mit varnish sollten die meisten flaschenhälse entschäft sein. Bleibt noch das captcha problem - die gehen alle ans Backend. Ohne die beiden captcha plugins wären auch die session cookies unnötig.

Varnish / Mobilebrowser Websiten

• von considerator

mobile Browserdetection

An sich eine ältere Angelengenheit - das Problem hat sich konkret mit der Überlegung zum scapegoat wordpress theme ergeben. Dieses hat an sich unterschiedliche Versionen ja nach Browsertyp (allerdings nur mobile / tablet / pc). Das macht aber SO gewaltige Probleme mit einem Webserverseitigen caching (egal ob varnish oder im wordpress selber). Daher habe ich schon länger gemäß der varnish best practice überlegt die Klassifizierung vom varnish erledigen zu lassen. Ich habe für die 3.x Version passend aus https://github.com/varnish/varnish-devicedetect und https://github.com/serbanghita/Mobile-Detect eine eigene Version generiert (aus der viel exakteren php library habe ich die useragent regexes per regex-transformation in varnish syntax überführt und noch die paar weiterführenden bot checks von der varnish library zusammengeführt. Damit würde dann ein passender header - X-UA-Device-Basic entsprechend gesetzt.

Allerdings ist das noch nicht gründlich getestet und das läuft auch nur auf dem künftigen proxy. (sprich: einsatzbereit ist es erst sicher in ein paar Wochen)

Trotzdem: künftige webseiten sollten auf diese browserdetection zurückgreifen, wenn mobile clients anderen content geliefert bekommen sollen.

Varnish 3.x

SNI bzw. SSL (via nginx) funktioniert bereits sehr gut. Auch die diversen workarounds um Angriffsvektoren und Forward Secrecy funktionieren laut ssl pulse: https://www.ssllabs.com/ssltest/analyze.html?d=wptest.piratenpartei.at

Varnish selbst funktioniert bei Wordpress & Mediawiki scheinbar fehlerfrei. Mit dem Forum gibt es ein kurioses Problem: alle seiten könnten gecached werden, nur https://forum.piratenpartei.at/member.php?action=login darf nicht durchlaufen (also muss pipe statt deliver/pass sein), sonst gibt es zB. mit firefox reproduzierbar immer #503. Allerdings die simple pipe option funktioniert "immer" (da sind mir noch keine Probleme aufgefallen). Mit dieser kleinen Einschränkung (mit expliziter Behandlung) scheint aber alles zu funktionieren. (Guests sehen bis zu 10 Minuten den alten Stand - da gibt es glaube ich keine cache invalidation funktion/plugin. Bei dem hohen Anteil von Benutzern wäre da vermutlich auch ESI fast Pflicht).

• lava: wie siehts egtl. mit ssl für uniliquid.at aus?
  • ist einsatzbereit, nur eben derzeit auf der 2. IP von stonekeeper (ehemalige forum.piratenpartei.at). Das ganze ist wenn mir kein Fehler unterlaufen ist, ein vollständiger Ersatz vom derzeiteigen Proxy (incl. Konfiguration). Bis auf DNS und bei Mediawiki/wordpress ein geändertes Ziel für die purges, absolut einsatzbereit. Das ganze hat auch ein paar Vorteile gegenüber der aktuellen Lösung (siehe oben).
• cool :)

Projekt: Benutzerverwaltung (komplett über Admidio?)

• Teamleitung?
• Mitarbeiter werden gesucht die zumindest PHP und SQL können
  • lava wird 4 Informatiker fragen...

• • vermutlich technisch gesehen sinnvoll das entweder als reiner Adapter oder als LDAP schnittstelle auszuführen
  • lava: Hätte das ähnlich gelöst wie bei Forum und Wiki usw. - d.h. lokale regelmäßige abfrage vom admidio...
  • würde ich in beiden Fällen so machen. LDAP hätte nur den Vorteil, dass die Lösung nicht so spezifisch auf eine bestimme Application ist, bzw. eine Erweiterung der Tools nicht unbedingt weiteren Aufwand bedeutet.
  • lava: dafür mehr Einarbeitungszeit/arbeit nötig ;) ich hab da eine idee die recht unkompliziert sein dürfte... admidio erlaubt ja die beliebige erweiterung um neue rollen --> berechtigungen
  • Ein weiterer Faktor ist auch, dass teilweise ein connector auf eigentlich nicht standardisierte Schnittstellen zugreifen muss um die verschiedenen Tools einzubinden und ein update/upgrade kann da durchaus etwas durcheinander bringen. Etwa der Wiki connector will mit wheezy nicht so recht zusammenarbeiten (die Ursache ist aber glaube ich in diesem Fall in der restlichen Logik).

Nächste Sitzung

• lava schickt einen Doodle aus?
• Dienstag, 09.07.2013, 20 Uhr
• Pad zur Sitzung: https://ppoe.piratenpad.de/AG-Tech-2013-07-09