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
