Messages

Wird gefixt in 15.7.4. Hier ist der Fix, fall es lokal schneller benötigt wird:

https://github.com/opnsense/core/commit/a6f879fcdff23b40ea1546b8e0242bb7e1e225fe

Danke, schöne Studie. Von dem "Bus" hab ich auch immer mal gehört in den letzten Firmen. Immer äußerst drohend und oft Zitiert vom Management, aber da erzieht man eben seine Mannschaft zu einer selbstständigen Einheit in der jeder übernehmen kann und dann läuft das schon. ;)

Christian, unbound is in FreeBSD base nowadays. There was a move from dnsmasq to unbound in pfSense most likely due to that reason, but that transition hasn't been completed, at least not in our code base.

Bind is in there for a single purpose: Dynamic DNS via RFC 2136. As far as I know there is no replacement. We tried to use bind-tools as a lightweight package but the way the port is designed it conflicts with bind910 installations which some people have asked for as well.

We can add more dns into the packages, but I believe the pressing work is cleaning up the intermittent state of resolver and forwarder and maybe tackling the bind-tools vs full bind packages in FreeBSD.

@phoenix: thanks for all the reports over the past weeks. it has helped to drop the response time immensely.

@chol: no spam so far. the filter seems to work, so hopefully no extra (hard) captchas here any time.

So keep the fingers crossed. :)

Looks promising, thanks Ad! :)

Added tor and polipo, which will be available with 15.7.4 (this week maybe depending on the state of software security) for manual installation. Have fun.

https://github.com/opnsense/tools/commit/d4628b332ebe6266d9505f4b6087d87fd68eaa38

It's gotten worse with the spamming. So far our attempts (even banning) have been barely successful. We will look into it again (although captchas are a general nuisance for humans these days). If we only knew.... :/

Danke, hab's gleich al offiziellen Bug festgehalten: https://github.com/opnsense/core/issues/264

/etc/rc.conf modification or a drop-in file for /etc/rc.conf.d ought to be enough like you would configure it on FreeBSD, but was I said it sometimes does not work and does not take care of restart after upgrade and other assorted scenarios. Still trying to figure this out.

They always had a "fork" in their OpenBSD source repository, but that was more like what FreeBSD and others do as well and it had no name, no portable release. The release date for Heartbleed was April 7 [1]. The domain was registered on April 11, the project was announced on April 22 [2].

[1] https://en.wikipedia.org/wiki/Heartbleed
[2] https://en.wikipedia.org/wiki/LibreSSL

Thanks mate, I'll try to reproduce that.

I only help out the HardendBSD people with a few nitpicks and documentation improvements. So far they do an amazing job of their own. :)

We still have patches on top of FreeBSD but we'll get there. We have someone who converted his FreeBSD into an OPNsense by replacing base and kernel using our internal tools and it's working fine:

https://kram3r.wordpress.com/2015/07/09/opnsense-on-digitalocean-droplet/

The long run will be to simply switch your FreeBSD package repository and install opnsense and after reboot your system is up and running without further need to change the base/kernel. That'll give us the opportunity to move away from our own kernel builds and give broader support and a rich tool kit to turn OPNsense into whatever you can imagine (if you need more than what is there, that is).

That's what I wanted to do for 15.7 initially, only start with OpenSSL as that is the default and changing defaults only leads to trouble. ;)

A little history. 6 months ago we started to look into LibreSSL as a replacement, but found ourselves in a situation where:

(a) LibreSSL existed as a port, but using it as a drop-in replacement for OpenSSL from ports wasn't even remotely possible due to linker errors, old code using deprecated OpenSSL APIs that LibreSSL removed and so on and so forth, and

(b) pkgng was a few major iterations behind and not capable of coping with a seamless replacement of OpenSSL/LibreSSL as a package dependences, and

(c) a mix of both even though most of the work had already been done. ;)

We've helped clean up the fallout in FreeBSD ports along with Bernard Spil (thanks!) and some other interested/involved individuals. At some point we've had help from OpenBSD developers like Stuart Henderson and Loganaden Velvindron eventually easing OPNsense and thus FreeBSD into the idea of a good adoption of LibreSSL. PCBSD joined the venture, too. FreeBSD base not yet though.

We've worked through all of the issues at least for our own packages ecosystem and come 15.7 we've had a major bug in the dependencies/package linking that prevented us from deploying a one-image-fits all approach just then. With 15.7.1 that changed, but was too late for the images for obvious reasons. In one of the next couple of stable releases, we'll have said switch in the GUI as we further improve the firmware bits and pieces.

With all these changes, it's better to let things simmer beneath the GUI for a bit until we're completely confident it can be shipped as a standard feature. It's easy to tell somebody to run a command line to try a feature and fix it with him, but a button in the GUI is a lot harder to debug and users who see the button doesn't work are simply conditioned to think we have a flaky product. It's a lot harder to get support/bug repots in this case.

All in all, we're almost there now. It's been a great adventure. :)

Not all packages from the repository are installed by default. You can query the remote by:

# pkg rquery "%n: %c"

You'll notice sixxs-aiccu is already there waiting to be installed. :)

And, yes, you can configure /etc/rc.conf, but you'll have to run "service xxx start" manually for now. We have an automatic hook, but it needs to be replaced as it is not working very well, e.g. with open-vm-tools(-nox11).

Hi wild045,

I will take care of the packages requests soon: https://github.com/opnsense/tools/issues/12

As far as pkg and our new plugin infrastructure (what pfSense calls packages essentially) goes one doesn't need to care about pkg at all as the plugin build framework wraps everything already. What is barely working is the plugin plugin into the running system. It works by manually reloading the web server, typing the URL in the browser, but we want to have a dynamic menu and backend service as well to make sure the plugins deserve their name.

If anybody wonders why plugins are not named packages, well, FreeBSD already has designated terms for ports and packages and everything is already packaged in OPNsense (except base/kernel) so we thought plugins would be a more fitting term. Also, alliterations are neat. :)


Cheers,
Franco