Subject: Re: Thoughts on more helpful upgrading
To: Paul Hoffman <phoffman@proper.com>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 01/16/2001 22:24:37
In message <p05010414b68abc89c2d0@[165.227.249.17]>, Paul Hoffman writes:
>
>1) Password files
>
>It seems incredibly unlikely to me that anyone would not want their
>users and passwords on the upgraded system. Making someone guess
>which files they need to copy out of /etc.old seems wrong (I had to
>keep trying over and over since there were more files than I knew
>about). I propose that instead of what we do today (move the entire
>/etc to /etc.old and start fresh), we instead copy the fresh password
>files (group, master.passwd, passwd, pwd.db, spwd.db) to a new
>directory, /etc.fresh, and copy the old password files from /etc.old
>to the new /etc.
Strong agreement.
>
>2) Additional files
>
>If the /etc.old has some files that do not exist in the fresh /etc,
>they should be copied to /etc. That is, there seems no reason not to
>keep around files that have been put in /etc by the user that we are
>sure won't affect the new boot. This certainly means ifconfig.* and
>conf files of programs that are not booted automatically.
You have to be careful about this one. You're clearly right about
ifconfig.*, but what about things affected by, say, the new rc
structure? What about user-created changes to printcap? I think that
two things are needed for this to work. First, the installer has to
have pretty good knowledge of certain classes of files -- what to copy,
what to update, etc. Second, given that /etc isn't that large, I
suggest that there be a shadow copy put in at installation, never to be
touched by the user; its purpose is to provide something for the
installer to compare against. This would let it, say, compare /etc/rc
to see if it's been touched, and if not just install the new /etc/rc.d
subsystem instead. But it has to have a base copy to compare against,
because you don't want it to need intimate knowledge of 1.4, 1.4.1, etc.
--Steve Bellovin, http://www.research.att.com/~smb