Author Topic: Future Request About Addons/Packages Versions (Read 11859 times)

FlashPan · « **on:** July 31, 2015, 10:20:09 am »

Hi all,

I was reading this thread about the possible design of making addons available to opnsense.

https://forum.opnsense.org/index.php?topic=13.0

As the thread was so old I though I'd start a new one here with I think a very valid suggestion. I'm not a programmer or package maintainer just your normal run of the mill Admin.

I think that opnsense should look into is to keeping previous verisions of packages to be available to install.

Sadly with pfsense if you upgrade a package and it kills your whole appliance or the package does not work as expected your are basically done. Their is no roll back facility to the previous package that most likely was still operational.

Additionally if you have not upgraded a package for whatever reason and you re-install or recover your appliance (or wish to roll out multiple appliances) with a backup config you are forced to download the latest package again.

Just my thoughts

Cheers

franco · « **Reply #1 on:** July 31, 2015, 11:47:13 am »

Hi FlashPan,

the packages/addons/extensions are going to be called plugins. Initial code is already online: https://github.com/opnsense/plugins

I see the requirement for keeping previous versions, but it's very hard to pull this off. Even the native FreeBSD package tool does not do this. Unless you upgrade, you won't even know it's broken. We can probably cache the old plugins, but only for a limited number of builds (2-3).

Are packages not fixed after they break? I don't understand this bit. Can you explain a little more here. I think if they break we fix them again and done.

Cheers,
Franco

FlashPan · « **Reply #2 on:** July 31, 2015, 12:03:09 pm »

Hi Franco,

Thanks for your speedy response. I understand it can be difficult and do not envy you guys for the work you put in etc but as an Admin I think of such scenarios

In part why I raised this request/question is that in some cases (not always) for example, you could have a pluggin Snort - Rev A installed and working fine, Rev B is released and you upgrade to that, find out its broken or "other issues" you then have to wait for the author the create/build Rev C - an unknown amount of time which could lead to a system critical feature not being available.

I was not suggesting that all revisions be kept or made available but I think that 2 or 3 seems like a good number anyhow for roll back purposes.

Again 1 reason why I suggested this is from this exact experience on a different platform after upgrading a package/addon/pluggin.

Cheers

franco · « **Reply #3 on:** July 31, 2015, 12:40:07 pm »

I think I understand what you are saying. We usually have release cycles of a week, I don't know how often package were updated in other projects?

Now, there's basically two user choices to this from my point of view:

(1) Either this breakage is caught early by individuals so they can revert to an older package on their own. The time window here is about two weeks, after that the old version may be purged from the mirror as we do snapshots of package mirrors, not versions of packages.

(2) Users come here and let us know what is wrong so we can fix (hopefully within a week), provide workarounds or provide older packages for manual install (with a day of delay or so). We can always rebuild older packages, but we'll need a heads up in order to provide proper support.

Cheers,
Franco

none · « **Reply #4 on:** August 10, 2015, 09:49:56 pm »

Hi Franco,

is there any guide to use packages/plugins on opnsense ?

if it is needed to have version 16, I can upgrade as well. This is a home net5501-70, I am trying to test a new options (opnsense) and I get it if it gets a bit unstable (can use other box to make sure it won't render my home unconnected).

Where I can start ?

So far I found a link to git

thanks, for the software and the help on forum

none

franco · « **Reply #5 on:** August 11, 2015, 08:27:49 am »

The progress is as follows: there is a plugins.git that has two plugins: a test plugin called "os-test" and a vmware plugin "os-vmware". Both of them are a proof of concept, but can be installed on a running system using, e.g.:

# pkg install os-test

To remove:

# pkg remove os-test

This is essentially all that is needed to build and deliver plugins already weaved into our release process. What is missing now is (ordered by time of delivery):

(a) a package manager GUI for easy install/remove/search
(b) a few hooks into the running GUI (e.g. menu generation)
(c) user submissions for plugins (user contributions are vital)

Groveld · « **Reply #6 on:** August 11, 2015, 12:35:13 pm »

Is it really a good idea to include packages/plugins just like pfSense?
I understand the probable need for a rollback option for integrated plugins, but to have the option to enable all kinds of plugins might break or slow your system considerably. I like the option to do so, but it will be risky without proper documentation. I like OPNsense over pfSense just for this reason alone, the build in plugins/options are being tested by developers (people who really know what they are doing) and only released when they think it's safe to use.
Yes, it's still a young project and mistakes will be made, but it's a sturdy platform and like this philosophy so far.

Pardon my rant

Groveld

franco · « **Reply #7 on:** August 11, 2015, 01:32:37 pm »

I think it is inevitable, not by mere fact of supporting feature richness, but also so that we can shrink image size again and split off unwanted services such as e.g. PPTP, or maybe even all VPN types.

There ought to be enough collaboration on the plugins with committers (OPNsense devs) and authors (outside contributors). There is an official repo, anything that will be good enough will go into that repo and is advertised/updated with each release. That also means when it's in we need to maintain the code and prevent breakage and review each change. There will be no "let's pull this plugin change in no matter what it does". It's true that plugins are from the community for the community, but that doesn't mean that we shouldn't take care of them and help to make them better.

The initial packages/plugins come from the base system and from us directly, yes, but mostly because of popular demand and lack of plugin infrastructure. Other projects are revamping their infrastructure as well now, so we have been on the right track with this all along. It just takes effort on our side to deliver the proper tools and care so that authors can step in and provide a rich plugin environment. And this is where we are now.

Groveld · « **Reply #8 on:** August 11, 2015, 01:39:00 pm »

Fair enough, i've never looked at it that way...
I know pfSense, which is packed with options and still has the option to add more. but to use it to make the base system lighter is kinda cool.
again, i'm not against the plugins thing,i just like secure systems

Keep up the good work!