|
| 1 | +Everything described in [the docker instructions](docker) is relevant, but this page is dedicated to podman quirks. |
| 2 | +# Podman |
| 3 | +Your first instinct when using Podman should be to run containers as rootless. |
| 4 | +A typical container designed to work with rootless podman would run as root or a user inside the container, and inherit any non-root permissions of the host user running the pod. In the BEST-case scenario, the user inside the container would also be rootless, with means the host user is rootless and the container is rootless. |
| 5 | +**Unfortunately this is not how ARM works, since it has been designed with Docker in mind, which runs as insecure root by default**, but efforts have been made to not run the scripts as root inside the container. |
| 6 | +### podman root mode |
| 7 | +This is how you should think of ARM from a security standpoint with podman. The classic Podman matrix where the bottom-right side is the most secure, and the upper left side is the least. **This doesn't really matter if youre just running this locally without network access**, but it gives you an idea of the expectations of permissions needed in the container image. |
| 8 | + |
| 9 | +| | Rootful Host (insecure) | Rootless Host (more secure)| |
| 10 | +| ------------------------------- | ----------------------------- | -------------------------- | |
| 11 | +| Root in Container (insecure) | ARM during container setup | ✖️ | |
| 12 | +| Rootless Container (more secure)| ARM when running as `arm` user | ✖️ | |
| 13 | + |
| 14 | +- ARM expects the host to have a user called `arm` on the host machine (the name does not matter! as long as you pass in the correct PID and GID, which is typically 1000 for the first user on the system) |
| 15 | +- It expects the the mounted volumes like `media`, `logs`, `music`, `config` to be owned by this `arm` user. |
| 16 | +- It expects the Container to be run as root (which ensures that the mapping of all GIDs and PIDs on the host machine map 1:1 with the container) |
| 17 | +- It expects the `arm` user on the host to belong to the groups `cdrom,video` and `arm`. |
| 18 | +- It expects there to be a corresponding directory for each ´/dev/sr*´ in the ´/mnt/dev/sr*´ on the host, owned by the `arm` user |
| 19 | + |
| 20 | +**These requirements are basically what the `setup-docker.sh` script does (except creating directories for volumes you need)** |
| 21 | + |
| 22 | +### Minimum podman |
| 23 | +``` |
| 24 | +# This assumes your cdrom is sr0 |
| 25 | +sudo podman run \ |
| 26 | + -p "8080:8080" \ |
| 27 | + -e ARM_UID="1000" \ |
| 28 | + -e ARM_GID="1000" \ |
| 29 | + -v /home/arm/content:/home/arm:Z \ |
| 30 | + -v /home/arm/.config:/etc/arm/config:Z \ |
| 31 | + --device /dev/sr0 \ |
| 32 | + --restart always \ |
| 33 | + --name arm \ |
| 34 | + --cpuset-cpus='5,6' \ |
| 35 | + docker.io/automaticrippingmachine/automatic-ripping-machine:latest |
| 36 | +
|
| 37 | +
|
| 38 | +``` |
| 39 | + |
| 40 | +This assumes a file structure like so: |
| 41 | +``` |
| 42 | +- /home/ |
| 43 | + - arm/ |
| 44 | + - .config/ |
| 45 | + - content/ |
| 46 | + - music/ |
| 47 | + - media/ |
| 48 | + - logs/ |
| 49 | +``` |
| 50 | +This aligns with podman's tendency to prefer to keep config inside the calling user's directories, rather than polluting and chaning ownership in the hosts `/etc` directory. |
| 51 | + |
| 52 | +[Other ARM documentation](docker) recommends that you need to run the `lsscsi -g` and grab the corresponding sg* device for your sr* device and pass that in as well, but I have had no trouble running with only ´sr0´ device passed in. Your mileage may vary. |
| 53 | + |
| 54 | + |
| 55 | +### Gotchas |
| 56 | +#### cdrom permissions |
| 57 | +If you're using Podman, chances are you're also using Fedora. |
| 58 | +- Fedora maps the GID of `cdrom` to 11, while the container image (based on ubuntu) maps it to 24. This discrepancy should be taken care of in [newer images of ARM](https://github.com/automatic-ripping-machine/arm-dependencies/pull/512), but if you have permission issues, you can go into the the running image like so: |
| 59 | + |
| 60 | +``` |
| 61 | +podman exec -it arm bash |
| 62 | +``` |
| 63 | +then run |
| 64 | +``` |
| 65 | +ls -al /dev/sr0 |
| 66 | +``` |
| 67 | +This assumes your cdrom is `sr0` and your running container is named `arm` |
| 68 | + |
| 69 | +If the group ownership has an 11 in it like so: |
| 70 | +`brw-rw----. 1 root 11 11, 0 Feb 7 13:12 /dev/sr0` |
| 71 | +it means the group was not mapped correctly. |
| 72 | +Your best bet is to use the most recent ARM image, or create a new group on the host mapped to GID 24 and change the ownership of /dev/sr0 to this new user group. |
| 73 | +#### log permissions |
| 74 | +For some reason the log files like `empty.log` and `arm.log` have sometimes been created with the root user rather than the `arm` user. If this happens you can fix this on the host machine by `chown arm:arm empty.log` and it should stop giving you errors. |
0 commit comments