Dokumente managen mit agorum und Kopano

Einer meiner Mitstreiter aus unserem Verband – Stefan – wird nicht müde, mir die Vorteile seines Dokumenten-Mangement-Systems (DMS) agorum aufzuzählen. Zwar ist es für den rein privaten Einsatz „etwas“ mit Kanonen auf Spatzen geschossen, weil es aber eine passende App im Univention App-Center gibt und ich mich sowieso gerade mit den Kopano Files beschäftige, habe ich es mir einmal genauer angesehen. Den Hintergrund zum oben stehenden Bild habe ich ja erst vor kurzem in meinem Blog über die Kopano Files und ownCloud erklärt. Einer der bärtigen Lego-Männer spricht in diesem Beitrag WebDAV – und zwar mit Stefans agorum ;-).

Dokumenten-Management-System / agorum

Die Definition von Dokumentenmanagement [1] würde wohl mindestens einen eigenen Blog-Beitrag erfordern. Grob gesagt wird hier die Suche nach abgelegten Dokumenten deutlich vereinfacht, indem beliebige Schlagworte und Metadaten mit Dokumenten verknüpft werden. Weiterhin werden Dokumenten versioniert und können mit Prozessen versehen werden. Gerade letzteres finde ich spannend (wenn auch komplex): Durchläuft zum Beispiel ein Urlaubsantrag im Unternehmen mehrere Stellen bis zur Freigabe, so kümmert sich das DMS darum, wer im nächsten Schritt was machen muss. So weit will ich hier aber gar nicht gehen, das können Stefan und seine agorum’s sowieso viel besser erklären.

So wie für Kopano gibt es auch für agorum eine App im Univention App-Center. Auf einem Univention-System kann diese per Mausklick installiert werden. Sie warnt jedoch gleich vorab, dass sie einen hohen Ressourcenbedarf von mindestens 1GB freien RAM hat. Wenn man das System nur oberflächlich nutzt, begnügt es sich auch mit weniger – habe ich für Euch probiert. Die Installation verläuft auffällig unauffällig, auch wenn sie aufgrund der Größe des Servers etwas mehr Zeit in Anspruch nimmt. Sobald sie erfolgreich abgeschlossen ist, erscheint auf der Willkommen-Seite des Univention-Servers einen neuer Link in das agorum-Home-Modul.

agorum einrichten

Zunächst war ich etwas ratlos nach der Installation. Zwar konnte ich in der Benutzerverwaltung nun anklicken, dass ein Benutzer auch agorum nutzen darf, doch geschah zunächst nichts. Ich merkte also schon, dass es sich hierbei nicht um einen Selbstläufer handelt ;-). Die App installiert agorum in das Verzeichnis /opt/agorum/agorumcore. Hier begann ich dann auch zu suchen …

Wichtige Informationsquellen:
doc/agorum-core-datasheet.txt (Installations-Protokoll)
jboss/server/default/log/server.log (Log-File)
agorum Wiki [2]

Ein Blick in das oben angegebene Logfile offenbarte mir, dass regelmäßig ein „UserImportService“ startet. Scheinbar war ich nur zu ungeduldig und mein markierter Benutzer war bei agorum noch nicht angekommen. Ich probierte es noch einmal und siehe da … Es ging. Gleich als nächstes realisierte ich, dass die Version 7.5.5-3415 schon ein paar Tage älter ist. Ein Blick in die Update-Sektion des Wikis [3] verriet mir, wie ich schnell und einfach ein Update ausführen konnte. Das herunterzuladende bin-File war 433 MB groß und die Installation dauerte bei mir ca. 15 Minuten. Aber wie schon geschrieben erfüllt mein Server ja auch nicht ganz die Minimalanforderungen von agorum – vermutlich geht es sonst schneller.

Ich verzichte im folgenden einmal auf blumige Beschreibungen meiner Erfahrungen der letzten 24 Stunden und gebe einfach die Schritte an, die mich zu einem nutzbaren System brachten:

1. In der Univention-Benutzerkonsole dem Administrator und allen weiteren gewünschten Benutzern Zugriff auf „agorum core“ geben. Nach dem Speichern dauert es eine Weile, bis diese Benutzer in die agorum-Benutzerverwaltung synchronisiert werden.
   
2. Als Benutzer „roi“ (Passwort: siehe Installationsprotokoll) an agorum anmelden und direkt zum Modul „desk4web“ wechseln. In diesem Modul gibt es links den Bereich Administration und darunter die Benutzerverwaltung. Hier gibt es den Eintrag „UserImport“, unter welchem dann die synchronisierten Univention-Benutzer zu finden sind. Die Zeile des Administrators habe ich markiert, den Benutzer über das Menü Bearbeiten -> Bearbeiten geöffnet und einen Haken bei „Administrator“ gesetzt. So wurde der Administrator ein Administrator ;-).
   
3. Besagter „roi“ ist der Standard-Admin des agorum-Systems. Es gibt ihn nur lokal bei agorum und nicht im Univention. Ich denke, dass man dessen Passwort in jedem Fall ändern sollte. Die Änderung kann im selben Dialog wie unter 2. beschrieben, jedoch im Bereich „SystemUser“, vorgenommen werden. Ein Doppelklick auf den „roi“ öffnet dessen Optionen, in denen sich das Passwort ändern lässt.
4. Es gibt viele Dienste die agorum selbst mitbringt. Dazu gehören auch Maildienste, die den Start meiner bereits vorhandenen Maildienste blockierten. Vor allem blockierte etwas den TCP-Port 587 und somit den Start von Postfix. Für administrative Eingriffe wie diesen bringt agorum eine MetaDB mit. Diese funktioniert so wie die Windows Registry. Im Baum unter „MAIN_MODULE_MANAGEMENT/roiprotocols/smtpextern/control“ findet sich der Parameter SSLPort des smtpextern-Dienstes. Dieser verwies auf den Port tcp/587. Da ich nicht herausfinden konnte, wie ich diesen Dienst abstellen kann, habe ich den Port kurzerhand auf tcp/2502 umgebogen. Im Anschluss musste ich einmal unter „MetaDB Cache“ den Cache leeren.
   
5. Beim Recherchieren zu all diesen Punkten stieß ich noch auf den „roihost“. Das ist ein Eintrag in der /etc/hosts-Datei, der wohl sehr wichtig ist. Bei mir verwies dieser scheinbare auf eine falsche IP-Adresse (localhost). Um auf Nummer sicher zu gehen, habe ich dies noch korrigiert. Das geht natürlich – Univention-like – nicht einfach über den Editor. Hier müssen UCR-Variablen gelöscht und gesetzt werden. Das sieht dann auf der Kommandozeile des Univention-Servers wie folgt aus:
   root@ucs:~# ucr unset hosts/static/<falsche IP-Adresse>
   root@ucs:~# ucr set hosts/static/<richtige IP-Adresse> roihost
6. Letztendlich habe ich das System neu gestartet. Damit konnte ich gleich sehen, ob auch alles in Zukunft passen wird.

Integration von agorum in Kopano

Man kann in agorum E-Mails über IMAP und den Mail-Adaptor [4] sichtbar machen. Für Personen, die fest im Workflow mir Dokumenten arbeiten und alles möglichst lückenlos dokumentieren kann das sinnvoll sein. Mein Anwendungsszenario geht aber in die andere Richtung: Das DMS kümmert sich um die Dokumente, deren Versionen und sinnvoll verknüpfte Ablage, Kopano übernimmt den Part mit der Kommunikation, zu der auch die E-Mail gehört. In Gesprächen mit unseren Kunden bekomme ich immer wieder das starke Gefühl, dass 10-20% der Mitarbeiter alltäglich in einem DMS arbeiten, während alle anderen nur mehr oder weniger regelmäßig Dokumente zuliefern. Und genau dieser größere Anteil integriert agorum bestimmt viel lieber in Kopano, als es umgedreht zu machen ;-).

Von den verschiedenen Schnittstellen, die agorum mitbringt, ist Stand heute WebDAV diejenige, über die eine Integration in die Kopano Files machbar ist. Der verlinkte Artikel beschreibt die Einrichtung des Files-Plugins, so dass ich mich hier nur auf die Konfiguration berufe. Meine größte Herausforderung war, die richtige IP-Adresse zu finden. Da agorum in einem Docker-Image läuft, brachte mich ‚localhost‘ nicht wirklich weiter. Letztendlich kam ich genau mit der IP-Adresse des oben genannten „roihost“ und folgenden Einstellungen in den Kopano Files weiter:

Der Account type ist „Webdav“, die Server address wie oben erklärt und – ganz wichtig – der Webdav base path ist „/webdav/privat“. Da alles auf meinem Univention-System stattfindet, kann ich die Kopano Credentials nutzen und muss Benutzername und Passwort nicht separat eintragen. Der Webdav base path hat mir einige Kopfschmerzen bereitet. Definiert wird dieser bei agorum in der oben schon genannten MetaDB im Pfad „MAIN_MODULE_MANAGEMENT/roiprotocols/webdav/control/SharePoints/“. Hier wird „privat“ dem DMS-Pfad „home/${USERNAME}/MyFiles“ zugeordnet, was genau meinen Bedarf erfüllt.

Letztendlich habe ich in den Kopano Files Zugriff auf meinen agorum-Bereich erhalten. Der Upload mehrerer Dokumente funktioniert darüber sehr gut und einfach. Um die wirkliche Power des DMS zu nutzen, müsste ich nun auf dessen Seite vermutlich noch etwas mehr Voodoo betreiben. Das überlasse ich aber gern denen, die wissen was da zu tun ist.

Fazit und Weiterführendes

Ein DMS lebt davon, dass es von Allen im Unternehmen genutzt wird. Ich denke, dass wir mit den Kopano Files die Hürde für viele Anwender sehr niedrig hängen und es denen, die wirklich vom DMS profitieren, damit auch leichter machen. Natürlich ist noch Luft nach oben: Als einen weiteren Schritt planen wir, die Files neben WebDAV auch mit CMIS auszustatten. Dieses Protokoll erlaubt dann – so sagt zumindest Stefan 😉 – viel mehr, wie zum Beispiel auch die Suche im DMS über dessen eigene Mechanismen.

[1] https://de.wikipedia.org/wiki/Dokumentenmanagement
[2] https://www.agorum.com/wiki/index.php/Kategorie:Main
[3] https://www.agorum.com/wiki/index.php/Agorum_core_Update_unter_Linux
[4] https://www.agorum.com/wiki/index.php/Kategorie:Mail-Adaptor