Shared Services Configuration - Revision history

Ssm2017: added quicklinks header

2014-09-11T08:20:10Z

added quicklinks header

Justincc: /* Step 3C: Disable unused connectors on Grid B (optional) */

2014-04-30T23:14:36Z

‎Step 3C: Disable unused connectors on Grid B (optional)

Justincc: /* Step 3: Configure Grid B's LLLoginService to use Grid A services where appropriate */

2014-04-30T23:12:33Z

‎Step 3: Configure Grid B's LLLoginService to use Grid A services where appropriate

Justincc: /* Not supported */

2014-04-30T23:05:34Z

‎Not supported

Justincc: /* Access control */

2014-04-30T23:03:10Z

‎Access control

Justincc: /* Conceptually simpler than the Hypergrid */

2014-04-30T23:01:40Z

‎Conceptually simpler than the Hypergrid

Justincc: /* Advantages */

2014-04-30T23:00:29Z

‎Advantages

Justincc: /* Introduction */

2014-04-30T22:53:46Z

‎Introduction

Justincc: /* Introduction */

2014-04-30T22:53:33Z

‎Introduction

Justincc: /* Disucssion */

2014-04-30T22:52:04Z

‎Disucssion

← Older revision		Revision as of 08:20, 11 September 2014
Line 1:		Line 1:
		+	{{Quicklinks}}
		+
	=Introduction=		=Introduction=
	In some scenarios, one may want 2 or more separate installations of OpenSimulator rather than one large grid. However, this creates major inconvenience if users need access to both grids - a user account needs to be created on both and they will have entirely different inventory (and hence clothing, body parts and attachments) between OpenSimulator installations.		In some scenarios, one may want 2 or more separate installations of OpenSimulator rather than one large grid. However, this creates major inconvenience if users need access to both grids - a user account needs to be created on both and they will have entirely different inventory (and hence clothing, body parts and attachments) between OpenSimulator installations.

@@ Line 135: / Line 135: @@
 ===Step 3C: Disable unused connectors on Grid B (optional)===
-This is technically an optional step, but I think that it's a very good idea to disable the grid B services that are no longer required, in order to save confusion if anything is misconfigured.
+This is technically an optional step, but I think that it's a very good idea to disable the Grid B services that are no longer required, in order to save confusion if anything is misconfigured.
-To do this, one comments out the connectors made available in the [ServiceList] section.  In this case, these are service connectors made available to other parties.  So the following connectors should be commented out.
+To do this, one comments out the connectors made available in the [ServiceList] section of Grid B's robust.ini file.  In this case, these are service connectors made available to other parties.  So the following connectors should be commented out.
 <source lang="ini">

@@ Line 55: / Line 55: @@
 </source>
-==Step 3: Configure Grid B's LLLoginService to use Grid A services where appropriate==
+==Step 3: Configure Grid B's LoginService to use Grid A services where appropriate==
 As well as redirecting Grid B's simulators to use Grid A's services, we need to configure Grid B's login service to use Grid A's services.

@@ Line 156: / Line 156: @@
 ===Not supported===
-To emphasise what was said in the introduction, this is not a configuration of OpenSimulator officially supported by the project.  As it's not commonly used, you may run into bugs or other issues associated with this unusual setup.  Changes over time may require configuration adjustment that is not documented elsewhere.
+To emphasise what was said in the introduction, this is not a configuration of OpenSimulator officially supported by the project.  As it's not commonly used, you may run into bugs or other issues associated with this unusual setup.  Changes over time may require configuration adjustment that is not documented elsewhere.  It also means that this configuration is not well tested.
 Having said that, there's no reason to think that this will stop working.  It relies on fundamental configuration requirements for OpenSimulator (distributed services and connectors) which are necessary for other functionality.

@@ Line 164: / Line 164: @@
 ===Access control===
-Once somebody has a user account they can move indiscrimnately between the installations sharing those services.  There is no way to prevent this.  If you need to access control you will need to do this either via the normal configuration options (e.g. region access lists) that you would use on a unified grid, or via Hypergrid instead which does have developed and developing access controls.  It might also be possible to enforce some access control via network firewall configuration.
+Once somebody has a user account they can move indiscrimnately between the installations sharing those services.  It might be possible to limit this with a non-shared authentication service (or even an alternative authentication service implementation) that can control whether a user is allowed access to only Grid A or Grid B.
 ===Friends Service===

@@ Line 176: / Line 176: @@
 The chief advantage relates to the other mechanism (the Hypergrid) for allowing users to keep the same account details and inventory on different grids.  Unlike the Hypergrid, there are no non-Second Life concepts to understand, such as inventory suitcases or Hypergrid links.
-However, this approach doesn't allow a user to move between grids unless they logout from one grid and login back to another, even though those grids use the same account and authentication details.
+However, this approach doesn't allow a user to move between grids unless they logout from one grid and login back to another, even though those grids use the same account and authentication details.  This makes it quite difficult to imagine scenarios where the naive service sharing described above is useful.
 ===Scalability===

← Older revision		Revision as of 23:00, 30 April 2014
Line 177:		Line 177:

	However, this approach doesn't allow a user to move between grids unless they logout from one grid and login back to another, even though those grids use the same account and authentication details.		However, this approach doesn't allow a user to move between grids unless they logout from one grid and login back to another, even though those grids use the same account and authentication details.
		+
		+	===Scalability===
		+	The scalability issue is complex here.
		+
		+	On the one hand, if one has to have multiple grids with shared user accounts/inventory rather than a single big grid, sharing services will still make efficiencies of scale possible. For instance, if one is using a deduplicating asset service, then deduplication will occur over multiple grids sharing an asset service instead of potentially having two copies of the same asset in 2 different grids.
		+
		+	One could achieve this simply by sharing the asset service as above but none of the others.
		+
		+	However, this same concentration of requests into a shared service may be a scalability problem, requiring the techniques in [[Performance]] to scale the shared services. This would not be an issue if the grids were completely separate or if the grid connectivity was achieved via Hypergrid, where both grids retain their own service instances.

@@ Line 6: / Line 6: @@
 Another approach, which we will detail here, is to share the user account, authentication, avatar, asset and inventory services between multiple installations but not other services, such as grid or griduser.  This will allow the two grids to remain seperate (one will not be able to teleport between regions on different grids) whilst allow the user to retain the same account details, inventory and attachments between multiple OpenSimulator installations.
-'''This approach should be considered experimental.  It is not officially supported by the OpenSimulator project at this time.  I have seen it used successfully in a few situations but there may well be corner cases that cause issues. -- [[User:Justincc|Justincc]] ([[User talk:Justincc|talk]]) 22:35, 30 April 2014 (UTC)''
+'''This approach should be considered experimental.  It is not officially supported by the OpenSimulator project at this time.  I have seen it used successfully in a few situations but there may well be corner cases that cause issues. -- [[User:Justincc|Justincc]] ([[User talk:Justincc|talk]]) 22:35, 30 April 2014 (UTC)'''
 =Steps=

@@ Line 1: / Line 1: @@
 =Introduction=
-For various reasons, sometimes one wants to have 2 or more separate installations of OpenSimulator rather than one large grid.  However, this creates major inconvenience if users need to login to both grids - a user account needs to be created on both and they will have entirely different inventory (and hence clothing, body parts and attachments) between OpenSimulator installations.
+In some scenarios, one may want 2 or more separate installations of OpenSimulator rather than one large grid.  However, this creates major inconvenience if users need access to both grids - a user account needs to be created on both and they will have entirely different inventory (and hence clothing, body parts and attachments) between OpenSimulator installations.
 One approach is to have a single user account on one of the grids and allow the user to travel to other grids via the [[Hypergrid]].

@@ Line 151: / Line 151: @@
 You should now be able to use the same avatar account to log onto Grid A (via http://192.168.1.2:8002 in this example) and to Grid B (via http://192.168.1.3:8002).  Users will have the same details, inventory and worn items/attachments on both grids.  However, these grids are still conceptually separate - regions can overlap (e.g. grid A and grid B have different regions at 1000,1000) and there is no way to move directly between them without Hypergrid being active.
-=Disucssion=
+=Discussion=
-==Problems==
+==Disadvantages==
 ===Not supported===