Alternative to Dokuwiki out of the box?

UCS - Univention Corporate Server
#1

Hi, i’m looking for a “out of the box” solution for
a) installing Dokuwiki on UCS (unfortunately it’s not available anymore as an app)
b) setting up an alternative maybe within Nextcloud

I like the straight forward aproach of Dokuwiki, the BlueSpice Mediawiki is fine but way to much for my needs.

I was also thinking of moving to Markdown-Files in Nextcloud, but then i have to problem of finding my content, because i’m not familiar (or i don’t want to dive to deep into installing stuff outside the univention) with the installation of an index-service like elasticsearch.

TL;DR: Any ideas how to get Dokuwiki running on Univention, or an simple alternative?

– German:
Ich suche nach einer Alternative zu Dokuwiki (welche ich bisher als mein eigene Wissensdatenbank eingesetzt habe), die leider nicht mehr in Univention verfügbar ist.
Als Alternative habe ich mich an Markdown-Dateien in Nextcloud versucht, das ist aber nur bedingt tauglich, da ich keine Volltextsuche habe, da ich kein Elasticsearch o.ä. innerhalb von Univention installiert bekomme.
Ich möchte auch nicht wirklich außerhalb der Univention etwas installieren (gerade der Ansatz, “alles” in einer fertigen Lösung zu haben, macht für mich den Reiz von UCS aus).

UCS5 and Dokuwiki
#2

Hi Gunni, I recently looked into BookStack and am quite happy with it. It cannot be installed as UCS app, but it is quite easy to get LDAP working. It supports Markdown and fulltext search and has a really good permissions system.

#3

Hey Andres,
thanks for your answer - but as mentioned I’m really looking for a solution within UCS.

So has anyone successfully installed a fulltext search within Nextcloud/UCS?

#4

I get that you want something that’s trivial to install, but at the moment there isn’t. Why don’t you install DokuWiki manually, then? It really is incredibly easy to install, even with limited knowledge about Linux system administration. It boils down to:

  1. Download the tarball
  2. Extract the tarball to /var/www (it’ll create a dokuwiki sub-directory)
  3. Change file & directory ownership: chown -R www-data: /var/www/dokuwiki

And that’s all it takes to get up and running! Your Dokuwiki is now accessible at https://server.name/dokuwiki/

#5

Thanks for that. I know how to setup Dokuwiki (I have it running on a own Linux Server), but I was looking for a solution, that integrates the benefits of Univention into it (e.g. User-Login, E-Mail, etc.).
But thanks anyway, I appreciate any help.

Maybe you have an likewise simple 3-step-solution for getting FullTextSearch running on NC in Univention?

#6

LDAP authentication can be enabled more or less easily. I’m using the following script /usr/lib/univention-server/server_password_change.d/dokuwiki in order to set up LDAP authentication:

#!/bin/bash

set -e

if [[ "$1" != postchange ]]; then
  exit 0
fi

eval "$(univention-config-registry shell)"

# Change 'access_group' to a DN of a group whose users should be allowed to access the installation:
access_group="memberOf=cn=AccessWiki,ou=Benutzergruppen,ou=Gruppen,ou=LINET,${ldap_base}"

# Change the path to your installation here:
conf=/var/www/dokuwiki/conf/local.php

# Leave the rest unchanged
conf_new=${conf}.new
password="$(</etc/machine.secret)"

touch ${conf_new}
chown www-data: ${conf_new}
chmod 0600 ${conf_new}
sed -Ee "/conf\['authtype'\]|conf\['plugin'\]\['authldap'\]/d" < ${conf} > ${conf_new}

cat >> ${conf_new} <<EOF
\$conf['authtype'] = 'authldap';
\$conf['plugin']['authldap']['server'] = '${ldap_master}';
\$conf['plugin']['authldap']['port'] = 7389;
\$conf['plugin']['authldap']['usertree'] = '${ldap_base}';
\$conf['plugin']['authldap']['grouptree'] = '${ldap_base}';
\$conf['plugin']['authldap']['userfilter'] = '(&(uid=%{user})(objectClass=posixAccount)(${access_group}))';
\$conf['plugin']['authldap']['groupfilter'] = '(&(objectClass=posixGroup)(|(gidNumber=%{gid})(memberUID=%{user})))';
\$conf['plugin']['authldap']['starttls'] = 1;
\$conf['plugin']['authldap']['binddn'] = '${ldap_hostdn}';
\$conf['plugin']['authldap']['bindpw'] = '${password}';
EOF

mv ${conf_new} ${conf}

You’ll have to change the two places where I’ve placed comments. Afterwards make the script executable, run it once as root with the parameter postchange and check the content of …/local.php afterwards.

Note that my script assumes that only a subset of all users should have access to the wiki. That’s what the access_group variable is there for. If you want all users to have access, either leave out that line from the generation of local.php, or chose a group all users are a member of, e.g. Domain Users.

The reason I’m using such a script is that I’m using the machine account’s LDAP object as the bind user. The machine account’s password is rotated regularly, though, therefore the configuration has to be adjusted each time — hence the script which does exactly that.

You don’t have to configure anything in order to use the mail server running on the same machine.

I don’t. I’ve never tried to use full text search in Nextcloud (or Owncloud).

1 Like
#7

Thanks, looks great - I will try this in the next days (quite busy right now) and come back here (and then mark it as solution, if it is g).

#8

It’s working - in a way.

First, I wasn’t able to get it running, and I guess it was because I didn’t (or still don’t) understand the syntax of LDAP (cn,dc,ou,…).
I changed the local.php (after running your script) at the userfilter line to:

$conf[‘plugin’][‘authldap’][‘userfilter’] = ‘(&(uid=%{user})(objectClass=person))’;

With that, I was able to login to the Wiki with an UCS-User, before not - maybe you could tell me some more things:

  • Could you provide the access_group line with my settings: Fresh lokal install of UCS in a VM with ucs.famr.intranet, so I do better understand it?
  • How would I add the Group wikiBenutzer to that?
  • How do I define an Admin for the Wiki itself? I did this now by changing the superuser in local.php to an username from ucs, but that seems to be a bit awkward.

Again, thanks for your insight, I also found your post in LDAP Log in UCS 4.1-4, wie? and LDAP Auth für externe Systeme quite helpful, even if I wasn’t able to fully understand or adapt them.

#9

The whole filter setup assumes that you want to restrict wiki usage to a certain group of users. If you do not want that (= all users will have access to the wiki), you can simply use the userfilter that you’ve posted yourself.

If, on the other hand, you do want to restrict access to the group you’ve named (wikiBenutzer), you first need to determine its DN (distinguished name). This is easy: run univention-ldapsearch cn=wikiBenutzer dn and replace the memberOf=cn=… with memberOf=<the DN listed in the output of univention-ldapsearch>.

You can include group names in the superuser setting by prefixing them with @. We use:

$conf['superuser'] = 'administrator,@Domain Admins';

#10

No success here (see below some outputs).

I’m a bit confused, shouldn’t the Groupmembership be visible if I run
univention-ldapsearch uid=<USERNAME> dn ?
Regardless to which groups the User is assigned, the output ist always
dn: uid=<USERNAME>,cn=users,dc=famr,dc=intranet
Even the Administrator-Account has the same output.
But in the Univention Usermanagement the assignments are correct.

Maybe some of these Outputs help, the Username is usr-gr, the Groupname is grp-Wiki:

LDAP-Search for UID

univention-ldapsearch uid=usr-gr dn
# extended LDIF
#
# LDAPv3
# base <dc=famr,dc=intranet> (default) with scope subtree
# filter: uid=usr-gr
# requesting: dn
#

# usr-gr, users, famr.intranet
dn: uid=usr-gr,cn=users,dc=famr,dc=intranet

# search result
search: 3
result: 0 Success

LDAP-Search for Group (cn)

univention-ldapsearch cn=grp-Wiki dn
# extended LDIF
#
# LDAPv3
# base <dc=famr,dc=intranet> (default) with scope subtree
# filter: cn=grp-Wiki
# requesting: dn
#

# grp-Wiki, groups, famr.intranet
dn: cn=grp-Wiki,cn=groups,dc=famr,dc=intranet

# search result
search: 3
result: 0 Success

Excerpt of the syslog after an Login-Attemp with usr-gr who is assigned to the grp-Wiki

(for better readability I omitted the timestamp and every line starts with ucs slapd[2908]: conn=1040)

fd=25 ACCEPT from IP=192.168.xxx.xxx:54540 (IP=0.0.0.0:7389)
op=0 EXT oid=1.3.6.1.4.1.1466.20037
op=0 STARTTLS
op=0 RESULT oid= err=0 text=
fd=25 TLS established tls_ssf=256 ssf=256
op=1 BIND dn="cn=ucs,cn=dc,cn=computers,dc=famr,dc=intranet" method=128
op=1 BIND dn="cn=ucs,cn=dc,cn=computers,dc=famr,dc=intranet" mech=SIMPLE ssf=0
op=1 RESULT tag=97 err=0 text=
op=2 BIND anonymous mech=implicit ssf=0
op=2 BIND dn="cn=ucs,cn=dc,cn=computers,dc=famr,dc=intranet" method=128
op=2 BIND dn="cn=ucs,cn=dc,cn=computers,dc=famr,dc=intranet" mech=SIMPLE ssf=0
op=2 RESULT tag=97 err=0 text=
op=3 SRCH base="dc=famr,dc=intranet" scope=2 deref=0 filter="(&(uid=usr-gr)(objectClass=posixAccount)(memberOf=cn=grp-wiki,cn=groups,dc=famr,dc=intranet,dc=famr,dc=intranet))"
ucs slapd[2908]: <= mdb_equality_candidates: (memberOf) not indexed
op=3 SEARCH RESULT tag=101 err=0 nentries=0 text=
op=4 UNBIND
fd=25 closed
#11

You have the base DN twice there. Just remove the second instance of ,dc=famr,dc=intranet.

In my scrip the $(ucr get ldap/base) part in the access_group= line adds the LDAP’s base DN as my intention was to have you only replace the relative DN part with one that suits you. But as you’ve used the full DN there, you have to remove the ,$(ucr get ldap/base) part from the script or, as I said above, the duplicate ,dc=famr,dc=intranet from the configuration file.

#12

Wow, thanks, I didn’t see this - my bad. (Lack of understanding of LDAP and lack of looking closely, sorry!).

Again, thank you very much - you saved my day!

#13

You’re quite welcome.

Mastodon