Re: CVS commit: src/usr.sbin/postinstall

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Thu, Jun 13, 2019 at 17:07:36 -0000, Christos Zoulas wrote:

> In article <20190613112930.GR17040%pony.stderr.spb.ru@localhost>,
> Valery Ushakov  <uwe%stderr.spb.ru@localhost> wrote:
> >On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote:
> >
> >> On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote:
> >> > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote:
> >> > 
> >> > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote:
> >> > > > [...]
> >> > > > I've been using etcupdate for ages so I only ever really used
> >> > > > postinstall to fix "obsolete" and "catpages".  etcupdate -a has some
> >> > > > kinks and may be we should concentrate on fixing those instead?
> >> > > 
> >> > > I *never* used etcupdate, so for me it's better to have a working
> >postinstall
> >> > > (I have a PR about it: install/52349, which may have been fixed by the
> >> > > recent change)
> >> > 
> >> > The rc.d part is probably addressed by this very change that Christos
> >> > made (that i was replying to).
> >> > 
> >> > The other part is exactly what I'm talking about.  postinstall does
> >> > NOT update your system to the new etc.tgz set, it cherry picks stuff
> >> > from the new etc.tgz.
> >> 
> >> It should create files and directory that are expected to be there
> >> but are not.
> >
> >That "should" seems to be the crux of the matter.  It seems that
> >different people think that postinstall should do different things.
> 
> >Most new files added to etc that were not previously there are not
> >needed to boot your system with its old etc (shinynewd may be hip and
> >progressive, but if that system ran without it, it will happily
> >continue to run without it for the time being).  My conception of
> >postinstall has always been that it takes care specifically about
> >those rare cases where a new file in etc *is* required to keep the
> >system operational and you, for whatever reasons, can't/don't want to
> >do a full etc update.  I may be misremembering, it's been about 15
> >years, please correct me if I do.
> 
> No, this is correct (most shiny new files are not needed). There are
> problems though:
> 1. Files that get updated sometimes need the new files (npf for example
>    recently), and break otherwise.

Was that file that get updated also in etc, as I understood from your
private comments - in which case the new file won't be there since you
still have mostly old etc, right?

If something in the base set changes that requires a coordinated
update to the configuration in etc then yes, that's the prime thing
for postinstall to fix, as I understand.

Consider e.g. ssh check that moves existing(!) /etc/ssh* files to
/etc/ssh/*


> 2. There is significant amount of work to keep things synchronized over.
>    There are multiple places people need to edit when adding/removing stuff
>    and this is error prone.

Right.


> 3. Keep upgrading and you end up missing more and more files in
>    /etc.  What's the mechanism *in base* to help you keep them in
>    sync.

etcupdate(8)?

I've been using it all this time, since Martti committed it to base.
I used it to upgrade very old machines (my mr.coffee hasn't been
booted in a decade since 2007 and I upgraded it in 2017 and it was all
very smooth).

As I said, it has its kinks.  Special handling for passwd/group would
be very nice and -a (automatic) should really install new files
without asking.  Other then that I really love it.  Adding a bit more
user-friendliness to it might be in order simpley because most people
that don't track current only use it may be once in a couple of years,
so some handholding in this rather delicate task of merging new etc
would definitely help to reassure them.


> 4. Unpacking sets installs programs, postinstall deletes programs. This is
>    driven from the sets. OTOH their respective rc files don't get installed
>    or removed from postinstall; this seems inconsistent to me. For example,
>    dhclient got removed as a program, the rc file is still there.
>    The automount stuff got installed as programs the rc files did not.

postinstall fix obsolete will delete programs, yes, but it should not
be run blindly.  Say, oldd is removed from base, as long as you don't
run fix obsolete, you should be fine.  Except, as I mentioned, fix rc
seems to also delete obsolete rc files, in which case fix rc might
screw your system by deleting oldd rc script (while the oldd itself
and oldd.conf are still in place).

fix obsolete and fix catpages are really quite orthogonal to the rest
of postinstall.  As I said, I use etcupdate, and obsolete and catpages
are the only postinstall fixes that I need to use.  So for fix rc to
delete stuff seems a bit reckless.  Again, as I said, after etcupdate
fix obsolete will take care of obsolete etc stuff b/c you will get new
/var/db/obsolete/etc

When the automount staff got installed, again, that doesn't affect the
current configuration of the system as embodied in the state of its
etc.  You can't use the new stuff untill you do proper full etc update.


> I think that the desire here is for postinstall is to be a very safe process
> that keeps the system up-to-date with minimal (or zero risk). The question is
> how to achieve that? We have risk added because of the manual process of
> keeping lists of things that postinstall does, and at the same time we have
> risk added by inadvertently adding and running things that were not there
> before. But this is not postinstall's fault. We should design things so
> that they need to be explicitly enabled by the user. And there is gray
> areas, like npf_boot which changes the functionality of the system.
> 
> I would like postinstall to improve in these three areas (in priority order):
> 1. Make postinstall as safe as we can, by designing the installed files
>    properly and blacklisting the dangerous ones.
> 2. Automate as much of it as possible so that there are fewer mistakes
>    or omissions, and less work to be done.
> 3. Keep /etc as much in sync with a newly installed system, without
>    breaking (1).

I see two basic scenarios here.

1) install new sets except etc, run only postinstall (without
postinstall fix oboslete!!!) to do minimal fixup of the etc to get the
new system booting with its old configuration

2) install new sets, use etcupdate to merge new etc.  run postinstall
fix obsolete when ready.

postinstall currently is kinda between 1) and 2).  If you try to move
it forward to 2) you will be more or less reinventing etcupdate that
we already have.

-uwe