[ On Saturday, February 9, 2002 at 19:06:04 (-0600), Frederick Bruckman wrote: ]
> Subject: Re: Summary: Third-party rc.d scripts
>
> Well, currently, ${PKG_SYSCONFDIR} defaults to ${PREFIX}/etc, so
> that's a boon for the fellow who wants to share configs between 300
> machines.

Yes, very well fine and good, except for host-specific config files,
such as most notably and most importantly some of those for SSH (and
many other examples can be trotted out for specific uses of any number
of other packages).  Such files cannot be shared since they are, by
definition, host-specific.

In the case of security/ssh the current default startup script will
helpfully generate the most necessary host-specific files, though the
way it does so might be in conflict with some site's security policy.

Indeed there are many ways that configuration files can be made less
host specific, but depending on the application, the environment, and
indeed the amount of effort one wishes to put into maintaining modified
packages, this is not always possible or pragmatic.  As a result the
default of PKG_SYSCONFDIR may actually conflict with the needs of
someone trying to share ${PREFIX} amongst many clients -- it all depends
on what packages they happen to use and perhaps also how they use them.

> Honestly, put yourself in his position. Which is easier: 1)
> arrange to run pkg_install on each host, for each package you install
> on the server, each time you install it, or 2) tar up a template
> "etc.tar.gz" on the server, with the dangerous parts missing (myname,
> ifconfig.<if>), and pull it down and reboot each host after all the
> packages are installed.

There are so many possible factors to this issue that no one answer can
ever be right for everyone.  However in general the first option, if
it's implemented, is the one that's going to be guaranteed to always
work for all packages and it may actually be the easier option too
(depending on how well planned the overall setup procedures are, and how
static the machines are, what they are used for, etc.).

One way or another some procedure must be followed to configure each
host, even if the clients share the majority of their files on some
commonly accessed file server.  If a well defined procedure is made
available in canned form for locally "activating" packages installed on
a shared file server then it can be invoked as part of the procedure
used to configure each host.

What's important here is to realise that packages may have host-specific
configuration files, just as the system itself does.  If NetBSD's pkgsrc
is to properly and full support the sharing of installed packages then
some mechanism needs to be invented which manages these files in a
consistent manner and which can be automated so as to facilitate mass
configuration of many hosts.

As has also been pointed out if it is to really be complete such a
procedure also needs a way to register to the server which packages have
been "activated" on a given client host.  This way when a package is
updated any new host-specific files can be added to a given client
host's local configuration directory; and the server administrator will
find out if any clients will be affected should a package be deleted,
etc.


Alternately perhaps it's best if pkgsrc simply declare that the sharing
of installed packages is not officially supported, and people who need
to do such sharing can work out their own local hacks for any of the
specific pacakges they use which might require host-specific
configuration.  Hints can be documented for appropriate settings for the
like of PKG_SYSCONFDIR, and so on, just as we now have hints for setting
up diskless clients, but no canned procedures.  Perhaps they'll be lucky
and none of the packages they use will have host-specific configuration
files.  :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>