Bug 1005316

Summary: RHEL6.5 ipa-server-install --uninstall does not remove /var/lib/sss/pubconf/kdcinfo.$REALM
Product: Red Hat Enterprise Linux 6 Reporter: Scott Poore <spoore>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED NOTABUG QA Contact: Kaushik Banerjee <kbanerje>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: grajaiya, jgalipea, jhrozek, lslebodn, mkosek, okos, pbrezina, rcritten, spoore
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-12 11:41:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Scott Poore 2013-09-06 16:07:55 UTC
Description of problem:

It appears that IPA uninstall is again not removing /var/lib/sss/pubconf/kdcinfo.$REALM

This was seen after an upgrade from RHEL6.2 to RHEL6.5:

/var/lib/sss/pubconf/kdcinfo.TESTRELM.COM
:: [   FAIL   ] :: Make sure that uninstall removed /var/lib/sss/pubconf/kdcinfo.TESTRELM.COM. Bug BZ 829070 (Expected 2, got 0)

That test simply does an ls check:

rlRun "ls /var/lib/sss/pubconf/kdcinfo.$RELM" 2 "Make sure that uninstall removed /var/lib/sss/pubconf/kdcinfo.$RELM. Bug BZ 829070"

Version-Release number of selected component (if applicable):
ipa-server-3.0.0-34.el6.x86_64

How reproducible:
always (at least for upgrades).


Steps to Reproduce:
1.  Install IPA (on rhel6.2)
2.  Upgrade to RHEL 6.5 3.0.0 version of ipa
3.  ipa-server-install --uninstall -U
4.  ls -ld ls /var/lib/sss/pubconf/kdcinfo.$RELM

Actual results:
directory still exists

Expected results:
directory removed by uninstall

Additional info:
This is the same thing previously fixed for:

https://bugzilla.redhat.com/show_bug.cgi?id=829070

Comment 3 Rob Crittenden 2013-09-06 17:22:07 UTC
It's interesting to note that we didn't actually make any changes in https://bugzilla.redhat.com/show_bug.cgi?id=829070 , so I'm not sure we can call this a regression.

We have no cleanup code associated with that file. I'm not sure who is responsible for deleting it, though sssd owns it. I don't know if authconfig or sssd is supposed to handle it.

Comment 4 Scott Poore 2013-09-06 18:12:44 UTC
Rob, 

Interesting.  I should have re-read through the whole bug there.

I may have been thinking of another bug where the IPA uninstall was going to be updated to handle removing something.   Let me check an upgrade again.  

Let me re-check something and run some more tests on this one.  I'm removing the regression keyword for now as well.

I'll get back to you guys later today on this one.

Thanks,
Scott

Comment 5 Scott Poore 2013-09-07 04:04:47 UTC
Ok, I saw this again in automated tests but, I'm not seeing it on some of my manual tests.  So, seems to be inconsistent.

I may need help next week tracking this down.

Comment 6 Martin Kosek 2013-09-09 07:30:01 UTC
Jakub, can you please advise? As Rob said, IPA does not really touch the kdcinfo...

Comment 7 Jakub Hrozek 2013-09-09 09:03:35 UTC
kdcinfo should be removed by the SSSD as soon as the provider goes offline or as soon as the SSSD is stopped. Does ipa-server-install --uninstall stop the SSSD? 

If so, and you still see the file around, then it's and SSSD bug.

Comment 8 Martin Kosek 2013-09-09 10:30:44 UTC
(In reply to Jakub Hrozek from comment #7)
> kdcinfo should be removed by the SSSD as soon as the provider goes offline
> or as soon as the SSSD is stopped. Does ipa-server-install --uninstall stop
> the SSSD? 

Yes.

> 
> If so, and you still see the file around, then it's and SSSD bug.

Moving to SSSD for now, until Scott confirms if SSSD was properly stopped when the kdcinfo was still around.

I am thinking that this may be a race condition in the test itself which does not wait until SSSD is stopped and tests it before that.

Comment 9 Scott Poore 2013-09-09 16:10:19 UTC
So, ipa-server-install --uninstall doesn't wait for sssd to come down completely?

If so, I think Martin may be right about race condition there.  Looking at the test output again, sssd is not yet shut down:

/var/lib/sss/pubconf/kdcinfo.TESTRELM.COM
:: [   FAIL   ] :: Make sure that uninstall removed /var/lib/sss/pubconf
/kdcinfo.TESTRELM.COM. Bug BZ 829070 (Expected 2, got 0)


root     15772     1  0 19:23 ?        00:00:01 /usr/sbin/sssd -f -D
root     15773 15772  0 19:23 ?        00:00:01 /usr/libexec/sssd/sssd_be --domain testrelm.com --debug-to-files
root     15774 15772  0 19:23 ?        00:00:00 /usr/libexec/sssd/sssd_nss --debug-to-files
root     15775 15772  0 19:23 ?        00:00:00 /usr/libexec/sssd/sssd_pam --debug-to-files
root     15776 15772  0 19:23 ?        00:00:00 /usr/libexec/sssd/sssd_ssh --debug-to-files
root     15777 15772  0 19:23 ?        00:00:00 /usr/libexec/sssd/sssd_pac --debug-to-files
:: [   FAIL   ] :: Make sure that sssd appears to be stopped as per BZ 830598 (Expected 1, got 0)

So, That test for 820598 may simply be that the ps ran before sssd could stop?

Comment 10 Martin Kosek 2013-09-09 16:22:15 UTC
Does the SSSD shuts down eventually? Like several seconds after uninstallation finishes.

It would be also useful to attach ipaserver-uninstall.log to find out if the sssd was really requested to stop and what was the result.

Comment 11 Jakub Hrozek 2013-09-10 08:37:22 UTC
Also, if you have the SSSD logs handy, there should be be a log message telling you that the files are being removed.

Comment 12 Scott Poore 2013-09-10 14:54:12 UTC
I believe this is right...I haven't had a chance to get logs but, I added a 60 second sleep before the check and it's not failing anymore...

So, I believe it's a test problem as mentioned.  I'm going to run a few more tests today and if I don't see anything else, I'll just close this one as NOTABUG.

Thanks,
Scott

Comment 13 Jakub Hrozek 2013-09-12 11:41:57 UTC
I ran a local test as well and saw the files being removed correctly. Closing on my end.

Scott, kindly reopen if you still see the problem.