389-ds-base

#625 IPA install fails when openldap-servers package is already installed
Closed: wontfix Opened by nkinder.

Closed: wontfix
Reopen Issue

Description of problem:
IPA install fails when openldap-servers package is already installed.
Openldap-servers adds /etc/portreserve/slapd that is used by portreserver to
reserve UDP port 636. So, IPA install runs, it finds port 636 being used and
fails.

This should also occur if you simply try to set up 389 DS to use port 636 when openlda-server is installed.

Steps to Reproduce:
1. Install openldap-servers package
2. Make sure portreserve service is running
3. Install IPA

Actual results:
IPA install fails

Expected results:
IPA install succeeds

Additional info:
[root@dell-pe1800-01 ~]# service portreserve status
portreserve (pid 26075) is running...

[root@dell-pe1800-01 ~]# netstat -ntulp | grep portreserve
udp 0 0 0.0.0.0:750 0.0.0.0:
26075/portreserve
udp 0 0 0.0.0.0:636 0.0.0.0:
26075/portreserve

[root@dell-pe1800-01 ~]# cat /etc/portreserve/slapd
ldaps

[root@dell-pe1800-01 ~]# rpm -ql openldap-servers | grep port
/etc/portreserve/slapd

'''Here is the current status'''

  • IPA installation guide (prerequisite) clearly states that some system ports (like 636) should be available for IPA to work.[[BR]]
    http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/installing-ipa.html#prerequisites[[BR]]
    https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Preparing_for_an_IPA_Installation.html#prereq-ports[[BR]]

  • The IPA installation procedure may contain a test around 'portreserve' like

{{{
service portreserve status
if [ $? -eq 0 ]
then
portrelease slapd
fi

}}}

'''Here are the next steps'''

* Need to evaluate if this bug needs to be handled at 389 level or at IPA level

I did some investigation of how portreserve is supposed to be used. The short summary is that current Fedora distributions don't use it since systemd handles port conflict resolution. I checked the OpenLDAP source RPM on F18, and it doesn't use portreserve. This means we don't have to fix anything here in 389-ds-base-1.3.x.

Platforms that use SysV init scripts (such as RHEL6) need to use portreserve in order to prevent well-known ports in the 600-1023 range from being randomly grabbed by RPC services. We don't plan to fix this in 389-ds-base 1.2.11, so I'm closing this as WONTFIX.

Metadata Update from @tbordaz:
- Issue assigned to tbordaz
- Issue set to the milestone: N/A

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/625

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
Normal
Needs Review
IPA
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.