Add-Ons/Plugins/Packages

[fraenki]

Hi,

just installed OPNsense and made a few tests. Looks very promising and I really hope this project will attract many more people.

I've got a question regarding Add-Ons/Packages, because I've noticed that the item "Packages" is missing from OPNsense' menu. Packages in pfSense are a great way to enhance functionality and make it possible to even add new components to the WebGUI.

Do you plan to offer a similar Plugin/Add-On functionality? I'd love to contribute a Plugin or two. ;-)


Thanks
- Frank

[jschellevis]

Yes, we are certainly planning on adding a packaging system. That is to say our current firmware upgrade system makes use of pkg as opnsense is now a standard pkg package as well :-) This functionality will extended to be able to add new features this way as well.. currently the core team is discussing the best way to do this.
 

[fraenki]

Yes, we are certainly planning on adding a packaging system. That is to say our current firmware upgrade system makes use of pkg as opnsense is now a standard pkg package as well :-) This functionality will extended to be able to add new features this way as well.. currently the core team is discussing the best way to do this.

Great to hear this! Pkg is certainly the way to go for packaging.

I need to admit that I like the simplistic approach pfSense is using for their Add-On system: combining standard pkg packages with pfSense-specific Add-Ons – meaning that you can use any unmodified pkg package to build an Add-On on top of that. (I'm knowingly ignoring that PBI ever existed.)

Oh, and talking about pfSense... maybe it's a good idea to start with both a "official/stable" and a "community/unstable" repository for Add-Ons...


Regards
- Frank

[jschellevis]

Great to hear this! Pkg is certainly the way to go for packaging.

I need to admit that I like the simplistic approach pfSense is using for their Add-On system: combining standard pkg packages with pfSense-specific Add-Ons – meaning that you can use any unmodified pkg package to build an Add-On on top of that. (I'm knowingly ignoring that PBI ever existed.)

Oh, and talking about pfSense... maybe it's a good idea to start with both a "official/stable" and a "community/unstable" repository for Add-Ons...

Thanks for your suggestions!

It should be possible to have standard pkg packages with addons by just using the dependency system for that and have the standard package installed as dependency for you new package. Or am I missing the point here?

As for stable/unstable repositories I know we have a repository for testing.. something similar would be great for community/unstable packages as well.. when they become 'official' we can incorporate them into the 'official' pkg repository.

[fraenki]

It should be possible to have standard pkg packages with addons by just using the dependency system for that and have the standard package installed as dependency for you new package. Or am I missing the point here?

Let me see if I get this right... to create a addon for OPNsense one would need to do the following:

- create a new pkg package (or FreeBSD port, i.a. sysutils/opnsense-addon-xy)
- add required OPNsense-specific files (additional GUI components, configuration files, etc.)
- add package opnsense-x.y.z as a dependency (to define which version is compatible with this addon)
- add any required pkg package as dependency

Is this what you are suggesting? I like this approach, it's very straight and simple. Though I assume there is a reason why other addon systems a far more complex (pfSense, FreeNAS).


Regards
- Frank

[jschellevis]

That is precisely what I am suggesting.. but we still need to work out the details.
To quote Einstein: Everything should be made as simple as possible, but not simpler. So hopefully we can do it this way... but first things first :-)

[franco]

We typically use ports.git/opnsense/xyz for custom ports. For plugins, we may want a little prefix for the package like "opns-" to indicate "doesn't work without the other thingy". Other than that you are right: add ports dependencies to third party tools you want to run, and the custom code to drop into the GUI base. It'll get a little harder when there is an API server, but security issues are more important than ease of integration in the long run. I don't think you need a specific dependency on the "opnsense" package. If the code is not there, then nothing bad happens. The main package is also not in the ports tree so asking for that dependency is asking for trouble maybe. I don't know yet.

If you have useful plugins that don't bloat the default image we can consider cutting out the plugin foo and move then directly to the core. We are cool with that if you are. Plugins are coming back mid-term anyway though. It would be a way to bridge the gap like we do for IPS and proxy.

[muahdib]

I definitely would LOVE to see a standardised scheme of package state.

in pfSense you have Alpha, Beta, Release, Stable, ... It is really not clear what means what and also depends on the package itself.

I would like to just see two options:

Experimental
Stable

And Stable should be chosen ... well, I do not really know, but community consensus? If X people mark an experimental as stable? I don't trust the package developer 100% if (s)he says it's stable, maybe a status of stable from the developer + community consensus? ...

Best
Ray

[franco]

We want to have two kinds of packages:

* officially verified packages that are known to the OPNsense installation and can be installed with a click in the GUI (the term stable applies here)
* unofficial packages that can be used, but must be installed manually (or must set up a private mirror) so that e.g. internal plugins can be used too

The approaches only differ in the visibility, but certainly officially verified packages are the ones the community regards as stable and useful, maybe decided through forum or mailing list discussions. The very good ones may also be part of the standard installation if the authors agree to such requests.