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
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
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
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. :/
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
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
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
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