Bug 623745 - SessionTimer with LDAPSecurityDomainSessionTable started before configuration completed
SessionTimer with LDAPSecurityDomainSessionTable started before configuration...
Status: CLOSED CURRENTRELEASE
Product: Dogtag Certificate System
Classification: Community
Component: Other (Show other bugs)
1.3
All Linux
low Severity medium
: ---
: ---
Assigned To: Ade Lee
Chandrasekar Kannan
:
Depends On:
Blocks: 445047
  Show dependency treegraph
 
Reported: 2010-08-12 12:42 EDT by John Dennis
Modified: 2015-01-05 20:18 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-04 16:22:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix (848 bytes, patch)
2010-08-12 15:13 EDT, Ade Lee
no flags Details | Diff

  None (edit)
Description John Dennis 2010-08-12 12:42:46 EDT
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 15:13:33 EDT
Created attachment 438510 [details]
patch to fix

patch to fix .. mharmsen, please review.
Comment 2 Matthew Harmsen 2010-08-12 16:54:31 EDT
attachment (id=438510) +mharmsen
Comment 3 Ade Lee 2010-08-12 17:27:35 EDT
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-10 21:56:45 EDT
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.

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