Bug 623745

Summary: SessionTimer with LDAPSecurityDomainSessionTable started before configuration completed
Product: [Retired] Dogtag Certificate System Reporter: John Dennis <jdennis>
Component: OtherAssignee: Ade Lee <alee>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: low    
Version: 1.3CC: alee, awnuk, benl, cfu, jgalipea, jmagne, mharmsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-04 20:22:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 445047    
Attachments:
Description Flags
patch to fix none

Description John Dennis 2010-08-12 16:42:46 UTC
In CMSEngine.init a SessionTimer is established, currently by default its bound to an LDAPSecurityDomainSessionTable instnace. However LDAPSecurityDomainSessionTable requires LDAP access (e.g. needs the internaldb password for binding). However the LDAP password is established by the admin configuration wizard. The cs.state will be 0 until the admin configuration is completed. Thus if the timer is started prior to CS being configured it will generate errors complaining about bad password configuration. The timer should not be started unless CS is in the configured state (cs.state==1)

The following is an IRC snippet discussing the problem:


(12:07:40 PM) jdennis: alee: I'm seeing errors from LDAPSecurityDomainSessionTable before the admin config wizard has run, I'm wondering if this is expected
(12:08:02 PM) jdennis: alee: here is what is happening
(12:08:48 PM) jdennis: a timer is setup in CMSEngine.init to timeout the session id's, it requires access to LDAP
(12:09:18 PM) jdennis: however the LDAP password has not yet been established because the admin wizard has not run yet
(12:09:56 PM) jdennis: thus when the timer fires it attempts an ldap login but fails.
(12:10:00 PM) alee: jdennis: yes - this is code that I recently added .. is it preventing the server from starting up?
(12:11:29 PM) jdennis: alee: after some investigation I don't think so, but it might have been a red herring as I was trying to pick off all the reported errors in the belief each was the result of something I broke, but I'm beginning to think it's not broken but expected.
(12:11:52 PM) alee: jdennis: in this case, it probably is expected ..
(12:12:11 PM) alee: that said -- I should probably put in a conditional in there 
(12:12:34 PM) alee: so that it does not try to login if the system is not configured
(12:12:49 PM) jdennis: alee: there is a conditional based on the CS state, 0 being "not yet configured" I believe, should the timer even be started in state 0?
(12:13:12 PM) alee: probably not .. let me look at the code ..
(12:13:47 PM) jdennis: alee: this is a check for the state, line 271 CMSEngine.java
(12:13:59 PM) jdennis: alee: is that the correct check?
(12:14:59 PM) alee: are you looking at dogtag or 8.1 code?
(12:15:20 PM) jdennis: alee: dogtag as of 6 weeks ago
(12:15:46 PM) alee: jdennis: ah ok -- thats why the line numbers do not match up ..
(12:16:05 PM) jdennis:  SessionTimer timertask = new SessionTimer(mSecurityDomainSessionTable);
(12:16:05 PM) jdennis:         if ((state == 1) && (sd.equals("existing"))) {
(12:16:05 PM) jdennis:             // for non-security domain hosts, do not check session domain table
(12:16:05 PM) jdennis:         } else {
(12:16:05 PM) jdennis:             mSDTimer.schedule(timertask, 5, (new Long(secdomain_check_interval)).longValue());
(12:16:05 PM) jdennis:         }
(12:16:41 PM) jdennis: alee: should the state==1 be state==0 ?
(12:17:09 PM) alee: no -- thinking ..
(12:18:08 PM) alee: it should probably be  ..
(12:18:26 PM) alee: if state ==0  || sd.equals("existing")
(12:19:45 PM) jdennis: alee: o.k. I'll update my local working version, do you want to patch mainline?
(12:20:26 PM) alee: yeah -- please file a BZ and I'll fix it

Comment 1 Ade Lee 2010-08-12 19:13:33 UTC
Created attachment 438510 [details]
patch to fix

patch to fix .. mharmsen, please review.

Comment 2 Matthew Harmsen 2010-08-12 20:54:31 UTC
attachment (id=438510) +mharmsen

Comment 3 Ade Lee 2010-08-12 21:27:35 UTC
Checked into tip:
[vakwetu@dhcp231-121 common]$ svn ci -m "Bug 623745 - SessionTimer with LDAPSecurityDomainSessionTable started before configuration completed" 
Sending        common/src/com/netscape/cmscore/apps/CMSEngine.java
Transmitting file data .
Committed revision 1175.

Checked into 8.1:
[vakwetu@dhcp231-121 common]$ svn ci -m "Bug 623745 - SessionTimer with LDAPSecurityDomainSessionTable started before configuration completed" 
Sending        common/src/com/netscape/cmscore/apps/CMSEngine.java
Transmitting file data .
Committed revision 1176.

Comment 5 Ade Lee 2011-05-11 01:56:45 UTC
Kashyap, 

Prior to the fix, for an unconfigured (but started) CA, errors were observed in the debug log because a timer was set to check the session table.  These would be LDAP errors from LDAPSecurityDomainSessionTable because the LDAP host and password were not yet established.

After the fix, these errors should not be observed.  In fact, you should only see logs from LDAPSecurityDomainSessionTable checks on configured security domain CA's.