Open paidforby opened 6 years ago
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.
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
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
Anyone know if there is an existing sudomesh component that does this: https://openwrt.org/docs/guide-developer/packages ?
would it be possible to create generic ipks?
@paidforby not sure what you mean by "generic ipk"
You're probably talking about this: https://github.com/sudomesh/sudowrt-packages
@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.
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
.
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.
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,
There are two main challenges standing in the way,
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.