and you will see the access key and secret key in the log output.
For root, you just need to do that as root.
The needed file is ~/.local/share/storj/gateway/config.yaml (for root it will be /root/.local/share/storj/gateway/config.yaml), which contain
# the serialized access, or name of the access to use
access: 1cCYertoijhgoiogtjgfhtrhmrohjbokgfmnvbortmbrtkhjriotobmjiotyhbt....
If you do not plan to change the access grant too often, you may just setup it once and hardcode resulted S3 creds in your app.
You may reuse it of course, just run a setup as root (or copy your config to the root home folder, or provide a path to the config file in the gateway run command with --config-dir option).
Just gateway run uses parameters from config.yaml and seems ignore your --access option…
Got it ! Created a new access grant from satellite dashboard and ran gateway setup as root user (sudo). Now I can see the config file in both location.
It collect the usage statistics (not personalized), you may disable it with option tracing.enabled: false in your config.yaml (root one, if you run it as root), or with an argument --tracing.enabled=false in your gateway run command.
no. More like a warning - usually you should not run anything as root, it’s not safe.
It’s better to use a special limited user for that, especially when the service is not require any root access (like in this case).
This is not possible, if you did it correctly and this user has an access to this file, remember - it’s looking for ~/.local/share/storj/gateway/config.yaml
So, if the user is USER, the path would be /home/USER/.local/share/storj/gateway/config.yaml
However, if you use sudo, it will looking for config for the root, i.e. /root/.local/share/storj/gateway/config.yaml