[Pki-devel] ProfileSubsystem configuration with LDAPConnection

Fraser Tweedale ftweedal at redhat.com
Mon Aug 11 01:14:08 UTC 2014


On Fri, Aug 08, 2014 at 02:16:48PM -0400, Ade Lee wrote:
> On Fri, 2014-08-08 at 10:18 -0400, Ade Lee wrote:
> > On Tue, 2014-07-22 at 14:52 +1000, Fraser Tweedale wrote:
> > > On Mon, Jul 21, 2014 at 09:12:17AM -0500, Endi Sukma Dewata wrote:
> > > > On 7/20/2014 9:13 PM, Fraser Tweedale wrote:
> > > > >With the introduction of LDAP-based profiles, the ProfileSubsystem
> > > > >needs access to the profile configuration.  When spawning a new
> > > > >instance, the CMS tries to start its subsystems, but the
> > > > >ProfileSubsystem cannot start because it requires the LDAP
> > > > >connection details, which are not yet configured (this action is
> > > > >performed by SystemConfigService.configureDatabase).
> > > > >
> > > > >OK, so what to do?  I see two options:
> > > > >
> > > > >1) Remove the profile subsystem from the initial CS.cfg, so that it
> > > > >doesn't start up.  Add it back into CS.cfg as a configuration step;
> > > > >on the next startup, it will run and be happy, because the database
> > > > >configuration is there.
> > > > >
> > > > >2) Handle the absense of database configuration in ProfileSubsystem
> > > > >itself.  That is, keep track of whether initialisation has been
> > > > >successfully performed, and try again "just-in-time" when it is
> > > > >needed.  This probably violates semantics of the IProfileSubsystem
> > > > >API.
> > > > >
> > > > >Feedback or other ideas are appreciated.  I'm going to push ahead
> > > > >with option (1).  Both options feel like hacks but (2) seems like a
> > > > >worse hack ^_^
> > > > 
> > > > Agree with option 1, but instead of removing the profile subsystem from the
> > > > list we probably can also add something like an 'enabled' parameter.
> > > > 
> > > > The profile subsystem should be disabled by default, so it will be skipped
> > > > during initialization. After the configuration the profile can be enabled
> > > > and supplied with the proper database configuration.
> > > 
> > > Thanks Endi.  Having the 'enabled' parameter was a very good idea -
> > > it turned out to be much easier to implement than removing the
> > > parameter (which broke the dynamic subsystem loading code).
> > > 
> > 
> > How is this going?
> > 
> > Sorry to be a little late to respond to this, but I would think that you
> > will need some profiles loaded in order to issue the system certificates
> > to do the installation.  As I recall correctly, the profiles used for
> > this are in the same directory as the CS.cfg.
> > 
> > What does this mean?  Most likely that you will need to have the profile
> > subsystem start up in "file" mode, where it reads in the profiles needed
> > for installation and all the default profiles from files, and then
> > switch to ldap mode as a last step in the configuration.
> > 
> > Ade
> 
> Well, it looks like you got it working - which means that we don't
> really use the profile subsystem when creating the system certs.  Given
> that the server isn't really up yet, that makes sense.
> 

Correct; there was no issue with deferring the initialisation of the
profile subsystem.

> >  
> > > Cheers,
> > > 
> > > Fraser
> > > 
> > > > -- 
> > > > Endi S. Dewata
> > > 
> > > _______________________________________________
> > > Pki-devel mailing list
> > > Pki-devel at redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> > 
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 




More information about the Pki-devel mailing list