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 <https://openwrt.org/docs/guide-developer/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 <https://openwisp.org/demo.html>, the template URL is https://demo.openwisp.io/admin/config/template/45bacea6-661e-40af-b047-4ea5ae48c95a/change/ (to access this see demo system instructions <https://openwisp.org/demo.html>). 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 <https://openwisp.io/docs/developer/contributing.html>. d) How should I coordinate with OpenWISP? We have a gitter chat focused on development <https://gitter.im/openwisp/development>. Best regards Federico Capoano -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/openwisp/CAAGgX6KLKpn1YzUxWd%2BZiVVwdG51cwm%2BRVCyiSMjq8rciW%2BJ8Q%40mail.gmail.com.
