Description of problem:
setup-ds-admin.pl fails to configure admin server on ipv6 enabled hosts.
The DS instance is successfully created, but admin server configuration fails due to ns-slapd listening *only* on ipv6 interfaces.
Version-Release number of selected component (if applicable):
Name : 389-ds
Arch : noarch
Version : 1.1.3
Release : 5.fc12
Executing setup-ds-admin.pl, accepting all defaults using Typical setup type.
Default hostname and domain name are correct, and ipv4 only.
Steps to Reproduce:
Your new DS instance 'ws' was successfully created.
Creating the configuration directory server . . .
Error: failed to open an LDAP connection to host 'ws.int.kritek.net'
port '389' as user 'cn=Directory Manager'. Error: unknown.
Failed to create the configuration directory server
Exiting . . .
Log file is '/tmp/setupSjpStD.log'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ns-slapd 30155 nobody 6u IPv6 5218169 0t0 TCP *:ldap (LISTEN)
Configuration of DS and admin server to be completed.
Fedora 12 i386
Linux ws.int.kritek.net 18.104.22.168-99.fc12.i686.PAE #1 SMP Mon Apr 5 16:15:03 EDT 2010 i686 i686 i386 GNU/Linux
Server machine is ipv6 enabled. It has Global ipv6 addresses configured.
dns resolution for the hostname used works completely, and is ipv4 only.
ns-slapd listens on ipv6 only.
I set the sysctl key net.ipv6.bindv6only to both 0 and 1 while running setup-ds-admin.pl with same result.
I was able to successfuly complete the setup by including fixlistenhost.ldif with contents:
dig +short ws.int.kritek.net
dig +short -x 192.168.1.2
From /etc/hosts on that machine:
192.168.1.2 ws.int.kritek.net ws
; generated by /sbin/dhclient-script
/etc/nsswitch.conf is stock, unchanged.
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.
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
Red Hat Enterprise Linux Server release 6.3 (Santiago)
rpm -qa|grep 389
one interesting note I have two ip addresses on the network interface
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.