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
Created attachment 438510 [details] patch to fix patch to fix .. mharmsen, please review.
attachment (id=438510) +mharmsen
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.
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.