AG:Technik/Protokolle/Meeting 2012-07-25

Aus Piratenwiki
Wechseln zu: Navigation, Suche

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

Dieses Protokoll im Pad: https://ppoe.piratenpad.de/TF-Tech-2012-07-25


Beginn: 25. Juli 2012 - 21:30 Uhr

Ende: 25. Juli 2012 - 24:00 Uhr  


Anwesend:

Gäste:

  • idler
  • kA

Entschuldigt:


Inhaltsverzeichnis

Agendapunkte

Infrastruktur

  • Server von Zols
    • 1 realativ brauchbarer Server
    • 1 sehr alter Server (pentium3)
    • Beide rack-mounted, und bei Eduardo
      • Brauchen günstigen einen Platz für Housing
  • Kartendrucker bei MeyGee
    • (nichts neues)
  • Flying Dutchman
    • (nichts neues)

Vilinthril:

  • Vorschläge für Server-Namen: Jolly Roger, Black Pearl, so was halt …
  • Vorschläge für Server-Nutzung: Mumble-Server? Pad-, Streaming-, Daten-Server? Transfer von Wiki/Website/Forum auf eigene Server? LQFB-VM einhängen?
    • Mumble braucht (nur) eine kräftige Netzwerkanbindung
      • verr: solang wir so knapp bei Kasse sind würde ich da unseren DE Nachbarn dankbar sein und da nix selber machen. Evtl kann man mal was spenden? eine weitere option wäre, da gemeinsam was aufzubaun? Evtl PPI? PPEU? Piraten ohne Grenzen? Nur so ein Gedanke.
    • piratepad viel RAM und eine eigene VM
      • Frage ob es da nicht sinnvoller wäre das auf einem hetzner Server zu lassen housing mit mindestens 100Mb symmetrisch dürfte auch nicht unter 50-60€ zu haben sein. Beides ist an sich auch nicht wirklich geheime Daten, Das Pad sollte aber besser in Österreich liegen (rechtliche Gründe)
    • lqfb braucht recht wenig, bisschen speicherplatz sonst stell ich keine hohe belastung fest - kann mich aber auch irren weil ich hab nur meine kleine testinstanz auf einem eigenen server beobachtet :)

TF:Technik Meetings

  • neuer Termin?
  • doodlecracy: Donnerstag, 20:00 (alle außer mik)
    • verr kann's so richtig fix erst zu Semesterbeginn sagen, aber 20:00 is OK.
    • mik: ich war nur mit mittwoch 21 uhr zufrieden, mir sind aber aktuell prinzipiell egal, wann das treffen is - ob ich kann oder nicht, seh ich erst im herbst.
      • Mal versuchen, vielleicht klappt das donnerstags besser. Wir könnten dann ab nächste Woche den Donnerstag nehmen.
  • "Beschluss": TF:Technik Sitzung ab sofort jeden Donnerstag um 20:00!

Status Mailserver neu

  • "ziemlich fertig"
  • deutlich besser als der alte Server.  \ o /
  • wie migrieren wir die Daten? 
    • Backup
    • "rießiges Datenpaket" rüberschieben?
      • Migrieren mit Opt-In 
    • von 0 anfangen, alten Server als abhol-Backup laufen lassen?
      • -> User hinweisen dass sie selber sichern sollen.
        • Anleitung bereitstellen
        • Möglicherweise neuen Server auch unter einer neuen Adresse für die Mailclients (nicht zB. mail.piratenpartei.at)
    • alte Adressen bestehen lassen verwirrt die Leute?
    • Gelegenheit nutzen um Nominklatur anzupassen

Bundesforum

  • Forensoftware: Entscheidungsprozess läuft, erstes Meeting war am Montag
  • Kommunikation: Redmine und IRC
  • Support-Adresse: tba
  • Evtl. Koordinierung mit eventueller TF:Forenmoderation
  • Wo soll das drauf? (Test-VM, und die dann produktiv schalten)
    • (Eilt nicht, aber bei Gelegenheit halt.)
  • Wie machen wir SingleID/SignOn jetzt eigentlich? Über MeyGee's Konnektoren?
    • openID? OAuth?
    • größtes Problem: Bestehende Accounts
    • OK, wir bleiben also Foren-seitig mal komplett offen und schaun dann das wir da die neue MV darauf hinbiegen können, oder so.
    • (SingleID wär Ziel, SingleSignon is' quasi Utopie)
    • (Kerberos? Aufsetzen, Zeit-Synchronisierung, etc, ...)

=== LQFB 2.0 === 

lava: bin erst ab 22:30 da :(

Beim Liquid Feedback Server gibts ein paar Punkte die mir nicht ganz klar sind:

  • gizmo hat Security Audit vorgeschlagen, wie ist da vorzugehen? Wer darf so einen Security Audit überhaupt durchführen?
    • Audit für die ganze IT wär praktisch, sobald sie "fertig" ist.
  • Prozesse @ Sicherheitsmaßnahmen definieren? http://wiki.piratenpartei.de/LQPP/Betriebsdoku#Prozesse_LiquidFeedback-System_und_Clearingstelle
  • Protokollierung der Verfügbarkeit?
    • Wer erstellt Backups?
  • Mails versenden? Mach ich das richtig? (exim4 + absender ist lqfbsupport@piratenpartei.at, macht das probleme mit dem echten piratenpartei.at mail server?)
  • verschieben auf subdomain lqfb.piratenpartei.at ohne portangabe? +1 bzw. https proxy dort leitet auf die tatsächliche instanz weiter...
    • grundsätzlich kein Problem, ich will die Domain aber erst freischalten, wenn die VM einigermaßen "fertig" ist (theoretisch ist es sogar schon lqfb.piratenpartei.at im proxy eingetragen, es gibt nur keinen Eintrag im DNS Server)

TF:Tech Personalpolitik

  • Aufnahme von Forenteam-Leuten in die TF:Technik

Diverses

  • Webshop
    • derzeit liegt die Verantwortung bei der LO-NÖ, eduardo hat das Merchandising abgegeben
  • undelivered Mail
    • Workflow für Tickets?
    • Weiterleitung auf den mv@ Account (Bitte von Maus)
  • Zugang zu allen Servern eher mit Public Key Crypto anstatt Passwörtern?
    • Liste, wer wo Zugriff hat?
      • vertagt
  • Helpdesk plugin für's Redmine kaufen?
    • Genauer evaluieren und evtl. zusammenlegen (36$)
      • Was wir brauchen:
        • CRM, also zB Konversationen im Ticket abbilden?
          • Antwort auf Ticket Mail macht derzeit ein neues Ticket -> nervig
          • Antwort auf Ticket bekommt der externe Ersteller nicht mit -> ungut -> nur auf Mail antworten -> neues Ticket -> siehe oben
          • => so wie man CRM halt kennt, man mailt hin und her, und im Redmien sieht man dann halt bei einem (!) Ticket die ganze Konversation. Eventuelle unter-Punkte kann man dann ja splitten. 
        • (Sichtbarkeit von Tickets -> spart Eingang)? 
          • ->  mik:eingang muss bleiben, wegen eventuellen sensiblen daten in den mails
          • -> verr: deshalb ja "per default versteckt". also nicht das ganze projekt sondern nur einzelne tickets, und mailscript-tickets per default versteckt, oder so.
          • -> mik: ja genau so isses ja derzeit, mailscripts-tickets landen im eingang (also versteckt) und werden dann manuell bei bearbeitung in technik verschoben, wenn keine sensiblen daten drin sind.
          • -> verr ja, aber ich würds cool finden, wenn man da keinen eingang bräuchte, sondern nut "technik" und neue tickets sind eben nur für mitglieder?
          • mik: es gäbe schon die option "privat" bei tickets, müsste man mit dem mailscript auch setzen können, allerdings is halt umständlich, weil du die eigenschaft nur siehst und ändern kannst, wenn du "mehr" klickst beim bearbeiten. OK, man sieht schon, dass sie privat sind (nachdem man draufgeklickt hat) trotzdem muss man noch "mehr" klicken, um es zu ändern. sichtbarkeit müsste man jetzt noch testen.
          • verr: was ist einfacher? das ändern oder projekt verschieben?
          • mik: privat abhackeln is 1 klick mehr, beim verschieben kann ich ja status usw. ändern und einen kommentar dazuschreiben. subprojekt hat noch den vorteil, dass z.B. die forenmoderation oder wiki die ja unterprojekte sind, die sensiblen mails auch nicht unbedingt sehen - sonst würden die auch andere sehen, oder? das eingang unterprojekt finde ich persönlich übersichtlicher, man könnte, wenn gewünscht, einstellen, dass unterprojekts-tickets nicht im übergeordneten projekt angezeigt werden, dann wäre das ganze klarer abgegrenzt.
          • verr und mik haben's getestet: geht genau so wie geplant.
        • schönere Anbindung Mail<->Redmine? -> statt dem script gäbs noch eine möglichkeit, dazu muss man aber am mailserver was ändern (kann ich bei bedarf mal raussuchen)
    • http://redminecrm.com/projects/helpdesk
    • http://demo.redminecrm.com/projects/helpdesk
    • Pro: würde uns viel arbeit erleichtern und ersparen (und wahrscheinlich das Problem unterhalb lösen)
    • Contra: Spricht gegen unsere Open Source/Free Software-Politik
    • Alternative: 
      • Derzeitiges Mail Script aufmotzen -> mik: schätze ich für schwer bis unmöglich ein (zumindest ohne redmine-addon developer/guru)

Redmine: Feedback für Ticket-Ersteller

  • Derzeit ist es glaube ich so, dass benachrichtigungen über Veränderungen an Tickets nur dann erstellt werden, wenn man selbst das Ticket sehen könnte. Damit gehen effektiv ein Haufen von Bearbeitungen an den Tickets am eigentlich Betroffenen vorbei.
  • Optionen?
    • Helpdesk Plugin siehe vorheriger Tagesordnungspunkt.
  • In diesem Zusammenhang auch der Antrag von der LO Salzburg - eben dass Leute die Mails an die LO schicken, eine "Ist angekommen" Meldung bekommen.

Diverses

Ende: 24:00

Meine Werkzeuge
Namensräume

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