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 ^_^

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).

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

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.

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