suggestions for improvement for the docker images of MinimServer

[airflow]

After some time using the docker images of MinimServer, I'd like to make a few comments about those images.

I think they could be improved. They don't really make use of the altered configuration/administration paradigms of containers.

Some ideas:

• Instead of having to enter the license key after initial startup via the GUI, this should be configurable via a docker-compose environment variable.
• Generally, the configuration of the server should be able to be mapped into the container for easy and reproducible recreation of the ready configured service (there were already some discussions about this on the forum).
• There should be a preconfigured healthcheck.
  

Generally, it's great the product is provided as docker images. Thanks!

[simoncn]

(15-03-2025 23:36)airflow Wrote:  After some time using the docker images of MinimServer, I'd like to make a few comments about those images.

I think they could be improved. They don't really make use of the altered configuration/administration paradigms of containers.

Thanks for these suggestions. See my comments below.

Quote:Instead of having to enter the license key after initial startup via the GUI, this should be configurable via a docker-compose environment variable.

Activating a full license requires interacting with the online license server to check whether this is permitted (key is valid and matches email, activation quota not exceeded, etc.) and to update the central license database. This requires the MinimServer instance to be running in the container. An interactive GUI is needed to inform the user of any issues.

Quote:Generally, the configuration of the server should be able to be mapped into the container for easy and reproducible recreation of the ready configured service (there were already some discussions about this on the forum).

Please post a link to the previous discussion. The profile feature of MinimServer (available on all platforms) supports applying a preconfigured configuration. If this is not what you are suggesting, please clarify.

Quote:There should be a preconfigured healthcheck.

Please explain what you mean by this.

Quote:Generally, it's great the product is provided as docker images. Thanks!

Thanks for your appreciation and feedback.

[airflow]

(16-03-2025 16:04)simoncn Wrote:  Activating a full license requires interacting with the online license server to check whether this is permitted (key is valid and matches email, activation quota not exceeded, etc.) and to update the central license database. This requires the MinimServer instance to be running in the container. An interactive GUI is needed to inform the user of any issues.

I understand your sentiment. But on the other hand it destroys the elegance of being able to deploy a licensed in an automated way. I have an idea for a compromise: If you would make it possible to define the license information via environment variables, it could work that in this case when you connect for the first time, you are greeted with a screen which shows the already entered license information and just prompts you to confirm.

Quote:Please post a link to the previous discussion. The profile feature of MinimServer (available on all platforms) supports applying a preconfigured configuration. If this is not what you are suggesting, please clarify.

I am referring to this discussion.

I think activating the correct, complete configuration for MinimServer should possible to be done in a more automated way as well.

I normally do it by pasting the prepared configuration into mscript like this:

Code:

cat /Music/minimconfig/minimserver2-config.mscript | /opt/minimserver/minimserver-2.2/bin/mscript

But I cannot really automate this step (in the course of creating the container), because the instance first has to be licensed before it accepts the confguration. So it becomes now two manual steps (1. license and 2. configuration).

Quote:

Quote:There should be a preconfigured healthcheck.

Please explain what you mean by this.

Docker offers healthchecks which can be already defined in the published images of MinimServer. It's possible to define them later individually by the administrator, but it could be already included.

For example, it could be something like a simple check whether a

Code:

echo about | /opt/minimserver/minimserver-2.2/bin/mscript

returns (contains)

Code:

MinimServer is running

[simoncn]

(16-03-2025 18:17)airflow Wrote:  I understand your sentiment. But on the other hand it destroys the elegance of being able to deploy a licensed in an automated way. I have an idea for a compromise: If you would make it possible to define the license information via environment variables, it could work that in this case when you connect for the first time, you are greeted with a screen which shows the already entered license information and just prompts you to confirm.

MinimServer doesn't use environment variables for configuration. Also, this doesn't feel like a good way to pass sensitive confidential information.

What is the scenario when something like this is required? I would expect creating a new licensed container to be an infrequent event as the number of licensed containers that can be in use is limited to the license device limit (3 or 5). Once created, a licesnsed container should usually not be destroyed because this would cause its license activation to be lost. If this is the case, entering license information using copy and paste when the container is first started doesn't seem to me to be too onerous.

Quote:I am referring to this discussion.

Thanks for this.

Quote:I think activating the correct, complete configuration for MinimServer should possible to be done in a more automated way as well.

I normally do it by pasting the prepared configuration into mscript like this:

Code:

cat /Music/minimconfig/minimserver2-config.mscript | /opt/minimserver/minimserver-2.2/bin/mscript

But I cannot really automate this step (in the course of creating the container), because the instance first has to be licensed before it accepts the confguration. So it becomes now two manual steps (1. license and 2. configuration).

Using profiles solves this problem. A profile file can contain properties that need a full license as well as properties that don't. Here is an example:

Code:

contentDir = /opt/Music
+tagOptions = Album.ignore.sort={A, The}
.profileVersion = 2.2

You can import and select this profile using a starter license. At this stage the tagOptions setting is not enabled. When a full license is activated, this enables the tagOptions setting.

Quote:Docker offers healthchecks which can be already defined in the published images of MinimServer. It's possible to define them later individually by the administrator, but it could be already included.

For example, it could be something like a simple check whether a

Code:

echo about | /opt/minimserver/minimserver-2.2/bin/mscript

returns (contains)

Code:

MinimServer is running

Thanks for clarifying. It seems that MinimServer already provides commands that can be used for this.

Please bear in mind that MinimServer supports many platforms and it is not feasible to provide deep platform-specific integration with all features of all platforms.

[airflow]

In case anyone's interested, this is how my docker-compose file looks now, with working healthcheck.

Code:

services:
  minimserver:
    image: minimworld/minimserver:latest
    init: true
    restart: always
    container_name: minimserver
    volumes:
      - /mnt/DATA/shares/musik:/Music:ro
    network_mode: host
    ports:
      - 192.168.0.2:9790:9790
      - 192.168.0.2:9791:9791
    healthcheck:
      # Use grep -q to check for "is running". Exits 0 if found, 1 otherwise.
      test: ["CMD-SHELL", "echo about | /opt/minimserver/minimserver-2.2/bin/mscript | grep -q 'is running'"]
      start_period: 60s  # Wait 60s before the first check
      interval: 30s     # Check every 30s after the start_period
      timeout: 10s      # Allow 10s for the command to run
      retries: 3        # Mark as unhealthy after 3 consecutive failures

[simoncn]

Thanks for posting this. Why is there a reference to port 9789? MinimServer uses ports 9790 and 9791. It doesn't use port 9789.

[airflow]

(10-04-2025 13:58)simoncn Wrote:  Thanks for posting this. Why is there a reference to port 9789? MinimServer uses ports 9790 and 9791. It doesn't use port 9789.

Thanks for the notice, that was actually an error in my docker-compose file. I now corrected it to contain both ports and not do any portmapping. What is port 9791 used for?

Not using network mode "host" any more (which would be better) is not possible (so it has to stay activated as mode=host), because otherwise the licensing doesn't work.

[simoncn]

Port 9791 is used for UPnP communication. Port 9790 is used for HTTP communication.

I haven't found a way to make UPnP discovery work without using network mode "host".