I'm rather surprised this isn't the default. Does it work okay? If so, I may make it the default soon unless there are
good counterarguments.
At the moment, kick can be performed using the "kick user" command on the simulator console. I haven't used banning
facilities from the viewer itself so I can't comment on how well they are working.
Unfortunately, there's currently no good way of kicking a user without first
knowing which simulator they are on.
On 09/10/12 15:20, Joshua Rubeck wrote:
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]
<mailto:[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]>
<mailto:[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]>
<mailto:[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] <mailto:[email protected]>
<javascript:_e({}, 'cvml',
>> '[email protected]
<mailto:[email protected]>');>
>> (513) 556-3018 <tel:%28513%29%20556-3018>
<tel:%28513%29%20556-3018>
>>
>> http://ucsim.uc.edu
>>
>> On Sun, Oct 7, 2012 at 9:52 AM, Joshua Rubeck
>> <[email protected] <mailto:[email protected]>
<javascript:_e({}, 'cvml',
>> '[email protected]
<mailto:[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]
<mailto:[email protected]> <javascript:_e({}, 'cvml',
>> '[email protected].__de
<mailto:[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:[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:[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:[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:[email protected]>
<mailto:Opensim-users@lists.__berlios.de
<mailto:[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:[email protected]>
<mailto:Opensim-users@lists.__berlios.de
<mailto:[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] <mailto:[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] <mailto:[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
--
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
