Struct names and members for secrets.conf

Julien ÉLIE julien at trigofacile.com
Thu Dec 23 22:51:07 UTC 2021


Hi all,

For the new secrets.conf file, we spoke about the following contents:

cancels {
     canlockadminsec: [ "password" ]
     canlockusersec: [ "anotherpassword" ]
}


I've created lib/secretsconf.c and include/inn/secretsconf.h (not yet 
committed) to handle the creation of the new struct for our secrets.

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?



To parse secrets.conf, I just search the "cancels" tag and get the 
values from it.  It works fine but will need changing when other secrets 
are added in the future.

     /* INN_PATH_SECRETS is "secrets.conf" in paths.h */
     configfile = concatpath(innconf->pathetc, INN_PATH_SECRETS);
     group = config_parse_file(path == NULL ? configfile : path);
     free(configfile);

     if (group != NULL)
         subgroup = config_find_group(group, "cancels");

     /* Unconditionally parse subgroup, even if NULL, in order
      * to initialize vectors. */
     secretsconf = secretsconf_parse(subgroup);

     if (group != NULL)
         config_free(group);



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.

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).


If we have something like that in the future in secrets.conf:

feed news.server.com {
     login: "login"
     password : "pass"
}

feed news.server2.com {
     login: "login2"
     password : "pass2"
}

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).




Maybe secretsconf->cancels (or whatever name) should also be constructed 
this way (a chained list of structs)?

struct cancels {
     char *tag;                    /* NULL */
     struct vector *canlockadmin;
     struct vector *canlockuser;
     struct cancels *next;         /* always NULL though */
};

Though I would be inclined not to have "tag" and "next".



Apart from that detail to finalize the patch, Cancel-Lock generation 
works fine!

-- 
Julien ÉLIE

« Et vous allez reprendre votre bateau… Et, mergitur ou pas, fluctuat !
   Compris ! Fluctuat ! » (Goudurix)


More information about the inn-workers mailing list