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/