Wooo Hooo !!!
Brilliant - I will begin testing it tonight. If I spot anything I will report back.
Looking good !!
I have only found two things so far and both are relatively minor and easy to fix.
- The folder /var/log/cmh is missing. As a result, log files are not being created.
- Timezones are not implemented. Here is what I did:
apt -U tzdata
and then create a mount /etc/localtime :/etc/localtime
This way it will automagically pick up the time from the host (assuming the host uses tzdata).
Note: it is possible to make this more general by passing in an environment variable e.g. TZ and then running some commands like:
ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone (not sure the second command affects anything btw)
In any case - for now I have gone with the first approach. So now my docker-compose.yml looks like this (remove the TZ variable and added the second mount):
version: '2'
services:
openluup:
container_name: openluup
image: vwout/openluup
restart: unless-stopped
network_mode: host
volumes:
- <a convenient folder on your host>:/mnt/uploads
- /etc/localtime:/etc/localtimeGood point about the timezones.
The logs mounts are equal to the Debian image. The openLuup logs are in /etc/cmh-ludl/logs/, or does it use /var/log/cmh (where Vera stores its logs) as well?
So it looks like (understand I’m new to this environment):
- ALTUI looks to, by default, log to /var/log/cmh BUT, if running on openluup, then that location is on openluup
- openluup logs by default to /etc/cmh-ludl/logs – so that’s where the logs for plugins installed on openluup go
- Vera of course logs to /var/log/cmh
There may be some startup mapping for openluup that can be tweaked (not got there yet) …
If I go to ALTUI → Misc → osCommand → Tail Logs (with your default install) it does not return anything. Adding that directory and restarting then provides log information.
The default command is: tail -n 50 /var/log/cmh/LuaUPnP.log
By the looks of it, it’s high level stuff, but “something” is definitely placing log entries there.
Executing tail -n 50 /etc/cmh-ludl/logs/LuaUPnP.log gives openluup information as well as locally installed plugins.
Not yet sure how to get to the vera logs from here :o
These may end up being some tweaks / mapping for the image as it gets figured out …
So - we are on the right track, this from the official openluup documentation
openLuup also maintains another log, which is a subset of the main one, and contains only device variable changes, scene invocations, and workflow messages. Those entries are written to a log file, if the /var/cmh/ directory exists, in /var/cmh/LuaUPnP.log,
One other thing that would likely be helpful: set up /etc/cmh-ludl as a docker volume so that updates to the image do not over write that directory (there may be others …) or instructions on how to copy from that directory to a folder on the host and then mount the host directory to the image (I can do that tomorrow). I kinda prefer the later since it will survive an accidental docker reset.
Well, there is no Vera in scope of the openLuup container. openLuup could be linked to your Vera, but the Vera logs won’t be in the container on /var/log/cmh, but on your Vera. To access them from altUI running on openLuup that is on another box, you need to mount the folders from your vera. sshfs could be an option there.
[quote=“Stuart, post:16, topic:199649”]So - we are on the right track, this from the official openluup documentation
openLuup also maintains another log, which is a subset of the main one, and contains only device variable changes, scene invocations, and workflow messages. Those entries are written to a log file, if the /var/cmh/ directory exists, in /var/cmh/LuaUPnP.log,[/quote] I can add the volume /var/cmh to have the Vera-like openLuup logs. Since you already have the full log, this may not add much other than the fact the removing information makes the remain stand out more, which could be usefull.
This is something I discussed with akbooer in the prelude to publishing the image, see [url=https://github.com/akbooer/openLuup/pull/13]https://github.com/akbooer/openLuup/pull/13[/url]. Detaching openLuup from the image could reduce the image to basically a lua image with some plugins. The directory /var/cmh-ludl is a volume already. It means that docker creates the volume when the image is started first time, Docker will copy the contents of the folder to the newly created volume in that case. Using a pre-created (e.g. named) volume won’t work, since it will remain empty.
FWIW, I generally add a sym link from /var/log/cmh to /etc/cmh-ludl/logs, and then the AltUI tail logs command works as is.
The images at vwout/openluup on Docker Hub are updated.
I applied the following changes:
- Providing /var/log/cmh Vera-style log folder (symlinked to openLuup logs)
- Debian based image: New tag (next to latest): ‘slim’
- Alpine based image: Enable timezone configuration via TZ environment variable
- Update to compose-file
Looking very good !
I was getting errors from the Alpine version, basically complaining about syntax errors. I did not check the debian version.
I believe the error is in the file openLuup_reload_for_docker Specifically the line
function openLuupShutdown {should be
openLuupShutdown(){at least when I make that change, all seems well :o
When/how did you get any errors? I can’t reproduce them.
I did notice that the shutdown script does not work how it should … it no longer prints to log to stdout for tracing by docker logs
The errors occurred when I tried to start a new container or restart with different runtime parameters. Cannot remember exactly. I was grinding through and not paying as much attention as I should. I mostly use a docker-compose file to create the container. It’s possible that I fat fingered something procedurally and ‘fixed’ something that did not need fixing.
I can go back and try again with the original syntax later tonight / tomorrow and see if I can reproduce. The error message was something about unexpected } – and mentioned the file openLuup_reload_for_docker so that’s what led me to suspect the syntax on the function definition.
One other thing - and I need to dig a little more: the volume declarations in the Dockerfile … My understanding (could easily be flawed) is that they end up being created at container creation time with a random named (for the volume). But what happens if you later delete the container and create a new one - do not these volumes get recreated? If that’s the case the date (from the previous container ) would not carry over to the new one. So I’m thinking it may be better to create named volumes the docker run command, or mount bind to folders on the host. Thoughts?
Nevermind, I linted the script(s) and they had errors anyhow. No curly braces though.
Your understanding of volumes is more or less correct. Volumes are created automatically by Docker when the container starts - at least for the volumes specified in the Dockerfile, unless a mount or bind is specified for the volume. This is a so called unnamed volume. The volumes however are not deleted when the container is removed.
So your data will be preserved. Just hard to find.
Thing is that the volumes that are created by Docker at startup of a container, are unnamed, so hard to recognize. You can, as I do in the composefile (or using docker volume create) manually create a named volume to mount with a container. The difference is that Docker only copies the data from the image to the volume in case of creation of an unnamed volume. When you bind or mount a volume, Docker does not do this.
At least, that was the case. Apparently, recently Docker changed. It also copies data to a newly created empty volume.
And that is what the composefile is using. It creates empty volumes for ludl (/etc/cmh-ludl/), logs and backups. At startup, the contents of the openLuup image is copied into the ludl volume. As long as this volume is used with a container, the data should be preserved. Updating openLuup in that case should happen via the auto-update feature of openLuup itself, not by installing a new image. A new image is only required to get environment bufixes and security updates.
The script openLuup_reload_for_docker had curly braces in the function declaration. Are we talking at cross purposes ?
You can, as I do in the composefile (or using `docker volume create`) manually create a named volume to mount with a container.
I was not using your compose file – so I best go take another look !
Again - thanks for taking this on and doing such a great job !!!
I meant to say that the linter did not complain about curly braces, but that there were a few other issues. One of which was the use of the keyword ‘function’, which apparently is allowed in bash, but not in sh.
Hi @vwout
Looking at your username it?s clear which one is yours, but it was interesting to see other Docker options for openluup listed too.
slightlyaskew/openluup
DOCKER - openLuup Container
vwout/openluup
DOCKER - Automated Build Ready to use openLuup environment with AltUI based on Debian with mountpoints for custom plugins.
airedale/openluup
DOCKER
I’m going to use Container Station on my QNAP NAS to install the Docker image, I believe the approach will be similar to Synology’s Container Station too ?
Are there any specific commands I should look to enter when creating the Openluup container?
Yep 
I decided to roll my own image since the others are big, undocumented and not updated recently.
The image is usable without any particular configuration, though you do want to map at last the exposed port 3480 to be able to access AltUI.
I don’t see this being configured in the screenshots. Maybe it is automatic on Qnap (I don’t own one), but you might want to check this in the advanced settings. The container does not have any other configuration that you must set. And I think you can reduce the amount of memory. OpenLuup does not need 8GB
There should not be that much difference between using it on any Docker host. The only thing is that to use persistent data stores for openLuup, logs and backups, you probably have to use the command line, just like on Synology. Qnap also does not seem to offer the use of named mounts via their UI.
Hi guys,
I’m running openluup in vbox now and want to migrate to docker, because of some strange behavior in openluup/AltUI. What is the easiest way to restore my setup in the docker container?
I don’t want to copy all files, because then I will probably have the same issues? The issue seems related to AltUI.
I know I need the user_data.json of course, but that is probably not enough.
Any suggestions?
Most likely reason for strange behavior is a rogue plugin. Do you have plugins installed?
Migrating configuration is the easy part, your dependency on plugins is the complicating part here since there is no way to automatically install plugins.
When you have the user_data.json, you can provide this to docker when you start the container for the first time, see the documentation on GitHub - vwout/docker-openluup: Dockerized openLuup environment with AltUI, or in the docker-compose file at docker-openluup/docker-compose.yml at master · vwout/docker-openluup · GitHub.
Openluup will import the data provided by the user_data.json as specified in the environment variable USER_DATA_JSON into its configuration. Any functionality depending on plugins won’t work until the plugins are installed.
I don’t know whether configuration related to not available plugins will survive, or when the configuration is kept when plugins are installed. This will require some experimentation.
If you know which plugins you need and which files are related to these plugins, you can try exporting these from vbox and storing them in a directory. Bind this directory as /etc/cmh-lu/ and openluup will load the plugins right from the start.
The good news is that you can try as many times as you want. As long as you keep your vbox configuration as is, you can recreate the openluup container as many times as you want.
I would recommend using a volume for at last the openluup environment, that is /etc/cmh-ludl/.
[quote=“vwout, post:30, topic:199649”]Most likely reason for strange behavior is a rogue plugin. Do you have plugins installed?
Migrating configuration is the easy part, your dependency on plugins is the complicating part here since there is no way to automatically install plugins.
When you have the user_data.json, you can provide this to docker when you start the container for the first time, see the documentation on GitHub - vwout/docker-openluup: Dockerized openLuup environment with AltUI, or in the docker-compose file at docker-openluup/docker-compose.yml at master · vwout/docker-openluup · GitHub.
Openluup will import the data provided by the user_data.json as specified in the environment variable USER_DATA_JSON into its configuration. Any functionality depending on plugins won’t work until the plugins are installed.
I don’t know whether configuration related to not available plugins will survive, or when the configuration is kept when plugins are installed. This will require some experimentation.
If you know which plugins you need and which files are related to these plugins, you can try exporting these from vbox and storing them in a directory. Bind this directory as /etc/cmh-lu/ and openluup will load the plugins right from the start.
The good news is that you can try as many times as you want. As long as you keep your vbox configuration as is, you can recreate the openluup container as many times as you want.
I would recommend using a volume for at last the openluup environment, that is /etc/cmh-ludl/.[/quote]
Yes I have multiple plugins installed. I understand that will be the tricky part. Maybe I will try to migrate in the near future, but there is no hurry anymore, because I have mij vbox running quite well again.
Thanks for the docker! I will definitely be using it in the near future. Probably when someone else has migrated successfully with plugins 