[Opensim-dev] external host name
Chris Hart
Chris at codetorque.co.uk
Fri Dec 12 14:43:10 UTC 2008
It's a one-way pull on startup with no writing back if you use web
regions - I did have a dig around to see if I could figure out a way to
enable that somehow, but it seemed like a lot of effort for not a lot of
gain. What I would like to see is a fall-back - if web regions load
fails, go back and try the filesystem. It's on my todo list - depends on
whether others think this would be useful as to how soon I get round to
it.
Chris
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Stefan
Andersson
Sent: 12 December 2008 14:32
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] external host name
Afaik the only region.xml data that depends on writing back is the map
image asset id and last refresh. If they are not updated it will mean a
re-creation on each region restart, wich is not that fatal, in some
cases even desirable, I guess.
Of course, them being stored in there I consider ugly hack. Should be
part of the region data table, really.
Best regards,
Stefan Andersson
Tribal Media AB
> Date: Fri, 12 Dec 2008 14:26:50 +0000
> From: jjustincc at googlemail.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] external host name
>
> Kyle "G" wrote:
> > Chris Hart has setup ReactionGrid to have region.xml files pulled
form a
> > web source already. She has greatly simplified our life by doing
this
> > and building some asp.net web admin tools for managing servers.
>
> That's rather interesting - I thought pulling region information from
web was currently broken (because some other code
> started trying to write information back to the 'file'). Is this no
longer the case?
>
> >
> > Kyle G
> >
> > www.reactiongrid.com <http://www.reactiongrid.com>
> >
> >
> >
> > *From:* opensim-dev-bounces at lists.berlios.de
> > [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Stefan
> > Andersson
> > *Sent:* Friday, December 12, 2008 5:20 AM
> > *To:* opensim-dev at lists.berlios.de
> > *Subject:* Re: [Opensim-dev] external host name
> >
> >
> >
> > An often overlooked feature in OpenSim is to be able to pull
Region.xml
> > from a web source, and I believe the work needed to pull opensim.ini
> > from a web source is minimal (maybe just some nini config magic?)
> >
> > In a setting where instances move around, this is probably features
> > worth examining.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> > Join the 3d web revolution : http://tribalnet.se/
> >
> >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> >
> > Date: Thu, 11 Dec 2008 18:28:19 -0800
> > From: dahliatrimble at gmail.com
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] external host name
> >
> > I think it may be beneficial to allow some kind of tag to be used in
the
> > region xml config file which may get the hostname or IP address from
> > another source, perhaps an environment variable? I suggest this as I
> > often move regions and their configs around to different hosts and
it's
> > a pain to keep changing the host name in the files. I guess a macro
> > processor run on the file at region startup would accomplish the
same
> > thing, but it would be a convenience if opensim.exe did it.
> >
> > On Thu, Dec 11, 2008 at 6:11 PM, Teravus Ovares <teravus at gmail.com
> > <mailto:teravus at gmail.com>> wrote:
> >
> > I agree. It is inconstant. On purpose. :). As I said, remoting
> > issues caused regions in Linux and Windows to be unable to tell each
> > other that they were online using the RegionInfo object.
> >
> >
> > Best Regards
> >
> > Teravus
> >
> > On 12/11/08, Cristina Videira Lopes <lopes at ics.uci.edu
> > <mailto:lopes at ics.uci.edu>> 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
> > <mailto: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
<mailto:lopes at ics.uci.edu>>
> > To:
> >> opensim-dev at lists.berlios.de <mailto: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-cda2cdde
0000/
> > vs.
> > MailScanner
> >> has detected a possible fraud attempt from "128.200.71.43:9000
> > <http://128.200.71.43:9000/>"
> > claiming to
> >> be MailScanner warning: numerical links are often malicious:
> > MailScanner
> >> warning: numerical links are often malicious:
> >>
http://128.200.71.43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
> >
> > 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 <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > ________________________________
> >
> >> _______________________________________________
> > Opensim-dev
> >> mailing
> > list
> >
> >> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> _______________________________________________
> > Opensim-dev
> >> mailing
> >> list
> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >> _______________________________________________
> > Opensim-dev
> >> mailing
> >> list
> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >>
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >>
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - http://www.avg.com
> > Version: 8.0.176 / Virus Database: 270.9.16/1842 - Release Date:
> > 12/11/2008 8:36 AM
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.16/1841 - Release Date:
11/12/2008 20:58
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081212/e72960d5/attachment-0001.html>
More information about the Opensim-dev
mailing list