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 How reproducible: 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: 1. 2. 3. Actual results: 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' lsof -i:389 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ns-slapd 30155 nobody 6u IPv6 5218169 0t0 TCP *:ldap (LISTEN) Expected results: Configuration of DS and admin server to be completed. Additional info: Fedora 12 i386 Linux ws.int.kritek.net 2.6.32.11-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: dn: cn=config changetype: modify replace: nsslapd-listenhost nsslapd-listenhost: 192.168.1.2 From /etc/dirsrv/slapd-ws/dse.ldif nsslapd-localhost: ws.int.kritek.net From DNS: dig +short ws.int.kritek.net 192.168.1.2 dig +short -x 192.168.1.2 ws.int.kritek.net. From /etc/hosts on that machine: 192.168.1.2 ws.int.kritek.net ws From /etc/sysconfig/network: NETWORKING=yes HOSTNAME=ws.int.kritek.net From /etc/resolv.conf: ; generated by /sbin/dhclient-script search int.kritek.net nameserver 192.168.20.2 /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. - 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.