Hide Forgot
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): ipa-server-3.0.0-37.el6 How reproducible: Steps to Reproduce: 1.ipa-server-install 2.semanage port -l | grep ldap 3. 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:
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