|
Home > Archive > Debian Developers > April 2004 > Re: Release update
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Release update
|
|
| Nathanael Nerode 2004-02-22, 9:33 am |
| OK, so I started making an analysis of the RC bugs.
(1) There are an awful lot of simple Depends/Build-Depends bugs. Maintainers,
look at your packages, and if you have one of these, fix and upload it now.
Other people: if these sit around for a long time, it's a sign that the
maintainer isn't doing his job -- but NMU the package if you can.
(2) There are a large number of RC bugs filed in Februrary. I think
maintainers probably mostly need to be given a bit more time on these, so I
didn't look at them further.
(3) There are a fair number of packages which have bugs with no maintainer
comment for over a month. This is not good. Maintainers: take a look at
your bugs! QA: there may be some more needed forcible orphanings in here.
These are just the ones I noticed; I may have missed some. Also, I only got
to the letter d before wearing out.
abntex
anubis
atari-bootstrap
ax25-tools
cl-sdl-opengl (bug 217857)
db3
db4.0
debian-guide
debian-guide-zh
debian-installer-demo
defrag
diasce2
dvb-dev
There's lots more further down, like... xemacs21 !
(4) Some packages are in bad enough shape that in my opinion they must not be
released with sarge:
amavis-ng: Four outstanding unfixed RC bugs, including data loss.
cl-uncommonsql: Orphaned and dead upstream.
(5) Conclusion: Many maintainers are doing their jobs excellently.
Unfortunately, a fair number of maintainers simply aren't bothering to deal
with their RC bugs. I don't know what the best course of action is. Some
combination of package removals, NMUs, orphanings, etc., I suppose.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stefano Zacchiroli 2004-02-22, 10:33 am |
| On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
> (1) There are an awful lot of simple Depends/Build-Depends bugs.
> Maintainers,
Out of curiosity: could you please give some figure of this "awful lot"?
50? 100? 200?
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
| |
| Nathanael Nerode 2004-02-22, 3:33 pm |
| On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
> (1) There are an awful lot of simple Depends/Build-Depends bugs.
> Maintainers,
Stefano Zacchiroli wrote:
>Out of curiosity: could you please give some figure of this "awful lot"?
>50? 100? 200?
Looking at all RC bugs (not just those in sarge), I count about 80.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jose Carlos Garcia Sogo 2004-02-24, 12:33 am |
| On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
> OK, so I started making an analysis of the RC bugs.
>
> (1) There are an awful lot of simple Depends/Build-Depends bugs. Maintainers,
> look at your packages, and if you have one of these, fix and upload it now.
> Other people: if these sit around for a long time, it's a sign that the
> maintainer isn't doing his job -- but NMU the package if you can.
>
> (2) There are a large number of RC bugs filed in Februrary. I think
> maintainers probably mostly need to be given a bit more time on these, soI
> didn't look at them further.
>
> (3) There are a fair number of packages which have bugs with no maintainer
> comment for over a month. This is not good. Maintainers: take a look at
> your bugs! QA: there may be some more needed forcible orphanings in here.
> These are just the ones I noticed; I may have missed some. Also, I only got
> to the letter d before wearing out.
>
[...]
> diasce2
[...]
Looking at it this week.
BTW, you have to take into account that people usually have real life
issues that don't make them devote as much time to Debian as they'd
like.
Cheers,
--
Jose Carlos Garcia Sogo
jsogo@debian.org
| |
| Steve Langasek 2004-02-24, 12:33 am |
| On Mon, Feb 23, 2004 at 11:34:06PM +0100, Jose Carlos Garcia Sogo wrote:
> On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
[color=blue]
[color=blue]
[color=blue]
[color=blue]
> [...]
> [...]
> Looking at it this week.
> BTW, you have to take into account that people usually have real life
> issues that don't make them devote as much time to Debian as they'd
> like.
Although I think we all understand when other things take priority over
Debian work, the RC bugcount shows clearly that we can't afford to
consider this an excuse for unaddressed bugs if we hope to release in a
timely manner. Please consider looking for a co-maintainer if you find
you don't have time to regularly address RC bugs on your packages.
--
Steve Langasek
postmodern programmer
| |
| Hamish Moffatt 2004-02-25, 9:37 am |
| On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
> (3) There are a fair number of packages which have bugs with no maintainer
> comment for over a month. This is not good. Maintainers: take a look at
> your bugs! QA: there may be some more needed forcible orphanings in here.
> These are just the ones I noticed; I may have missed some. Also, I only got
> to the letter d before wearing out.
>
[..]
> dvb-dev
? This package has no RC bugs so why does it appear in your list? It has
some normal (and below) bugs which are older than a month but that's not
too serious.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-02-29, 6:33 pm |
| Jose Carlos Garcia Sogo wrote:
> On Sun, Feb 22, 2004 at 05:15:42PM -0500, Nathanael Nerode wrote:
> [...]
> [...]
>
> Looking at it this week.
>
> BTW, you have to take into account that people usually have real life
> issues that don't make them devote as much time to Debian as they'd
> like.
I quote from above:[color=darkred]
:-)
Asking for a *comment* after a month is not unreasonable IMNSHO -- I'm not
asking that the bugs actually be *fixed* after a month!
--
Nathanael Nerode <neroden at gcc.gnu.org>
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/ http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jose Carlos Garcia Sogo 2004-02-29, 6:33 pm |
| El día 29 feb 2004, Nathanael Nerode escribía:
[...]
>
> I quote from above:
>
> :-)
>
> Asking for a *comment* after a month is not unreasonable IMNSHO -- I'm not
> asking that the bugs actually be *fixed* after a month!
Yup, but sometimes you even have not time to make a comment.
BTW, I'm trying to contact upstream, as I'd like to talk about other
things, but it seems that project's webpage has some issues... I'll try
to get the fix from CVS tomorrow.
Cheers,
--
Jose Carlos Garcia Sogo
jsogo@debian.org
| |
| Steve Kemp 2004-03-29, 10:34 am |
| On Mon, Mar 29, 2004 at 03:40:22PM +0100, Colin Watson wrote:
> * As of now, no new packages will be added to the base system. This
> means that packages in the base system *must not* change their
> package relationships.
Without wanting to cause another flamewar on debian-devel what
are the chances that we could get some kind of firewall installed
within the base system in time for a new release?
I have seen this discussion come up a couple of times in various
places, but without any change.
There are many firewall packages that we could consider adding,
and in general I think this would be a good thing.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josip Rodin 2004-03-29, 1:37 pm |
| On Mon, Mar 29, 2004 at 04:24:59PM +0100, Steve Kemp wrote:
>
> Without wanting to cause another flamewar on debian-devel what
> are the chances that we could get some kind of firewall installed
> within the base system in time for a new release?
iptables is of important priority?
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 1:37 pm |
| On Mon, Mar 29, 2004 at 07:50:05PM +0200, Josip Rodin wrote:
>
> iptables is of important priority?
Having iptables or ipchains installed as part of the base install
would be good - but I'm suggesting that we have some default rules,
such as accepting only local connections to all services.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2004-03-29, 2:35 pm |
| Steve Kemp wrote:
> On Mon, Mar 29, 2004 at 07:50:05PM +0200, Josip Rodin wrote:
>
>
> Having iptables or ipchains installed as part of the base install
> would be good - but I'm suggesting that we have some default rules,
> such as accepting only local connections to all services.
Which would AFAIK immediately kill the s390 installer, which runs over
ssh. I have yet to see a rule set which works decently everywhere.
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-29, 2:35 pm |
| On Mar 29, Steve Kemp <skx@debian.org> wrote:
> Without wanting to cause another flamewar on debian-devel what
> are the chances that we could get some kind of firewall installed
> within the base system in time for a new release?
Firewalls do not provide security, they are a policy enforcement tool.
If you think that the default install contains insecure software
accessible from the network then we can try to talk about it.
--
ciao, |
Marco | [5426 asRxtSpkjoCQk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Zefram 2004-03-29, 2:35 pm |
| Steve Kemp wrote:
>Having iptables or ipchains installed as part of the base install
>would be good - but I'm suggesting that we have some default rules,
>such as accepting only local connections to all services.
That would be a really bad idea. Having the services only accept local
connections would make some sense, but crippling the networking is not
a good default.
-zefram
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 2:35 pm |
| On Mon, Mar 29, 2004 at 08:22:56PM +0200, Marco d'Itri wrote:
> Firewalls do not provide security, they are a policy enforcement tool.
> If you think that the default install contains insecure software
> accessible from the network then we can try to talk about it.
Whilst I am not thinking of anything specific I do believe that
we should be trying to reduce the number of network accessible
services which are installed by default.
For example portmap, nfs-server, etc. I am sure that these services
are secure but as a matter of principle I believe that nothing should
be open unless it is explicitly enabled.
That's why I would be pleased if we could offer a firewall question
in the base installer, or install someting by default.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 2:35 pm |
| On Mon, Mar 29, 2004 at 08:26:06PM +0200, Thiemo Seufer wrote:
>
> Which would AFAIK immediately kill the s390 installer, which runs over
> ssh. I have yet to see a rule set which works decently everywhere.
Sure, some people are going to have different needs, but I think
that disabling incoming connections unless explicitly enabled would
be a proactive step for the distribution.
If there is one arch which wouldn't allow this then fair enough
disable it for that one, I don't think that is a sufficiently good
argument for disabling it for all though.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 2:35 pm |
| On Mon, Mar 29, 2004 at 07:52:45PM +0100, Zefram wrote:
> That would be a really bad idea. Having the services only accept local
> connections would make some sense, but crippling the networking is not
> a good default.
"Crippling" seems to be a harsh assessment.
However going the other way and setting up all networking packages
_by default_ to bind to only the local interface would be an acceptible
alternative.
The attraction of a firewalling-by-default approach would be that
only one additional new package must be added, rather than updating
all the networking packages. (mysql, postgres, apache, bind, etc).
Steve
--
# Debian Security Audit Project
http://www.shellcode.org/Audit/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2004-03-29, 3:35 pm |
| Steve Kemp wrote:
> On Mon, Mar 29, 2004 at 08:26:06PM +0200, Thiemo Seufer wrote:
>
>
> Sure, some people are going to have different needs, but I think
> that disabling incoming connections unless explicitly enabled would
> be a proactive step for the distribution.
I disagree. If you don't want to use a network service, then don't
install it in the first place, or bind it to a local port.
> If there is one arch which wouldn't allow this then fair enough
> disable it for that one, I don't think that is a sufficiently good
> argument for disabling it for all though.
It was just an example. The same goes for every remote box which is
updated via network.
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josip Rodin 2004-03-29, 3:36 pm |
| On Mon, Mar 29, 2004 at 07:01:59PM +0100, Steve Kemp wrote:
> I'm suggesting that we have some default rules,
> such as accepting only local connections to all services.
The simplest solution to not needing network servers is not having them
installed at all.
(I don't want to have to explicitely unscrew the firewall every time
I install a new machine, that's one step extra and one more time-wasting
item.)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-29, 3:36 pm |
| On Mar 29, Steve Kemp <skx@debian.org> wrote:
> For example portmap, nfs-server, etc. I am sure that these services
> are secure but as a matter of principle I believe that nothing should
> be open unless it is explicitly enabled.
>
> That's why I would be pleased if we could offer a firewall question
> in the base installer, or install someting by default.
This can easily be controlled with tcpd.
--
ciao, |
Marco | [5427 ad13NpLJmAMZ.]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 4:36 pm |
| On Mon, Mar 29, 2004 at 09:24:16PM +0200, Thiemo Seufer wrote:
> I disagree. If you don't want to use a network service, then don't
> install it in the first place, or bind it to a local port.
This is one approach.
However it fails when installing a new system. By default when
installing Woody right now many things are listening globally.
Exim, portmap, echo etc from inetd.
Other things must be explicitly installed such as openssh, apache,
but the user gets no choice about these base packages. Sure they
could be disabled by a clueful person. But I think the overhead
of "would you like this machine to run a firewall [yes/no]" to
be minimal.
> It was just an example. The same goes for every remote box which is
> updated via network.
I'm not talking about *updating* an existing system, I'm talking
about installing a new system.
However I guess you could mean updating Woody -> Sarge. In this
case I would suggest a firewall ruleset which said something like
* Drop all incoming connections.
* Permit connections which are established.
At the point the firewall was brought up the remote session doing
the update would be established, so there would be no issue.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 4:36 pm |
| On Mon, Mar 29, 2004 at 10:13:58PM +0200, Josip Rodin wrote:
> The simplest solution to not needing network servers is not having them
> installed at all.
The doesn't deal with networking services installed without choice
as I tried to explain previously.
> (I don't want to have to explicitely unscrew the firewall every time
> I install a new machine, that's one step extra and one more time-wasting
> item.)
However I would imagine that debconf would remember a "no, not
interested" type response making your disabling it a one-time operation
anyway.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josip Rodin 2004-03-29, 4:36 pm |
| On Mon, Mar 29, 2004 at 10:23:51PM +0100, Steve Kemp wrote:
>
> The doesn't deal with networking services installed without choice
> as I tried to explain previously.
You mean that mention of nfs-common and portmap? I didn't see that the last
time I used the installer. If I had, I would have filed a bug about it.
If you do, please report it.
>
> However I would imagine that debconf would remember a "no, not
> interested" type response making your disabling it a one-time operation
> anyway.
Too many debconf questions is another slippery slope...
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 5:36 pm |
| On Mon, Mar 29, 2004 at 11:28:25PM +0200, Josip Rodin wrote:
> You mean that mention of nfs-common and portmap? I didn't see that the last
> time I used the installer. If I had, I would have filed a bug about it.
> If you do, please report it.
Yes and Exim.
However I confess I haven't installed Sarge, if it really is the
case that no (or v. minimal) networking services are installed out
of the box then I drop my suggestion entirely.
I have installed Woody an awful lot, and each time I do so I get
irritated by having to remove these things..
> Too many debconf questions is another slippery slope...
Agreed .. but having extraneous services installed by default is
another.
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josip Rodin 2004-03-29, 5:36 pm |
| On Mon, Mar 29, 2004 at 10:30:51PM +0100, Steve Kemp wrote:
>
> Yes and Exim.
>
> However I confess I haven't installed Sarge, if it really is the
> case that no (or v. minimal) networking services are installed out
> of the box then I drop my suggestion entirely.
>
> I have installed Woody an awful lot, and each time I do so I get
> irritated by having to remove these things..
I don't recall having to remove RPC stuff in woody proper, only after
selecting 'traditional Unix server' in tasksel...
The MTA, yes, and also the three default inetd services.
>
> Agreed .. but having extraneous services installed by default is
> another.
We don't seem to be going in that direction with services, though, rather
the opposite.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2004-03-29, 5:37 pm |
| Steve Kemp wrote:
> On Mon, Mar 29, 2004 at 09:24:16PM +0200, Thiemo Seufer wrote:
>
>
> This is one approach.
>
> However it fails when installing a new system. By default when
> installing Woody right now many things are listening globally.
> Exim, portmap, echo etc from inetd.
If those are opening ports by default, file bugs against them.
> Other things must be explicitly installed such as openssh, apache,
> but the user gets no choice about these base packages. Sure they
> could be disabled by a clueful person. But I think the overhead
> of "would you like this machine to run a firewall [yes/no]" to
> be minimal.
It's not about the overhead, it's about the potential breakage,
e.g. for automated noninteractive installs.
>
> I'm not talking about *updating* an existing system, I'm talking
> about installing a new system.
Adding some firewall to the base affects both.
> However I guess you could mean updating Woody -> Sarge. In this
> case I would suggest a firewall ruleset which said something like
>
> * Drop all incoming connections.
> * Permit connections which are established.
>
> At the point the firewall was brought up the remote session doing
> the update would be established, so there would be no issue.
It occurs to me you never did system management over flaky connections.
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-03-29, 5:37 pm |
| On Mon, Mar 29, 2004 at 11:43:59PM +0200, Thiemo Seufer wrote:
> If those are opening ports by default, file bugs against them.
For my sins of suggesting this I will test out the new installer
tomorrow night, and report bugs if services are installed.
>
> Adding some firewall to the base affects both.
I could see that being the case, yes.
> It occurs to me you never did system management over flaky connections.
Yes, frequently. But I have never done a remote install I guess.
Hell my site still uses UUCP due to irregular communications 
Steve
--
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-03-29, 5:37 pm |
| On Mon, Mar 29, 2004 at 11:46:42PM +0200, Josip Rodin wrote:
> On Mon, Mar 29, 2004 at 10:30:51PM +0100, Steve Kemp wrote:
>
> I don't recall having to remove RPC stuff in woody proper, only after
> selecting 'traditional Unix server' in tasksel...
>
> The MTA, yes, and also the three default inetd services.
Both nfs-common and portmap are still priority standard so it will be
installed by default unless the user chooses something in tasksel... I
didn't look to see what other services get installed by default but
those two definitely will be.
Chris
| |
| Javier Fernández-Sanguino Peña 2004-03-29, 7:34 pm |
| On Mon, Mar 29, 2004 at 09:05:33PM +0200, Marco d'Itri wrote:
> On Mar 29, Steve Kemp <skx@debian.org> wrote:
>
> This can easily be controlled with tcpd.
Funny. As with Steve's example, we don't enforce any policy regarding tcp.
We used to have a "PARANOID" one, but now we don't even do that.
It could be easily controlled with tcpd if the maintainer cared to apply
the patch [1] available in #62145 (which I've been holding myself to not
NMU). Yes, it would introduce yet another debconf question on the default
installation, sorry Joey.
Regards
Javier
[1] Slightly tested by myself
| |
| Javier Fernández-Sanguino Peña 2004-03-29, 8:38 pm |
| On Mon, Mar 29, 2004 at 07:01:59PM +0100, Steve Kemp wrote:
> On Mon, Mar 29, 2004 at 07:50:05PM +0200, Josip Rodin wrote:
>
>
> Having iptables or ipchains installed as part of the base install
> would be good - but I'm suggesting that we have some default rules,
> such as accepting only local connections to all services.
Iptables is, or at least I think it is. However, the maintainer, in
response to #212692, said:
"iptables is not a firewall."
Feel free to reopen that bug report, if firewall configuration should be
part of the base install, it should be done by a good default rule in the
iptables scripts. IMHO that would prevent people from shooting themselves
in the foot because they do not know their way around Debian. An example of
that is the fact that many will still install network services without
wanting them to be installed. [1]
Regards
Javi
[1] This was the case of the 'standard' network services (portamap,
nfs-common) in woody, don't know about sarge though since
installation-reports don't include information of network services
installed in the system.
| |
| Steve Langasek 2004-03-29, 11:36 pm |
| On Mon, Mar 29, 2004 at 04:24:59PM +0100, Steve Kemp wrote:
> On Mon, Mar 29, 2004 at 03:40:22PM +0100, Colin Watson wrote:
[color=darkred]
> Without wanting to cause another flamewar on debian-devel what
> are the chances that we could get some kind of firewall installed
> within the base system in time for a new release?
> I have seen this discussion come up a couple of times in various
> places, but without any change.
> There are many firewall packages that we could consider adding,
> and in general I think this would be a good thing.
Are there any firewall packages which, upon examination, you believe are
worth adding to the base system? I have so far not found any that
aren't burdened with chewy configuration front-ends.
I think it's a bit late to be creating such a package for sarge from
scratch.
--
Steve Langasek
postmodern programmer
| |
| Marco d'Itri 2004-03-30, 4:33 am |
| On Mar 30, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
> It could be easily controlled with tcpd if the maintainer cared to apply
> the patch [1] available in #62145 (which I've been holding myself to not
> NMU).
I'm the tcpd co-maintainer, and you'd better not NMU it without
agreement with me or aj.
--
ciao, |
Marco | [5431 aregY7d/0/LME]
| |
| Javier Fernández-Sanguino Peña 2004-03-30, 4:33 am |
| On Tue, Mar 30, 2004 at 10:14:07AM +0200, Marco d'Itri wrote:
> On Mar 30, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
>
> I'm the tcpd co-maintainer, and you'd better not NMU it without
> agreement with me or aj.
No need to be harsh here. I've always tried to follow proper NMU procedure
(making some innocent mistakes in some cases) and I wouldn't dare to NMU an
important package without sufficient testing and, even so, have only done
it (IIRC) for RC bugs.
Nevertheless, I've been bugging aj (in private e-mail) about this and other
probable NMUs (such as ifupdown, which has also some longstanding bugs that
should be fixed IMHO before release, including about 7 translations).
I will forward you the private e-mail, let's see if you can do something in
that respect....
Regards
Javier
| |
| Alexander Schmehl 2004-03-30, 6:36 am |
| Good Morning,
* Javier Fernández-Sanguino Peña <jfs@computer.org> [040330 02:38]:
> [1] This was the case of the 'standard' network services (portamap,
> nfs-common) in woody, don't know about sarge though since
> installation-reports don't include information of network services
> installed in the system.
The new sarge install on my workstation (choosed tasks to install:
»Desktop environment« and »Office environment«), portmap and nfs-common
(and some other stuff, I sure I won't need, thats the bad thing about
the tasks).
An »nmap -sV« shows me this:
PORT STATE SERVICE VERSION
9/tcp open discard?
13/tcp open daytime
22/tcp open ssh OpenSSH 3.8p1 (protocol 2.0)
37/tcp open time
111/tcp open rpcbind 2 (rpc #100000)
113/tcp open ident OpenBSD identd
515/tcp open printer BSD/Linux lpd (access denied)
835/tcp open status 1 (rpc #100024)
May I help you in an other way, before I start configuring that machine
to my needs?
Yours sincerely,
Alexander
| |
| Javier Fernández-Sanguino Peña 2004-03-30, 8:35 am |
| On Tue, Mar 30, 2004 at 12:46:54PM +0200, Alexander Schmehl wrote:
> The new sarge install on my workstation (choosed tasks to install:
> »Desktop environment« and »Office environment«), portmap and nfs-common
> (and some other stuff, I sure I won't need, thats the bad thing about
> the tasks).
Thanks for this information.
> An »nmap -sV« shows me this:
¿How about an 'lsof -ni' run in the system (as root)?
Ok. Let's find the culprits.
> PORT STATE SERVICE VERSION
> 9/tcp open discard?
> 13/tcp open daytime
Those two are default in netkit-inetd. IMHO they are not really needed, but
don't pose a huge risk [1]
> 22/tcp open ssh OpenSSH 3.8p1 (protocol 2.0)
Ssh is 'standard' priority. It is good to have it installed when a
user only want's a Desktop? Risk could be mitigated if access to it
was correctly restricted through tcp-wrappers.
> 37/tcp open time
That's provided by netkit-inetd. Again, not really useful for a
Desktop-Office environment but doesn't pose much risk [1]
> 111/tcp open rpcbind 2 (rpc #100000)
That's portmap. Again 'standard' priority. And useless in a Desktop-Office
environment unless you use RPC services (which you don't seem to)
> 113/tcp open ident OpenBSD identd
That's probably open because of 'pidentd'. Standard priority, but shouldn't
be there.
> 515/tcp open printer BSD/Linux lpd (access denied)
That's 'lpr', again, standard priority. I would rather have it configured
to _not_ listen on the tcp port, or, at least, access to it should be
limited through tcp-wrappers. It could be replaced with other printer
daemons that don't do TCP but are as useful in Desktop-Office environments
[2]
> 835/tcp open status 1 (rpc #100024)
That's probably rpc.mountd? (nfs-common, 'standard' priority).
I could make a gross estimate of risk-assesment based on the DSAs we have
published since 1997:
- openssh: 10 DSAs (19981210, 19991215a, 20001118, dsa-025, dsa-027,
dsa-086, dsa-091, dsa-119, dsa-134 and dsa-382)
- lpr: 4 DSAs (19980828a, 19991030, 20000109 and dsa-267)
- nfs-common: 1 DSA (20000719a)
OpenSSH's bugs are remote root in many cases, lpr's are usually local vulns
(there is one remote buffer overflow) and nfs-common's was a buffer
overflow. Of course, I'm omitting the security vulnerabilities these had
which didn't affect our stable releases (openssh's security bugs would be
higher).
Based on this info I still advocate for implementing/fixing #62145,
openssh, lpr, portmap and nfs-common all use tcp-wrappers (though libwrap)
Either that or find a way to avoid having openssh/lpr/portmap/nfs-common
installed in the environment Alexander describes. Only lpr is needed in
that environment and it still could be replaced with other non-network
aware printer package or configured to only listen on the loopback
interface.
Or do we have to be hit by a worm targeted to our stable release in order
to get this done? [3] Can't we learn from past mistakes? [4]
> May I help you in an other way, before I start configuring that machine
> to my needs?
Thanks a lot for the info.
Javier
[1] At least _known_ risk, besides the fact that they can be used to
fingerprint the system.
[2] Cups? It has been more vulnerable to remote attacks than lpr in the
past. PDQ was available in stable but is not available any more (why?)
Please send patches if you think you can improve this:
http://www.debian.org/doc/manuals/s...es.en.html#s5.5
[3] Hint: Red Hat added firewalling configuration in the default
installation in the next release after the Ramen/Lion worm propagated in
the default installation of RedHat 6.0-6.2
[4] Hint: The Ramen/Lion worm exploited a number of services available in
the default installation of RedHat 6.0-6.2, namely: CVE-2000-0573
(wu-ftpd), CVE-2000-0666 (rpc.statd) and CVE-2000-0917 (lprng), the worm
appeared (on average) 161 days after the patches for these were available.
The only one we (thank god) don't provide is wu-ftpd, but think
openssh =~ wu-ftpd
| |
| Patrice Fortier 2004-03-30, 9:42 am |
| Le lun 29/03/2004 à 23:28, Josip Rodin a écrit :
>
> You mean that mention of nfs-common and portmap? I didn't see that the last
> time I used the installer. If I had, I would have filed a bug about it.
> If you do, please report it.
OK so here is what I have running after a desktop install:
- inetd, with daytime, time, discard and identd allowed
- openssh (as daemon) (1)
- lpd
- portmap (2)
- nfs-common
There may be more, I don't remeber
I had updates for ssh, portmap and nfs-common last week, and
each update restarted its service even if I had disabled them
(update-rc.d -f xxx remove). As a sidenote, I find this _very_
irritating... I'd like this policy enforced for these scripts
http://www.debian.org/doc/debian-po...es.html#s10.7.3
(1) When updating, you're asked if you want the ssh service
started. Whatever the answer, it will be started anyway. This is
a known ssh package bug and it won't be fixed (so I suggest not
asking the question  ).
(2) portmap is also started in /etc/rcS.d/S41 to mount network
partitions in /etc/rcS.d/S45mountnfs.sh. I complained about that
but I was explained that it was for people with nfs /usr system.
Maybe we (you ) could ckeck this case at install time (or
first boot) to avoid this second Sxxportmap (it's also started
in /etc/rc2.d/S18portmap) during boot single.
Do you want me to fill bug reports, and for which...packages (as
the update problem with /etc/rc?.d/ scripts seems to be general)?
Regards,
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-03-30, 9:42 am |
| On Tue, Mar 30, 2004 at 03:43:10PM +0200, Patrice Fortier wrote:
> (1) When updating, you're asked if you want the ssh service
> started. Whatever the answer, it will be started anyway. This is
> a known ssh package bug and it won't be fixed (so I suggest not
> asking the question ).
Er. I know of a number of bugs in that area which will be fixed in
sarge+1 by splitting ssh into client and server packages, but this isn't
one of them. Please elaborate.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Zefram 2004-03-30, 9:42 am |
| Patrice Fortier wrote:
>I had updates for ssh, portmap and nfs-common last week, and
>each update restarted its service even if I had disabled them
>(update-rc.d -f xxx remove).
....
All of this rather resembles Bug#176009 (cron script starts a stopped lpd)
which I submitted over a year ago (just adding to the list of gripes in
this thread). We clearly have a general problem with network daemons,
not just a problem with a few specific ones.
Therefore, I suggest that we separate each of these daemon packages into
two, one that provides the daemon software and a separate one to run it.
That way those of us who want to install a daemon and use it in our own
way would not be hampered by someone's idea of how the daemon should
normally be run. And where the daemon is packaged with a client,
installing the client wouldn't cause an unwanted daemon to run.
Example: the "ssh" package would, as now, provide both the ssh client
and ssh server, but wouldn't contain an init script. There would be a
separate "ssh-daemon" package, with a dependency on the "ssh" package,
and containing an init script.
Debian should ship with *no* network daemons listening by default.
I'm rather surprised that it hasn't adopted this policy already.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Oliver Kurth 2004-03-30, 9:42 am |
| On Tue, 2004-03-30 at 16:08, Zefram wrote:
> Patrice Fortier wrote:
> Therefore, I suggest that we separate each of these daemon packages into
> two, one that provides the daemon software and a separate one to run it.
> That way those of us who want to install a daemon and use it in our own
> way would not be hampered by someone's idea of how the daemon should
> normally be run. And where the daemon is packaged with a client,
> installing the client wouldn't cause an unwanted daemon to run.
Why splitting? How about a unified system, eg. each init script sources
a config file from /etc/default, where you have a simple line like
START_FOO=yes
> Example: the "ssh" package would, as now, provide both the ssh client
> and ssh server, but wouldn't contain an init script. There would be a
> separate "ssh-daemon" package, with a dependency on the "ssh" package,
> and containing an init script.
IMHO shipping packages with just an init script is bloat.
> Debian should ship with *no* network daemons listening by default.
> I'm rather surprised that it hasn't adopted this policy already.
I agree.
Greetings,
Oliver
| |
| Colin Watson 2004-03-30, 9:42 am |
| On Tue, Mar 30, 2004 at 03:08:54PM +0100, Zefram wrote:
> Example: the "ssh" package would, as now, provide both the ssh client
> and ssh server, but wouldn't contain an init script. There would be a
> separate "ssh-daemon" package, with a dependency on the "ssh" package,
> and containing an init script.
As previously mentioned, this will happen immediately after sarge,
although not quite as you describe.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joachim Breitner 2004-03-30, 9:42 am |
| Hi,
why two packages? A little bit of magic should do it: Service gets
installed turned off, and whatever the administrator sets is respected -
on upgrade, on logrotate, on boot.
This would require some clarifications (is update-rc.d now for
administrators or for package maintainers) and some common guidelines
(some packages currently use /etc/defaults/something, some use the
symlinks in /etc/rc?.d directly, others have something set in
/etc/init.d/something or use some magic, like checking for a line in
/etc/inetd.conf).
Ideally, all network daemons, from the administrator POV:
* are installed disabled
* may be started temporarily (/etc/init.d/package start)
- then being logrotated, restarted on upgrade, but no start on boot
* may be started permanently (perhaps symlinking in /etc/rc?.d)
- logrotated, restarted on upgrade, restarted on boot
* may then be temporarily disabled (/etc/init.d/package stop)
- no logrotate restart, no start on upgrade, but start on boot.
That is, for each service we have two states ( (not)running generally
and (not)running right now) which should both be off on installation and
never be changed by upgrades or cronjobs.
[For correctness sake: since on boot the "right now" state is undefined,
starting the service according to the "generally" state is compliant
with these rules].
Questions to be solved: how to implement, what interface for package
maintainers, what interface for administrators
nomeata
Am Di, den 30.03.2004 schrieb Zefram um 16:08:
> Patrice Fortier wrote:
> ...
>
> All of this rather resembles Bug#176009 (cron script starts a stopped lpd)
> which I submitted over a year ago (just adding to the list of gripes in
> this thread). We clearly have a general problem with network daemons,
> not just a problem with a few specific ones.
>
> Therefore, I suggest that we separate each of these daemon packages into
> two, one that provides the daemon software and a separate one to run it.
> That way those of us who want to install a daemon and use it in our own
> way would not be hampered by someone's idea of how the daemon should
> normally be run. And where the daemon is packaged with a client,
> installing the client wouldn't cause an unwanted daemon to run.
>
> Example: the "ssh" package would, as now, provide both the ssh client
> and ssh server, but wouldn't contain an init script. There would be a
> separate "ssh-daemon" package, with a dependency on the "ssh" package,
> and containing an init script.
>
> Debian should ship with *no* network daemons listening by default.
> I'm rather surprised that it hasn't adopted this policy already.
--
Joachim "nomeata" Breitner
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: joachimbreitner@amessage.de | http://people.debian.org/~nomeata
| |
| Zefram 2004-03-30, 10:35 am |
| Joachim Breitner wrote:
>why two packages? A little bit of magic should do it: Service gets
>installed turned off,
Ah, that would be neater.
>This would require some clarifications (is update-rc.d now for
>administrators or for package maintainers)
I've been wondering that too.
-zefram
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Patrice Fortier 2004-03-30, 10:35 am |
| Le mar 30/03/2004 à 15:43, Patrice Fortier a écrit :
> I had updates for ssh, portmap and nfs-common last week, and
> each update restarted its service even if I had disabled them
> (update-rc.d -f xxx remove).
hum, I forgot to say that the daemons were restarted and the
symlinks in /etc/rc?.d/ were _created again_.
This is what I meant pointing
http://www.debian.org/doc/debian-po...es.html#s10.7.3
Regards,
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Javier Fernández-Sanguino Peña 2004-03-30, 10:35 am |
| On Tue, Mar 30, 2004 at 03:43:10PM +0200, Patrice Fortier wrote:
> I had updates for ssh, portmap and nfs-common last week, and
> each update restarted its service even if I had disabled them
> (update-rc.d -f xxx remove). As a sidenote, I find this _very_
> irritating... I'd like this policy enforced for these scripts
> http://www.debian.org/doc/debian-po...es.html#s10.7.3
This is really a FAQ item, you should not remove all of the items, just the
start links so the status is preserved on upgrades. for more info:
http://www.debian.org/doc/manuals/s...l#s-disableserv
> (1) When updating, you're asked if you want the ssh service
> started. Whatever the answer, it will be started anyway. This is
> a known ssh package bug and it won't be fixed (so I suggest not
> asking the question ).
Which bug # is this?
> (2) portmap is also started in /etc/rcS.d/S41 to mount network
> partitions in /etc/rcS.d/S45mountnfs.sh. I complained about that
> but I was explained that it was for people with nfs /usr system.
> Maybe we (you ) could ckeck this case at install time (or
> first boot) to avoid this second Sxxportmap (it's also started
> in /etc/rc2.d/S18portmap) during boot single.
That could be a opened as a bug too. IMHO.
> Do you want me to fill bug reports, and for which...packages (as
> the update problem with /etc/rc?.d/ scripts seems to be general)?
The problem in the rc?.d scripts is not really a problem. It's more like a
feature.
Regards
Javier
| |
| Henning Makholm 2004-03-30, 10:36 am |
| Scripsit Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <jfs@computer.org>
[color=darkred]
> Ssh is 'standard' priority. It is good to have it installed when a
> user only want's a Desktop?
I think that an ssh *client* would fit the definition for "important".
The server, on the other hand, ought to be "optional" - and part of
the "internet server" task. Perhaps "standard" is a compromise. :-)
I wonder what's keeping openssh from being split into a client and a
server package. #39741 is more than 4 years old, and the bug log does
not contain a single sentence explaining why none of the maintainers
it has had during the years have found it worthwhile/possible to split
it. It can't be that hard, can it?
--
Henning Makholm "Nej, hvor er vi altså heldige! Længe
leve vor Buxgører Sansibar Bastelvel!"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Patrice Fortier 2004-03-30, 10:36 am |
| [This is the reply I sent to colin, but as I'm asked for it again ]
Le mar 30/03/2004 à 15:56, Colin Watson a écrit :
> On Tue, Mar 30, 2004 at 03:43:10PM +0200, Patrice Fortier wrote:
>
> Er. I know of a number of bugs in that area which will be fixed in
> sarge+1 by splitting ssh into client and server packages, but this isn't
> one of them. Please elaborate.
I guess it is : #140963
But I didn't stated it correctly. I meant it won't be fixed in sarge.
I'm not asked the question (to start or not sshd) during the install,
but I am when updating.
As I use ssh with xinetd, I don't need it started in /etc/rc?.d/.
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-03-30, 11:37 am |
| On Tue, Mar 30, 2004 at 04:10:51PM +0100, Henning Makholm wrote:
> I wonder what's keeping openssh from being split into a client and a
> server package. #39741 is more than 4 years old,
Doesn't one of the other bug reports mention it? Maybe not ...
> and the bug log does not contain a single sentence explaining why none
> of the maintainers it has had during the years have found it
> worthwhile/possible to split it. It can't be that hard, can it?
It's fiddly, but the main reason I haven't done it yet is that ssh has
hundreds of bug reports and during the sarge release cycle I much
preferred to try to get the thing as stable as possible and cut the bug
count down before doing large and potentially destabilizing things. As
I've now said several times in this thread, it's first on the list for
sarge+1.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Michael Banck 2004-03-30, 12:35 pm |
| On Tue, Mar 30, 2004 at 03:21:25PM +0200, Javier Fernández-Sanguino Peña wrote:
>
> Ssh is 'standard' priority. It is good to have it installed when a
> user only want's a Desktop?
To the best of my knowledge, ssh asks the user whether he/she wants to
run the demon. I think that's good enough for sarge, and the problem
will be fixed in sarge+1 anyway.
Michael
--
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2004-03-30, 4:35 pm |
| In article <1080654190.3518.32.camel@minas-tirith.u-bordeaux3.fr>,
Patrice Fortier <Patrice.Fortier@u-bordeaux3.fr> wrote:
>I had updates for ssh, portmap and nfs-common last week, and
>each update restarted its service even if I had disabled them
>(update-rc.d -f xxx remove).
That's the wrong way to disable a service. Next time you upgrade,
the links will re-appear. You had to use -f (force) to do this,
which is already a hint that You Shouldn't Do That Unless You
Know What You Are Doing.
Mike.
--
Netu, v qba'g yvxr gur cynvagrkg
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2004-03-30, 4:35 pm |
| In article <1080656620.663.10.camel@barney.ehbuehl.net>,
Joachim Breitner <nomeata@debian.org> wrote:
>why two packages? A little bit of magic should do it: Service gets
>installed turned off, and whatever the administrator sets is respected -
>on upgrade, on logrotate, on boot.
>This would require some clarifications (is update-rc.d now for
>administrators or for package maintainers) and some common guidelines
>(some packages currently use /etc/defaults/something, some use the
>symlinks in /etc/rc?.d directly, others have something set in
>/etc/init.d/something or use some magic, like checking for a line in
>/etc/inetd.conf).
>
>Ideally, all network daemons, from the administrator POV:
> * are installed disabled
> * may be started temporarily (/etc/init.d/package start)
> - then being logrotated, restarted on upgrade, but no start on boot
> * may be started permanently (perhaps symlinking in /etc/rc?.d)
> - logrotated, restarted on upgrade, restarted on boot
> * may then be temporarily disabled (/etc/init.d/package stop)
> - no logrotate restart, no start on upgrade, but start on boot.
>
>That is, for each service we have two states ( (not)running generally
>and (not)running right now) which should both be off on installation and
>never be changed by upgrades or cronjobs.
>
>Questions to be solved: how to implement, what interface for package
>maintainers, what interface for administrators
Implementation is easy.. Set "AUTORUN" to "True" or "False" in
/etc/default/sshd. Then:
AUTORUN=True
[ ! -f /etc/default/sshd ] || . /etc/default/sshd
case "${0##*/}" in
S*)
case "$AUTORUN" in
[YyTt]*)
;;
*)
exit 0
;;
esac
;;
esac
That's all. The only thing is that file-rc must be changed to start
the init.d scripts with SnnNAME or KnnNAME instead of just NAME.
Sysvinit already does this because it executes the symlink to
the script, so you can test $0.
Restart should only be done if the service is currently running.
That's hard when upgrading: if you stop the package in preinst
and want to start it in postinst, you have to remember the
"is running" state somewhere. It would be better than the
current invoke-rc.d though, which might not restart a service
that was running, or might start a service that wasn't.
Perhaps two new arguments to an initscript: "suspend" which would
stop the service if it was running and save the running state
to /var/run/running/packagename, and "resume" which would be
like "start" but only if /var/run/running/packagename is
present.
Invoke-rc.d would have to be modified to try "suspend" first,
and fall back to the normal "stop if normally running in this
runlevel" behaviour if it didn't work.
Hmm, "suspend" and "resume" are perhaps not the best names in the
world for this because of their association with powersave mode.
Mike.
--
Netu, v qba'g yvxr gur cynvagrkg
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Gran 2004-03-30, 8:34 pm |
| This one time, at band camp, Miquel van Smoorenburg said:
>
> AUTORUN=True
> [ ! -f /etc/default/sshd ] || . /etc/default/sshd
>
> case "${0##*/}" in
> S*)
> case "$AUTORUN" in
> [YyTt]*)
> ;;
> *)
> exit 0
> ;;
> esac
> ;;
> esac
>
> That's all. The only thing is that file-rc must be changed to start
> the init.d scripts with SnnNAME or KnnNAME instead of just NAME.
> Sysvinit already does this because it executes the symlink to
> the script, so you can test $0.
Or
case "$1" in
start)
case "$AUTORUN" in
[...]
;;
....
No need to change other things for that.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
| |
| Adrian 'Dagurashibanipal' von Bidder 2004-03-31, 2:33 am |
| | |
| Marc Haber 2004-03-31, 3:35 am |
| On Tue, 30 Mar 2004 02:38:26 +0200, Javier Fern=E1ndez-Sanguino Pe=F1a
<jfs@computer.org> wrote:
>Iptables is, or at least I think it is. However, the maintainer, in
>response to #212692, said:
>
>"iptables is not a firewall."
>
>Feel free to reopen that bug report, if firewall configuration should be
>part of the base install, it should be done by a good default rule in =
the
>iptables scripts.
No!
That would make all the firewall scripts out there more complex, and
it would probably break them on introduction and upgrades. If we
insist on shipping an unnecessary firewall with the base system, we
_MUST_ make it easily uninstallable while retaining
/usr/sbin/iptables. And surely a lot of systems is going to break on
upgrade if the current iptables package is suddenly replaced by one
establishing a non-empty, non-permit-all rule set on installation.
Greetings
Marc
--=20
-------------------------------------- !! No courtesy copies, please !! =
-----
Marc Haber | " Questions are the | Mailadresse im =
Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32=
15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31=
29
| |
| Andreas Barth 2004-03-31, 10:40 am |
| * Marc Haber (mh+debian-devel@zugschlus.de) [040331 10:10]:
> On Tue, 30 Mar 2004 02:38:26 +0200, Javier Fernández-Sanguino Peña
> <jfs@computer.org> wrote:
[color=darkred]
> No!
>
> That would make all the firewall scripts out there more complex, and
> it would probably break them on introduction and upgrades. If we
> insist on shipping an unnecessary firewall with the base system, we
> _MUST_ make it easily uninstallable while retaining
> /usr/sbin/iptables. And surely a lot of systems is going to break on
> upgrade if the current iptables package is suddenly replaced by one
> establishing a non-empty, non-permit-all rule set on installation.
If we consider installing some firewall script by default, than this
should only be done by d-i, and not by a "normal" upgrade. Via this
way, there is no risk for existing setups, and it can quite easily be
disabled. If this easy firewall is just some new package, than it's
also quite easy to enhance existing installations with it.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Patrice Fortier 2004-03-31, 11:37 am |
| Le mar 30/03/2004 à 17:02, Javier Fernández-Sanguino Peña a écrit :
> On Tue, Mar 30, 2004 at 03:43:10PM +0200, Patrice Fortier wrote:
>
> This is really a FAQ item, you should not remove all of the items, just the
> start links so the status is preserved on upgrades. for more info:
> http://www.debian.org/doc/manuals/s...l#s-disableserv
As it is said, it's really not intuitive.
What is the reason for this behaviour?
I guess there already were a lot of discussions as:
1/ It's not intuitive (so much, that's even written in your manual).
2/ It violates the debian policy for /etc/ files.
3/ someone had to code this, and make people accept it .
I'm really interested by an answer for this.
> The problem in the rc?.d scripts is not really a problem. It's more like a
> feature.
;o)
Regards,
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-31, 1:37 pm |
| On Tue, Mar 30, 2004 at 02:21:51AM +0200, Javier Fernández-Sanguino Peña wrote:
> Funny. As with Steve's example, we don't enforce any policy regarding tcp.
> We used to have a "PARANOID" one, but now we don't even do that.
Good. TCP "paranoid" setting does nothing for security.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alexander Schmehl 2004-03-31, 3:38 pm |
| Good evening,
Sorry for the delay, had some work to do.
* Javier Fern=E1ndez-Sanguino Pe=F1a <jfs@computer.org> [040330 15:21]:
> Thanks for this information.
Your are welcome.
> =BFHow about an 'lsof -ni' run in the system (as root)?
~# lsof -ni
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 633 daemon 3u IPv4 1974 UDP *:sunrpc=20
portmap 633 daemon 4u IPv4 1975 TCP *:sunrpc (LISTEN)
exim4 1051 Debian-exim 0u IPv4 2428 TCP 127.0.0.1:smtp (LIS=
TEN)
famd 1056 root 3u IPv4 2453 TCP 127.0.0.1:omirr (LI=
STEN)
inetd 1061 root 4u IPv4 2465 TCP *:discard (LISTEN)
inetd 1061 root 5u IPv4 2466 UDP *:discard=20
inetd 1061 root 6u IPv4 2467 TCP *:daytime (LISTEN)
inetd 1061 root 7u IPv4 2468 TCP *:time (LISTEN)
inetd 1061 root 8u IPv4 2469 TCP *:auth (LISTEN)
lpd 1065 root 6u IPv4 2495 TCP *:printer (LISTEN)
sshd 1073 root 3u IPv4 2502 TCP *:ssh (LISTEN)
rpc.statd 1079 root 4u IPv4 2535 UDP *:834=20
rpc.statd 1079 root 5u IPv4 2519 UDP *:831=20
rpc.statd 1079 root 6u IPv4 2547 TCP *:837 (LISTEN)
ntpd 1082 root 4u IPv4 2542 UDP *:ntp=20
ntpd 1082 root 5u IPv4 2543 UDP 127.0.0.1:ntp=20
ntpd 1082 root 6u IPv4 2544 UDP 192.168.0.2:ntp=20
xfce4-ses 1122 alex 4u IPv4 2650 TCP *:32768 (LISTEN)
sshd 1213 root 4u IPv4 3431 TCP 192.168.0.2:ssh->19=
2.168.0.3:32817 (ESTABLISHED)
Oh, after the installation I did two things: I installed ntp,
ntp-simple, ntpdate and sids xfce4.
>=20
> Ssh is 'standard' priority. It is good to have it installed when a=20
> user only want's a Desktop? Risk could be mitigated if access to it=20
> was correctly restricted through tcp-wrappers.
Allthough I would would install both packages on all my systems, I think
that from the (desktop) users point of view, it would be easier to have
the package splited in -server and -client.
Yours sincerely,
Alexander
| |
| Alexander Schmehl 2004-03-31, 3:38 pm |
| * Michael Banck <mbanck@debian.org> [040330 18:55]:
> To the best of my knowledge, ssh asks the user whether he/she wants to
> run the demon. I think that's good enough for sarge, and the problem
> will be fixed in sarge+1 anyway.
Yes, during the metioned installation I have been asked, and I wanted
the ssh-server to be started.
Yours sincerely,
Alexander
| |
| Henning Makholm 2004-03-31, 7:35 pm |
| Scripsit Patrice Fortier <Patrice.Fortier@u-bordeaux3.fr>
> Le mar 30/03/2004 à 17:02, Javier Fernández-Sanguino Peña a écrit :
[color=darkred]
> As it is said, it's really not intuitive.
> What is the reason for this behaviour?
It is easy to implement in update-rc.d without needing specific
support from the maintainer scripts to tell it whether the
package is being installed anew or just updated (or resurrected from
removed-but-not-purged state).
--
Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at
følge den vej kun bliver gennemsnitligt ca. 48 år gammel,
og at man sætter sin sociale situation ganske overstyr og, så
vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed."
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Javier Fernández-Sanguino Peña 2004-04-01, 3:37 am |
|
On Wed, Mar 31, 2004 at 09:28:42AM -0800, Adam McKenna wrote:
> On Tue, Mar 30, 2004 at 02:21:51AM +0200, Javier Fernández-Sanguino Peña wrote:
>
> Good. TCP "paranoid" setting does nothing for security.
I agree here [1]. My proposal to #62145 is not to reinstate that, but to
have tcpd ask people wether they want an "ALL: ALL" in their
/etc/hosts.deny, _that's_ what I call paranoid :-)
Javi
[1] Tcp-wrappers' paranoid definition is based on being able to do a
reverse DNS resolution of the incoming IP address.
| |
| Patrice Fortier 2004-04-02, 9:34 am |
| Le mar 30/03/2004 à 16:23, Joachim Breitner a écrit :
> Hi,
>
> This would require some clarifications (is update-rc.d now for
> administrators or for package maintainers)
Considering all I read here about update-rc.d, I'd say that it was
(at least) designed to be used by package maintainers. As explained
in
http://www.debian.org/doc/manuals/s...l#s-disableserv
it's hard to use it correctly if you're not aware of some package
maintainance subtilities (the last link in /etc/rc?.d/ for example),
which is not even described in the man page.
But, when someone ask where is chkconfig (the RH version of
update-rc.d), everybody reply that it's update-rc.d.
So from this PoV, I consider that it's also an administrator tool.
And there's still the "good ol' days" way:
find /etc/rc?.d/ -name "???service" -exec rm {} \;
> and some common guidelines
> (some packages currently use /etc/defaults/something, some use the
> symlinks in /etc/rc?.d directly, others have something set in
> /etc/init.d/something or use some magic, like checking for a line in
> /etc/inetd.conf).
>
> Ideally, all network daemons, from the administrator POV:
> * are installed disabled
> * may be started temporarily (/etc/init.d/package start)
> - then being logrotated, restarted on upgrade, but no start on boot
> * may be started permanently (perhaps symlinking in /etc/rc?.d)
> - logrotated, restarted on upgrade, restarted on boot
> * may then be temporarily disabled (/etc/init.d/package stop)
> - no logrotate restart, no start on upgrade, but start on boot.
Exactly!
> Questions to be solved: how to implement, what interface for package
> maintainers, what interface for administrators
In a pleasant world update-rc.d should be enough for both.
The main problem seems to be that the design of update-rc.d is
flawed:
Quoted from Henning Makholm:
>
> It is easy to implement in update-rc.d without needing specific
> support from the maintainer scripts to tell it whether the
> package is being installed anew or just updated (or resurrected from
> removed-but-not-purged state).
As I understand this (correct me if I'm wrong), when update-rc.d
is called (.postinst ?) by a package, it is unable to know if it's
performing an install (create the links) or an update (don't touch
anything).
So, update-rc.d is based on a hack, which check if there is at least
a single link remaining in /etc/rc?.d/ to guess if the package is
already installed or not.
There are several drawbacks in this situation:
- there are (heavy) chances that update-rc.d asumptions are false.
If the admin want to disable a service, he will make a find/rm, or
read the update-rc.d man page and make update-rc.d -f.
update-rc.d behaviour will then be wrong, performing an install
instead of an update, and violating the policy about /etc files.
- As it's based on hack, an admin needs to know about this
http://www.debian.org/doc/manuals/s...l#s-disableserv
to use update-rc.d correctly. ie: the admin needs to perfrom a
hack to make a simple task.
So, I guess that the real question to ask is more:
How (or when) can we know during the package installation if we're
performing an install or an update, to call update-rc.d accordingly?
With this, you can remove the hack from update-rc.d, and it can be
used by both package managers and administrators.
This is mainly a package update problem.
Regards,
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| cobaco (aka Bart Cornelis) 2004-04-02, 9:34 am |
| =2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Quoted from Henning Makholm:
>
> As I understand this (correct me if I'm wrong), when update-rc.d
> is called (.postinst ?) by a package, it is unable to know if it's
> performing an install (create the links) or an update (don't touch
> anything).
> So, update-rc.d is based on a hack, which check if there is at least
> a single link remaining in /etc/rc?.d/ to guess if the package is
> already installed or not.
I'm probably missing something, but is their any reason way it doesn't jus=
t=20
check whether the /etc/init.d/<package> script is there? You could then=20
then do with the /etc/rc?.d/ links what you want.
=2D --=20
Cheers, cobaco (aka Bart Cornelis)
=20
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAbW4C5ihPJ4ZiSrsRAiAvAJ9lBpqQTUKs
yDrDZfRsaPwYXjfYswCglyq8
B6j/kIL0eOadRiVT2zVEB9M=3D
=3D/Ei1
=2D----END PGP SIGNATURE-----
| |
| sean finney 2004-04-02, 10:36 am |
| hey,
On Fri, Apr 02, 2004 at 03:30:55PM +0200, Patrice Fortier wrote:
> Quoted from Henning Makholm:
>
> As I understand this (correct me if I'm wrong), when update-rc.d
> is called (.postinst ?) by a package, it is unable to know if it's
> performing an install (create the links) or an update (don't touch
> anything).
it's possible to know in the postinst whether you are performing a fresh
install or an upgrade, which is a much more accurate way of determining
what to do with symlinks in /etc/rc?.d.
> I'm probably missing something, but is their any reason way it doesn't just
> check whether the /etc/init.d/<package> script is there? You could then
> then do with the /etc/rc?.d/ links what you want.
if someone removes a package without purgeing, re-installing it will
seem like an upgrade with these tests.
sean
| |
| Andreas Metzler 2004-04-02, 10:36 am |
| On Fri, Apr 02, 2004 at 03:30:55PM +0200, Patrice Fortier wrote:
> Le mar 30/03/2004 à 16:23, Joachim Breitner a écrit :
[color=darkred]
> Considering all I read here about update-rc.d, I'd say that it was
> (at least) designed to be used by package maintainers.
Imho correct.
[...]
> But, when someone ask where is chkconfig (the RH version of
> update-rc.d), everybody reply that it's update-rc.d.
> So from this PoV, I consider that it's also an administrator tool.
I agree. chkconfig combines the funtionality of update-rc.d and a
runlevel-editor like rcconf.
cu andreas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Henning Makholm 2004-04-02, 6:37 pm |
| Scripsit "cobaco (aka Bart Cornelis)" <cobaco@linux.be>
[color=darkred]
> I'm probably missing something, but is their any reason way it doesn't just
> check whether the /etc/init.d/<package> script is there?
It wouldn't learn anything by checking - when postinst runs, the
script is *always* there (unless the sysadmin has forcefully removed
it even from /etc/init.d/, which seems a little extreeme).
--
Henning Makholm "They discussed old Tommy Somebody and Jerry Someone Else."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-04-04, 5:34 am |
| Javier Fern=C3=A1ndez-Sanguino Pe=C3=B1a wrote:
> On Tue, Mar 30, 2004 at 12:46:54PM +0200, Alexander Schmehl wrote:
<snip>
>=20
> That's portmap. Again 'standard' priority. And useless in a Desktop-O=
ffice
> environment unless you use RPC services (which you don't seem to)
The automatic portmap install sucks, and apparently is usually due to F=
AM
requiring and using RPC. This whole chain is unnecessary unless you us=
e
NFS, but apparently the FAM and portmap maintainers haven't managed to
coordinate their act well enough to figure out how to run fam *without*=
RPC=20
listening by default. :-P Perhaps a fam-norpc package in 'standard', =
with
the full fam package in 'extra'?
>=20
> That's probably open because of 'pidentd'. Standard priority, but
> shouldn't be there.
Who uses identd anyway? :-) From reading the RFC, the daemon seems to =
be
quite strictly a server tool, and fairly sophisticated servers at that =
--
but I could be utterly mistaken.
<snip>
> Based on this info I still advocate for implementing/fixing #62145,
> openssh, lpr, portmap and nfs-common all use tcp-wrappers (though lib=
wrap)
> Either that or find a way to avoid having openssh/lpr/portmap/nfs-com=
mon
> installed in the environment Alexander describes.
Indeed. :-(
> Only lpr is needed in
> that environment and it still could be replaced with other non-networ=
k
> aware printer package or configured to only listen on the loopback
> interface.
--=20
Make sure your vote will count.
http://www.verifiedvoting.org/
| |
| Nathanael Nerode 2004-04-04, 5:34 am |
| Alexander Schmehl wrote:
> Good evening,
>=20
> Sorry for the delay, had some work to do.
>=20
>=20
> * Javier Fern=C3=A1ndez-Sanguino Pe=C3=B1a <jfs@computer.org> [040330=
15:21]:
>=20
>=20
> Your are welcome.
>=20
>=20
>=20
> ~# lsof -ni
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> portmap 633 daemon 3u IPv4 1974 UDP *:sunrpc
> portmap 633 daemon 4u IPv4 1975 TCP *:sunrpc (LIS=
TEN)
The fault of fam....
> exim4 1051 Debian-exim 0u IPv4 2428 TCP 127.0.0.1:smt=
p
> (LISTEN)
Not fam. =20
Perhaps there should be some way to say "I don't actually receive SMTP =
mail
on this machine, so don't run a server".
> famd 1056 root 3u IPv4 2453 TCP 127.0.0.1:omi=
rr
> (LISTEN)
fam...
> inetd 1061 root 4u IPv4 2465 TCP *:discard (LI=
STEN)
> inetd 1061 root 5u IPv4 2466 UDP *:discard
> inetd 1061 root 6u IPv4 2467 TCP *:daytime (LI=
STEN)
> inetd 1061 root 7u IPv4 2468 TCP *:time (LISTE=
N)
> inetd 1061 root 8u IPv4 2469 TCP *:auth (LISTE=
N)
> lpd 1065 root 6u IPv4 2495 TCP *:printer (LI=
STEN)
Not fam. =20
> sshd 1073 root 3u IPv4 2502 TCP *:ssh (LISTEN=
)
Apparently required deliberate installation.
> rpc.statd 1079 root 4u IPv4 2535 UDP *:834
> rpc.statd 1079 root 5u IPv4 2519 UDP *:831
> rpc.statd 1079 root 6u IPv4 2547 TCP *:837 (LISTEN=
)
Fam's fault again...
> ntpd 1082 root 4u IPv4 2542 UDP *:ntp
> ntpd 1082 root 5u IPv4 2543 UDP 127.0.0.1:ntp=
> ntpd 1082 root 6u IPv4 2544 UDP 192.168.0.2:n=
tp
Apparently required deliberate installation.
> xfce4-ses 1122 alex 4u IPv4 2650 TCP *:32768 (LIST=
EN)
XFCE listens remotely by default?!? That sounds bad. Or did you confi=
gure
it to do that?
> sshd 1213 root 4u IPv4 3431 TCP
Apparently required deliberate installation.
So, of the ones which didn't require deliberate installation, we have s=
ix
from FAM, 5 from inetd, lpd, exim4, and xfce4. It sounds like the prob=
lems
are actually concentrated in a few packages. :-P
--=20
Make sure your vote will count.
http://www.verifiedvoting.org/
| |
| Andreas Metzler 2004-04-04, 6:34 am |
| Nathanael Nerode <neroden@twcny.rr.com> wrote:
> Alexander Schmehl wrote:
[...]
> Not fam.
> Perhaps there should be some way to say "I don't actually receive SMTP mail
> on this machine, so don't run a server".
[...]
There is. QUEUERUNNER='queueonly' in /etc/default/exim4. Or you can
disable the daemon the usual way by modifying the runlevel symlinks.
You are aware that this exim4 is only listening on the loopback
interfcae, are you?
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Per Olofsson 2004-04-04, 6:34 am |
| On Sun, Apr 04, 2004 at 05:03 -0400, Nathanael Nerode wrote:
> Fam's fault again...
No, that's NFS.
--
Pelle
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-04-04, 6:35 am |
| Per Olofsson wrote:
> On Sun, Apr 04, 2004 at 05:03 -0400, Nathanael Nerode wrote:
>
> No, that's NFS.
Really? Why in the name of * is NFS installed by default?
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-04-04, 7:35 am |
| Andreas Metzler wrote:
> Nathanael Nerode <neroden@twcny.rr.com> wrote:
> [...]
> [...]
>
> There is. QUEUERUNNER='queueonly' in /etc/default/exim4. Or you can
> disable the daemon the usual way by modifying the runlevel symlinks.
>
> You are aware that this exim4 is only listening on the loopback
> interfcae, are you?
> cu andreas
Yes. No real complaint about exim4. I was mostly going "what the hell is
wrong with FAM?"
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Per Olofsson 2004-04-04, 7:35 am |
| On Sun, Apr 04, 2004 at 06:15 -0400, Nathanael Nerode wrote:
> Really? Why in the name of * is NFS installed by default?
Historical reasons perhaps? Unix systems usually have NFS as a part of
their standard installation, I think.
If the NFS packages' priority were lowered, the same could be done
with portmap, so that you won't get that package either unless you
really install fam (or something else which depends on portmap). Not
everybody uses fam.
--
Pelle
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gary L Greene Jr 2004-04-04, 8:34 am |
| =2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 04 April 2004 05:03 am, Nathanael Nerode wrote:
> Alexander Schmehl wrote:
5:21]:[color=darkred]
N)[color=darkred]
>
> The fault of fam....
No. This is the fault of the RPC for the NFS server.
>
> Fam's fault again...
>
Again, not related to FAM, but to the NFS server.
=2D --=20
Gary L. Greene, Jr.
Sent from uriel.gvsu.edu
07:24:19 up 14:54, 2 users, load average: 0.47, 0.46, 0.27
Ark Linux - Home (1.0-0.dockyard20040130.1ark)
running on a \m, <\l>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=46ounder and president of the Grand Valley Linux Users Group
check out http://www.gvlug.org/ for more info.
PHONE : (616) 331-0849
EMAIL : greeneg@arklinux.org (my Ark Linux account)
EMAIL : greeneg@student.gvsu.edu (my student account)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAb/ETrTQE7CqFxs8RAn/OAJ9zOZHZUedYfpskWMobyzu/URGSEgCgxoMS
XwpNm2P0nHd37Zcre4w+upM=3D
=3DEUjP
=2D----END PGP SIGNATURE-----
| |
| Gary L Greene Jr 2004-04-04, 8:34 am |
| =2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 04 April 2004 07:15 am, Per Olofsson wrote:
> On Sun, Apr 04, 2004 at 06:15 -0400, Nathanael Nerode wrote:
>
> Historical reasons perhaps? Unix systems usually have NFS as a part of
> their standard installation, I think.
>
> If the NFS packages' priority were lowered, the same could be done
> with portmap, so that you won't get that package either unless you
> really install fam (or something else which depends on portmap). Not
> everybody uses fam.
=46AM doesn't use portmap, only NFS does from what I recall.
=2D --=20
Gary L. Greene, Jr.
Sent from uriel.gvsu.edu
07:27:51 up 14:58, 2 users, load average: 0.18, 0.28, 0.23
Ark Linux - Home (1.0-0.dockyard20040130.1ark)
running on a \m, <\l>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=46ounder and president of the Grand Valley Linux Users Group
check out http://www.gvlug.org/ for more info.
PHONE : (616) 331-0849
EMAIL : greeneg@arklinux.org (my Ark Linux account)
EMAIL : greeneg@student.gvsu.edu (my student account)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAb/ FqrTQE7CqFxs8RAkRRAJ4xxBVlgPkO1mU5PqQBY1
FAqTXFEgCgnvjc
CqUVk+AMGJxS19tWJHKt8gg=3D
=3DtUSY
=2D----END PGP SIGNATURE-----
| |
| Per Olofsson 2004-04-04, 8:34 am |
| On Sun, Apr 04, 2004 at 06:28 -0500, Gary L Greene Jr wrote:
> FAM doesn't use portmap, only NFS does from what I recall.
$ apt-cache show fam
Package: fam
[...]
Depends: portmap, libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.2-1),
libstdc++5 (>= 1:3.3.2-1)
--
Pelle
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-04-05, 9:35 am |
| On 04-Apr-04, 03:56 (CDT), Nathanael Nerode <neroden@twcny.rr.com> wrote:
> Javier Fern??ndez-Sanguino Pe??a wrote:
>
> The automatic portmap install sucks, and apparently is usually due to FAM
> requiring and using RPC.
Didn't we have this discussion last week? (See the archives, on "New
portmap packages" and "Fam mustn't depend on portmap", in January 04.)
The conclusion was that fam is written in a way to make it difficult to
seperate, and that portmap wasn't huge security risk anyway, but that it
should default to listening only on localhost. I think.
> Who uses identd anyway? :-)
IRC users. A lot of IRC daemons expect the client to support identd
services, even though it's completely useless.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Patrice Fortier 2004-04-05, 9:35 am |
| Le dim 04/04/2004 à 10:56, Nathanael Nerode a écrit :
>
> The automatic portmap install sucks, and apparently is usually due to FAM
> requiring and using RPC. This whole chain is unnecessary unless you use
> NFS,
I already tested some sarge install here and I don't have fam always
installed. I always had portmap and nfs installed though.
So the problem is more with nfs than with fam IMHO.
Note that portmap is _also_ started in /etc/rcS.d/.
Regards,
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marc Haber 2004-04-05, 4:34 pm |
| On Mon, 5 Apr 2004 07:28:02 -0500, Steve Greenland
<steveg@moregruel.net> wrote:
>IRC users. A lot of IRC daemons expect the client to support identd
>services, even though it's completely useless.
Demanding identd on IRC connects helps ruling out the gazillions of
open and misconfiured ip proxies out there. This application of identd
is far from what it was designed to accomplish, though.
Greetings
Marc
--=20
-------------------------------------- !! No courtesy copies, please !! =
-----
Marc Haber | " Questions are the | Mailadresse im =
Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32=
15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31=
29
| |
|
| |