Bug 213626
Summary: | start-slapd fails if nsslapd-listenhost is specified (multihomed, FDS 1.0.3) | ||
---|---|---|---|
Product: | [Retired] 389 | Reporter: | Dirk Husung <husung> |
Component: | Directory Server | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0.2 | CC: | bj+bugzilla, jgalipea, nhosoi |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-07 16:41:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 152373, 240316, 427409 |
Description
Dirk Husung
2006-11-02 11:52:57 UTC
I think this may be IPv6 related. Is your workaround to use an IPv6 style address? Sorry, our computer center doesn't support IPv6 addresses yet, so an IPv6 style address would not be a workaround for me, I think. (The <ip-address> in the error message was correctly resolved, btw.) Someone else reported a workaround was to use an IPv6 style address like this: nsslapd-listenhost: ::ffff:N.N.N.N Can you give it a try? Even though your network is not IPv6, the TCP stack may be able to parse this address into a valid IPv4 netaddr. Thanks a lot! That seems to solve my problem; slapd starts up and the log file reports: [02/Nov/2006:16:44:11 +0100] - Fedora-Directory/1.0.3 B2006.303.2257 starting up [02/Nov/2006:16:44:11 +0100] - slapd started. Listening on <ip-address> port 389 for LDAP requests (with the correct <ip-address>) Another way, which helped me for this problem, was adding '::ffff:' in front of IP address in /etc/hosts for the line containing hostname which directory server is binding to. The problem is ... On FDS 1.0.2 and older, if the IPv4 style listenhost is set in the config file (dse.ldif), it's converted to the IPv4-compatible IPv6 address and the conflict is avoided. If the IPv6 style listenhost is set, it shows the same bind conflict error at the start up time: createprlistensocket - PR_Bind() on fe80::208:74ff:xxxx:xxxx port <port> failed: Netscape Portable Runtime error -5967 (TCP file descriptor is already bound.) On FDS 1.0.3, the listenhost sets what's specified in the config file. Thus, if the listenhost is the same as the main socket's address, the bind fails with the error "already bound". *** Bug 249789 has been marked as a duplicate of this bug. *** It turned out the problem was caused by setting the wrong socket type. This bug was fixed as part of another bug #250702: Summary: not all the addresses associated with listenhost are bound to listen sockets *** Bug 160624 has been marked as a duplicate of this bug. *** Verfied aginst: 1195501819 redhat-ds-base-8.0.0-11.el5dsrv Mon Nov 19 2007 1195501821 redhat-ds-admin-8.0.0-1.15.el5dsrv Mon Nov 19 2007 1195501823 redhat-admin-console-8.0.0-9.el5dsrv Mon Nov 19 2007 1195501823 redhat-ds-console-8.0.0-8.el5dsrv Mon Nov 19 2007 |