support for babeld 1.8.2

[bennlich]

files changed:

• /opt/tunneldigger/broker/scripts/down_hook.sh
• /opt/tunneldigger/broker/scripts/up_hook.sh
• /etc/babeld.conf
• /etc/system/systemd/babeld.service

I made the corresponding changes manually to the HE exit node, but unfortunately I have not tested the create-exitnode.sh script yet. (Would be nice if the way to upgrade the deployed HE node was to simply rerun the create-exitnode.sh script, but I wasn't confident this would work. Does anyone know?)

TODO:

• test the create-exitnode.sh script on a fresh exitnode (any takers?)
• remove or fix babeld-monitor.sh (and its associated systemd units). I broke it with this upgrade--I'm irrationally optimistic that it will solve all of our babeld problems, and that we won't need this monitor anymore.

notes:

• the rogue reconnecting node appears to be back, trying to open tunnels to HE every couple of minutes with tunneldigger id 5fec6d32-83e9-41cf-aaa5-e038fea8d191. This is sort of convenient because it helps us test whether we continue to see the memory error in setsockopt out of memory causes babeld failure bugs#24.
• I had to install netcat-openbsd because the version of netcat on the HE node did not support ipv6 addresses, and babeld -G seems to bind to ipv6 ::1 only.
• babeld -i is no longer a thing (same with -a and -x). The new way to dump babeld state is to communicate with babeld over TCP: (echo "dump") | nc -q1 ::1 31337. I'm thinking it would be nice to put this in an easily accessible babeld-dump.sh script on the PATH. Any suggestions for where such a script ought to live? I imagine we might end up with some kind of mesh-tools/ directory with useful debugging/management scripts.

I'm okay to merge as soon as someone tests meshing with an exitnode created with create-exitnode.sh.

[paidforby]

Cool stuff @Benny and thanks for updating HE!

I noticed one problem, we can no longer start babeld with systemd like before. If you try running,

/usr/local/bin/babeld -S /var/lib/babeld/state -c /etc/babeld.conf 

you'll get,

Eek... asked to run on no interfaces!

Checking an exitnode right after creating it, I noticed that babeld failed to start. This is isn't a huge problem, because as soon as you get an up hook on a tunnel, babeld is (I'm assuming) started properly by that? I can't test this theory because I don't have a home node on hand to point at my exitnode. Not sure of the best way to restart babeld in the latest version, but this system service was mostly used by the babeld-monitor (which is hopefully, no longer necessary 🤞 ).

It would be nice to be able to just re-run create_exitnode.sh, but I know, right now, that doesn't work, errors occur when cloning repos into already filled directories.
The simple (but maybe not best?) solution is to delete those directories if they already exist? or maybe if they do exist, just git pull rebase them?
Adding something like,

if [ -e "/root/babel_build" ]; then
     rm -r /root/babel_build
fi

for each repo does the trick, but seems a little destructive.

Also, love the mesh-tools idea, I typically like putting stuff like that in /opt/, but that's just me.

[bennlich]

Thanks for looking at this @paidforby ! And good catch. I forgot to include a change to babeld.service that I made on HE: to pass in a fake dummyinterface name to babeld when first starting. Also reminds me to ping jech about this... Would be nice to not have to do that.

This is isn't a huge problem, because as soon as you get an up hook on a tunnel, babeld is (I'm assuming) started properly by that?

No, babeld needs to already be running in order for the tunnel hooks to communicate with it over TCP.

It would be nice to be able to just re-run create_exitnode.sh, but I know, right now, that doesn't work, errors occur when cloning repos into already filled directories. The simple (but maybe not best?) solution is to delete those directories if they already exist?

I think that's actually a good solution. Wholesale obliteration is a good way to have certainty that you're actually replacing what you want to replace, and not accidentally missing a few files here and there. Wholesale obliteration gets easier (and better) the fewer the places we write to.

Unfortunately, we probably don't want to obliterate the /etc and /opt directories. Would it be weird to write to ~/exitnode_etc and ~/exitnode_opt, and then put symlinks into /etc and /opt that point to files in those local directories? I'm imagining then an upgrade might be as easy as wholesale replacing ~/exitnode_opt and ~/exitnode_etc. Although it seems like there are still going to be a few files here and there that we have to insert in particular places that don't really belong to us, e.g. /etc/systemd/system/babeld.service.

[bennlich]

Should now be able to run babeld-info after logging into HE.

[paidforby]

added that rebuild feature per your suggestion @bennlich
Also, cool babelling info script! Could use a little formatting, but otherwise works nicely as a replacement for babeld -i.
Seems more than fine to merge, though as I suggested in sudomesh/bugs#33 (comment) it seems a little confusing to use "dummyinterface" maybe we could use loopback instead? Just a minor suggestion, feel free to merge at your discretion.

[bennlich]

Need to fix babeld-monitor.sh before merging this--it turns out the babeld memory leak was not fixed by the upgrade :-/

cc @eenblam

[paidforby]

I'm going to merge this because I'm tired of the rebuild feature not being in master