How to test the re6st-node package
Here are some manual tests one can perform when testing a new re6st package. It is assumed the code has already been sufficiently tested with the re6st demo.
Test re6st update
Making sure re6st can update properly without manual assistance is very important, as failure to do so could break a whole re6st network when updating. Install the package on a computer already running a working re6st. Multiple re6stnet configurations can be tested, but one configuration with max-clients > 0 and client-count > 0 should at least be tested. To debug properly, include these lines in your re6stnet.conf:
# increase re6stnet verbosity:
verbose 3
# enable OpenVPN logging:
ovpnlog
# increase OpenVPN verbosity:
O--verb
O3
Test re6stnet service
After installing or upgrading re6st-node, the re6stnet service should be enabled and active by default
systemctl is-enabled re6stnet && systemctl is-active re6stnet
You should also check that the service was restarted properly, you can use checkrestart command from debian-goodies package
Test if processes spawned correctly and interfaces are setup
ps auxf | grep re6stnet
ip link
There should be at least one re6stnet process and babeld process running after update. If max-clients is non-zero, a re6stnet-tcp interface should be setup, and if client-count is non-zero, re6stnetX interfaces should start appearing as tunnels are made. Each interface has a openvpn process with --dev <interface-name> associated to it, and an entry in ip link output.
The loopback interface (or the interface specified with the interface option) should have a re6st global IPv6 assigned.
Check logs for error:
Go to /var/log/re6stnet/ and check re6stnet.log. You can search for "Traceback" to check if python errors occured. Note that not all errors indicate abnormal re6st, for instance:
Traceback (most recent call last):
File "/opt/re6st/eggs/re6stnet-0.568-py2.7.egg/re6st/registry.py", line 742, in rpc
n = len(h) // 2
TypeError: object of type 'NoneType' has no len()
This error means the node didn't get an answer when contacting the registry, which could be due to a temporary network downtime unrelated to the upgrade
Test default route
After a few moments, re6st should choose an interface for the default route
ip -6 route | grep default
If default parameter is set in re6stnet conf:
ping -6 google.com
Else you can try to directly ping the neighbour at the other end of the re6st tunnel and see if you receive a duplicate packet
ping -6 ff02::1%<default-interface>
Test new re6st install
Install re6st-node on a computer with empty /etc/re6stnet folder, and which didn't previously have re6st
Test re6st-conf
re6st-conf --fingerprint ALG:FINGERPRINT --registry URL -d /etc/re6stnet --token TOKEN
Check P-VIFIB-Re6stnet for fingerprint and url information. For instance the command for trial network is:
sudo re6st-conf --fingerprint sha256:499a44702d687e968c047d28e33f59e5c3bae71a38619dc730152a3557c20301 --registry http://re6stnet.gnet.erp5.cn/ --dir /etc/re6stnet/ --token TOKEN
/etc/re6stnet should contain:
ca.crt cert.crt cert.key re6stnet.conf
Check re6stnet.conf contents:
registry <registry-url>
ca <path-to-ca>
cert <path-to-cert>
key <path-to-key>
# increase re6stnet verbosity:
#verbose 3
# enable OpenVPN logging:
#ovpnlog
# uncomment the following 2 lines to increase OpenVPN verbosity:
#O--verb
#O3
Redo the tests from previous section
Check processes are spawned correctly, check interfaces, check the logs and the default route
Check the cache
You can check the cache is being correctly populated with addresses by dumping the contents of the peer table in /var/lib/re6stnet/cache.db
sqlite3 /var/lib/re6stnet/cache.db 'SELECT * FROM peer;'