AG:Technik/Protokolle/Meeting 2013-01-29

Aus Piratenwiki
Wechseln zu: Navigation, Suche

Protokoll der letzten Sitzung im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-01-15 (vorherige Woche ausgefallen)

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


Beginn: 29.01.2013 - 20:00 Uhr

Ende: 29.01.2013 - 00:00

Anwesend:

Gäste:

Entschuldigt: Considerator: möglicherweise etwas verspätet (BSG Sitzung ab 19:00)

Inhaltsverzeichnis

Agendapunkte

Monitor von Stonekeeper

  • von: Considerator

Jetzt gibt es unter https://monitor.piratenpartei.at/stonekeeper/check_mk/ auch einen umfassenden Nagios am Stonekeeper. Auch wenn die URL etwas anderes andeutet, das läuft vollständig am stonekeeper (mit einem https Backendzugriff von Pound am lurchlaich).

  • sehr gut!

Status Buchungssystem

Ticketprobleme in Redmine

  • von Considerator

Die Mailboxen werden jetzt wieder analog zum alten Script einzeln eingelesen, aber mit den helpdesk. Das ist deutlich stabiler. Allerdings kommt es noch immer zu doppelten Tickets und die wenigsten Tickets werden als Fehlerfrei abgearbeitet deklariert. Es ist zumindest in der Vergangenheit teilweise zu einer grundsätzlichen Verweigerung bestimmte Mails zu verarbeiten gekommen. Kurioserweise fällt das twitter statusmail darunter. Die Frage ist nur, was sinnvoller ist, versuchen die Probleme/Fehler mit Redmine zu lösen (möglicherweise sehr aufwändig. Die Symtome deuten nämlich auf ein Multithreading/Locking Problem hin), oder eine Alternatives Ticketsystem zu finden, das unsere Anforderungen erfüllt. Das LQFB-Eingang Projekt spinnt jetzt - browsen erzeugt massenhaft Last. die Tickets selbst sind kein Problem...

  • OTRS Testbetrieb unter

https://ticket.piratenpartei.at/otrs/index.pl

Status wordpress

  • von Considerator

Trennung "statisch" - dynamisch

    • Es hat sich herausgestellt, dass die ganzen captcha Formulare etwas problematisch sind. Diese stellen genau genommen echt dynamischen Content dar. Ich habe vor kurzem die diesbezüglichen Probleme einigermassen umgangen, gelöst ist es noch nicht. Es wäre sehr hilfreich wenn wir diese vollständig dynamischen Dinge vom Rest trennen würden. An sich stellen diese auch eine absolute Begrenzug für die Disk-IO dar. Die Kommentar-Captchas erzeugen für JEDEN Aufruf Disk-IO. Außerdem erfolgt ein Teil der Interaktion von captcha/contact form über dynamische Seiteninhalte.
    • Eine Mögliche Lösung könnte sein, diese auf subpages mit klarer uri Kennzeichnung zu verbannen. zB. könnte man das Kommentarformular auf /postname/kommentar/ beschränken und normalerweise unten nur einen Link angeben. Das benötigt aber eine Modifikation des Themes. Vergleichbar dazu dann eben auf den anderen Seiten, wo man das Contact Form Plugin nutzt eben /dynamisch/ in den permalink einfügen. anderenfalls kann per Definition nur sehr beschränkt caching durchgeführt werden - es ist ja fast jede Seite davon betroffen...

scapegoat Theme

mehrsprachig? (Kärnten)

Frage aus Kärnten für eine mehrsprachige Seite.


Mailserver (Flying Dutchman)

  • von Considerator

Status? im Westen nichts Neues

Redmine

  • von Considerator

Wer kann Root Projekte erstellen (Sekretariat / SG)?

Abstimmung: Aufnahme paddy in die Taskforce Technik

  • Ja: Considerator, Zwitschi, lava
  • Nein:
  • Enthaltung:

Ergebnis: Aufgenommen

Forum PHP

Nächste Sitzung

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Piratenpartei
Mitmachen im Wiki
Werkzeuge
Drucken/exportieren