[Opensim-dev] external host name

Hurliman, John john.hurliman at intel.com
Sat Dec 13 08:11:56 UTC 2008 

Virtual hosting is not a client concept. The viewer uses libcurl in HTTP 1.1 mode which sends a Host header in all CAPS communication. If some of the CAPS services use SSL certificates, web proxies, or name-based virtual hosting in the CAPS server itself (a CAPS endpoint might be an Apache server) you can have one IP address serving up different domain names. hostnameA and hostnameB resolving to IPaddressA is a valid and common setup. If the server internally resolves both to IPaddressA and your SSL certificate is for hostnameA, or your service is actually tied to hostnameB but the reverse DNS resolves to hostnameA, that's not going to work.

If you enter everything in your config files as IP addresses no DNS resolution would ever take place. I don't understand how that figures in to the discussion.

Apologies if I'm beating a dead horse, looking at the commit logs it seems this has already been resolved in SVN.

John

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- 
> bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Friday, December 12, 2008 2:30 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] external host name
> 
> The viewer has no concept of virtual hosting. Hostnames in caps and
> other urls are for configuration convenience only.
> 
> In those places where hosts are compared, hostnameA == IPaddressA
> should be true. resolving all names in those comparisons (like check
> for cache hits) solves that. We can't assume everyone has DNS set up.
> Tinygrids and standalones won't, most likely.
> 
> Melanie
> 
> Hurliman, John wrote:
>> Resolving all hostnames to IP addresses would break virtual hosting,
> a very common practice. I don't understand your earlier argument: we
> can't assume DNS presence*, so we should use DNS to resolve all
> hostnames? Can you clarify that?
>>  *If you're building a virtual world in an environment where there is
>> no DNS service, why would you put a hostname in your config file?
>> 
>> John
>> 
>>> -----Original Message-----
>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>> Sent: Thursday, December 11, 2008 9:31 PM
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] external host name
>>> 
>>> Then we should resolve all hostname fields int he LL stack, and feed
>>> the client IP addresses. That should still allow us flexible handling.
>>> Most importantly, we should not string-compare hostss. Not if (host a
>>> == host b) but if (resolve(host a) == resolve(host b))
>>> 
>>> Melanie
>>> 
>>> 
>>> Diva Canto wrote:
>>>> I agree. The problem is that the client doesn't understand that, and
>>>> this causes problems with caps urls.
>>>> 
>>>> Melanie wrote:
>>>>> A host name can also be an IP address. IP addresses and hostnames
>>>>> are interchangable and we can't assume DNS presence. So, the
>>>>> field should accept a name or IP, and resolve names, like almost
>>>>> everything else on the internet does.
>>>>> 
>>>>> Melanie
>>>>> 
>>>>> 
>>>>> Cristina Videira Lopes wrote:
>>>>> 
>>>>>> The thing is that this can potentially create a RegionInfo data
>>>>>> structure with
>>>>>>            nRegionInfo.ExternalHostName = regionData.IPADDR;
>>>>>>  This is inconsistent with certain queries on the Grid server, like
>>>>>> "give me all my neighbors" which may send host names.
>>>>>> 
>>>>>> So, back to the point: someone needs to decide what is it that
>>>>>> RegionInfo.ExternalHostName  is supposed to hold.
>>>>>> 
>>>>>> Teravus Ovares wrote:
>>>>>> 
>>>>>>> RegionUpData is my fault, and spawned from compatibility issues
>>>>>>> with .NET remoting and Mono remoting with complex types.  It is
>>>>>>> only used to notify a neighbor region that 'this region is up'
>>>>>>> 
>>>>>>> Best Regards
>>>>>>> 
>>>>>>> Teravus
>>>>>>> 
>>>>>>> On 12/11/08, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> Things are very messy right now. You can search for "sim_ip", for
>>>>>>>> example, which is used in chatting with the grid server, and
>>>>>>>> where it is being converted to an IP address in about half of the
>>>>>>>> cases.
>>>>>>>> 
>>>>>>>> To compensate, and before I noticed this inconsistency, Homer
>>>>>>>> introduced another field called "sim_host", so not to mess
>>>>>>>> with what was already there, that is supposed to carry the
>>>>>>>> external host name, but this only works up to the point in
>>>>>>>> which RegionInfo data structures are created. At that point,
>>>>>>>> we need to decide what to place in m_externalHostName, sim_ip
>>>>>>>> or sim_host. Which means changes in OGS1.
>>>>>>>> 
>>>>>>>> I also noticed that there is yet another data structure called
>>>>>>>> RegionUpData that uses IP addresses.
>>>>>>>> 
>>>>>>>> So, messy. Someone should decide what this field is supposed
>>>>>>>> to be, and make it a rule.
>>>>>>>> 
>>>>>>>> Charles Krinke wrote:
>>>>>>>> 
>>>>>>>> Dear Diva:
>>>>>>>> 
>>>>>>>> You have a very good point and I would support harmonizing to one
>>>>>>>> notion even at the expense of breaking some things for a while.
>>>>>>>> 
>>>>>>>> In fact, if someone can identify what some of those things
>>>>>>>> are, or come up with a couple of search strings or grep
>>>>>>>> expressions, I would like to look at the anomalies myself.
>>>>>>>> 
>>>>>>>> +1 on external_host_name
>>>>>>>> 
>>>>>>>> Charles
>>>>>>>> 
>>>>>>>> ________________________________
>>>>>>>> 
>>>>>>>> 
>>>>>>>> From: Cristina Videira Lopes <lopes at ics.uci.edu>
>>>>>>>> To: opensim-dev at lists.berlios.de
>>>>>>>> Sent: Thursday, December 11, 2008 2:42:05 PM
>>>>>>>> Subject: [Opensim-dev] external host name
>>>>>>>> 
>>>>>>>> It turns out that a lot of problems with CAPs have to do with
>>>>>>>> inconsistencies surrounding the URL of the seed cap.
>>>>>>>> Specifically, in some cases we're producing URLs with hostnames,
>>>>>>>> other times we're producing URLs with IP addresses, for example:
>>>>>>>> 
>>>>>>>> http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b- b136-
>>>>>>>> cd a2cdde0000/ vs. MailScanner has detected a possible fraud
>>>>>>>> attempt from "128.200.71.43:9000" claiming to be MailScanner
>>>>>>>> warning: numerical links are often malicious:
>>>>>>>> http://128.200.71.43:9000/CAPS/4cfc94fa-09be-409b-b136-
>>>>>>>> cda2cdde000 0/
>>>>>>>> 
>>>>>>>> The client is not smart enough to test if this is the same host,
>>>>>>>> it assumes it isn't, so it decides someone's trying to game it.
>>>>>>>> 
>>>>>>>> The inconsistencies are all over the code in OpenSim, and they
>>>>>>>> pertain to the use of ExternalHostName in several data s!
>>>>>>>> tructures. In some cases, an explicit conversion to IP addresses
>>>>>>>> is made.
>>>>>>>> 
>>>>>>>> We should converge to one single thing. And I believe that thing
>>>>>>>> should be whatever it is given in external_host_name config. Is
>>>>>>>> this right? However, I am a bit afraid this is going to break 17
>>>>>>>> different things...
>>>>>>>> 
>>>>>>>> Crista
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Opensim-dev mailing list
>>>>>>>> Opensim-dev at lists.berlios.de
>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>>> ________________________________
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Opensim-dev
>>>>>>> 
>>>>>>> 
>>>>>>>> mailing
>>>>>>>> list
>>>>>>>> 
>>>>>>>> 
>>>>>>> Opensim-dev at lists.berlios.de
>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>> 
>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Opensim-dev mailing list
>>>>>>>> Opensim-dev at lists.berlios.de
>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Opensim-dev mailing list
>>>>>>> Opensim-dev at lists.berlios.de
>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------- -
>>>>>> - - - ----
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>> 
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------ -
>>>> - - - --
>>>> 
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

More information about the Opensim-dev mailing list