rustic profiles and password file paths in systemd units

[NobbZ]

Hi, currently I am using a systemd timer for my hourly backups using rustic and used to manually do a copy using restic to a cloud backup about once a day.

Though I now want to migrate to rustic copy and a systemd-timer.

The problem I currently have with this is, for systemd I generally use systemd credentials.

So the path to the passwordfile is not known in advance.

I can use %d in the unit file or the environment variable CREDENTIALS_DIRECTORY to get the base path to the creds, and each cred is a "file" in that folder.

So I am searching for a flag or environment variable that I can use to specify the targets password. From my first experiments it seems as if I can use RUSTIC_PASSWORD_FILE as usualy for the source repository.

Also using password-file = "${HOME}/.rustic_password" (for the testing) did result in an error that no file was found, therefore I assume that environment variables are not expanded in the configuration.

Also how would I specify a different location for the "profiles"? It seems that by default ~/.config/rustic is checked, though as copy will be ran by systemd with dynamic user and ephemeral home and restricted disk access, I would actually prefer if I could tell it to search for profiles in /etc/rustic or %d/CREDENTIALS_DIRECTORY. Hoping that there will be a way to also somehow tell rustic to read the targets password file from there…

[aawsome]

Yes, for the target repositories, there are no command line flags nor env variables. For the password, you could use something like password-command="echo ${HOME}/.rustic_password" in the config file.

About systemd: I think you can set $XDG_CONFIG_HOME to /etc and rustic will use config files under /etc/rustic...

[NobbZ]

Sadly using cat ${HOME}/.rustic_password as the password-command does result in "Error: unexpected end of file", if though I explicitely write out this as /home/nmelzer/.rustic_password everything works. So it seems as if the env-var is not properly expanded but used literally.

Even password-command = "bash -c 'cat $HOME/.config/rustic/password'" and similar constructs fail with the same error.

[NobbZ]

I just checked the "tokenization" of the command.

https://github.com/rustic-rs/rustic/blob/main/src/repository/mod.rs#L119-L121

Perhaps you should instead do something like this:

                let output = Command::new("bash")
                    .args(&["-c", command])
                    .output()?;

[NobbZ]

Of course I have no clue what would be an adequate equivalent for windows…

Though I wouldn't be surprised if there is already a crate that can run commands with ENV-expansion.

[aawsome]

Ok, seems you are right. Sorry, I expected it to work differentely, but I must admit I never thought too much about env var expansion. The environment variables are expanded, though. If you create a script like

#!/bin/sh
echo $X

under a static path and give that script (using the full path) to the password-command option, it will use the env variable $X as password. Maybe you can use this to build a solution for you.

I'll also think about what rustic can handle better here...

[NobbZ]

Yeah, that could work, even though that increases the touching points with the real filesystem for the service.

Shall I open an issue for the command not "tokenizing" properly and/or the variable expansion?

[aawsome]

I thought a bit about the problem:

• I think that the interpretation of e.g. $X into "use the content of the env variable X is a duty that shouldn't be done by rustic. There are shells and there is syntax specific to some shells which fulfill this job and do so well
• Forwarding env variables is the job of rustic, but it seems this is working as one would assume it should be.
• When rustic calls a program, I would not enforce this to run through a shell. The reason is, a user could write or use its own program which handles variables or other thing in its own way - adding a shell introduces complexity in the best case and may yield unwanted and irritating effects in the worst case. Moreover, if it is a shell the use wants to produce the password he/she can easily order the shell to do this.

The only thing which I'm irritated about is why your bash -c ... example didn't work - I would like to investigate this a bit deeper and find out, what's going on there..

[aawsome]

Ah, ok I found the problem - you were right about a "tokenizing" problem:
If you specify password-command = "bash -c 'echo $X'", it will cut this into parts, but the parts look ["bash", "-c", "'echo", "$X'"] - which of course is wrong.
Instead rustic should have split this into `["bash", "-c", "echo $X"] - and the this produces the wanted result.
So I'll try to find a way how this split can be implemented.

[aawsome]

I just had a look at restic - and there is a hand-made parsing of the command line given e.g. for the password-command, see https://github.com/restic/restic/blob/master/internal/backend/shell_split.go.

In Rust we thankfully have parser-combinators at hand.. I think #383 should solve the problem. It also adds debug output of the "password command tokens" if you use --log-level=debug.

[aawsome]

Now that #383 is merged, setting password-command to "bash -c 'cat $HOME/.config/rustic/password'" should work.