Bug 1125950 - ipa-server-install --uinstall doesn't remove port 7389 from ldap_port_t
Summary: ipa-server-install --uinstall doesn't remove port 7389 from ldap_port_t
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Pavel Picka
QA Contact: Namita Soman
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-01 12:13 UTC by David Spurek
Modified: 2015-11-19 12:00 UTC (History)
8 users (show)

Fixed In Version: ipa-4.2.0-0.1.alpha1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-19 12:00:50 UTC

Attachments (Terms of Use)
logs (3.76 MB, application/x-gzip)
2014-08-05 07:01 UTC, David Spurek
no flags Details
log (1.52 KB, text/plain)
2015-10-09 14:16 UTC, Pavel Picka
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2362 normal SHIPPED_LIVE ipa bug fix and enhancement update 2015-11-19 10:40:46 UTC

Description David Spurek 2014-08-01 12:13:00 UTC
Description of problem:
ipa-server-install --uinstall doesn't remove port 7389 from ldap_port_t

ipa-server-install enables ldap_port_t for tcp port 7389 but uninstall doesn't remove it

[root@pes-guest-79 SOURCES]# semanage port -l | grep ldap
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

after ipa-server-install 

[test]semanage port -l | grep ldap
ldap_port_t                    tcp      7389, 389, 636, 3268
ldap_port_t                    udp      389, 636

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
2.semanage port -l | grep ldap

Actual results:
semanage port -l | grep ldap
ldap_port_t                    tcp      7389, 389, 636, 3268
ldap_port_t                    udp      389, 636

Expected results:
semanage port -l | grep ldap
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

Additional info:

Comment 1 Martin Kosek 2014-08-04 10:05:29 UTC
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:

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

Comment 2 Noriko Hosoi 2014-08-04 19:26:14 UTC
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

# getenforce

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 ####".

Comment 3 David Spurek 2014-08-05 07:01:53 UTC
Created attachment 924105 [details]

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.

Comment 4 Noriko Hosoi 2014-08-05 17:09:16 UTC
Thanks, David.  Looking into the log files...

In ipaserver-uninstall.log, I see ns-slapd processes are shutdown:
> Shutting down dirsrv: 
>     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

Comment 5 Rob Crittenden 2014-08-05 18:18:17 UTC
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.

Comment 6 Nathan Kinder 2014-08-05 18:28:20 UTC
(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.

Comment 7 Noriko Hosoi 2014-08-05 19:01:10 UTC
Adding Martin to the CC list...

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

Comment 8 Martin Kosek 2014-08-06 14:47:23 UTC
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.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.

Comment 9 Martin Kosek 2014-08-11 15:26:14 UTC
Upstream ticket:

Comment 10 Martin Kosek 2014-08-13 14:53:20 UTC
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.

Comment 11 Martin Kosek 2015-02-13 09:28:41 UTC
Fixed upstream:

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

Comment 14 Pavel Picka 2015-10-09 14:16:41 UTC
Created attachment 1081358 [details]

VERIFIED - sanity only

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

Comment 15 errata-xmlrpc 2015-11-19 12:00:50 UTC
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.


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