[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Freeipa-devel] should server install be done in two stages?

Let me throw out an idea, see if it rings true ...

We seem to have a somewhat awkward install scenario that I think is in part due to the lack of a "post install" step, but maybe I'm just not understanding the architecture well enough. Here's the issues:

We use LDAP for our backend, some ipa components need to modify the contents of our dirsrv instance or modify it's configuration. We have a nice interface in ipaldap.py for connecting to the server adding/modifying entries. But we're not using that interface during server install, I assume because we haven't bootstrapped far enough to be able to bind to our ds instance as the admin. But imagine if we had...

Right now we're getting around this problem with a proliferation of ldif template files in /usr/share/ipa and passing them to /usr/bin/ldapmodify with the admin password. IMHO its a bit awkward, probably doesn't scale gracefully, and its probably not the best mechanism to take into account site wide defaults.

I'm finding for the radius stuff, and I think this has general application, a lot of what I want to do to initially set things up is not really bootstrapping, rather it's things I'd like to do by calling our LDAP API (e.g. add/modify entries). I could use the LDAP API if we had completed the bootstrapping stage. Suppose IPA components were installed/instantiated in two steps instead of just one, bootstrap and postinstall.

During bootstrap your component is called to do only what is necessary to instantiate itself. Such things might include creating a service principal and installing schema.

Later your component is called for a postinstall step. At this point you're guaranteed the directory server is up and running, the kdc is up and running, and the necessary principals and keytabs have been created. You're then free to use the API we've created. It's also would be a great time to take into account site specific defaults which you might want to take into consideration as you finalize your installation configuration.

What I've been finding is I need to implement things twice, once using bootstrap methodologies and once again as "normal" code, it's a unfortunate redundancy. Here is an example: Radius has profiles, we'll have an API which allows one to create and modify a profile. However, there needs to be an initial default profile. Right now the only way to create the initial default profile is with bootstrap ldif's, I can't call the API to create a profile and set it as the default :-( Also when the default profile was created it would be nice if it could take into account site defaults. This is why I feel like there is a stage missing during the install process.

Thoughts, Comments?
John Dennis <jdennis redhat com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]