You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jaap Vermeulen <ja...@skyscape.com> on 2004/11/08 23:38:13 UTC

snv URL does not use FQDN

Hi,

I just want to know whether it is reasonable to file an issue against the
svn: protocol urls with respect to fully-qualified domain names.  If a
machine "A" is in domain "B.C", and you refer in the URL to the machine as
"svn://A/...", you should also be able to refer to it as "svn://A.B.C/..."
without SVN getting confused and ornery and refusing to update or do other
operations on a working copy because the URLs don't match.

Thanks,

	-Jaap-

PS: I quickly checked the issue DB and didn't see related issues.  Let me
know if there is already an outstanding issue for this.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: snv URL does not use FQDN

Posted by Keven Ring <ke...@mitre.org>.
JM Ibanez wrote:

>On Wed, 10 Nov 2004 12:35:26 -0500, Dale Worley <dw...@pingtel.com> wrote:
>  
>
>>It is a good idea, but I'm not sure there is a workable method to implement
>>it.  As far as I know, there isn't any standardized way to translate "A"
>>into "A.B.C", that is, to get the fully-qualified version of an abbreviated
>>machine name.
>>    
>>
>
>Isn't it possible for the svn client to store the IP instead? (i.e. if
>A maps to IP w.x.y.z, and A.B.C maps to IP w.x.y.z, then A ~= A.B.C?)
>
>  
>
Probably, assuming that A.B.C isn't obtaining an IP address via DHCP, or 
some other similar dynaminc mechanism.

>Also, isn't it possible to check that the domain of a particular
>machine while resolving the address of A (i.e., if machine has domain
>B.C., then all calls for A ~= A.B.C)?
>
>  
>
I don't believe that this is a requirement at all.  IIRC, (on Unix), 
there is an option called "search" that can be added to your 
/etc/resolv.conf file.  It appears that Windows has a similar 
capability, but I haven't tried it rigorously.

The purpose of this option is to define the domain search criteria when 
provided with just an "A", and "A" will not resolve.

However, that being said, one could look up the IP address for "A", and 
then do a reverse DNS lookup to obtain "A.B.C".

If that is done, then
1) You don't have to worry about dynamically changing IP addresses on 
the server side
2) You don't have to "guess" which domain "A" resolved to.

This also allows a machine to have aliases, although that could 
significantly complicate things, eg, for virtual hosts on a web server, 
etc...

Sounds like a lot of sticky edge cases...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: snv URL does not use FQDN

Posted by Dominic Anello <da...@danky.com>.
On 2004-11-11 02:07:50 +0800, JM Ibanez wrote:
> On Wed, 10 Nov 2004 12:35:26 -0500, Dale Worley <dw...@pingtel.com> wrote:
> > It is a good idea, but I'm not sure there is a workable method to implement
> > it.  As far as I know, there isn't any standardized way to translate "A"
> > into "A.B.C", that is, to get the fully-qualified version of an abbreviated
> > machine name.
> 
> Isn't it possible for the svn client to store the IP instead? (i.e. if
> A maps to IP w.x.y.z, and A.B.C maps to IP w.x.y.z, then A ~= A.B.C?)
----8<----

Unfortunately, that means you would have to do a --relocate every time
you changed the IP address of the machine.

Rather, if the host referred to on the command line did not match the
one in the WC, I would resolve both host names at run-time.  If A and
A.B.C both resolved to the same IP address, you could proceed as if the
user issued the command with the WC host.

So if you have a WC based on http://A/foo/bar and the user does:
$ svn switch http:/A.B.C/foo/wux

Then svn could look and see A and A.B.C both resolve to 1.2.3.4 and then
behave as if the user issued:
$ svn switch http://A/foo/wux

That would solve the host versus FQDN issue without having to worry
about changing IP addresses.

-Dominic

Re: snv URL does not use FQDN

Posted by JM Ibanez <jm...@gmail.com>.
On Wed, 10 Nov 2004 12:35:26 -0500, Dale Worley <dw...@pingtel.com> wrote:
> It is a good idea, but I'm not sure there is a workable method to implement
> it.  As far as I know, there isn't any standardized way to translate "A"
> into "A.B.C", that is, to get the fully-qualified version of an abbreviated
> machine name.

Isn't it possible for the svn client to store the IP instead? (i.e. if
A maps to IP w.x.y.z, and A.B.C maps to IP w.x.y.z, then A ~= A.B.C?)

Also, isn't it possible to check that the domain of a particular
machine while resolving the address of A (i.e., if machine has domain
B.C., then all calls for A ~= A.B.C)?

-- 
JM Ibanez
   - A million monkeys can't go wrong...
http://www.livejournal.com/~jmibanez/
http://www.mycgiserver.com/~butiki/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: snv URL does not use FQDN

Posted by Dale Worley <dw...@pingtel.com>.
It is more complicated than it appears.  First, remember that "resolve"
means the process of translating a host name (as specified by the user) to
an IP address.  Now it turns out that the common Unix method for resolving
involves trying not only the specified name, but also that name with the
domains listed in /etc/resolv.conf appended.  But the routine that does this
does *not* return the "full" name back to the caller -- the caller gets the
IP address and nothing more.

Ping does something additional -- once it gets the IP address, it then "does
a reverse lookup" to translate the IP address back into a domain name.  But
this translation is done via an entirely different database, the "PTR
records" in DNS.  And if the PTR records aren't set up correctly, the
reverse lookup will fail.

Perversely, my company provides an example of this, and you can see the
effect on ping, it does not use the host name as you would expect:

$ ping www.pingtel.com
PING www.pingtel.com (216.142.118.36) 56(84) bytes of data.
64 bytes from 216.142.118.36: icmp_seq=1 ttl=240 time=52.3 ms
64 bytes from 216.142.118.36: icmp_seq=2 ttl=240 time=49.4 ms
64 bytes from 216.142.118.36: icmp_seq=3 ttl=240 time=46.5 ms
64 bytes from 216.142.118.36: icmp_seq=4 ttl=240 time=50.6 ms
64 bytes from 216.142.118.36: icmp_seq=5 ttl=240 time=53.7 ms
64 bytes from 216.142.118.36: icmp_seq=6 ttl=240 time=44.6 ms

I suppose you could demand that all Subversion clients on your machine were
to go through this process (or something similar), but it would have severe
upward-compatibility problems, I'd think -- If a working copy already exists
that was checked out with an abbreviated or alternative host name, a client
that canonicalized all host names would be unable to use it.

Dale

-----Original Message-----
From: Jaap Vermeulen [mailto:jaap@skyscape.com]

I've been looking at the responses to this message on the mailing list.

What I'm asking for is much simpler than what is discussed.  And it follows
standard (and predictable) practices.

When you provide a name, it will be resolved to a FQDN.  In other words, if
you type "blarvitz", the DNS libraries will automatically add the domain
based on a list of primary/subdomains that your machine is in.  (This is
true both for UNIX or Windows.) For example, try a ping to your SVN server
without the primary domain and examine its output; it will have the FQDN.
This is done by routines like "gethostbyname()" or "getaddrinfo()".

The only thing I'm asking for is that the host part of the svn: URL is
resolved to a FQDN.  This can be done either by resolving both the given and
stored host name and then comparing them (probably best), or by storing the
resolved host name and only resolving the given host name and then comparing
it.

This avoid issues where if you provide a partial host name, it will not
match with the stored (partial) host name, even though they will both be
resolved to the same FQDN.  If an IP address is used, you simply try a
reverse lookup.  If either the lookup or the reverse lookup fails, you keep
the original string (of course).  In the end the host names either match or
don't match, and the result is no worse than what we have now.  :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: snv URL does not use FQDN

Posted by Jaap Vermeulen <ja...@skyscape.com>.
I've been looking at the responses to this message on the mailing list.

What I'm asking for is much simpler than what is discussed.  And it follows
standard (and predictable) practices.

When you provide a name, it will be resolved to a FQDN.  In other words, if
you type "blarvitz", the DNS libraries will automatically add the domain
based on a list of primary/subdomains that your machine is in.  (This is
true both for UNIX or Windows.) For example, try a ping to your SVN server
without the primary domain and examine its output; it will have the FQDN.
This is done by routines like "gethostbyname()" or "getaddrinfo()".

The only thing I'm asking for is that the host part of the svn: URL is
resolved to a FQDN.  This can be done either by resolving both the given and
stored host name and then comparing them (probably best), or by storing the
resolved host name and only resolving the given host name and then comparing
it.

This avoid issues where if you provide a partial host name, it will not
match with the stored (partial) host name, even though they will both be
resolved to the same FQDN.  If an IP address is used, you simply try a
reverse lookup.  If either the lookup or the reverse lookup fails, you keep
the original string (of course).  In the end the host names either match or
don't match, and the result is no worse than what we have now.  :-)

Thanks,

	-Jaap-

> -----Original Message-----
> From: Jaap Vermeulen [mailto:jaap@skyscape.com]
> Sent: Monday, November 08, 2004 6:38 PM
> To: users@subversion.tigris.org
> Subject: snv URL does not use FQDN
>
>
>
> Hi,
>
> I just want to know whether it is reasonable to file an issue
> against the svn: protocol urls with respect to fully-qualified
> domain names.  If a machine "A" is in domain "B.C", and you refer
> in the URL to the machine as "svn://A/...", you should also be
> able to refer to it as "svn://A.B.C/..." without SVN getting
> confused and ornery and refusing to update or do other operations
> on a working copy because the URLs don't match.
>
> Thanks,
>
> 	-Jaap-
>
> PS: I quickly checked the issue DB and didn't see related issues.
>  Let me know if there is already an outstanding issue for this.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: snv URL does not use FQDN

Posted by Dale Worley <dw...@pingtel.com>.
It is a good idea, but I'm not sure there is a workable method to implement
it.  As far as I know, there isn't any standardized way to translate "A"
into "A.B.C", that is, to get the fully-qualified version of an abbreviated
machine name.

Dale

-----Original Message-----
From: Jaap Vermeulen [mailto:jaap@skyscape.com]

If a
machine "A" is in domain "B.C", and you refer in the URL to the machine as
"svn://A/...", you should also be able to refer to it as "svn://A.B.C/..."
without SVN getting confused and ornery and refusing to update or do other
operations on a working copy because the URLs don't match.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org