Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.

2020-06-14 Thread Kevin Chadwick
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.

2020-06-14 Thread Kevin Chadwick
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

2020-06-14 Thread Strahil Nikolov
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



unsubscribe

2020-06-14 Thread Agris Pudāns