Apache uses its service credentials to retrieve the schema from LDAP at start up. We use the credentials because of the requirement to allow disabling anonymous binds in 389-ds.
Right now we try the authentication just once and fail the IPA server startup if the authentication fails. Simo has suggested we try this authentication at least more than once, perhaps 3 times.
Simo clarified. What this really should do is fetch the schema again if it wasn't retrieve the first time.
The use case is LDAP is down when Apache starts so it can't get the schema. It should try again when a request comes in.
After some research I'm not sure what the approach should be here. The suggestion to try again when a request comes in is certainly an option, but that would mean to detect whether schema is already loaded during every single request. Frankly I don't like that idea.
I didn't find many parts depending on schema loading, maybe the right approach would be to load the schema when a command needs it.
Ok, I discussed this with Pavel and neither of us doesn't get what is the purpose of this ticket. When loading the schema during startup fails, the IPA application will completely fail to start. Therefore I'm in favor of closing this bug. Rob, what do you think?
Not starting is the problem. What is desired is handling errors better, and it may involve not requesting the schema at startup at all (perhaps).
We need the schema to do all sorts of validation in the code which is why I fetch it at startup. I'm not sure under what conditions Apache would start without 389-ds but the behavior isn't so nice, all client requests are denied. I couldn't find a way to not start Apache at all so I just had to abort the wsgi app.
Perhaps if there is no schema it can be obtained the first time it is needed using whatever credentials are available? The schema should not have any special protection on it so it should succeed.
The only reason I went through the trouble of using the host keytab to fetch the schema is in case anonymous binds are disabled in the server.
Replying to [comment:6 rcritten]:
Not starting is the problem. What is desired is handling errors better, and it may involve not requesting the schema at startup at all (perhaps). We need the schema to do all sorts of validation in the code which is why I fetch it at startup. I'm not sure under what conditions Apache would start without 389-ds but the behavior isn't so nice, all client requests are denied. I couldn't find a way to not start Apache at all so I just had to abort the wsgi app.
Yes, that one I get - another solution might be to return always an answer that the server isn't reachable or something like that.
I might need a bit more information about the schema usage, I grepped through the code several times and I didn't find a place where schema is used the way you say it is. The only place is is used is for some kind of JSON validation and I already have a patch which is loading the schema there if it hasn't been loaded yet. That means the only thing left to do is to erase the schema loading at startup.
Yes, that was basically my idea.
For where it is used, look in ldap2.py for:
decode_dict_vals_table_keygen (used to determine data types in ipalib/)
Also look for get_allowed_attributes() and get_single_value()
Pushing to 2.1. We have a patch for this but it reaches deep into the code so is risky. The workaround for this is to restart the httpd process so seems easy enough.
attachment freeipa-rcrit-787-schema.patch
master: 868d4e7[[BR]] ipa-2-0: f8f69e9
Metadata Update from @rcritten: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.1 - 2011/05
Login to comment on this ticket.