On Tue, Feb 02, 2010 at 01:35:48PM +0100, Bert Huijben wrote:
>
>
> $ svnserve -r /path listened on IPv6 or on both IPv6 and IPv4 if you
> compiled APR with IPV6 before this change. (IPv4 if you don't)
As discussed on IRC, svnserve in daemon mode only supports a single
address family at a time. It does not support both v4 and v6 at the
same time (see #2382).
Unless your OS supports v4-mapped addresses (not all do, or enable them
by default), the default behaviour of svnserve is to listen on a single
v6 wildcard socket. Which makes it not work out of the box for people
who type an IPv4 IP address into their svn URL, or a hostname which
does not resolve to an IPv6 address, or if they don't have IPv6
configured on their network (i.e. the wildcard socket will never
receive packets unless you are on the same ethernet segment as the
server and you type a link-local address -- and nobody does that!).
Most users who run into this problem don't know how to deal with it,
because they aren't aware of the IPv4/IPv6 issues. They may not even
know what IPv6 is, let alone how to configure DNS for their local network.
The case we need to fix is:
u...@server$ svnserve -d -r /repos # only listens on :: (v6 wildcard)
# but the user doesn't realise this
u...@client$ svn co svn://192.168.1.4/trunk # user gets "connection
# refused" error
The user is using svnserve on a LAN, has a small and cheap v4-only
wireless router box which provides an internet uplink and does DHCP
and DNS for the user (and no, it does not provide local hostnames
in the default configuration, it only resolves DNS hostnames on the
internet). That's quite a common case today, isn't it?
How is the user supposed to deal with this without finding help and
being told to use --listen-address 192.168.1.4?
> After this change it will listen on IPv4 (or break if you don't have IPv4).
If you don't have v4, today, you are advanced enough to check for
a -6 switch. Even if you do have v6 today, you will most likely
still have v4 addresses on your network, and you probably don't
care which protocol svnserve is using (if you do, again, you are
special and advanced, look for the -6 switch).
> These decisions don't belong in our applications, but on the operating
> or otherwise in a portability library like APR.
> -0 on this change.
Are you still -0?
> I would prefer a '-4' to explicitly ask for the new behavior of
> forcing IPv4 on users (maybe also -6 for consistency) and leaving the
> default via ordering to the operating system and DNS resolvers. (Just
> as tools like ping, traceroute, etc. do).
There are ping and ping6, and traceroute and traceroute6 on my system.
One set of tools for v4, the other for v6. It may be different on Windows.
> We shouldn't try to help users back in the IPv4 only world... We will
> have to revert this 'default change' within the next 2-3 years
> anyway...
svnserve now works out of the box for v4-only and for dual v4/v6 network.
These are the common cases. We are getting complaints (or at least,
confused users asking for help) because they don't work out of the box.
Asking and answering questions costs both us and the users time.
For v6-only networks, you need to pass -6. I'll happily sit and wait
patiently until the day the first clueless user pops into the #svn
channel because of a "connection refused" error from svnserve because
the network is v6-only and the user didn't specify -6. First, I will
check to see if my hair is already grey. Then, we can wait a few more
years, and then it'll probably be worth switching the default back.
Stefan
