> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: dinsdag 2 februari 2010 13:03
> To: commits_at_subversion.apache.org
> Subject: svn commit: r905595 -
> /subversion/trunk/subversion/svnserve/main.c
>
> Author: stsp
> Date: Tue Feb 2 12:02:40 2010
> New Revision: 905595
>
> URL: http://svn.apache.org/viewvc?rev=905595&view=rev
> Log:
> Make svnserve in deamon mode prefer IPv4 addresses when resolving
> the listen hostname, and add a switch to make it prefer IPv6 instead.
>
> This avoids the typical "I just started svnserve and it refuses all
> connections" problem, which is caused by svnserve defaulting to an
> IPv6 wildcard socket on a server which is on an IPv4-only network.
>
> Reported by: nucc1
> (via IRC in #svn, but it's been reported countless times before)
>
> * subversion/svnserve/main.c
> (svnserve__options): Add a --prefer-ipv6 option (short form -6).
> In the help text, document that listening on IPv4 and IPv6 addresses
> at the same time is not supported in daemon mode, and suggest
> workarounds.
> (main): If APR was compiled with IPv6 support, prefer IPv4 addresses
> by default when resolving the listen hostname, unless the -6 option
> was passed. If APR was not compiled with IPv6 support, the -6 option
> is silently ignored.
>
> Modified:
> subversion/trunk/subversion/svnserve/main.c
>
> Modified: subversion/trunk/subversion/svnserve/main.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/svnserve/main.
> c?rev=905595&r1=905594&r2=905595&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/svnserve/main.c (original)
> +++ subversion/trunk/subversion/svnserve/main.c Tue Feb 2 12:02:40 2010
> @@ -179,6 +179,14 @@
> " "
> "[mode: daemon, listen-once]")},
> #endif
> + {"prefer-ipv6", '6', 0,
> + N_("prefer IPv6 when resolving the listen hostname\n"
> + " "
> + "[IPv4 is preferred by default. Using IPv4 and IPv6\n"
> + " "
> + "at the same time is not supported in daemon mode.\n"
> + " "
> + "Use inetd mode or tunnel mode if you need this.]")},
> #ifdef CONNECTION_HAVE_THREAD_OPTION
> /* ### Making the assumption here that WIN32 never has fork and so
> * ### this option never exists when --service exists. */
> @@ -380,6 +388,8 @@
> apr_uint16_t port = SVN_RA_SVN_PORT;
> const char *host = NULL;
> int family = APR_INET;
> + u_int32_t sockaddr_info_flags = 0;
> + svn_boolean_t prefer_v6 = FALSE;
> int mode_opt_count = 0;
> const char *config_filename = NULL;
> const char *pid_filename = NULL;
> @@ -429,6 +439,10 @@
> usage(argv[0], pool);
> switch (opt)
> {
> + case '6':
> + prefer_v6 = TRUE;
> + break;
> +
> case 'h':
> help(pool);
> break;
> @@ -677,10 +691,24 @@
> {
> apr_socket_close(sock);
> family = APR_UNSPEC;
> +
> + if (prefer_v6)
> + {
> + if (host == NULL)
> + host = "::";
> + sockaddr_info_flags = APR_IPV6_ADDR_OK;
> + }
> + else
> + {
> + if (host == NULL)
> + host = "0.0.0.0";
> + sockaddr_info_flags = APR_IPV4_ADDR_OK;
> + }
> }
> #endif
>
> - status = apr_sockaddr_info_get(&sa, host, family, port, 0, pool);
> + status = apr_sockaddr_info_get(&sa, host, family, port,
> + sockaddr_info_flags, pool);
> if (status)
> {
> err = svn_error_wrap_apr(status, _("Can't get address info"));
>
$ 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)
After this change it will listen on IPv4 (or break if you don't have IPv4).
These decisions don't belong in our applications, but on the operating or otherwise in a portability library like APR.
Just because more and more users are enabling their systems for IPv6 (as indicated by users seeing this issue) we should not roll back to a IPv4 world.
-0 on this change.
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).
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...
So we fix a 'bug', by introducing a new bug for the future...
No thanks,
Bert
Received on 2010-02-02 13:36:25 CET