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

[John Dennis]

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 at redhat.com>