Hello from EMSU and a request for guidance

[Martin Süfke]

Hello everyone,

my name is Martin and I hail from a small ( less than 10 people) team at
EMSU GmbH in Aachen, Germany. Our main product are in-store shelves with
displays[1],
a show room and marketing solution. We have an established system using
routers
running OpenWRT to provide internet connectivity to control the images
and videos
on the devices.

To improve on the setup process of these routers, we are looking into
managing
them with OpenWISP. Thank you everyone who has worked on this project so
far,
OpenWISP looks great for managing OpenWRT routers. Right out of the box it
checks almost all of our requirements when used with the custom OpenWRT
firmware image we already have.

However, there is one issue we cannot live without: Setting any router's
password
based on criteria such as the router's MAC address. While the
send-command-to-change-password function[2] sounds great for a few devices,
it would be unfeasible to run that by hand and the "access credentials"
scheme
used by OpenWISP is not quite to our liking (yet). There is also a
number of other
constraints and desiderata I will not elaborate on right now.

We have some developer time we could pour into a password provisioning
scheme
within OpenWISP.
My question is: How to do that best so that it can become a sensible
addition to the
project instead of only an in-house patch? Is such a feature even
desirable for the
public project?

Being faster with the keyboard than with the social project integration,
I have something
kind-of working. My solution reuses the MAC address found in the VPN
configuration to
write a custom UCI file which is then picked up by a custom script on
the OpenWRT router.
If anybody would want that as-is, I could share it.

However, I am unsure if and how to proceed:
a) Does such a feature already exists already somewhere else?
b) My solution is a bit Frankenstein-ish, misusing the VPN configuration
for something
   decidedly non-VPN, are there better ways to accomplish what I have?
c) My changes could be applied as a patch on the released
openwisp-controller 1.0.3 [3],
yet I am unaware of where "development happens" and how features are
added to
OpenWISP in general.
d) How should I coordinate with OpenWISP?

Please advise.

Yours,
  Martin

[1] https://emsu.io/moebel/
[2]
https://openwisp.io/docs/user/send-commands.html?highlight=Change%20password
[3] https://github.com/openwisp/openwisp-controller/tree/1.0.3

[Federico Capoano]

Hi Martin,

I am glad you find OpenWISP helpful!

What you describe seems to me more like a special password policy of your organization rather than a feature that should be added to the core of OpenWISP.

Therefore, I think this is best implemented with additional logic that is kept separate from OpenWISP.

There are ways in which it could be done with a few lines of additional Python code using the Django signals (events) provided by OpenWISP, eg:

- listen to device created signal and generate an /etc/shadow file in the config of the device with the right password based on the mac address of the device, alternatively the /etc/shadow could be a template which has a variable and you could only generate the variable

- do something similar but using the send command feature automatically after the device is created and becomes available for the first time

However, if I had to do it on a project I would be working on, I wouldn't even bother, unless I was forced to use vanilla OpenWrt images.

If, as I usually do, I or the organization I am working with is preparing their own tailored firmware image, I would simply add this logic in an uci-defaults script, which is executed the first time the device boots.

Regarding the SSH access from the OpenWISP side, you can solve that with an SSH key that is deployed on your devices with a template, you can find an example of this in the demo system, the template URL is https://demo.openwisp.io/admin/config/template/45bacea6-661e-40af-b047-4ea5ae48c95a/change/ (to access this see demo system instructions).

So to reply to your questions:

a) Does such a feature already exists already somewhere else?

Such a feature does not exist.

b) My solution is a bit Frankenstein-ish, misusing the VPN configuration
for something
    decidedly non-VPN, are there better ways to accomplish what I have?

I recommend one of the ways I explained above, uci-defaults being the simplest one which does not involve writing logic on the server side.

I would opt to add logic on the server side only if the policy can change over time (in that case I would opt for a template which you can update in the future) or if you're using vanilla OpenWrt images (the images from downloads.openwrt.org) and hence you cannot include custom uci-defaults scripts.

Since OpenWISP is designed to be extensible, this allows to accommodate special cases like this one without editing the core system but by leveraging its Python API, the Django framework and even the HTTP REST API if needed.

Find out more about Django signals here:

https://docs.djangoproject.com/en/4.1/topics/signals/

Custom Signals defined by OpenWISP Controller and OpenWISP Monitoring:

https://github.com/openwisp/openwisp-controller/#signals

https://github.com/openwisp/openwisp-monitoring/#signals

The standard django signals described in the Django documentation are also available (eg: post_save, post_delete, etc).

Those signals (events) can be listened to and code can be triggered to be executed when those events happen.

This allows you to program and extend what OpenWISP can do with logic that is tailored to your use case.

c) My changes could be applied as a patch on the released
openwisp-controller 1.0.3 [3],
yet I am unaware of where "development happens" and how features are
added to
OpenWISP in general.

Everything is explained in the Contributing guidelines.

d) How should I coordinate with OpenWISP?

We have a gitter chat focused on development.

Best regards

Federico Capoano