openldap-2.4.39

[Fernando de Oliveira]

[wget -c ​ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz]

​http://www.openldap.org/software/release/changes.html

OpenLDAP 2.4.39 Release (2014/01/26)
	Fixed libldap MozNSS crash (ITS#7783)
	Fixed libldap memory leak with SASL (ITS#7757)
	Fixed libldap assert in parse_passwdpolicy_control (ITS#7759)
	Fixed libldap shortcut NULL RDNs (ITS#7762)
	Fixed libldap deref to use correct control
	Fixed liblmdb keysizes with mdb_update_key (ITS#7756)
	Fixed slapd cn=config olcDbConfig modification (ITS#7750)
	Fixed slapd-bdb/hdb to bail out of search if config is paused (ITS#7761)
	Fixed slapd-bdb/hdb indexing issue with derived attributes (ITS#7778)
	Fixed slapd-mdb to bail out of search if config is paused (ITS#7761)
	Fixed slapd-mdb indexing issue with derived attributes (ITS#7778)
	Fixed slapd-perl to bail out of search if config is paused (ITS#7761)
	Fixed slapd-sql to bail out of search if config is paused (ITS#7761)
	Fixed slapo-constraint handling of softadd/softdel (ITS#7773)
	Fixed slapo-syncprov assert with findbase (ITS#7749)
	Build Environment
		Test suite: Use $(MAKE) for tests (ITS#7753)
	Documentation
		admin24 fix TLSDHParamFile to be correct (ITS#7684)

[Fernando de Oliveira]

I installed the client, then sendmail. After, as do not have a server from which to test the client, installed the server. It simply does not start. Never dealt with this before, don't know howto configure.

[Fernando de Oliveira]

If someone could help me to configure this thing, I could update this one, too.

[Fernando de Oliveira]

Forgot: please

[Fernando de Oliveira]

I have succeeded in several points:

# /usr/sbin/slapd -T test
config file testing succeeded

$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts 
#

#
dn:
namingContexts: dc=my-domain,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

However, the server fails to start with the bootscript, without any message. I can start if I run

/usr/sbin/slapd

I can stop with the bootscript:

# /etc/rc.d/init.d/slapd stop
  *  Stopping OpenLDAP                                                 [  OK  ]

But not start:

# /etc/rc.d/init.d/slapd start
*****Starting OpenLDAP                                                 [ FAIL ]

If I try to start with options from the bootscript, fails, but succeeds without any options:

root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap -g ldap -h "ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
root [ /home/fernando ]# evaluate_retval
*****                                                                  [ FAIL ]
root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap -g ldap -h ""root [ /home/fernando ]# evaluate_retval
*****                                                                  [ FAIL ]
root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap -g ldap
root [ /home/fernando ]# evaluate_retval
*****                                                                  [ FAIL ]
root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap
root [ /home/fernando ]# evaluate_retval
*****                                                                  [ FAIL ]
root [ /home/fernando ]# start_daemon /usr/sbin/slapd
root [ /home/fernando ]# evaluate_retval
  *                                                                    [  OK  

[Fernando de Oliveira]

Recompiled with debug enabled and solved.

root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap -g ldap -h "ldap://127.0.0.1:389/ ldaps:/// ldapi:///" -d 1
ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /etc/openldap/ldap.conf
ldap_init: using /etc/openldap/ldap.conf
ldap_url_parse_ext(ldap://127.0.0.1)
ldap_init: HOME env is /root
ldap_init: trying /root/ldaprc
ldap_init: trying /root/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
52e7c1e2 @(#) $OpenLDAP: slapd 2.4.39 (Jan 28 2014 11:21:24) $
	root@VMWLFS74:/home/fernando/tmp/paco-build-2014.01.28-11h18m35s/openldap-2.4.39/servers/slapd
ldap_pvt_gethostbyname_a: host=VMWLFS74, r=0
52e7c1e2 daemon_init: listen on ldap://127.0.0.1:389/
52e7c1e2 daemon_init: listen on ldaps:///
52e7c1e2 daemon_init: listen on ldapi:///
52e7c1e2 daemon_init: 3 listeners to open...
ldap_url_parse_ext(ldap://127.0.0.1:389/)
52e7c1e2 daemon: listener initialized ldap://127.0.0.1:389/
ldap_url_parse_ext(ldaps:///)
52e7c1e2 daemon: listener initialized ldaps:///
ldap_url_parse_ext(ldapi:///)
52e7c1e2 daemon: listener initialized ldapi:///
52e7c1e2 daemon_init: 4 listeners opened
ldap_create
52e7c1e2 slapd init: initiated server.
52e7c1e2 slap_sasl_init: initialized!
52e7c1e2 could not open config file "/etc/openldap/slapd.conf": Permission denied (13)
52e7c1e2 slapd destroy: freeing system resources.
52e7c1e2 slapd stopped.
52e7c1e2 connections_destroy: nothing to destroy.
root [ /home/fernando ]# evaluate_retval
*****                                                                  [ FAIL ]
root [ /home/fernando ]# ls -l /etc/openldap/slapd.conf
-rw------- 1 root root 2100 Jan 28 10:36 /etc/openldap/slapd.conf
root [ /home/fernando ]# chown -v ldap:ldap /etc/openldap/slapd.confalterado o dono de “/etc/openldap/slapd.conf” de root:root para ldap:ldap
root [ /home/fernando ]# start_daemon /usr/sbin/slapd -u ldap -g ldap -h "ldap://127.0.0.1:389/ ldaps:/// ldapi:///" -d 1 &
[1] 16298
root [ /home/fernando ]# ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /etc/openldap/ldap.conf
ldap_init: using /etc/openldap/ldap.conf
ldap_url_parse_ext(ldap://127.0.0.1)
ldap_init: HOME env is /root
ldap_init: trying /root/ldaprc
ldap_init: trying /root/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
52e7c224 @(#) $OpenLDAP: slapd 2.4.39 (Jan 28 2014 11:21:24) $
	root@VMWLFS74:/home/fernando/tmp/paco-build-2014.01.28-11h18m35s/openldap-2.4.39/servers/slapd
ldap_pvt_gethostbyname_a: host=VMWLFS74, r=0
52e7c224 daemon_init: listen on ldap://127.0.0.1:389/
52e7c224 daemon_init: listen on ldaps:///
52e7c224 daemon_init: listen on ldapi:///
52e7c224 daemon_init: 3 listeners to open...
ldap_url_parse_ext(ldap://127.0.0.1:389/)
52e7c224 daemon: listener initialized ldap://127.0.0.1:389/
ldap_url_parse_ext(ldaps:///)
52e7c224 daemon: listener initialized ldaps:///
ldap_url_parse_ext(ldapi:///)
52e7c224 daemon: listener initialized ldapi:///
52e7c224 daemon_init: 4 listeners opened
ldap_create
52e7c224 slapd init: initiated server.
52e7c224 slap_sasl_init: initialized!
52e7c224 bdb_back_initialize: initialize BDB backend
52e7c224 bdb_back_initialize: Berkeley DB 6.0.20: (June 24, 2013)
52e7c224 bdb_db_init: Initializing BDB database
...



52e7c224 slapd startup: initiated.
52e7c224 backend_startup_one: starting "cn=config"
52e7c224 config_back_db_open
52e7c224 config_build_entry: "cn=config"
52e7c224 config_build_entry: "cn=module{0}"
52e7c224 config_build_entry: "cn=schema"
52e7c224 >>> dnNormalize: <cn={0}core>
52e7c224 <<< dnNormalize: <cn={0}core>
52e7c224 config_build_entry: "cn={0}core"
52e7c224 config_build_entry: "olcDatabase={-1}frontend"
52e7c224 config_build_entry: "olcDatabase={0}config"
52e7c224 config_build_entry: "olcDatabase={1}bdb"
52e7c224 backend_startup_one: starting "dc=my-domain,dc=com"
52e7c224 bdb_db_open: database "dc=my-domain,dc=com": dbenv_open(/var/lib/openldap).
52e7c224 slapd starting

root [ /home/fernando ]# evaluate_retval
  *                                                                    [  OK  ]

[Fernando de Oliveira]

Should I include this instruction or a note about it (if note, without the .default)?

chown -v ldap:ldap /etc/openldap/slapd.conf.default

[Armin K]

Now that you mentioned it, I remember having a similar issue, but I failed to add the solution to the book. Maybe I wasn't contributor anymore at the time I discovered the issue.

I have this part in my install script:

chmod 700 /etc/openldap/slapd.d /var/lib/openldap
chown -R ldap:ldap /etc/openldap/slapd.d /var/lib/openldap

chmod 640 /etc/openldap/slapd.conf /etc/openldap/slapd.ldif /etc/openldap/DB_CONFIG.example
chown root:ldap /etc/openldap/slapd.conf /etc/openldap/slapd.ldif /etc/openldap/DB_CONFIG.example

I believe that this configuration was taken either from Debian or Archlinux, I am not sure. It does work however.

[bdubbs@…]

That looks like a good solution. I'd shorten the instructions a bit with /etc/openldap/{slapd.conf,slapd.ldif,DB_CONFIG.example}

[Fernando de Oliveira]

Thanks, Armin, for posting the instructions and confirming the problem.

I was writing this, when I saw Bruce's comments, thanks, Bruce.

I have completely removed openldap and reinstalled according to the books as is now.

After confirming that bootscript fails to start it, tried Armin's suggestion:

chown -c root:ldap /etc/openldap/slapd.conf

and it failed again.

With

chown -c ldap:ldap /etc/openldap/slapd.conf

success. Also "Testing the Configuration" succeeded.

Thus, that is what I think will be including in the page.

Now, I have a new problem, cannot forward X by ssh.

fernando [ ~ ]$ ssh -X 192.168.0.106
fernando@192.168.0.106's password: 
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Tue Jan 28 13:09:33 2014 from 192.168.0.162
/usr/bin/xauth:  file /home/fernando/.Xauthority does not exist
fernando [ ~ ]$ gvim /home/fernando/Downloads/blfs/openldap-2.4.39-simulation-2014.01.28-12h28m20s.log.xz
X11 connection rejected because of wrong authentication.
E233: impossível abrir displayE852: The child process failed to start the GUIX11 connection rejected because of wrong authentication.

Aperte ENTER ou digite um comando para continuar
fernando [ ~ ]$ sudo rm -v .Xauthority
[sudo] senha de fernando: 
X11 connection rejected because of wrong authentication.
removido “.Xauthority”

I have installed since yesterday:

cyrus-sasl db openldap-client openldap sendmail procmail fetchmail mailx

Asking here, because I may have broken something, when configuring any of these, including openldap. But will try support, later, if cannot solve.

[Armin K]

No, don't have ldap user own the configuration file. That's why I chmod it to 640, for ldap group to be able to read the file, but only the owner (root) to be able to change it.

[Fernando de Oliveira]

[Solved the other problem: had modified /etc/hosts and 127.0.0.1 was point not to localhost.]

Sorry, now, understood. But still trying to minimize the changes to the book. Then, will do:

chmod -c 640 /etc/openldap/slapd.conf
chown -c root:ldap /etc/openldap/slapd.conf

Just tested and worked.

Is that OK?

[Armin K]

What's wrong with my original proposal?

[Fernando de Oliveira]

Nothing. I am trying to keep the modifications to the book at the minimum. Those instructions above did the trick for the server to start. But I do not know much about this, so I asked if it is OK. Can just blindly copy and paste to the book your instructions, but am trying to understand why Debian or ArchLinux did those.

At the moment, I have:

# env LC_ALL=C ls -dl /etc/openldap/slapd.d /var/lib/openldap/* /etc/openldap/slapd.conf /etc/openldap/slapd.ldif /etc/openldap/DB_CONFIG.example
ls: cannot access /etc/openldap/slapd.d: No such file or directory
-rw------- 1 root root      845 Jan 28 12:50 /etc/openldap/DB_CONFIG.example
-rw-r----- 1 root ldap     2103 Jan 28 12:50 /etc/openldap/slapd.conf
-rw------- 1 root root     2564 Jan 28 12:50 /etc/openldap/slapd.ldif
-rw------- 1 ldap ldap      845 Jan 28 12:50 /var/lib/openldap/DB_CONFIG.example
-rw------- 1 ldap ldap   262144 Jan 28 13:44 /var/lib/openldap/__db.001
-rw------- 1 ldap ldap    32768 Jan 28 13:44 /var/lib/openldap/__db.002
-rw------- 1 ldap ldap    49152 Jan 28 13:44 /var/lib/openldap/__db.003
-rw-r--r-- 1 ldap ldap     2048 Jan 28 13:44 /var/lib/openldap/alock
-rw------- 1 ldap ldap     8192 Jan 28 12:55 /var/lib/openldap/dn2id.bdb
-rw------- 1 ldap ldap    32768 Jan 28 12:55 /var/lib/openldap/id2entry.bdb
-rw------- 1 ldap ldap 10485760 Jan 28 13:11 /var/lib/openldap/log.0000000001

Thus, one directory is not present.

All /var/lib/openldap/* is owned by ldap ldap and only one is not 700.

The files affected by the other instructions:

/etc/openldap/DB_CONFIG.example (would need chown and chmod)
/etc/openldap/slapd.ldif (would need chown and chmod)
/var/lib/openldap/alock (would need chmod)

So, my question is: are these completely necessary for other things that I do not know? It is a good opportunity for me to learn, so, please, be patient with me.

Thanks, again.

[Fernando de Oliveira]

Yesterday, spent many hours with the tests. Always failed at about

...
ldapsearch failed (255)!
>>>>> test058-syncrepl-asymmetric failed for bdb
(exit 255)
make[2]: *** [bdb-mod] Error 255
make[2]: Target `bdb' not remade because of errors.
make[2]: Leaving directory `/home/fernando/tmp/paco-build-2014.01.27-13h23m20s/openldap-2.4.39/tests'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/home/fernando/tmp/paco-build-2014.01.27-13h23m20s/openldap-2.4.39/tests'
make: *** [test] Error 2

real    18m58.216s
user    0m35.444s
sys 2m19.996s

$ du -sch ../*20M   ../DEST-openldap-2.4.39
89M ../openldap-2.4.39
108M    total

increasing build_dir_size by about 5MB.

Could not find how to progress the tests nor the reason. Therefore, will only add that the "tests may fail after a long time".

[Fernando de Oliveira]

Thanks Armin and Bruce.

After some research elsewhere, I decided to take part of suggestions by both of you and part of mine, to add new commands.

Fixed at r12643.

[Fernando de Oliveira]

Replying to fo:

Nothing. I am trying to keep the modifications to the book at the minimum. Those instructions above did the trick for the server to start. But I do not know much about this, so I asked if it is OK. Can just blindly copy and paste to the book your instructions, but am trying to understand why Debian or ArchLinux did those.

At the moment, I have:

# env LC_ALL=C ls -dl /etc/openldap/slapd.d /var/lib/openldap/* /etc/openldap/slapd.conf /etc/openldap/slapd.ldif /etc/openldap/DB_CONFIG.example
ls: cannot access /etc/openldap/slapd.d: No such file or directory
-rw------- 1 root root      845 Jan 28 12:50 /etc/openldap/DB_CONFIG.example
-rw-r----- 1 root ldap     2103 Jan 28 12:50 /etc/openldap/slapd.conf
-rw------- 1 root root     2564 Jan 28 12:50 /etc/openldap/slapd.ldif
-rw------- 1 ldap ldap      845 Jan 28 12:50 /var/lib/openldap/DB_CONFIG.example
-rw------- 1 ldap ldap   262144 Jan 28 13:44 /var/lib/openldap/__db.001
-rw------- 1 ldap ldap    32768 Jan 28 13:44 /var/lib/openldap/__db.002
-rw------- 1 ldap ldap    49152 Jan 28 13:44 /var/lib/openldap/__db.003
-rw-r--r-- 1 ldap ldap     2048 Jan 28 13:44 /var/lib/openldap/alock
-rw------- 1 ldap ldap     8192 Jan 28 12:55 /var/lib/openldap/dn2id.bdb
-rw------- 1 ldap ldap    32768 Jan 28 12:55 /var/lib/openldap/id2entry.bdb
-rw------- 1 ldap ldap 10485760 Jan 28 13:11 /var/lib/openldap/log.0000000001

Thus, one directory is not present.

All /var/lib/openldap/* is owned by ldap ldap and only one is not 700.

The files affected by the other instructions:

/etc/openldap/DB_CONFIG.example (would need chown and chmod)
/etc/openldap/slapd.ldif (would need chown and chmod)
/var/lib/openldap/alock (would need chmod)

So, my question is: are these completely necessary for other things that I do not know? It is a good opportunity for me to learn, so, please, be patient with me.

Thanks, again.

Reopening the ticket now that Armin decided that he wants to reply to my questions.

Please, Armin, after you reproduce here your explanations bout the necessity of your instructions, send a patch with the modifications you want to be in the book.

Thanks.

[Fernando de Oliveira]

OK, I will do it, but still need to understand some points.

[Fernando de Oliveira]

Em 29-01-2014 01:41, Armin K. escreveu:>

On 29.1.2014 3:12, Fernando de Oliveira wrote:

Em 28-01-2014 21:10, Armin K. escreveu:

On 29.1.2014 0:33, Fernando de Oliveira wrote:

Author: fernando Date: Tue Jan 28 15:33:24 2014 New Revision: 12643

Log: Updates to sendmail.8.14.8 and openldap-2.4.39.

Modified:

trunk/BOOK/general.ent trunk/BOOK/introduction/welcome/changelog.xml trunk/BOOK/server/mail/sendmail.xml trunk/BOOK/server/other/openldap.xml

If it was server config file, this would rather be unsecure. But you still didn't chmod nor chown slapd.conf and slapd.ldif. Anyways, *anything* in /var/lib/openldap should *not* be either readable or writable by anyone than the ldap daemon itself.

Thanks. It was a mistake.

I wanted to follow more closely your suggestions, but I had to research, because you failed to reply to my comment in the ticket. So I am doing what Ubuntu and Debian do.

Fixed at revision 12644.

Partially fixed. I am still pointing out that having slapd configuration files and ldap databases in /var/lib/openldap readable by anyone is a SECURITY ISSUE. Especially since a file stores admin password in the PLAIN TEXT. That's why mode 640 and root:ldap ownership was used. root owner, so only root could modify the file and ldap group so the group which owns slapd daemon could read but not modify the file in case of security breach.

I still cannot understand why Ubuntu and Debian do differently.

Thanks for the explanation that you did not want to give before.

Hope that now you will be pleased. If not, please write, and we will try again.

Fixed at r12645.

[Armin K]

I can't explain better than I tried in the mail, but here's again

By default, ldap server (slapd) is running as root unless you specify the -u and -g switches, which blfs bootscript does.

So, instead of running the daemon as root user, blfs runs it as a unprivileged, ldap user - for security (as as side note, running some network daemons as root might be unsecure).

But then again, openldap package installs slapd configuration files with mode 600, which means it's only readable and writable by root user, which is also the owner of the file.

Saying that, slapd daemon which runs as ldap user and group can't read the file and thus it fails on startup.

The "whatever distro I borrowed the chown's and chmod's from (doesn't mean it's Debian/Ubuntu)" makes the members of ldap group read the file, but only the owner (still root) modify the file. That's where chmod 640 and chown root:ldap comes into question.

Only root can modify the file, but member of the ldap group (which is the ldap user) can only read the file, so in case of security breach through the slapd daemon (it could happen, but doesn't mean it will) the file can't be modified by ldap user, which the daemon runs as, but only as root. That also means that anyone who manages to log in as the unprivileged user can't change slapd administrator password which is stored in the (not 100% sure) plaintext in the slapd configuration file.

Again, increased security measure. chowning slapd configuration file to ldap user, without any chmod would also work fine, but then again you don't take the security into account.

[Fernando de Oliveira]

Thanks. Good explanation. So, everything seems to OK, now, right?

Still, I included a directory with:

install -v -dm700 -o ldap -g ldap /etc/openldap/slapd.d

which I see with some configuration files and directories(ugly named ones, with equal sihn in the name of files and directories), but have no idea where they came from. Gave up and just included it with the right ownership/permissions, in case someone wants and knows how to use.

[bdubbs@…]

Milestone current deleted