You are currently browsing the category archive for the ‘Fedora Directory Server’ category.

The Howto:MultiMasterReplication wiki page for the 389 Directory Server documents use of the script for setting up replication.

The --with-ssl option is used to setup SSL for replication. I have seen a couple of postings on various forums that the script hangs when using --with-ssl option. That happened to me as well at first. I haven’t seen any answers on how to resolve this so I posting my patch to the script. (Maybe someone will submit it to the script’s maintainer, I’m too lazy. Update 1/14/2011: the maintainer, Rich Megginson, accepted the patch so refer to his repository for the latest version.)

The problem is that in the current version of the script the --with-ssl option also sets the port used for connections – port 636 by default. Just setting the port to 636 is not sufficient to inform the script’s underlying Net::LDAP perl library that SSL communication is expected. Specifying a ldaps scheme with the host name triggers the required SSL support in Net::LDAP.

So, I prepended ldaps:// to the server in each occurrence of Net::LDAP->new(). For example,

my $ldap = Net::LDAP->new(“ldaps://$server”, port => $prt) || die “$@”;

(full source is provided below)

Note that the --with-ssl servers two purposes. One is to tell the script to configure the directory to use SSL for all future replication transactions. That is, the communication between the two directory servers will be encrypted. The other action of --with-ssl is to encrypt the communications the script makes to each directory server during the setup and querying (the Net::LDAP business we just resolved). So, you will also want to use both the --with-ssl option for the script’s other subcommands, such as --display and --remove so those communications are consistently held over secure channels.


Another MMR setup script. I’ve not used it.
Read the rest of this entry »

I have some installations of Fedora Directory Server (FDS) running as the user nobody. It is generally preferred that services like FDS run under a dedicated user and certainly not the nobody account. The user is configured during an initial scripted interactive setup but I wanted to change the user for the existing installations. I could not find a how-to for doing this (though did not look very hard) so I did a new installation on a beater box and during setup configured it to run as user ldapperuser and group ldappergroup. I used this installation to experiment with reconfiguring the user.

I shutdown the slapd service and changed ownership of the files owned by ldapperuser and/or ldappergroup.

find /opt/fedora-ds -user ldapperuser | xargs chown ldap
find /opt/fedora-ds -group ldappergroup | xargs chgrp ldap

By grep’ing for the silly user and group names I found these text files needed to be edited to change the user and/or group.


I restarted the slapd process and confirmed in a process list that it was running as the new user.

Finally, I exported the entire directory to an ldif file and grep’ed it for the user and group names. There I found that I needed to change the nsSuiteSpotUser attribute in "cn=slapd-pepper, cn=Fedora Directory Server, cn=Server Group,,, o=NetscapeRoot"

I made this change to nsSuiteSpotUser via the Admin console.

There may very well be an official way to change the user for an installed FDS but this brute force method is simple enough.


April 2017
« May