My Jellyfin server is setup with Podman under the user account “jellyfin”. The account is also a system account (UID 913).
As of right now, the way start/stop/restart the container is using machinectl shell jellyfin@.
How can I control that container in my Cockpit as myself, so that I won’t have to do that, and how can I do it without needing to use machinectl?
Tried
$ sudo -u jellyfin systemctl [email protected] --user status container-jellyfin
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
You give your user access to the podman control group
What you need to also make sure you have is slirp4netns which are the user controllable net utils
Theres a good guide out there
# Basic Setup and Use of Podman in a Rootless environment.
Prior to allowing users without root privileges to run Podman, the administrator must install or build Podman and complete the following configurations.
## Administrator Actions
### Installing Podman
For installing Podman, see the [installation instructions](https://podman.io/getting-started/installation).
### Building Podman
For building Podman, see the [build instructions](https://podman.io/getting-started/installation#building-from-scratch).
### Install `slirp4netns`
The [slirp4netns](https://github.com/rootless-containers/slirp4netns) package provides user-mode networking for unprivileged network namespaces and must be installed on the machine in order for Podman to run in a rootless environment. The package is available on most Linux distributions via their package distribution software such as `yum`, `dnf`, `apt`, `zypper`, etc. If the package is not available, you can build and install `slirp4netns` from [GitHub](https://github.com/rootless-containers/slirp4netns).
show original
You should read it as well as
# Shortcomings of Rootless Podman
The following list categorizes the known issues and irregularities with running Podman as a non-root user. Although currently functional, there is still a number of work items that are under consideration to be added. These proposed changes are in varying degrees of design and development.
Contributors are more than welcomed to help with this work. If you decide to carve off a piece and work on it, please create an issue in [GitHub](https://github.com/containers/podman/issues), and assign it to yourself. If you find other unexpected behavior with rootless Podman and feel it’s warranted, please feel free to update this document.
* Podman can not create containers that bind to ports < 1024.
* The kernel does not allow processes without CAP_NET_BIND_SERVICE to bind to low ports.
* You can modify the `net.ipv4.ip_unprivileged_port_start` sysctl to change the lowest port. For example `sysctl net.ipv4.ip_unprivileged_port_start=443` allows rootless Podman containers to bind to ports >= 443.
* A proxy server, kernel firewall rule, or redirection tool such as [redir](https://github.com/troglobit/redir) may be used to redirect traffic from a privileged port to an unprivileged one (where a podman pod is bound) in a server scenario - where a user has access to the root account (or setuid on the binary would be an acceptable risk), but wants to run the containers as an unprivileged user for enhanced security and for a limited number of pre-known ports.
* “How To” documentation is patchy at best.
* If /etc/subuid and /etc/subgid are not set up for a user, then podman commands
can easily fail
* This can be a big issue on machines using Network Based Password information (FreeIPA, Active Directory, LDAP)
* We are working to get support for NSSWITCH on the /etc/subuid and /etc/subgid files.
* No cgroup V1 Support
* cgroup V1 does not safely support cgroup delegation.
* As of Fedora 31 defaults to cgroup V2, which has full support of rootless cgroup management. Note this requires the --cgroup-manager within rootless containers to use systemd, which new containers will get by default.
* Some system unit configuration options do not work in the rootless container
* systemd fails to apply several options and failures are silently ignored (e.g. CPUShares, MemoryLimit). Should work on cgroup V2.
show original
So you know what your getting into
To go rootless you should understand how that affects the syscalls of podman and what podman is doing. Its supposed to be seemless but isnt
1 Like
You’re missing the point of the question, OP likely already has this configured.
To answer the question I dont think you can without logging into that user in cockpit? Support multiple users · Issue #692 · cockpit-project/cockpit-podman · GitHub
I just have them aliased and/or in scripts to grab output I want and avoid the long stanzas.
The “right” way to handle this is to have the containers shipping logs and health to some other service, unfortunately its not very user friendly to try keeping it all via systemd (tho scripts and aliases help).
Well, that’s a lil annoying
Was hoping for a quick way to start it up from Cockpit, especially since they seem to have stopped supporting Docker in Cockpit.
Have you tried creating a systemd unit? That would allow you to at least stop and restart it.
yea, on user level
I just machinectl into the jellyfin account, then start/stop from there
podman also has a subcommand to generate a systemd unit file and those can use User and Group parameters. Might work as a way to run a system (not user) service-like pod under a certain username.
I also suspect there is a more elegant way to do this but that’s what I know.
Thanks so much! I’ll look into that
