The `xactfetch` script now uses a helper tool, `secretsocket` to
handle looking up secrets. This tool supports various secret source
types, including files, environment variables, and external commands.
Separating this functionality out of the main script makes it a lot
more flexible and pluggable. It's main purpose, though, was actually
to allow `xactfetch` to run in a container while communicating with
`rbw` outside that container, specifically for development puposes.
The `secretsocket` tool reads its configuration from a TOML document.
This document defines the secrets the tool handles, and how to look
them up.
Note that the `xactfetch` container image no longer defines the
`XDG_CONFIG_HOME` environment variable, as it uses Chromium instead of
Firefox now, and the former does not work with a read-only config
directory. As such, we have to mount the `rbw` configuration in the
default location.
Usually, `xactfetch` will only fail for one bank or the other. Rarely
do we want to redownload the data from both banks just because one
failed. The latest version of `xactfetch` supports specifying a bank
name as a CLI argument, so now we can define separate jobs for each
bank. Then, when one Job fails, only that one will be retried later.
It's kind of a bummer that it's so repetitive to define two CronJobs
that differ by only a single command-line argument. I suppose that's
a good argument for using one of the preprocessor tools like Jsonnet
or KCL.
When the `xactfetch` CronJob is triggered manually, it will now skip
the `sleep` step. Presumably, whoever triggered it wants the script
to run _right now_, probably to diagnose a problem.
Vaultwarden has started prompting for the master password occasionally
when syncing the vault. Thus, we need to make sure it is available in
the _sync_ container, by mounting the secret and providing the
`PINENTRY_PASSWORD_FILE` environment variable.
Dustin