(Final?) krb5.Conf Lexer/Parser Proposal

[Theodore Ts'o]

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.

						- Ted