proposal for sudowrt 0.3.0 (dispossessed) #zeroconf

[paidforby]

New additions made in this merge allow a newly flashed node to retrieve an IP over its WAN connection from a sudomesh/meshnode-database. Once the node gets an IP, it configures itself to mesh with other People's Open Nodes and to tunnel to a sudomesh/exitnode.

This is done with two scripts:

1. /opt/mesh/retrieve_ip - runs every minute, looks for internet connection, gets mesh IP, passes that IP to the zeroconf script to complete config, deletes the cron that triggers it every minute, deletes itself so it isn't accidentally re-run, and reboots the node.
2. /opt/mesh/zeroconf- takes new mesh IP as input, copies in template config files, makes necessary changes to config files

These additions replace the functionality of sudomesh/makenode; however, importantly, it is still backwards compatible with makenode. That is, if you don't have an hardwired internet connection for your node or would just like the ...convenience... of makenode, you can still configure your node the "old" way after flashing.

However, it should be highly encouraged that new node owners learn to configure their node by hand (e.g. "how do I set the hostname?"). Furthermore, we should see this as an opportunity to build out the features of sudomesh/peoplesopen-dash for node owners who have no interest in sshing into their node.

A few items of note:

• a pre-built binary of this version is avaiable here, http://builds.sudomesh.org/dev-builds/dispossessed/0.3.0/

• 0.3.0 is backwards compatible in the sense that it can babel with mesh nodes flashed with sudowrt 0.2.x and configured with makenode 0.0.1, can tunnel/babel to existing exitnodes (we don't tag releases for this?).

• the root password (for ssh) and admin password (for admin dash) are both set to the default "meshtheplanet" this allows first time users to ssh in and change these passwords (it also allows makenode to configure them)

• the default root/admin passwords "expire" after 12 hours of uptime (we are actually just deleting /etc/shadow, probably not the best way, but it works), there is also the suggestion that ssh access should be made accessible only on a specific physical port, this has yet to be implemented.

• the new script /opt/mesh/zeroconf, can take any IP as an input and reconfigure the node based on that IP, this is a dangerously convenient way of reconfiguring and should be used with great care. We should eventually have a way of checking that the IP requested is a valid mesh IP or is available in the meshnode-database. This may also encourage us to rethink our, arguably, wasteful handling of IPs.

[bennlich]

Woooooo! Incredible!!! This is very exciting. 🐩 🍩 🐄 🐬 😮 🐈

importantly, it is still backwards compatible with makenode.

Hell yeah! I love backwards compatibility. So good!

--

It would be great to get at least a couple of people to independently test this release. I'll try to test it in the next couple of days. The things I'm going to test are:

• [x] does the node get a mesh ip
• [ ] does the node tunnel to an exitnode
• [ ] do ports 3 and 4 work as expected (i.e. do they provide access to the private / public networks respectively)
• [ ] does the admin panel work
• [x] do I get a WAN connection on the private SSID
• [ ] do i get a WAN connection on the public SSID
• [x] does the retrieve_ip script clean itself up

For folks with access to extender nodes, it would also be nice to test:

• [ ] Does the node successfully assign IPs and network w/ extenders on ports 1 and 2

@paidforby Could you make a list of the typical steps of manual configuration one would go through after flashing a node w/ this firmware? E.g. how to change the passwords, set hostname, etc.?

Let me know if there are other things I should add to my list of things to test.

Congrats on this work! 🚀

[paidforby]

Thanks @bennlich Nice checklist! I think you covered most of what should be checked, I would add

• [ ] zeroconf two nodes and confirm that they can babel over their adhoc interfaces

Another note, this should be only compatible the new exitnode because of #127 and depending on the state of the new exitnode (e.g. https://github.com/sudomesh/bugs/issues/31 ), it may be difficult to tell if the WAN connection via the l2tp tunnel is working properly.

Also some of those steps are included in this zeroconf_succeeded message that is copied to the root directory after zeroconf succeeds. I suggest adding more such instructions there (e.g. "go to /etc/config/system to change your hostname, currently sudomesh-node, to whatever you'd like").

[paidforby]

Ok, so now for what I actually came here to do.

Here's an exhaustive checklist for people who may be interested in reviewing this PR. It's mostly inspired by the above list by @bennlich and a convo with @gobengo

• [ ] does the node get a mesh ip
• [ ] does the node tunnel to an exitnode
• [ ] does the node babel with other nodes (both physically via ad-hoc and virtually via tunnel)
• [ ] does the node successfully assign IPs and network w/ extenders on ports 1 and 2
• [ ] do ports 3 and 4 work as expected (i.e. do they provide access to the private / public networks respectively)
• [ ] do wireless clients get a WAN connection on the private SSID
• [ ] do wireless clients get a WAN connection on the public SSID
• [ ] does the retrieve_ip script clean itself up
• [ ] can the node be reconfigured with makenode v0.0.1
• [ ] can the zeroconf script be re-run manually with a new (or the same) IP
• [ ] does the admin panel work (with default pw and changed pw)
• [ ] does the default root password expire after a day
• [ ] are the instructions provided in zeroconf_succeeded text helpful... :)

[paidforby]

p.s. @bennlich I built a new version of the firmware with those recent commits, available here, http://builds.sudomesh.org/dev-builds/dispossessed/0.3.0/

However, it still seems to have trouble babeling, maybe still related to https://github.com/sudomesh/bugs/issues/31. I suggest fixing while working on https://github.com/sudomesh/bugs/issues/33.

[paidforby]

I was tired of looking at this PR and figured I had given people enough time to voice any concern, so I decided to merge it. If there are any major problems we will discover them when we attempt to deploy the next version of the firmware. I'm tempted to tag another release, but we can hesitate on that since the walkthrough may also need to be updated to reflect the zeroconf option. If there are any immediate problems, then we can open issues rather than burying them inside an already bloated PR.

[bennlich]

Nice! Some days the merge buzzer buzzes, and you gotta answer.

[eenblam]

@paidforby Excited to see this in action this evening! Thanks!

[bennlich]

Hey @paidforby. @gobengo reported that on a newly flashed homenode there are no more authorized_keys. Was that intentional?

[paidforby]

x-post from rocket chat. Yes, this was intentional. I'm in favor of an opt-in policy for root access and that node installers should take responsibility for the nodes they install by adding their ssh keys and patching those nodes when needed.

[muxlux]

just don't forget to change to root (or add ssh key) & private network admin passwds within 12 hours :) dispossessed is sooooo easypeasy thx @paidforby!

On Thu, Jul 5, 2018 at 7:22 PM, grant_____ notifications@github.com wrote:

x-post from rocket chat. Yes, this was intentional. I'm in favor of an opt-in policy for root access and that node installers should take responsibility for the nodes they install by adding their ssh keys and patching those nodes when needed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sudomesh/sudowrt-firmware/pull/132#issuecomment-402906081, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLJ4rd3U3O-G8ljHMoCCffWfTJ4YwM7ks5uDsnagaJpZM4Ti4MA .

-- First they ignore you, then they laugh at you, then they fight you, then you win.

• Mohandas Karamchand Gandhi

CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

[bennlich]

Okay, cool. That sounds good to me @paidforby. It does seem like a big change though. Wondering where to document... I think I'll just add some emphasis to the walkthrough that if you're installing a node somewhere, you are responsible for talking to the owner about whether or not to add your keys / who applies patches, etc.

[bennlich]

It also seems like node installers should use special PON ssh keys for this (not their normal default ssh key), so they can hand them off if they take a break from the org. And it seems extra important to write down who installs which nodes where.