Ubound

[Qinn]

Hi there I guess this Q has been asked, so if I get a RTFF I understand  . Is there a particularly reason why dnsmasq (forwarder) service is still default, instead of ubound (resolver)?

[franco]

It's the legacy default. At some point in pfSense development (should be 2.2) the unbound package was moved to the base installation as an alternative or maybe as an attempt to switch, I cannot remember exactly. I just know there's still both now in 2.3 and likely 2.4.

The two main reasons we haven't switched over is (a) increased complexity and (b) problems with the integration at the point when we forked in late 2014, because it was not fully done.

Switching to unbound as the default and removing dnsmasq could be an approach, though thinking about it now another may be to remove unbound from the base installation again and only deliver it as a plugin as we've vowed long ago to make the system more flexible in terms of configuration-

Dnsmasq is still a good choice for the majority of SOHO and a fair share of SMB, so that the following could apply: "don't fix something that isn't broken".


Cheers,
Franco

[Qinn]

It's the legacy default. At some point in pfSense development (should be 2.2) the unbound package was moved to the base installation as an alternative or maybe as an attempt to switch, I cannot remember exactly. I just know there's still both now in 2.3 and likely 2.4.

The two main reasons we haven't switched over is (a) increased complexity and (b) problems with the integration at the point when we forked in late 2014, because it was not fully done.

Switching to unbound as the default and removing dnsmasq could be an approach, though thinking about it now another may be to remove unbound from the base installation again and only deliver it as a plugin as we've vowed long ago to make the system more flexible in terms of configuration-

Dnsmasq is still a good choice for the majority of SOHO and a fair share of SMB, so that the following could apply: "don't fix something that isn't broken".


Cheers,
Franco

Thanks for the lengthy explanation. I agree wholeheartedly (not that it matters ) not to move over to unbound (yet), I had my fair share of problems when I moved over when using pfsense 2.3.1.

In my private setup (pfsense) I even decided to move to t1n1wall (fork of M0n0wall) as of the problems I encountered with pfsense, but I don't want to bash them, for many it's a really good product. Now both setup's are on OPNsense and they are running stable for a few weeks, fingers crossed

Although my credo is "do one thing and do it well (Unix)", in my private setup I can take some more risk than in business, so is it possible to install the package pfblockerNG on OPNsense or should I stay away from it?

[franco]

You're right about the unix approach. It seems we are at an impasse regarding ways to go forward using those two principles, but that just means we'll have to put in more work to get to see the path we're going to take. Like the good Theo de Raadt likes to say "let's give [the code] some slack".

Unbound has gradually improved and is now at the heart of BSD itself. Same is true for us with some more tickets queued up for 17.1. What we really need (and thought we had at a point) was a maintainer of DNS code within OPNsense who can bring it to the next level. There was a contributor named Manuel Faux who pushed amazing cleanups about 6 months ago.

Manuel, if you read this, we want you back.

So, anyway, nice to hear your setups run ok, hopefully also with 16.7 that is just around the corner. Discussions like these are truly invaluable and essential for the future of OPNsense. Let's keep this going, please!


Cheers,
Franco

[Qinn]

You're right about the unix approach. It seems we are at an impasse regarding ways to go forward using those two principles, but that just means we'll have to put in more work to get to see the path we're going to take. Like the good Theo de Raadt likes to say "let's give [the code] some slack".

Unbound has gradually improved and is now at the heart of BSD itself. Same is true for us with some more tickets queued up for 17.1. What we really need (and thought we had at a point) was a maintainer of DNS code within OPNsense who can bring it to the next level. There was a contributor named Manuel Faux who pushed amazing cleanups about 6 months ago.

Manuel, if you read this, we want you back.

So, anyway, nice to hear your setups run ok, hopefully also with 16.7 that is just around the corner. Discussions like these are truly invaluable and essential for the future of OPNsense. Let's keep this going, please!


Cheers,
Franco

I agree it's a slippery slope, once you start introducing (third party) app's, how can you guarantee safety which is the core and second stability will certainly drop (as I experienced with pfsense) you'll only need one lemon.
So it's a pickle, no doubt about it, I wish you every wisdom making the right choices. 

With another setup I had a Fatal trap 12: page fault while in kernel mode, this error was only shown at the console window and there was no reboot. When I rebooted there was no error message on the dashboard (might be a nice add).

As I was convinced it was a RAM module, I forgot to look for an error log. After I replaced the RAM module, which I thought was flaky, I looked for the crash log (good management suggests it had to be the other way around  ) in  /var/crash , but there was none (anymore), might there be another location?

Btw hope all goes well with the roll out on 28-07 fingers crossed .

[franco]

Hi Qinn,

Crash dump configuration is done early during the rc phase, meaning multi-boot. This includes setting the swap partition as the place to store a crash and rebooting directly after hitting the panic to avoid the box hanging there waiting for user input. This can fail:

(a) when there are no swap partitions there can be no kernel crash reports on the next reboot, but the automatic reboot will be there.

(b) when the boot stage didn't reach the setup code in the rc phase, e.g. during kernel boot before mounting the root file system.

In the latter case there is not lot to be donesince the system isn't ready to be configured and since your device didn't reboot maybe it was that? Or was the device in full operation / had an uptime of more than a minute?


Cheers,
Franco

[Qinn]

Hi Qinn,

Crash dump configuration is done early during the rc phase, meaning multi-boot. This includes setting the swap partition as the place to store a crash and rebooting directly after hitting the panic to avoid the box hanging there waiting for user input. This can fail:

(a) when there are no swap partitions there can be no kernel crash reports on the next reboot, but the automatic reboot will be there.

(b) when the boot stage didn't reach the setup code in the rc phase, e.g. during kernel boot before mounting the root file system.

In the latter case there is not lot to be donesince the system isn't ready to be configured and since your device didn't reboot maybe it was that? Or was the device in full operation / had an uptime of more than a minute?


Cheers,
Franco

So by choosing the default installation settings there is no swap created? I did a swapinfo and it gave

root@OPNsense:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity

so it seems there is none. As you refer to the bootstage I realize I may not have been clear about the occurrence of this error. This fault happend after booting was complete, so OPNsense was running fully. After a while I looked  at the console screen and noticed the eror Fatal trap 12: page fault while in kernel mode  so I hit the reset (hard so on the machine) and then replaced the flaky RAM module. I then realized that I didn't  take a look at any error log and I started looking for a log that might contain this error , but found none. I hoped it would be in /var/crash , but apart from the default minfree file it was empty, so I hoped anyone could point me to a log that might contain such an error => Fatal trap 12: page fault while in kernel mode

[franco]

Swap is omitted in the installer for install targets < 30GB. This was done to lighten the wear of flash-based storage, avoid allocating a large percentage of the target media and to not ask too many questions during the guided installation.

We've tried swap files instead, but they cannot be used as crash dump devices.

Still odd that it did not reboot properly. Did the crash ever occur again? I'm afraid there's no info to gather from the crash. Having "minfree" in the /var/crash directory also means that you've never seen a crash report in the GUI. :/

[Qinn]

Swap is omitted in the installer for install targets < 30GB. This was done to lighten the wear of flash-based storage, avoid allocating a large percentage of the target media and to not ask too many questions during the guided installation.

We've tried swap files instead, but they cannot be used as crash dump devices.

Still odd that it did not reboot properly. Did the crash ever occur again? I'm afraid there's no info to gather from the crash. Having "minfree" in the /var/crash directory also means that you've never seen a crash report in the GUI. :/

So if there is a next time (for now it seems probable that the DDR module was flaky, Uptime is growing steadily ) I should check /var/crash before there is a reboot?


Checked with root@OPNsense:~ # egrep 'ada0' /var/run/dmesg.boot
ada0 at ata0 bus 0 scbus2 target 0 lun 0
ada0: <KingSpec KDM-40VS.2-032GMS 20140803> ACS-2 ATA device
ada0: Serial Number 986031400067
ada0: 100.000MB/s transfers (UDMA5, PIO 512bytes)
ada0: 30458MB (62377984 512 byte sectors)
ada0: Previously was known as ad0

Seems I am just outta luck with a SDD on IDE of 30458MB  Just out of curiosity, why the line at 30GB when only 3% is used by the system?

root@OPNsense:~ # df -h
Filesystem                   Size    Used   Avail Capacity  Mounted on
/dev/ufs/OPNsense     29G    934M    26G       3%    /
devfs                          1.0K      1.0K      0B    100%   /dev
devfs                          1.0K      1.0K      0B    100%   /var/dhcpd/dev

[franco]

/var/crash is only filled after reboot because at the time of the crash the system cannot push to the file system anymore (in case the file system itself crashed). If it can gather a report, it'll be there when it's back up. Otherwise a screen cap of any sort would be helpful.

The line between large SD cards and SSDs is blurry, especially with PC Engines pushing 16 GB MSATA. I also remember the swap calculation can be excessive, factoring in the RAM. It's in the code, wanting to be fixed. In fact, a lot still is which is why we'll do another bsdinstaller iteration for 17.1.

Well, we can lower the standard to 25GB? It needs more intelligence for sure or a question, but that makes the install more and more lengthy. Anyone else with an opinion on this? I don't mind alternatives, but we'll have to act fast to get it into the 16.7 installer media (today!).

But remember, it's only the kernel crashes that won't be able to show up. Devices run fine without swap.


Cheers,
Franco

[franco]

PS: I guess 18 GB would also work. Below is the code logic...

https://github.com/opnsense/ports/blob/master/opnsense/bsdinstaller/files/installer/conf/Product.lua#L13-L30

[Qinn]

The line between large SD cards and SSDs is blurry, especially with PC Engines pushing 16 GB MSATA. I also remember the swap calculation can be excessive, factoring in the RAM. It's in the code, wanting to be fixed. In fact, a lot still is which is why we'll do another bsdinstaller iteration for 17.1.

Cheers,
Franco

Do you suggest I step over to the nano version? (btw I use and SSD 32 GB on the IDE connector)

[Qinn]

Well, we can lower the standard to 25GB? It needs more intelligence for sure or a question, but that makes the install more and more lengthy. Anyone else with an opinion on this? I don't mind alternatives, but we'll have to act fast to get it into the 16.7 installer media (today!).

But remember, it's only the kernel crashes that won't be able to show up. Devices run fine without swap.


Cheers,
Franco

If you'll ask me, I would say Yes.

[Qinn]

PS: I guess 18 GB would also work. Below is the code logic...

https://github.com/opnsense/ports/blob/master/opnsense/bsdinstaller/files/installer/conf/Product.lua#L13-L30

Please bear in mind I am not a programmer by profession and haven't looked at all the code , so I am very well wrong, but something in the code does not seem logical to me:

...or part_cap < 4096

 
part_cap can't be smaller than 4096, when in the first part of the Call it's ruled out that part_cap is smaller then 30720?

if part_cap < 30720 then
return {

[franco]

You're right. I've added the first if later. It's not a bug, though an unreachable conditions. I can mop this up for the final image.

Though the question still stands... what should be the threshold for using swap?


Cheers,
Franco