A fork of the profile library code....

[Theodore Ts'o]

Based on the discussion I've changed my profile parser to accept
quoted strings in tag and section names.  I.e., you can now do this:

["section with trailing spaces   "]
	"a silly tag name" = quux

I will _not_ however, support this sort of thing in my profile code
fork:

["arbi"tra"ry "si"ll"y quoting ga"mes]

As that just leads to bloat and I can't think of any justification for
ANSI C string concatenation...

On Thu, Jan 05, 2006 at 04:20:38PM -0500, Alexandra Ellwood wrote:
> Our config file could also benefit from tag synonyms like "ticket  
> lifetime".  I've seen a bunch of '-' versus '_' mistakes that  
> mystified users who couldn't understand why their libdefault edit  
> didn't work.  And once I spent several hours debugging code only to  
> discover that the code actually worked, and my test config file  
> contained a similar typo.

One of the things which I've been toying with is writing an optional
extension to the profile code to do configuration file verification.
The verifier would take a file which defines the schema for a
particular config file:

[libdefaults]
	default_realm = string
# The following krb5.conf variables are only for MIT Kerberos.
	krb4_config = filename
	krb4_realms = filename
	kdc_timesync = integer
	ccache_type = integer
	ticket_lifetime = integer
	forwardable = boolean
	proxiable = boolean

[realms]
	* = {
		kdc = string
		admin_server = string
		default_domain = string
	}

... and then print out warnings if a user had a string in a field that
expected an integer.  One could imagine also adding
application-specific verifiers, i.e.,

		kdc = kdc_specifier

Which would verify that the hostname was a valid hostname and the port
was a valid port number, and print warnings if that were not the case.

Since the verifier would print warnings if an unexpected tag (i.e.,
"ticket-lifetime") were to show up in a config file, it would help
mitigate mistakes made by someone who typo'ed their config file.

> (This is of course exactly the sort of problem which made me opposed  
> to the design goal that these files being hand editable by end users  
> in the first place.  However, since we're going to make them user  
> editable, we should make the process of editing them user friendly.)

Heh.  This is part of what I was talking about differences in
expectations/paradigms for different platforms.  I still remember
Athena release engineers swearing up and down (or more accurately,
*at*) the AIX SAM database, which was a binary-only, configuration
database much like the Windows respository.  Having non-text-editable
config files is extremely un-Unix like, and is pretty much a
guaranteed way to make Unix programmers/system administrators to be
very cranky.... hence the old joke of "AIX... it *reminds* you of
Unix".

						- Ted