On 7 25, Hubert Feyrer wrote:
> On Fri, 24 Jul 1998, Tim Rightnour wrote:
> > anything else to do the same..  Having mysql run itself is fine.. just shut the
> > !@#$ thing off before leaving the config.. I don't like finding out I have a
> > service I didn't even know was running on my machine a few days later..
> 
> Sure not, but you decide to have the service when you pkg_add/make 
> install whatever you're doing.
> 
> I've helped setting up some machine for some Linux wheenie recently, and 
> wow was he surprised some things did *not* work out of the box after 
> pkg_add... certainly things like adding things to config files like the 
> apache modules.

  This is one of the major drawbacks of Linux installation systems!  When I
install, e.g., httpd, it's because I want it present for future use _after_
I've had a chance to properly configure it and make sure the configuration
is as secure as I can make it.  I absolutely do _not_ want it to start running
out of the box--that's a security hole by any reasonable definition.  This is
one of the principal reasons why Linux boxes are such popular targets for
hackers--users install things they think they might want to try out, and
then they forget about (or are unaware of) the fact that they're actually
running, often with some convenient but insecure default configuration,
exposing them to network attacks.

  Let's not emulate bad habits just because they're habits.  A post-installation
script that can be run by the user to actually start things up if that's what's
desired sounds like a very reasonable solution to me--it requires minimal
effort on the part of the user, but protects us all from premature startup
of services that incur risks.

> You wouldn't mind any shell-pkg modifying /etc/shells either.

  That's much less risky than starting up daemons, though I would prefer that
/etc/shells not be changed by default, and a message be issued that warns the
user that it should be modified if ftp service is to work for users of that
shell.

> The deal if the pkg system was and is to make things for _users_ as easy 
> as possible.

  Yes, but not at the cost of making NetBSD systems too easy to configure
insecurely--I'd _really_ hate to see NetBSD become the kind of popular hacker
target that Linux has become.

> Introducing any additional manual intervention is bad.

  Not if it's minimal.