NC APP config for user_saml and user_ldap app

[marioqxx]

Hi,

the apps user_saml and user_ldap cannot be configured with the provided configuration so far. This is because both support multiple configurations and first, an empty configuration needs to be created, then subsequently filled with the configured parameters. I do have this outside of this role, but would add it to the nc_apps.yml. The reason I ask here is, that this will blow-up the nc_apps.yml code with 3 tasks for each user_saml and user_ldap, totalling to 6 tasks. If this outweighs the benefit, I'll adapt my code and include it. Please let me know your preferences.

[aalaesar]

Hello there !
depending on the configuration workflow, maybe a custom module for configuring each application could be made.
It would create an interface for a large amount of use cases for peoples.
could you describe/give a sample of the workflow for each application ?

Regards

[marioqxx]

Hi @aalaesar,

the worklow is comparatively simple. Check presence configuration (php occ ldap:...), if not present, create new one (php occ ldap:...), then loop over each parameter and set in the (new created) config (php occ ldap: ...:set ). It basically resembles the OCC-commandline commands. All other apps that do not have multiple configurations work with the current implementation.

To the specifics. For user_ldap I run:
ansible.builtin.command: php occ ldap:show-config {{ nc_ldap_conf }}
ansible.builtin.command: php occ ldap:create-empty-config -p {{ nc_ldap_conf }}
in a loop with all the paremters to be set in a dictionary:
ansible.builtin.command: php occ ldap:set-config {{ nc_ldap_conf }} {{ item.key }} "{{ item.value }}"

For user_saml I run:
ansible.builtin.command: php occ saml:config:get -p {{ nc_saml_conf }}
ansible.builtin.command: php occ saml:config:create
in a loop with all the paremters to be set in a dictionary:
ansible.builtin.command: php occ saml:config:set {{ item.key }} "{{ item.value }}" {{ provider }}

The create in user_ldap allows to specify a configuration name, while this is not the case for user_saml. So for user_saml you run evidently into an idempotency issue (for rare cases).

Bottom-line: There is no common interface between the two apps and there is likely no common interface for other apps, i.e. an abstraction layer is required and it is not granted that the behaviour remains the same with an update of the app.

My implementation would add the tasks such, that the "conventional" configuration as for any other app can be used, but with an additional parameter - the name of the configuration - which is required for idempotency.

nextcloud_apps:
app_name_1:
source: "http://download_link.com/some_archive.zip"
conf: config-name
parameter1: ldap://ldapsrv
parameter2: another_value

As stated, this will add extra tasks to the nc_apps.yml file for each app, thus blows this file up.