Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14 13:58, Kevin Chadwick wrote: > 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? To be clear. Previously, with scrub (no-df... the set reassemble line was missing/default.
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
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. However, Is sync or softdep a better default for the best chance of avoiding manual fsck/support issues? 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? Any thoughts or links on the most secure pf.conf that remains being compatible with any network? Thank You
Re: OpenBSD Readonly File System
In Linux, the kernel can force flushing the disk cache (which also can be disabled ) via fsync() call . That feature is called 'write barrier'. As I'm not a developer, I never read that portion of the source of openBSD , so I got no idea if similar logic can be used in openBSD. Does 'softdep' represents the behaviour of 'write barriers' in Linux ? Best Regards, Strahil Nikolov На 13 юни 2020 г. 19:56:18 GMT+03:00, "Todd C. Miller" написа: >On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote: > >> On 2020-06-11 12:07, Strahil Nikolov wrote: >> > I always thought that 'sync' mount option is enough to avoid >> > corruption of the FS. Am I just "fooling" myself ? >> >> As "sync" is the default...yes, I think you are. > >Actually, by default only metadata is written synchronously. The >"sync" mount option causes data to be written synchronously too. >Of course, the disk *itself* has a cache so even with synchronous >writes you can't be sure the data has actually made it to the platter. > >So yes, I agree that sync mounts are not really enough to help here. >You are probably correct that softdep is better for this kind of >thing since it does a better job of keeping the filesystem in a >consistent state, at the cost of missing data when there is an >unclean shutdown. In theory, the on-device cache can still cause >issues when you lose power though. > > - todd
