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

[christos%astron.com@localhost (Christos Zoulas)]

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.
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.
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.
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.

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).

christos