Your message dated Wed, 3 Aug 2005 23:21:42 +1000
with message-id <[EMAIL PROTECTED]>
and subject line Bug#318350: completely disable zeroconf with switch in
/etc/defaults/zeroconf
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 14 Jul 2005 23:57:14 +0000
>From [EMAIL PROTECTED] Thu Jul 14 16:57:14 2005
Return-path: <[EMAIL PROTECTED]>
Received: from bender.bawue.de [193.7.176.20]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DtDZq-0001ou-00; Thu, 14 Jul 2005 16:57:14 -0700
Received: by bender.bawue.de (Postfix, from userid 10)
id 32E2E44045; Fri, 15 Jul 2005 01:57:11 +0200 (MEST)
Received: by mobile-mx.n-dimensional.de (Postfix, from userid 1001)
id B9E737104A; Fri, 15 Jul 2005 01:56:14 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Hans Ulrich Niedermann <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: completely disable zeroconf with switch in /etc/defaults/zeroconf
X-Mailer: reportbug 3.15
Date: Fri, 15 Jul 2005 01:56:14 +0200
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: zeroconf
Version: 0.6-1
Severity: wishlist
It would be very nice if one could add a DISABLE_ZEROCONF=yes switch
or something similar to /etc/default/zeroconf.
This could come in quite handy in cases where something goes wrong
with zeroconf.
The example leading me to this idea is a little confused, but I'm
describing it here for reference purposes anyway.
I've just experienced a case of a system hanging indefinitely at
"ifup -a" time while booting, which was caused by this old
/etc/network/if-up.d/zeroconf script:
,----
|#!/bin/sh
|
|/usr/sbin/zeroconf -i $IFACE
`----
which probably some older package had left lying around.
Having no clean way to disable zeroconf, I resorted to
"dpkg --purge zeroconf", which then, incidentally, didn't remove the
/etc/network/if-up.d/zeroconf script. But that was ok - at least
"ifup -a" was failing now, not hanging.
Hmm... perhaps "ifup -a" should use a timeout, but that would be
a seperate wishlist bug, I think.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (900, 'stable'), (700, 'unstable'), (100,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.10-swsusp2-ndim-2
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
---------------------------------------
Received: (at 318350-done) by bugs.debian.org; 3 Aug 2005 13:18:40 +0000
>From [EMAIL PROTECTED] Wed Aug 03 06:18:40 2005
Return-path: <[EMAIL PROTECTED]>
Received: from baalzebub.progsoc.uts.edu.au [138.25.6.16] (Debian-exim)
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1E0J8p-00055Y-00; Wed, 03 Aug 2005 06:18:39 -0700
Received: from wildfire by baalzebub.progsoc.uts.edu.au with local (Exim 4.34)
id 1E0JBm-00078s-OV; Wed, 03 Aug 2005 23:21:42 +1000
Date: Wed, 3 Aug 2005 23:21:42 +1000
From: Anand Kumria <[EMAIL PROTECTED]>
To: Hans Ulrich Niedermann <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Bug#318350: completely disable zeroconf with switch in
/etc/defaults/zeroconf
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.6+20040907i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: [EMAIL PROTECTED]
X-SA-Exim-Scanned: No (on baalzebub.progsoc.uts.edu.au); SAEximRunCond expanded
to false
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Hi Hans,
The most recent upload of zeroconf (0.6.1-1) now has the ability to be
completely disabled as you requested. I just forgot to close the bug in
the changelog.
Cheers,
Anand
On Sat, Jul 16, 2005 at 12:50:21PM +0200, Hans Ulrich Niedermann wrote:
> Anand Kumria <[EMAIL PROTECTED]> writes:
>
> > On Sat, Jul 16, 2005 at 10:19:42AM +0200, Hans Ulrich Niedermann wrote:
> >> Anand Kumria <[EMAIL PROTECTED]> writes:
> >>
> >> > On Fri, Jul 15, 2005 at 01:56:14AM +0200, Hans Ulrich Niedermann wrote:
> >> >> Package: zeroconf
> >> >> Version: 0.6-1
> >> >> Severity: wishlist
> >> >>
> >> >>
> >> >> It would be very nice if one could add a DISABLE_ZEROCONF=yes switch
> >> >> or something similar to /etc/default/zeroconf.
> >> >
> >> > Why would you disable it completely? Why not just blacklist the
> >> > particular interface you are having problems with?
>
> [...]
>
> >> 2. If a problem occurs during the "ifup -a" on boot, there is no
> >> running system in which one could easily check which of the
> >> interfaces is actually having the problem.
> >>
> >> Completely disable zeroconf it from a rescue system, boot up, and
> >> then check each interface from the running system is much easier
> >> than finding out what all the possible interfaces could be called
> >> like.
> >>
> >> If you do a reasonable amount of tunneling, it is not easy to keep
> >> track of all that tun* and tap* device numbers which you have to
> >> explictly disable.
> >
> > Ahh - okay; zeroconf shouldmore extensively check the link type and only
> > bother for link/ether device which will solve this problem in the
> > general case.
>
> Hmm... from the RFC:
>
> This specification applies to all IEEE 802 Local Area Networks (LANs)
> [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11
> wireless LANs [802.11], as well as to other link-layer technologies
> that operate at data rates of at least 1 Mbps, have a round-trip
> latency of at most one second, and support ARP [RFC826]. Wherever
> this document uses the term "IEEE 802", the text applies equally to
> any of these network technologies.
>
> I presume a whitelist containing only "link/ether" includes all those?
>
> > But I'll add in the disable feature in the next upload.
>
> Thank you.
>
> Uli
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
