Open arkanoid87 opened 7 months ago
How about drop in files, they can be configured by profile: https://creativeprojects.github.io/resticprofile/schedules/systemd/index.html#systemd-drop-in-files
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.
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?
do you know if enable linger would make resticprofile systemd user schedule behave just like the root one does?
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?
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!
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.
root:root
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)