Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 07:02:44AM -0400, Michael Stone wrote:
> On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> > sorry, it's you who needs to wake up to the real world.
> >
> > if people don't know how to administer a unix machine then they need
> > to learn fast.
>
> Not true.
you discredit your argument with silly assertions like this.
> Maintaining a unix-like machine for desktop or personal use requires
> a different skill set than a machine used as a server. People using
> linux as a windows replacement or because they want to see what linux
> is *don't need* a bunch of services enabled *by default*.
if they "*don't need* a bunch of services enabled *by default*" then
they shouldn't install the packages that provide those services. most
workstations do not need a pop or imap server, very few need an ftp
server.
those workstation users who install these packages have to take
responsibility for their own actions, and they should be presumed to
know what they are doing.
> > no amount of molly-coddling by the distribution authors (i.e. us) is
> > going to obviate that essential requirement. maintaining security on
> > your own systems requires personal knowledge and experience, it can
> > not be done by proxy.
>
> Agreed, for machines that need public services. But I'm talking about
> defaults. Can you come up with a reason we *need* a bunch of stuff
> enabled by default?
if a service isn't needed then don't install the package that provides
that service. what is so difficult to understand about that?
it's not as if people are forced to install rsh or telnet servers any
more. Anthony has done a great job of splitting up netbase so that
these packages are now optional extras.
> > the "we-know-better-than-you" attitude is what redhat and caldera
> > (and microsoft, for that matter) does. it sucks. debian has always
> > done better than that
>
> This is empty "we're better than them propaganda". Debian already
> makes choices in what services are installed and enabled by default.
> It does not follow that changing the *existing* list of services we
> enable by default implies a "we-know-better-than-you" attitude.
ok, i see the communication problem now...why we're going round in
circles on this point. i think we're talking about completely different
things here.
i'm not talking about what debian chooses to have installed by default
(i.e. base/required packages).
i'm talking about the current practice of postinst scripts in various
packages enabling the services that they provide (if any). i am not
talking at all about which packages are base or required or extra or
whatever - i'm talking specifically and ONLY about what the postinst
scripts of packages do when they are installed. install a package which
provides a daemon and it *should* be enabled in the postinst. if you
don't want the service it provides then don't install the package.
of course, if debconf or something can provide a mechanism for the
system admin to globally choose whether to enable or not enable services
when they are installed then that is even better. but until we have such
a mechanism, such packages should do what they always done and enable
themselves at install time.
> A system with daemons disabled will always have a better guarantee of
> security than one with daemons enabled. In the not-so-distant past we've
> shipped systems with a vulnerable telnetd and a vulnerable ftpd enabled
> *by default.*
which is one of the reasons why they are now split off from the netbase
package - so that people can choose whether they want these services
installed or not.
splitting netbase was the right solution to that problem...installing
stuff but leaving it disabled is a PITA, not a solution to a problem.
more to the point, it's a bigger and more annoying problem than the one
it is purported to solve.
> > why run debian (with all it's useful tools like update-inetd and
> > update-rc.d and so on) if you're going to throw away those advantages?
>
> Why does changing default behavior throw away advantages? What prevents
> you from using those tools if you want them?
the advantage of these tools is that packages can enable the services
they provide when they are installed. they don't provide much (if any)
benefit to the casual command-line user - it's easier to edit inetd.conf
manually than it is to remember the args for update-inetd.
craig
--
craig sanders
Reply to: