[IDEA] Separate default network config into different "profile" packages

For Developers
1

One of the issues I face on a semi-regular basis with OpenWrt devices is the need for manual reconfiguration in case of a factory reset.

OpenWrt by default ships a "network gateway" profile that assigns the appropriate ports to wan and lan configurations, sets up firewall rules and routing inbetween, disabled WiFi, etc., for security purposes. This is fine for a fire and forget type of setup, where you set up the device once and it works wonderfully.

But, I believe many of us have multiple OpenWrt devices at home in various roles, where losing the configuration due to a factory reset means tiresome manual setup again. For example, I have 3x Belkin RT3200's which sometime go bonkers and need a reset. These three units are set up as a dumb wireless APs with bridged interfaces (no relayd), and a factory reset renders me unable to re-do the setup without physically accessing the device (uplink to main network is through WAN port for ease of use, after reset, SSH and web interface access is restricted).

Today, we have pretty awesome solutions for customised firmware builds - both the OpenWrt Image Builder, and aparcar's much-appreciated work on attendedsysupgrade and its backing service. This makes it incredibly easy to generate role-specific builds, including/excluding packages as one sees fit.

Running the image builder locally, however, can be a daunting task for a beginner, and most people opt for attendedsysupgrade, which has one major drawback: no custom files/packages can be included, only things from the official ImageBuilder. This means that ASU cannot create actual role-specific builds that can auto-configure themselves to the intended role/profile upon reset.

To solve this, and to make OpenWrt a bit more flexible, I would like to propose the separation of the default network configuration/profile into separate packages. The default build then could include the default profile ("network gateway"), and via ImageBuilder/ASU, the user could replace that package with a more fitting version for their purpose (e.g. a network gateway with WiFi enabled by default, or a wireless AP/switch profile like mine above), while still allowing the user to manually configure final details.

I want to emphasize that this would have very little effect on the official builds - at the end user, nothing would really change on a pure install, but for those who customise their setups, this would be a godsend in case of necessary repairs/reconfiguration.

This solution would also allow users to easily re-configure their network by installing a single meta-package. I remember, as a beginner with OpenWrt, coming from more user-friendly options like Padavan or AsusWrt, I often struggled to achieve specific network configurations that are usually a single button selection on said firmwares. The amount of control, combined with the often out-of-date wiki (not trying to complain here, in fact I appreciate those amazing people who sacrifice their free time to keep it up to date!), and the somewhat steep learning curve can be quite a deterrent for a lot of people from actually using pure OpenWrt (on another note, it would be great if there was an open source project, similar to what GL.inet has done, to provide a simplified, more user-friendly interface that hides away all the pesky low level configuration bits). If there was a list of officially supported/provided profiles/roles, even in a limited manner (I doubt there would be need for more than 3-4 different roles), I think a lot more users would choose OpenWrt over other hacky projects that lack transparency.

I understand that for OpenWrt, ease of use is not a primary goal, however I believe this change would be superficial enough to require very little work on top of what already exists, while providing a significant amount of usability upgrade.

2

Make a feature request to provide a text-input field for a uci-defaults script:
https://openwrt.org/docs/guide-developer/uci-defaults

3

The problem with that, as @aparcar and others has pointed out, is that people would use it to supply their whole network config, not just a barebones fallback variant, exposing their wireless network names and PSKs, and other sensitive information (say, their root password...).

What I'm recommending would become a core part of OpenWrt, configuration-on-demand, allowing people to request a build from ASU that fulfills a specific role by default, with base values supplied. That way the actual fine-tuning of the interfaces would still be on the user, BUT the default configuration would be something that matches their needs, and requires only the private, instance-specific variables to be configured.

For example, in my use-case, the default configuration of a wireless-ap-switch profile would bridge all ethernet ports into the lan bridge, forego the creation of all wan-related bits (bridge, firewall zone, routing), disable DHCP server and firewall, and set lan as DHCP client. In contrast, a wireless-gateway profile would do precisely what OpenWrt does right now - create the wan interface with the wan port, assign it to the wan firewall zone, create the lan bridge from all the LAN-side ethernet interfaces, create routes, etc., whereas a wireless-relay profile would create the wireless STA interface for uplink, put it in the wan zone, create the AP interfaces, bridge them over with all the ethernet ports, enabled relayd and so on.

Also, this idea is but the first step of what I've been working out as a plan to make OpenWrt et al more user-friendly. There are further steps that I'm still working out the logistics of:

  • making luci able to manage remote devices + including a remote manager, similar to how e.g. the Deluge web interface works, or Portainer with multiple hosts
  • creating a templating language (YAML-based) that allows the deployment of ready-made configurations with user variables, where the LuCI interface for setup is automatically generated (think of it like docker-compose, or, an even more apt comparison would be HomeAssistant's blueprints). This would allow users to deploy e.g. guest networks, or whole network configurations, with a single click (well, technically not one click, but through a nice interface where they can set the appropriate variables, let it be simple text fields or dropdown selectors)
  • creating a system that can store and "swap" saved configurations (either partial or full) with a click of a button - especially useful for travel routers where one might want to switch between ethernet or WiFi STA uplinks and such
4

I commend you for your efforts, but the above rationale seems to be flawed.
Users usually can reach their device and restore the backup after factory reset.
In addition, you likely underestimate the amount of work to implement this idea.
Meanwhile, you can use one of the LAN ports as the main link to your network.

5

I like the idea and would like to help. I have made a package that supplies a file before

there is already a very decent remote management software for openwrt (although not "openwrt official"), I would recommend you contribute to them instead

this will never fly

also a nice idea, as a separate package not part of openwrt core

6

In addition, you likely underestimate the amount of work to implement this idea.

I don't see why it would be a great effort to separate the script that currently generates the default /etc/config/network, /etc/config/dhcp, /etc/config/wireless and /etc/config/firewall configurations, package it, and allow for the creation of alternative implementations.

I commend you for your efforts, but the above rationale seems to be flawed.
Users usually can reach their device and restore the backup after factory reset.

Usually yes, but OpenWrt is slowly becoming a much bigger thing than the "garage project" (no offense meant) it used to be. Right now it does a single thing (configuring networking via uci) very well, at the price of having no ease of use features.

At this point I wouldn't even mind if OpenWrt got broken up into three individual parts:

  • The low level hardware support that provides the unified build system that can be configured to support any device with network interfaces that can run the Linux kernel
  • The middleware, a.k.a. uci, a standardised interface for querying and configuring underlying features
  • The frontend, a.k.a. luci that provides ease of use features, possibly even abstracts certain things for proper human-machine interactions

Right now I'm recommending extending luci to provide the UX most average users would need. I could easily see OpenWrt being deployed in an enterprise environment if the software support was there. Say, you built a Ubiquiti network - if any of the APs go down, after a remotely executed factory reset, you can easily re-deploy the config, if you want a new AP/switch/edgerouter set up, it's also straightforward, all from a single interface. It's just use friendly.

Since this is an internal change to the project, I'd like to wait for feedback from the core team before we even begin work.

OpenWisp is for deploying configurations remotely without using LuCI. My idea is to make a single instance of LuCI connect to any remote where luci-mod-rpc is available, which should be, again, a straightforward change in LuCI (add a remote manager, modify uci.js to connect to selected host from remote manager).

There's already a similar approach in the wiki that executes code snippets right from the wiki pages. This would be similar, but with a configuration system that allows easy user definition of variables.

Not a core part, no, but it would rely on the aforementioned templating system that would auto-manage the IDs of certain sections. E.g. you could deploy a guest network, and all related bits (firewall zones, rules, forwarding, DHCP server, wireless network, network bridge, etc.) would be tagged with an ID that identifies that specific entry as part of a profile. So it can't really be done separately unless you want to swap EVERY config running on the device.

7
8

Yeah, that feature wasn't available when I made my post.

Also, adding specific packages for network configurations that can be easily swapped out during build (either via SDK, Image Builder, or AUC's online image builder) would be preferable to having manually coded configurations, especially for defaults.

9

Someone has to implement that feature and become its maintainer.
Since no one has volunteered yet, this is unlikely to happen in the near future.
Meanwhile the uci-defaults script should provide sufficient functionality.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.