"Steven M. Bellovin" <smb@cs.columbia.edu> writes:

> In message <200503090948.19761@gryphon.flame.org>, Michael Graff writes:
> 
> >My major gripes are that building on one machine and rsync'ing the
> >binaries out is becoming a major pain recently.  I guess it's time
> >to start some sort of cvs pool for my /etc config files, and some
> >smart script to detect changes to /etc and to (perhaps) propagate
> >them into other machine's configs during /usr rsync.
> >
> >pkgsrc is really making this harder every day, but I'm just told I'm doing
> >something odd and it would be easy if I just followed these simple steps
> >provided by lots of helpful yet not-doing-what-I'm-doing people.  (insert
> >about 20 annoyingly tedious steps here)
> 
> We really need to think seriously about this; it's my biggest single 
> gripe about running NetBSD.  I run two different clusters, one tracking 
> -current and one on 2.0; they all tend to have slightly different 
> configurations and needs for packages.  It's mostly harmless to have 
> extra packages installed, of course (I overprovision disk space when I 
> can), but trying to build and move appropriate change sets -- patches, 
> bug fixes, new builds of -current, etc. -- is a royal pain.

I have about 25 machines running a locally-modified version of CVS.
I don't like some of the default contents of /etc, so I've changed it
in my own repository (with netbsd on the vendor branch).  I update
machines by making a release, rsyncing that over, and running a script
that unpacks the kernel and all sets but etc.  It then unpacks etc.tgz
someplace else, and runs 'etcmanage' (about which I've posted before)
which is like 'etcupdate -a' but has the ability to initially register
files with known checksums.  The script also removes outdated packages
and adds the new ones (I rsync those too).  I will move to pkg_chk now
that it can run without pkgsrc present.

I also generate most config files on most machines with a Scheme
program, and store those in /usr/sinew/etc, and then another script at
update time copies them in place (ifconfig.*, dhcpd.conf, quagga
configs, etc.)

This doesn't help with merging changes to files that the release can
change and are locally changed as well.  New accounts in
/etc/master.passwd are one of my biggest remaining headaches.

I think what my etcmanage tool does that etcupdate doesn't is

  from a DESTDIR, generate a manifest of md5 (yes, I know, but this
  isn't about security) checksums of the files in etc (+
  dev/MAKEDEV*).

  Given a manifest, check each file and if the checksum matches,
  record in the database the file and checksum.

On update, I think they both do

  if the file in /etc's checksum matches the database, and the file is
  in the new DESTDIR and different, install it and update database.
  If the file is not present in DESTDIR, remove it and update the
  database.

  If the file in /etc matches the one in DESTDIR, and the stored
  checksum does not match, update the stored checksum.  [This is
  necessary to clean up after postinstall 'helpfully' updates files in
  /etc/rc.d.  This exposes the fact that some things in /etc don't
  really belong in etc.tgz, but some do.  It's not clear that it is
  any more reasonable/normal to /etc/rc.d/foo than a shell script in
  /bin.]


One can always symlink files in /etc into a shared dir (nfs or rsync,
same thing really), and thus get shared behavior.

As for ease of rsyncing and etc files, it might be interesting to look
at how other systems deal with this.



-- 
        Greg Troxel <gdt@ir.bbn.com>