By: Lars Van Casteren user 06 Jan 2019 at 3:03 p.m. CST

5 Responses
Lars Van Casteren gravatar
I have an Ansible role that installs and configures Gluu in a CI/CD kind of way as part of a pipeline. It borrows heavily from https://github.com/GuillaumeSmaha/ansible-role-gluu and there are also some things happening after Gluu is installed, like setting up the jdk cacert's, configuring ActiveDirectory (doing that straight into opendj) and configuring the cache-refresh. All this runs pretty smooth and is controlled from Ansible variables depending on the environment. I would now like to move to docker but I have a hard time understanding how to configure it automatically like with the Ansible roles from GuillaumeSmaha. How can you specify a .key & .crt to use as opposed to have the installer create a self-signed one and how can I add an OpenID connect client? It seems it should all be possible using config-init and the config.json but does it need to be present before running the runall.sh installation or can it be re-run afterwards? Thanks for any help!

By Michael Schwartz staff 07 Jan 2019 at 3:13 a.m. CST

Michael Schwartz gravatar
Did you check out Gluu Server Docker Edition: https://gluu.org/docs/ ? It's quite challenging to get all the components to work on Docker. We've done much of the heavy lifting for you if you can use our distribution. We also have Red Hat certified Linux containers.

By Lars Van Casteren user 07 Jan 2019 at 5:04 a.m. CST

Lars Van Casteren gravatar
Hello Michael, Thanks for your reply. Yes, I'm using the Docker Edition and it works perfectly to deploy a vanilla Gluu with self-signed certs. The issue I'm having is to automatically add an oxauth client configuration, a backend ActiveDirectory, custom login script and custom cacherefresh settings. I'm thinking the easiest way seems to be to insert the necessary values in the included ldif templates in the OpenDJ docker image, create a custom docker image and update the runall.sh to use that custom image as ldap so openDJ contains the configuration I need. I'm still thinking about a possible approach on how to achieve updating the cacert & nginx key/certificates with our own key/cert without breaking everything but I'm not sure which ones I have to update. Thanks for the heavy lifting ;) L

By Chris Blanton staff 07 Jan 2019 at 10:13 a.m. CST

Chris Blanton gravatar
Lars, > The issue I'm having is to automatically add an oxauth client configuration, a backend ActiveDirectory, custom login script and custom cacherefresh settings. For this you could build a custom image or have another container that adds information to the LDAP, which I presume you do already according to "configuring ActiveDirectory (doing that straight into opendj) and configuring the cache-refresh". I think creating a new container job that adds all your necessary clients to a new config as the best option. > I'm still thinking about a possible approach on how to achieve updating the cacert & nginx key/certificates with our own key/cert without breaking everything but I'm not sure which ones I have to update. You can modify the data in Consul to change out your ssl certs. They're saved as `ssl_cert` and `ssl_key`, if I'm remembering correctly. Once you've made those modifications, you can then do a `config-init dump` command to save the `config.json` to disk so you can back it up and use to redeploy at a later time with basically the same configuration with `config-init load`. See [the technical documentation](https://gluu.org/docs/de/technical/#config-init) for further use cases. Note that some of the configuration is "permanently" added to LDAP and changing the `config.json` or Consul configuration directory won't impact those configuration settings.

By Lars Van Casteren user 07 Jan 2019 at 10:59 a.m. CST

Lars Van Casteren gravatar
Hello Chris, Thanks for your reply. The additional container seems like a good approach, I just found out I can set specific base-inum & inum-org for config-init so I think I could get away by just generating an ldif with the configuration I need and copy it to the ldap container and execute it through docker exec and restart. I did try to change the ssl_cert & ssl_key directly in Consul but I think there was a trust error when trying to login to oxtrust but I'm not sure. So adding them to Consul, dumping & running config-init load is sufficient to also add them to the cacerts on each container when the config-init load. I presume I'll have to either delete the ./volumes or spin-up new containers (excluding config-init & consul obviously) Would there perhaps be a way to pass on the ssl_cert & ssl_key during installation? Thanks! Lars

By Chris Blanton staff 07 Jan 2019 at 11:05 a.m. CST

Chris Blanton gravatar
> The additional container seems like a good approach, I just found out I can set specific base-inum & inum-org for config-init so I think I could get away by just generating an ldif with the configuration I need and copy it to the ldap container and execute it through docker exec and restart. Right and you can use the same base configuration across deployments. > I did try to change the ssl_cert & ssl_key directly in Consul but I think there was a trust error when trying to login to oxtrust but I'm not sure. You need to make sure the containers restart as they need to reacquire the certs from the config and add them to their truststore before starting. > So adding them to Consul, dumping & running config-init load is sufficient to also add them to the cacerts on each container when the config-init load. I presume I'll have to either delete the ./volumes or spin-up new containers (excluding config-init & consul obviously) You shouldn't have to remove the volumes and the `/etc/certs` directory and trust store aren't persisted in our default configuration. > Would there perhaps be a way to pass on the ssl_cert & ssl_key during installation? I'm not sure we could pass those directly into a container, but again, you could copy a `config.json` add the necessary certs in there and instead of generating config, start a fresh installation with the `config-init` load command. The only requirement is that the `config.json` exist in the correct spot to be loaded by `config-init`