[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 18:46:32 UTC 2010


See below
>
> We really need to have
> regex =
> as an option. For example:
> [ldap_uri]
> type = field
> vtype = string
> regex = ldaps?://[\w\.]*
> list = true
> sep = , #How would we do space-separation? Should we even bother?
>

We can look into regex validation. Do not see big deal here.
Will be a special function though. Can be added incrementally
in a separate patch and handled as a separate task
(within v1 validation functionality).

As for separators I imply that space is always a valid separator.
Those would be additional separators we can check.
Adding comma to the list for example would not generate an error and
would parse list:
foo bar baz
the same way as
foo,bar,baz
or
foo, bar, baz

There was a bug recently about the similar issue.
Multiple separators for a list is already baked into the parsing logic.


> [snip]
>
> This example is completely unparseable to my brain. Could you please try
> representing it with a real-world example, such as ldap_uri? Also, I
> don't like seclist, secprefixref and secref. They are not descriptive
> and it will be impossible for anyone to keep them straight.

But this is what we have in sssd.conf

I am talking about the:

services = nss, pam

Services attribute is a section list meaning that the nss and pam
sections need to be defined.
Another example of the section list is the "domains" attribute.

domains = redhat.com

But the sections are actually named:

[domain/redhat.com]
...

So to describe it one would say:
[domais_def]
name = domains
section = sssd
seclist = yes
secprefix = domain

Now imagine that "domain" is actually not a constant but a value of
another key in the ini file.
Then we would have to use some kind of the reference.
That would be something like "secprefref". But currently it is not used
so we can skip it for now.

So based on the definition of the "domains" key the sections that should
be present in the INI file
should be constructed as the value of the key in the actual ini file
prepaneded with the word
"domain". So how I can say that a key should belong to such a
dynamically defined section?
This is where the "secref" is going to be used. See example at the end
of the mail.


We will need to come up with some better "implication" rules and
describe it.
For example: if vtype is defined it should be implied that  this is a
field. If the regex is defined then it should imply vtype = string and
so on.
But this we can do and build as we go.
One lesson for this is to write good doc as you go.


> [snip]
>
> See above, but we need to add, at a minimum, support for
> regular-expression handling. I'd also prefer it strongly if we could add
> support for something like +=
>
> In other words, I want to be able to say:
> [id_provider]
> type = field
> vtype = multi
> choices = local
>
> in the core config file, but then be able to say:
>
> [id_provider]
> type = extend  #implies vtype=multi
> choices = ldap
>

I do not understand what you are trying to say here.
I think I missed one other key that I wanted to include: values (or may
be "choices" as you suggested)

choices = local, ldap

would mean that the value for the key can be only one from the list.
If the list = yes for such value, it would mean that each of the
values for the key in the real ini file should be one of those.
For example:
is schema:

[family]
name = family
section = building
list = yes
vtype = string
choices = Dad, Mom, Son, Daughter

In the config file:
family = Mom, Son, Son       <- will be Ok

family = Mom, Sister, Son       <- will will generate and error because
"Sister" is not a valid value

 

> in the sssd-ldap.conf and have the resulting combined INI be effectively:
>
> [id_provider]
> type = field
> vtype = multi
> choices = local,ldap
>
>
> This way, for things like the providers, we can provide a selection list
> of options. Since otherwise, our only option would be
> [id_provider]
> type = field
> vtype = string
> regex = .*
>

So I think what you are trying to say is:

(in schema)

[domais_def]
name = domains
section = sssd
seclist = yes
secprefix = domain

[id_provider]
name = provider
secref = domains_def
vtype = string
list = yes
choices = local, ldap

(will mean that)

The key "provider" will have a string value from the provided
choice of "local, ldap" and will belong to the section that will be
dynamically
constructed from the value of the key "domains" in section "sssd" using
prefix "domains"

[sssd]
domains = somewhere.com
...

[domain/somewhere.com]
provider = ldap
...




-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list