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

run system scheduler as different user #331

Open
arkanoid87 opened this issue Feb 27, 2024 · 7 comments
Open

run system scheduler as different user #331

arkanoid87 opened this issue Feb 27, 2024 · 7 comments

Comments

@arkanoid87
Copy link

arkanoid87 commented Feb 27, 2024

  • system scheduler allow running even if user is not logged in, but it writes new snapshots as root:root
  • user scheduler preserves permission and writes snapshots as if they were written by the user, but can't be scheduled to run by system when user is not logged in

To get the best of both worlds it is possible to set systemd unit to run as specific user
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#User=

problem can't be solved by providing systemd templates as they are declared in global section of configuration, but we need a per-user (or --profile) change (run-as username)

@jkellerer
Copy link
Collaborator

How about drop in files, they can be configured by profile: https://creativeprojects.github.io/resticprofile/schedules/systemd/index.html#systemd-drop-in-files

@arkanoid87
Copy link
Author

Thanks!
Sorry, I somehow skipped that section of the manual. It seems a perfect solution to the problem!
I just re-scheduled my profiles, I'll close the issue after first round or timers.

@arkanoid87
Copy link
Author

arkanoid87 commented Feb 29, 2024

systemd-drop-in-files seems to work, but drags some issue into the picture, like HOME folder not set properly when "User=" property is set, and this causes restic to complain about permission denied on "/root/.cache/restic"

One fix is to set cache-dir on resticprofile profile.

But the right way to do this probably is to switch back to "user" scheduler but enable linger
https://wiki.archlinux.org/title/systemd/User#Automatic_start-up_of_systemd_user_instances

maybe it is worth speaking about linger in resticprofile system user scheduler?

@arkanoid87
Copy link
Author

do you know if enable linger would make resticprofile systemd user schedule behave just like the root one does?

@creativeprojects
Copy link
Owner

do you know if enable linger would make resticprofile systemd user schedule behave just like the root one does?

No I don't know, I don't use user scheduling on any of my linux machines.

But I can certainly mention it in the documentation. It's not something resticprofile should setup automatically though.

Have you tried it yourself?

@gamelaster
Copy link

I had same issue, and drop in config with specifying User, Group and replacing Environment works perfectly now.
I am quite surprised that this is not part of resticprofile. Are there any reasons why is not implemented? Thanks!

@jkellerer
Copy link
Collaborator

User based schedules are implemented by using resticprofile schedule from a the desired user account and everything including the profile config is read from the user context. What is not implemented is a user switch so that the root scheduler can be used out of the box. Therefore linger may be needed to run user backups when the user is not logged in.

Changing the user automatically (so that the root scheduler can be used) adds additional complexity as secrets that may just be readable by root must be transferred into a user process.

That said, systemd templates or drop-ins allow to configure it and force you to setup permissions and env so that the user context is working correctly. I do see a benefit of an automatic approach here but it is also not easy to setup and get right for a little savings in config work that could also be documented to get you started.

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

No branches or pull requests

4 participants