Found out that MaxPrims are only honored in regions.ini if the Module PrimLimitsModule is activated in permissions in the OpenSim.ini.
Right now I am still trying to figure out how to force the software to kick or ban someone from a region. That seems to be a pretty big hole but I dont know if there is something in the configuration I am missing or what. I know some of the god tools are not working, wondering if this is related at all, but probably not. On Mon, Oct 8, 2012 at 9:17 PM, Justin Clark-Casey <[email protected] > wrote: > Prim limits should be respected when set in Regions.ini. If not, then > that's a reportable bug. > > You can also set prim limits per parcel in the viewer which is a different > mechanism. > > > On 08/10/12 13:15, James Stallings II wrote: > >> To summarize: >> >> - No SQL server needs to be accessible over the network except in the >> event of a 'special case' (e.g., an >> externally-hosted web front end). >> - No other ports but 8002 in a standard or default ROBUST configuration >> need be accessible to the viewer-based end user. >> - The keys were removed by consensus because they provided *no* security. >> >> Joshua: >> Use the similar settings in the OpenSim.ini file, the one's in the >> Region.ini file should be removed. >> >> >> Cheers >> James/Hiro >> http://SimHost.com >> >> >> On Mon, Oct 8, 2012 at 3:01 AM, Joshua Rubeck <[email protected]<mailto: >> [email protected]>**> wrote: >> >> Thanks for the info guys, that was very helpful. One of the other >> things we were having issues with is the MaxPrims >> setting in the region INI files. Clearly this setting is available, >> however it does not appear to work. I am sure on >> my grids this is not an issue after all OpenSimulator is usually used >> to eliminate many of the restrictions SL has. >> However for us we are trying to follow the same style of region and >> prims counts as SL for the sole reason that it >> appears to be more cost effective in terms of resources. I mean we >> can have more regions on Server A if each region >> is limited to 15k prim, where as Server B can only host a few safely >> without thos limitations. Any idea how to make >> sure the software enforces the max prim limitations? >> >> >> On Sun, Oct 7, 2012 at 10:12 PM, Tom Haines <[email protected]<mailto: >> [email protected]>> wrote: >> >> Blocking port 8003 on the firewall to block unauthorized regions >> doesn't work if you have an external >> organization that hosts a region server that connects to your >> grid and has OpenSim users both NATing to the same >> IP address. And situations like this tend to pop up for >> political, and not technical reasons, which means there >> is little recourse for the grid operator. >> >> I've considered SSH tunneling for the 8003 connection, but have >> not had a chance to experiment. >> >> And to confirm, there is no communication directly between viewer >> and SQL server. The database will, and should >> be run unexposed to the end user. >> >> >> On Sunday, October 7, 2012, wrote: >> >> Further to this i understand there should be no reason for a >> normal viewer >> to talk directly to the SQL server. It is all done via the >> simulator. >> >> As such it would be feasible to set your SQL server to only >> allow your >> OpenSim users to authenticate from servers you run (usually >> by IP or >> FQDN). There should always be a focus on security but I would >> imagine all >> these factors would make it at least very difficult for >> someone to >> casually connect a simulator to your grid even without >> additional >> authentication in OpenSim. >> >> >> >> > unless there have been profound recent changes in the OS >> services >> > connectors structure that i've failed to notice (which is >> QUITE >> > possible), all end-user accessibility is handled by port >> 8002 and the >> > rest (connection services) is governed by port 8003 (in a >> standard >> > ROBUST based grid setup). therefore, placing :8003 behind >> your firewall >> > (thus preventing 'unauthorized' outside users from >> attaching to your >> > grid services) should not interfere with public/open >> access via viewers >> > on :8002 which would remain outside the firewall. afaik, >> this is the >> > only reliable and in my experience completely effective >> solution to the >> > problem. >> > >> > i also believe the security key function was removed by >> concensus as it >> > didn't provide any hardcore security. >> > >> > hope this helps and is remotely correct in it's technical >> assumptions - >> > or at least follows the path your concerns and argument >> were headed... >> > >> > - core >> > >> > On 10/7/2012 11:50 AM, Tom Haines wrote: >> >> I disagree that this should not be considered a concern. >> Under this >> >> security model, anyone with the information to connect to >> the grid as >> >> a user has enough information to connect a region to the >> grid. >> >> >> >> I am concerned with this as an operator of an educational >> grid. We >> >> offer our services to students and educators with the >> understanding >> >> that we can limit the objectionable content they would be >> exposed to >> >> in SL or other public OpenSim grids. Obviously if anyone >> can connect >> >> their own regions without authorization from the grid >> operators, our >> >> ability to offer this service is compromised. >> >> >> >> I know there were pass keys used in the past to >> authenticate regions, >> >> but I believe this functionality has been removed. I >> haven't seen >> >> anything on the website regarding this. I've read before >> that >> >> firewalls are the best defense, but this is untenable, >> since our usage >> >> requirements demand controlled access by region >> operators, but open >> >> access to end users from heterogeneous network >> environments. >> >> >> >> Could someone weigh in with the official line on this? >> >> >> >> On Sunday, October 7, 2012, Fleep Tuque wrote: >> >> >> >> Hi Josh, >> >> >> >> As far as I know, in order to connect a region to >> your grid, >> >> someone would need to know all the connection details >> and unless >> >> you provide that information, I'm not sure how anyone >> would know >> >> how to or be able to connect to your grid. FleepGrid >> has been >> >> running for nearly 2 years and I've never seen any >> attempts to >> >> connect a rogue region as far as I know, so I'm not >> sure it's much >> >> of a concern. >> >> >> >> I'll let someone with more knowledge of the possible >> configuration >> >> options address any .ini settings that you might be >> able to use to >> >> disable region connections, but if this is a security >> issue or >> >> problem, it's the first I've heard of it. >> >> >> >> Sincerely, >> >> >> >> - Chris/Fleep >> >> >> >> Chris M. Collins (SL/OS: Fleep Tuque) >> >> Center for Simulations & Virtual Environments >> Research (UCSIM) >> >> UCIT Instructional & Research Computing >> >> University of Cincinnati >> >> 406A Zimmer Hall >> >> 315 College Drive >> >> PO BOX 210088 >> >> Cincinnati, OH 45221-0088 >> >> [email protected] <javascript:_e({}, 'cvml', >> >> '[email protected]');> >> >> (513) 556-3018 <tel:%28513%29%20556-3018> >> >> >> >> >> http://ucsim.uc.edu >> >> >> >> On Sun, Oct 7, 2012 at 9:52 AM, Joshua Rubeck >> >> <[email protected] <javascript:_e({}, 'cvml', >> >> '[email protected]');>> wrote: >> >> >> >> Okay so here is a question for everyone. Myself >> and a few >> >> others are setting up a grid for public use, but >> we do not >> >> want other people to be able to connect their >> regions on a >> >> home based computer to our grid. One of my >> friends remembers >> >> that there used to be a setting that would >> prevent an >> >> opensimulator instance from connectiong to robust >> without >> >> authentication but I cannot find that in the >> configuration >> >> files. Is there a configuration that allows us to >> run a public >> >> grid without other people being able to connect >> their regions >> >> to our gird. >> >> ______________________________**_________________ >> >> Opensim-users mailing list >> >> [email protected] <javascript:_e({}, 'cvml', >> >> >> '[email protected].**de<[email protected]> >> ');> >> >> >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> >> >> >> >> >> >> >> >> ______________________________**_________________ >> >> Opensim-users mailing list >> >> [email protected] >> >> >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> > >> > ______________________________**_________________ >> > Opensim-users mailing list >> > [email protected] >> > >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] >> >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] <mailto:Opensim-users@lists.** >> berlios.de <[email protected]>> >> >> >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] <mailto:Opensim-users@lists.** >> berlios.de <[email protected]>> >> >> >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> >> >> >> -- >> ==============================**===== >> http://simhost.com >> http://twitter.com/jstallings2 >> http://www.linkedin.com/pub/5/**770/a49<http://www.linkedin.com/pub/5/770/a49> >> >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > ______________________________**_________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >
_______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
