Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 982582
Description of problem: First bug submission, sorry if I screw it up. Platform is CentOS 6.4 (64bit) using EPEL 389 Directory Server packages. After running "setup-ds-admin.pl", LDAP binds to IPv6 address, while ds-admin binds to IPv4 address Have also tried to disable IPv6 using the following... echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6 but it still binds to IPv4 instead. Version-Release number of selected component (if applicable): rpm -qa | grep 389 | sort 389-admin-1.1.29-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-adminutil-1.1.15-1.el6.x86_64 389-console-1.1.7-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-14.el6_4.x86_64 389-ds-base-libs-1.2.11.15-14.el6_4.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 How reproducible: Consistently. Steps to Reproduce: 1. Install CentOS-6.4-x86_64-minimal 2. rpm -ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm 3. rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6 4. yum -y install 389-ds openldap-clients 5. setup-ds-admin.pl Actual results: netstat -tulpn Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 3070/httpd.worker tcp 0 :::389 :::* LISTEN 2969/ns-slapd Expected results: netstat -tulpn Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 2969/ns-slapd tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 3070/httpd.worker Additional info: This has been reported and closed previously under RH Bug 588480. Can manually change LDAP configuration to use IPv4 using following steps: vi /etc/dirsrv/fix-ipv6-bind.ldif dn: cn=config changetype: modify replace: nsslapd-listenhost nsslapd-listenhost: 0.0.0.0 ldapmodify -a -x -h localhost -p 389 -D cn="Directory Manager" -w PASSWORD -f /etc/dirsrv/fix-ipv4-bind.ldif vi /etc/dirsrv/fix-ipv6-sslbind.ldif dn: cn=config changetype: modify replace: nsslapd-securelistenhost nsslapd-securelistenhost: 0.0.0.0 ldapmodify -a -x -h localhost -p 389 -D cn="Directory Manager" -w PASSWORD -f /etc/dirsrv/fix-ipv4-sslbind.ldif service dirsrv restart service dirsrv-admin restart
The current implementation uses the ipv6 interface if listenhost is not specified:
{{{ int slapd_listenhost2addr(const char listenhost, PRNetAddr addr) { if (NULL == listenhost) { / listen on all interfaces / if ( PR_SUCCESS != PR_SetNetAddr(PR_IpAddrAny, PR_AF_INET6, 0, netaddr)) { }}}
I'm not sure why this is a problem, and I'm not sure if I change it to ipv4(PR_AF_INET) if that will break ipv6 clients.
I also don't understand the complaints...
By default, both IPv4 and v6 are listened: {{{
dn:
dn: }}} Once disabling the IPv6: {{{
}}} indeed, IPv6 is not available: {{{
ldap_search: Can't connect to the LDAP server - No route to host
dn: }}} Sure, netstat returns ":::*" even after IPv6 is disabled. {{{
tcp6 0 0 :::389 :::* LISTEN 14613/ns-slapd }}} But that's just the format that netstat uses?
For instance, other utilities such as sshd and cupsd returns ":::" even after IPv6 is disabled... {{{ tcp6 0 0 :::22 ::: LISTEN 825/sshd tcp6 0 0 :::631 :::* LISTEN 1440/cupsd }}}
Regarding the admin server, please take a look at /etc/dirsrv/admin-serv/console.conf. You will see a comment like this: {{{
Listen 0.0.0.0:9830 }}}
Since we have no feedbacks, we are closing this ticket for now.
Please feel free to reopen it if you run into the problem.
Metadata Update from @nhosoi: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.3 - 8/14 (August)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/775
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.