(Final?) krb5.Conf Lexer/Parser Proposal

[Alexandra Ellwood]

On Jan 6, 2006, at 4:49 PM, Theodore Ts'o wrote:

> On Fri, Jan 06, 2006 at 04:16:03PM -0500, Alexandra Ellwood wrote:
>> Support folks for the Mac are already used to asking for the user's
>> config files in three different locations, and at least so far users
>> have been good about returning all the files.  And yes, several times
>> we've gotten more than one file back in an Apple bug report with a
>> user config file adding the realm that causes the failure and setting
>> default_realm to it.
>
> Sounds like a useful thing to do would be to create a small tool which
> takes all of the config files and integrates them all into an
> "equivalent single config file", either for the user's edification or
> for sending to support folks....
>
> I think that would solve the concerns about support.

If the files aren't self-explanatory haven't we failed in our goal to  
make it human editable?  And if we expect users to use a special tool  
to display what the file really does then why don't we have them use  
one for editing it that doesn't let them produce invalid files in the  
first place?

It seems to me that if we expect folks to edit these files with a  
text editor then the text in the file must be obvious and self- 
explanatory.


Also, I've never seen support folks have trouble with the concept  
that the contents of the two files are merged with tags in the first  
one taking precedence.  However I've never tried to explain the final  
signifier to anyone who wasn't looking at the profile code.  I didn't  
even know it existed until a month ago because I've never seen it  
used, despite handling bug reports on a platform that has supported  
multiple configuration files for the last 4 years.


>> Obviously that's a contrived example.  My real point is that the
>> final signifier '*' syntax is difficult to see in a large config file
>> and difficult to figure out what it does.  If we decide we want to
>> preserve the final signifier mechanism I would argue we need a more
>> noticeable and self-descriptive syntax for it.  The current syntax is
>> more appropriate for a machine-generated config file with a GUI  
>> front-
>> end that displays what is going on in a clear and obvious manner.
>
> Granted, it could be better.  Would something like this more fit  
> the bill?
>
> ["top-level section] final
> 	ticket_lifetime = 36000
>
> [realms]
> 	ATHENA.MIT.EDU = final {
> 		kdc = KERBEROS-2.MIT.EDU:88
> 		admin_server = KERBEROS-2.MIT.EDU
> 	}

This sort of syntax would be preferable, presuming we decide we need  
this functionality.  I'm still not convinced that the added  
complexity is worth it.


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>