Re: OpenBSD Readonly File System

2020-12-18 Thread Kostya Berger
Hey, I read that message about Freeradius not being able to access /dev/null in 
a setup where /dev is mounted on an mfs -based filesystem.I'm running similar 
setup (for years now) - OpenBSD on a USB stick. EVERYTHING is mounted 
read-only, except /var, /tmp, /dev and /jails, which are mfs - based.
Now what I've noticed in particular about /dev is this: for this mfs-based /dev 
to work I HAD TO leave the initial /dev directory populated with dev files just 
as it was from the installation. Or else, run MAKEDEV in there -- but make sure 
it is filled with devices with original permissions etc. 
When I tried to mount mfs over EMPTY /dev directory, the resulting devices were 
not accessible.
The same proved true about /var. So in order to install packages, I had to 
remount /usr /var read-write, then install && remount ro. Otherwise it won't 
work.

Hope that helps

With kindest regards,
Kostya Berger
 


Re: OpenBSD Readonly File System

2020-07-11 Thread Strahil Nikolov
And if the FS is mounted rw, do you have the issue ?

Best Regards,
Strahil Nikolov

На 11 юли 2020 г. 10:22:53 GMT+03:00, Vertigo Altair  
написа:
>  Hello Again,
>I followed Stuart's recommendations,
>
>in fstab, / has read-write permissions;
>also, I mounted /dev as ramdisk,  ( I executed "MAKEDEV all" in
>/dev_src
>directory for once)
>
>vertigo# cat /etc/fstab
>5e045fec2af2ab03.b none swap sw
>5e045fec2af2ab03.a / ffs rw 1 1
>  5e045fec2af2ab03.e /mydir ffs rw 1 1
>5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2
>swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0
>
>and I'm updating / as readonly in rc.local;
>
>vertigo# cat /etc/rc.local
>mount -fur /
>
>Everything is OK right now. However, when I try to run radiusd, I'm
>getting
>"failed to opening /dev/null: permission denied" error.
>All configs, and files related with radiusd are in read-write /mydir
>directory.
>I tried to change the permission for /dev/ as 776 and /dev/null as 777
>but
>this didn't work.
>
>vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb
>FreeRADIUS Version 3.0.21
>Copyright (C) 1999-2019 The FreeRADIUS server project and contributors
>There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>PARTICULAR PURPOSE
>You may redistribute copies of FreeRADIUS under the terms of the
>GNU General Public License
>For more information about these matters, see the file named COPYRIGHT
>Starting - reading configuration files ...
>including dictionary file /usr/local/share/freeradius/dictionary
>including dictionary file /usr/local/share/freeradius/dictionary.dhcp
>including dictionary file /usr/local/share/freeradius/dictionary.vqp
>including dictionary file /mydir/etc/raddb/dictionary
>including configuration file /mydir/etc/raddb/radiusd.conf
>including configuration file /mydir/etc/raddb/proxy.conf
>including configuration file /mydir/etc/raddb/clients.conf
>including files in directory /mydir/etc/raddb/mods-enabled/
>including configuration file /mydir/etc/raddb/mods-enabled/always
>including configuration file /mydir/etc/raddb/mods-enabled/attr_filter
>including configuration file /mydir/etc/raddb/mods-enabled/cache_eap
>including configuration file /mydir/etc/raddb/mods-enabled/chap
>including configuration file /mydir/etc/raddb/mods-enabled/date
>including configuration file /mydir/etc/raddb/mods-enabled/detail
>including configuration file /mydir/etc/raddb/mods-enabled/detail.log
>including configuration file /mydir/etc/raddb/mods-enabled/digest
>including configuration file
>/mydir/etc/raddb/mods-enabled/dynamic_clients
>including configuration file /mydir/etc/raddb/mods-enabled/eap
>including configuration file /mydir/etc/raddb/mods-enabled/echo
>including configuration file /mydir/etc/raddb/mods-enabled/exec
>including configuration file /mydir/etc/raddb/mods-enabled/expiration
>including configuration file /mydir/etc/raddb/mods-enabled/expr
>including configuration file /mydir/etc/raddb/mods-enabled/files
>including configuration file /mydir/etc/raddb/mods-enabled/linelog
>including configuration file /mydir/etc/raddb/mods-enabled/logintime
>including configuration file /mydir/etc/raddb/mods-enabled/mschap
>including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth
>including configuration file /mydir/etc/raddb/mods-enabled/pap
>including configuration file /mydir/etc/raddb/mods-enabled/passwd
>including configuration file /mydir/etc/raddb/mods-enabled/preprocess
>including configuration file /mydir/etc/raddb/mods-enabled/radutmp
>including configuration file /mydir/etc/raddb/mods-enabled/realm
>including configuration file /mydir/etc/raddb/mods-enabled/replicate
>including configuration file /mydir/etc/raddb/mods-enabled/soh
>including configuration file /mydir/etc/raddb/mods-enabled/sradutmp
>including configuration file /mydir/etc/raddb/mods-enabled/unix
>including configuration file /mydir/etc/raddb/mods-enabled/unpack
>including configuration file /mydir/etc/raddb/mods-enabled/utf8
>including files in directory /mydir/etc/raddb/policy.d/
>including configuration file /mydir/etc/raddb/policy.d/abfab-tr
>including configuration file /mydir/etc/raddb/policy.d/accounting
>including configuration file /mydir/etc/raddb/policy.d/canonicalization
>including configuration file /mydir/etc/raddb/policy.d/control
>including configuration file /mydir/etc/raddb/policy.d/cui
>including configuration file /mydir/etc/raddb/policy.d/debug
>including configuration file /mydir/etc/raddb/policy.d/dhcp
>including configuration file /mydir/etc/raddb/policy.d/eap
>including configuration file /mydir/etc/raddb/policy.d/filter
>including configuration file
>/mydir/etc/raddb/policy.d/moonshot-targeted-ids
>including configuration file /mydir/etc/raddb/policy.d/operator-name
>including configuration file /mydir/etc/raddb/policy.d/rfc7542
>including files in directory /mydir/etc/raddb/sites-enabled/
>including configuration file
>/mydir/etc/raddb/sites-enabled/inner-tunnel
>main {
> security {
>

Re: OpenBSD Readonly File System

2020-07-11 Thread Stuart Henderson
On 2020/07/11 10:22, Vertigo Altair wrote:
>   Hello Again,
> I followed Stuart's recommendations,
> 
> in fstab, / has read-write permissions;
> also, I mounted /dev as ramdisk,  ( I executed "MAKEDEV all" in /dev_src 
> directory for once)
> 
> vertigo# cat /etc/fstab
> 5e045fec2af2ab03.b none swap sw
> 5e045fec2af2ab03.a / ffs rw 1 1
>   5e045fec2af2ab03.e /mydir ffs rw 1 1  
> 5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2
> swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0
> 
> and I'm updating / as readonly in rc.local;
> 
> vertigo# cat /etc/rc.local
> mount -fur /
> 
> Everything is OK right now. However, when I try to run radiusd, I'm getting 
> "failed to opening
> /dev/null: permission denied" error.
> All configs, and files related with radiusd are in read-write /mydir 
> directory.
> I tried to change the permission for /dev/ as 776 and /dev/null as 777 but 
> this didn't work.

/dev should be mode 755 owned by root:wheel, and /dev/null should be
mode 666. Permissions on the mfs are copied from permissions on the
mount point (so boot in single user mode and check /dev permissions
before it's mounted, they should be as above).

This doesn't explain the "permission denied" from freeradius though...



> vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb
> FreeRADIUS Version 3.0.21
> Copyright (C) 1999-2019 The FreeRADIUS server project and contributors
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE
> You may redistribute copies of FreeRADIUS under the terms of the
> GNU General Public License
> For more information about these matters, see the file named COPYRIGHT
> Starting - reading configuration files ...
> including dictionary file /usr/local/share/freeradius/dictionary
> including dictionary file /usr/local/share/freeradius/dictionary.dhcp
> including dictionary file /usr/local/share/freeradius/dictionary.vqp
> including dictionary file /mydir/etc/raddb/dictionary
> including configuration file /mydir/etc/raddb/radiusd.conf
> including configuration file /mydir/etc/raddb/proxy.conf
> including configuration file /mydir/etc/raddb/clients.conf
> including files in directory /mydir/etc/raddb/mods-enabled/
> including configuration file /mydir/etc/raddb/mods-enabled/always
> including configuration file /mydir/etc/raddb/mods-enabled/attr_filter
> including configuration file /mydir/etc/raddb/mods-enabled/cache_eap
> including configuration file /mydir/etc/raddb/mods-enabled/chap
> including configuration file /mydir/etc/raddb/mods-enabled/date
> including configuration file /mydir/etc/raddb/mods-enabled/detail
> including configuration file /mydir/etc/raddb/mods-enabled/detail.log
> including configuration file /mydir/etc/raddb/mods-enabled/digest
> including configuration file /mydir/etc/raddb/mods-enabled/dynamic_clients
> including configuration file /mydir/etc/raddb/mods-enabled/eap
> including configuration file /mydir/etc/raddb/mods-enabled/echo
> including configuration file /mydir/etc/raddb/mods-enabled/exec
> including configuration file /mydir/etc/raddb/mods-enabled/expiration
> including configuration file /mydir/etc/raddb/mods-enabled/expr
> including configuration file /mydir/etc/raddb/mods-enabled/files
> including configuration file /mydir/etc/raddb/mods-enabled/linelog
> including configuration file /mydir/etc/raddb/mods-enabled/logintime
> including configuration file /mydir/etc/raddb/mods-enabled/mschap
> including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth
> including configuration file /mydir/etc/raddb/mods-enabled/pap
> including configuration file /mydir/etc/raddb/mods-enabled/passwd
> including configuration file /mydir/etc/raddb/mods-enabled/preprocess
> including configuration file /mydir/etc/raddb/mods-enabled/radutmp
> including configuration file /mydir/etc/raddb/mods-enabled/realm
> including configuration file /mydir/etc/raddb/mods-enabled/replicate
> including configuration file /mydir/etc/raddb/mods-enabled/soh
> including configuration file /mydir/etc/raddb/mods-enabled/sradutmp
> including configuration file /mydir/etc/raddb/mods-enabled/unix
> including configuration file /mydir/etc/raddb/mods-enabled/unpack
> including configuration file /mydir/etc/raddb/mods-enabled/utf8
> including files in directory /mydir/etc/raddb/policy.d/
> including configuration file /mydir/etc/raddb/policy.d/abfab-tr
> including configuration file /mydir/etc/raddb/policy.d/accounting
> including configuration file /mydir/etc/raddb/policy.d/canonicalization
> including configuration file /mydir/etc/raddb/policy.d/control
> including configuration file /mydir/etc/raddb/policy.d/cui
> including configuration file /mydir/etc/raddb/policy.d/debug
> including configuration file /mydir/etc/raddb/policy.d/dhcp
> including configuration file /mydir/etc/raddb/policy.d/eap
> including configuration file /mydir/etc/raddb/policy.d/filter
> including configuration file 

Re: OpenBSD Readonly File System

2020-07-11 Thread Vertigo Altair
  Hello Again,
I followed Stuart's recommendations,

in fstab, / has read-write permissions;
also, I mounted /dev as ramdisk,  ( I executed "MAKEDEV all" in /dev_src
directory for once)

vertigo# cat /etc/fstab
5e045fec2af2ab03.b none swap sw
5e045fec2af2ab03.a / ffs rw 1 1
  5e045fec2af2ab03.e /mydir ffs rw 1 1
5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2
swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0

and I'm updating / as readonly in rc.local;

vertigo# cat /etc/rc.local
mount -fur /

Everything is OK right now. However, when I try to run radiusd, I'm getting
"failed to opening /dev/null: permission denied" error.
All configs, and files related with radiusd are in read-write /mydir
directory.
I tried to change the permission for /dev/ as 776 and /dev/null as 777 but
this didn't work.

vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb
FreeRADIUS Version 3.0.21
Copyright (C) 1999-2019 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /usr/local/share/freeradius/dictionary
including dictionary file /usr/local/share/freeradius/dictionary.dhcp
including dictionary file /usr/local/share/freeradius/dictionary.vqp
including dictionary file /mydir/etc/raddb/dictionary
including configuration file /mydir/etc/raddb/radiusd.conf
including configuration file /mydir/etc/raddb/proxy.conf
including configuration file /mydir/etc/raddb/clients.conf
including files in directory /mydir/etc/raddb/mods-enabled/
including configuration file /mydir/etc/raddb/mods-enabled/always
including configuration file /mydir/etc/raddb/mods-enabled/attr_filter
including configuration file /mydir/etc/raddb/mods-enabled/cache_eap
including configuration file /mydir/etc/raddb/mods-enabled/chap
including configuration file /mydir/etc/raddb/mods-enabled/date
including configuration file /mydir/etc/raddb/mods-enabled/detail
including configuration file /mydir/etc/raddb/mods-enabled/detail.log
including configuration file /mydir/etc/raddb/mods-enabled/digest
including configuration file /mydir/etc/raddb/mods-enabled/dynamic_clients
including configuration file /mydir/etc/raddb/mods-enabled/eap
including configuration file /mydir/etc/raddb/mods-enabled/echo
including configuration file /mydir/etc/raddb/mods-enabled/exec
including configuration file /mydir/etc/raddb/mods-enabled/expiration
including configuration file /mydir/etc/raddb/mods-enabled/expr
including configuration file /mydir/etc/raddb/mods-enabled/files
including configuration file /mydir/etc/raddb/mods-enabled/linelog
including configuration file /mydir/etc/raddb/mods-enabled/logintime
including configuration file /mydir/etc/raddb/mods-enabled/mschap
including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth
including configuration file /mydir/etc/raddb/mods-enabled/pap
including configuration file /mydir/etc/raddb/mods-enabled/passwd
including configuration file /mydir/etc/raddb/mods-enabled/preprocess
including configuration file /mydir/etc/raddb/mods-enabled/radutmp
including configuration file /mydir/etc/raddb/mods-enabled/realm
including configuration file /mydir/etc/raddb/mods-enabled/replicate
including configuration file /mydir/etc/raddb/mods-enabled/soh
including configuration file /mydir/etc/raddb/mods-enabled/sradutmp
including configuration file /mydir/etc/raddb/mods-enabled/unix
including configuration file /mydir/etc/raddb/mods-enabled/unpack
including configuration file /mydir/etc/raddb/mods-enabled/utf8
including files in directory /mydir/etc/raddb/policy.d/
including configuration file /mydir/etc/raddb/policy.d/abfab-tr
including configuration file /mydir/etc/raddb/policy.d/accounting
including configuration file /mydir/etc/raddb/policy.d/canonicalization
including configuration file /mydir/etc/raddb/policy.d/control
including configuration file /mydir/etc/raddb/policy.d/cui
including configuration file /mydir/etc/raddb/policy.d/debug
including configuration file /mydir/etc/raddb/policy.d/dhcp
including configuration file /mydir/etc/raddb/policy.d/eap
including configuration file /mydir/etc/raddb/policy.d/filter
including configuration file /mydir/etc/raddb/policy.d/moonshot-targeted-ids
including configuration file /mydir/etc/raddb/policy.d/operator-name
including configuration file /mydir/etc/raddb/policy.d/rfc7542
including files in directory /mydir/etc/raddb/sites-enabled/
including configuration file /mydir/etc/raddb/sites-enabled/inner-tunnel
main {
 security {
user = "_freeradius"
group = "_freeradius"
allow_core_dumps = no
 }
name = "radiusd"
prefix = "/usr/local"
localstatedir = "/mydir/var"
logdir = "/mydir/var/log/radius"
run_dir = 

Re: OpenBSD Readonly File System

2020-06-27 Thread gwes




On 6/27/20 10:57 AM, Stuart Henderson wrote:

On 2020-06-26, Marko Cupać  wrote:

On 2020-06-24, Aaron Mason  wrote:
Auto filesystem repair is bad juju.

On 2020-06-25 11:17, Stuart Henderson wrote:
Nonsense. For many, the possible downsides of automatically running
fsck -y are much less a problem than the downsides of *not* running it.

Some time ago I wrote here on misc@ about read-only setup, where I
intended to modify rc(8) in order to be able to relink kernel before
mounting filesystems read-only, and - if I remember correctly - I was
warned never to modify rc(8) directly as it's considered as part of base
system, and I should only affect it with rc.local, which I did.

Is there a way to run fsck -y automatically without modifying rc(8)? Is
modifying rc(8) now supported?

No, you still need to modify rc to do that, so you need to remember to
reinstate it after updating. It would be nice if that wasn't needed but
diffs to make it configurable have never been approved.



20 years or so I worked on a network appliance based on FreeBSD.
It was required to come up after power failures no matter what.
We thought that this was the simplest way to harden the
system enough for our requirements:

We separated the boot environment from the runtime environment.

The initial root filesystem was never writable except during updates.
It was populated with the absolute minimumnecessary for
the system to come up capable of calling home.

During the transition to normal operation filesystems
containing the usual files were mounted over it
making it invisible and inaccessible.

The runtime filesystems could fail fsck during boot and the system could
be remotely repaired.
They could be refreshed via newfs and tarballs during boot if desired.

best,
Geoff Steckel





Re: OpenBSD Readonly File System

2020-06-27 Thread Stuart Henderson
On 2020-06-26, Marko Cupać  wrote:
>>> On 2020-06-24, Aaron Mason  wrote:
>>> Auto filesystem repair is bad juju.
>
>> On 2020-06-25 11:17, Stuart Henderson wrote:
>> Nonsense. For many, the possible downsides of automatically running
>> fsck -y are much less a problem than the downsides of *not* running it.
>
> Some time ago I wrote here on misc@ about read-only setup, where I 
> intended to modify rc(8) in order to be able to relink kernel before 
> mounting filesystems read-only, and - if I remember correctly - I was 
> warned never to modify rc(8) directly as it's considered as part of base 
> system, and I should only affect it with rc.local, which I did.
>
> Is there a way to run fsck -y automatically without modifying rc(8)? Is 
> modifying rc(8) now supported?

No, you still need to modify rc to do that, so you need to remember to
reinstate it after updating. It would be nice if that wasn't needed but
diffs to make it configurable have never been approved.




Re: OpenBSD Readonly File System

2020-06-26 Thread Marko Cupać

On 2020-06-24, Aaron Mason  wrote:
Auto filesystem repair is bad juju.



On 2020-06-25 11:17, Stuart Henderson wrote:
Nonsense. For many, the possible downsides of automatically running
fsck -y are much less a problem than the downsides of *not* running it.


Some time ago I wrote here on misc@ about read-only setup, where I 
intended to modify rc(8) in order to be able to relink kernel before 
mounting filesystems read-only, and - if I remember correctly - I was 
warned never to modify rc(8) directly as it's considered as part of base 
system, and I should only affect it with rc.local, which I did.


Is there a way to run fsck -y automatically without modifying rc(8)? Is 
modifying rc(8) now supported?


--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/



Re: OpenBSD Readonly File System

2020-06-26 Thread Vertigo Altair
Hi,

Thanks to Stuart's recommendations, I made progress but got stuck at
another point:
When i mount /dev on fstab as this:
swap /dev mfs rw,async,noatime,nosuid,-s2M,-i8,-P/dev_src 0 0
Freeradius doesn't work. Here error message:
Error opening /dev/null: Permission denied

I've changed /dev/null permissions to _freeradius even made it 777.
But nothing changed.

Any thoughts?

On Thu, 25 Jun 2020 at 12:19, Stuart Henderson  wrote:

> > On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
> > wrote:
> >> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
> >> +#  automatic file system check fails with exit code 8.
>
> I have quite a few machines patched like this.
>
> On 2020-06-24, Aaron Mason  wrote:
> > Auto filesystem repair is bad juju.
>
> Nonsense. For many, the possible downsides of automatically running
> fsck -y are much less a problem than the downsides of *not* running it.
>
> Even if there is corruption, there's still a fair chance the machine
> will come up far enough to fix things.
>
> What else is someone going to do other than OOB/drive/fly/whatever
> to the machine, press enter and type "fsck -y"? They're not going to
> suddenly try to backup a dirty fs where they wouldn't already have
> backups. Someone who cares about the data will already have a way
> to rebuild or restore from backups.
>
>
>


Re: OpenBSD Readonly File System

2020-06-25 Thread Stuart Henderson
> On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
> wrote:
>> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
>> +#  automatic file system check fails with exit code 8.

I have quite a few machines patched like this.

On 2020-06-24, Aaron Mason  wrote:
> Auto filesystem repair is bad juju.

Nonsense. For many, the possible downsides of automatically running
fsck -y are much less a problem than the downsides of *not* running it.

Even if there is corruption, there's still a fair chance the machine
will come up far enough to fix things.

What else is someone going to do other than OOB/drive/fly/whatever
to the machine, press enter and type "fsck -y"? They're not going to
suddenly try to backup a dirty fs where they wouldn't already have
backups. Someone who cares about the data will already have a way
to rebuild or restore from backups.




Re: OpenBSD Readonly File System

2020-06-25 Thread Mogens Jensen
On Wednesday, June 24, 2020 10:58 PM, Aaron Mason  
wrote:

> Auto filesystem repair is bad juju.

Indeed, but an unbootable network appliance thousands of miles away,
is much much worse.


Regards,
Mogens Jensen





Re: OpenBSD Readonly File System

2020-06-24 Thread Aaron Mason
On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
 wrote:
>
> Tuesday, June 9, 2020 7:59 AM, Vertigo Altair  
> wrote:
>
> > Hi Misc,
> > I have a firewall device and I'm using OpenBSD on it.
>
> Last year I had to configure an OpenBSD 6.5 firewall for use in a
> remote location, and was concerned about power loss corrupting the
> filesystem and making the system unbootable without manual
> intervention. As I did not want to modify OpenBSD in unsupported ways,
> I decided to test what kind of damage power loss could do, by
> randomly removing and applying power to the firewall, many many times.
>
> What I found was that 99% of the time, the system would just repair the
> filesystem and boot without problems, but if by chance the power was
> removed at a short time window during kernel relinking, the kernel
> would become corrupt and leave the system completely unbootable and
> not easy to repair. It was suggested to me that I tried to mount root
> partition with the sync option, so I arranged the partition layout in a
> way that would make it feasible and added the option to fstab.
>
> Only other problem I found, was that a few times after removing power
> when writing a large file, the system would require me to run fsck -y
> manually, this is by design, but I decided it was more important to me
> that the system could boot unattended, with a minuscule risk of
> completely ruining the filesystem, so I wrote a small unsupported patch
> for the rc script (sorry if the formatting gets messed up by posting):
>
> The patch has only been tested on OpenBSD 6.5.
>
> ---
> Index: src/etc/rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.536
> diff -u -p -u -p -r1.536 rc
> --- src/etc/rc  1 Apr 2019 11:39:46 -   1.536
> +++ src/etc/rc  20 Aug 2019 22:47:49 -
> @@ -1,5 +1,8 @@
>  #  $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $
>
> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
> +#  automatic file system check fails with exit code 8.
> +
>  # System startup script run by init on autoboot or after single-user.
>  # Output and error are redirected to console by init, and the console is the
>  # controlling terminal.
> @@ -271,8 +274,14 @@ do_fsck() {
> echo "Reboot failed; help!"
> exit 1
> ;;
> -   8)  echo "Automatic file system check failed; help!"
> -   exit 1
> +   8)  echo "Automatic file system check failed; trying fsck -y"
> +   fsck -y
> +   case $? in
> +   0)  ;;
> +   *)  echo "Could not repair file system unattended; help!"
> +   exit 1
> +   ;;
> +   esac
> ;;
> 12) echo "Boot interrupted."
> exit 1
> ---
>
> After mounting root filesystem with sync option and applying the patch,
> I was no longer able to make the system unbootable by power loss in my
> test setup. It may be possible, but the risk is now so small that it is
> not a concern for me and the risk of something else breaking is
> probably bigger. During operation in remote location, the system has
> always been able to completely boot after a power loss so far.
>
> So while it was not possible for me to not make any unsupported
> modifications at all, I think it is a very small change compared to
> have read only filesystems. Anyone who knows OpenBSD, will be able to
> manage the firewall without special instructions.
>
>
> Regards,
> Mogens Jensen
>

Auto filesystem repair is bad juju.

-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse



Re: OpenBSD Readonly File System

2020-06-22 Thread Mogens Jensen
Tuesday, June 9, 2020 7:59 AM, Vertigo Altair  wrote:

> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it.

Last year I had to configure an OpenBSD 6.5 firewall for use in a
remote location, and was concerned about power loss corrupting the
filesystem and making the system unbootable without manual
intervention. As I did not want to modify OpenBSD in unsupported ways,
I decided to test what kind of damage power loss could do, by
randomly removing and applying power to the firewall, many many times.

What I found was that 99% of the time, the system would just repair the
filesystem and boot without problems, but if by chance the power was
removed at a short time window during kernel relinking, the kernel
would become corrupt and leave the system completely unbootable and
not easy to repair. It was suggested to me that I tried to mount root
partition with the sync option, so I arranged the partition layout in a
way that would make it feasible and added the option to fstab.

Only other problem I found, was that a few times after removing power
when writing a large file, the system would require me to run fsck -y
manually, this is by design, but I decided it was more important to me
that the system could boot unattended, with a minuscule risk of
completely ruining the filesystem, so I wrote a small unsupported patch
for the rc script (sorry if the formatting gets messed up by posting):

The patch has only been tested on OpenBSD 6.5.

---
Index: src/etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.536
diff -u -p -u -p -r1.536 rc
--- src/etc/rc  1 Apr 2019 11:39:46 -   1.536
+++ src/etc/rc  20 Aug 2019 22:47:49 -
@@ -1,5 +1,8 @@
 #  $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $

+# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
+#  automatic file system check fails with exit code 8.
+
 # System startup script run by init on autoboot or after single-user.
 # Output and error are redirected to console by init, and the console is the
 # controlling terminal.
@@ -271,8 +274,14 @@ do_fsck() {
echo "Reboot failed; help!"
exit 1
;;
-   8)  echo "Automatic file system check failed; help!"
-   exit 1
+   8)  echo "Automatic file system check failed; trying fsck -y"
+   fsck -y
+   case $? in
+   0)  ;;
+   *)  echo "Could not repair file system unattended; help!"
+   exit 1
+   ;;
+   esac
;;
12) echo "Boot interrupted."
exit 1
---

After mounting root filesystem with sync option and applying the patch,
I was no longer able to make the system unbootable by power loss in my
test setup. It may be possible, but the risk is now so small that it is
not a concern for me and the risk of something else breaking is
probably bigger. During operation in remote location, the system has
always been able to completely boot after a power loss so far.

So while it was not possible for me to not make any unsupported
modifications at all, I think it is a very small change compared to
have read only filesystems. Anyone who knows OpenBSD, will be able to
manage the firewall without special instructions.


Regards,
Mogens Jensen



Re: OpenBSD Readonly File System

2020-06-15 Thread Nick Holland
On 2020-06-13 12:56, Todd C. Miller wrote:
> 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.

Thanks for the correction!  The really embarrassing thing is I even
checked the man page, but started from the incorrect assumption that
"async" and "sync" were the only two choices and read what I expected,
not what is actually on the page. 

Nick.



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



Re: OpenBSD Readonly File System

2020-06-13 Thread Marko Cupać

On 2020-06-09 09:59, Vertigo Altair wrote:

Hi Misc,
I have a firewall device and I'm using OpenBSD on it. There is an
electricity problem where the device runs. Therefore, I have to run the
"fsck -y" command regularly at startup due to the electricity problem. 
To

overcome this, I want to use readonly file system.
 I know there are some projects like "resflash", but I want to do that
manually.
...
On startup following errors comming from /etc/rc; I think errors about
/etc/motd are not so important, but are the errors coming from 
/etc/tty*
can cause any problems? If my method is not correct, what is the best 
way

to do this?


AFAIK, OpenBSD officially does not support read-only root file system.

But I have a similar problem, and I have described my solution here:

https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages

HTH,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/



Re: OpenBSD Readonly File System

2020-06-13 Thread 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



Re: OpenBSD Readonly File System

2020-06-13 Thread Nick Holland
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.

File systems are complicated.  Making them work robustly is even
more complicated.  And the ways hardware (including power) fails
is often difficult to comprehend from a high-level language
standpoint ("I just wrote fifty bytes to the end of the file,
what's the big deal?").  All things considered, FFS works
amazingly well.


Back to the OP's question -- I'm curious why he's having trouble
I just don't have.  The vast majority of the time, my firewalls
and other OpenBSD systems just come back on their own without
intervention.  When I'm moving or otherwise maintaining an
OpenBSD system, I often just yank the power cord and let the
thing fsck itself on reboot.  I'm not going to say it ALWAYS
comes back without intervention, but I'd guess well over 90%
of the time, they just come up without help.)

So...  I'd look at what's going on more than try to change the
basic operation of OpenBSD.  Why are you writing to disk so much
that your file systems end up being trashed?

Some ideas I'd try before making a Franken-system:
* Log to another system over the network via syslog so less
writing happens locally.
* use the noatime mount option -- that reduces a lot of
unneeded writes.  
* Faster disks -- How about a small SSD?  They spend less
time writing, and often have enough on-board capacitance to
complete writes after a power interruption.
* experiment with softdeps.  Supposedly, it helps keep the
/FILE SYSTEM/ consistent.  My experience is it tends to
truncate files on unexpected power-downs, but in MOST cases,
I'd rather have a zero byte file that has obviously been
mangled than one that looks ok.  I almost always use softdeps,
maybe that's why my systems almost always come back after a
power interruption?

I have no hard facts to back up any of those helping a
system come up on its own after a impolite powerdown, but 
they all seem like they might.  And I do most of them, and
my results seem to be better than the OP's, so maybe?

Nick.



Re: OpenBSD Readonly File System

2020-06-12 Thread Kevin Chadwick
On 2020-06-11 23:47, Dirk Coetzee wrote:

> I always thought that 'sync' mount option  is enough  to avoid  corruption of
the FS.

> Am I just "fooling" myself  ?

> I guess it boils down to a matter of preference and business requirements.
> 
> "slow writes" vs "no writes".

It's a good point, perhaps? Comments anyone?

I think many went the RO route to avoid fsck and add an extra layer of security.

Now that there is KARL and ffs2 means fsck is faster. The argument for RO being
more of a problem than anything else, has gotten stronger, whilst ironically
there seems to be more frequent reports of people using RO.

Batteries/UPS are certainly still, the best answer. Database corruption for 
example.

I also wonder how sync might affect disk churn during KARL. I'm not sure I care
at all, about a one-off at boot though.

Is there any mileage for root to be mounted sync in any case with so few writes,
but maybe a problem for bsd.rd and live upgrades may want to re-mount? Though
perhaps safety is more important, in any case?



Re: OpenBSD Readonly File System

2020-06-11 Thread Dirk Coetzee
I guess it boils down to a matter of preference and business requirements.

"slow writes" vs "no writes".

-Original Message-
From: Strahil Nikolov  
Sent: Friday, 12 June 2020 12:08 AM
To: Dirk Coetzee ; Joe Barnett ; 
Vertigo Altair 
Cc: Misc 
Subject: Re: OpenBSD Readonly File System

I always thought that 'sync' mount option  is enough  to avoid  corruption of 
the FS.
Am I just "fooling" myself  ?

Best  Regards,
Strahil Nikolov

На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee  написа:
>I have been in a similar situation of power being unreliable and no 
>UPS, so I sympathize.
>
>This is how I have achieved RO filesystem (default partitions)
>
>1. Add to /etc/fstab
>   swap /dev mfs rw,-P=/dev,-s=32m 0 0
>
>2. Create RO Script
>   #!/bin/sh
>
>   UP=$(( $(date +%s) - $(sysctl -n kern.boottime) ))  ## Date in
>Seconds subtracted from OS boot time
>
>   if [ $UP -lt 3600 ]; then  ## 
> If less than 1 hour -
>leave system as is. No modification of FS. You can add crontab for this 
>script to run every hour.
>  exit 1
>   else
>  mount -uvr /
>  mount -uvr /usr
>  mount -uvr /usr/X11R6
>  mount -uvr /usr/local
>  mount -uvr /usr/obj
>  mount -uvr /usr/src
>   fi
>
>   exit 1
>
>
>Obviously this is a last resort. Default partitions, etc should remain 
>as devs intended. The Developers also assume a work (RW) filesystem.
>
>I have a RW script that I run before doing  sysupgrade / syspatch etc.
>Also make the Filesystems RW before rebooting.
>
>
>
>
>-Original Message-----
>From: owner-m...@openbsd.org  On Behalf Of Joe 
>Barnett
>Sent: Wednesday, 10 June 2020 8:02 AM
>To: Vertigo Altair 
>Cc: Misc 
>Subject: Re: OpenBSD Readonly File System
>
>On 2020-06-09 00:59, Vertigo Altair wrote:
>> Hi Misc,
>> I have a firewall device and I'm using OpenBSD on it. There is an 
>> electricity problem where the device runs. Therefore, I have to run 
>> the "fsck -y" command regularly at startup due to the electricity
>problem.
>> To
>> overcome this, I want to use readonly file system.
>>  I know there are some projects like "resflash", but I want to do
>that
>> manually.
>
>I have hacked and slashed my way to this kind of configuration for my 
>firewall/gateway and a few other machines -- and with what appears to 
>be good results.  Please understand this is almost certainly not 
>supported by the project.  I have outlined this at the following URL:
>
>https://www.mr72.com/readonlyfs.html
>
>I hope this helps.  Any feedback will be greatly appreciated.
>
>Good luck!
>
>Joe
>
>> My partitions like this;
>> 
>> vertigo# df -h
>> Filesystem SizeUsed   Avail Capacity  Mounted on
>> /dev/sd0a  3.9G489M3.2G13%/
>> /dev/sd0g 91.8G1.0G   86.2G 1%/mypartition
>> /dev/sd0d  989M   12.0K940M 0%/tmp
>> /dev/sd0f  3.9G1.7G2.0G46%/usr
>> /dev/sd0e  3.9G   46.9M3.6G 1%/var
>> 
>> I want to / and /usr as readonly, I updated /etc/fstab and I made / 
>> and /usr readonly;
>> 
>> vertigo# cat /etc/fstab
>> ec347fefe8d05509.b none swap sw
>> ec347fefe8d05509.a / ffs ro 1 1
>> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 
>> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f 
>> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs 
>> rw,nodev,nosuid 1 2
>> 
>> 
>> On startup following errors comming from /etc/rc; I think errors
>about
>> /etc/motd are not so important, but are the errors coming from
>> /etc/tty*
>> can cause any problems? If my method is not correct, what is the best
>
>> way to do this?
>> 
>>>> OpenBSD/amd64 BOOTX64 3.50
>> boot>
>> booting hd0a:/bsd: 12957000+2753552+327712+0+708608
>> [807408+128+1024872+749630]=0x1271a18
>> entry point at 0x1001000
>> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 
>> 1986, 1989, 1991, 1993
>> The Regents of the University of California.  All rights 
>> reserved.
>> Copyright (c) 1995-2020 OpenBSD. All rights reserved.  
>> https://www.OpenBSD.org
>> 
>> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
>> 
>>
>r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN
>> ERIC.MP
>> real mem = 4151607296 (3959MB)
>> avail mem = 4013170688 (3827MB)
>> mpath0 at root
>> scs

Re: OpenBSD Readonly File System

2020-06-11 Thread Strahil Nikolov
I always thought that 'sync' mount option  is enough  to avoid  corruption of 
the FS.
Am I just "fooling" myself  ?

Best  Regards,
Strahil Nikolov

На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee  написа:
>I have been in a similar situation of power being unreliable and no
>UPS, so I sympathize.
>
>This is how I have achieved RO filesystem (default partitions)
>
>1. Add to /etc/fstab
>   swap /dev mfs rw,-P=/dev,-s=32m 0 0
>
>2. Create RO Script
>   #!/bin/sh
>
>   UP=$(( $(date +%s) - $(sysctl -n kern.boottime) ))  ## Date in
>Seconds subtracted from OS boot time
>
>   if [ $UP -lt 3600 ]; then  ## 
> If less than 1 hour -
>leave system as is. No modification of FS. You can add crontab for this
>script to run every hour.
>  exit 1
>   else
>  mount -uvr /
>  mount -uvr /usr
>  mount -uvr /usr/X11R6
>  mount -uvr /usr/local
>  mount -uvr /usr/obj
>  mount -uvr /usr/src
>   fi
>
>   exit 1
>
>
>Obviously this is a last resort. Default partitions, etc should remain
>as devs intended. The Developers also assume a work (RW) filesystem. 
>
>I have a RW script that I run before doing  sysupgrade / syspatch etc.
>Also make the Filesystems RW before rebooting.
>
>
>
>
>-Original Message-
>From: owner-m...@openbsd.org  On Behalf Of Joe
>Barnett
>Sent: Wednesday, 10 June 2020 8:02 AM
>To: Vertigo Altair 
>Cc: Misc 
>Subject: Re: OpenBSD Readonly File System
>
>On 2020-06-09 00:59, Vertigo Altair wrote:
>> Hi Misc,
>> I have a firewall device and I'm using OpenBSD on it. There is an 
>> electricity problem where the device runs. Therefore, I have to run 
>> the "fsck -y" command regularly at startup due to the electricity
>problem.
>> To
>> overcome this, I want to use readonly file system.
>>  I know there are some projects like "resflash", but I want to do
>that 
>> manually.
>
>I have hacked and slashed my way to this kind of configuration for my
>firewall/gateway and a few other machines -- and with what appears to
>be good results.  Please understand this is almost certainly not
>supported by the project.  I have outlined this at the following URL:
>
>https://www.mr72.com/readonlyfs.html
>
>I hope this helps.  Any feedback will be greatly appreciated.
>
>Good luck!
>
>Joe
>
>> My partitions like this;
>> 
>> vertigo# df -h
>> Filesystem SizeUsed   Avail Capacity  Mounted on
>> /dev/sd0a  3.9G489M3.2G13%/
>> /dev/sd0g 91.8G1.0G   86.2G 1%/mypartition
>> /dev/sd0d  989M   12.0K940M 0%/tmp
>> /dev/sd0f  3.9G1.7G2.0G46%/usr
>> /dev/sd0e  3.9G   46.9M3.6G 1%/var
>> 
>> I want to / and /usr as readonly, I updated /etc/fstab and I made / 
>> and /usr readonly;
>> 
>> vertigo# cat /etc/fstab
>> ec347fefe8d05509.b none swap sw
>> ec347fefe8d05509.a / ffs ro 1 1
>> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 
>> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f 
>> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs 
>> rw,nodev,nosuid 1 2
>> 
>> 
>> On startup following errors comming from /etc/rc; I think errors
>about 
>> /etc/motd are not so important, but are the errors coming from
>> /etc/tty*
>> can cause any problems? If my method is not correct, what is the best
>
>> way to do this?
>> 
>>>> OpenBSD/amd64 BOOTX64 3.50
>> boot>
>> booting hd0a:/bsd: 12957000+2753552+327712+0+708608
>> [807408+128+1024872+749630]=0x1271a18
>> entry point at 0x1001000
>> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 
>> 1986, 1989, 1991, 1993
>> The Regents of the University of California.  All rights 
>> reserved.
>> Copyright (c) 1995-2020 OpenBSD. All rights reserved.  
>> https://www.OpenBSD.org
>> 
>> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
>> 
>>
>r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN
>> ERIC.MP
>> real mem = 4151607296 (3959MB)
>> avail mem = 4013170688 (3827MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries)
>> bios0: vendor American Megatrends Inc. version "BAR3NA05" date
>> 07/23/2018
>> bios0: NF533 NF533
>> acpi0 at bios0: ACPI 5.0
>> acpi0: sleep states S0 S3 S4 S

Re: OpenBSD Readonly File System

2020-06-09 Thread Dirk Coetzee
I have been in a similar situation of power being unreliable and no UPS, so I 
sympathize.

This is how I have achieved RO filesystem (default partitions)

1. Add to /etc/fstab
swap /dev mfs rw,-P=/dev,-s=32m 0 0

2. Create RO Script
#!/bin/sh

UP=$(( $(date +%s) - $(sysctl -n kern.boottime) ))  ## Date in 
Seconds subtracted from OS boot time

if [ $UP -lt 3600 ]; then  ## 
If less than 1 hour - leave system as is. No modification of FS. You can add 
crontab for this script to run every hour.
   exit 1
else
   mount -uvr /
   mount -uvr /usr
   mount -uvr /usr/X11R6
   mount -uvr /usr/local
   mount -uvr /usr/obj
   mount -uvr /usr/src
fi

exit 1


Obviously this is a last resort. Default partitions, etc should remain as devs 
intended. The Developers also assume a work (RW) filesystem. 

I have a RW script that I run before doing  sysupgrade / syspatch etc. Also 
make the Filesystems RW before rebooting.




-Original Message-
From: owner-m...@openbsd.org  On Behalf Of Joe Barnett
Sent: Wednesday, 10 June 2020 8:02 AM
To: Vertigo Altair 
Cc: Misc 
Subject: Re: OpenBSD Readonly File System

On 2020-06-09 00:59, Vertigo Altair wrote:
> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it. There is an 
> electricity problem where the device runs. Therefore, I have to run 
> the "fsck -y" command regularly at startup due to the electricity problem.
> To
> overcome this, I want to use readonly file system.
>  I know there are some projects like "resflash", but I want to do that 
> manually.

I have hacked and slashed my way to this kind of configuration for my 
firewall/gateway and a few other machines -- and with what appears to be good 
results.  Please understand this is almost certainly not supported by the 
project.  I have outlined this at the following URL:

https://www.mr72.com/readonlyfs.html

I hope this helps.  Any feedback will be greatly appreciated.

Good luck!

Joe

> My partitions like this;
> 
> vertigo# df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd0a  3.9G489M3.2G13%/
> /dev/sd0g 91.8G1.0G   86.2G 1%/mypartition
> /dev/sd0d  989M   12.0K940M 0%/tmp
> /dev/sd0f  3.9G1.7G2.0G46%/usr
> /dev/sd0e  3.9G   46.9M3.6G 1%/var
> 
> I want to / and /usr as readonly, I updated /etc/fstab and I made / 
> and /usr readonly;
> 
> vertigo# cat /etc/fstab
> ec347fefe8d05509.b none swap sw
> ec347fefe8d05509.a / ffs ro 1 1
> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 
> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f 
> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs 
> rw,nodev,nosuid 1 2
> 
> 
> On startup following errors comming from /etc/rc; I think errors about 
> /etc/motd are not so important, but are the errors coming from
> /etc/tty*
> can cause any problems? If my method is not correct, what is the best 
> way to do this?
> 
>>> OpenBSD/amd64 BOOTX64 3.50
> boot>
> booting hd0a:/bsd: 12957000+2753552+327712+0+708608
> [807408+128+1024872+749630]=0x1271a18
> entry point at 0x1001000
> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 
> 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights 
> reserved.
> Copyright (c) 1995-2020 OpenBSD. All rights reserved.  
> https://www.OpenBSD.org
> 
> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
> 
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN
> ERIC.MP
> real mem = 4151607296 (3959MB)
> avail mem = 4013170688 (3827MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries)
> bios0: vendor American Megatrends Inc. version "BAR3NA05" date
> 07/23/2018
> bios0: NF533 NF533
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT 
> UEFI
> acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
> 6,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MW
> AIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT
> ,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP
> ,ERMS,MD_CLEAR,IB

Re: OpenBSD Readonly File System

2020-06-09 Thread Joe Barnett

On 2020-06-09 00:59, Vertigo Altair wrote:

Hi Misc,
I have a firewall device and I'm using OpenBSD on it. There is an
electricity problem where the device runs. Therefore, I have to run the
"fsck -y" command regularly at startup due to the electricity problem. 
To

overcome this, I want to use readonly file system.
 I know there are some projects like "resflash", but I want to do that
manually.


I have hacked and slashed my way to this kind of configuration for my 
firewall/gateway and a few other machines -- and with what appears to be 
good results.  Please understand this is almost certainly not supported 
by the project.  I have outlined this at the following URL:


https://www.mr72.com/readonlyfs.html

I hope this helps.  Any feedback will be greatly appreciated.

Good luck!

Joe


My partitions like this;

vertigo# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd0a  3.9G489M3.2G13%/
/dev/sd0g 91.8G1.0G   86.2G 1%/mypartition
/dev/sd0d  989M   12.0K940M 0%/tmp
/dev/sd0f  3.9G1.7G2.0G46%/usr
/dev/sd0e  3.9G   46.9M3.6G 1%/var

I want to / and /usr as readonly, I updated /etc/fstab and I made / and
/usr readonly;

vertigo# cat /etc/fstab
ec347fefe8d05509.b none swap sw
ec347fefe8d05509.a / ffs ro 1 1
ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2
ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2
ec347fefe8d05509.f /usr ffs ro,wxallowed,nodev 1 2
ec347fefe8d05509.e /var ffs rw,nodev,nosuid 1 2


On startup following errors comming from /etc/rc; I think errors about
/etc/motd are not so important, but are the errors coming from 
/etc/tty*
can cause any problems? If my method is not correct, what is the best 
way

to do this?


OpenBSD/amd64 BOOTX64 3.50

boot>
booting hd0a:/bsd: 12957000+2753552+327712+0+708608
[807408+128+1024872+749630]=0x1271a18
entry point at 0x1001000
[ using 2583064 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights 
reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.  
https://www.OpenBSD.org


OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4151607296 (3959MB)
avail mem = 4013170688 (3827MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries)
bios0: vendor American Megatrends Inc. version "BAR3NA05" date 
07/23/2018

bios0: NF533 NF533
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT 
UEFI

acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09
cpu3:

Re: OpenBSD Readonly File System

2020-06-09 Thread Ottavio Caruso
On Tue, 9 Jun 2020 at 08:59, Vertigo Altair  wrote:
>
> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it. There is an
> electricity problem where the device runs. Therefore, I have to run the
> "fsck -y" command regularly at startup due to the electricity problem.

Isn't it just easier to buy a UPS?


-- 
Ottavio Caruso



Re: OpenBSD Readonly File System

2020-06-09 Thread Stuart Henderson
On 2020-06-09, Vertigo Altair  wrote:
> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it. There is an
> electricity problem where the device runs. Therefore, I have to run the
> "fsck -y" command regularly at startup due to the electricity problem. To
> overcome this, I want to use readonly file system.
>  I know there are some projects like "resflash", but I want to do that
> manually.

The usual way to handle / is to have it RW during boot and remount
it (mount -ur /) in rc.local.

Use a ramdisk (MFS) for /dev. Create a directory on / to populate
it from, e.g.

cd /
mkdir dev_src
cp dev/MAKEDEV dev_src
cd dev_src
sh MAKEDEV all

Mount /dev using the -P mount option to populate it from your source
directory, it doesn't need much space but needs quite a few inodes,
a line like this works:

swap /dev mfs rw,async,noatime,nosuid,-s2M,-i8,-P/dev_src 0 0

The dev_src directory needs regenerating after OS updates.

/tmp and /var/run probably also best done as ramdisk.
Other parts of /var, especially /var/db, are tricky, you can use a
ramdisk populated from a source directory as with /dev, but you need
a way to sync it back to the source directory otherwise you run into
problems (dhcp leases, /var/db/pkg, maybe others depending on what
you run).

logs: syslog memory buffers are useful.

Normally OpenBSD relinks the kernel in a random order - at the end of
running /etc/rc, and when you use syspatch to add kernel patches.
With RO /usr and / this can't be done. If power is unstable it is
often good to avoid the relinking at boot (I've had a few where
power has gone, come back for long enough to start relinking, then
gone again during relink - considering how circuit breakers work
this isn't a big surprise).. but you'll need to be aware of this
when applying patches.

I have a number of VPN client routers in situations where they
may have unstable power or people powering them down without halting
first. I tried quite hard to use OpenBSD with them (usually on
pcengines boards - alix, apu etc) with various run-from-ramdisk
(flashboot, flashrd, resflash) or manual readonly+MFS setups,
but came to the conclusion that it's just too much hassle wrangling
these and keeping on top of OpenBSD updates. I had to add a bunch
more earlier this year so now I have ~60 hapac2 running routeros.
Definitely not perfect but seems a better fit to this situation.