Improve validators guide

[leonardocustodio]

Hello,

I made a minor tweak to improve the validator's guide.

1. Changed the order of generating the node key. The reason for that is that if the user starts to sync with the validator flag without the key, the node will not even begin, so I believe it is better if we tell the user to generate it before, even though we don't say to pass the validator flag on the next step, a lot of people could pass anyway.

2. When using localhost to rotate the keys, it will give an error about not being whitelisted; this makes some validators start the node with the unsafe flag, as some people have proposed in the community. But if you use 127.0.0.1, it will work as it is already whitelisted, preventing people from using the unsafe flag.

[ajk-code]

Hey @leonardocustodio

1. The node key is created on first initialization (without --validator flag) in the default directory ~/.local/share/polkadot/chains/polkadot/network/secret_ed25519. Telling admins to manually pre-generate those keys and add additional flags in /etc/default/polkadot (--node-key-path) just makes things more complicated IMHO and is usually not required unless somehow automated setups are used for deployment. And in this case it makes more sense having it a the bottom of the page since few are gonna automate their validator installation I guess since automation can be very dangerous and hence a more advanced topic. What do you think?
2. localhost maps to 127.0.1.1 in my hosts file (stock debian) and rotation works just fine with localhost as documented, no unsafe flags used. According to the help page it defaults to auto which allows all RPC methods on localhost only, do you use a non 127.0.0.0/8 IP as localhost IP in your hosts file or something?

[leonardocustodio]

Hello @ajk-code ,

Thanks for your feedback.

1. You are right, I suppose I always started with the validator flag and thus I would get the error.

2. I use stock Ubuntu Server 24.04. This used to work on the previous version but stopped working from 1.15.x forward, have you tried in a recent version?

ubuntu@ip-172-31-40-65:~$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

This is the default Ubuntu hosts, still, the error happens anyway:

ubuntu@ip-172-31-40-65:~$ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9944
Provided Host header is not whitelisted.

ubuntu@ip-172-31-40-65:~$ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://127.0.0.1:9944
{"jsonrpc":"2.0","id":1,"result":"0x0000"}

This is from Kusama Thousand Validators element channel, it seems lots of people get the same error with localhost and I believe everyone is using stock distro

[ajk-code]

@leonardocustodio Did you try disabling IPv6? Just to test, to rule out any IPv6 shenanigans :)

[leonardocustodio]

Disabling IPv6 with:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

Indeed makes it work.

ip -a (before)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:54:d4:7a:63:1d brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    inet 172.31.40.65/20 metric 100 brd 172.31.47.255 scope global dynamic ens5
       valid_lft 3261sec preferred_lft 3261sec
    inet6 fe80::854:d4ff:fe7a:631d/64 scope link 
       valid_lft forever preferred_lft forever

ip -a (after)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:54:d4:7a:63:1d brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    inet 172.31.40.65/20 metric 100 brd 172.31.47.255 scope global dynamic ens5
       valid_lft 3067sec preferred_lft 3067sec

Though again, this is a fresh install with default options and no IPv6 internet access, I suppose Ubuntu just enables the interface by default. What do you think would be better? Should we put a warning about IPv6 or just replace localhost with 127.0.0.1? My only concern is that people without knowing that will start the node with unsafe flags and might leave it running that way without knowing the proper solution, like the people on the element channel

[ajk-code]

Yeah maybe a warning/disclaimer would be helpful, maybe you could check if the listener starts on IPv6 loopback (::1) as well and create a PR if it is not ? Regardless of that, I think that sort of issues is something a validator operator should be able to handle by him-/herself, there are so many factors and possibilities here (nss, netfilter, policies etc . on different OSI layers) we cannot nor should we cover all possible OS/sysadmin scenarios on the validator setup page imho. What do you think?