Feature Request: Wizard for EdgeOS

[vchrizz]

Would you be interested in creating a Wizard for EdgeOS ?

So users could just add/upload the Wizard on to the EdgeRouter without having to manually install deb files via shell?

I created an EdgeOS-Wizard for OLSRd routing and want to ask you before I start creating a Wizard for WireGuard.

[FossoresLP]

Hi, I'm sorry for taking so long to reply. This would be pretty interesting, however I'm a little unsure about updating. How would that be handled in this case? For WireGuard it is strongly recommended to always use the latest version. But auto updating is not recommeded for the packages right now, since they are not properly tested before now releases.

[vchrizz]

Wizards in EdgeOS are put in directory /config/ which stays untouched after an EdgeOS firmware upgrade. (if enabled in the wizard) The wizard for OLSRd installs a script to check if OLSRd is installed and installs OLSRd again in case it is not installed (like after a firmware upgrade). For wireguard I could think of a similar script in /config/scripts/post-config.d/ to do the same and check for possible wireguard updates. Before firmware updates I usually test the upgrade with a local running router though to be sure everything works as expected.

[FossoresLP]

Thank you for the detailed reply. What I'm worried about is that since users do no longer have to know how to install the deb packages, the update would (as you described) have to happen using a script. I have rejected the idea of adding such a script to this repository in the past due to releases not being tested very well and sometimes breaking. (See #28) Although the best approach would of course be to address the untested releases, do you think there would be something else we could do to resolve this? I was thinking about notifying the user about updates but that seems hard due to the limitations of the UI and I'm not sure requiring manual updates when using the wizard would be a good idea. Another idea I had was to simply wait 1-2 days before installing an update (in that time, most issues would have been reported and fixed / the release would have been pulled).

[vchrizz]

Well, for the OLSRd-wizard we let the user to opt-in for auto-update, see following screenshot: As for releases I think they should be tested accordingly as already stated. If you do not want to test or do not have the possibility to test, you could flag the release as beta and not use it for auto-update until you have enough feedback that a beta-release is well tested and ready for "final" (and auto-update) release. In our OLSRd-wizard there is also a field that informs users about available updates and lets the user upgrade manually by selecting the appropriate checkbox before "apply" is clicked. That way the user has full control over updates wether for automatic or manual.

[FossoresLP]

I'd be more than happy to merge a PR for such a wizard then. Although I am not sure how much I can do about testing, as long as there are sensible options to manually upgrade your proposal looks like a great improvement in the user experience. Still, I'd like to add a warning to the auto-update function, even when potentially implementing some kind of beta release system. And thanks for taking the time to answer my questions and sticking with this even though it took me so long to reply.

[dulitz]

For pre-release testing, perhaps someone could commit to run a few EdgeRouters with the wizard in auto-update, with a monitoring system? I could provide 2 or 3 if someone was willing to run them...

[vchrizz]

I'd be more than happy to merge a PR for such a wizard then.

Great, then I'll start with the wizard. Will take some time though I guess until I have something to show. I'll keep you posted. Thanks!

For pre-release testing, perhaps someone could commit to run a few EdgeRouters with the wizard in auto-update, with a monitoring system? I could provide 2 or 3 if someone was willing to run them...

Cool, thanks for the opportunity! We have many EdgeRouters in our network, hence the wizard for OLSRd. In the last few days I installed the wireguard package from this repo on all of them and am worrying about a possible EdgeRouter firmware upgrade where I would need to install the package again, thats why I am thinking about creating a wizard for wireguard which does that for us :)

[vchrizz]

While working on the wizard I noticed following: filename of the package is: e50-v2-v1.0.20210606-v1.0.20210914.deb dpkg returns as version: 1.0.20210606-2

1. Why is the version inconsistency in the filename (without -2) to the package (with -2)?
2. Which version should be checked for package updates? (looking at the package version I guess the first) a. the first 1.0.20210606 ? b. the latter 1.0.20210914 ? (why is that even in the filename?) c. both?
3. Why not name the file wireguard_e50_v2_1.0.20210606-2.deb ?

For a version-check it is helpful to clearly have the actual package version in the file name (also without v as prefix), otherwise this has to be handled specially where a version comparison is done.

[FossoresLP]

I would recommend using the Git tags of releases for version checks instead of the actual file names. Those adhere to the naming scheme you described.

The file names currently include the module and tools version. I did it this way, since there is no good way to otherwise check which tools version the package includes without installing it. There was originally no intent to have package releases (-2), but that started to become necessary later on. I could change the file names. However, that has the potential to break other scripts that have already gained somewhat widespread adoption (e.g. https://github.com/whiskerz007/ubnt_get_wireguard).

My approach would be to compare the installed version (using dpkg) with the latest release tag on GitHub. Would that work for you?

[vchrizz]

Ok, I understand. Yes, comparing to the release tag works. I didn't notice the release tag matches the package version. Good idea, thanks!

[vchrizz]

A first view on the wizard: I'm thinking about how much configuration I should put into the wizard. Preferably I would add rather less options to keep it clean and if a user needs more advanced configuration, it is still possible to configure specifics via the ConfigTree menu. Like for instance the configuration of multiple interfaces, I would stick the wizard to configure just one interface (wg0) as it is the most common situation. What do you think?

[FossoresLP]

It looks like all common configuration options are available. I would agree that multiple interfaces would be a somewhat advanced feature. In my opinion, your interface is a good compromise between features and ease-of-use. In case anyone disagrees, please give your feedback in this issue.

[vchrizz]

Basically I've got a working "alpha" version ready of the wizard, which does following:

• check package installation status (and try to download/install package, if not already installed)
• check if updated version available
• check process status if an instance is running
• read/write configuration (as shown in the screenshot before)

I am a bit struggling with selecting the right package for the different EdgeRouter devices, at the moment I came up selecting the right model using the following snippet. Because I do not have access to every model available, I tried to construct that snippet by looking at Ubiquiti's firmware download page. Hopefully I got it right, else please report so I may fix it! If anyone has an EdgeRouter/EdgePoint not listed here, please run show version | grep model on your router and show the output.

edgerouterhw=$(/usr/sbin/ubnt-hal show-version | awk '/HW model/{$1=$2="";print substr($0,3)}')
case $edgerouterhw in
    'EdgeRouter X 5-Port'|'EdgeRouter X SFP 6-Port'|'EdgePoint Router 6-Port'|'EdgeRouter 10X')
        edgeroutermodel='e50'
        ;;
    'EdgeRouter Lite 3-Port'|'EdgeRouter PoE 5-Port')
        edgeroutermodel='e100'
        ;;
    'EdgePoint Router 8-Port'|'EdgeRouter Pro 8-Port')
        edgeroutermodel='e200'
        ;;
    'EdgeRouter 6P'|'EdgeRouter 4'|'EdgeRouter 12'|'EdgeRouter 12P')
        edgeroutermodel='e300'
        ;;
    'EdgeRouter Infinity'|'EdgeRouter 8-Port')
        edgeroutermodel='e1000'
        ;;
esac

[dulitz]

My ER-6P reports EdgePoint Router 6-Port and is an e300. I'm not sure if there is anything that reports "EdgeRouter 6P".

[vchrizz]

I have following EdgeRouters on hand to test:

• ER-X-SFP EdgeRouter X SFP 6-Port (e50)
• EP-R6 EdgePoint Router 6-Port (e50)
• ER-6P EdgeRouter 6P (e300)

Interesting, that your ER-6P reports different than mine. Which EdgeOS version do you have running on it? On my ER-6P actually v2.0.9-hotfix.1 is running. edit: Are you sure you have an ER-6P (e300) and not maybe EP-R6 (e50) as it seems it is an EdgePoint? I know, those model names look similar... ;)

[doc-jay]

I think multiple interfaces would be helpful, of course they can still go to the config tree and manually create a new one, and then manually do all of the settings from there.

[vchrizz]

When designing the wizard interface I first thought to add the possibility for multiple interfaces but then realized that I'm somhow re-creating the ConfigTree and therefore reconsidered that, thinking: if an user is advanced enough to know how to handle uncommon situations, the user might also be able to use the ConfigTree. The wizard is intended for installing/upgrading wireguard (like e.g. assure to be installed after firmware updates - but this could also be done with a small script and the deb package in /config/), as also give a simple/quick interface to rather less advanced users. So I now designed the wizard to configure interface wg0 and not touching other existing wg1-wg999 interfaces in ConfigTree.

[vchrizz]

Thanks to @pocki80 I could solve the problem with selecting the right package by using /usr/sbin/ubnt-hal-e getBoardIdE which returns the router's board-id. There I just replace the last integer with a zero to match the board-series with the wireguard packages. what works quite well:

edgerouterhw=$(/usr/sbin/ubnt-hal-e getBoardIdE | sed 's/[0-9]$/0/')
edgeosversion=$(/usr/sbin/ubnt-hal show-version | awk '/Version/{split($2,v,".");print v[1];exit}')
pkgvariant="$edgerouterhw-$edgeosversion"

For example on an ER-X-SFP running EdgeOS v2 this leads to:

echo $pkgvariant
e50-v2

@FossoresLP How do you want to handle automated updates of the wizard itself? For the package I would set up a cronjob which regularly (daily?) checks the "latest" tag to download and install if auto-uprade is enabled.

[FossoresLP]

I would assume a similar approach to the package would be nice. It would probably be a good idea to check for wizard updates before updating the package, just in case we want to fix an issue with the update script. I'm not sure where the best place for pulling the update would be, however. Pulling from master is not exactly best practice. Maybe the wizard could get a file in the release, a simple ZIP would probably be enough.

I'm pretty sure the boards hardware series number do not match for UGW (they use e.g. e120), however this should not be an issue since the wizard only works on ER anyway, right?

[vchrizz]

Ok, then I assume an own repository for the wizard would be appropriate where the update process can be handled same as for the package. For now I created one in my account: ER-wizard-WireGuard To upload the wizard in EdgeOS it must be a tar file containing the three files wizard-run wizard.html and validator.json so that tar file should be used for releases . I'm working on the auto-update feature, else the wizard should be pretty much completed, but I still have to do some testing.

It would probably be a good idea to check for wizard updates before updating the package, just in case we want to fix an issue with the update script.

You mean the order of the automated update? To first update wizard and after that the package? Good point.

I'm pretty sure the boards hardware series number do not match for UGW (they use e.g. e120), however this should not be an issue since the wizard only works on ER anyway, right?

Right, as far as I know the wizard functionality is available only on EdgeMAX / EdgeOS devices, so the wizard is only for those devices. I don't know UGW devices yet, do they have any plugin-like functionality like the wizards in EdgeOS ?

[vchrizz]

After some thorough testing of the finished wizard I think it is fairly ready to use, so I released v1.0 in the mentioned repository. Feel free to try it out and please report if you notice any issues I might not noticed yet. If no severe bugs will be reported that I overlooked I would call this "feature request" completed. I hope this would also fix #28 #41 #87 (at least for EdgeMAX / EdgeRouter devices)

[vchrizz]

Meanwhile I've got v1.4 of the wizard with mostly feature addings like key generation and display QRcode. It works quite fine on all routers I have by my hand, so I am slowly deploying the wizard on productive routers in our network. I would kindly ask you to try it and report back any problems. Thanks!

[dc361]

Asking a fairly basic question -- do you need to have wireguard installed and configured before using the wizard? I tried from scratch on an ERX-SFP that is configured as a switch but the wizard didn't set an IP address on the wg0 interface. The wg showconf wg0 command only listed the key and the mtu. Also the QRcode generated was invalid.

[vchrizz]

The wizard should install the wireguard package for you if it is not installed already. At the moment, the wizard doesn't do any IP configuration, I thought about it but have no idea in what way to implement that. What do you expect how it should work? Ideas welcome! What exactly was invalid in the QRcode? The contents of the generated QRcode should show if you hover your cursor over the image or also in the browser console to double check th generated values. Could you open issues and describe in more detail please? Then I could try to implement/fix that.

[Amoeba00]

This is a very cool wizard and I did some testing on my ER-4. Reported issues on your GitHub page. Thanks for your efforts on this. Very impressive!

[Amoeba00]

OK - all issues addressed. Works great on ER-4 and ER-12 (in place upgrade to 1.0.20210606-3).

[vchrizz]

I guess this "Feature Request" can be closed, as the Wireguard Wizard seems to work quite fine.

[FossoresLP]

@vchrizz Thank you for your work on the wizard. I'll add a link to the installation guide for EdgeOS.