On 2020-06-14, Kevin Chadwick <m8il1i...@gmail.com> wrote: > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades.
You'll need to cope with /usr for upgrades too, OpenBSD breaks binary compatibility fairly often (mostly system call changes - at a guess roughly every 2-3 releases - and some other things like the arm and aarch64 abi change last autumn). You can't expect an old kernel to work with new userland and vice-versa. > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Probably softdep, but it brings its own issues. Transient storage io faults (disk slow to respond) which might correct themselves without softdep often cause the machine to crash with softdep, and it has to store the filesystem changes in memory before it writes them out, which can be a problem if memory is already tight. > Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by > switching to 3g was somehow, a short lived reprieve and was more to do with > re-assembly settings that had worked for me flawlessly, for years on a > landline. > > I believe scrub had no-df before and I am now using without issue, so far. > > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? If you have mixed MTUs (e.g. forwarding packets from an ethernet interface over some ppp/vpn/encapsulated links which can't handle 1500 byte packets) then for some traffic (connecting to sites with broken firewalls that block all ICMP) you may need no-df on the scrub rule. >From the description in pf.conf(5) no-df on "set reassemble" is something else, can't say I've ever needed to use that. > Any thoughts or links on the most secure pf.conf that remains being compatible > with any network? "block" :)
