Packages should not Conflict on the basis of duplicate functionality
Scott K. Ellis
> service. There is no reason that these three packages cannot
> coexist on the same system. Any namespace overlap can be
> solved by alternatives or renaming, as such things are normally
> rectified.
> Debian policy should proscribe such inconveniences.
Okay, then solve the problem of which one should actually work on the
standard port? You can't use update-alternatives if the software is
launched in a different manner. If you have such an advanced setup, it
isn't really that hard to build it yourself, or use --force.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Clint Adams
> standard port? You can't use update-alternatives if the software is
Well, I would prefer that things didn't start listening for connections
without asking first, but I can't imagine that that's a popular suggestion.
> launched in a different manner. If you have such an advanced setup, it
> isn't really that hard to build it yourself, or use --force.
And if I did an apt-get dist-upgrade, I would get this:
Reading Package Lists... Done
Building Dependency Tree... Done
You might want to run `apt-get -f install' to correct these.
Sorry, but the following packages have unmet dependencies:
cucipop: Conflicts: pop3-server
Conflicts: qpopper but <version> is installed
gnu-pop3d: Conflicts: pop3-server
E: Unmet dependencies. Try using -f.
And if I were to do an apt-get -f dist-upgrade, it would remove
gnu-pop3d and qpopper, leaving cucipop.
So what you're telling me is that anyone with a "complex" setup
shouldn't bother using Debian?
Scott K. Ellis
> > standard port? You can't use update-alternatives if the software is
>
> Well, I would prefer that things didn't start listening for connections
> without asking first, but I can't imagine that that's a popular
suggestion.
That arguement has gone on many times (check the list archives), but the
gist of the matter is that if you don't want it to start, why did you
install it (dpkg --unpack works wonders).
> > launched in a different manner. If you have such an advanced setup, it
> > isn't really that hard to build it yourself, or use --force.
>
> And if I did an apt-get dist-upgrade, I would get this:
>
> Reading Package Lists... Done
> Building Dependency Tree... Done
> You might want to run `apt-get -f install' to correct these.
> Sorry, but the following packages have unmet dependencies:
> cucipop: Conflicts: pop3-server
> Conflicts: qpopper but <version> is installed
> gnu-pop3d: Conflicts: pop3-server
> E: Unmet dependencies. Try using -f.
>
> And if I were to do an apt-get -f dist-upgrade, it would remove
> gnu-pop3d and qpopper, leaving cucipop.
Of course. Now if you built them yourself, dpkg wouldn't touch them.
> So what you're telling me is that anyone with a "complex" setup
> shouldn't bother using Debian?
People who want such "complex" setups should have enough sense to be able to
figure out how to make them work, without imposing additional difficulty on
the maintainers for such a rare case. There is not generally a use for more
than one POP server, ident server, mail server, etc. I can find exceptions,
but it isn't Debian's job to make every possible configuration easy, just
the most likely and typical ones.
Clint Adams
If I wanted to build them myself, I would use Slackware.
If I repackage them I will need to remove the Conflicts line from
the control files every single time I upgrade.
> People who want such "complex" setups should have enough sense to be able to
> figure out how to make them work, without imposing additional difficulty on
> the maintainers for such a rare case. There is not generally a use for more
> than one POP server, ident server, mail server, etc. I can find exceptions,
> but it isn't Debian's job to make every possible configuration easy, just
> the most likely and typical ones.
The most likely and typical configurations are those for a home workstation.
So let's screw anyone who wants to use Debian on a production server.
I run apache and roxen on the same machine. That's hardly typical.
Why on earth would anyone want to run two different web servers?
These two packages should obviously conflict since they're both
web servers and want to grab port 80.
They both provide httpd; should I file bugs against them demanding that
they conflict with it too?
Herbert Xu
>> These packages don't conflict; they merely provide the same
>> service. There is no reason that these three packages cannot
>> coexist on the same system. Any namespace overlap can be
>> solved by alternatives or renaming, as such things are normally
>> rectified.
>> Debian policy should proscribe such inconveniences.
> Okay, then solve the problem of which one should actually work on the
> standard port? You can't use update-alternatives if the software is
> launched in a different manner. If you have such an advanced setup, it
> isn't really that hard to build it yourself, or use --force.
FWIW, the current practice when it comes to things like identd is not to
conflict with each other but be alert when you add entries to inetd.conf.
There is a very good historic reason why this is so, because identd used to
be part of netstd, so if you conflicted with that, you'd be conflicting with
a whole bunch of stuff that you can't live without of. Even though this is
no longer the case, I think we should definitely keep the same mechanisms in
place since there is no reason why we can't have multiple identd's installed,
or multiple fignerd's, etc. as long as they don't overlap in their fs
namespace.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <her...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Colin Walters
> > If you want to run two httpd's, popd's or mta's, you'll probably have to
> > do more than the usual tweaking to the package setup anyway, so what is
> > really the big deal of having to:
> >
> > 1. `apt-get source foo`
> > 2. edit various files, mostly in debian/
> > 3. add an epoch to the package version
> > 4. `fakeroot debian/rules binary`
> > 5. `sudo dpkg -i foo.deb`
>
> What's really the big deal of having to
>
> 1. apt-get install apache roxen
>
> By putting an epoch in the version number you defeat the whole automatic
> upgrade system.
>
> > If you must insist that these matters be resolved formally, then please be
> > so generous to provide us with some reference implementations of a generic
> > /usr/sbin/{httpd,popd,smtpd}-config.
>
> I see absolutely no need for an httpd-config. I'm perfectly happy
> with they way apache, apache-ssl, and roxen coexist.
And of course you can always do dpkg --force-conflicts. I believe that's what
the --force commands are really there for: special situations.
--
Colin Walters <walte...@osu.edu>
http://web.verbum.org/levanti
PGP Fingerprint: 2951 C835 FB23 82D4 3969 EDB5 08D9 B9EA 7D30 CC26
Clint Adams
> the --force commands are really there for: special situations.
Broken situations. Sure, you can --force dpkg to overwrite files
from another package. But Debian prefers to fix the problem instead.
A. Wrasman
Also most daemons should fail binding to a port if multiple ones are installed and they automatically
start. So unless they have conflicting files they shouldn't conflict. Instead of conflicting
each package that suplies foo-daemon should just spit out an warning message on install saying that
there are multiple packages installed that provide foo-daemon and each package that provides foo-daemon must be manually configured to receive predictable usage.
I know at my day job we have development servers that maintain multiple versions of various
packages, such as cobol, informix and internally written packages. While these aren't running
on Debian or even linux in most cases most of these packages would have unpredictable usage if people didn't change environment variables or config files so they know which one they are using at any one instance.
We also have a webserver that has three differemt webservers on it (even though they are all derived from apache.)
Raz
Martin Bialasinski
* "Michael" == Michael Stone <mst...@debian.org> wrote:
Michael> On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote:
>> The Doctor What wrote:
>> > Why shouldn't *all* daemon packages ask these questions, and whether to even
>> > run *upon install*?
>>
>> Because we need to decrease the number of questions asked at install time,
>> not increase it.
Michael> Bzzt. Security is more important than usability. We're not
Michael> building windows 2000 here...
Ii I install a daemon, I want to use it. So it is the obvious step to
automatically activate it. Debian packages installed should be usable
without further manual steps. This is why no program may depend on
environment variables. This is why any programm has to ship a default
config if possible.
If you fear for security, then the default config of this package is
not good enough, not the fact that it is shipped in a "ready to use"
condition.
Ciao,
Martin
Raul Miller
> > Ii I install a daemon, I want to use it.
Do you want it for personal use, or do you want it available as a
public service?
--
Raul
John Hasler
> Ideally, if debconf were used, this one question would be asked the first
> time you install a daemon, and all other daemons would inherit it
> thereafter. Quite easily done with debconf..
That's the ideal, but what is the policy now? Should chrony ask a question
in its postinst or start up chronyd without permission? Right now policy
seems to me to strongly oppose questions but say nothing about starting
daemons.
--
John Hasler
jo...@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Martin Bialasinski
* "Raul" == Raul Miller <ra...@usatoday.com> wrote:
Raul> On Sat, Sep 25, 1999 at 10:11:17AM -0400, Michael Stone wrote:
>> > Ii I install a daemon, I want to use it.
Raul> Do you want it for personal use, or do you want it available as a
Raul> public service?
If I install a finger daemon, I want it running with secure
defaults at once. I do not want it to give information only on me and only to
me. If I need a more specific setup, I change the config.
I expect a package I install to be fully functional at once. I don't
want to set some environment variables, I don't want to edit a config
file, if a good default is possible (and I find this the case on most
Debian packages). For daemons. I expect then to be operating right
after apt-get install. YMMV.
Ciao,
Martin
Brian May
>Which reminds me, it might be nice for Debian to run something akin to a
>port scanner locally from cron.daily or something, so that the sysadmin
>will notice such problems better. (Optionally, and not reporting ports
>that the sysadmin knows are OK.)
How about something like (beware - quick hack):
netstat -a | grep -vE '(kerberos|finger|ftp|pop-3)'
That will list all connections and active ports, except for those
with kerberos, finger, ftp and pop-3 listed.
I imagine it would be easy to make that more robust, but you should get
the general idea. Perhaps you may only want to include lines with *:* so
that active connections are not counted.
--
Brian May <b...@snoopy.apana.org.au>
Chris Rutter
> They both provide httpd; should I file bugs against them demanding that
> they conflict with it too?
I think this is a good point; it doesn't seem to be a clear area
of policy. It sounds like perhaps some new system needs to be
implemented. Perhaps a Suspicious: line in the control file, which
will mirror Conflicts:, except only elciiting a warning to the
user? Or perhaps a simple flag is required to override it?
What is wrong with the semantics of `dpkg --force-conflicts' as it
stands? That it confuses packages like `apt-get', whinging about
broken packages, or some other reason?
I think any deeper idea (such as a database of `claimed' ports in
/etc, or something) would be ugly, and best avoided in the name of
non-intervention.
--
Chris <ch...@fluff.org> ( http://www.fluff.org/chris )
Brian May
>stands? That it confuses packages like `apt-get', whinging about
>broken packages, or some other reason?
If both packages contain the same file with exactly the same
functionality, there is no problem.
However, if both packages contain a different implementation of the
same file (or even worse - a completely different program with the same
name), then things will break, depending on what order the
programs are installed in.
The warning messages produced when a file does conflict have a tendancy
to scroll of the top of the screen, and unless you are paying attention,
there is no way (that I know of) to find what files (if any) conflict
after installing multiple packages. If I submit a bug report
against package X, how are you, the maintainer to know that
it is broken, because an important file, eg /usr/bin/z was overwritten
by packge Y, which does something completely different?
Also, --force-conflicts can hide other serious problems. eg if your
package diverts a file, but with the wrong package name, when dpkg
unpacks it, it will overwrite the original file.
--
Brian May <b...@snoopy.apana.org.au>
Raul Miller
> > Perhaps there are people who want a "service enabled by default" policy,
> > and perhaps we should accomodate them. However, I'm not one of them
> > and I don't want any services turned on on some of my machines without
> > my explicit ok.
On Mon, Sep 27, 1999 at 01:05:58PM +1000, Craig Sanders wrote:
> then don't install those services. installing a package *IS* an explicit
> OK.
You're saying that packages reliably say when they provide daemons?
> you've been using debian long enough to know that this is the way it
> works....and IMO, it is the way it should work. i don't want to have to
> fuck around with explicitly turning services on when i install them - if
> i didn't want them to run then i wouldn't have installed them.
I wasn't trying to suggest that you should.
--
Raul
Chris Rutter
> However, if both packages contain a different implementation of the
> same file (or even worse - a completely different program with the same
> name), then things will break, depending on what order the
> programs are installed in.
This is true, and would need extra heuristics in the packaging
policy/system to cope with this. All conflicting files could be
given names that wouldn't clash (prefix them with the first letter
of the package name, or whatever), and then diversions/symlinks
used.
> The warning messages produced when a file does conflict have a tendancy
> to scroll of the top of the screen, and unless you are paying attention,
> there is no way (that I know of) to find what files (if any) conflict
> after installing multiple packages. If I submit a bug report
> against package X, how are you, the maintainer to know that
> it is broken, because an important file, eg /usr/bin/z was overwritten
> by packge Y, which does something completely different?
Um, yes, it's a difficult one, but I don't think the problem is
*that* wide-spread. I agree with the Apache and Roxen example --
I have wanted to do this as a quite straight-forward thing before,
but I think few packages will have big difficulties.
This won't list all diversions/etc., but you can always diff the
output of `dpkg -L' against two packages to see if files conlict.
Or maybe I mean `sort | uniq -d' -- of course this doesn't help
if some people have chosen /usr/X11R6/bin and some /usr/bin/X11,
for instance. I'm sure a trivial utility could be made to do this.
I suggest you compile a list of these sorts of problems, and set
about trying to fix them in a sane way, if you have time.
--
Chris <ch...@fluff.org> ( http://www.fluff.org/chris )
Sean 'Shaleh' Perry
> So what you're telling me is that anyone with a "complex" setup
> shouldn't bother using Debian?
>
a) I would not test a new daemon on a working machine, I would use a separate
one. In the case of gnu pop3, it will spin off and consume 99% of your cpu due
to poor child management. We (I am one of the developers) are fixing this, but
currently it is test quality if not run from inetd.
b) if you know what you are doing, compile the packages by hand, fix their
install scripts, and remove the conflicts. You are trying to circumvent the
norm.
Debian is operating on making the easy case easy. 90+% of our users want to
just install a package and go.
Franklin Belew
> > a) I would not test a new daemon on a working machine, I would use a separate
>
>
> > b) if you know what you are doing, compile the packages by hand, fix their
> > install scripts, and remove the conflicts. You are trying to circumvent the
> > norm.
>
> Debian packaging system?
>
> > Debian is operating on making the easy case easy. 90+% of our users want to
> > just install a package and go.
>
> 90+% of our users probably don't run production servers. Is there some
> reason you don't want to cater to 100% of our users if possible?
>
Example:
I run gnome, I keep the debian packages installed in the normal location
I compile cvs every once in awhile into /usr/local/gnome
I have the knowlege to do this, and anyone who plans on running something unstable, or outside the "norm" should also have the knowlege to do this.
Now I haven't looked into it much, but debconf may be able to help.
If it is as powerful as it looks, you could put a question on some daemons asking if you will be running more than one instance, and if so configure accordingly. I will personally never do this on a production machine, but if you wish to research it further, I suggest you research debconf
Frank aka Myth
PS: I know my lines are longer than 76 characters, fix your own pager/viewers wordwrap
--
Some people claim that the UNIX learning curve is steep,
but at least you only have to climb it once.
Clint Adams
> microsoft, for that matter) does. it sucks. debian has always done
> better than that - our way is to encourage people to learn to do it for
> themself by not trying to hide the fact that knowledge and experience is
> required (not just optional or "would be nice" but absolutly required)
You don't think that "you only can have one daemon for a particular
service and it's going to be turned on by default" is representative
of the "we-know-better-than-you" attitude?
Craig Sanders
> > 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 - our way is to encourage people to learn to
> > do it for themself by not trying to hide the fact that knowledge and
> > experience is required (not just optional or "would be nice" but
> > absolutly required)
>
> You don't think that "you only can have one daemon for a particular
> service and it's going to be turned on by default" is representative
> of the "we-know-better-than-you" attitude?
no, because debian doesn't fuck up configuration by forcing you to
go though some stupid and limited GUI interface (try doing something
non-standard with network interface setup on RH and you'll know what
i mean - you can't do it...actually, you can if you spend enough time
figuring out their setup but you risk that your custom mods will be
blown away the next time someone runs the stupid GUI configurator).
debian's attitude is: if you want something different, DIY. and more
importantly, it lets you DIY.
craig
--
craig sanders
Clint Adams
> importantly, it lets you DIY.
Err.. what Unix DOESN'T let you DIY?
Craig Sanders
> > debian's attitude is: if you want something different, DIY. and more
> > importantly, it lets you DIY.
>
> Err.. what Unix DOESN'T let you DIY?
read the rest of my message. the bit that ranted about unix's that
get in the way of DIY. RH is one. sun's Netra is another...both are
examples of how NOT to do configuration management on unix.
craig
--
craig sanders
Clint Adams
> get in the way of DIY. RH is one. sun's Netra is another...both are
> examples of how NOT to do configuration management on unix.
No. You're talking about doing something your way and then having
it wrecked by the RH/whatever way. And if you decide to do something
your way in conflict with the Debian way, Debian may wreck your work
too.
If I'm running /usr/local/sbin/sillycommercialpop3d, or
/opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck,
and I want to install php72-pop3 which Requires pop3-server,
and I naively apt-get install php72-pop3, not thinking it would
require a local pop server or thinking that my pop server should
be sufficient, I'd probably end up with a nice little tagalog
pop server that installs itself in inetd and steals the port.
There are two simple solutions to this. Either you do it the
Debian way and package up sillycommercialpop with a Provides
pop3-server and maybe a Conflicts pop3-server if you're feeling
vindictive, and then you install the deb, or you never rely
on Debian's automation again.
When I recommend to people that they use kernel-package
instead of DIY, they are usually a bit shocked.
Francois Gurin
> 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 - our way is to encourage people to learn to do it for
> themself by not trying to hide the fact that knowledge and experience is
> required (not just optional or "would be nice" but absolutly required)
the "minimum hassle/inconvenience" attitude? I agree. Sounds harmfull.
> > When we ship a system with a bunch of stuff enabled by default,
> > we're not only putting their machine at risk but we're also creating
> > problems for everyone else who's system is attacked by someone using
> > the debian machine as a jump-off point. That's bad.
>
> that's bad. it's also bullshit. enabling daemons by default is not
> inherently a security problem.
And why can't there be an option to determine this? You avoided that
point.
Maybe "you-know-better-than-I"..
> if they don't need it then they shouldn't install the package.
And if the package has a dependency?
There are many situations dealing with the package system that can
lead to daemons installing without your knowledge. mtools for potato
includes floppyd, if someone upgrades a slink machine to potato,
should floppyd be automatically started?
not all packages start daemons automatically. Some ask. Wouldn't it
be keen if Joe Bloe knew what to expect?
--francois
Craig Sanders
> And why can't there be an option to determine this? You avoided that
> point.
no i didn't. i answered it in another message.
to paraphrase: i am against messing with the current default. i am not
against (indeed, i am in favour of) increasing choice.
if it is possible to add that choice without screwing anything up and
without being a pain in the arse then i am all in favour of it.
> > if they don't need it then they shouldn't install the package.
>
> And if the package has a dependency?
> There are many situations dealing with the package system that can
> lead to daemons installing without your knowledge. mtools for potato
> includes floppyd, if someone upgrades a slink machine to potato,
> should floppyd be automatically started?
if mtools needs floppyd to run and the user has chosen to install mtools
then yes. the user want mtools to work, they don't want mtools to work
ONLY if they do some weird and obscure thing (even if it IS documented
in the debian changelog, it is still weird and obscure unless they
happen to be aware of the fact that this major change has occurred)
which they never needed to do in the past...
in other words, mtools used to just work, it should continue to just
work after an upgrade.
> not all packages start daemons automatically. Some ask. Wouldn't it
> be keen if Joe Bloe knew what to expect?
those that ask, shouldn't. there are already way too many stupid
questions in postinst scripts.
if (via debconf or whatever) there is a way for users to voluntarily
specify that they want daemon packages to ask then that would be
fine...but it should take some deliberate action on the user's part
before they get these annoying questions.
craig
--
craig sanders
Craig Sanders
> > read the rest of my message. the bit that ranted about unix's that
> > get in the way of DIY. RH is one. sun's Netra is another...both are
> > examples of how NOT to do configuration management on unix.
>
> No. You're talking about doing something your way and then having
> it wrecked by the RH/whatever way. And if you decide to do something
> your way in conflict with the Debian way, Debian may wreck your work
> too.
debian provides methods of having your cake and eating it too. it
provides tools for integrating your custom changes into the debian
system so that you don't ever have to worry about the system screwing up
your custom stuff.
> If I'm running /usr/local/sbin/sillycommercialpop3d, or
> /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck,
> and I want to install php72-pop3 which Requires pop3-server,
this is what the dummy package (or whatever it is called is for). fake
up as many Provides: lines as you need.
> and I naively apt-get install php72-pop3, not thinking it would
> require a local pop server or thinking that my pop server should
> be sufficient,
if you suffer from this naivety then you need to cure it. expecting
software to magically perform some miracle is not going to help you do
anything but dig yourself into a much deeper hole.
> I'd probably end up with a nice little tagalog pop server that
> installs itself in inetd and steals the port. There are two simple
> solutions to this.
this would be a problem caused by insufficient knowledge/experience on
the part of the operator. don't fix the symptom, it'll just come back
again...fix the cause instead.
> Either you do it the Debian way and package up sillycommercialpop with
> a Provides pop3-server
yep, this is another good way of doing it. like the dummy package you
get to DIY and still retain the benefits of the packaging system.
if you don't like that, then there distributions which don't provide
such useful system administration tools. try slackware, for example.
> When I recommend to people that they use kernel-package instead of
> DIY, they are usually a bit shocked.
kernel-package is a useful tool which helps to DIY. it doesn't conflict
with the notion of DIY at all, it makes it easier...especially if you
like to compile your kernels on your fastest machine and then ship them
out with scp to wherever they are needed.
Daniel Burrows
> > And if the package has a dependency?
> > There are many situations dealing with the package system that can
> > lead to daemons installing without your knowledge. mtools for potato
> > includes floppyd, if someone upgrades a slink machine to potato,
> > should floppyd be automatically started?
>
> if mtools needs floppyd to run and the user has chosen to install mtools
> then yes. the user want mtools to work, they don't want mtools to work
> ONLY if they do some weird and obscure thing (even if it IS documented
> in the debian changelog, it is still weird and obscure unless they
> happen to be aware of the fact that this major change has occurred)
> which they never needed to do in the past...
>
> in other words, mtools used to just work, it should continue to just
> work after an upgrade.
I think it really looks like this question will not be solved until debconf
is integrated into the distribution. floppyd is *not* required for mtools to
work, it's just an optional and obscure 'feature' (not to mention either an evil
or a clever hack :P) that most people aren't going to need (I wasn't even aware
it existed until someone brought it up here) It also sounds like a potentially
gaping security hole to me. In this case I think the only sane solution is to
shut it off by default. I believe there are other packages that have similar
situations (none spring to mind though) On the other hand, many things (like
exim, ftp daemons, and inetd) should start running as soon as they're installed
in most setups. (OTOH, a less promiscuous default inetd setup -- say, no ftp
or telnet -- might be good)
I don't really see any way to cleanly balance the needs of the four groups
(two groups of packages, and two groups of users) without debconf. With
debconf, it's laughably easy. Apologies if I have the idea of the system
wrong :), but I think we just need to make a single template for all daemon
entries, then specify the daemon name and the default setting (on or off) in
each daemon. To keep people who aren't interested in this from having to see
it, two things could be done. First, all the daemon-starting questions should
have a higher priority than normal questions (I don't remember all the
priorities now, but say maybe 2 above the 'total newbie' level). Second, an
additional option could be collected by the base packages (at the same priority
level) asking whether further daemon questions should be shown. (this might be a
little trickier)
Daniel
--
Going on about Dungeons and Dragons being tools of the devil is like guarding
the door while *it* is coming up through the floorboards...
The Demon Lord of Hla'Siloth may want to cut your soul up into a thousand
pieces, but at least he won't try to convince you that you haven't got one.
-- [ approximately ] Terry Pratchett, _Johnny and the Dead_
Raul Miller
> to paraphrase: i am against messing with the current default. i am not
> against (indeed, i am in favour of) increasing choice.
There is currently no default -- it varies on a per-package basis.
> ... there are already way too many stupid questions in postinst scripts.
Agreed, in general. On the other hand, slink was far worse than potato,
and a lot (most) of the questions I'm getting currently are conffiles.
--
Raul
Clint Adams
I note that
### to run vtund as a server on port 5000, uncomment the following line:
#--server-- 5000
isn't uncommented by default.
Raul Miller
On Thu, Sep 30, 1999 at 09:21:29AM -0400, Clint Adams wrote:
> I note that
>
> ### to run vtund as a server on port 5000, uncomment the following line:
> #--server-- 5000
>
> isn't uncommented by default.
Sure, but in the context of daemon processes that's not the one default:
that's just one of many many.
Are you saying you don't ever want any packages to change their
default? [Sounds rather draconian to me.]
Are you saying that there's some kind of debian default which you're
trying to preserve? [If so, what is it? ... note that if this default
is "reasonable behavior" then the definition of that default is almost
always what we're discussing.]
Or are you saying something else?
--
Raul
Clint Adams
I was merely pointing out the irony of one of Craig's packages
not enabling the daemon by default.
Craig Sanders
> On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote:
> > to paraphrase: i am against messing with the current default. i am not
> > against (indeed, i am in favour of) increasing choice.
>
update-inetd and update-rc.d pretty much establish what the current
default is. they are there to be used by the {pre,post}{inst,rm} to
enable and disable services at install/remove time.
craig
--
craig sanders
Craig Sanders
> > There is currently no default -- it varies on a per-package basis.
>
>
> ### to run vtund as a server on port 5000, uncomment the following line:
> #--server-- 5000
>
> isn't uncommented by default.
it isn't useful to run the vtund server until it is configured. there
is no "standard" configuration which is suitable for shipping as a
default - it MUST be customised for each site, each tunnel must be setup
individually.
given that, there is no point at all in running vtund until the user has
configured it to meet their needs.
other daemons, e.g. pop and imap, work with little or no configuration -
install them and they start working immediately. it is useful to enable
them at install time.
Craig Sanders
> On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> >
> > 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.
Eric Weigel
As a user, I have to say that the "Provides/Conflicts" that happens
with POP3 servers is annoying.
I wanted to look at each of ipopd, gnu-pop3d and cucipop. I could only
look at one at a time. It was ok in my case, because the machine I was
using has very little pop3 traffic. But it was awkward.
If I wanted to download source and recompile it, I would not be using
Debian. I like the package manager. I also like the thought that goes
into problems like this.
I'd like to see something like this:
WARNING:
you already have a pop3-server installed (cucipop)
starting ipopd automatically may cause problems
there are cases where running several pop3-servers
automatically makes sense: most of them require you to do
special configuration.
if you answer No to the following question, you can edit
"some configuration file", then run "some reconfiguration
program" to start ipopd without conflicting with the existing
pop3-server. Read /usr/share/doc/ipopd/somedocfile
for instructions on how to do this.
do you want ipopd to start automatically? (y/N)
WARNING:
you already have an http-server installed (apache)
starting apache-ssl automatically may cause problems
there are cases where running several http-servers
automatically makes sense: most of them require you to do
special configuration.
if you answer No to the following question, you can edit
/etc/apache-ssl/httpd.conf, then run "some reconfiguration
program" to start apache-ssl without conflicting with the
existing http-server. Read /usr/share/doc/apache-ssl/somedocfile
for instructions on how to do this.
do you want apache-ssl to start automatically? (y/N)
I am full aware that this doesn't solve all the problems. Some
services start from init.d scripts, some from inetd.
pop3 servers seem to mostly run from inetd. But someone may package
one that starts from an init.d script.
Sometimes, different protocols use the same port (ssh and ssh2 come to
mind) In the ssh case, one solution is to enable the "ssh1
compatibility" in the sshd2 configuration. Another is to run ssh1 or
ssh2 on a different port.
Pretty soon, there will be two DNS servers: some people will want to
run Bind as their main server, and test the new one on perhaps just one
IP address. A "Provides/Conflicts" in this case would (for me) really
really suck.
This is a problem that each person who packages a service that listens
on a port has to deal with. And more of a problem because different
implementations of such a service are packaged by different people.
Perhaps a general framework for dealing with the issue would help, if
it left room for each packager to handle things as the package
requires.
The following presumes that each package that provides a service will
provide a virtual package, "service-server", so that the potential
conflict can be detected and dealt with, and that when such a conflict
is detected, a nice long question is asked of the user, and the user
answers yes or no (with no being the default).
Something like:
if it starts from an init.d script, have the init.d script check for
the
existence of some configuration file. based on the content or
existence
of that file, start or don't start the service, configured as
appropriate.
if the user answers no to the auto-start question, make sure the
special
file is in the state which prevents the service from starting. provide
also a script in /usr/sbin to let the user turn on and off the
service,
and/or provide a document in /usr/share/doc/package which describes
how to do it (the document should exist, whether the script does or
not).
if it starts from /etc/inetd, put a line into /etc/inetd which would
start
the service, but commented out if the service should not be started by
default. in this case, the user will probably have to edit
/etc/services
and /etc/inetd to get the service started with no conflict. provide a
document in /usr/share/doc/package which describes how to do it. (i
omitted the script here because it seems to be taboo to edit
/etc/services
from any package except that which owns it)
I'm going to look at ipopd, gnu-pop3d, cucipop, apache, apache-ssl, ssh
and ssh2 to see how bad my idea is. I'll post what I find out.
If a framework like this makes sense, then no package has to know about
another package, and no packager has to know what another packager is
doing, so long as each package and packager "does the right thing" when
a potential conflict crops up.
The bottom line: let the user decide.
Eric
Bestnet Internet Inc
On Fri, 1 Oct 1999 10:28:03 +1000, Craig Sanders wrote:
>On Thu, Sep 30, 1999 at 08:34:48AM -0400, Raul Miller wrote:
>> On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote:
>> > to paraphrase: i am against messing with the current default. i am not
>> > against (indeed, i am in favour of) increasing choice.
>>
>> There is currently no default -- it varies on a per-package basis.
>
>update-inetd and update-rc.d pretty much establish what the current
>default is. they are there to be used by the {pre,post}{inst,rm} to
>enable and disable services at install/remove time.
>
Raul Miller
> 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 this is completely unreasonable in many cases. And, of course,
different package instances may or may not provide daemons and the
decision at the package level may have been for a different instance.
And, in general, there's more than one way to do it.
All of which make this current discussion rather... odd.
--
Raul
Bjoern Brill
On Wed, 29 Sep 1999, Clint Adams wrote:
> > debian's attitude is: if you want something different, DIY. and more
> > importantly, it lets you DIY.
>
> Err.. what Unix DOESN'T let you DIY?
Every Unix lets you DIY, of course. The problem is the *'/(&%
configuration done by most all distributions and commercial Unices. It
says: "do it our way or DIY everything". Now DIY everything is an option
if you've had several years of experience as Unix sysadmin, but how do you
get there? And why do you need a distribution involving years of work of
several hundred people then? ftp; configure; make install; vi /etc/foo
does it (maybe with some struggles in between).
What brought me to Debian is the "we provide a reasonably working setup
for most users, and if you don't like it you can go and DIY without f*ing
up all the rest and fighting some AutoMagicallyMisConfigured(TM) utility"
approach. Try SuSE's yast if you can't see the difference.
Debian isn't RH, but it isn't Slackware either. It has some of the goodies
of both sides. In the case of daemon configuration, there is still some
work to be done, however. Set up (sensibly) and start the first one
providing a service and leave following ones for DIY could be a good
solution.
Bj"orn Brill <br...@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
The Doctor What
> On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote:
>
> > The fantasy is over--WELCOME TO REAL LIFE! It turns out that some
> > people install Linux without preexisting knowledge of how to securely
> > administer a Unix machine.
>
> sorry, it's you who needs to wake up to the real world.
Excuse me. I work for TurboLinux. We make it an EXPLICIT policy to
disable all daemons, for Workstation and Server products. We also provide
a tool to manage these (turboservices and turbonetcfg).
I used to work for Tandem Computers, Tandem Computers had a similar policy
too.
While Mr. Stone is being a little extreme, this is the real world.
This is a security issue. More than that it is a matter of choice.
> if people don't know how to administer a Unix machine then they need
> to learn fast. 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.
Since all users should know Unix anyway, let us turn off all services
by default.
This is not my position.
I'm of the opinion that it should ask as Debian has no separate "Workstation"
or "Server" set up. If it really bothers you, then maybe a global switch
that sets whether daemons should just start up or ask first.
> > When we ship a system with a bunch of stuff enabled by default,
> > we're not only putting their machine at risk but we're also creating
> > problems for everyone else who's system is attacked by someone using
> > the debian machine as a jump-off point. That's bad.
>
> that's bad. it's also bullshit. enabling daemons by default is not
> inherently a security problem.
I would beg to differ. In some environments, having an unconfigured
server running for 30 seconds is too much. And don't tell me to
pulling the net cable. What if it's being installed via the net?
But security is not the only issue here. Choice is. Have a policy that
says all daemons should ask:
Should it start now, or be configured later
Should it use inetd, or run stand-alone?
Should it use the default port(s)? Or something else?
> if they don't need it then they shouldn't install the package.
There is a difference between installing a package, reading
the docs, seeing how it works in loop-back or an alternate port, and
installing a package to run now.
> 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?
If we ask the questions upon initial install, set the daemon the way we
want it, how are we throwing away Debian's tools? We are getting what we
want. If we want to only use half the tools, that's our perogative.
> it's damned annoying to see people trying to force their personal
> preferences on everyone else by making loud noises about trumped up
> nebulous and vague "security" issues. it would be nicer if such FUD were
> left behind in the proprietary software world.
No kidding. Security isn't the only issue here, but it part of this
discussion.
Ciao!
--
"I'm not a god, I was misquoted."
-- Lister (Red Dwarf)
The Doctor What: Un-Humble http://docwhat.gerf.org/
doc...@gerf.org (finger doc...@gerf.org for PGP key)
KF6VNC
The Doctor What
> The Doctor What wrote:
> > Why shouldn't *all* daemon packages ask these questions, and whether to even
> > run *upon install*?
>
> Because we need to decrease the number of questions asked at install time,
> not increase it.
According to who? I admit there a lot, and someone needs to issue
bugreports againts silly, redundant questions.... But until debconf, then
we are stuck with the current methods of configuring things.
By all means make it debconf, but these questions need to be asked.
Ciao!
--
"If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy."
-Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
The Doctor What: Need I say more? http://docwhat.gerf.org/
Craig Sanders
> Excuse me. I work for TurboLinux.
i don't give a damn who you work for.
> We make it an EXPLICIT policy to disable all daemons,
well, bully for you. i guess that must make you so proud.
if someone doesn't want a service enabled then they should not install
the package that provides that service. if they want the service, then
install the appropriate package. simple. their choice to install or not
install.
now what is so fucking difficult to understand about that?
> If it really bothers you, then maybe a global switch
> that sets whether daemons should just start up or ask first.
you must be some kind of genius to figure that out all by yourself. gee,
i wish i had of thought of that. i wish several other people in this
thread had thought of that. oh. that's right. we did. i guess you aren't
such a genius after all.
> I would beg to differ. In some environments, having an unconfigured
> server running for 30 seconds is too much. And don't tell me to
> pulling the net cable. What if it's being installed via the net?
DON'T INSTALL THE DAEMON IF YOU DON'T WANT TO RUN IT.
WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION?
this argument has gone way beyond the point of being tiresome, it is
tedious. it is especially tedious when some pompous cretin just spews
out trivialities based on some misunderstanding of the thread which is
explicable only by you not having read it.
no regards,
craig
--
craig sanders
Clint Adams
> is no "standard" configuration which is suitable for shipping as a
> default - it MUST be customised for each site, each tunnel must be setup
> individually.
When did "useful" enter this discussion?
pipsecd starts the daemon automatically even though no tunnel has
been set up, and even if userlink-modules hasn't been installed.
And even though it is of absolutely no use to you, the daemon
starts running when you install the package. And if there's some
sort of exploitable back door in the code, you're vulnerable.
But fine, you think security is a non-issue.
You seem to recognize at least one situation where it is
counterproductive for Debian to make an assumption about the
user's configuration. Why can you not recognize others?
Clint Adams
> if someone doesn't want a service enabled then they should not install
> the package that provides that service. if they want the service, then
> install the appropriate package. simple. their choice to install or not
> install.
>
> now what is so fucking difficult to understand about that?
The reasoning behind why anyone should share that opinion.
I'm at a loss. Sure, you can --unpack a deb to get to the
files without running the postinst or whatever starts these
evil daemons, but why should --install be synonymous with
"run"?
Josip Rodin
> I wanted to look at each of ipopd, gnu-pop3d and cucipop. I could only
> look at one at a time. It was ok in my case, because the machine I was
> using has very little pop3 traffic. But it was awkward.
>
> If I wanted to download source and recompile it, I would not be using
> Debian. I like the package manager. I also like the thought that goes
> into problems like this.
I'd like to propose something else: until the packages provide proper
debconf (or whatever) support which would configure the port and other
settings for the daemon, let's keep the Provides:+Conflicts: scheme we
have been using so far.
Let's admit it - the newbies[1] are the majority of Debian users. Most of
these newbie users will (usually by accident) try to install another POP3
daemon, it will stomp over an existing one, and the user will get problems
they will not know how to fix, at least not instantly.
I'm all for detailed configuration and enhanced settings and all that nice
stuff for sysadmins, but first, let's get it properly implemented in the
packaging system, the back bone. Until then, keep the default way safe
for the general use.
[1] note the difference between "newbie" and "lamer".
--
enJoy -*/\*- don't even try to pronounce my first name
The Doctor What
> I'd like to propose something else: until the packages provide proper
> debconf (or whatever) support which would configure the port and other
> settings for the daemon, let's keep the Provides:+Conflicts: scheme we
> have been using so far.
I would like to second the idea that debconf handle this when it is ready.
Personally, I'd like to see packages ask this question now, but the idea
seems to have gotten very hostile responses.
Ciao!
--
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor.
-- Wernher von Braun
The Doctor What: A Holtje Production http://docwhat.gerf.org/
doc...@gerf.org (finger doc...@gerf.org for PGP key)
KF6VNC
Craig Sanders
> > it isn't useful to run the vtund server until it is configured. there
> > is no "standard" configuration which is suitable for shipping as a
> > default - it MUST be customised for each site, each tunnel must be setup
> > individually.
>
> When did "useful" enter this discussion?
usefulness or utility has always been in this discussion. you should pay
more attention.
> pipsecd starts the daemon automatically even though no tunnel has
> been set up, and even if userlink-modules hasn't been installed.
>
> And even though it is of absolutely no use to you, the daemon
> starts running when you install the package. And if there's some
> sort of exploitable back door in the code, you're vulnerable.
> But fine, you think security is a non-issue.
if pipsecd turns out to have a security hole then that MUST be fixed
regardless of whether it is started at install-time or not. fixing
the bug is the solution to the problem. merely not starting it is no
solution at all, that's just hiding your head in the sand.
> You seem to recognize at least one situation where it is
> counterproductive for Debian to make an assumption about the
> user's configuration. Why can you not recognize others?
i have little interest left in this tedious thread, so i'll say this
once and once only. i really hope you can manage to understand it:
vtund was my package to create as i saw fit. I personally saw no need
to have the vtund running when it wasn't yet configured, so I personally
chose not to have it start until the user configured it. The maintainer
of pipsecd, according to your report, made a different choice. that is
their right.
this is not a matter for policy, this is not a matter where a tiny
minority of whiners can have artificial hysterics about fantasy security
issues and other FUD. my package, my decision. if you feel that the way
i manage my package is a problem, then file a bug report - i'll evaluate
that bug report and take whatever action (if any) i feel is appropriate.
ditto for the pipsecd package, Samuel can make up his own mind about how
to look after his package.
by the same token, packages containing other daemons belong to their
respective maintainers. if there is any conflict between differing
packages, then it is up to the relevant maintainers to sort out a
solution - e.g. the emacs and xemacs conflict...until the people
responsible for those packages put their heads together and figured it
out, it was not possible to have both installed at the same time. now,
it is no problem at all.
what this means is that if there is a great desire to have several pop
packages installed at once, then it is up to the maintainers of the pop
packages (and other interested parties) to come up with a way that can
be achieved without hassle, and without imposing stupid and onerous
burdens on the maintainers of unrelated packages.
craig
--
craig sanders
The Doctor What
> On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote:
> > I took care in my message above to remove anything offensive towards
> > Craig. Unfortunately Craig didn't do the same.
>
> garbage. you went out of your way to be offensive. to quote the opening
> line of your message:
>
> "Excuse me. I work for TurboLinux."
>
> you work for a "real" (i.e. commercial) linux distribution.
>
> anyone should be able to guess that that particular attitude is not
> going to go down well in debian-devel. it's akin to saying that
> proprietary software is better because the programmers get paid to write
> it (and, by logical extension, that free software authors are just
> amateur bumblers).
>
> i find posturing based on your employer to be particularly annoying -
> it's a blatant attempt to cash in on borrowed status. it doesn't work
> that way here, it's not who you work for that's important, it's what
> you've done.
The idea was not to say that "since I work for *a company* I'm an
authority". My point was that I work in the "real world" and have a
counter example. Perhaps that should have been phrased:
"As I work in the 'real world', at TurboLinux in fact, I consider my self
as at least a counter-example. We make it an EXPLICIT...."
Full Quote:
****************************************************************
On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote:
>
> > The fantasy is over--WELCOME TO REAL LIFE! It turns out that some
> > people install Linux without preexisting knowledge of how to securely
> > administer a Unix machine.
>
> sorry, it's you who needs to wake up to the real world.
Excuse me. I work for TurboLinux. We make it an EXPLICIT policy to
disable all daemons, for Workstation and Server products. We also provide
a tool to manage these (turboservices and turbonetcfg).
I used to work for Tandem Computers, Tandem Computers had a similar policy
too.
While Mr. Stone is being a little extreme, this is the real world.
This is a security issue. More than that it is a matter of choice.
****************************************************************
Please note that I don't say anywhere in the letter that you do not live in
the real world. I also don't say that you can't understand the obvious or
imploy any other methods to insult your intellegence. In fact, I try
hard not to put you down at all, though I must have failed.
You on the other hand show no thought for anyone else.
Quotes (out of context, but I think they speak for them selves):
"i don't give a damn who you work for."
"well, bully for you. i guess that must make you so proud."
"now what is so fucking difficult to understand about that?"
"you must be some kind of genius to figure that out all by yourself."
"i guess you aren't such a genius after all."
"WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION?"
"it is especially tedious when some pompous cretin just spews out
trivialities based on some misunderstanding of the thread which is
explicable only by you not having read it."
And finally, just to make sure we're all clear on the matter
"no regards, craig"
Note that those are verbatum and all are full sentences. I did not clip
short any sentences.
> > It is my hope that Craig Sanders reads this and thinks about what he
> > has done and why.
>
> very little of what i write is done without review and consideration of
> the effect of my words. i am a very deliberate writer. i presume that
> others are just as deliberate. if they're not, then they need to learn
> more caution and control over the language they use.
I'll take that at face value, and ignore yet another jib at me.
My last sentence was not to say that you write without review or
consideration of your words. I wanted you to know I was hurt. I thought
that if you were even slightly . . . empethetic, sympathetic, "human" . . .
that you'd reconsider, or at least see that stabbing at people isn't
productive.
But no, I see that isn't so. I'm sorry. I generally like people, work
hard to help even people who piss me off. I try to understand people. I
work to try to see why conflicts arise. I try to reach a consenses.
But that's where we differ, isn't it?
Bye,
Christian Holtje
--
"If only you'd listened to me, I could have saved you from all that yukkiness."
--Kryten (Red Dwarf)
The Doctor What: A Holtje Production http://docwhat.gerf.org/
doc...@gerf.org (finger doc...@gerf.org for PGP key)
KF6VNC
Hamish Moffatt
> "Excuse me. I work for TurboLinux."
>
> the implication here is that you know what you are talking about because
> you work for a "real" (i.e. commercial) linux distribution.
When in fact the opposite is true? :-)
Hamish
--
Hamish Moffatt VK3SB (ex-VK3TYD).
CCs of replies from mailing lists are welcome.
Hamish Moffatt
> On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote:
> In short, a summary (admittedly from my point of view) follows:
> In a discussion on whether network daemons should do one of the following:
> a) Simply start up, grabbing any ports it needs (most do this)
> b) Not start up (a few do this)
> c) Ask about what ports to grab and whether to start up (some do this)
>
> This letter is to make it public that I think Craig has gone too far. He
> has hurt my feelings and has been very insulting to everyone in
> debian-devel. And this is not the way to get things done.
Did you consider his point, though? Why would you install a service
if you don't want it to run?
> However, Craig's arguments have become increasingly hostile and insulting,
> building up to the message mentioned above. Being mean and insulting are
> not ways to get your point across.
It seems to me that he was just frustrated because you weren't
evening reading what he had to say.
Clint Adams
> don't intend to use it, why install it?
Perhaps you can explain where this idea comes from.
Of course, if I want to evaluate a daemon, I can --unpack the package
into /usr/local/testfun and manually enable it, evaluate it, and then
rm -r it. Sure, that's possible. And I can also compile it myself
from dsc and munge the install scripts. Or I can build it from
pristine source and stick it in /usr/local. So clearly nothing is
preventing me from reaching my desired ends even if it prevents the
preferable means.
But I install packages I don't intend to use. On certain systems
I'll install tcsh or csh. I have no intention of using them
(this is aside from any package that might require a csh provider),
but there is the potential for a user to want tcsh there sometime
in the future, and if he is not clueful to get it on his own,
he'll be okay because it's there. Having a shell package
going and changing users' shells on install would be horrific,
though I doubt anyone would dispute that.
There are daemons that can be run legitimately by a user on high
ports. Let's say you have a system where you let people run
web servers in user space. Luckily, roxen and apache don't
conflict with one another, so you can easily have both available
for users to use, and edit the configs so that neither of them
run on port 80 or any other system port. The daemons are being used;
they're just not being used in the "standard configuration."
On the downside, one cannot reasonably assume that if one installs
both packages that roxen will grab port 80 on bootup.
If you have packages conflict, then yes, you can be pretty certain
that the pop server you've installed is the one that will be grabbing
port 110 on all IPs, because any other pop server has been removed.
So if the consensus is that "debconf should handle it," why don't
we stop the flaming and whining and figure out the logistics of
the matter?
Anthony Towns
> The idea was not to say that "since I work for *a company* I'm an
> authority". My point was that I work in the "real world" and have a
> counter example.
And of course, everyone else on the list doesn't work in the "real world",
and just plays in their own little pointless sandpit. Feh.
That *is* offensive.
(And if we all do live in the "real world" then there's nothing special
about the fact that you do too, so you wouldn't bother pointing it out,
right? So since it was necessary to point it out, the rest of us must
be cloistered academics, or insulated children or something, yes?)
``I work for TurboLinux, and this is the way we do it...'' is all very
well.
``I work for TurboLinux. This is the way you should do it.'' is less so.
In any case, I fail to see how pressing `_' in dselect before any
unnecessary daemons are installed could possibly be less secure than
saying "No, I don't want services activated by default" and then
installing them anyway. This isn't about increasing security per se,
it's about either increasing choice (so you can install daemons even
if you don't want to run them for whatever reason), or about giving you
more knowledge about what's going on (so that when you install linuxconf
you find out that it comes with a remote configuration thingo).
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
The Doctor What
> On Fri, Oct 01, 1999 at 11:53:19PM -0500, The Doctor What wrote:
> > The idea was not to say that "since I work for *a company* I'm an
> > authority". My point was that I work in the "real world" and have a
> > counter example.
>
> And of course, everyone else on the list doesn't work in the "real world",
> and just plays in their own little pointless sandpit. Feh.
>
> That *is* offensive.
>
> (And if we all do live in the "real world" then there's nothing special
> about the fact that you do too, so you wouldn't bother pointing it out,
> right? So since it was necessary to point it out, the rest of us must
> be cloistered academics, or insulated children or something, yes?)
>
> ``I work for TurboLinux, and this is the way we do it...'' is all very
> well.
>
> ``I work for TurboLinux. This is the way you should do it.'' is less so.
I was saying that I have "real world" (counter) examples. Namely mine. He
suggested that Michael Stone wasn't in the real world. Michael Stone was
offering the same opinion of Craig Sanders.
Craig obviously has real world experience, as per his web site
http://siva.taz.net.au/~cas/
And running a home machine (Like azure http://azure.humbug.org.au/~aj) is
real too.
The fact I work at TurboLinux gives me *zero* right to say "it should be
so". The fact I use Debian and like Linux does give me the right to say,
"*I* think it should be done this way".
I did not say anyone else is or is not in the real world. For the most
part, I let people decide that for themselves.
> In any case, I fail to see how pressing `_' in dselect before any
> unnecessary daemons are installed could possibly be less secure than
> saying "No, I don't want services activated by default" and then
> installing them anyway. This isn't about increasing security per se,
> it's about either increasing choice (so you can install daemons even
> if you don't want to run them for whatever reason), or about giving you
> more knowledge about what's going on (so that when you install linuxconf
> you find out that it comes with a remote configuration thingo).
Both are secure. Asking a user at install time gives the following
advantages (in order of importance to me):
* Ability to run concurrent 'same service' servers (more choice!)
* Ability to *not* run a server on install (more choice)
* A clear indication that this package uses the net
* Security by default. A user can ignore it, but it isn't 'reasonable' to
go any further and force this down their throat.
So in that respect, we are on the same page. I agree. I just think that
all packages should ask. If one wants a global switch that says:
"Run all daemons at install: (y/n/Ask)" Fine! I'd love it! I'd be very
happy.
Ciao!
--
Any member introducing a dog into the Society's premises shall be liable to a fine of one pound. Any animal leading a blind person shall be deemed to be a cat.
-- Rule 46, Oxford Union Society, London
The Doctor What: Un-Humble http://docwhat.gerf.org/
doc...@gerf.org (finger doc...@gerf.org for PGP key)
KF6VNC
Steve Willer
On Sat, 2 Oct 1999, Anthony Towns wrote:
> And of course, everyone else on the list doesn't work in the "real world",
> and just plays in their own little pointless sandpit. Feh.
>
> That *is* offensive.
Well, you know what? In many cases, it's true. I have seen many people in
the past few months presenting some kind of strong opinion on "real-world"
issues and then later mention offhand that they just use Linux on their
home computer. The same kind of thing happened in the discussion about
static binaries and the lack of an ability to recover from various forms
of error (oh, and by the way, you can't run lilo on the hard drive while
booting from the rescue floppy right now, because lilo is dynamically
linked).
Most of the truly experienced people, with real-life 24-7 pager support
experience, don't seem to pay attention to this list. This is probably to
be expected.
Piotr Roszatycki
> DON'T INSTALL THE DAEMON IF YOU DON'T WANT TO RUN IT.
>
i.e:
I've install postgresql on my home computer. I need this
daemon only sometimes. I don't want to start it every time
I reboot system.
debconf could be helpful.
--
Piotr "Dexter" Roszatycki
mailto:dex...@fnet.pl
Martin Bialasinski
* "Piotr" == Piotr Roszatycki <dex...@fnet.pl> wrote:
Piotr> I've install postgresql on my home computer. I need this daemon
Piotr> only sometimes. I don't want to start it every time I reboot
Piotr> system.
Configure this in a runlevel. Debian doesn't predefine the use of
runlevels. If you start in RL 3, and make postgresql start in RL 4,
then this setup won't be reverted by a package update or such.
And you can either switch to RL 4, or start postgresql with its init.d
script.
Piotr> debconf could be helpful.
Not in this case I think.
Ciao,
Martin
Marek Habersack
> On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote:
> > I took care in my message above to remove anything offensive towards
> > Craig. Unfortunately Craig didn't do the same.
>
> garbage. you went out of your way to be offensive. to quote the opening
> line of your message:
>
>
> the implication here is that you know what you are talking about because
> you work for a "real" (i.e. commercial) linux distribution.
understand what The Doctor What said about TurboLinux is that he just states
that he knows the chores of a Unix administrator. Point. Don't attribute to
anyone what he didn't say.
> that way here, it's not who you work for that's important, it's what
> you've done.
Exactly what he said. He's DONE work for TurboLinux. He did it well. He has
every right to be proud of it and to draw it in discussion like this.
marek
David Bristel
On Sat, 2 Oct 1999, Hamish Moffatt wrote:
> Date: Sat, 2 Oct 1999 15:05:22 +1000
> From: Hamish Moffatt <ham...@debian.org>
> To: debian...@lists.debian.org
> Subject: Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
> Resent-Date: 2 Oct 1999 05:05:34 -0000
> Resent-From: debian...@lists.debian.org
> Resent-cc: recipient list not shown: ;
>
> On Sat, Oct 02, 1999 at 12:46:46PM +1000, Craig Sanders wrote:
> > "Excuse me. I work for TurboLinux."
> >
> > the implication here is that you know what you are talking about because
> > you work for a "real" (i.e. commercial) linux distribution.
>
> When in fact the opposite is true? :-)
Please don't add fuel to the fire. While almost all those on -devel(including
myself) feel that Debian is the best distribution out there, it's not good to
start putting down other distributions. I myself have a severe dislike of
Redhat, but I'd not go to the point of saying it's not a "real" distribution.
Anyone who works in the computer industry in any area knows that it is a
difficult task to create even the most basic product and support it. This is
why being a developer holds such high regard by those technically knowledgeable.
There have been a number of arguments that have shown up on this list, and this
is only the most recent. The only way to stop these arguments from getting out
of control is to keep them off the list, and in personal e-mail if you feel you
need to insult them, or defend yourself against them. If they can't respond
rationally, or if the argument gets out of hand, go to someone about your
problem who MIGHT be able to help settle the argument.
I hope this helps in some way, as I do not wish to see Debian get ripped apart
because of personal differences between people. Debian has continued to grow,
and gain support through the hard work of MANY people, not just one or two, or
even a handful. So, let's keep the good of the distribution in mind, work
through any differences we may have, and continue on.
David Bristel
>
> Hamish
> --
> Hamish Moffatt VK3SB (ex-VK3TYD).
> CCs of replies from mailing lists are welcome.
>
>
David Bristel
On Sat, 2 Oct 1999, Hamish Moffatt wrote:
> Date: Sat, 2 Oct 1999 15:10:23 +1000
> From: Hamish Moffatt <ham...@debian.org>
> To: debian...@lists.debian.org
> Subject: Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
> Resent-Date: 2 Oct 1999 05:10:33 -0000
> Resent-From: debian...@lists.debian.org
> Resent-cc: recipient list not shown: ;
>
> On Fri, Oct 01, 1999 at 09:06:59PM -0500, The Doctor What wrote:
> > On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote:
> > In short, a summary (admittedly from my point of view) follows:
> > In a discussion on whether network daemons should do one of the following:
> > a) Simply start up, grabbing any ports it needs (most do this)
> > b) Not start up (a few do this)
> > c) Ask about what ports to grab and whether to start up (some do this)
> >
> > This letter is to make it public that I think Craig has gone too far. He
> > has hurt my feelings and has been very insulting to everyone in
> > debian-devel. And this is not the way to get things done.
>
> Did you consider his point, though? Why would you install a service
> if you don't want it to run?
Simple answer here, if you install a group of packages during the install, you
may not realize what packages you have installed. For those who do custom
installs as the only way, you probably have never experienced what "Scientific
Workstation" may end up installing. If you are in a hurry, you may choose that
option, then not spend the time picking through all the packages to remove the
ones you want. A possible solution would be a "daemon" flag to go on a package,
and after the install, the installed daemons are listed. This is just an idea,
but that's another subject.
David Bristel
Alexander N. Benner
Ship's Log, Lt. Piotr Roszatycki, Stardate 021099.1636:
> On Fri, 1 Oct 1999, Craig Sanders wrote:
> > DON'T INSTALL THE DAEMON IF YOU DON'T WANT TO RUN IT.
> >
> > WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION?
this is as wrong as it is loud
> I've install postgresql on my home computer. I need this
> daemon only sometimes. I don't want to start it every time
> I reboot system.
>
> debconf could be helpful.
I like to discover new things, I like to learn. How shall I learn about
networking, databases, etc. without installing the software?
Unlike other ppl I have to pay for my phoneline, this argument should be known
on this list by now, and therfore try not to install too much at home.
About 4 times a YYear I carry my 'puter to my office and install there (as
much as I can)
Greetings
--
Alexander N. Benner -*- Niko...@innocent.com -*- Ephesians 6:12 , John 1:5
She relaxed just a little, [..] "I'm hardly presentable..." [..] Hardly
presentable! Wasn't it strange, the way humans looked at themselves with eyes
of flesh [..] But to the angels, she appeared as God Himself saw her, just as
any other redeemed saint of the living God: pure, shining, clean, dressed in
garments as white as snow. PIERCING THE DARKNESS by Frank E. Peretti
Colin Walters
>
> > Did you consider his point, though? Why would you install a service
> > if you don't want it to run?
> Simple answer here, if you install a group of packages during the install, you
> may not realize what packages you have installed. For those who do custom
> installs as the only way, you probably have never experienced what "Scientific
> Workstation" may end up installing. If you are in a hurry, you may choose that
> option, then not spend the time picking through all the packages to remove the
> ones you want. A possible solution would be a "daemon" flag to go on a package,
> and after the install, the installed daemons are listed. This is just an idea,
> but that's another subject.
This is basically what Red Hat does upon installation; it prompts you for which
services to enable out of a list of installed daemons. Perhaps upon installation
or a dist-upgrade, apt could list everything that had a "daemon" flag and prompt
you to start it. That way we would avoid asking every time.
--
Colin Walters <lev...@verbum.org>
http://web.verbum.org/levanti
PGP Fingerprint: A580 5AA1 0887 2032 7EFB 19F4 9776 6282 C207 843A
Craig Sanders
> I've install postgresql on my home computer. I need this daemon only
> sometimes. I don't want to start it every time I reboot system.
you need to do something non-standard, so you should do a little bit of
work to accommodate your own needs.
if i needed to do the above then i would edit /etc/init.d/postgresql and
(in the case statement) change "start)" to "go)". this way, it would
not get started at boot time, but i could easily start it by running
"/etc/init.d/postgresql go".
pros:
simple. takes <20 seconds with vi. minimal change, so follows principle
of least surprise. easy to remember. init.d scripts are conffiles so it
won't be automatically replaced at the next upgrade.
cons:
you have to re-do the change if you ever upgrade and answer "Y" to
dpkg's question about replacing /etc/init.d/postgresql.
craig
--
craig sanders
Rick
> On Sat, Oct 02, 1999 at 10:49:58AM -0700, David Bristel wrote:
> >
> > > Did you consider his point, though? Why would you install a service
> > > if you don't want it to run?
> > ones you want. A possible solution would be a "daemon" flag to go on a package,
> > and after the install, the installed daemons are listed. This is just an idea,
> > but that's another subject.
>
> This is basically what Red Hat does upon installation; it prompts you for which
> services to enable out of a list of installed daemons. Perhaps upon installation
> or a dist-upgrade, apt could list everything that had a "daemon" flag and prompt
> you to start it. That way we would avoid asking every time.
I'm uncertain whether this is a good idea or not. I have helped many
people install redhat linux and, frankly, the daemon enable screen
confuses them. They don't know what all these things are or which ones
they may need. If this gets implemented at least have an obvious "enable
default daemons" button.
I also agree that it would be useful to allow installing daemons without
starting them. I am fond of Roxen Challenger, but I may also want Apache
installed (on an alternate port) in case I decide to play around with it.
It would be a waste of resources to run two http daemons on my machine
when I only want to play with the second one occasionally. Installing,
configuring, and then removing Apache every time is not satisfactory.
Other than that I have not yet decided on the best solution for this.
Personally, I just remove the symlink from my rc directory for each daemon
I don't want started. However, I don't know how this is affected by
package upgrades, etc, because I've just recently started using debian
(unstable).
Laters,
Rick (ri...@chillin.org)
http://rick.chillin.org
"As long as you want to live, everywhere will become heaven.
Isn't that right? Because you are still alive.
The chance to achieve happiness, you can find it anywhere."
Yui Ikari
Neon Genesis Evangelion, "The End Of Evangelion"
Terry Katz
style systems ), and use a 'chkconfig' type setup..
Irix implements it with a config directory (/etc/config), which contains
files with the same name as the init script or app, and contains a single
word .. 'on' or 'off' ..
so, you can issue:
chkconfig postgresql on
/etc/init.d/postgresql start
chkconfig postgresql off
The modifications to add this to the distribution shouldn't be that
difficult .. the chkconfig (or whatever you want to call it) script can be
used to both test for and set the options..
chkconfig [<app> [on/off]] .. leave off the last parameter to check for the
status inside an init.d script and start based on that .. (leave off second
parameter to see a complete list of whats on/off)
The initial change to add this to the init scripts could take a while
(although its simple to just add it to the beginning of the init scripts,
and just exit if the config is off), but once its implemented it would be a
nice tool.. no? (every now and again it would be nice to be able to
chkconfig gdm off, and/or chkconfig network off, etc...)
this is a li'l longer implementation (to get started) than changing
start->go, and if you change it just locally then whenever a package is
upgraded you'll have to add the check line to the beginning of the init
scripts .. but long term, this may be a nice feature for debian in general
.. no?
my 2c
-Terry Katz
> -----Original Message-----
> From: Craig Sanders [mailto:c...@taz.net.au]
> Sent: Saturday, October 02, 1999 6:31 PM
> To: Piotr Roszatycki
> Cc: Debian Development Mailing List
> Subject: Re: Packages should not Conflict on the basis of duplicate
> functionality
>
>
> On Sat, Oct 02, 1999 at 04:36:04PM +0200, Piotr Roszatycki wrote:
>
> > I've install postgresql on my home computer. I need this daemon only
> > sometimes. I don't want to start it every time I reboot system.
>
> you need to do something non-standard, so you should do a little bit of
> work to accommodate your own needs.
>
> if i needed to do the above then i would edit /etc/init.d/postgresql and
> (in the case statement) change "start)" to "go)". this way, it would
> not get started at boot time, but i could easily start it by running
> "/etc/init.d/postgresql go".
>
>
> pros:
>
> simple. takes <20 seconds with vi. minimal change, so follows principle
> of least surprise. easy to remember. init.d scripts are conffiles so it
> won't be automatically replaced at the next upgrade.
>
> cons:
>
> you have to re-do the change if you ever upgrade and answer "Y" to
> dpkg's question about replacing /etc/init.d/postgresql.
>
> craig
>
> --
> craig sanders
>
>
Martin Bialasinski
* "Terry" == Terry Katz <ka...@advanced.org> wrote:
Terry> so, you can issue:
Terry> chkconfig postgresql on
Terry> /etc/init.d/postgresql start
Terry> chkconfig postgresql off
I don't know if I understand you correctly, but does this mean, that
the question whether a init.d script would start the daemon is
dependent on the status of this chkconfig thing?
This is a way bad idea.
This means, that during startup, not only the rcX.d links (or the
filerc equivalent) determines what gets started, but also another
config.
This also means, that when I explicitly call "/etc/init.d/postgresql
start" to start the daemon, the result still depends on another config
setting.
The result is a unnecessary "AND" style switch.
If this is how Irix handles this, then I am glad I don't have to use
it.
Ciao,
Martin
Raul Miller
> I'm uncertain whether this is a good idea or not. I have helped many
> people install redhat linux and, frankly, the daemon enable screen
> confuses them. They don't know what all these things are or which ones
> they may need. If this gets implemented at least have an obvious "enable
> default daemons" button.
Agreed, this is a problem with Red Hat's implementation.
We should ask the user what kind of policy they want to have for network
services. We should inform them that there's a small risk that remote
users may compromise their machine if they enable network services,
but that in some situations the machine would be worthless without such
services. We should present a couple examples (http, remote login),
present the basic options (no network services on by default, most
network services on by default, choose on a service by service basis),
and we should give them a command to use after the install is complete
that lets them see what network services are in use and what package
is responsible for them, and a reference to how to find documentation
in the variety of formats a package could supply it in (man, info,
/usr/{,share}/doc, --help or -h, documentation embedded in configuration
files, or for the really desperate: documentation embedded in programs)
I'm not sure whether is such a reference about documentation.
I'm sure there's no such reference about associating packages with
network sockets. It would be possible to write such a thing, based on
lsof -F -i -n, but maybe it's better to teach everyone how to use lsof
(run lsof as root, teach about the +M option, egrep for '(UDP).*(LISTEN|\*)'),
use dpkg -S to find package associated with a program.
--
Raul
Rick
> On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
> > I'm uncertain whether this is a good idea or not. I have helped many
> > people install redhat linux and, frankly, the daemon enable screen
> > confuses them. They don't know what all these things are or which ones
> > they may need. If this gets implemented at least have an obvious "enable
> > default daemons" button.
>
> Think about this for a second. Why do we want to make it easy for people
> to enable remote access to their system if they're unaware of what that
> means?
I agree with you, that was just an example. It could just as easily be a
"disable all daemons" or perhaps "disable all network daemons".
Laters,
Rick (ri...@chillin.org)
http://rick.chillin.org
Rick
> Why not implement a system similar to that in Irix ( and a few other sysv
> style systems ), and use a 'chkconfig' type setup..
>
> Irix implements it with a config directory (/etc/config), which contains
> files with the same name as the init script or app, and contains a single
> word .. 'on' or 'off' ..
>
> so, you can issue:
>
> chkconfig postgresql on
> /etc/init.d/postgresql start
> chkconfig postgresql off
This is possibly a good idea. However, if you're gonna be doing this, why
not just remove the symlink from /etc/rc2.d? When you want the daemon
back recreate the symlink. I'm under the impression that package updates
would recreate this link, so maybe that wouldn't work very well.
> The modifications to add this to the distribution shouldn't be that
> difficult .. the chkconfig (or whatever you want to call it) script can be
> used to both test for and set the options..
>
> chkconfig [<app> [on/off]] .. leave off the last parameter to check for the
> status inside an init.d script and start based on that .. (leave off second
> parameter to see a complete list of whats on/off)
>
> The initial change to add this to the init scripts could take a while
> (although its simple to just add it to the beginning of the init scripts,
> and just exit if the config is off), but once its implemented it would be a
> nice tool.. no? (every now and again it would be nice to be able to
> chkconfig gdm off, and/or chkconfig network off, etc...)
How is "chkconfig network off" any better/easier than "/etc/init.d/network
stop" (aside from the fact it won't get restarted when you reboot)? I
thought that's what different runlevels were for, having different daemons
started when you boot. Maybe I'm just thinking that mucking with
/etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for
those less familiar with the init system.
I don't like the idea of adding this check to each init script. Wouldn't
it be better to add this check to /etc/init.d/rcS when it goes through the
/etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name
as the init script minus the S??)?
Laters,
Rick (ri...@chillin.org)
http://rick.chillin.org
"As long as you want to live, everywhere will become heaven.
Isn't that right? Because you are still alive.
The chance to achieve happiness, you can find it anywhere."
Yui Ikari
Neon Genesis Evangelion, "The End Of Evangelion"
Terry Katz
originally thinking .. Irix has been the main OS at my company until
recently when I started moving the apps over to high end Linux boxes, and
have gotten used to the chkconfig setup .. (which serves more purposes than
just preventing daemons from starting .. its also used for tracing and
debugging .. ie, you can have a trace/debug log created whenever you boot,
and also use it to prevent the scripts from display a lot of info (ie, make
them quiet) .. I got used to the idea of 'chkconfig trace on' rebooting, and
using that to debug startup failures, etc... 'checkconfig autoconfig on' to
tell it to use dhcp, etc.. it just made it a bit easier than editing the
config scripts and placing exit's in them, and then removing them later ..
or removing links, and then recreating, etc...)
So, I withdraw my suggestion ;-)
-Terry
Colin Walters
runlevel 3? We could keep runlevel 2 as the default, which would
become the "workstation" (i.e. no services) runlevel, and 3 would
be the "all installed daemons start" runlevel. That way, the
default configuration upon installation would be for a
secure "workstation".
--
Colin Walters <lev...@verbum.org>
http://web.verbum.org/levanti
PGP Fingerprint: A580 5AA1 0887 2032 7EFB 19F4 9776 6282 C207 843A
Fabien Ninoles
> On Fri, Oct 01, 1999 at 09:06:59PM -0500, The Doctor What wrote:
> > On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote:
> > In short, a summary (admittedly from my point of view) follows:
> > In a discussion on whether network daemons should do one of the following:
> > a) Simply start up, grabbing any ports it needs (most do this)
> > b) Not start up (a few do this)
> > c) Ask about what ports to grab and whether to start up (some do this)
> >
> > This letter is to make it public that I think Craig has gone too far. He
> > has hurt my feelings and has been very insulting to everyone in
> > debian-devel. And this is not the way to get things done.
>
> if you don't want it to run?
I can add I'm one of those who would prefer being asked. My configuration
is that I have network service on init 3 and 5, [xwgk]dm on 4 and 5. Sometime
I'm on a network, sometime I'm not. Having *any* service start automatically
can be as annoying as having to restart all services after each upgrade.
Given the possibilities that debconf give us, can't we consider to make it
a possible choice of medium priorities, the default being that each daemon
should (re)start themself? It's not as secure as it should be but is reasonable
and more insecure daemon (like date, echo, etc.) can use a greater priority.
>
> Hamish
> --
> Hamish Moffatt VK3SB (ex-VK3TYD).
> CCs of replies from mailing lists are welcome.
>
--
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail: f...@tzone.org
WebPage: http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
Staffan Hamala
> Ok, try this on for size:
>
> How many network services do you get if you are doing if you decide to
> install cfs?
>
> How many if you decide to install crossfire-sounds?
>
> [Aside: obviously there's a difference between not accepting a connection
> and accepting a connection then dropping it. Very occasionally this
> makes a difference from a security standpoint.]
Yep,
Also, when I installed Debian on my home machine, I went through selecting
packages for two hours using dselect, and I didn't think much about each
one of them, or I would have been there selecting the whole night.
Eg, I noticed there was an YP client available, I thought "cool, I'll
install that and do some tests on how that works later". Afterwards
I happened to notice that my ISDN router connected and disconnected
all the time, and traced that back to the YP client that was up and
running when I thought I had only installed it, not run it..
Of course both points in this discussion are valid, all users _can_ go
through dselect for half a day, deselecting all network apps that they
don't need, but you can't seriously consider many people to do this.
Myself, I do it the easy way, ie install everything, boot up, remove
half of the rc* things and strip inetd.conf and so on, but I won't
expect new users to do so.
Most new users just install it, and don't even know about half of the
daemons they are running, so it really might be a good thing to
add one question about running all daemons or not.
/Staffan
The Doctor What
> On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
> > I'm uncertain whether this is a good idea or not. I have helped many
> > people install redhat linux and, frankly, the daemon enable screen
> > confuses them. They don't know what all these things are or which ones
> > they may need. If this gets implemented at least have an obvious "enable
> > default daemons" button.
>
>
> We should ask the user what kind of policy they want to have for network
> services. We should inform them that there's a small risk that remote
> users may compromise their machine if they enable network services,
> but that in some situations the machine would be worthless without such
> services. We should present a couple examples (http, remote login),
> present the basic options (no network services on by default, most
> network services on by default, choose on a service by service basis),
> and we should give them a command to use after the install is complete
> that lets them see what network services are in use and what package
> is responsible for them, and a reference to how to find documentation
> in the variety of formats a package could supply it in (man, info,
> /usr/{,share}/doc, --help or -h, documentation embedded in configuration
> files, or for the really desperate: documentation embedded in programs)
>
> I'm not sure whether is such a reference about documentation.
>
> I'm sure there's no such reference about associating packages with
> network sockets. It would be possible to write such a thing, based on
> lsof -F -i -n, but maybe it's better to teach everyone how to use lsof
> (run lsof as root, teach about the +M option, egrep for '(UDP).*(LISTEN|\*)'),
> use dpkg -S to find package associated with a program.
I **really** like the idea of a policy manager program. I see one
problem, in that portions of policy management would include pam in
addition to resource management, etc.
Hmmm...I think I will have to propose that to my developers here at
TurboLinux. Yup. Already had a bunch of positive responses.
Regarding TurboLinux and RedHat people being here on this list; We are
not competitors. We compete with WinNT and Solaris and SCO. You are some
of the great people that make this linux dream a reality. :-)
Ciao!
--
Have you heard that the next Space Shuttle is supposed to carry several Guernsey cows?
It's gonna be the herd shot 'round the world.
The Doctor What: Not that 'who' guy http://docwhat.gerf.org/
doc...@gerf.org (finger doc...@gerf.org for PGP key)
KF6VNC
Joey Hess
> One way to minimize the harm of unintentionally installed or
> misconfigured daemons would be to add a default ipchain/ipfwadm policy
> rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets
> except those from localhost.
Good lord.
Does anyone else feel people on the net are too paraniod these days?
--
see shy jo