[Reactor] Bug when sending MQTT boolean payloads

[tamorgen]

Good day all,
I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing.

I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container.

Has anyone done this? Any advice?

[therealdb]

Just copy storage and config from your bare metal install, point the container paths to the disk and you're good to go. Very easy*.

• this excludes external controllers, but the relative installation is well documented.

[toggledbits]

@tamorgen said in Advice reqeusted to migrate MSR from Bare Metal to Container:

Any advice?

I know nothing about Podman and can't provide much help there, but I can tell you how the Docker images are built, and you can probably use that info to help with building your own Podman images.

The biggest structural difference between bare-metal and the docker image is that all of the writable subdirectories are moved to /var/reactor within the image. They do not live under the Reactor install directory as they do in a bare-metal system. This is done by setting the REACTOR_DATA_PREFIX environment variable within the image to /var/reactor. Reactor will apply this prefix when it goes hunting for those data directories: config, storage, logs, ext, and locales. In the case of docker, it's then easy to bind this /var/reactor directory inside the image to a user directory on the real user file system outside the image (a thing docker does). The goal is that no writable directory lives inside the eventual container, and this is important, because the container is temporary — it is destroyed and recreated when the image is updated, and possibly even when the container is stopped, and if your writable data was in there, you'd lose your entire configuration and states every time. When a docker user installs Reactor, they create a directory (usually in their home directory) to house all this data. They configure the container to map /var/reactor inside the container to this data directory outside the container, so whenever Reactor writes to configuration or storage, it ends up writing to files inside that data directory. If the container is deleted and recreated, that data isn't lost because it's now living outside the container.

Reactor runs as root inside the Docker container. This is a legacy docker-ism. Containers exist so that things could be run as root but still be... well, contained... prevented from fully exercising root's (absolute) power over other things in the host system. Within the docker container, Reactor runs as root but it's only going to be able to manipulate things inside the container. It can't stop other system processes, take over system devices that haven't been configured for it, or go mad infecting or deleting files outside the container. Podman apparently likes to run tasks in user land (i.e. as a user other than root), and this is something you'll need to research how to handle. That may also determine where inside the image you choose to put the Reactor build itself.

Under docker specifically, Reactor is aware that it's running in a container, because I manipulate data inside the image so it will know that, but it's just informational. It doesn't modify its behavior in any meaningful way, so you won't need to change anything else about Reactor, I think.

I think the long pole here is that you're going to have to create your own image to use with Podman. I don't think it will use docker images directly. There is some suggestion that you can run a docker container inside a Podman container or something to that effect, but that sounds to me like it will complicate your configuration and therefore your troubleshooting when things aren't going well, and I don't recommend it. Your Podman image/container will need to have all of the same dependencies resolved as a bare-metal install, so the image needs to have a good version of nodejs (LTS, 20+) and all of the npm package dependencies installed. You will likely need to configure some kind of virtual network interface that the running container will use internally to access the network externally, etc. (this is simpler than it sounds, but necessary for LAN and WAN access).

A key consideration before you venture forth may be this: I don't use or support Podman, and am not likely to. I have enough work handling the configurations I do support. You would be making yourself the subject matter expert in this community for Podman. That could be very good if you're the kind of person who loves to dig in themselves when things aren't working and figure it out, build up a knowledge base, and start using it to help others, track to my build releases and keep your images fresh. But otherwise, you could end up in the "I used a bunch of Google search/AI results full of commands I don't understand to build something complicated that I don't understand, and it has been working since _______ but doesn't work today; WAF is low" mode, and your only paths forward would be (a) more Google/AI spelunking, or (b) fall back to one of the supported configurations.

[tamorgen]

@toggledbits, thanks for the very detailed reply. One of the things I was struggling with understanding was the reference to the user directory in the example docker compose file.

In reality, docker and podman aren’t that different. Podman can use docker images without issue. I’m doing so currently with a Plex image. In fact, I didn’t even have to destroy and recreate the container. All I had to do was take the variables out of the docker container and put it into Podman. Podman will even often run with docker compose files.

And you are right about user privileges. Podman doesn’t need to run things as root. They see it as an advantage.

Another advantage is that you can run multiple containers in the same network space. For instance, I can run Pi-hole and Unbound in the same private IP space, so they can interact with each other, but nothing that I don’t want to.

Back to the subject at hand, I need to copy my extras, config, and storage directories into my user directory, and they’ll stay safe, and I should be able to have my reactor service up and running on the new server, is what I’m hearing. I’ll let you know how it goes.

[tamorgen]

@toggledbits,
Well, I took a first step. I tried using the docker-compose.yaml file with podman-compose, but it gave me some issues. I fell back on just using docker-compose, and it worked with only a minor hickup. It told me the version tag was depricated and to remove it to prevent problems in the future, so I did so, and it's running without issue. Rules and reactions are working as before, which is fantastic. Reactor on my old server is stopped/disabled, so one more item crossed off. I'm hoping to have the old server fully decommissioned this weekend.

At some point, I'll go back and try and get it running with Podman, if it's possible. I can engage their community and see if they have any advice, but right now it's more important for me to turn off my office heater going into summer.

The other major advantage is that in theory, I won't have to manually update nodejs each release, which has been kind of a pain lately.