Currently, slapd will start up even if it can't bind to an interface, if more than one potential interface is given where the bind is successful. This was, as best as Howard can recall, done because of ipv4/ipv6 issues on some systems.
However, it seems to me that it should at least be possible to specify to slapd that you do not want it to start up unless binding to all interfaces is successful.
This is fairly trivial to reproduce. As a non-privileged user, simply do:
-h "ldap:// ldapi://slapd.sock"
It will fail to bind to 389, but bind to the LDAPI socket anyway, and continue the startup process. This gives a false result that slapd started successfully, although clearly external clients will be unable to talk to it.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Sat, Jan 09, 2016, Quanah Gibson-Mount wrote:
Currently, slapd will start up even if it can't bind to an interface, if more than one potential interface is given where the bind is successful.
FWIW: sendmail had the inverse problem and it was resolved by marking an "interface" as optional: DaemonPortOptions: Modifier Options (flags) for the daemon O optional; if opening the socket fails ignore it This was done so a (generic) cf file could have both IPv4 and IPv6 DaemonPortOptions (sockets) without failing to start when IPv6 isn't available.
On 10. jan. 2016 00:48, Quanah Gibson-Mount wrote:
Currently, slapd will start up even if it can't bind to an interface, if more than one potential interface is given where the bind is successful. (...) This is fairly trivial to reproduce. As a non-privileged user, simply do:
-h "ldap:// ldapi://slapd.sock"
It will fail to bind to 389, but bind to the LDAPI socket anyway, and continue the startup process. This gives a false result that slapd started successfully, although clearly external clients will be unable to talk to it.
Doesn't start on my Linux machines, RHEL 6.7 and 7.2:
5693ba7e @(#) $OpenLDAP: slapd 2.4.X (Jan 11 2016 14:14:28) $ hbf@bombur.uio.no:/site/var/ldap/ol/openldap.gt/servers/slapd 5693ba7e daemon: bind(7) failed errno=13 (Permission denied) 5693ba7e daemon: bind(7) failed errno=13 (Permission denied) 5693ba7e slapd stopped.
On Sat, Jan 09, 2016 at 03:48:12PM -0800, Quanah Gibson-Mount wrote:
This is fairly trivial to reproduce. As a non-privileged user, simply do:
-h "ldap:// ldapi://slapd.sock"
It will fail to bind to 389, but bind to the LDAPI socket anyway, and continue the startup process.
I was sure I saw this at the time when we were talking about it in IRC, but now I can't get it to reproduce again. Guess I screwed up.
--On Monday, January 11, 2016 7:06 PM -0800 Ryan Tandy ryan@nardis.ca wrote:
On Sat, Jan 09, 2016 at 03:48:12PM -0800, Quanah Gibson-Mount wrote:
This is fairly trivial to reproduce. As a non-privileged user, simply do:
-h "ldap:// ldapi://slapd.sock"
It will fail to bind to 389, but bind to the LDAPI socket anyway, and continue the startup process.
I was sure I saw this at the time when we were talking about it in IRC, but now I can't get it to reproduce again. Guess I screwed up.
Either way, I am seeing it sporadically on systems where it has a screwy /etc/hosts file, along the lines of:
127.0.0.1 localhost ::1 hostname.fqdn hostname localhost
ipv4address hostname.fqdn hostname
and of course, hostname is not assigned to ::1, just localhost is.
In this case, every once in a great while, we see:
Jan 9 08:37:56 zqa-126 slapd[23993]: daemon: bind(8) failed errno=22 (Invalid argument) Jan 9 08:37:56 zqa-126 slapd[23993]: @(#) $OpenLDAP: slapd 2.4.43 (Jan 4 2016 20:01:22) $#012#011build@u1287:/home/build/p4/zimbra/JUDASPRIEST/ThirdParty/openldap/tmp/UBUNTU12_64/zimbra-openldap/servers/slapd
(and away it goes, only listening on ldapi).
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
-
Hallvard Breien Furuseth -
ml+openldap＠esmtp.org -
Quanah Gibson-Mount -
Ryan Tandy