Struct names and members for secrets.conf

[Julien ÉLIE]

Hi Russ,

>> When using secretsconf->canlockadminsec to access it, I'm wondering
>> whether it should not just be:
> 
>> cancels {
>>      canlockadmin: [ "password" ]
>>      canlockuser: [ "anotherpassword" ]
>> }
> 
>> and we just call secretsconf->canlockadmin.
>> When we have dozens of secrets in secrets.conf, it will be weird to always
>> add "sec" in the parameter name, won't it?
> 
> Agreed.  I kind of like the idea of having a secretsconf (or even just
> secrets) variable that holds the secret configuration and retrieving all
> the secrets from there.

OK for "secrets" instead of "secretsconf".


> We could even wrap that in a small library to
> make it easier to use everywhere in the source tree.

Like innconfval does for instance?
A secretsval program that would give the secrets when executed? (so that 
they can be retrieved from Perl, Python and shell scripts)

Yet, we may probably want a general program for that, and not a 
dedicated one for each configuration file...
Why not add a -f flag (for "file") to innconfval?  Default value is 
"inn.conf", and it can be set to other file names (like "secrets.conf").

innconfval -f secrets.conf canlockadmin
would then return the list of canlock admin secrets.


>> That's why it populates secretsconf->canlockadmin(sec).
>> Would it be better to have instead:
>> - secretsconf->cancels->canlockadmin
>> - cancels->canlockadmin
>> - cancels_secrets->canlockadmin
>> ?
> 
>> Maybe the first (secretsconf->cancels->canlockadmin) is better but we
>> may also create as many simpler structs as group types in secrets.conf.
>> Just asking in case you have a preference or another better idea.
> 
> The first has the nice advantage that it's super-obvious in the source
> code that you're retrieving a secret, which you should then be careful
> with (not log, etc.).

Yes, that's a nice advantage.


>> With the first proposal, I'll probably have to add a
>> secretsconf_get_cancels() function to retrieve the cancels groups in the
>> secretsconf struct (and then use the result as if it were one of the
>> last 2 proposals in fact).
> 
> Yeah, I wonder if we could have some sort of API that looks like:
> 
>      canlockadmin = get_secret(secrets, "cancels", "canlockadmin");
> 
> where get_secret() takes the secrets config_group and then a variable
> number of arguments, all strings, that represent the hierarchical path
> down to the key that we want.  It would just be a convenience wrapper
> around the config_find_group(secrets, "cancels") and then
> config_param_string(cancels, "canlockadmin", &data) call.

Not all secrets are strings.  Here, for canlockadmin, it is a vector.
So maybe we need get_secret_list(secrets, "cancels", "canlockadmin") and 
another get_secret_string() function for future string secrets?

A drawback of these getter functions is that we'll have to parse the 
config_group tree each time we need a secret.  That's pretty quick 
though, and we do not need them continuously but only for a few actions 
(like posting or initial authentication against a peer), contrary to 
parameters like inn.conf timeout, wireformat and like.
So it seems probably fine to query the secret in the config_group tree.


>> We would have secretsconf->feed being a chained list of structs:
> 
>> struct feed {
>>      char *tag;
>>      char *login;
>>      char *password;
>>      struct feed *next;  /* next would be for "news.server2.com" tag */
>> };
> 
>> (assuming we don't use nested groups inside them).
> 
> The intent of the config API was that you wouldn't take the config file
> and turn it into a chained list up front, but instead you'd iterate
> through it each time you needed something with
> 
>      feed = config_find_group(secrets, "feed");
> 
> and then config_next_group(feed) to get the next.  If that becomes tedious
> we could add some config_find_group_by_tag() function that takes both the
> group type and the tag.

Oh yes, I understand the principle.
We'll see for the config_find_group_by_tag() later if need be (not 
useful for Cancel-Lock).

-- 
Julien ÉLIE

« Only wimps use tape backup:  _real_ men just upload their important
   stuff on ftp, and let the rest of the world mirror it ;) » (Linus
   Torvalds, 1996)