request: integration of ldap backend

[brainchild0]

The documentation makes no mention of any backends being integrated in the container image. Users wishing to integrate with an LDAP server would be able to do so if the backend were included.

[gcavalcante8808]

Hi @brainchild0,

well this would be a good feature I think.

Actually I don't work with kerberes in a daily basis anymore, but if you can provide some configuration files or commands its should be possible to provide the feature.

What do you think?

[brainchild0]

I am considering attempting some work to expand the project, though I make no promises.

Having considered the project broadly, I emphasize the following three closely-related directions for improvement:

1. Introduction of unit tests.
2. Introduction of a more complete template system, for generating configuration files on initial launch.
3. Support for multiple back ends, according to options given on initial launch along with configuration options.

As noted, I consider the three areas of work closely related, in particular, with the two former supporting the final.

Expanding functionality for other back ends, especially including the more complicated processes required for successful integration with an LDAP server, creates a need to verify consistent function, against regressions, or against differences for the various back ends. As such, unit tests have an important relation to support for LDAP back ends.

Similarly, a more comprehensive and flexible system for generating the configuration files would permit a cleaner separation of concerns when applying differences in configuration based on the selection of back end.

Such are my current thoughts on the subject. Please let me know yours.

[gcavalcante8808]

Hi @brainchild0,

Those are good ideas indeed. As we start to think more in a product/feature way, I agree that the first think that would be those unit tests.

I can bear the test writing (and CI configuration as well).

The items 2 and 3 seems to be more closely related, as we can use the template system to provide common configurations.

If you can provide some sample/configuration files maybe we can discuss about some templating options as there is plenty of options: since a solution like envsubst to jinja2/mustache/tmpl ...

[brainchild0]

I can bear the test writing (and CI configuration as well).

I have started some of this work, in case you want to wait until I am ready to share.

I hit some obstacles with bugs in Linux and Docker related to adding and removing container networks in rapid succession, but hopefully I can resume progress with effective workarounds.

The items 2 and 3 seems to be more closely related, as we can use the template system to provide common configurations.

Yes, but tests are related too. LDAP integration offers many opportunities for failure, so reaching a useful distribution depends on proving consistent operation.

maybe we can discuss about some templating options as there is plenty of options: since a solution like envsubst to jinja2/mustache/tmpl ...

I agree these tools represent the preferred direction.

I originally transitioned to envsubst for compatibility with the existing text, but I believe Mustache will provide an appropriate balance of flexibility, portability, and distribution size. Clean formatting and conditionals are valuable advantages over envsubst.

[gcavalcante8808]

Hi @brainchild0,

I have started some of this work, in case you want to wait until I am ready to share.

I hit some obstacles with bugs in Linux and Docker related to adding and removing container networks in rapid succession, but hopefully I can resume progress with effective workarounds.

Initially, as I had an previous idea on how to test it, I just implemented the tests on PR #9. The test part seems fine currently.

Yes, but tests are related too. LDAP integration offers many opportunities for failure, so reaching a useful distribution depends on proving consistent operation.

I agree these tools represent the preferred direction.

I originally transitioned to envsubst for compatibility with the existing text, but I believe Mustache will provide an appropriate balance of flexibility, portability, and distribution size. Clean formatting and conditionals are valuable advantages over envsubst.

Mustache seems to be a good choice then.

As the tests are e2e, I think that is possible to change the backend (ldap, h2db, etc) and still verify by using the current tests.

If you can contribute if a PR or some configuration files that would be really nice and useful. Thanks!

[brainchild0]

Initially, as I had an previous idea on how to test it, I just implemented the tests on PR #9. The test part seems fine currently.

I will review your work. I took a rather different approach, and will need some time to weigh the merits of each.

As the tests are e2e, I think that is possible to change the backend (ldap, h2db, etc) and still verify by using the current tests.

I think it would be feasible, as well as advisable, to reuse much of the client-side testing processes for all the various back ends, as such would ensure consistent and correct functionality regardless of storage details on the service side.

Nevertheless some back ends, especially LDAP, have varied and non-trivial configuration cases, and it may be important to ensure correct behavior across a range of such variations. Further to same considerations, certain processes, such as those related to user management, require additional steps in the LDAP directory.