Bug 588480 - setup-ds-admin.pl fails to configure admin server on ipv6 enabled hosts
Summary: setup-ds-admin.pl fails to configure admin server on ipv6 enabled hosts
Alias: None
Product: 389
Classification: Retired
Component: Install/Uninstall
Version: 1.1.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 434915 389_1.2.8
TreeView+ depends on / blocked
Reported: 2010-05-03 19:26 UTC by Rick Dicaire
Modified: 2015-01-04 23:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-02-14 18:39:54 UTC

Attachments (Terms of Use)

Description Rick Dicaire 2010-05-03 19:26:28 UTC
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:
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
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 #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

From /etc/dirsrv/slapd-ws/dse.ldif
nsslapd-localhost: ws.int.kritek.net

From DNS:
dig +short ws.int.kritek.net
dig +short -x

From /etc/hosts on that machine: ws.int.kritek.net ws

From /etc/sysconfig/network:

From /etc/resolv.conf:
; generated by /sbin/dhclient-script
search int.kritek.net

/etc/nsswitch.conf is stock, unchanged.

Comment 3 Nathan Kinder 2011-02-11 19:47:58 UTC
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
ns-slapd 29385 nobody    6u  IPv6 255107       TCP *:ldap (LISTEN)

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

Comment 4 Nathan Kinder 2011-02-11 20:03:10 UTC
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.

Comment 5 Nathan Kinder 2011-02-14 18:38:03 UTC
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.

Comment 6 Nathan Kinder 2011-02-14 18:39:54 UTC
Closing this as WORKSFORME.  If any other details come up where this issue can be reproduced, please reopen the bug.

Comment 7 Paul Robert Marino 2012-07-24 23:36:21 UTC
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

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 scope global eth0
    inet xx.xx.xx.133/23 brd 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

Comment 8 Paul Robert Marino 2012-07-24 23:51:53 UTC
I just verified it on an other server the ip address on eth0:1 seems to be the key

Comment 9 Rich Megginson 2012-07-25 00:22:13 UTC
(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?

Comment 10 Paul Robert Marino 2012-07-25 00:43:01 UTC
That's what it seems like

Comment 11 Rich Megginson 2012-07-25 00:50:52 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.