[SSSD] New version of the libini_config section merge design

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Mon Jun 2 13:37:10 UTC 2014


On 05/31/2014 04:45 AM, Dmitri Pal wrote:
> I reworked the design based on the feedback provided.
> It is a completely rewritten version.
> Please take a look.
> https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge

I'm likely awfully under-informed (I haven't seen any prior discussion or
requirements, never used the library), but I'd like to give my opinion anyway,
if only as an exercise.

I wouldn't like to steal much of anyone's time so please ignore me if I'm
entirely missing the point. I've likely missed some requirements and the below
needs details figured out, but I think this general approach would be better
for both end-users and developers.

First of all, the proposal sounds terribly complicated. Both in merging logic
and in permission requirements. What's worse, this complexity is hidden from
system administrators (users) in the code. It means that all the parameters
passed to "ini_config_augment" will need to be documented somewhere.

As in: "you can put these and these sections in these files and the files will
need to have these and these permissions and be owned by such and such user
and group, etc.". This will be needed for every application using this feature
and it will need to be updated with the code. And all hell will break loose
when someone decides to adjust ini_config_augment arguments based on
previously read keys/sections. Just because it can be done, you know.

Assigning special treatment to "augmenting" configuration, and adding ability
to ignore erros there specifically, also doesn't seem right. Given the
overwriting feature is provided, the *whole* of the actual configuration can
be placed there, and thus it seems better to give equal treatment both to the
"main" and to the "augmented" configuration. I.e. either provide a way to
ignore/enforce errors in both or in none.

 From my, once again, entirely uninformed view as a potential user and an
administrator I would have liked to see the following instead.

Allow both sections and keys appear more than once in a configuration file.
Repeated keys would overwrite previous value. New keys in repeated sections
would add keys. Missing keys in repeated sections wouldn't change anything.
I assume this is the way it works currently, as some QA tests use it.

Adjust the configuration language to add syntax to remove sections and keys.
Something which can be understood with little or no documentation. For
example:

     [section_a]
     key_a = 1
     key_b = 2

     [section_b]
     key_c = 3

     ; Add "key_d" to "section_b"
     [section_b]
     key_d = 4

     ; Remove "section_a"
     -[section_a]
     ; Start "section_a" anew
     [section_a]
     key_d = 42

     ; Remove "key_c" from "section_b" and overwrite "key_c"
     [section_b]
     -key_d
     key_c = 2

Add configuration language syntax to include files/directories of files,
optionally specifying file permission requirements and section modification
permissions. With this amount of features the need for documentation to read
them would be inevitable, but we can at least try:

     [section_a]
     key_a = 1
     key_b = 2

     [section_b]
     key_c = 3

     ; Include an application configuration file, only allowed to add some
     ; sections
     <application.conf add section_c_*,
                       user application,
                       group application,
                       mode 640>

     ; Include a subdirectory of configuration files, allowed to add any
     ; and modify/remove some sections
     <service.d add *,
                modify section_a_*,
                user root,
                group service,
                mode 660>

     ; Include another configuration file keeping the permissions intact
     <additional.conf>

Included files would be processed as if read at the spot of the directive
without any other requirements. I.e. they can continue existing or start new
sections. The usual ordering of files in directories would apply. Nested
includes should be possible allowing applications to sub-delegate some of
their configuration. Includes should not be allowed to relax section
addition/modification permissions, only to make them stricter. File permission
requirements should probably be changeable, though.

The support for the extended syntax may be configurable via the API.

This way there might be no need to add another function, although a feature
for merging many files from the code would be useful.

This way everything is visible to and controllable by the administrator and
doesn't need application-specific documentation, only the configuration
language documentation, which may be borrowed from the library and would
rarely change. More complicated include statements would need some comments,
but at least those would be close to the actual logic.

Nick



More information about the sssd-devel mailing list