Allow current host in peers #25
Conversation
There are legitimate cases where one might want to use the current host in "peers". In particular our tests do this by using "localhost"; this *usually* works because the hostname returned by `gethostname` is the ~unique name of the host, so doesn't match "localhost". In some environments, though, `gethostname` can return "localhost", which causes the peer to get filtered out. Notably this includes nix build environments, which intentionally avoid letting global unique state into the environment, since it would make the build non-reproducible.
|
I see that setting OTOH I still think the current behavior is surprising, and doesn't appear to be documented. |
There was a problem hiding this comment.
It looks like that filter was added 7 years ago, near the initial efforts to write tgen. IIRC, the idea was that we just want to put the full peer list on every node, but we only wanted remote downloads. This was back when every tgen acted as both a server and a client.
These days, in tornettools, servers and clients are independent
I'm happy to remove it as long as we're sure it does not upset our new(er) tornettools workflow (I don't think it does) :)
|
Tested using shadow/tornettools#52 |
There are legitimate cases where one might want to use the current host
in "peers". In particular our tests do this by using "localhost"; this
usually works because the hostname returned by
gethostnameis the~unique name of the host, so doesn't match "localhost".
In some environments, though,
gethostnamecan return "localhost",which causes the peer to get filtered out. Notably this includes nix
build environments, which intentionally avoid letting global unique
state into the environment, since it would make the build
non-reproducible.
I'm not sure what problem this check was originally trying to solve. If we want to keep the safeguard some alternative options are:
gethostnamecould a different name for the host than used in the config.