Can't find the latest images

[interfaSys]

I'm looking for images of 15.7.24 and 16.1

On this page:
https://wiki.opnsense.org/index.php/Software_setup

* SourceForge is down (not your problem)
* US mirror 1 redirects to /releases which only contains 15.7.11 and 15.7.18
* US mirror 2 is down
* EU mirror 1 lands in / and in /releases, there are the same releases as the other mirrors
* EU mirror 2 redirects to /releases which only contains 15.7.11 and 15.7.18
* https://pkg.opnsense.org lands in / and there are no latest image
* Nothing on Github afaict
* https://opnsense.org/download contains 15.7.18

It may be that we need to install 15.7.18 and update, but there is no indication of that anywhere in the documentation.

So how are we supposed to install OPNsense?

On the same page, there is also a note about LibreSSL 15.1.9, but I'm guessing we're way past that and it can be removed.

The link to the HardenedBSD snapshots is 404

[franco]

You're absolutely right. I promised to add a README to the mirror, which I've just done:

https://pkg.opnsense.org/releases/15.7.18/README

(Feel free to recommend updates and clarifications, I'll gladly weave them into the document.)

The wiki page is unmaintained unfortunately. The download page on the website is being kept up to date:

https://opnsense.org/download/

The last available HardenedBSD snapshot is available from the snapshot directory:

https://pkg.opnsense.org/snapshots/

Does that help?

[interfaSys]

OK. I think it would be good to update the wiki for 16.1, to at least explain the way releases work.

Hopefully, newer packages are automatically downloaded before starting the configuration process, like on some Linux distros.

[franco]

All available upgrades are fetched and applied in a single step, yes. But building ports manually may confuse dependency chains and can cause an installation to collapse. Package locking is a good idea for manual port build packages, you can do so from the GUI since 15.7.24.

[interfaSys]

I just saw that locking feature. What is it using underneath to protect the packages?

[franco]

It's FreeBSD's pkg native mechanism to prevent packages from being modified (or worse: removed).

https://www.freebsd.org/cgi/man.cgi?query=pkg-lock&sektion=8&n=1

[interfaSys]

Thanks. I'll need to do some tests. Last time I investigated there were some issues when compiling from source:
https://github.com/freebsd/pkg/issues/1000

[franco]

The pkg maintainers are very conservative about supporting mixed configurations between packages and ports. Their reason is unknown scope and increasing complexity, and it's very true. They try to hold the project together.

I've had a few discussions for small fixes (to me) which were brute hacks for them with said perspective.

It all boils down to: we can't have the same package installed multiple (in whatever configuration, dependency chain, etc.) times because it's already installed. Clashing files prevents this. PBI tried to solve this but failed for assorted reasons.

pkg lock works most of the time (bugs make it ignore the lock), and you'll have to make sure to lock recursively, it's been known to e.g. upgrade the PHP version when the default version changes and your original package stops working.

We've always tried to stay as close to FreeBSD ports as possible to be able to reuse FreeBSD packages. Unfortunately, OpenSSL/LibreSSL from ports gets in the way as all ports are currently being built against the FreeBSD base version. There is chatter to change that which would be a step forward, but then we'd also have to support the second crypto flavour there, which causes package duplication in the repositories.

pkg is really good and the crew did an amazing job, yet there's enough to do for the next years to come. Let's give them some slack and let them do their work even if it takes a while longer.

[interfaSys]

Thanks. I'll see if I ever need to compile everything from source, but that would probably mean adding a compile box to do it because I don't fancy compiling the gcc toolchain on the router itself.

[franco]

The native (clang) toolchain is already there. It's been this way since we released 15.1.