Bug 1125950

This port is being set by 389-ds-base's setup-ds.pl script, as I saw in their source file ./ldap/admin/src/scripts/DSCreate.pm.in and function updateSelinuxPolicy. My assumption is that it does not record that this port was enabled and they simply do not un-enable it on uninstall to avoid breaking stuff.

I would discuss whether there is a value in fixing this state as this is not very harmful and should be fixed in RHEL-7.0, based on the F18 fix:
https://bugzilla.redhat.com/show_bug.cgi?id=879516#c12

Anyway, moving to 389-ds-base component to decide.

I cannot reproduce the problem with setup-ds.pl and remove-ds.pl.

Here's the steps.
Note: following commands are run by root.
# setup-ds.pl ==> created slapd-vm-115 with the port 20389

# semanage port -l | egrep ldap
ldap_port_t                    tcp      20389, 10390, 389, 636, 3268
ldap_port_t                    udp      389, 636

# remove-ds.pl -i slapd-vm-115
Instance slapd-vm-115 removed.

# semanage port -l | egrep ldap
ldap_port_t                    tcp      10390, 389, 636, 3268
ldap_port_t                    udp      389, 636

Verified that the port "20389" was successfully removed.

The OS:
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 Beta (Santiago)

389-ds-base version:
# rpm -q 389-ds-base
389-ds-base-1.2.11.29-1.el6.x86_64

# getenforce
Enforcing

Is some errors from remove-ds.pl logged in the IPA log or system log?  If the command line "`semanage port -d -t ldap_port_t -p tcp $port" fails, DSCreate returns an error with the message "Error: could not remove selinux label from port ####".

Created attachment 924105 [details]
logs

I don't see errors which you mentioned. I am attaching ipa and dirsrv logs. Can you check them? Maybe you will find something useful.

Thanks, David.  Looking into the log files...

In ipaserver-uninstall.log, I see ns-slapd processes are shutdown:
> Shutting down dirsrv: 
>     LAB-ENG-BRQ-REDHAT-COM...[  OK  ]
>     PKI-IPA...[  OK  ]

Then, following messages are logged. Probably, it's trying to make sure the server is really down?
> Stopping Directory Service
> 
> 2014-08-05T06:35:55Z DEBUG stderr=/etc/init.d/dirsrv: line 181: kill: (20093) - No such process
> /etc/init.d/dirsrv: line 181: kill: (20161) - No such process

But after that, I don't see much useful info related to the Directory Server...

I'd like to learn where "remove-ds.pl" is called to clean up the DS environment (or some other method equivalent to remoe-ds.pl?).  For instance, the command line is supposed to appear as the value of "args"?  Something like this?
> 2014-08-05T06:38:47Z DEBUG args=/usr/sbin/setsebool -P httpd_manage_ipa off

remove-ds.pl isn't called by IPA. This is a legacy thing. remove-ds didn't do what we needed very long ago (2008-ish). Things may be different now.

(In reply to Rob Crittenden from comment #5)
> remove-ds.pl isn't called by IPA. This is a legacy thing. remove-ds didn't
> do what we needed very long ago (2008-ish). Things may be different now.

If that's the case, this isn't really a 389-ds-base bug.  We clean up the SELinux port labelling with remove-ds.pl.  If IPA is going to continue performing it's own removal of 389 DS instances, it's going to have to handle it itself.  It would be much better for it to just use remove-ds.pl if possible.

Adding Martin to the CC list...

Martin, could you confirm how IPA is cleaning up the DS instance?

Ah, thanks Rob for the historical reasons shared in Comment 5. In last years, I did not care much about how DS is removed as it just worked. As we see, it does not.

Currently, we just remove the directories. In dsinstance.py, I see:

def erase_ds_instance_data(serverid):
    installutils.rmtree(paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % serverid)

    installutils.rmtree(paths.USR_LIB_SLAPD_INSTANCE_TEMPLATE % serverid)

    installutils.rmtree(paths.USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE % serverid)

    installutils.rmtree(paths.VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE % serverid)

    installutils.rmtree(paths.SLAPD_INSTANCE_LOCK_TEMPLATE % serverid)

    installutils.remove_file(paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % serverid)

    installutils.rmtree(paths.VAR_LIB_DIRSRV_INSTANCE_SCRIPTS_TEMPLATE % serverid)

    installutils.remove_file(paths.DS_KEYTAB)

    installutils.remove_file(paths.SYSCONFIG_DIRSRV_INSTANCE % serverid)

We can definitely try to switch to remove-ds.pl again and see if it works or not.

Moving back to FreeIPA component as this does not really seem as DS bug.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4487

Upstream ticket was scheduled for FreeIPA 4.2. As this is not a critical issue, we do not plan to backport to RHEL-6 (please provide a proper justification if you disagree). As such, moving this Bugzilla to RHEL-7.

Fixed upstream:

master:
55b7eed77e5f76c159ba157d020e93aa9d43bdc5 Use 'remove-ds.pl' to remove DS instance

Created attachment 1081358 [details]
log

VERIFIED - sanity only

- as port 7389 is default policy of SELinux in RHEL 7.x, not a bug 
- remove-ds.pl used

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html