The conf-file in the Domino Container build script

Posted on by

In my previous post, I showed that the Domino-container build script now has a menu. When Daniel announced his plans to include a menu, I asked him to add the option to output the result of a menu build in the form build.sh domino 12.0.2 FP3 -verse -nomad etc. Why? So you could use this in a script to build the same container image with an updated Linux OS base layer unattended. Daniel listened, but implemented it in a different way.

The Domino Container .conf files

In the menu, you see the option to write your selection and edit your selection.

If you write it, it will be written to <home-dir of current user>/.DominoContainer/default.conf. Edit selection will show you this file. This obviously gives you the option to make the selection you want for a specific server type, write that selection and rename the default.conf to something more descriptive like mailserver.conf, appserver.conf, travelerserver.conf etc. When you have these files, you can build the image for your mail server from a command line using:

cd /local/github/domino-container
./build.sh -conf=mailserver.conf

If your .conf file is somewhere else than in the default location, you have to add the full path.

Structure of the .conf file

If you look at your .conf file, you’ll see that the structure is pretty clear. This is an example.

# Saved conf/menu file
DOMINO_VERSION=latest
VERSE_VERSION=latest
TRAVELER_VERSION=latest
NOMAD_VERSION=latest
DOMRESTAPI_VER=latest
CAPI_VERSION=latest
LEAP_VERSION=latest
ONTIME_VERSION=latest
DOMLP_LANG=NL
AutoTestImage=yes
FROM_IMAGE=ubi9-minimal
CUSTOM_ADD_ONS=nshborg.taz#b0720811c7ed82da96e9df97d213672027e9d874a072fe802f6c9115593fd6e5,spamgeek.taz#35a3931e9b6708100f08c1c7d3c022f133c6cd9cf5212a9b2dd08bb93ddfd692
DOCKER_TZ=Europe/Amsterdam

The example above shows a .conf file with every possible add-on selected. Personally, I wouldn’t want a Dutch language pack for my Domino server, but otherwise the above shows my standard image.

As you can see, it lists “latest” by default for every selected item. If you would want a container image for Domino 12.0.2 FP3, you would simply change the corresponding line to this:

DOMINO_VERSION=12.0.2FP3

If you are building your image on a server that’s not capable of downloading software that’s not available locally, this also allows you to fix the build-script to versions which you do have available locally.

As you can see, there are also lines in my .conf file that don’t have a corresponding entry in the menu, but have to be set by adding extra switches to the build-command. Those extra lines where the result of running the build-command like this:

./build.sh menu -from=ubi9-minimal -custom-addon=nshborg.taz#b0720811c7ed82da96e9df97d213672027e9d874a072fe802f6c9115593fd6e5,spamgeek.taz#35a3931e9b6708100f08c1c7d3c022f133c6cd9cf5212a9b2dd08bb93ddfd692

These options are now part of the .conf file and therefore I don’t have to add them anymore to the build-command. If I don’t want to have them in my build, I would have to edit the selection and remove the lines by hand.

Build Configuration (build.cfg)

The menu options distinguish between the selection (W & E) and the configuration (C). The latter are parameters which are used in the build process. There are default options which you can change if you want. The most interesting, in my view, are:

  • SOFTWARE_DIR=/local/software
    Location where the script will look for software AND where the domdownload script will save the software it downloaded during the build
  • LinuxYumUpdate=yes
    This determines whether the latest updates for the base OS are installed during build
  • DOCKER_NETWORK_NAME=host
    host is the correct setting if you plan to use the host network for your Domino container (which is the default). If you choose to forward ports, you should enter a proper name for your network. If you put multiple Domino containers on the same host, you should put them all in the same network, so they can find each other.

There are also parameters which you can add here to the configuration

  • CONTAINER_VERSION=”<your version definition of the image>”
  • CONTAINER_MAINTAINER=”<name and email address of the maintainer>”
  • CONTAINER_DOMINO_NAME=”<description of the image>”
    Here you could mention for what type of server this image is meant

Thoughts

The new configuration files for the build-command make it easy to create configurations for different type of servers. This allows you to run the build-process unattended, which in turn allows you the periodically update the base OS in the container by creating a new image and updating the container automatically.

While writing this article, I realised that there are some items where there’s room for improvement:

  • No visual indicator in the menu for custom-addons in the .conf file
    Both the base image and custom-addons can be added to the .conf file by adding them in the command line when running the build script or by adding them manually to the .conf file. Even though you can’t select the base image from the menu, you do see which base image will be used. That’s not the case for the custom-addons. It’s handy that the custom-addons are saved in the .conf file, but the fact that there’s no visual indication for them, might lead to unexpected results
  • Some of the build.cfg parameters would be better suited for the .conf file
    A description of the image would be specific to a certain type of server. If you create a mailserver.conf, appserver.conf etc, you would probably want to add these parameters to these .conf-files to have them automatically integrated in the image description (which would be visible through docker image inspect <image-id>)
  • No .conf parameters for borg, tika and some other build options which can be set via the command line
    This is a bit of gold plating, but for consistency it would be good if all parameters that can be set while running the build-script (visible through build.sh help) are configurable in the .conf file AND have a visual indicator in the menu.

That said, the .conf file is a great addition to the project which makes it very easy to create the same type of container image each time that you run the build-script. The option to create multiple .conf-files with different options, opens up a world of possibilities.