Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Staffan Hamala]

On Sun, 03 Oct 1999, Raul Miller wrote:

> 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

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Fabien Ninoles]

On Sat, Oct 02, 1999 at 03:10:23PM +1000, Hamish Moffatt wrote:
> 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?

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 NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris   Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
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

RE: Packages should not Conflict on the basis of duplicate functionality

[Terry Katz]

Looking back on it .. I guess the chkconfig idea wasn't as good as I was
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

> On Sun, 3 Oct 1999, Terry Katz wrote:
>
> > 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 [ [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 ([EMAIL PROTECTED])
> 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"
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>

RE: Packages should not Conflict on the basis of duplicate functionality

[Rick]

On Sun, 3 Oct 1999, Terry Katz wrote:

> 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 [ [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 ([EMAIL PROTECTED])
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"

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Raul Miller]

On Sat, Oct 02, 1999 at 03:53:43PM +1000, Anthony Towns wrote:
> 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.

How long are you suggesting a person study their initial configuration
in deselect before installing any packages?

--
Raul

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Raul Miller]

On Sat, Oct 02, 1999 at 08:06:10PM +1000, Craig Sanders wrote:
> i show no regard for those who demonstrate they are fools. i show
> contempt for those who demonstrate that they are annoying fools. guess
> which category you fall into.

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.]

[Aside: I know that if you install packages one at a time, using apt,
and if you read each package description, and sit back and read the
package docs after installing it, that you'll not have any problems with
unwanted network services cropping up.  But: is this how you use debian?]

-- 
Raul

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Terry" == Terry Katz <[EMAIL PROTECTED]> 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

RE: Packages should not Conflict on the basis of duplicate functionality

[Terry Katz]

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

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 [ [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:[EMAIL PROTECTED]
> 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
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

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

Re: Packages should not Conflict on the basis of duplicate functionality

[Alexander N. Benner]

Hi

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 -*- [EMAIL PROTECTED] -*- 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

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[David Bristel]

On Sat, 2 Oct 1999, Craig Sanders wrote:

> Date: Sat, 2 Oct 1999 20:06:10 +1000
> From: Craig Sanders <[EMAIL PROTECTED]>
> To: The Doctor What <[EMAIL PROTECTED]>
> Cc: debian-devel@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 10:06:43 -
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
> 
> On Fri, Oct 01, 1999 at 11:52:59PM -0500, The Doctor What wrote:
> > You on the other hand show no thought for anyone else.
> 
> i show no regard for those who demonstrate they are fools. i show
> contempt for those who demonstrate that they are annoying fools. guess
> which category you fall into.

This is where you are at fault, Craig.  If you feel someone is a fool, or an
annoying fool, then you should either make your point, and show CLEARLY that
your point is the right one.  You should do so without insults, and without any
comments that would lead to an argument rather than debate on an issue.
Further, you harm Debian by going off topic to make your opinion of a PERSON on
the list, rather than keeping it off the list.  If you feel the need to insult
someone, then PLEASE, do it in private e-mails so it doesn't get out of hand.


David Bristel

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[David Bristel]

On Sat, 2 Oct 1999, Hamish Moffatt wrote:

> Date: Sat, 2 Oct 1999 15:10:23 +1000
> From: Hamish Moffatt <[EMAIL PROTECTED]>
> To: debian-devel@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 -
> Resent-From: debian-devel@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

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[David Bristel]

On Sat, 2 Oct 1999, Hamish Moffatt wrote:

> Date: Sat, 2 Oct 1999 15:05:22 +1000
> From: Hamish Moffatt <[EMAIL PROTECTED]>
> To: debian-devel@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 -
> Resent-From: debian-devel@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.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Marek Habersack]

* Anthony Towns said:
> 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.
Come on! Better stop it now. You know damned well this is not the case.
Everyone has their experiences in the real work and world - and everyone has
the right to support their speech using the examples and poits from his own
life. EVERYONE. And if you take it personal, then I'm sorry. I don't feel
offended by what TDW said.

marek


pgpZayTm40LwI.pgp
Description: PGP signature

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Marek Habersack]

* Craig Sanders said:

> > and
> > 
> > >  now what is so fucking difficult to understand about that?
> > 
> > the word "deliberate" isn't the first that occurs to me.
> 
> if you can't comprehend that someone might deliberately choose those
> words, then that is your problem not mine. such paucity of imagination
> is truly sad.
No - your attitude is sad. Perhaps you are not educated enough to state your
position in a civilized way using strong but NOT insulting words. It's even
more said when we realize that you use the Shakespeare's language which has
more than enough words and expressions to express anything without using
bold language. And before you say that - I use these and worse words myself,
but one has to know when and where to use them. This is not one of these
places.

marek


pgprXnNirx9I8.pgp
Description: PGP signature

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Marek Habersack]

* Craig Sanders said:
> 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."
> 
> the implication here is that you know what you are talking about because
> you work for a "real" (i.e. commercial) linux distribution. 
No, you get it plain wrong. I guess it's just a way of thinking, but how I
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


pgp5G54mQ8CFD.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Piotr" == Piotr Roszatycki <[EMAIL PROTECTED]> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Piotr Roszatycki]

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?

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:[EMAIL PROTECTED]

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Craig Sanders]

On Fri, Oct 01, 1999 at 11:52:59PM -0500, The Doctor What wrote:
> You on the other hand show no thought for anyone else.

i show no regard for those who demonstrate they are fools. i show
contempt for those who demonstrate that they are annoying fools. guess
which category you fall into.

in short, say something merely stupid and i will ignore you. say
something stupid and irritating and i will rub your nose in it.

> And finally, just to make sure we're all clear on the matter
> "no regards, craig"

i had some doubts as to whether you might get the picture. in your case,
i thought spelling it out was necessary.


> or at least see that stabbing at people isn't productive.

if it makes fools quit their yapping then it can be highly productive.


this "discussion" is a waste of time.


craig


--
craig sanders

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Craig Sanders]

On Fri, Oct 01, 1999 at 11:38:47PM -0400, Steve Willer wrote:
> When someone writes things like:
> 
> >  well, bully for you.  i guess that must make you so proud.
> 
> and
> 
> >  now what is so fucking difficult to understand about that?
> 
> the word "deliberate" isn't the first that occurs to me.

if you can't comprehend that someone might deliberately choose those
words, then that is your problem not mine. such paucity of imagination
is truly sad.


craig

--
craig sanders

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[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.

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[The Doctor What]

On Sat, Oct 02, 1999 at 03:53:43PM +1000, Anthony Towns wrote:
> 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/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Anthony Towns]

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.

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 <[EMAIL PROTECTED]> 
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


pgpJhFUJJiYSd.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> No, this is silly.  When you install a package, it is for use.  If you 
> 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?

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Hamish Moffatt]

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?

> 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.



Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Hamish Moffatt]

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? :-)


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[The Doctor What]

On Sat, Oct 02, 1999 at 12:46:46PM +1000, Craig Sanders wrote:
> 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."
> 
> the implication here is that you know what you are talking about because
> 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/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Steve Willer]

On Sat, 2 Oct 1999, 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. 

Either that, or you're attributing an attitude to him that doesn't exist. 
That would mean you're wrong, and furthermore that you're being a rude
jerk. 

Boy, wouldn't that be embarrassing. You must feel awful.

> 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.

When someone writes things like:

>  well, bully for you.  i guess that must make you so proud.

and

>  now what is so fucking difficult to understand about that?

the word "deliberate" isn't the first that occurs to me.

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Craig Sanders]

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."

the implication here is that you know what you are talking about because
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.


> 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.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Fri, Oct 01, 1999 at 10:20:41AM -0400, Clint Adams wrote:
> > 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

Re: Packages should not Conflict on the basis of duplicate functionality

[The Doctor What]

On Fri, Oct 01, 1999 at 08:38:00PM +0200, Josip Rodin wrote:
> 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/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[The Doctor What]

Just to make sure we are all clear here:
I have cc'ed the listmaster and I am angry and insulted.  On the flip
side, I am trying very hard to be calm and collected and (most importantly
in my mind) fair.  The subject is deliberatly melodramatic.

On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote:
[wrote lots of mean, insulting offensive things]

For those tuning in late, here is the archive url for my letter to
debian-devel, and Craig Sanders` response:

http://www.debian.org/Lists-Archives/debian-devel-9910/msg9.html
http://www.debian.org/Lists-Archives/debian-devel-9910/msg00018.html

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.

Craig's opinion is direct:
Things should stay the same.  If someone installs a package, they are
expecting it to run.  Everything else is a special case requiring extra
work on the part of the user.

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. 

I took care in my message above to remove anything offensive towards
Craig.  Unfortunately Craig didn't do the same.

Perhaps Craig didn't mean it that way.  Perhaps he did feel persicuited or
attacked.  Not everyone's message was super polite.  Including mine.  But
even so, I think he went beyond limit.

I decided that I should check out some of his messages.  Many are usefull,
but woe to anyone who doesn't understand him or even worse doesn't
understand him *and* disagrees him!
Two Examples:
http://www.debian.org/Lists-Archives/debian-devel-9908/msg00044.html
http://www.debian.org/Lists-Archives/debian-devel-9907/msg00857.html

Fustratingly, he does bring usefull information to this mailing list and
have points that should be heard.  Just not with the meanness and rudeness
exhibited above.

It is my hope that Craig Sanders reads this and thinks about what he has
done and why.

Till then I am
Christian Holtje (aka [EMAIL PROTECTED])

-- 
Nobody said computers were going to be polite.

The Doctor What: A Holtje Production http://docwhat.gerf.org/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: Packages should not Conflict on the basis of duplicate functionality

[John Goerzen]

The Doctor What <[EMAIL PROTECTED]> writes:

> I do not believe that any network daemon should automatically start
> grabbing resources without asking.  By installing a package, I only
> consent to commiting disk space and the resoureses needed to get it
> actually on the disk.  Anything beyond that should be asked
> for.

No, this is silly.  When you install a package, it is for use.  If you 
don't intend to use it, why install it?

Incidentally, can we do something about the insane CC line please?

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
The 955,570th digit of pi is 2.

Re: Packages should not Conflict on the basis of duplicate functionality

[Josip Rodin]

On Thu, Sep 30, 1999 at 09:47:24PM -0500, Eric Weigel wrote:
> 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.
[snip]

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

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

[Craig flaming Doctor What deleted]

> 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"?

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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?

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?

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Fri, Oct 01, 1999 at 03:13:36AM -0500, The Doctor What wrote:

> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[The Doctor What]

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.

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/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: Packages should not Conflict on the basis of duplicate functionality

[The Doctor What]

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.

> 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/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: Packages should not Conflict on the basis of duplicate functionality

[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 <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

On Fri, Oct 01, 1999 at 10:53:44AM +1000, Craig Sanders wrote:
> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[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

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Thu, Sep 30, 1999 at 07:02:44AM -0400, Michael Stone wrote:
> On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> > sorry, it's you who needs to wake up to the real world.
> > 
> > if people don't know how to administer a unix machine then they need
> > to learn fast. 
> 
> Not true. 

you discredit your argument with silly assertions like this.

> Maintaining a unix-like machine for desktop or personal use requires
> a different skill set than a machine used as a server. People using
> linux as a windows replacement or because they want to see what linux
> is *don't need* a bunch of services enabled *by default*.

if they "*don't need* a bunch of services enabled *by default*" then
they shouldn't install the packages that provide those services. most
workstations do not need a pop or imap server, very few need an ftp
server.

those workstation users who install these packages have to take
responsibility for their own actions, and they should be presumed to
know what they are doing.


> > no amount of molly-coddling by the distribution authors (i.e. us) is
> > going to obviate that essential requirement. maintaining security on
> > your own systems requires personal knowledge and experience, it can
> > not be done by proxy.
>
> Agreed, for machines that need public services. But I'm talking about
> defaults. Can you come up with a reason we *need* a bunch of stuff
> enabled by default?

if a service isn't needed then don't install the package that provides
that service. what is so difficult to understand about that?

it's not as if people are forced to install rsh or telnet servers any
more.  Anthony has done a great job of splitting up netbase so that
these packages are now optional extras.


> > the "we-know-better-than-you" attitude is what redhat and caldera
> > (and microsoft, for that matter) does. it sucks. debian has always
> > done better than that
>
> This is empty "we're better than them propaganda". Debian already
> makes choices in what services are installed and enabled by default.
> It does not follow that changing the *existing* list of services we
> enable by default implies a "we-know-better-than-you" attitude.

ok, i see the communication problem now...why we're going round in
circles on this point. i think we're talking about completely different
things here.

i'm not talking about what debian chooses to have installed by default
(i.e. base/required packages).

i'm talking about the current practice of postinst scripts in various
packages enabling the services that they provide (if any). i am not
talking at all about which packages are base or required or extra or
whatever - i'm talking specifically and ONLY about what the postinst
scripts of packages do when they are installed. install a package which
provides a daemon and it *should* be enabled in the postinst. if you
don't want the service it provides then don't install the package.

of course, if debconf or something can provide a mechanism for the
system admin to globally choose whether to enable or not enable services
when they are installed then that is even better. but until we have such
a mechanism, such packages should do what they always done and enable
themselves at install time.


> A system with daemons disabled will always have a better guarantee of
> security than one with daemons enabled. In the not-so-distant past we've
> shipped systems with a vulnerable telnetd and a vulnerable ftpd enabled
> *by default.* 

which is one of the reasons why they are now split off from the netbase
package - so that people can choose whether they want these services
installed or not.

splitting netbase was the right solution to that problem...installing
stuff but leaving it disabled is a PITA, not a solution to a problem.
more to the point, it's a bigger and more annoying problem than the one
it is purported to solve.



> > why run debian (with all it's useful tools like update-inetd and
> > update-rc.d and so on) if you're going to throw away those advantages?
> 
> Why does changing default behavior throw away advantages? What prevents
> you from using those tools if you want them? 

the advantage of these tools is that packages can enable the services
they provide when they are installed. they don't provide much (if any)
benefit to the casual command-line user - it's easier to edit inetd.conf
manually than it is to remember the args for update-inetd.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Thu, Sep 30, 1999 at 09:21:09AM -0400, Clint Adams wrote:
> > There is currently no default -- it varies on a per-package basis.
> 
> I note that
> 
> ### 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

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

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.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> Or are you saying something else?

I was merely pointing out the irony of one of Craig's packages
not enabling the daemon by default.

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

> > There is currently no default -- it varies on a per-package basis.

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

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> There is currently no default -- it varies on a per-package basis.

I note that

### to run vtund as a server on port 5000, uncomment the following line:
#--server-- 5000

isn't uncommented by default.

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

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.

> ... 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Michael Stone]

On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> sorry, it's you who needs to wake up to the real world.
> 
> if people don't know how to administer a unix machine then they need
> to learn fast. 

Not true. 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*. And if
there is no way to access the machine remotely then there's no harm if
having a non-guru administer the machine. (It can be a security
nightmare, but if no one can get in, it doesn't matter.)

> 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?

> 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. (OTOH, saying "if
you want to disable the service, remove the package--there's no reason
to do anything else" does seem to imply such an attitude.)

> > 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.

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.* If they'd been off instead of on they wouldn't have been a
security problem for the many people who never used them.


> see previous message. if a particular daemon is a problem then it needs
> to be fixed or replaced or dropped from the distribution. changing the
> default so that it is only enabled manually will NOT increase security
> at all.

See above.

> > It's really time to get away from the mentality that everyone needs to
> > have everything turned on all of the time; if a persone really *needs*
> > something enabled, they can figure out how to do it. (If they can't,
> > should they really be administering a network node?)
> 
> if they don't need it then they shouldn't install the package.

It's a default. Not everyone reads everything about every
package--that's just the way things are, and we need to work with that
in mind rather than building this wall of fantasy that we can do
dangerous things as long as we bury a disclaimer in the docs. *That's*
the commercial vendor's mentality you lamented previously.

> 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? 

> 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.

What reasoning are you providing other than personal preference? Do you
have any critique other than a misguided "that's what they do in the big
bad proprietary software world?" (FYI, enabling everything by default is
exactly what they do in the proprietary world because they don't have
the courage to change things. Some vendors still have passwordless
accounts because they're afraid to change things. I expect better from
free software--"we've always done it this way" is not adequate defense.)

Mike Stone


pgpUnuT0MvfHV.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Daniel Burrows]

On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders was heard to say:
> > 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_

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 10:38:34PM -0400, Clint Adams wrote:
> > 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.


craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 11:45:13PM -0500, Francois Gurin wrote:
> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Francois Gurin]

On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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.

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.

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

On Wed, Sep 29, 1999 at 09:57:53PM +1000, Drake Diedrich wrote:
>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.

This approach (adding complexity to the active system) is a hack.

There are situations where it's appropriate, but in most cases it's
just one more thing to mess up, or one more thing where the user would
have to wrestle with semi-automated configuration.

The debconf solution is much better.

-- 
Raul

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 09:26:39PM -0400, 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?

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

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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?

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 08:50:00PM -0400, Clint Adams wrote:
> > 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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?

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

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.

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.

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)


> 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.

see previous message. if a particular daemon is a problem then it needs
to be fixed or replaced or dropped from the distribution. changing the
default so that it is only enabled manually will NOT increase security
at all.


> It's really time to get away from the mentality that everyone needs to
> have everything turned on all of the time; if a persone really *needs*
> something enabled, they can figure out how to do it. (If they can't,
> should they really be administering a network node?)

if they don't need it then they shouldn't install the package.

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?

> This isn't a UI issue, this is a matter of security and of us taking
> responsibility for the state of quite a few systems out on the
> internet which will be configured according to *our* defaults.

it's not a matter of security, it's a matter of personal preference.
enabling daemons when they are installed is not a security problem.

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.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 04:30:45AM -0500, Francois Gurin wrote:

> Minimun hassle/inconvenience is mutually exclusive of minimum harm.
> Looking at the example set forth by some of the other distributions
> (and more than a few operating systems), the reduced hassle of
> installation and administration is traded for security (which I hope
> most people will agree is harmful).

this is a load of crap.

enabling daemons by default is not a security problem.

if a particular daemon is a security problem then it should be fixed or
dropped from the distribution. if the default configuration of a daemon
is a security problem then that config should be fixed or the package
dropped from the distribution.


craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 02:27:45PM -0400, Mark W. Eichin wrote:
> 
> > it's an either/or situation (i.e. no way of satisfying both parties
> 
> Actually, it isn't -- there's an easy way of giving users a choice,
> and two people have suggested it already (debconf).  This seems to be
> the most Debianish way to handle it - technologically superior, and
> avoids punishing one set of users at the expense of the other (even if
> it is a small minority, you don't care about that when you're in it
> :-)

if that can be done, then fine.

i'm against changing the default so that it only suits a tiny minority.
i'm not against increasing choice.

the default should remain as is, though - those who want it different
should be the ones who have to take whatever action with debconf.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 01:08:31PM -0400, Laurel Fan wrote:
> Excerpts from debian: 29-Sep-99 Re: Packages should not Con.. by Craig
> [EMAIL PROTECTED] 
> > IMO that's the price you pay for saying "install a whole bunch of
> > random stuff i haven't personally selected". if you cared, you'd
> > take the time to vet all selections yourself.
>
> In the initial install, is it possible to go in and unselect and
> select packages after picking profile/tasks (Or just look at what it
> wants to install)?

yes. dselect is run immediately after the pre-selection stage.

> The install program and the docs say "skip the Select step of
> dselect"... Does it mean "skip it because you will confuse the
> installer" or "you should skip it because it's already done"?

it means "skip it because i don't want pre-selections".

that option is to not run the pre-selection script, to jump straight
into dselect. it's the option i always choose when building systems
because i prefer to select all packages.

crai

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Mark W. Eichin]

> it's an either/or situation (i.e. no way of satisfying both parties

Actually, it isn't -- there's an easy way of giving users a choice,
and two people have suggested it already (debconf).  This seems to be
the most Debianish way to handle it - technologically superior, and
avoids punishing one set of users at the expense of the other (even if
it is a small minority, you don't care about that when you're in it
:-)

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Laurel" == Laurel Fan <[EMAIL PROTECTED]> wrote:

Laurel> install)?  The install program and the docs say "skip the
Laurel> Select step of dselect"... Does it mean "skip it because you
Laurel> will confuse the installer" or "you should skip it because
Laurel> it's already done"?

The second is correct.

Ciao,
Martin

Re: Packages should not Conflict on the basis of duplicate functionality

[Laurel Fan]

Excerpts from debian: 29-Sep-99 Re: Packages should not Con.. by Craig
[EMAIL PROTECTED] 
> IMO that's the price you pay for saying "install a whole bunch of random
> stuff i haven't personally selected". if you cared, you'd take the time
> to vet all selections yourself.

In the initial install, is it possible to go in and unselect and select
packages after picking profile/tasks (Or just look at what it wants to
install)?  The install program and the docs say "skip the Select step of
dselect"... Does it mean "skip it because you will confuse the
installer" or "you should skip it because it's already done"?

Re: Packages should not Conflict on the basis of duplicate functionality

[Drake Diedrich]

On Wed, Sep 29, 1999 at 04:31:05AM -0500, Francois Gurin wrote:
> 
> Minimun hassle/inconvenience is mutually exclusive of minimum harm.
> Looking at the example set forth by some of the other distributions
> (and more than a few operating systems), the reduced hassle of
> installation and administration is traded for security (which I 
> hope most people will agree is harmful).  
> 

   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.  Daemon maintainers could then add commented
out or localhost-only examples in their init.d scripts, which could be
modified by the sysadmin to their local policies.  The brave could answer no
in netbase's postinst to a default deny policy.  The DNS rule begs to be
tightened up.  Non-IP daemons (netatalk) are outside the scope of an IP
firewall, but maybe netfilter will have a cure for that.
  I'd prefer to just remove the Conflicts: and allow the daemons to race for
the service number.  It can be very useful to run different daemons on
different aliases, ports, or interfaces.  Alternatively some daemons could
default to unique numbers (eg. squid/junkbuster), requiring sysadmin
intervention to reconfigure if a well-known port was prefered.

/etc/init.d/daemon
--
case "$1" in
  start)
# start http daemon here
#   if [ -e /proc/net/ip_fwchains ]; then
#  ipchains -I input 1 -j ACCEPT -p tcp -d 0/0 http
#   elif [ -e  /proc/net/ip_input ]; then
#  ipfwadm -I -i accept -P tcp -D 0/0 http 
#   fi
#   ;;

  stop)
#   if [ -e /proc/net/ip_fwchains ]; then
#  ipchains -D input -j ACCEPT -p tcp -d 0/0 http
#   elif [ -e  /proc/net/ip_input ]; then
#  ipfwadm -D -i accept -P tcp -D 0/0 http 
#   fi
   # stop http daemon here
   ;;
esac


/etc/init.d/network
---
# comment these out if you don't want to self firewall
if [ -e /proc/net/ip_fwchains ]; then
  ipchains -A input -j ACCEPT -s localhost
  ipchains -A input -j ACCEPT -s ${IPADDR}
  ipchains -A input -j ACCEPT -p icmp
  ipchains -A input -j ACCEPT -p tcp -d ${IPADDR} \! -y
  ipchains -A input -j ACCEPT -p udp -d ${IPADDR} -s 0.0.0.0/0 domain -l
  ipchains -A input -j DENY -l
elif [ -e  /proc/net/ip_input ]; then
  ipfwadm -I -a accept -S localhost
  ipfwadm -I -a accept -S ${IPADDR}
  ipfwadm -I -a accept -P icmp
  ipfwadm -I -a accept -P tcp -D ${IPADDR} -k
  ipfwadm -I -a accept -P udp -D ${IPADDR} domain -o
  ipfwadm -I -a deny -o
fi
  

/etc/ppp/ /etc/pcmcia/ ip-(up|down).d/...

# need similar rules here too with new IP numbers

Re: Packages should not Conflict on the basis of duplicate functionality

[Michael Stone]

On Wed, Sep 29, 1999 at 03:51:37PM +1000, Craig Sanders wrote:
> On Wed, Sep 29, 1999 at 12:52:16AM -0400, Mark W. Eichin wrote:
> > True, but don't forget the case of an initial install - you pick some
> > profile, and get lots of stuff, with no hints.  (In this case, I like
> > they idea of a debconf global flag of "prompt me about daemon
> > enablement", which is kind of the *reverse* of what most people want
> > debconf for...)
> 
> IMO that's the price you pay for saying "install a whole bunch of random
> stuff i haven't personally selected". if you cared, you'd take the time
> to vet all selections yourself. if you don't care, accept whatever the
> selection set gives you. if you discover later that you actually DO
> care, then uninstall or disable the relevant package.

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. 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.
It's really time to get away from the mentality that everyone needs to
have everything turned on all of the time; if a persone really *needs*
something enabled, they can figure out how to do it. (If they can't,
should they really be administering a network node?) This isn't a UI
issue, this is a matter of security and of us taking responsibility for
the state of quite a few systems out on the internet which will be
configured according to *our* defaults.

Mike Stone


pgpfn5eRoNQJs.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Francois Gurin]

> ok. i just don't think it's as big a deal as some people do. more to the
> point, i think that doing the opposite (i.e. not enabling services by
> default when a package is installed) will cause even more problems (and
> confusion and hassle) to everyone else.
> 
> i.e. there's a tiny minority who are inconvenienced by daemons being
> enabled when a package is installed. there would be a huge majority who
> would be inconvenienced if the reverse were true. it looks to me like
> it's an either/or situation (i.e. no way of satisfying both parties
> at once - mutually exclusive needs) so it's a pretty easy choice to
> make...cause the minimum harm/hassle/inconvenience.

The capability to make that decision during package install needs
to be implemented, at the very least to take advantage of debconf.
The functionality could be standardized and implemented so that the
default is on par with debian policy.  

This is a simple way  of "satisfying both parties".  

Minimun hassle/inconvenience is mutually exclusive of minimum harm.
Looking at the example set forth by some of the other distributions
(and more than a few operating systems), the reduced hassle of
installation and administration is traded for security (which I 
hope most people will agree is harmful).  

--francois


 

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Wed, Sep 29, 1999 at 12:52:16AM -0400, Mark W. Eichin wrote:

> > no, but it should be pretty obvious from the description. e.g. a pop
> > server package is going to install a pop server. a web server package is
> > going to install a web server. etc.  this should be self-evident.
> 
> True, but don't forget the case of an initial install - you pick some
> profile, and get lots of stuff, with no hints.  (In this case, I like
> they idea of a debconf global flag of "prompt me about daemon
> enablement", which is kind of the *reverse* of what most people want
> debconf for...)

IMO that's the price you pay for saying "install a whole bunch of random
stuff i haven't personally selected". if you cared, you'd take the time
to vet all selections yourself. if you don't care, accept whatever the
selection set gives you. if you discover later that you actually DO
care, then uninstall or disable the relevant package.

(generic "you" used in above paragraph, not referring to you personally)

> If you doubt that this is an issue, consider ipmasq: it was part of
> one of the standard install profiles, I don't even know which one --
> but it badly confused one firewall and at least two laptop installs
> that I know of personally, because it automatically enabled certain
> safety rules that were wrong in the non-masq multiple-interface case.

sounds like a bug in either the ipmasq package or in the selection set.  or
both.

> The ipmasq maintainer has since made the rules for firing that much
> more rational, we did work out some reasonable approach which I forget

so it's solved.  where's the problem?

> at the moment - I just want to bring it up as a point of actual
> experience with the initial install startup case...

ok. i just don't think it's as big a deal as some people do. more to the
point, i think that doing the opposite (i.e. not enabling services by
default when a package is installed) will cause even more problems (and
confusion and hassle) to everyone else.

i.e. there's a tiny minority who are inconvenienced by daemons being
enabled when a package is installed. there would be a huge majority who
would be inconvenienced if the reverse were true. it looks to me like
it's an either/or situation (i.e. no way of satisfying both parties
at once - mutually exclusive needs) so it's a pretty easy choice to
make...cause the minimum harm/hassle/inconvenience.


craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Mark W. Eichin]

> no, but it should be pretty obvious from the description. e.g. a pop
> server package is going to install a pop server. a web server package is
> going to install a web server. etc.  this should be self-evident.

True, but don't forget the case of an initial install - you pick some
profile, and get lots of stuff, with no hints.  (In this case, I like
they idea of a debconf global flag of "prompt me about daemon
enablement", which is kind of the *reverse* of what most people want
debconf for...)

If you doubt that this is an issue, consider ipmasq: it was part of
one of the standard install profiles, I don't even know which one --
but it badly confused one firewall and at least two laptop installs
that I know of personally, because it automatically enabled certain
safety rules that were wrong in the non-masq multiple-interface case.
The ipmasq maintainer has since made the rules for firing that much
more rational, we did work out some reasonable approach which I forget
at the moment - I just want to bring it up as a point of actual
experience with the initial install startup case...

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Mon, Sep 27, 1999 at 03:21:34AM -0400, Raul Miller wrote:
> 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?

no, but it should be pretty obvious from the description. e.g. a pop
server package is going to install a pop server. a web server package is
going to install a web server. etc.  this should be self-evident.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Chris Rutter]

On Mon, 27 Sep 1999, Brian May wrote:

> 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 <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

Raul Miller <[EMAIL PROTECTED]> wrote:
> > 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
> worksand 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Brian May]

>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?

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 <[EMAIL PROTECTED]>

Re: Packages should not Conflict on the basis of duplicate functionality

[Craig Sanders]

On Sat, Sep 25, 1999 at 01:10:51AM -0400, Raul Miller wrote:
> 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.

then don't install those services. installing a package *IS* an explicit
OK.

you've been using debian long enough to know that this is the way it
worksand 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.

what you are proposing is more work, more hassle, more stupid questions
to answer for every install.

if you want something different from the default then you can implement
in whatever way seems best to you for your systems - but don't force it
on everyone else.

craig

--
craig sanders

Re: Packages should not Conflict on the basis of duplicate functionality

[Chris Rutter]

On Sat, 25 Sep 1999, Raul Miller wrote:

> 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.

Yes, and I think this is an *excellent* candidate for something that
can be trivially fixed by the new debconf -- you can tell it (at
least I hope you can) that the default answer for all of the `Can
I start this daemon?' questions is `no' (assuming, of course, that
the maintainers add questions like these into their packages).

-- 
Chris <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )

Re: Packages should not Conflict on the basis of duplicate functionality

[Chris Rutter]

On Fri, 24 Sep 1999, Clint Adams wrote:

> 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 <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Raul" == Raul Miller <[EMAIL PROTECTED]> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[John Hasler]

Joey Hess writes:
> 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
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

On Sat, Sep 25, 1999 at 10:11:17AM -0400, Michael Stone wrote:
> > 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Michael Stone]

On Sat, Sep 25, 1999 at 03:32:25PM +0200, Martin Bialasinski wrote:
> Michael Stone <[EMAIL PROTECTED]> wrote:
>> Bzzt. Security is more important than usability. We're not building
>> windows 2000 here...
> 
> Ii I install a daemon, I want to use it. 

That doesn't account for daemons installed by default or daemons
installed by accident by people who are trying to install everything
because they're not sure what they want. If what you said was true, the
various imap and mountd exploits that have given linux such a bad rep
would never have been the problem that they are.

> 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.

Yes. The default config of activating a bunch of stuff by default is not
good enough.

Mike Stone



pgpqPcuqZ5xa0.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Michael" == Michael Stone <[EMAIL PROTECTED]> 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

Re: Packages should not Conflict on the basis of duplicate functionality

[Michael Stone]

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.

Bzzt. Security is more important than usability. We're not building
windows 2000 here...

Mike Stone


pgpgs1yPXXsXw.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Joey Hess]

Seth R Arnold wrote:
> How about add one question: "Automatically start all daemons: [Y/n]"
> 
> If they answer yes, then no questions. If they answer no, ask as many
> questions as you want. :)
> 
> Of course, the downside of this particular question is ... not *all* daemons
> should be automatically started. Some require configuration before being
> started. Perhaps a change of wording would improve my question.

That'd be workable.

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..

-- 
see shy jo

Re: Packages should not Conflict on the basis of duplicate functionality

[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

Re: Packages should not Conflict on the basis of duplicate functionality

[Seth R Arnold]

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.

How about add one question: "Automatically start all daemons: [Y/n]"

If they answer yes, then no questions. If they answer no, ask as many
questions as you want. :)

Of course, the downside of this particular question is ... not *all* daemons
should be automatically started. Some require configuration before being
started. Perhaps a change of wording would improve my question.

fwiw, $.02.

-- 
Seth Arnold | http://www.willamette.edu/~sarnold/
Hate spam? See http://maps.vix.com/rbl/ for help
Hi! I'm a .signature virus! Copy me into
your ~/.signature to help me spread!

Re: Packages should not Conflict on the basis of duplicate functionality

[Joey Hess]

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.

-- 
see shy jo

Re: Packages should not Conflict on the basis of duplicate functionality

[Raul Miller]

On Fri, Sep 24, 1999 at 11:34:28PM -0500, The Doctor What wrote:
> I do not like the idea of a daemon starting up with a default
> configuration that I have not double checked upon installation.  I
> consider automatically starting with no choice a misfeature.

I think I agree.

I got a rude start today when I saw messages of the form:
Sep 24 09:00:21 minion inetd[790]: linuxconf/tcp: unknown service

[linuxconf was going to provide a tcp service to enable people to
configure my machine and the only reason I stumbled across this was that
I'd customized my /etc/services file and hadn't merged in changes from
the .dpkg-dist copy?]

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.

Yes I'm aware that some of these services might not have any security
bugs.  So what?

-- 
Raul

Re: Packages should not Conflict on the basis of duplicate functionality

[The Doctor What]

On Fri, Sep 24, 1999 at 11:13:27AM -0400, Scott K. Ellis wrote:
> 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.

I do not believe that any network daemon should automatically start
grabbing resources without asking.  By installing a package, I only
consent to commiting disk space and the resoureses needed to get it
actually on the disk.  Anything beyond that should be asked
for.

Some polite packages do ask nicely whether to use inetd or to start via an
/etc/init.d file.  

Other ones ask which port to run on or even if to run at all.

Why shouldn't *all* daemon packages ask these questions, and whether to even
run *upon install*?

I do not like the idea of a daemon starting up with a default
configuration that I have not double checked upon installation.  I
consider automatically starting with no choice a misfeature.

And as to the idea that if I run a 'complex' system, I should dl the package
and recompile is not a good one.  We have not defined 'complex' and
'simple' except trivially; if you do something that isn't possible with
the current tools, then it is complex.  We cannot afford that
definition.  It would hinder us.

Running multiple daemons providing the same service is reasonable and
expected in a production environment and *even* in the home of an
enterprising user.

The real question is not "why not" by "how".

Ciao!

-- 
We is confronted with insurmountable opportunities.
 -- Walt Kelly, "Pogo"

The Doctor What: Second Baseman  http://docwhat.gerf.org/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> And of course you can always do dpkg --force-conflicts.  I believe that's what
> 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.

Re: Packages should not Conflict on the basis of duplicate functionality

[Colin Walters]

On Fri, Sep 24, 1999 at 05:12:00PM -0400, Clint Adams wrote:
> > 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 <[EMAIL PROTECTED]>
http://web.verbum.org/levanti
PGP Fingerprint: 2951 C835 FB23 82D4 3969  EDB5 08D9 B9EA 7D30 CC26

Re: Packages should not Conflict on the basis of duplicate functionality

[Herbert Xu]

Scott K. Ellis <[EMAIL PROTECTED]> wrote:
>>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~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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.

Re: Packages should not Conflict on the basis of duplicate functionality

[Joost Kooij]

Hi,

On Fri, 24 Sep 1999, Clint Adams wrote:

> 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.

I'd say that it is at least less usual than typical.

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`


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.

Such a script, which would contain all the appropriate smarts to have
multiple incantations of some {httpd,popd,smtpd} daemon installed and
configured automatically, could then be put in a {httpd,popd,smtpd}-common
package on which all {httpd,popd,smtpd} incantations would then have to
(pre-)depend.

Taking this one step further, a generic configuration interface would
allow any other package to configure the daemon, without having to touch
configuration files it doesn't own or even having to know about any or all
particular tastes of configuration style.

I'm sure you are more eager than I am to spout further ideas about this.

Cheers,


Joost

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> Of course.  Now if you built them yourself, dpkg wouldn't touch them.

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?

Re: Packages should not Conflict on the basis of duplicate functionality

[Scott K. Ellis]

> > 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
>
> 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  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.

Re: Packages should not Conflict on the basis of duplicate functionality

[Clint Adams]

> 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

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  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?

Re: Packages should not Conflict on the basis of duplicate functionality

[Scott K. Ellis]

>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.