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/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
