creativeprojects
init doesn't accept `--host`
I'm not sure if this is a real problem or just a inconvinience in the configuration (v1).
I tried to set hostname at the most top profile default because of docker's random hostnames official docs.
But when I initialized the repo with --name default init (or whatever other profile where the repo path is set, but also the host parameter), the repo doesn't get created and an error is printed out:
unknown flag: --host
If this is intended, you might close it. If there is something I can do instead of my current approach*, you might tell me.
*currently I workaround this with a separate profile containing all flags except the host flag.
Hi,
If you look at the restic inline help, the host flag is not a global flag nor it is a specific flag on the init command:
% restic init --help
The "init" command initializes a new repository.
EXIT STATUS
===========
Exit status is 0 if the command was successful, and non-zero if there was any error.
Usage:
restic init [flags]
Flags:
--copy-chunker-params copy chunker parameters from the secondary repository (useful with the copy command)
-h, --help help for init
--key-hint2 string key ID of key to try decrypting the secondary repository first (default: $RESTIC_KEY_HINT2)
--password-command2 command shell command to obtain the secondary repository password from (default: $RESTIC_PASSWORD_COMMAND2)
--password-file2 file file to read the secondary repository password from (default: $RESTIC_PASSWORD_FILE2)
--repo2 repository secondary repository to copy chunker parameters from (default: $RESTIC_REPOSITORY2)
--repository-file2 file file from which to read the secondary repository location to copy chunker parameters from (default: $RESTIC_REPOSITORY_FILE2)
Global Flags:
--cacert file file to load root certificates from (default: use system certificates)
--cache-dir directory set the cache directory. (default: use system default cache directory)
--cleanup-cache auto remove old cache directories
--insecure-tls skip TLS certificate verification when connecting to the repo (insecure)
--json set output mode to JSON for commands that support it
--key-hint key key ID of key to try decrypting first (default: $RESTIC_KEY_HINT)
--limit-download int limits downloads to a maximum rate in KiB/s. (default: unlimited)
--limit-upload int limits uploads to a maximum rate in KiB/s. (default: unlimited)
--no-cache do not use a local cache
--no-lock do not lock the repository, this allows some operations on read-only repositories
-o, --option key=value set extended option (key=value, can be specified multiple times)
--password-command command shell command to obtain the repository password from (default: $RESTIC_PASSWORD_COMMAND)
-p, --password-file file file to read the repository password from (default: $RESTIC_PASSWORD_FILE)
-q, --quiet do not output comprehensive progress report
-r, --repo repository repository to backup to or restore from (default: $RESTIC_REPOSITORY)
--repository-file file file to read the repository location from (default: $RESTIC_REPOSITORY_FILE)
--tls-client-cert file path to a file containing PEM encoded TLS client certificate and private key
-v, --verbose n be verbose (specify multiple times or a level using --verbose=n, max level/times is 3)
For that matter I think it is a mistake in the resticprofile documentation. Thanks for pointing it out 😄
In your case I think it's better that you set the container name via docker:
On the docker run command line you can use the flags -h or --hostname to set the hostname of the container.
I will change the documentation to refect this 😛 Thanks 👍🏻
Thank you for your quick answer and the updated docs.
I think running the container with a specified hostname is a good idea but also has some downsides:
-
~~Can hostname be the same as the docker host?~~ ~~(because I backup host files, I'd like having the hostname set to the docker host's hostname)~~ Actually I think this should be possible, see this Stackoverflow answer.
-
Would it still be scalable with docker compose? (not a problem for me now)
-
less variable by just changing config file, also same hostname for all profiles (not a problem for me)
- Would it still be scalable with docker compose? (not a problem for me now)
It looks like it is supported in docker compose (I haven't tested it) https://docs.docker.com/compose/compose-file/compose-file-v3/#domainname-hostname-ipc-mac_address-privileged-read_only-shm_size-stdin_open-tty-user-working_dir
- less variable by just changing config file, also same hostname for all profiles (not a problem for me)
That's true. The issue is not in resticprofile but it's because restic does not allow the use of a host flag on the init command. For that we need to do a Pull Request on the restic code (which I beleive should be rather simple)
- Would it still be scalable with docker compose?
It looks like it is supported in docker compose (I haven't tested it) link
I probably described it not good enough, I meant you cannot scale=2 (or more) because you would have duplicate hostnames/dns names. But I also couldn't find any evidence or problems about it in the web.
The issue is not in resticprofile but it's because restic does not allow the use of a
hostflag on theinitcommand. For that we need to do a Pull Request on the restic code (which I beleive should be rather simple)
As for the restic PR, I think seeing it from restic, it doesn't make sense to accept a flag that does nothing(?) when initializing?
I probably described it not good enough, I meant you cannot scale=2 (or more) because you would have duplicate hostnames/dns names. But I also couldn't find any evidence or problems about it in the web.
In docker the instance hostname and instance name are two different things. So you can still have two instances server1 and server2 using the same hostname myserver. So I think we're good (again, not tested 😛 )
As for a host parameter in restic, the init command does use the name of the host who generated the repository key. You can see the list of keys with the restic key list command.
I think that might be the only place it's using the host, so not very useful indeed 😦