(Final?) krb5.Conf Lexer/Parser Proposal
tytso at MIT.EDU
Mon Jan 9 11:33:33 EST 2006
On Mon, Jan 09, 2006 at 09:17:54AM -0500, Jeffrey Altman wrote:
> Theodore Ts'o wrote:
> > Yes, but you still don't and can't know how to effect certain changes,
> > because you still don't know from which file various relations or
> > sections might come from. For example, if you want to delete a kdc,
> > and it is in the first profile file, then it's easy --- you just
> > delete the relation. But if it isn't, you have to replicate the realm
> > information, slap the finalizer on it, and then remove the first KDC
> > --- but there's no way to know that using the current API.
> This is not a failure of the API. This is a failure of the state
> information stored in memory. The profile library can store with
> every relation the source of the data in that relation. There is
> absolutely no reason that the application should be aware of where
> composite data comes from.
Actually, it *is* a failure of the API. The profile library already
stores all of the relations in per-file trees. (It has to, since it's
the only way it can easily reread a changed file without having to
reread everything.) It just doesn't doesn't report the information to
application that way; in fact, it goes out of its way to make things
look like it comes a single file.
Part of this is for an application that is only querying the profile,
it doesn't want or need to know which file it came from; one of the
reasons why I wonder if there ought to be seperate API's or indeed
entirely different libraries for querying the profile and for GUI
applications wanting to update one or more config files.
> System administrators are clueful enough to be able to configure the
> profile to refer *only* to the "system" profile and not the "user"
> profile or to be able to edit the file by hand.
Granted, good point.
More information about the krbdev