Shared Services Configuration/de - Revision history

Manni: /* Schritt 3: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet */

2018-07-03T00:28:10Z

‎Schritt 3: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet

Manni: /* Schritt 3: Configure Grid B's LoginService to use Grid A services where appropriate */

2018-07-03T00:27:40Z

‎Schritt 3: Configure Grid B's LoginService to use Grid A services where appropriate

Manni: /* Discussion */

2018-07-03T00:24:43Z

‎Discussion

Manni: /* Schritte */

2018-07-03T00:19:32Z

‎Schritte

Show changes

Manni: /* Steps */

2018-07-03T00:11:42Z

‎Steps

Manni: /* Einführung */

2018-07-03T00:08:07Z

‎Einführung

Manni: /* Introduction */

2018-07-03T00:07:41Z

‎Introduction

Manni: Created page with "{{Quicklinks}} =Introduction= In some scenarios, one may want 2 or more separate installations of OpenSimulator rather than one large grid. However, this creates major incon..."

2018-07-03T00:05:17Z

Created page with "{{Quicklinks}} =Introduction= In some scenarios, one may want 2 or more separate installations of OpenSimulator rather than one large grid. However, this creates major incon..."

New page

{{Quicklinks}}

=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.

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.

'''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=

These are steps for sharing services between two separate OpenSimulator installations (Grid A and Grid B).

We make the following assumptions

* Both installations are running in grid mode.
* 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.
* Hypergrid is inactive.
* 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

<source lang="ini">
[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"
</source>

==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.

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

<source lang="ini">
[LoginService]
UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService"
</source>

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

<source lang="ini">
[LoginService]
UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector"
</source>

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

<source lang="ini">
[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"
</source>

to

<source lang="ini">
[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"
</source>

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

<source lang="ini">
[UserAccountService]
UserAccountServerURI = "http://192.168.1.2:8003"
</source>

So in total, the following entries need to be added

<source lang="ini">
[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"
</source>

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 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">
[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"
</source>

==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.

=Discussion=

==Disadvantages==

===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. 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.

===Hypergrid===
It's unknown whether Hypergrid will work on this configuration. It may well be possible when each grid has its own service, though extra configuration will definitely be required (e.g. setting up connectors).

===Access control===
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.

Without 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.

===Friends Service===
If the friends service is shared, then users will see friends who are at other grids. This may be confusing, since they won't be able to communicate with them as IMs are routed only to simulators in 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.

==Advantages==

===Conceptually simpler than the Hypergrid===
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. This makes it quite difficult to imagine scenarios where the naive service sharing described above is useful.

===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.

[[Category:German Translations]]

@@ Line 56: / Line 56: @@
 </source>
-=Schritt 3: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet=
+==Schritt 3: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet==
 Neben der Umleitung der Simulatoren von Grid B auf die Dienste von Grid A müssen wir den Anmeldungsdienst von Grid B so konfigurieren, dass die Dienste von Grid A verwendet werden.

@@ Line 56: / Line 56: @@
 </source>
-==Schritt 3: Configure Grid B's LoginService to use Grid A services where appropriate==
+=Schritt 3: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet=
 Neben der Umleitung der Simulatoren von Grid B auf die Dienste von Grid A müssen wir den Anmeldungsdienst von Grid B so konfigurieren, dass die Dienste von Grid A verwendet werden.
 Wir müssen dies tun, da der Login-Service diese anderen Dienste konsultiert, um entweder den Benutzer zu identifizieren und zu authentifizieren (Authentation- und UserAccount-Dienste) oder Informationen zu erhalten, um die Login-Antwort zu füllen (Avatar, Inventar).
 Die Konfiguration hier ist komplexer, da wir dem Grid B-Login-Dienst mitteilen müssen, dass Connectors für den Zugriff auf die Dienste von Grid A verwendet werden sollen, anstatt seine eigenen lokalen Dienstinstanzen zu instanziieren.
 ==Schritt 3A: Konfigurieren Sie den Anmeldungsdienst für die Verwendung von Connectors für gemeinsame Dienste==

@@ Line 4: / Line 4: @@
 In einigen Szenarios können zwei oder mehr separate Installationen von OpenSimulator anstelle von einem großen Raster gewünscht werden. Dies führt jedoch zu großen Unannehmlichkeiten, wenn Benutzer Zugriff auf beide Grids benötigen - auf beiden muss ein Benutzerkonto erstellt werden, und sie haben zwischen OpenSimulator-Installationen ein völlig anderes Inventar (und damit Kleidung, Körperteile und Anhänge).
-Ein Ansatz besteht darin, ein einziges Benutzerkonto in einem der Grids zu haben und es dem Benutzer zu ermöglichen, über das  [[Hypergrid]]zu anderen Grids zu reisen.
+Ein Ansatz besteht darin, ein einziges Benutzerkonto in einem der Grids zu haben und es dem Benutzer zu ermöglichen, über das  [[Hypergrid]] zu anderen Grids zu reisen.
 Ein weiterer Ansatz, den wir hier näher erläutern werden, ist die gemeinsame Nutzung von Benutzerkonten, Authentifizierungs-, Avatar-, Asset- und Inventardiensten zwischen mehreren Installationen, jedoch nicht mit anderen Diensten wie dem Grid oder Griduser. Dadurch können die beiden Grids getrennt bleiben (eine Region kann nicht zwischen Regionen auf verschiedenen Grids teleportieren), während der Benutzer die gleichen Kontodetails, Inventar und Anhänge zwischen mehreren OpenSimulator-Installationen beibehalten kann.

@@ Line 152: / Line 152: @@
 Sie sollten nun dasselbe Avatar-Konto verwenden können, um sich bei Grid A (in diesem Beispiel http://192.168.1.2:8002 ) und bei Grid B (über http://192.168.1.3:8002 ) anzumelden. Benutzer haben die gleichen Details, Inventar und abgenutzte Gegenstände / Anhänge auf beiden Gittern. Diese Gitter sind jedoch immer noch konzeptionell getrennt - Regionen können sich überlappen (z. B. Gitter A und Gitter B haben unterschiedliche Regionen bei 1000, 1000), und es gibt keine Möglichkeit, sich direkt zwischen ihnen zu bewegen, ohne dass Hypergrid aktiv ist.
-=Discussion=
+=Diskussion=
-==Disadvantages==
+==Nachteile==
-===Not supported===
+===Nicht unterstützt===
-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.
+Um zu betonen, was in der Einleitung gesagt wurde, ist dies keine Konfiguration von OpenSimulator, die offiziell vom Projekt unterstützt wird. Da es nicht häufig verwendet wird, können Fehler oder andere Probleme auftreten, die mit dieser ungewöhnlichen Konfiguration zusammenhängen. Änderungen im Laufe der Zeit erfordern möglicherweise Konfigurationsanpassungen, die an anderer Stelle nicht dokumentiert sind. Es bedeutet auch, dass diese Konfiguration nicht gut getestet wurde.
-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.
+Abgesehen davon gibt es keinen Grund zu der Annahme, dass dies nicht mehr funktionieren wird. Es basiert auf grundlegenden Konfigurationsanforderungen für OpenSimulator (verteilte Dienste und Konnektoren), die für andere Funktionen erforderlich sind.
 ===Hypergrid===
-It's unknown whether Hypergrid will work on this configuration.  It may well be possible when each grid has its own service, though extra configuration will definitely be required (e.g. setting up connectors).
+Es ist unbekannt, ob Hypergrid mit dieser Konfiguration arbeitet. Es kann durchaus möglich sein, dass jedes Gitter seinen eigenen Dienst hat, obwohl eine zusätzliche Konfiguration auf jeden Fall erforderlich ist (z. B. Einrichten von Anschlüssen).
-===Access control===
+===Zugangskontrolle===
-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.
+Sobald jemand ein Benutzerkonto hat, kann er sich ohne Unterschied zwischen den Installationen bewegen, die diese Dienste teilen. Es könnte möglich sein, dies durch einen nicht gemeinsam genutzten Authentifizierungsdienst (oder sogar eine alternative Authentifizierungsdienstimplementierung) zu begrenzen, der steuern kann, ob ein Benutzer nur Zugriff auf Grid A oder Grid B erhält.
-Without 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.
+Ohne dies müssen Sie, wenn Sie auf die Steuerung zugreifen müssen, dies entweder über die normalen Konfigurationsoptionen (z. B. Bereichszugriffslisten) tun, die Sie in einem einheitlichen Grid verwenden, oder über Hypergrid, das Zugriffskontrollen entwickelt und entwickelt hat. Es könnte auch möglich sein, eine Zugangskontrolle über eine Netzwerk-Firewall-Konfiguration zu erzwingen.
 ===Friends Service===
-If the friends service is shared, then users will see friends who are at other grids.  This may be confusing, since they won't be able to communicate with them as IMs are routed only to simulators in the same grid.
+Wenn der Freundesdienst freigegeben ist, werden Benutzer Freunde sehen, die sich in anderen Grids befinden. Dies kann verwirrend sein, da sie nicht mit ihnen kommunizieren können, da IMs nur an Simulatoren im selben Grid weitergeleitet werden.
-On the other hand, if the friends service is not shared then users will have to manage a separate friends list on each server.
+Wenn der Freundesdienst nicht freigegeben ist, müssen Benutzer auf jedem Server eine separate Freundesliste verwalten.
-==Advantages==
+==Vorteile==
-===Conceptually simpler than the Hypergrid===
+===Konzeptionell einfacher als das Hypergrid===
-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.
+Der Hauptvorteil bezieht sich auf den anderen Mechanismus (das Hypergrid), mit dem Benutzer die gleichen Kontodetails und das gleiche Inventar in verschiedenen Grids beibehalten können. Im Gegensatz zum Hypergrid gibt es keine Nicht-Second-Life-Konzepte wie Inventarkoffer oder 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.  This makes it quite difficult to imagine scenarios where the naive service sharing described above is useful.
+Dieser Ansatz ermöglicht es einem Benutzer jedoch nicht, sich zwischen den Rastern zu bewegen, es sei denn, sie melden sich von einem Raster ab und melden sich wieder an, auch wenn diese Raster dieselben Konto- und Authentifizierungsdetails verwenden. Dies macht es ziemlich schwierig, sich Szenarien vorzustellen, in denen die oben beschriebene naive Dienstfreigabe nützlich ist.
-===Scalability===
+===Skalierbarkeit===
-The scalability issue is complex here.
+Das Problem der Skalierbarkeit ist hier komplex.
-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.
+Auf der einen Seite, wenn man mehrere Grids mit gemeinsamen Benutzerkonten / Inventar anstelle eines einzelnen großen Grids haben muss, werden Sharing-Services immer noch Skaleneffekte ermöglichen. Wenn Sie beispielsweise einen deduplizierenden Asset-Service verwenden, erfolgt die Deduplizierung über mehrere Grids, die einen Asset-Service gemeinsam nutzen, anstatt potenziell zwei Kopien des gleichen Assets in zwei verschiedenen Grids zu haben.
-One could achieve this simply by sharing the asset service as above but none of the others.
+Man könnte dies erreichen, indem man einfach den Asset-Service wie oben teilt, aber keinen der anderen.
-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.
+Dieselbe Konzentration von Anforderungen in einem gemeinsam genutzten Dienst kann jedoch ein Skalierbarkeitsproblem sein, das die [[Performance]] erfordert, um die gemeinsam genutzten Dienste zu skalieren. Dies wäre kein Problem, wenn die Grids vollständig getrennt wären oder wenn die Grid-Konnektivität über Hypergrid erreicht würde, wobei beide Grids ihre eigenen Dienstinstanzen beibehalten.
 [[Category:German Translations]]

@@ Line 10: / Line 10: @@
 '''Dieser Ansatz sollte als experimentell betrachtet werden. Es wird derzeit vom OpenSimulator-Projekt nicht offiziell unterstützt. Ich habe gesehen, dass es in einigen Situationen erfolgreich verwendet wurde, aber es kann durchaus Fälle geben, die Probleme verursachen. -- [[User:Justincc|Justincc]] ([[User talk:Justincc|talk]]) 22:35, 30 April 2014 (UTC)'''
-=Steps=
+=Schritte=
-These are steps for sharing services between two separate OpenSimulator installations (Grid A and Grid B).
+Dies sind Schritte zum Freigeben von Diensten zwischen zwei separaten OpenSimulator-Installationen (Grid A und Grid B).
-We make the following assumptions
+Wir machen folgende Annahmen
-* Both installations are running in grid mode.
+* Beide Installationen werden im Rastermodus ausgeführt.
-* 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.
+* Jede Installation wird auf einem separaten Computer oder einer Gruppe von Computern gehostet. Wenn sich beide Installationen auf demselben Computer befinden, müssen Sie die Standardportnummern für nicht gemeinsam genutzte Dienste anpassen, damit sie nicht miteinander kollidieren.
-* Hypergrid is inactive.
+* Hypergrid ist inaktiv.
-* Grid A and Grid B are running on the same local network.  The ROBUST service addresses are as follows.
+* Grid A und Grid B werden im selben lokalen Netzwerk ausgeführt. Die ROBUST-Dienstadressen lauten wie folgt.
   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 ==
+== Schritt 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 ==
+== Schritt 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.
@@ Line 57: / Line 57: @@
 </source>
-==Step 3: Configure Grid B's LoginService to use Grid A services where appropriate==
+==Schritt 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 64: / Line 64: @@
 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===
+===Schritt 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.
@@ Line 106: / Line 106: @@
 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===
+===Schritt 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.
@@ Line 136: / Line 136: @@
 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)===
+===Schritt 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.
@@ Line 150: / Line 150: @@
 </source>
-==Conclusion==
+==Fazit==
 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.

@@ Line 1: / Line 1: @@
 {{Quicklinks}}
-=Introduction=
+=Einführung=
-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 einigen Szenarios können zwei oder mehr separate Installationen von OpenSimulator anstelle von einem großen Raster gewünscht werden. Dies führt jedoch zu großen Unannehmlichkeiten, wenn Benutzer Zugriff auf beide Grids benötigen - auf beiden muss ein Benutzerkonto erstellt werden, und sie haben zwischen OpenSimulator-Installationen ein völlig anderes Inventar (und damit Kleidung, Körperteile und Anhänge).
-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]].
+Ein Ansatz besteht darin, ein einziges Benutzerkonto in einem der Grids zu haben und es dem Benutzer zu ermöglichen, über das  [[Hypergrid]]zu anderen Grids zu reisen.
-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.
+Ein weiterer Ansatz, den wir hier näher erläutern werden, ist die gemeinsame Nutzung von Benutzerkonten, Authentifizierungs-, Avatar-, Asset- und Inventardiensten zwischen mehreren Installationen, jedoch nicht mit anderen Diensten wie dem Grid oder Griduser. Dadurch können die beiden Grids getrennt bleiben (eine Region kann nicht zwischen Regionen auf verschiedenen Grids teleportieren), während der Benutzer die gleichen Kontodetails, Inventar und Anhänge zwischen mehreren OpenSimulator-Installationen beibehalten kann.
-'''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)'''
+'''Dieser Ansatz sollte als experimentell betrachtet werden. Es wird derzeit vom OpenSimulator-Projekt nicht offiziell unterstützt. Ich habe gesehen, dass es in einigen Situationen erfolgreich verwendet wurde, aber es kann durchaus Fälle geben, die Probleme verursachen. -- [[User:Justincc|Justincc]] ([[User talk:Justincc|talk]]) 22:35, 30 April 2014 (UTC)'''
 =Steps=