Discourse und DokuWiki (u.a.) in NextCloud integrieren
===

[TOC]

# Protokoll vom 8.11.2018

## Anwesende
Micha Bakonyi, Flo Humer

## Abgleich der Rechte und Gruppen
MB: Wie sieht denn der aktuelle Stand eurer Entwicklung aus?
FH: Wir haben mittlerweile ein eigenes LDAP-Frontend im Nextcloud integriert. Ziel des FEs war Minimierung von Komplexität von LDAP im Vergleich zu anderen Frontends:
- Man kann Nutzer und Gruppen anlegen.
- Man sieht schnell, welche Berechtigungen die User haben und in welcher Gruppe sie sind
- Alle wesentlichen Felder, die in Discourse oder Nextcloud Nutzer- oder Gruppenbezogen von Belang sind sind in diesem Frontend verfügbar. Bspw. auch das Speicherplatz-Feld aus Nextcloud.
- Zusätzlich kann das Frontend Aktivierungsmails an NutzerInnen für deren Accounts schicken, über den die NutzerInnen ihr Passwort setzen können.
- Man kann die Discourse-Kategorienberechtigungen via Discourse-API setzen
- Der API-Call fragt alle Kategorien und die Gruppen ab, die für die einzelnen Kategorien Berechtigungen haben
- Die Discourse-Gruppen und die LDAP-Gruppenbezeichnungen sind identisch

Auch beim Löschen eines Users findet ein Abgleich statt.

MB: Ist es möglich, dass Sub-Projekte - in eurem Fall einzelne Hausprojekte - ihre NutzerInnen selbst verwalten? Oder passiert das zentral vom Dachverein aus?
FH: Zentrale Nutzerrechte-Vergabe - einzelne Gruppen können nicht selbst verwalten/administrieren.

## Bots für Discourse
FH: Es ist klar erkennbar, dass die Nutzer*innen v.a. das Discourse verwenden – das Wiki wird eher mäßig gelesen und befüllt. Nextcloud wird auch genutzt und der Kalender dann, wenn man ihnen aktiv die Synchronisation am Handy zeigt/einrichtet.
Wir sind daher nun der Meinung dass es Tools-mäßig eine Anlaufstelle geben muss. Wir sind dabei einen Bot zu entwickeln der für alltägliche Dinge den "Integrator" spielt. Klassisches Beispiel: wir haben versch. Teams, die sich um versch. Dinge kümmern. Es gibt bei uns im Haus einen Mail-Posteingang, der von einer Person betreut wird – die verschiebt die Mails aus dem Eingang in Unterordner. Eig. sollten die Teammitglieder ihre Unterordner checken, was aber nicht passiert. Das übernimmt jetzt der Bot: er checkt die Mails und schickt Discourse-Mails, dass eine neue Mail da ist.
Die nächste Ausbaustufe wäre, das Tasks-Plugin von Nextcloud entsprechend in Discourse zu integrieren: der Bot checkt also bspw. wenn Aufgaben nicht erledigt sind.
Da Web-Softwares immer mehr APIs anbieten wäre das Ziel, den Bot weiter auszubauen, sodass Discourse die zentrale "Kommandozentrale" wird, was sie sowies de facto ist.

### Hardware
MB: Welche Server-Hardware habt ihr am Start?
FH:
- 4Kerne virt. Maschine 8GB Ram
- läuft gut

MB: Wieviele User sind im LDAP?
FH: ca. 200

MB: Habt ihr ein Monitoring laufen, welches checkt, wieviele User gleichzeitig aktiv sind und wie sich dies auf die Performance auswirkt?
FH:nein, nur Ausfall-Monitoring

MB: Wie ist die Performance? (Wann) kommt es zu Peaks?
FH:
- bisher keine Performance-Engpässe, jedoch gibts aktuell ein Problem mit NC, dass sie alle 2-3 Tage für 2Minuten hängt. Hängt aber ggf. an Konfiguration
- Arbeitsspeicher wird langsam knapp v.a. wg. Elastic Search + Collabora

MB: Muss LDAP auf gleichem Server wie andockende Software laufen oder kann NC und Webseite etc. auf separaten Servern laufen für bessere Performance?
FH: NC, Collabora, Datenbanken, Elastic Search, LDAP etc. läuft in einzelnen Docker-Containern + somit auf einzelne Server verteilbar

### User + Gruppen
MB: Ist es möglich, dass sich User selbständig am Discourse anmelden und noch nicht im LDAP landen und dann später administrativ ins LDAP übernommen werden werden?

FH: man ist ggf. auf SSO von NC reduziert, eine separate Anmeldung am DC ohne SSO ggf. nicht möglich.
Micha: ggf. braucht es dann ein extra Discourse für den öffentlichen Bereich ...

### Administration + Support
MB: Wie ist deine Abschätzung für Pflege- und Support-Aufwand?
FH: Folgender Aufwand fällt an:
- Anlegen von Usern
- Feature-Requests
- Endanwender-Support wird an Peers abgegeben

MB: Ab wann bietet ihr Hosting? ;)
FH:
- 2034 :)
- nein, wollen das nicht Hauptberuflich machen
- auch wg. großem Initialaufwand
- eher Setup-Skript fertig machen + darüber dann (bezahlte) Support-Struktur anbieten a la SAAS

### Zeitplan Umstieg auf LDAP
MB: Kann man auch im Nachhinein gut auf LDAP umstellen oder müssen dann alle User ein neues PW bekommen?
MB: man kann in DC auf LDAP umsteigen, man muss jedoch schauen, dass dann die E-Mail zusammenpasst. Die User müssen sich dann ein neues PW setzen. SSO läuft so, dass NC mit Hash authentifiziert DC greift dann nicht mehr selbt auf Hash zu

### Zusammenarbeit und Vernetzung
MB: Braucht ihr Unterstützung?
FH:
- Ja! :)
- Leute mit KnowHow bzgl. Docker + Setup-Skript für Docker-Container + Continous Integration inkl. versch. Branches + Test-Server-Deployment etc.

MB: Inwieweit seid ihr vernetzt und fragt Leute an, ob sie Bock haben mitzumachen?
FH: Ich entwickle quasi allein aber konstant. Roland – mein Kollege – ist eher für Server-Infrastruktur zuständig. Durch die fehlende Manpower geht die Entwicklung recht schleppend voran. Wir sind jedoch mit Leuten in Wien vernetzt, die mal Interesse an der SSO-Lösung hatten.
Das Ziel war immer, ein Setup-Skript zu haben, welches die Konfigurations-Einstellungen, die wir gemacht haben, automatisch setzt. Das Skript gibt es auch, aber in einer sehr rudimentären Form und läuft noch nicht wirklich – ist aber in Entwicklung. Daher ist es aktuell sehr schwierig, einen Dev-Server aufzusetzen, der gut funktioniert. Es ist halt sehr aufwändig, ein solides Setup-Skript zu machen, habe ich auch unterschätzt.
Was gut machbar wäre: sich zunächst nur auf Discourse und Nextcloud zu beschränken und z.B. das Wiki draußen zu lassen. Das müsste auch ohne Setup-Skript gut laufen.

MB: es wäre schön, wenn verschiedene Gruppierungen, die in Richtung Nachhaltigkeit unterwegs sind, auch Geld zusammen schmeißen um für solche Lösungen, wie ihr sie entwickelt, monetäre Unterstützung leisten zu können, damit der Arbeitsdruck für die Entwickler weniger wird.

FH: Ich denke, es ist schwer, solche Projekt wie dieses zu monetarisieren. Einige der bestehenden Hausprojekte zahlen bei uns eine Hosting-Gebühr, womit ein bisschen Support-Aufwand vergütet wird, was aber weit weg ist von Tarifen in der Wirtschaft.
Ich fänd's super, wenn sich mehr Leute einbringen würden. Was halt fehlt ist eine Entwicklungsumgebung. Die Sachen liegen alle auf Github, man müsste das nur reorganisieren ... und Test-Server, Contious Integration Chain und wir sollten wieder mehr Fokus auf das Setup-Skript legen.
Wäre cool, wenn andere Organisationen die Software auch nutzen, damit dann mehr Motivation da ist, die Software auch von anderer Seite zu verbessern.
Die schönste Lösung für mich wäre: die Lösung, die wir haben, jedoch federated. D.h. jedes Projekt hat seinen eigenen kleinen Server, vllt. auch nur eine Docker-Instanz am gleichen Server. Und man kann ja via Nextcloud super Ordner über Nextclouds hinweg sharen – funktioniert leider auch nicht in jeder Nextcloud-App – und das wär's halt ultraschön, wenn man in Discourse eine Kategorie federated sharen könnte. Ich hab mir die Struktur von Discourse ein bisschen angeschaut und glaube, das ist fast nicht zu implementieren, aber hoffentlich täusche ich mich. Das ist aber ein Punkt, der mir schlaflose Nächte beschert mit unserer Lösung, da ich denke, dass in federated Lösungen die Zukunft liegt.
Unser Ziel ist ja, dass das Mietshaussyndikat richtig groß wird und da muss man halt drüber nachdenken, was sich langfristig gut betreiben lässt.
Und was aktuell richtig gut ist, dass die Leute automatisch, wenn sie in ihren Gruppen unterwegs sind, mitbekommen, was sich im Dachverein tut.
D.h. es gibt teilweise Kategorien pro Hausprojekt und zwei, drei öffentliche Kategorien.