Russ Allbery a écrit :
> "John H. Robinson, IV" writes:
>> Russ Allbery wrote:
>
>>> My understanding is that part (although certainly not all) of the
>>> reason behind the default change is consistency with the kfreebsd
>>> architectures which are expected to be part of Debian. Debian has
>>> n
Am Dienstag 13 April 2010 20:11:34 schrieb Russ Allbery:
> Or are you saying that inetd implementations use IPV6_ADDRFORM before
> running the underlying program? (All of the ones in Debian?) If so,
> there's some missing connecting of the dots in your reply.
I guess not all of them. OTOH, not a
Hendrik Sattler writes:
> I guess not all of them. OTOH, not all of them might use AF_INET6
> sockets for IPv4 connections (the two-sockets approach is always
> possible when using IPV6_V6ONLY socket option).
> At least xinetd uses IPV6_ADDRFORM although that socket option is
> already deprecate
Russ Allbery dixit:
>>> architectures which are expected to be part of Debian. Debian has
>>> needed to adapt to BSD behavior, non-standard or not, since the project
>>> decided to include the kfreebsd architectures. That's part of porting.
>
>> What is wrong with porting kfreebsd behaivour inst
"John H. Robinson, IV" writes:
> Russ Allbery wrote:
>> My understanding is that part (although certainly not all) of the
>> reason behind the default change is consistency with the kfreebsd
>> architectures which are expected to be part of Debian. Debian has
>> needed to adapt to BSD behavior,
#include
* Salvo Tomaselli [Tue, Apr 13 2010, 12:05:08PM]:
> On Tuesday 13 April 2010 11:33:15 George Danchev wrote:
> > It is legit to change a default value (regardless what standards says, if
> > you can't change a default value it it then a hard-coded one), and it is
> > pretty lame to assume
Russ Allbery wrote:
>
> My understanding is that part (although certainly not all) of the reason
> behind the default change is consistency with the kfreebsd architectures
> which are expected to be part of Debian. Debian has needed to adapt to
> BSD behavior, non-standard or not, since the proje
Hendrik Sattler writes:
> Zitat von Russ Allbery :
>> It's not an assumption. It's reality that one has to write code
>> against, because different platforms do different things. Even if you
>> could remove the option from the Linux kernel (retroactively, changing
>> time to remove all the syst
Salvo Tomaselli writes:
> Solaris is a little bit tricky, i would be very careful talking about
> it.
Thanks for your caution and concern about what I might or might not
understand, but I have been administering Solaris systems and writing code
for Solaris for 15 years.
> After having enabled t
On Tuesday 13 April 2010 11:33:15 George Danchev wrote:
> It is legit to change a default value (regardless what standards says, if
> you can't change a default value it it then a hard-coded one), and it is
> pretty lame to assume a default value will never be changed. This assumption
> also fails
Quoting "Salvo Tomaselli" :
On Tuesday 13 April 2010 07:46:10 Russ Allbery wrote:
It's not an assumption. It's reality that one has to write code against,
because different platforms do different things. Even if you could remove
the option from the Linux kernel (retroactively, changing time t
Zitat von Russ Allbery :
Hendrik Sattler writes:
It's a trade-off with a different goal in mind. So what. Both settings
of bindv6only are if you cannot assume standard behaviour. Maybe we
should patch this option _out_ of the linux kernel to get rid of the
assumption that the default may be c
On Tuesday 13 April 2010 07:46:10 Russ Allbery wrote:
> It's not an assumption. It's reality that one has to write code against,
> because different platforms do different things. Even if you could remove
> the option from the Linux kernel (retroactively, changing time to remove
> all the systems
Hendrik Sattler writes:
> It's a trade-off with a different goal in mind. So what. Both settings
> of bindv6only are if you cannot assume standard behaviour. Maybe we
> should patch this option _out_ of the linux kernel to get rid of the
> assumption that the default may be changed.
It's not an
Am Montag 12 April 2010 23:25:16 schrieb Russ Allbery:
> Adam Borowski writes:
> > Instead of listening on a single socket, you need to change every single
> > daemon to include a select() loop. That's explicitely allowed by all
> > relevant RFCs and by POSIX, so breaking that is quite a regressi
On 12/04/10 14:34, Salvo Tomaselli wrote:
Java assumed you wanted the second bug. BSD picked the first bug. We
> have to pick one or the other. Neither choice is attractive.
No, java assumed the*POSIX default behaviour*. Why is the word*default* so
difficult to understand?
It means: "an opt
Adam Borowski writes:
> Instead of listening on a single socket, you need to change every single
> daemon to include a select() loop. That's explicitely allowed by all
> relevant RFCs and by POSIX, so breaking that is quite a regression.
Yeah, I understand why POSIX made the choice that they di
Salvo Tomaselli writes:
> On Monday 12 April 2010 20:12:36 Russ Allbery wrote:
> > Marco is not changing the point. What Marco describes has been the
> > objection that several of us have had with bindv6only=0 from the very
> > beginning. He's just more persistant about continuing to repeat the s
On Mon, Apr 12, 2010 at 11:12:36AM -0700, Russ Allbery wrote:
> Salvo Tomaselli writes:
> > On Monday 12 April 2010 18:19:08 Marco d'Itri wrote:
> >> You keep missing the point. Let me try with shorter sentences, if you
> >> still do not get it maybe I can try a puppets show.
"Standards good. BS
On Monday 12 April 2010 20:12:36 Russ Allbery wrote:
> Marco is not changing the point. What Marco describes has been the
> objection that several of us have had with bindv6only=0 from the very
> beginning. He's just more persistant about continuing to repeat the same
> point when people keep rai
m...@linux.it (Marco d'Itri) writes:
> On Apr 12, Julien Cristau wrote:
>> This has exactly nothing to do with the default value of bindv6only.
>> If anything, setting it to 1 by default makes things worse for v4-only
>> setups.
> How so?
Because of IPv6 code that assumes that you get a socket
Salvo Tomaselli writes:
> On Monday 12 April 2010 18:19:08 Marco d'Itri wrote:
>> You keep missing the point. Let me try with shorter sentences, if you
>> still do not get it maybe I can try a puppets show.
> I keep on missing the point because you keep on changing it. Try to be
> coherent pleas
Am Montag 12 April 2010 18:19:08 schrieb Marco d'Itri:
> On Apr 12, Salvo Tomaselli wrote:
> > > If a kernel without IPv6 support is used then e.g. an ACL will contain
> > > plain IPv4 addresses as expected, but when a kernel with IPv6 support
> > > is installed in your scenario then that ACL will
On 2010-04-12, Salvo Tomaselli wrote:
> On Monday 12 April 2010 18:19:08 Marco d'Itri wrote:
>> You keep missing the point. Let me try with shorter sentences, if you
>> still do not get it maybe I can try a puppets show.
> I keep on missing the point because you keep on changing it. Try to be
> c
On Monday 12 April 2010 18:19:08 Marco d'Itri wrote:
> You keep missing the point. Let me try with shorter sentences, if you
> still do not get it maybe I can try a puppets show.
I keep on missing the point because you keep on changing it. Try to be
coherent please. You have removed the bsd thing,
On Apr 12, Salvo Tomaselli wrote:
> > If a kernel without IPv6 support is used then e.g. an ACL will contain
> > plain IPv4 addresses as expected, but when a kernel with IPv6 support is
> > installed in your scenario then that ACL will not work anymore (without
> > special code) because now the I
On Apr 12, Julien Cristau wrote:
> This has exactly nothing to do with the default value of bindv6only. If
> anything, setting it to 1 by default makes things worse for v4-only
> setups.
How so?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mon, Apr 12, 2010 at 12:00:35 +0200, Bernhard R. Link wrote:
> * Hendrik Sattler [100409 20:21]:
> > Actually not. They'll just assume that binding the port first for IPv4, then
> > for IPv6 will work. Eventually, they'll be surprised that it fails elsewhere
> > (notably those that stick to th
* Hendrik Sattler [100409 20:21]:
> Actually not. They'll just assume that binding the port first for IPv4, then
> for IPv6 will work. Eventually, they'll be surprised that it fails elsewhere
> (notably those that stick to the _documented_ default value).
> As already noted, there are already syst
On Sunday 11 April 2010 23:32:01 Marco d'Itri wrote:
> After months, you *still* do not understand the issue...
...
> If a kernel without IPv6 support is used then e.g. an ACL will contain
> plain IPv4 addresses as expected, but when a kernel with IPv6 support is
> installed in your scenario then
On Apr 11, Salvo Tomaselli wrote:
> > It is not just ugly, it is also stupid because it means that existing
> > configurations will not work anymore depending on the installed kernel.
> I don't get this one...
> Why shouldn't they work with a different kernel?
After months, you *still* do not und
> It is not just ugly, it is also stupid because it means that existing
> configurations will not work anymore depending on the installed kernel.
I don't get this one...
Why shouldn't they work with a different kernel?
It's obvious that if a program starts to support IPv6 at some point, something
On Apr 11, Wouter Verhelst wrote:
> They don't *need* to do that. It can just be documented that if you use
> IPv6, you need to use the v4-in-v6-mapped syntaxis.
>
> Granted, that's a bit ugly, but it does work.
It is not just ugly, it is also stupid because it means that existing
configurations
On Sunday 11 April 2010 12:42:01 Wouter Verhelst wrote:
> They don't *need* to do that. It can just be documented that if you use
> IPv6, you need to use the v4-in-v6-mapped syntaxis.
IMHO i think that using the mapped syntax can bring some consistency rather
than having logs and configuration fi
On Fri, Apr 09, 2010 at 04:14:57PM +0200, Marco d'Itri wrote:
> On Apr 08, Hendrik Sattler wrote:
>
> > I also don't really see the issues with bindv6only=0. If you listen on
> > all interfaces, it makes is easier. If you only listen on specific
> > interfaces, it's not in the way.
> This is
On Friday 09 April 2010 18:29:40 Marco d'Itri wrote:
> They will have an opportunity to develop more portable software.
My little real life example:
I tried to compile weborf on opensolaris, and i was expecting it to compile
and work without any problem, because i was only using POSIX calls.
It
Am Freitag 09 April 2010 18:29:40 schrieb Marco d'Itri:
> They will have an opportunity to develop more portable software.
Actually not. They'll just assume that binding the port first for IPv4, then
for IPv6 will work. Eventually, they'll be surprised that it fails elsewhere
(notably those that
On Fri, 9 Apr 2010 18:29:40 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Apr 09, Salvo Tomaselli wrote:
>> And some people might want to develop software.
>They will have an opportunity to develop more portable software.
Reality Check, Please. They will happily switch to CentOS or Windows
inste
On Apr 09, Salvo Tomaselli wrote:
> > I will be happy to re-evaluate this at the time of the freeze if it will
> > be determined that setting bindv6only=1 by default will have a
> > noticeable impact on the general system usability.
> Have you considered that some people might want to use softwar
On Fri, Apr 9, 2010 at 16:14:57 +0200, Marco d'Itri wrote:
> I am not aware of any Debian package which still has not been fixed.
>
xdmcp is still broken in at least gdm and xdm (I've got patches for
both, but they're not in sid).
Cheers,
Julien
signature.asc
Description: Digital signature
On Friday 09 April 2010 16:14:57 Marco d'Itri wrote:
> I will be happy to re-evaluate this at the time of the freeze if it will
> be determined that setting bindv6only=1 by default will have a
> noticeable impact on the general system usability.
Have you considered that some people might want to us
On Apr 08, Hendrik Sattler wrote:
> I also don't really see the issues with bindv6only=0. If you listen on
> all interfaces, it makes is easier. If you only listen on specific
> interfaces, it's not in the way.
This is not true, the big problem with bindv6only=0 is that you will get
IPv4 conn
> Then the Debian FreeBSD maintainers should fix this in their kernel.
I agree, I've tried to convince Marco D'Itri (netbase maintainer) that the bug
is their, but without any luck.
Bye
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "uns
On Thu, Apr 08, 2010 at 01:00:52PM +0200, Samuel Thibault wrote:
> Hendrik Sattler, le Thu 08 Apr 2010 12:38:36 +0200, a écrit :
> > Zitat von Salvo Tomaselli :
> > >>I also don't really see the issues with bindv6only=0. If you listen on
> > >>all interfaces, it makes is easier. If you only listen
On Thursday 08 April 2010 12:38:36 Hendrik Sattler wrote:
> We are discussing this for linux, not freebsd, don't we?
freebsd is the reason because this option has been changed in debian.
But again, if they must conform to one standard, i think they should conform
to opengroup rather than changing
Hendrik Sattler, le Thu 08 Apr 2010 12:38:36 +0200, a écrit :
> Zitat von Salvo Tomaselli :
> >>I also don't really see the issues with bindv6only=0. If you listen on
> >>all interfaces, it makes is easier. If you only listen on specific
> >>interfaces, it's not in the way.
> >The problem is that f
Zitat von Salvo Tomaselli :
OTOH, it defaults to 1 in Windows Vista/7, probably as compatibility
to XP which didn't have a dual-IP stack.
I don't think we should care about what windows does, there can't be
compatibility anyway.
I also don't really see the issues with bindv6only=0. If you list
Zitat von Salvo Tomaselli :
On Thursday 08 April 2010 11:05:30 Stephane Bortzmeyer wrote:
On Wed, Apr 07, 2010 at 08:20:37AM +0200,
Vincent Danjean wrote
a message of 63 lines which said:
> I've no strong opinion about the default value for
> net.ipv6.bindv6only. However, I think that any
> OTOH, it defaults to 1 in Windows Vista/7, probably as compatibility
> to XP which didn't have a dual-IP stack.
I don't think we should care about what windows does, there can't be
compatibility anyway.
> I also don't really see the issues with bindv6only=0. If you listen on
> all interfaces,
On Thursday 08 April 2010 11:05:30 Stephane Bortzmeyer wrote:
> On Wed, Apr 07, 2010 at 08:20:37AM +0200,
> Vincent Danjean wrote
>
> a message of 63 lines which said:
> > I've no strong opinion about the default value for
> > net.ipv6.bindv6only. However, I think that any application that
> >
On Wed, Apr 07, 2010 at 08:20:37AM +0200,
Vincent Danjean wrote
a message of 63 lines which said:
> I've no strong opinion about the default value for
> net.ipv6.bindv6only. However, I think that any application that
> breaks if the default value is 0 or 1 is broken and a bug must be
> filled
Hi,
On Wed, Apr 7, 2010 at 10:14 AM, Bernhard R. Link wrote:
> I personally would prefer ipv6 to still be a module so it can be
> blacklisted or some other way to disable it, but having this option on
> by default at least avoids many annoiances in ipv4 world.
I've always disabled IPv6 on all ho
Stanislav Maslovski writes:
>> I think that an application which depends on net.ipv6.bindv6only=1 is
>> broken (at least as Linux application).
>
> I am not sure that there are such applications. Can you give us an
> example?
Sorry, I don't know whether such applications really exist.
I just exp
On Wed, Apr 07, 2010 at 05:04:58PM +0900, Kazuo Oishi wrote:
> Vincent Danjean writes:
> >>> Anyone, could you teach me why net.ipv6.bindv6only need to be set
> >>> to 1 globally, and why other good programs need to be changed?
> >>> I think it should revert.
> >
> > I've no strong opinion about t
On Wed, Apr 07, 2010 at 12:22:26AM -0700, Ludovico Cavedon wrote:
> On Tue, Apr 6, 2010 at 11:20 PM, Vincent Danjean wrote:
> > ...and squeeze should be released with the default value that minimizes
> > the number of broken behavior
That is, whatever is consistent with the standards, ie, bindb6o
Vincent Danjean writes:
>>> Anyone, could you teach me why net.ipv6.bindv6only need to be set
>>> to 1 globally, and why other good programs need to be changed?
>>> I think it should revert.
>
> I've no strong opinion about the default value for net.ipv6.bindv6only.
> However, I think that any app
On Tue, Apr 6, 2010 at 11:20 PM, Vincent Danjean wrote:
> ...and squeeze should be released with the default value that minimizes
> the number of broken behavior (not the number of bugs because whatever
> the default value is, if the application depends on a particular default
> value, the bug exi
* Vincent Danjean [100407 08:21]:
> ...and squeeze should be released with the default value that minimizes
> the number of broken behavior (not the number of bugs because whatever
> the default value is, if the application depends on a particular default
> value, the bug exists)
I guess the ques
On 06/04/2010 15:47, Sylvestre Ledru wrote:
> Le mardi 06 avril 2010 à 21:04 +0900, Kazuo Oishi a écrit :
>> I have send this message to BTS and rejected.
>>
>> m...@linux.it (Marco d'Itri) writes:
>>>> Default value of net.ipv6.bindv6only should revert to 0.
Le mardi 06 avril 2010 à 21:04 +0900, Kazuo Oishi a écrit :
> I have send this message to BTS and rejected.
>
> m...@linux.it (Marco d'Itri) writes:
> >> Default value of net.ipv6.bindv6only should revert to 0.
> > This has already been discussed on debian-d
On Tue, Apr 06, 2010 at 09:04:18PM +0900,
Kazuo Oishi wrote
a message of 48 lines which said:
> Anyone, could you teach me why net.ipv6.bindv6only need to be set
> to 1 globally, and why other good programs need to be changed?
> I think it should revert.
I do not claim to have a final opinion
I have send this message to BTS and rejected.
m...@linux.it (Marco d'Itri) writes:
>> Default value of net.ipv6.bindv6only should revert to 0.
> This has already been discussed on debian-devel and I do not see any new
> arguments here.
I have already read debian-devel archive, b
62 matches
Mail list logo
