Bug 588480

I am unable to reproduce this issue.  Do you still have a system that you can reproduce the issue on?  I'd also like to know the version of the 389-ds-base package that you are using.

I'm curious to see the output of "netstat -an | grep 389" as well as the startup messages in the ns-slapd errors log.  I do see similar lsof output on my system, but ns-slapd is indeed listening on all interfaces:

# lsof -i:389
COMMAND    PID   USER   FD   TYPE DEVICE SIZE NODE NAME
ns-slapd 29385 nobody    6u  IPv6 255107       TCP *:ldap (LISTEN)

# netstat -an | grep 389
tcp        0      0 :::389                      :::*                        LISTEN

I will add that my installation does fail if I set net.ipv6.bindv6only=1 prior to running setup-ds-admin.pl.  This makes sense because ns-slapd will only bind to the v6 interface and Admin Server fails to connect to ns-slapd via the hostname that is mapped to the IPv4 address.

If I set net.ipv6.bindv6only=0 before running setup-ds-admin.pl, the install goes through just fine.

There is one other thing noticed in my testing.  My system is set up as follows:

- has IPv4 and IPv6 addresses both mapped to the FQDN in DNS.
- net.ipv6.bindv6only=1

When running setup-ds-admin.pl and specifying the FQDN, the isntaller bails when it tries to connect to ns-slapd to configure it as a config DS for Admin Server.

What I found was that PerLDAP does not support connecting with IPv6 when it is built against MozLDAP.  This seems to be related to the fact that it calls ldap_init() behind the scenes.  When PerLDAP is built against the OpenLDAP client libraries, this all works fine since ldap_initialize() is used behind the scenes.

Since we are moving to using the OpenLDAP libraries beneath PerLDAP, I think we will just let this issue be dealt with when that conversion is complete.  This is already done on F14 and later.

Closing this as WORKSFORME.  If any other details come up where this issue can be reproduced, please reopen the bug.

I ran into the same issue

the workaround suggested worked as well

cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)

 rpm -qa|grep 389
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-ds-console-doc-1.2.6-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-adminutil-1.1.15-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64

one interesting note I have two ip addresses on the network interface
one

ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether ac:16:2d:a5:08:b4 brd ff:ff:ff:ff:ff:ff
    inet xx.xx.xx.136/23 brd 10.150.105.255 scope global eth0
    inet xx.xx.xx.133/23 brd 10.150.105.255 scope global secondary eth0:1
    inet6 fe80::ae16:2dff:fea5:8b4/64 scope link
       valid_lft forever preferred_lft forever

and I'm trying to bind it to the 133 address

I just verified it on an other server the ip address on eth0:1 seems to be the key

(In reply to comment #8)
> I just verified it on an other server the ip address on eth0:1 seems to be
> the key

So the problem is not IPv6, it's that the server has multiple IP addresses?

That's what it seems like

(In reply to comment #10)
> That's what it seems like

Then I would like to leave this bug as closed, and please open another bug about "setup doesn't work on some multi-homed or multi-interface hosts" or something like that.