Congrats on 17.7

[CloudHoppingFlowerChild]

I'm sure it's all in my head, but I could swear my router is more responsive. Everything feels faster.

[franco]

Hi there,

The last speedup the GUI received was for a larger number of interfaces (e.g. VLANs), it was in 17.1.10. Maybe that's what you're seeing?


Thanks!
Franco

[theq86]

Yes, 17.7 upgrade was mostly flawless and runs stable.

The only thing that nagged me today was that dyndns is now a plugin.

Maybe, if you plan to move out some more features the upgrade routine should check, if the feature is being used currently and install the plugin during upgrade.

[monstermania]

The only thing that nagged me today was that dyndns is now a plugin.

I also use DynDns on my 17.1.x.
Are all DynDns-Settings gone after update to 17.7.x (i.e. Custom DynDns-Settings, Cron Job)!?
Do you have to manually re-enter dynds settings or are the settings useable again after you've installed the DynDns-Plugin?

Cheers
Dirk

[franco]

The settings are retained in the config.xml, it just needs the plugin.

We've been talking about how to handle these types of situations where plugins are missing, but they seem to be configured. It is a chicken-egg issue.

One thing we still want to add is a register of previously installed plugins (actively from the plugin tab). This way, we could simply say "hello, your config says you use plugins x, y and z, but they are not installed".

But the former only works of we ever had a plugin installed. We don't want to force anyone to install plugins automatically, we don't want to depend on them being automagically added.

What we may do is put os-dyndns back into the installer, depending on feedback, so it remains a plugin, but can be removed if not needed. But this, also, doesn't account for the upgrade case.

Not sure what else can be done to ease this situation during a clean upgrade. What do you guys think?

[monstermania]

@Franco
Thank you for clarification.

Hmm,
currently i see a big problem if someone make the update to 17.7.x by remote (and have no static ip like me) 
After the reboot there is no possibility to access the OPNsene by remote.
Maybe it is better to put back dyndns to installer (IMHO).

best regards
Dirk

[franco]

While putting the plugin to the images that won't solve the upgrade issue.

During the major upgrade all packages (including plugins) are downloaded so it could be installed, but somehow we need to pass the hint, preferably in a way that the user can decide what to do.

I can't speak for remote updates. They are always tricky. In retrospect, we should have mentioned the plugin change for DynDNS and RFC2136, it was in the 17.7.r1 but not in the 17.7 announcement. I'm fixing this so that the changelog message in the GUI is more clear.

https://github.com/opnsense/changelog/commit/f33a8a1

The change will be online in a few minutes.


Cheers,
Franco

[theq86]

What, if you would save the list of installed plugins in the configuration? Then you would know which plugins where installed previously.

For core functions which are moved to plugins you could add a query dialog into the firmware upgrade function.
You click upgrade, then you get the release notes and afterwards you tell the user which core functions will be inside plugins on the new release. The user now checks the box which plugin he wants to get installed automatically.

[franco]

The first suggestion is already planned: https://github.com/opnsense/core/issues/1663

The second one was something that seems reasonable, the tricky part remembering how to tell the upgrade that plugins are spit from the core and remembering to install them when a user selected them. I'll note this in the ticket, thanks!

[Vincent]

Hello,

For the last suggestion, a less complex way could be to automatically install on the first version a feature is moved into plugin.
And adding in release notes that those modules can be removed if useless after the upgrade.
That way it get smooth for the upgrade, don't requires tricky dialog to add, and lets the user remove unneeded things if documented in the release note

Cheers,
Vinceynt

[epoch]

I though I'd piggy-back here because the thread title is right.

I recently installed and setup 17.7 regular on an APU2, and 17.7 nano on an Alix2d3.
They look and perform absolutely great (give the Alix a full five minutes to boot but then you'll see.)

OPNsense is really a superb platform.
And when you'll have a pink-themed rpi distro, it will also be more lovely than m0n0 ever was in its days

Thank you very much for OPNsense. I wish you all continued success.

[FrenchFries]

I would like to join too and thank you for OPN Sense.

I stopped using pfSense (Registered) years ago when I asked them to show me the compilation toolchain and it was only reserved for 'partners'', i.e. nobody. So I became very pessimistic on the way pfSense (Registered) was built and if it included only pfSense (Regsitered). Now, they provide a toolchain, but it did not use to be the case.

When pronouncing pfSense, now I always write "Registered", because otherwize a lawyer mlight write me a letter (I received one few years ago). So I am happy to simply say "OPNSense".

So I went back to iptables on GNU/Linux (using fwBuilder and shell scripts) and then migrated to LEDE (absolutely gorgeous), before I jumped in FreeBSD and became addict.

OPNSense is abolutely fantastic : nice design, good FreeBSD/Hardened FreeBSD base, nice team, nice reputation.

Now I would like to study internals and do what I can in my spare time.

Keep on the good things:

French Fries

[franco]

Hi FrenchFries,

The disappearance of the build chain in 2014 is why OPNsense exists, and thusly forced pfSense to re-release their build chain in 2015 (and subsequently change the ESF licensing into Apache 2.0). Now it's 2017, several people note that pfSense -- or "nonSense" how the owners themselves call their build chain tool product because of trademark restrictions you mention -- doesn't build even with the provided tools. It's a strange open source world out there.


Cheers,
Franco

[FrenchFries]

This toolchain issue is very annoying, probably more than trademark, because it makes a lot of people suspicious about pfSense.

Personally, this is the reason why I stopped distributing appliances, I could not trust content and selling them became "morally" impossible. I don't want to imply that pfSense (trademark) has backdoors or zero days leaks, but this is what a lot of people believe and I preferred to stop thinking about it and quit the ecosystem. Now that they design their own hardware, I don't even want to think about it. This is not only pfSense acting like that, but a whole IT industry. Security through obscurity.

I hope that OPNSense can become build reproducible and will never behave like that.

[franco]

... but a whole IT industry. Security through obscurity.

It's true, we are witnessing a transformation of a legendary open source project into a normal commercial product. The timing is slow motion, but one could see that start happening 4 years ago. This change is hard to witness in the moment and was always downplayed, but the last years with multiple relicensing efforts almost going full circle have made it clearer.

I hope that OPNSense can become build reproducible and will never behave like that.

I challenge you to try the build. The only thing we don't publish are our signing keys... for obvious reasons.

There is a sporadic "can't build OPNsense, help" thread, but that is mostly due to kernel sources, ports and our code going out of sync every once in a while, it happens with all projects. Subsequently, such reports have improved the build further, "make update" is one of these additions that nowadays fetches and checks out the correct repositories. The documentation is also provided in full....

https://github.com/opnsense/tools#about-the-opnsense-tools


Cheers,
Franco