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