The received network parameter name can have a ':json' suffix that
is not present in the class attribute of this parameter.
This suffix was not removed and could cause attribute deletion to fail.

/reviewed-on nexedi/re6stnet!20

In commit d7a4d73f,
this was done only for the init.d script.

/reviewed-on nexedi/re6stnet!11

argparse is error-prone in that `action='append'` starts from (a copy of) the
given default when it adds values from command-line, rather than restarting
from an empty list. For example, simply passing `--disable-proto udp` resulted
in ['udp', 'udp6', 'udp'], which caused 'udp6' to remain disabled.

/reviewed-on nexedi/re6stnet!17

In commit 06974788,
we increased the --link-mtu value as a temporary way to compensate the
unexplained behaviour change of recent OpenVPN.

This was partly due to encryption, which was enabled despite
`--cipher none`. And it happens that the behaviour of --link-mtu only
changed for the server, with a mysterious difference of 93 bytes.

Hence the workaround to get identical tunnel MTU on both sides.

/reviewed-on !13

The fix to mark an interface as "up" and indicate its MTU was
useful for machines with a single client, because OpenVPN would fail
to configure them this way in OpenVPN 2.3. It has been fixed in 2.4
so the fix has been removed.

/reviewed-on nexedi/re6stnet!14

Passing `--cipher none` to OpenVPN is not enough anymore because
clients and servers can still negotiate the algorithm to use for
encryption (by default not empty). We pass the option `--ncp-disable`
to disable cipher negotiation.

/reviewed-on !12

The behaviour of --link-mtu has changed and we increase the values to
at least have interface MTU greater than IPv6 minimum.
We'll see later to have even greater values in ovpn_link_mtu_dict
(so that the resulting MTU is closer to what we had with 2.3)
or review the whole MTU part completely.

The main goal of this is to check if we should keep supporting
older distributions.

/reviewed-on !9

See "./demo --help" for more information.

/reviewed-on nexedi/re6stnet!8

/reviewed-on nexedi/re6stnet!7

prevent this kind of errors when running openssl fail:

```
10-12-2018 19:04:02 ERROR     AttributeError: 'NoneType' object has no attribute 'splitlines'
Traceback (most recent call last):
  File "/opt/re6st/eggs/re6stnet-0.513-py2.7.egg/re6st/cli/node.py", line 428, in main
    s(*args)
  File "/opt/re6st/eggs/re6stnet-0.513-py2.7.egg/re6st/utils.py", line 191, in select
    R[r]()
  File "/opt/re6st/eggs/re6stnet-0.513-py2.7.egg/re6st/tunnel.py", line 399, in handlePeerEvent
    True, crypto.FILETYPE_ASN1)
  File "/opt/re6st/eggs/re6stnet-0.513-py2.7.egg/re6st/x509.py", line 136, in loadVerify
    for x in err.splitlines():
```

/reviewed-on nexedi/re6stnet!6

Ideally, babeld should not keep running when it can't set such routes.
Currently, it only outputs an error message in its log.

In SQLite, a string that only contains '0' chars evaluates to False.

We currently have issues with OpenVPN hook scripts that aren't always killed
at exit. Such orphan processes prevent re6st from starting again (EADDRINUSE).

We want to know if it's an OpenVPN that does not exit cleanly on TERM,
or if it sometimes does not exit at all after 5s (then re6st sends a KILL
signal and at that point we should indeed make sure that any subprocess is
also KILLed).

gaierror: [Errno -2] Name or service not known
Traceback (most recent call last):
 File "re6st/cli/node.py", line 271, in main
   remote_gateway, config.disable_proto, config.neighbour)
 File "re6st/tunnel.py", line 663, in __init__
   cache, cert, address)
 File "re6st/tunnel.py", line 236, in __init__
   self._updateCountry(address)
 File "re6st/tunnel.py", line 643, in _updateCountry
   family, ip = resolve(*address)
 File "re6st/tunnel.py", line 30, in resolve
   for x in socket.getaddrinfo(ip, port, family, 0, proto))

where ip is '-a'

/reviewed-on !4

error: [Errno 21] Is a directory: 're6st/cli'

/reviewed-on !3

Also, add iptables/ip6tables example configuration.

Using datetime objects was a bad idea anyway. Its extra accuracy for
microseconds is lost because datime.utcnow() is slower than time.time().

Required to share the connectivity with others.