Greetings! I wanted to announce that the container image for the next nightly (which will eventually end up in the 8.1.26 release) contains changes to the default user/group that is used to launch Ignition.
The default user is now ignition with UID/GID of 2003. You'll have to perform a migration in order to successfully transition your existing data volumes, otherwise you may encounter an error such as this one below:
The above is one such manifestation of the new ignition user being unable to modify files that are owned by root within an attached data volume. You can choose between at least a couple options:
Explicitly set the user for the container to be 0:0 (i.e. root user:group), overriding the new default. You can do this with either --user 0:0 in your docker run or the user directive in Compose. Note that you're not getting any of the advantages here of non-root execution.
Migrate your data volume by temporarily launching a container with --user 0:0 and environment variables IGNITION_UID=2003 and IGNITION_GID=2003. This will leverage the existing root step-down functionality and remap your data volume file ownership to the target UID/GID that matches the new default user. After startup, you can stop the container and re-launch without any explicit user or UID/GID environment variable overrides in the future.
We're working on updating the docs site with more detailed guidance on the migration that should be available for the final release.
If you also need these capabilities (for sub-1024 port binding as non-root user and raw socket use for ICMP, respectively), yes, you'd specify those in your container config.
My point was that those should be the default--your image should include that in an override. IMNSHO. { Well, arguably, Ignition's default SystemD unit file should have it. }
I should clarify that the Docker image launches that gateway directly, no systemd involved (as is typical in most container images). The capabilities that a container gets when launched is controlled by the container runtime--see some info here. There isn't a way to "request" default capabilities within the OCI image definition that I'm aware of.
Tiny addendum: We just upgraded over this bump today and it broke us since we build a derivative image with git tools and our old Dockerfile was expecting root. After double-checking that things run as ignition normally, just adjusted our Dockerfile to look like this:
FROM inductiveautomation/ignition:8.1.26
USER root
RUN apt-get update && \
apt-get install -y git && \
rm -rf /var/lib/apt/lists/*
USER ignition
If I was more thoroughly adept with Docker I would've expected this, but I'm not and I didn't. Thankfully someone else on our team knows more Docker and set me straight quickly.
@justin.brzozoski, agreed that for derived images going forward, you'll need to temporarily set USER root to do things like OS package updates and then set USER ignition at the end. Just be careful if you do anything that creates files within the Ignition installation, you'll want to make sure that those files remain chown'd to ignition:ignition.
Not out of the woods yet ... we have our developer stations set up such that data/projects is mounted to a working directory on the host system and I just ran into this:
> git fetch
fatal: detected dubious ownership in repository at '/home/justin/work/ignition_projects'
To add an exception for this directory, call:
git config --global --add safe.directory /home/justin/work/ignition_projects
Probably simplest to run the image on my devstation as root and pass in my UID/GID ...
Also agreed. If you use the IGNITION_UID and IGNITION_GID environment variables combined with starting the gateway as root, it should work fine (and Ignition itself will still end up running as that desired IGNITION_UID through the root stepdown). Only other path would be to reset file ownership of the Ignition installation within your derived image to your target UID/GID; only trouble there is if you've got other users whose workstations have different UID/GIDs (likely). That is why we've retained that root stepdown functionality--for dev.
I was upgrading from version 8.1.1 to 8.1.39, and I ran into this issue. Adding "user: 0:0", "IGNITION_UID: 2003" and "IGNITION_GID: 2003" to my docker compose file fixed the Permission denied error, but when I removed those lines from the config the error presented itself again. It worked again when I re-added those to the config, but it was not the expected result. I feel like I still may be missing something to complete the upgrade. Any thoughts on this?
What do you have in the container logs when you try to launch after removing the run-as-root and the IGNITION_UID/IGNITION_GID environment variables? It might help to see the exact error[s].
When you launch as root (i.e. uid:gid 0:0), and you've specified the IGNITION_UID and IGNITION_GID vars, you should see something to the effect of:
init | 2024/05/29 13:48:47 | Adjusting ownership of 487 Ignition installation files to uid=2003,gid=2003.
... indicating that the entrypoint (as root) has updated the permissions of those files to match the target user/group.
EDIT: I did a quick sanity check w/ launching our old 8.1.1 image and upgrading [to 8.1.41] as described above and everything worked as expected.
Here are the logs when it is run with IGNITION_UID=2003 and IGNITION_GID=2003 and user: 0:0. This is not from the time that the image was upgraded, and I may not have access to the logs from when it was upgraded until I can upgrade another instance in a couple of weeks.
I'd double check whether you've successfully applied those environment variables. One way to check would be to inspect the currently running container, e.g. ( make sure you don't post this output if you've got sensitive values in the environment):
If those environment variables are applied and you've launched the container as root, then you should see something like this at the beginning of the logs:
...
init | 2024/06/03 19:46:37 | Adjusting ownership of 487 Ignition installation files to uid=2003,gid=2003.
init | 2024/06/03 19:46:37 | Staging user step-down from root to uid=2003,gid=2003
...
Are there any other particulars of this environment that you can share? Is this just running on a typical flavor of Linux with Docker Engine?
make sure you don't post this output if you've got sensitive values in the environment):