Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rootless systemd service #56

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

YurNaybor
Copy link

I needed some small fixes to make rootless containers working with systemd. Hopefully this is of use for others, too.

@ikke-t
Copy link
Owner

ikke-t commented Mar 27, 2022

Hmmm, didn't the auto update work for you without those links? Odd, for me the containers do update. I wonder if I did something manually then.

What comes to root owning the system files, this was discussed yearlier already. I purposely had root owning them as an extra security step.

@ikke-t
Copy link
Owner

ikke-t commented Mar 27, 2022

This should do it:

- name: ensure auto update is running for images

So I wonder is there bug somewhere that breaks it?

@YurNaybor
Copy link
Author

YurNaybor commented Mar 28, 2022

Well I actually had two errors during the role execution:

  1. "operation not permitted" at "create systemd service file for container", with "container_run_as_user = containers". This is logical, because it would effectively try to chown the files to root as non-root. If root ownership for the systemd units in rootless mode is really desired (which I highly doubt), one would have to add a second task for setting the permissions, without "become_user=..."

  2. The activation of the auto update / timer service failed (at "ensure auto update is running for images"), because of "service not found". Here I am not completely sure how systemd's user scope works, but simply providing links to the services in the users' systemd folders solved the problem. I'm not actually interested in having the auto update running, but the role execution should be at least successful.

@ikke-t
Copy link
Owner

ikke-t commented Sep 14, 2022

hi, sorry for such late reply, but it seems this now conflicts with the existing tree. Could you please rebase and check? There is the PR conflicting which made the service file ownership to be set separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants