Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document changes made by makenode in preparation for deprecation #19

Open
paidforby opened this issue Feb 13, 2018 · 9 comments
Open

document changes made by makenode in preparation for deprecation #19

paidforby opened this issue Feb 13, 2018 · 9 comments

Comments

@paidforby
Copy link

I would like to start documenting all the configurations that are changed by the makenode script. I've started the process at https://sudoroom.org/wiki/Mesh/Makenode. This is, hopefully, in preparation for deprecating makenode itself, or at least reducing its importance in node configuration.

Deprecation will occur through two processes,

  1. Moving all hardware dependent configurations to sudowrt-firmware
  2. Moving all end-user specific configuration to a web portal. accessible through peoplesopen-front or peoplesopen-dash?

There are two main challenges standing in the way,

  1. Getting an ip address from a meshnode-database
  2. Setting root password or ssh keys

A mesh ip address could be requested on first boot (or first connection to internet), so this should be simple enough.

The root password presents larger problem because it needs to be set securely. @Juul suggested setting the private ethernet port (port 3 on mynet N600) to have a default ssh key/password that could be used only on first boot (or within certain, predetermined time period). This way node operators can "opt-in" to having ssh access to their node, or otherwise leave their node locked out from any root access. There are still questions regarding patching and dev access. The documentation/deprecation process may provide a good time to explore options for remote patching/updates.

@Juul
Copy link
Member

Juul commented Feb 19, 2018

The generated .ipk in the ipks/ directory of makenode (after successfully runnning it for at least one node) can be extracted and inspected to see exactly which files are generated by makenode, but of course this is hardware-dependent. The extender nodes already have a system for creating config files based on templates on first boot (well actually it will continue trying until each script exits successfully). This is handled by these scripts. This system of first-boot scripts is built into openwrt. The linked files are specific to sudowrt but the system is part of any openwrt build.

@gobengo
Copy link
Contributor

gobengo commented Feb 20, 2018

Setting root password or ssh keys

I put some ideas for this here https://github.com/gobengo/makenode/wiki/Ideas-for-how-to-set-root-password-and-keys

@paidforby
Copy link
Author

Regarding some discussion with @gobengo and @bennlich would it be possible to create generic ipks? These could then be complied in to a package stream in a trusted repository hosted on the mesh. Once we figure out how to grab an IP from meshnode-database on first boot, nodes could pull updates from this repository to get any patches. We could then have a stable/unstable/testing structure of packages (or a system for maintaining immutable configurations?). I recall @Juul mentioning something about a node-configurator server, was this sort of package stream the idea behind https://github.com/sudomesh/node-configurator

@gobengo
Copy link
Contributor

gobengo commented Mar 7, 2018

Anyone know if there is an existing sudomesh component that does this: https://openwrt.org/docs/guide-developer/packages ?

@bennlich
Copy link
Contributor

bennlich commented Mar 7, 2018

would it be possible to create generic ipks?

@paidforby not sure what you mean by "generic ipk"

@max-b
Copy link
Member

max-b commented Mar 7, 2018

You're probably talking about this:
https://github.com/sudomesh/sudowrt-packages

@paidforby
Copy link
Author

@bennlich I guess I meant ipks that don't include node-specific configs like mesh IPs or hostnames.

And @max-b yeah! You're right, thanks for the reminder. We could handle patching through sudowrt-packages.

@bennlich
Copy link
Contributor

Some notes from tracking down where sudowrt-packages gets used:

Seems like packages listed in this file get pulled in with the feeds tool here during pre-build.

Looks like feeds are configured here: https://github.com/sudomesh/sudowrt-firmware/blob/master/openwrt_config/feeds

Some packages live in https://github.com/sudomesh/nodewatcher-firmware-packages instead of sudowrt-firmware. Not sure why.

This was useful reading: https://openwrt.org/docs/guide-developer/overview.

I guess the feeds tool is a build tool only--it doesn't live anywhere on a built OpenWRT router. I don't understand the difference between something like feeds and something like opkg.

@paidforby
Copy link
Author

packages that you want to build into the firmware get pulled from feeds. If we want to pull from these feeds after the firmware is built we should add them to opkg.conf either in makenode (for the normal build) https://github.com/sudomesh/makenode/blob/master/configs/ar71xx/templates/files/etc/opkg.conf or to the zeroconf branch here, https://github.com/sudomesh/sudowrt-firmware/blob/zeroconf/files/etc/opkg.conf
I'm still unsure how nodewatcher differs from sudowrt-packages differs from the normal openwrt repository, would useful to understand the differences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants