ProfileSubsystem configuration with LDAPConnection
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 ^_^ Cheers, Fraser
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. -- Endi S. Dewata
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
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
Cheers,
Fraser
-- Endi S. Dewata
_______________________________________________ Pki-devel mailing list Pki-devel@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@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
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@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (3)
-
Ade Lee -
Endi Sukma Dewata -
Fraser Tweedale