syspatch breaks calling stat on mfs filesystem

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

syspatch breaks calling stat on mfs filesystem

Art Manion
Environment:
System      : OpenBSD 6.6
Details     : OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 00:59:03 MST 2019
[hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
Architecture: OpenBSD.i386

Description:

syspatch adds up the sizes of existing files to be replaced and collects
the device names:

 91                 stat -qf "_dev=\"\${_dev} %Sd\";
 92                         local %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" ${_files})
\
 93                         2>/dev/null || _rc=$?

then checks that devices are mounted and are not read-only:

 97         for _d in $(printf '%s\n' ${_dev} | sort -u); do
 98                 mount | grep -v read-only | grep -q "^/dev/${_d} " ||
 99                         sp_err "Read-only filesystem, aborting"

I have a system with /var and /tmp mounted as mfs.  The stat string
format returns '??' for mfs devices:

$ stat -f %Sd /bin/cat
wd0a

$ stat -f %Sd /var/db/libc.tags
??

The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out
reporting a read-only filesystem, which is not correct.

I noticed this with syspatch66-010_libcauth.tgz which looks to be the
first patch that changes files in /var (like /var/db/libc.tags).

$ syspatch
Get/Verify syspatch66-010_libcaut... 100% |*************| 17685 KB    00:03

Installing patch 010_libcauth
Read-only filesystem, aborting

$ mount
/dev/wd0a on / type ffs (local)
/dev/wd0g on /home type ffs (local, nodev, nosuid)
/dev/wd0f on /usr type ffs (local, nodev, wxallowed)
/dev/wd0d on /mfs type ffs (local, nodev, nosuid)
mfs:37162 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=524288
512-blocks)
mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid, size=524288
512-blocks)
mfs:40334 on /dev type mfs (asynchronous, local, noexec, nosuid, size=8192
512-blocks)
/dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid)
_a_host_:/some/nfs/export on /mnt/_an_nfs_mount_ type nfs (noexec, v3, udp,
timeo=100, retrans=101)

Can work around it by modifying the check on line 98.  Is it OK to allow
mfs filesystems?

Is the major number for mfs uniquely 255?

$ stat -f %Hd /var/db/libc.tags
255

$ stat -f %Hd /mnt/_an_nfs_mount_
22

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Antoine Jacoutot-6
On Fri, 2019-12-06 at 09:26 -0500, Art Manion wrote:

> Environment:
> System      : OpenBSD 6.6
> Details     : OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 00:59:03 MST 2019
> [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> Architecture: OpenBSD.i386
>
> Description:
>
> syspatch adds up the sizes of existing files to be replaced and collects
> the device names:
>
>  91                 stat -qf "_dev=\"\${_dev} %Sd\";
>  92                         local %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" ${_files})
> \
>  93                         2>/dev/null || _rc=$?
>
> then checks that devices are mounted and are not read-only:
>
>  97         for _d in $(printf '%s\n' ${_dev} | sort -u); do
>  98                 mount | grep -v read-only | grep -q "^/dev/${_d} " ||
>  99                         sp_err "Read-only filesystem, aborting"
>
> I have a system with /var and /tmp mounted as mfs.  The stat string
> format returns '??' for mfs devices:
>
> $ stat -f %Sd /bin/cat
> wd0a
>
> $ stat -f %Sd /var/db/libc.tags
> ??
>
> The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out
> reporting a read-only filesystem, which is not correct.
>
> I noticed this with syspatch66-010_libcauth.tgz which looks to be the
> first patch that changes files in /var (like /var/db/libc.tags).
>
> $ syspatch
> Get/Verify syspatch66-010_libcaut... 100% |*************| 17685 KB    00:03
>
> Installing patch 010_libcauth
> Read-only filesystem, aborting
>
> $ mount
> /dev/wd0a on / type ffs (local)
> /dev/wd0g on /home type ffs (local, nodev, nosuid)
> /dev/wd0f on /usr type ffs (local, nodev, wxallowed)
> /dev/wd0d on /mfs type ffs (local, nodev, nosuid)
> mfs:37162 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=524288
> 512-blocks)
> mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid, size=524288
> 512-blocks)
> mfs:40334 on /dev type mfs (asynchronous, local, noexec, nosuid, size=8192
> 512-blocks)
> /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid)
> _a_host_:/some/nfs/export on /mnt/_an_nfs_mount_ type nfs (noexec, v3, udp,
> timeo=100, retrans=101)
>
> Can work around it by modifying the check on line 98.  Is it OK to allow
> mfs filesystems?
>
> Is the major number for mfs uniquely 255?
>
> $ stat -f %Hd /var/db/libc.tags
> 255
>
> $ stat -f %Hd /mnt/_an_nfs_mount_
> 22

Thanks for the report.
It is expected yes.
Actually having /var mounted over MFS is absolutely not supported (because this
is where we store rollback tarballs and where syspatch checks to see whether a
particular patch has been installed).
I will make that check stronger so that syspatch fails right away on MFS-mounted
/var.



--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Antoine Jacoutot-6
On Sun, Dec 08, 2019 at 12:01:37PM +0100, Antoine Jacoutot wrote:

> On Fri, 2019-12-06 at 09:26 -0500, Art Manion wrote:
> > Environment:
> > System      : OpenBSD 6.6
> > Details     : OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 00:59:03 MST 2019
> > [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> > Architecture: OpenBSD.i386
> >
> > Description:
> >
> > syspatch adds up the sizes of existing files to be replaced and collects
> > the device names:
> >
> >  91                 stat -qf "_dev=\"\${_dev} %Sd\";
> >  92                         local %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" ${_files})
> > \
> >  93                         2>/dev/null || _rc=$?
> >
> > then checks that devices are mounted and are not read-only:
> >
> >  97         for _d in $(printf '%s\n' ${_dev} | sort -u); do
> >  98                 mount | grep -v read-only | grep -q "^/dev/${_d} " ||
> >  99                         sp_err "Read-only filesystem, aborting"
> >
> > I have a system with /var and /tmp mounted as mfs.  The stat string
> > format returns '??' for mfs devices:
> >
> > $ stat -f %Sd /bin/cat
> > wd0a
> >
> > $ stat -f %Sd /var/db/libc.tags
> > ??
> >
> > The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out
> > reporting a read-only filesystem, which is not correct.
> >
> > I noticed this with syspatch66-010_libcauth.tgz which looks to be the
> > first patch that changes files in /var (like /var/db/libc.tags).
> >
> > $ syspatch
> > Get/Verify syspatch66-010_libcaut... 100% |*************| 17685 KB    00:03
> >
> > Installing patch 010_libcauth
> > Read-only filesystem, aborting
> >
> > $ mount
> > /dev/wd0a on / type ffs (local)
> > /dev/wd0g on /home type ffs (local, nodev, nosuid)
> > /dev/wd0f on /usr type ffs (local, nodev, wxallowed)
> > /dev/wd0d on /mfs type ffs (local, nodev, nosuid)
> > mfs:37162 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=524288
> > 512-blocks)
> > mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid, size=524288
> > 512-blocks)
> > mfs:40334 on /dev type mfs (asynchronous, local, noexec, nosuid, size=8192
> > 512-blocks)
> > /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid)
> > _a_host_:/some/nfs/export on /mnt/_an_nfs_mount_ type nfs (noexec, v3, udp,
> > timeo=100, retrans=101)
> >
> > Can work around it by modifying the check on line 98.  Is it OK to allow
> > mfs filesystems?
> >
> > Is the major number for mfs uniquely 255?
> >
> > $ stat -f %Hd /var/db/libc.tags
> > 255
> >
> > $ stat -f %Hd /mnt/_an_nfs_mount_
> > 22
>
> Thanks for the report.
> It is expected yes.
> Actually having /var mounted over MFS is absolutely not supported (because this
> is where we store rollback tarballs and where syspatch checks to see whether a
> particular patch has been installed).
> I will make that check stronger so that syspatch fails right away on MFS-mounted
> /var.

Ah I misread that you have /var/syspatch on UFS.
Ok then the behavior you are seeing is to be expected; we don't want to install
updated files to an ephemeral fs.
That said, the error message could be more useful.

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Art Manion
On Sun, Dec 8, 2019 at 6:08 AM Antoine Jacoutot <[hidden email]>
wrote:


> > > I have a system with /var and /tmp mounted as mfs.  The stat string
> > > format returns '??' for mfs devices:
> > >
> > > $ stat -f %Sd /bin/cat
> > > wd0a
> > >
> > > $ stat -f %Sd /var/db/libc.tags
> > > ??
> > >
> > > The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out
> > > reporting a read-only filesystem, which is not correct.
>


> > > mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid,
> size=524288
> > > 512-blocks)
> > > /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid)
>


> > > Can work around it by modifying the check on line 98.  Is it OK to
> allow
> > > mfs filesystems?
>


> > Actually having /var mounted over MFS is absolutely not supported
> (because this
> > is where we store rollback tarballs and where syspatch checks to see
> whether a
> > particular patch has been installed).
> > I will make that check stronger so that syspatch fails right away on
> MFS-mounted
> > /var.
>
> Ah I misread that you have /var/syspatch on UFS.
> Ok then the behavior you are seeing is to be expected; we don't want to
> install
> updated files to an ephemeral fs.
> That said, the error message could be more useful.


Understood. I'm OK dealing with my non-supported choice of mounting /var as
mfs.

The checks in question are about disk space, if the (valid!) concern is
about losing rollback files, I'd suggest an explicit check that
/var/syspatch is sane (local, UFS, whatever else). Every previous syspatch
on this system worked, only syspatch66-010_libcauth.tgz failed since it
happened to include new files destined for /var.

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Antoine Jacoutot-7
On Sun, Dec 08, 2019 at 02:56:58PM -0500, Art Manion wrote:

> On Sun, Dec 8, 2019 at 6:08 AM Antoine Jacoutot <[hidden email]>
> wrote:
>
>
> > > > I have a system with /var and /tmp mounted as mfs.  The stat string
> > > > format returns '??' for mfs devices:
> > > >
> > > > $ stat -f %Sd /bin/cat
> > > > wd0a
> > > >
> > > > $ stat -f %Sd /var/db/libc.tags
> > > > ??
> > > >
> > > > The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out
> > > > reporting a read-only filesystem, which is not correct.
> >
>
>
> > > > mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid,
> > size=524288
> > > > 512-blocks)
> > > > /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid)
> >
>
>
> > > > Can work around it by modifying the check on line 98.  Is it OK to
> > allow
> > > > mfs filesystems?
> >
>
>
> > > Actually having /var mounted over MFS is absolutely not supported
> > (because this
> > > is where we store rollback tarballs and where syspatch checks to see
> > whether a
> > > particular patch has been installed).
> > > I will make that check stronger so that syspatch fails right away on
> > MFS-mounted
> > > /var.
> >
> > Ah I misread that you have /var/syspatch on UFS.
> > Ok then the behavior you are seeing is to be expected; we don't want to
> > install
> > updated files to an ephemeral fs.
> > That said, the error message could be more useful.
>
>
> Understood. I'm OK dealing with my non-supported choice of mounting /var as
> mfs.
>
> The checks in question are about disk space, if the (valid!) concern is
> about losing rollback files, I'd suggest an explicit check that
> /var/syspatch is sane (local, UFS, whatever else). Every previous syspatch
> on this system worked, only syspatch66-010_libcauth.tgz failed since it
> happened to include new files destined for /var.

There is already a check.
Your /var/syspatch is on FFS, that's why it worked for previous syspatches.
But your /var/db is not, which is why it refused to install the new one.
The behavior is perfectly correct.

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Stuart Henderson
FWIW I've run various systems with partitions replaced with MFS (usually
copying from HD at boot and syncing back to HD at shutdown). This makes
sense for some directories but I came to the conclusion that doing this
for the rest of /var is more trouble than it's worth, in particular
it's easy to get out of sync between /var/db and files installed on
persistent storage.

My recommendation if you want to reduce active disk writes there would
be MFS /var/run (and /var/cache if you have things that use it), but
FFS for the rest of /var, use syslog memory-buffers for "standard"
logging (and if there are more important things, you can easily keep
writing them to /var/log on a facility/level or per-source basis).

syspatch should give correct messages in error cases but I don't think
the behaviour otherwise really needs to change.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Art Manion
In reply to this post by Antoine Jacoutot-7
On Mon, Dec 9, 2019 at 3:01 AM Antoine Jacoutot <[hidden email]>
wrote:


> > The checks in question are about disk space, if the (valid!) concern is
> > about losing rollback files, I'd suggest an explicit check that
> > /var/syspatch is sane (local, UFS, whatever else). Every previous
> syspatch
> > on this system worked, only syspatch66-010_libcauth.tgz failed since it
> > happened to include new files destined for /var.
>
> There is already a check.
> Your /var/syspatch is on FFS, that's why it worked for previous syspatches.
> But your /var/db is not, which is why it refused to install the new one.
> The behavior is perfectly correct.


Right, should have looked before I posted.

Thanks,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Art Manion
In reply to this post by Stuart Henderson
On Mon, Dec 9, 2019 at 5:55 AM Stuart Henderson <[hidden email]> wrote:

> FWIW I've run various systems with partitions replaced with MFS (usually
> copying from HD at boot and syncing back to HD at shutdown). This makes
> sense for some directories but I came to the conclusion that doing this
> for the rest of /var is more trouble than it's worth, in particular
> it's easy to get out of sync between /var/db and files installed on
> persistent storage.
>
> My recommendation if you want to reduce active disk writes there would
> be MFS /var/run (and /var/cache if you have things that use it), but
> FFS for the rest of /var, use syslog memory-buffers for "standard"
> logging (and if there are more important things, you can easily keep
> writing them to /var/log on a facility/level or per-source basis).
>
> syspatch should give correct messages in error cases but I don't think
> the behaviour otherwise really needs to change.
>

Thanks I'm going to more or less follow this advice.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Marko Cupać
In reply to this post by Antoine Jacoutot-6
On Sun, 08 Dec 2019 12:01:37 +0100
Antoine Jacoutot <[hidden email]> wrote:

> Actually having /var mounted over MFS is absolutely not supported
> (because this is where we store rollback tarballs and where syspatch
> checks to see whether a particular patch has been installed).

With all due respect, where in official OpenBSD documentation can one
read more about "having /var mounted over MFS is absolutely not
supported"? Lately I see more and more of these ad-hoc proclamations in
"trust me" style without nothing more than mailing list post to back
them up.

> I will make that check stronger so that syspatch fails right away on
> MFS-mounted /var.

Way to go...

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

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

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Claudio Jeker-3
On Thu, Dec 12, 2019 at 03:33:00PM +0100, Marko Cupać wrote:

> On Sun, 08 Dec 2019 12:01:37 +0100
> Antoine Jacoutot <[hidden email]> wrote:
>
> > Actually having /var mounted over MFS is absolutely not supported
> > (because this is where we store rollback tarballs and where syspatch
> > checks to see whether a particular patch has been installed).
>
> With all due respect, where in official OpenBSD documentation can one
> read more about "having /var mounted over MFS is absolutely not
> supported"? Lately I see more and more of these ad-hoc proclamations in
> "trust me" style without nothing more than mailing list post to back
> them up.

You changed the FS type from the default used by the installer and expect
us to document for this case? You have it reverse. Where in the
documentation does OpenBSD tell you that using a MFS mounted /var is
perfectly OK and will not cause any trouble?
You ripped off the warranty sticker by using a non persistent file system
for a partition that includes things like:
                backups/   Miscellaneous backup files.
                db/        Miscellaneous, automatically generated system-
                           specific database files.
                sysmerge/  Checksum files and reference sets for sysmerge(8).
                syspatch/  Rollback tarballs and patch files for syspatch(8).

It should be fairly clear that these directories should not sit on a file
system that loses all changes on reboot or powerloss.
 
> > I will make that check stronger so that syspatch fails right away on
> > MFS-mounted /var.
>
> Way to go...

Guess it has to be done to protect us from people like you.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Marko Cupać
On Thu, 12 Dec 2019 17:07:59 +0100
Claudio Jeker <[hidden email]> wrote:

> You changed the FS type from the default used by the installer and
> expect us to document for this case?

Oh, I see. So, what's next? "You changed mediaopt in hostname.if from
default used by the installer and expect us to support it, or to
document it once we don't support it anymore?"

> You have it reverse. Where in the
> documentation does OpenBSD tell you that using a MFS mounted /var is
> perfectly OK and will not cause any trouble?

More than a decade of using it in such way without any problems
whatsoever told me it used to be perfectly OK. Now you are telling me
it was undesired feature which has to be taken away?

> You ripped off the warranty sticker

I have always despised warranty stickers, and they were always first
thing to be ripped off my stuff. I am sad to see you, of all people (I
have deep respect for your work on OpenBSD) pulling this wording.

> by using a non persistent file
> system for a partition that includes things like:
>                 backups/   Miscellaneous backup files.
>                 db/        Miscellaneous, automatically generated
>                            system- specific database files.
>                 sysmerge/  Checksum files and reference sets for
>                            sysmerge(8).
>                 syspatch/  Rollback tarballs
>                            and patch files for syspatch(8).

I have enough understanding of administering OpenBSD to know the
importance of those partitions. I also know how and when to sync them to
persistent storage, and to pull them out of there while mounting them
as mfs's.

> It should be fairly clear that these directories should not sit on a
> file system that loses all changes on reboot or powerloss.

It is crystal clear to me what happens to these directories on reboot
or powerloss, mfs or ufs or nfs or a few other fs's. Does OpenBSD
nowadays optimise for lowest common denominator?

> Guess it has to be done to protect us from people like you.

Right, "you're with us or you're against us". I almost feel honoured to
hear "people like me" are a threat to "you", against which protective
measures need to be taken.

Anyway, for those who still need to syspatch their mfs'd setups, I've
updated my article with workaround description, and whole install
procedure and patching procedure will be ready by the end of next week.
People interested in this thread probably know where to find it.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Theo de Raadt-2
In reply to this post by Marko Cupać
Marko Cupać <[hidden email]> wrote:

> On Sun, 08 Dec 2019 12:01:37 +0100
> Antoine Jacoutot <[hidden email]> wrote:
>
> > Actually having /var mounted over MFS is absolutely not supported
> > (because this is where we store rollback tarballs and where syspatch
> > checks to see whether a particular patch has been installed).
>
> With all due respect, where in official OpenBSD documentation can one
> read more about "having /var mounted over MFS is absolutely not
> supported"? Lately I see more and more of these ad-hoc proclamations in
> "trust me" style without nothing more than mailing list post to back
> them up.

You did something custom.  We are not writing software for your weird
tweak.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Theo de Raadt-2
In reply to this post by Marko Cupać
Marko,

The software comes without warranty, and you don't get to yell at
developers about what they should do.

Maybe Linux does what you want?


Marko Cupać <[hidden email]> wrote:

> On Thu, 12 Dec 2019 17:07:59 +0100
> Claudio Jeker <[hidden email]> wrote:
>
> > You changed the FS type from the default used by the installer and
> > expect us to document for this case?
>
> Oh, I see. So, what's next? "You changed mediaopt in hostname.if from
> default used by the installer and expect us to support it, or to
> document it once we don't support it anymore?"
>
> > You have it reverse. Where in the
> > documentation does OpenBSD tell you that using a MFS mounted /var is
> > perfectly OK and will not cause any trouble?
>
> More than a decade of using it in such way without any problems
> whatsoever told me it used to be perfectly OK. Now you are telling me
> it was undesired feature which has to be taken away?
>
> > You ripped off the warranty sticker
>
> I have always despised warranty stickers, and they were always first
> thing to be ripped off my stuff. I am sad to see you, of all people (I
> have deep respect for your work on OpenBSD) pulling this wording.
>
> > by using a non persistent file
> > system for a partition that includes things like:
> >                 backups/   Miscellaneous backup files.
> >                 db/        Miscellaneous, automatically generated
> >                            system- specific database files.
> >                 sysmerge/  Checksum files and reference sets for
> >                            sysmerge(8).
> >                 syspatch/  Rollback tarballs
> >                            and patch files for syspatch(8).
>
> I have enough understanding of administering OpenBSD to know the
> importance of those partitions. I also know how and when to sync them to
> persistent storage, and to pull them out of there while mounting them
> as mfs's.
>
> > It should be fairly clear that these directories should not sit on a
> > file system that loses all changes on reboot or powerloss.
>
> It is crystal clear to me what happens to these directories on reboot
> or powerloss, mfs or ufs or nfs or a few other fs's. Does OpenBSD
> nowadays optimise for lowest common denominator?
>
> > Guess it has to be done to protect us from people like you.
>
> Right, "you're with us or you're against us". I almost feel honoured to
> hear "people like me" are a threat to "you", against which protective
> measures need to be taken.
>
> Anyway, for those who still need to syspatch their mfs'd setups, I've
> updated my article with workaround description, and whole install
> procedure and patching procedure will be ready by the end of next week.
> People interested in this thread probably know where to find it.
>
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Ingo Schwarze
In reply to this post by Marko Cupać
Hi Marko,

this thread comes across as needlessly confrontational.

Everybody can indeed re-configure OpenBSD or change parts of it
however they like (because it is free software with respect to
license permissions), even in ways that would be a very bad idea
for most other people - like /var on MFS for the reasons Claudio
explained, but you are welcome if it works for your use case.

The more unusual the changes, the higher the probability that they
have downsides, or that downsides appear at a later point, so users
doing configuration changes should be prepared to fix those downsides
on their systems - which they can because it is free software in
the sense of open source.

While we do sometimes include CAVEATS against *very* widespread,
very dangerous programming or configuration errors in manual pages,
we almost never document "don't do this unusual thing" because there
are infinitely many things that people might do that cause problems.
Instead, we document how the system works: both how it works by
default, and what the various options do.  It should not be a surpise
that there are combinations of options that don't work well together
out of the box - in this case using syspatch(8) (using it is
optional!) together with /var on MFS.  Neither should it come as a
surprise that such incompatibilities evolve over time.

Both syspatch(8) and hier(8) document that syspatch(8) stores
information in /var/syspatch/, and it should be easy to deduct
from the context that not being able to store that information
persistently seriously obstructs the operation of syspatch(8).

While OpenBSD is a general-purpose operating system, it doesn't
come with warranty stickers in the first place but it is also a
research project: we are always striving to make OpenBSD better in
innovative ways, so change is inevitable and indeed desired.  For
example, much less than a decade ago, the syspatch(8) program that
now clashed with your unusual configuration didn't even exist.
Besides, many improvements to security require deprecating possibilities
that are used rarely and entail risks - even if some people rely on
them.  It happens all the time, in all parts of the system.

That said, specific suggestions to keep the manual pages up to date
are always welcome, but please strive to suggest specific wording
improvements better but still concisely explaining how things work,
*not* in the style of "don't do this unusual thing".  By the very
definition of "unusual", people doing such things must figure out
themselves which downsides those specific changes might have, using
the positive information from the manuals.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Marko Cupać
In reply to this post by Theo de Raadt-2
On Thu, 12 Dec 2019 10:27:58 -0700
"Theo de Raadt" <[hidden email]> wrote:

> The software comes without warranty, and you don't get to yell at
> developers about what they should do.

I am sorry if my words were interpreted as yelling. I thought I was
engaging in insightful argument :) As for the warranty, I think you
described the situation much better than analogy with the sticker,
that's how I see things as well.

> Maybe Linux does what you want?

Nope, OpenBSD is orders of magnitude more suitable for this particular
use case than Linux, or even FreeBSD.

> You did something custom.  We are not writing software for your weird
> tweak.

Actually you _are_ writing software which works great even with my weird
tweak. Syspatch is a drop in the ocean of OpenBSD goodness. I can still
use all of the other great components without any problems whatsoever.
Hell, I can, with very little effort, further tweak my weird tweak so
syspatch can continue to update my weird setups, and that is also great.

Once again, thanks to all OpenBSD developers for all the great stuff
they provide. Still, I think syspatch have no real reason to refuse
updating mfs-based file systems. And I also think that "component X of
OpenBSD won't do Y" should not be worded as "not supported by OpenBSD".

Regards,

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

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

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Theo de Raadt-2
Marko Cupać <[hidden email]> wrote:

> And I also think that "component X of
> OpenBSD won't do Y" should not be worded as "not supported by OpenBSD".

Look, you are wrong.  People who can commit get to make that decision
and your opinion doesn't matter.

We are not going to write code for your crazy tweak.  Because as soon as
we do, someone will create an even crazier tweak, and then yell that it
should be supported also.

No.  It ends here.

What you are doing has so many risks, and it is your own mess to deal with.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch breaks calling stat on mfs filesystem

Marko Cupać
On Thu, 12 Dec 2019 11:13:28 -0700
"Theo de Raadt" <[hidden email]> wrote:

> No.  It ends here.

Understood :D

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

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