Good Morning from my Robotics Lab! This is Shadow_8472 and today I am reasonably sure my Podman containers won\u2019t be randomly going down anymore. Let\u2019s get started!<\/p>\n\n\n\n
I enjoy using Podman as a stand-in for Docker, but its rootless approach to running containers inherently challenges sysadmins facing Docker\u2019s help and tutorial legacy. The most problematic difference I\u2019ve experienced has been keeping containers running long-term. Months ago, I learned how to enable account lingering. This allows Podman containers without something remaining logged in as their respective users. I\u2019ve been living with manually restarting containers as needed. Well, since I decided to enable automatic security updates, starting containers automatically would be prudent before expecting other family members to rely on them.<\/p>\n\n\n\n
Against all odds, my initial search this past Wednesday yielded a blog article from Red Hat about integrating Podman containers into Systemd [1] to start them at boot. It was posted the day before.<\/p>\n\n\n\n
I trust Red Hat to not post malicious commands, but it\u2019s still a good idea to learn about strange commands before running them. Red Hat\u2019s tutorial starts with making a new user, enabling linger, and running a containerized web server. The first important command I ran was<\/p>\n\n\n\n
$ podman stop httpd && podman rm -a && podman volume prune<\/pre>\n\n\n\nThis command appears to thoroughly clean out Podman. I\u2019ve mounted volumes from the host before to persist data, but there\u2019s a more flexible volume structure I only learned about just now when researching for another section I had to spin off into a near-future post. I haven\u2019t used them yet, but I\u2019m sure they\u2019ll be useful once I learn how to use them.<\/p>\n\n\n\n
$ podman generate systemd --new --files --name httpd<\/pre>\n\n\n\nThis command makes a new systemd file. The –new option recreates the container fresh each time it\u2019s brought online. –files sends the configuration to a file instead of the terminal. –name must be the name of a running container or pod.<\/p>\n\n\n\n
$ cp -Z container-httpd.service ~\/.config\/systemd\/user\/<\/pre>\n\n\n\nThe file generated previously goes in a directory where systemd will find it when used with the –user flag. The -Z flag matches permissions with the destination directory. The tutorial finishes with a daemon-reload followed by starting and enabling the user\u2019s service.<\/p>\n\n\n\n
Takeaway<\/h2>\n\n\n\n
This is a resource for my bookmarks. That is all.<\/p>\n\n\n\n
Final Question<\/h2>\n\n\n\n
I took the opportunity during this project to put a Minetest server on ButtonMash, but I\u2019m having difficulty obtaining permissions. I can see its logs in Cockpit-Podman, but I don\u2019t have access to the server command line. How am I supposed to get started with adminning Minetest?<\/p>\n\n\n\n
I look forward hearing your answers in the comments below or on my Socials<\/a>.<\/p>\n\n\n\n
Work Cited<\/h2>\n\n\n\n
[1] A. Oliveira, \u201cConfigure a container to start automatically as a systemd service,\u201dredhat.com<\/em>,Feb. 21, 2023. [Online]. Available: https:\/\/www.redhat.com\/sysadmin\/container-systemd-persist-reboot<\/a> [Accessed Feb. 27, 2023].<\/p>\n","protected":false},"excerpt":{"rendered":"
Good Morning from my Robotics Lab! This is Shadow_8472 and today I am reasonably sure my Podman containers won\u2019t be randomly going down anymore. Let\u2019s get started! I enjoy using Podman as a stand-in for Docker, but its rootless approach to running containers inherently challenges sysadmins facing Docker\u2019s help and tutorial legacy. The most problematic … <\/p>\n