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 
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 

> 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" :)

Reply via email to