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.

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.

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.

Steps

These are steps for sharing services between two separate OpenSimulator installations (Grid A and Grid B). I will assume that both installations are running in grid mode. I will assume that each installation is hosted on a separate machine or set of machines. If both installations are on the same machine then you will need to adjust default port numbers on non-shared services so that they will not clash.

We will also assume that Grid A and Grid B are running on the same local network. The ROBUST service addresses are as follows.

Grid A - 192.168.1.2 (8002 public port, 8003 private port)
Grid B - 192.168.1.3 (8002 public port, 8003 private port)

Step 1: Decide which grid installation will host the shared services

One grid's ROBUST instance (more in sophisticated setups) will host the services to be shared between multiple installations. The other grid's simulator and ROBUST configuration will be changed so that it uses the shared services rather than its own. In these instructions, Grid A will host the shared services.

Step 2: Configure the simulators on Grid B to use Grid A's services

On Grid B, we need to configure the simulators so that they connected to Grid B for some service types but Grid A for others.

The services that need to be shared are

• Asset - to share asset used within inventory items.
• Authentication - so that login passwords are authenticated against the same stored hashes.
• Avatar - to share information about worn attachments, clothing and body parts.
• Inventory - to share inventory items.
• UserAccount - to share user account information.

To do this, we configure the ServerURI in each relevant service section to connect to the Grid A services rather than Grid B. In this example, the configuration would be as follows

[AssetService]
    AssetServerURI = "http://192.168.1.2:8003"
 
[AuthenticationService]
    AuthenticationServerURI = "http://192.168.1.2:8003"
 
[AvatarService]
    AvatarServerURI = "http://192.168.1.2:8003"
 
[InventoryService]
    InventoryServerURI = "http://192.168.1.2:8003"
 
[UserAccountService]
    UserAccountServerURI = "http://192.168.1.2:8003"

Step 3: Configure Grid B's LLLoginService 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.

We need to do this because the login service consults these other services either to identify and authenticate the user (Authentation and UserAccount services) or get information to populate the login response (Avatar, Inventory).

The configuration here is more complex because we need to tell the Grid B login service to use connectors to access Grid A's services rather than instantiate it's own local service instances.

Step 3A: Configure the Login Service to use connectors for shared services

This is done in the [LoginService] section of Robust.ini. Instead of specifying services in local service DLLs, we ask the login service to instantiate connectors.

For instance, the usual UserAccountService configuration here is

[LoginService]
    UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService"

which instantiates a local user account service from the OpenSim.Services.UserAccountService.dll. But for a connector configuration. this becomes

[LoginService]
    UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector"

In all, the service sections of [LoginService] change from

[LoginService]
    UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService"
    AuthenticationService = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
    InventoryService = "OpenSim.Services.InventoryService.dll:XInventoryService"
    AvatarService = "OpenSim.Services.AvatarService.dll:AvatarService"

to

[LoginService]
    UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector"
    AuthenticationService = "OpenSim.Services.Connectors.dll:AuthenticationServicesConnector"
    InventoryService = "OpenSim.Services.Connectors.dll:XInventoryServicesConnector"
    AvatarService = "OpenSim.Services.Connectors.dll:AvatarServiceConnector"

In this case, we don't need to configure the asset service since the login service doesn't need to access this.

We also can't reconfigure the library service, since it doesn't currently have a connector. So grids connected in this manner must have identical library configurations.

Step 3B: Configure the connectors with Grid A's ROBUST service URIs

As well as getting the login service to use connectors to grid A's services, we need to tell those connectors which URIs to use. The configuration here is actually the same as for the simulator. So for each of the connectors we configured above, we need to add the relevant ServerURI entry.

So for the user account service, for instance, we need to add

[UserAccountService]
    UserAccountServerURI = "http://192.168.1.2:8003"

So in total, the following entries need to be added

[AuthenticationService]
    AuthenticationServerURI = "http://192.168.1.2:8003"
 
[AvatarService]
    AvatarServerURI = "http://192.168.1.2:8003"
 
[InventoryService]
    InventoryServerURI = "http://192.168.1.2:8003"
 
[UserAccountService]
    UserAccountServerURI = "http://192.168.1.2:8003"

Again, this is the same as for simulator cnofiguration above except that we don't need to configure the asset service.

It's also a good idea to comment out all the other entries in those sections (e.g, LocalServiceModule). They very probably won't do any harm by being there but they are not used by the connectors.

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.

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.

[ServiceList]
    ;InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
    ;AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
    ;AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
    ;UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
    ;AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"

Conclusion

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.

Problems

Tight coupling

Once somebody has a user account they can move indiscrimnately between the installations sharing those services.

Friends Service

If the friends service is shared, then users will see friends who are at other grids. This may be confusing, since they will be able to communicate with them but not join them until they have logged on to the same grid.

On the other hand, if the friends service is not shared then users will have to manage a separate friends list on each server.