On Tue, Oct 22, 2002 at 11:37:34PM -0400, Greg A. Woods wrote:

> > It maybe just because I use pkgsrc on a machine I don't have root on
> > and
> 
> You _really_ probably should _NOT_ try using pkgsrc if you aren't
> allowed to be root.  Many things cannot install properly without being
> installed by root.  Obviously setuid programs won't work, nor as
> you've noticed can you make use of rc.d scripts.  Pkgsrc really does
> need the installs to be done as root, which is why when you run "make
> install" as a non-root user it first asks you for the root password.

It works fine thanks, with minimal patches.  I'm hardly not going to not
use pkgsrc at all just because it's not "the done thing" to do it
without root privs.  I've never needed a suid program from pkgsrc, and
have not until now needed NetBSD-style rc.d functionality (as x11/xfstt
used to provide a generic /bin/sh script).  It would be foolhardy for me
to dump all this and go back to "./configure;make;make install", and no
doubt create a hundred times more headaches.

> > run into "problems" which others don't hit, but it still strikes me as
> > odd that these variables are set such:
> > 
> > RCD_SCRIPTS_DIR?=       /etc/rc.d
> > RCD_SCRIPTS_EXAMPLEDIR?=        ${PREFIX}/etc/rc.d
> > 
> > Is there something which means we can't just leave pkgsrc startup
> > scripts in ${PREFIX}/etc/rc.d and run them from there?
> 
> Indeed there is a reason.   The generic configuration cannot assume that
> ${PREFIX} is on the root filesystem, and therefore that's not a suitable
> place for the scripts to be run from, by default.

That doesn't make sense to me.  If ${PREFIX} isn't on the root
filesystem, then the script will fail anyway because it can't run the
program in question.

> There's been a great deal of discussion over this very issue in the
> past, and the final decision has been that by default rc.d scripts
> should be installed as examples in ${PREFIX}/etc/rc.d and that
> administrators be instructed to copy those scripts into /etc/rc.d when
> they wish to "enable" the package (and of course they probably still
> have to set a flag variable in /etc/rc.conf to actually "turn on" the
> package).
 
Sure, fair enough.  I wonder why I had that $slapd problem then, because
I can be certain that I never enabled it in /etc/rc.conf

> > Not only for people like me who can't write to /etc
> 
> Note that if you can convince your system to run scripts or programs on
> reboot that you have installed, then you can very easily obtain root
> privileges on that system!  ;-)  That's a back door about as wide as the
> galaxy, if not wider.

Yes, makes sense, although the root-owned /etc/rc.conf would still need
to be told where user-specified ${PREFIX} is.

> > but also for read-only mounted / installs.
> 
> Huh?  That doesn't make sense.  You normally don't/can't do maintenance
> on a system when the root filesystem is mounted read-only.  You can't
> even effectively use some standard NetBSD features if the root
> filesystem is mounted read-only.  For example nobody could ever change
> their password on such a system.

Yes, and?  It makes perfect sense for organisations like ourselves who
need remote encoders and the like and never write to /, so prefer to
reduce the risk of root filesystem corruption by mounting read-only.  I
would also imagine many people in the embedded market would make use of
such a feature.

I was midly disappointed when moving from FreeBSD to NetBSD to find that
it was a much harder task to bring up my workstation with a read-only /,
as even on my desktop I hardly make use of writes to /, and am perfectly
willing to spend the time remounting the filesystem to do maybe one
change per week, if the rest of the time I'm safe in the knowledge that
it's much more likely to stay intact.

> >  Also makes more sense in keeping pkgsrc separate to base.
> 
> No, not really, it doesn't at all.  The whole point of "packaging"
> software is to carefully manage which files belong to which packages.
> While there's no default integration yet with the lists of files which
> belong to the main system, this isn't far in coming.  Once you know
> the origin and "ownership" of each file then there's absolutely no
> need for artifical separation of files from different origins into
> different hierarchies and such inappropriate complication can be done
> away with.
 
I was under the impression that pkgsrc was designed as a portable
package manager, and as such would run many different operating systems.
Obviously different operating systems have different ideas on how to
implement /etc/rc.d, and installing a NetBSD-style xfstt.sh in /etc/rc.d
on a RedHat box may not have the desired effect.

Either pkgsrc is NetBSD-only or it isn't.  If it is, then the current
implementation is correct.  If not, then it needs work to ensure
NetBSD-style scripts function correctly on non-NetBSD systems and are
handled properly by the host OS' init style.  From your mail, I get the
impression that the first is true, however if that's not the case, I
would like to help work on implementing the second.

> > A quick search also and I don't see a /usr/pkg/etc/rc.conf equivalent.
> > Worth implementing one?
> 
> No, definitely not.  All "local" startup configuration settings are in
> /etc/rc.conf (and /etc/rc.conf.d/*), whether it be for packages or base
> system software.
> 
> The only thing that might be worth implementing would be to install
> examples for the default "${rcvar}=whatever" and
> "${rcvar}_flags=whatever" values for package rc.d scripts into
> ${PREFIX}/etc/rc.conf.d/${name} and recommend that admins also copy
> these files to /etc/rc.conf.d when they enable a package.  This way
> smarter handling of defaults could be done for packages as well.

-- 
Jonathan Perkin - Internet Operations Engineer - BBC Internet Services
24x7 Hotline: +44 (0)1628 407 777 (x37777) - http://support.bbc.co.uk/