OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: Steve++ on January 01, 2017, 12:05:12 pm
-
Hi OpnSense team,
based on the information I have read about OPNsense version 17
I would like to suggest few features which could potentially improve
very good open source security appliance.
Versioning support:
- use git to maintain versioning of configuration stuff (if not used)
* ability to store changes after every apply/commit via GUI || CLI
* ability to revert every change when needed and export config backups as Git repository
* ability to synchronize members of HA cluster
* ability to track related changes where/when/who needed
- ability to see OPNSense git hash within version string (usefull for investigation purposes)
IP routing daemon support:
- add Bird (IPv4 & IPv6) as default IP routing package if possible
Native dual-stack support:
- make sure about dual-stack capabilities across all the components within OPNsense (IPv4 & IPv6)
Any feedback is highly appreciated in advance.
Thank you for your time and involvements.
Steve++
-
IP routing daemon support:
- add Bird (IPv4 & IPv6) as default IP routing package if possible
You can use this package: https://docs.opnsense.org/manual/how-tos/quagga.html
Native dual-stack support:
- make sure about dual-stack capabilities across all the components within OPNsense (IPv4 & IPv6)
You shoud create a ticket for components which are not ready for IPv6 or dual stack on GitHub.
So it is possible to fix the issue.
-
Hi Steve++,
Thanks for these suggestions! Git as a versioning system was discussed every now and then, dating back all the way back to 2013, but the truth is git itself is too heavy for this task and you can already do the following:
Save backups of older config.xmls in /conf/backup.
Diff backups against each other or the latest config under /conf/config.xml.
Since everything is in config.xml there is no need for tracking more than one file and every page saves its own changes so you also have an audit trail.
The config.xml format isn't perfect, but short of replacing it with a database backend there is not really much to be gained in changing anything here.
The benefit of git was, as far as I remember, you could do central management of different boxes using branches and have a slightly more favourable audit trail, but one would also need to deserialise the config.xml into individual files/directories to make more sense of the changes.
Not strictly against work here, but the question is: what is the use case that is not possible in the current system?
Happy new year,
Franco
-
Hi Franco & Fabian,
thank you for straighforward feedback from your side.
Versioning question:
Franco, based on your message it means that user should take care about creating backups of configuration files for potential reverts at their own. Am I right ?
Thank you for providing additional clarification.
Steve++