HOWTO: Configure 389-ds LDAP server on openSUSE Tumbleweed
- CommentsRecently I’ve been setting up LDAP authentication on CentOS servers to give a shared authentication method to all the compute nodes I use for my day job. I use 389-DS as it’s in my opinion much better to administer and configure than openLDAP (plus, it has very good documentation). As I have a self built NAS at home (with openSUSE Tumbleweed), I thought it’d be nice to use LDAP for all the web applications I run there. This post shows how to set up 389 Directory Server on openSUSE Tumbleweed, including the administration console.
(Obligatory) disclaimer
While this setup worked for me, there’s no guarantee it will work for you. If something breaks, you get to keep all the pieces. With some adjustments (repo names etc) this might also work on openSUSE Leap 42.1, but I haven’t tested it. Use these instructions at your own risk.
Prerequisites
Your machine should have a FQDN, either a proper domain name, or an internal LAN name. It doesn’t really matter as long as it’s a FQDN.
Secondly, you need to tune a couple of kernel parameters to ensure that the setup won’t scream at you for lack of available resources. In particular, you’ll need to raise the ranges of local ports available and the number of maximum file descriptors. You can easily do that by creating a file called /etc/sysctl.d/00-389-ds.conf
with the following contents:
# Local ports available
net.ipv4.ip_local_port_range = 1024 65000
# Maximum number of file handles
fs.file-max = 64000
After adding it, issue sysctl -p
as root to apply the changes.
Installing 389 Directory Server
Afterwards, we’ll need to add the network:ldap
OBS project, as in particular the admin bits of 389 aren’t yet available in Tumbleweed. Bear in mind that adding third-party repository to a Tumbleweed install is unsupported.
zypper ar -f obs://network:ldap Network_Ldap
# Trust the key when prompted
zypper ref
The obs://
scheme automatically adds the “guessed” distribution to your repository (with Leap it might fail though, so beware). Then we install the required packages:
zypper in 389-admin 389-admin-console 389-adminutil 389-console 389-ds 389-ds-console 389-adminutil 389-adminutil-lang
Adjusting the configuration to ensure that it works
So far so good. But if you follow the guides now and use setup-ds-admin.pl
, you’ll get strange errors and the administration server will fail to get configured properly. This is because of a missing dependency on the apache2-worker
package and because the configuration for the HTTP service used by 389 Directory Server is not properly adjusted for openSUSE: it references Apache 2 modules that the openSUSE package ships builtin or with different names and thus cannot be loaded.
Fixing the dependency problem is easy:
zypper in apache2-worker
Then, we’ll tackle the configuration issue. Open (as root) /etc/dirsrv/admin-serv/httpd.conf
, locate and comment out (or delete) the following line:
LoadModule unixd_module /usr/lib64/apache2/mod_unixd.so
Then change the mod_nss
one so that it reads like this:
LoadModule nss_module /usr/lib64/apache2/mod_nss.so
Save the file and now you’ll be able to run setup-ds-admin.pl
without issues. I won’t cover the process here, there are plenty of instructions in the 389 DS documentation.
After installation: fixing 389-console
If you want to use 389-console
on a 64 bit system with openJDK you’ll notice that upon running it’ll throw a Java exception saying that some classes (Mozilla NSS Java classes) can’t be found. This is because the script looks in the wrong library directory (/usr/lib
as opposed to /usr/lib64
). Edit /usr/bin/389-console
and find:
java \
-cp /usr/lib/java/jss4.jar: # rest of line truncated for readability
and change it to:
java \
-cp /usr/lib64/java/jss4.jar: # rest of line truncated for readability
Voilà!
![389-console working]({{ site.url }}/images/2016/01/389-ds-console.png)