Questions and sugestions about config.yaml

I’m running storagenodes on NAS (linux) in Docker.

  1. After starting a few nodes in different months, I see that the parameters in config.yaml had changed over time with newer releases. Some new appeared, some disappeared, some changed the default values. But the config file dosen’t change with stortagenode update. I imagine that storagenode uses the default values for new parameters, even if they are not present in config file. But what if someone needs/wants to change something, and has and older version that is not displaying that parameters/values? I think it’s best that storagenode update should bring to date the config file as well, keeping the user modifications. I personaly stopped all nodes and replaced the old config files with the one from the newest node, just to have everything in line, but this manual intervention could be avoided.
  2. What this parameters mean? When and why they should be modified?
#Enable additional details about the satellite connections via the HTTP healthcheck.
healthcheck.details: false

# Provide health endpoint (including suspension/audit failures) on main public port, but HTTP protocol.
healthcheck.enabled: true

# private address to listen on
server.private-address: 127.0.0.1:7778
  1. How to modify the list of trusted satellites if I only want to whitelist a few? How can I specify the ones I want? I see only this line:
# list of trust sources
# storage2.trust.sources: https://www.storj.io/dcs-satellites

and this one is “unused”:

# a comma-separated list of approved satellite node urls (unused)
# storage.whitelisted-satellites: ""
  1. This port should be configurable in docker run command as well. Or if it can, how is the correct imput and where to put it? Whould be easy for multinodes or special configs to see it in forums and explanations, instead of the reference to config file. I myself discovered it after 2 years, because I did’t understood the pointers others gaved me about the port in config.yaml.
# public address to listen on
server.address: :28967

My run command is:

docker run -d --restart unless-stopped --stop-timeout 300 \
	-p 28967:28967/tcp \
	-p 28967:28967/udp \
	-p 14002:14002 \
	-e WALLET="xxx" \
	-e EMAIL="xxx" \
	-e ADDRESS="wan_ip:28967" \
	-e STORAGE="7TB" \
	--mount type=bind,source="/volume1/Storj/Identity/storagenode/",destination=/app/identity \
	--mount type=bind,source="/volume1/Storj/",destination=/app/config \
	--name storagenode storjlabs/storagenode:latest \
	--log.level=error
1 Like

These two configures how your node would respond to http requests on its port (if you disable healthcheck, it will not respond on http requests, only on DRPC as before).

This is an address and port where storeagenode will listen for requests from CLI. If you have several binary nodes or uses --network host in your docker run command, you need to change it to unique port and use this port when you run some commands like storagenode dashboard or storagenode graceful-exit. For docker version without --network host you usually wouldn’t change this parameter.

There are several ways.

  1. You may prepare an own list of trusted satellites and provide this file in the storage2.trust.sources parameter (like option in the config.yaml or as argument in your docker run command after the image name).
  2. You may list them in the parameter storage.whitelisted-satellites (as an option or as an argument).
  3. You may list only blacklisted satellites in the parameter storage2.trust.exclusions

As usual - either in the config.yaml or as an argument in your docker run command after the image name, i.e.

...
storjlabs/storagenode:latest \
--server.address=:28999

However, you do not need to change it unless you used --network host parameter before the image name in your docker run command. This is a listening port inside the container, you usually provide a mapping for it with -p 28967:28999 option (here is an example if you changed the server.address parameter to listen on :28999).

All parameters you can get with storagenode setup --help and runtime parameters with storagenode run --help, i.e.

docker exec storagenode ./storagenode setup --help

And

docker exec storagenode ./storagenode run --help

As I showed above - you always may run storagenode setup --help to see available parameters and their default values.

You may add them to the config.yaml file or to your docker run command after the image name.

We changes the config.yaml file, if something is deprecated or not supported, but it is a rare case. Usually changes are not needed, especially if the value is not changed from the default.

1 Like

The argument in docker run command should be:

--server.address=:28967

or

--server.address=":28967"

?
Like for debug address:

--debug.addr=":5999"

In my case, I don’t use network host, but for some unexplained reason, the 28967 din’t worked for both nodes in one machine, so I used 28968 all the way, like this:
router portWAN:portNAS > docker portNAS:portDKR

-p 28968:28968/tcp \
-p 28968:28968/udp \
-p 14003:14002 \
-e ADDRESS="wanIP:28968" \

# public address to listen on
server.address: :28968

Maybe I changed this port in config, from 28967 to 28968 at setup, and I forgot, and all the tryes using 28967 failed after that… Now that I know about this, I will try again with docker port 28967 for both nodes.

Node1: 
-p 28967:28967/tcp \
-p 28967:28967/udp \
-p 14002:14002 \
-e ADDRESS="wanIP:28967" \
... --server.address=":28967"

Node2:
-p 28968:28967/tcp \
-p 28968:28967/udp \
-p 14003:14002 \
-e ADDRESS="wanIP:28968" \
... --server.address=":28967"

The default port will not work on the same machine for two nodes only in one condition - both nodes in the same internal network. This could be because your default docker network is configured to share address space between containers, so it’s basically the same as having --network host.

1 Like

Yes, both nodes are in Docker on one machine (NAS), and the NAS has only one connection to the router, so both nodes are on the same network. I only have one local network and router.

I meant the network configuration for docker. It uses the default virtual network, but usually it’s not shared between containers, unless you especially configure them to be connected with special options like changing a network with --network option or with deprecated --link option.
So seems your default configuration forces all containers to be connected (they uses the same address and network space), and thus you cannot use the same internal listening port.

I understand now. This means Synology did it again. I just install Docker and than storagenode; I don’t mess with Docker settings. Is there a way to change it to standard?

I found this but I don’t understand anything :sweat_smile:
I remember I saw bridge mode active…

EDIT: The containers run in bridge mode.

If it’s work right now, I believe there is nothing to fix.

After running the --help command, I have some questions about those parameters in config.yaml:

1.--debug.control > expose control panel - how to run it, should I stop the storagenode first, and what is used for? Is there any use for a regular SNO?

2.--filestore.write-buffer-size memory.Size > in-memory buffer for uploads (default 128.0 KiB) - should we tinker with this? Is there any benefit? How to enter the values?

3.--retain.max-time-skew duration and --storage2.retain-time-buffer - they have the same explanation but different default periods, 72h vs. 48h. They reffer to the same thing?

4.--color > use color in user interface - what user interface?
Thanks!

https://forum.storj.io/search?q=filestore.write-buffer-size

for CLI dashboard,

docker exec -it storagenode ./dashboard.sh --color