Configuration/de
From OpenSimulator
(→Running OpenSimulator in Standalone mode) |
(→Netzwerkzugriff für die eigenständige Installation) |
||
Line 110: | Line 110: | ||
</source> | </source> | ||
− | + | Dies ist der Standardwert von 9000, wenn Sie ihn nicht explizit geändert haben. | |
− | 2. UDP | + | 2. UDP über den InternalPort jeder Region, wie er in den Regionsdateien konfiguriert ist (z. B. Regions.ini). Zum Beispiel, wenn Sie konfiguriert haben |
<source lang="ini"> | <source lang="ini"> | ||
Line 138: | Line 138: | ||
</source> | </source> | ||
− | + | Dann müssen Sie die Ports 9000 und 9001 für UDP-Verkehr öffnen. | |
− | 3. | + | 3. Die Netzwerkadresse des Computers, der die OpenSimulator-Installation hostet, muss für die Verbindung von Viewern zugänglich sein. Im obigen Beispiel ist der Installationsrechner über den Domain-Namen "mygrid.com" aus dem Internet erreichbar. Wenn auf die gleiche Installation von Viewern im selben Netzwerk zugegriffen werden muss, muss es auch möglich sein, dass sie diesen Domänennamen erfolgreich auflösen (nicht alle Router, insbesondere Home-Router, haben diese "Loopback-Fähigkeit"). |
− | + | Wenn auf die Installation nur im selben LAN zugegriffen werden muss, könnte man die lokale IP-Adresse des Servers (zB 192.168.1.2) angeben. | |
== Connecting to a standalone installation == | == Connecting to a standalone installation == |
Revision as of 04:40, 5 September 2018
OpenSimulator Simulator Konfigurationsdatei
Die Konfiguration des Regionssimulators wird mithilfe einer Datei namens OpenSim.ini verwaltet. Diese Datei wird unabhängig davon verwendet, ob die Simulation im Standalone- oder im Grid-Modus ausgeführt wird. Diese Datei verweist auf einige zusätzliche Konfigurationsinformationen aus dem Verzeichnis config-include /. Informationen zu den verschiedenen Einstellungen finden Sie in der Datei OpenSim.ini (oder OpenSim.ini.example als Referenz).
Bitte beachten Sie, dass der Name OpenSim.ini (oder OpenSim.ini.example als Referenz).
Bitte beachten Sie, dass der Name OpenSim.ini über command line argumentsgeändert werden kann.
Es ist auch möglich, die Inifile-Einstellungen auf zwei Dateien zu verteilen. Dies ist nützlich, wenn Sie mehrere OpenSimulator-Prozesse ausführen möchten, bei denen die meisten Ihrer Einstellungen bis auf einige identisch sind. Die Masterdatei wird zuerst gelesen, dann wird die Inifile gelesen. Einstellungen, die in den in der Master-Datei angegebenen Inifile Overrule-Einstellungen angegeben sind. Die Master-Datei hat das gleiche Format und die gleichen Schlüsselwörter wie die Inifile, daher gilt die gleiche Dokumentation.
Datenbank
OpenSimulator unterstützt die folgenden Datenbank-Engines. Informationen zum Einrichten dieser Dateien finden Sie in der Datei OpenSim.ini.example und in den anderen Beispieldateien in bin / config-include. Wenn Sie die Standard-SQLite-Konfiguration nicht verwenden möchten, müssen Sie Ihre Datenbank einrichten, bevor Sie fortfahren . SQLite benötigt keine weitere Konfiguration. Detaillierte Einstellungen finden Sie unter Database Settings.
- SQLite (Standard) - eine leichtgewichtige Datenbank, die im Lieferumfang von OpenSimulator enthalten ist und ohne zusätzliche Konfiguration verwendet werden kann. Es ist hauptsächlich dafür gedacht, Sie schnell zum Laufen zu bringen, nicht für den produktiven Einsatz. Es ist deutlich langsamer als MySQL. Einige Funktionen (z. B. Anhangspersistenz) sind noch nicht vollständig implementiert.
- MySQL (vollständig unterstützt) - Dies ist die empfohlene Datenbank für alle Anwendungen, die über das Experimentieren oder kleine eigenständige Anwendungen hinausgehen. Die minimale MySQL-Version ist 5.1.
- MariaDB (vollständig unterstützt) - Eine kompatible Alternative zu MySQL. Sie müssen sicherstellen, dass der ausgewählte Zeichensatz utf8mb3 (dh 3 Bytes) ist. Einige Installationen sind standardmäßig auf uft8mb4 (4 Bytes) eingestellt und das wird fehlschlagen.
- MSSQL (nicht ganz unterstützt) - Die Unterstützung für einige aktuelle OpenSimulator-Funktionen ist möglicherweise noch nicht implementiert, obwohl die meisten davon unterstützt werden.
Standalone vs. Grid
Wir empfehlen, OpenSimulator zuerst im Standalone-Modus auszuführen, bevor Sie versuchen, es mit einem Grid zu verbinden oder ein eigenes Grid auszuführen. OpenSimulator wird standardmäßig im eigenständigen Modus auf den Binärdistributionen gestartet.
Eine OpenSimulator-Konfiguration besteht aus Regionen (die von Regionssimulatoren ausgeführt werden) und Back-End-Datendiensten (wie Benutzer-, Ressourcen- und Inventarverwaltung).
Ein System, das im eigenständigen Modus ausgeführt wird, führt sowohl den Regionssimulator als auch alle Datendienste in einem einzigen Prozess aus, wenn Sie OpenSim.exe ausführen. In diesem Modus können Sie beliebig viele Regionen ausführen, jedoch nur auf einem einzelnen Computer.
Im Grid-Modus sind die Datendienste nicht Teil des Regionsserverprozesses. Stattdessen werden sie in einer separaten ausführbaren Datei namens Robust.exe ausgeführt. Eine robuste Shell kann alle Dienste ausführen oder sie können auf beliebig viele Robust-Instanzen aufgeteilt werden. Dadurch können sie bei Bedarf auf völlig separaten Maschinen ausgeführt werden. In diesem Modus fungiert OpenSim.exe ausschließlich als Regionsserver und bedient eine oder mehrere Regionen, die mit den separaten Datendiensten kommunizieren. An diesem Punkt können Sie mehrere OpenSim.exe-Region-Simulatoren auf verschiedenen Computern ausführen.
Das Ausführen im Grid-Modus ist komplizierter als das Ausführen im Standalone-Modus. Es erfordert ein Verständnis von UUID, X, Y-Standort, Server-Handshake-Passwörtern, Grundbesitzern und Grundbesitzern und einigen anderen Einstellungen. Diese erfordern mehr Sorgfalt und Geduld beim Einrichten. Wir empfehlen dringend, dass Sie dies nicht versuchen, es sei denn, Sie sind sehr geduldig und sehr technisch kompetent.
OpenSimulator im Standalone-Modus ausführen
Binäre Verteilungen von OpenSimulator sind standardmäßig so konfiguriert, dass sie im eigenständigen Modus ausgeführt werden.
Wenn Sie OpenSimulator jedoch aus der Quelldistribution oder aus dem Git-Repository erstellen, müssen Sie Folgendes tun:
- Wechseln Sie in den Ordner bin
- Kopieren Sie die Datei OpenSim.ini.example in OpenSim.ini . Dies konfiguriert den 3D-Simulator selbst.
- Wechseln Sie in den Ordner bin / config-include
- Kopieren Sie die Datei StandaloneCommon.ini.example in StandaloneCommon.ini . Dies konfiguriert die In-Process-Datendienste, die von der Standalone-Konfiguration verwendet werden.
- Im [Architecture] -Abschnitt von OpenSim.ini , am unteren Ende der Datei, entfernen Sie die Kommentarzeichen für die Standalone.ini- Zeile. Um eine Codezeile auszukommentieren, entfernen Sie das Semikolon (;) Kommentarzeichen vor der Zeile, so dass es heißt:
Include-Architecture = "config-include/Standalone.ini"
Das Ausführen von OpenSimulator ist dann eine Frage des Startens von OpenSim.exe. Sie müssen jedoch zuvor alle Abhängigkeiten installiert haben. Weitere Informationen finden Sie unter Abhängigkeiten . Öffnen Sie danach eine Eingabeaufforderung (für Windows Benutzer, Startmenü> Ausführen> cmd) und navigieren Sie zum Verzeichnis Opensim / bin.
Führen Sie unter Windows Folgendes aus:
OpenSim.exe
Führen Sie unter Linux Folgendes aus:
mono OpenSim.exe
Der erste Start
Wenn Sie OpenSimulator zum ersten Mal ausführen, werden Sie an der Konsole mehrere Fragen stellen, die eine einzelne Region für Sie einrichten. Die von Ihnen eingegebenen Konfigurationsoptionen werden in die Datei bin / Regions / Regions.ini geschrieben, die Sie zu einem späteren Zeitpunkt bearbeiten können, wenn Sie Änderungen vornehmen müssen.
Viele der Fragen haben Standardwerte. Hier sind einige Erklärungen zu den gestellten Fragen:
- New region name
- Der Name für Ihre Region. Dies muss angegeben werden!
- Region UUID
- Die eindeutige ID Ihrer Region. In fast allen Fällen möchten Sie den zufällig erzeugten Standard in den eckigen Klammern akzeptieren. Der einzige Zeitpunkt, zu dem Sie nicht möchten, ist, wenn Sie versuchen, eine Konfiguration einzurichten, die auf bereits vorhandene Regionsdaten verweist. Aber in diesem Fall ist es wahrscheinlich besser, die Datei "Regions.ini" direkt zu bearbeiten
- Region Location
- Dies ist der Standort der Region im Raster. Im Standalone-Modus können Sie diese als Standard (1000,1000) beibehalten. Wenn Sie später weitere Regionen in der Regions.ini einrichten, benötigen Sie andere Rasterkoordinaten (zB 1000,1001). OpenSimulator-Regionen können an beliebiger Stelle in einem Raster von 65536 mal 65536 platziert werden. Für Hypergrid- aktivierte Regionen ist jedoch möglicherweise eine besondere Berücksichtigung der Region erforderlich. Weitere Informationen finden Sie unter Installing and Running Hypergrid#The 4096 Regions Limit.
- Internal IP address
- In praktisch allen Fällen kann dies als 0.0.0.0 belassen werden (dies ist ein Platzhalter, mit dem OpenSimulator auf UDP-Verbindungen auf einer der Netzwerkschnittstellen des Servers warten kann). Wenn Sie UDP-Verbindungen auf nur eine Netzwerkschnittstelle beschränken möchten, können Sie eine explizite IP-Adresse angeben. Diese Adresse wird nur intern verwendet - der externe Hostname ist der Name, der tatsächlich an den Viewer übergeben wird (und daher der wichtige Name ist).
- Internal port
- Dies ist der IP-Port für alle eingehenden Clientverbindungen. Der Name ist etwas irreführend, da er sowohl extern (z. B. von einem Second Life-Viewer) als auch intern verwendet wird. Sie können dies an jedem gewünschten Port vornehmen, aber es ist sicher, dass Sie den Standardwert 9000 verwenden. Jede Region auf Ihrem Server muss einen eindeutigen Port haben.
- Allow alternate ports
- Dies ist derzeit experimentell. Bitte belassen Sie es mit dem Standardwert False.
- External host name
- Wenn Sie dies bei der Standardeinstellung 'SYSTEMIP' belassen, wird dies die LAN-Netzwerkadresse des Geräts (z. B. 192.168.1.2). Dies ist in Ordnung, wenn Sie nur von Ihrem LAN aus eine Verbindung herstellen. Wenn Sie sich von einem Client im Internet aus verbinden wollen, sollte dies die externe IP-Adresse Ihres Routers sein. Vollständig qualifizierte Domänennamen (FQDNs) können ebenfalls verwendet werden, obwohl sie in eine numerische IP-Adresse konvertiert werden, bevor sie an den Viewer gesendet werden.
Die folgenden Details werden auch in OpenSimulator 0.6.9 und früher gestellt.
- Master Avatar UUID
- Dies ist eine ältere OpenSimulator-Funktion und kann auf dem Standardwert 00000000-0000-0000-0000-000000000000 stehen. Später können Sie dies in der Regions.ini in die UUID Ihres eigenen Avatars ändern, wenn Sie Probleme beim Bearbeiten des Geländes haben.
- Master Avatar first name
- Dies ist eine alternative Möglichkeit, den Master-Avatar anhand des Avatarnamens und nicht anhand der UUID anzugeben. Wenn Sie hier die Eingabetaste drücken, bleiben sowohl dieses Feld als auch das Feld für den Nachnamen leer. Das Akzeptieren des leeren Standards ist in Ordnung - dies kann später immer in der Datei "Regions.ini" geändert werden.
- Master Avatar last name
- Der Nachname des Master-Avatars.
- Master Avatar sandbox password
- Das Passwort des Master-Avatars.
In OpenSimulator 0.7 und höher wird OpenSimulator Sie auffordern, während des Einrichtungsvorgangs jeder Region einen Stand zuzuordnen. Wenn ein Nachlass erstellt werden muss, werden Sie ebenfalls aufgefordert, einen Nachlassverwalter zu beauftragen. Im Standalone-Modus kann während des Einrichtungsvorgangs auch ein Estate Manager erstellt werden.
Vergessen Sie nicht die Kontodetails, die Sie verwenden, um den Master-Avatar (in 0.6.9) oder den Estate-Manager (in 0.7 und später) einzurichten. Nur dieser Benutzer kann zunächst die In-World-Einstellungen für Ihre Region konfigurieren. Dies ist auch ein Benutzerkonto, mit dem Sie Ihren ersten Login-Test durchführen können.
Weitere Informationen zur Datei "Regions.ini", die diese Fragen generieren, finden Sie unter Configuring Regions.
Wenn Sie einen anderen Benutzer als den Estate Manager erstellen möchten, geben Sie in der Serverkonsole Folgendes ein:
create user
Dies stellt Ihnen eine Reihe von Fragen zur Erstellung eines Benutzers (wie Vorname, Nachname und Passwort).
Netzwerkzugriff für die eigenständige Installation
Im Standalone-Modus benötigt ein Viewer, der eine Verbindung zu Ihrer Installation herstellt, den folgenden Netzwerkzugriff auf Ihren Installationscomputer.
1. TCP über den http_listener_port, wie er in Ihrem Simulator verwendet wird. Dies wird im Abschnitt [Netzwerk] Ihrer OpenSim.ini.
[Network] http_listener_port = 9000
Dies ist der Standardwert von 9000, wenn Sie ihn nicht explizit geändert haben.
2. UDP über den InternalPort jeder Region, wie er in den Regionsdateien konfiguriert ist (z. B. Regions.ini). Zum Beispiel, wenn Sie konfiguriert haben
[test] RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c81 Location = 1000,1000 SizeX = 256 SizeY = 256 SizeZ = 256 InternalAddress = 0.0.0.0 InternalPort = 9000 AllowAlternatePorts = False ExternalHostName = mygrid.com [test2] RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c82 Location = 1000,1001 SizeX = 256 SizeY = 256 SizeZ = 256 InternalAddress = 0.0.0.0 InternalPort = 9001 AllowAlternatePorts = False ExternalHostName = mygrid.com
Dann müssen Sie die Ports 9000 und 9001 für UDP-Verkehr öffnen.
3. Die Netzwerkadresse des Computers, der die OpenSimulator-Installation hostet, muss für die Verbindung von Viewern zugänglich sein. Im obigen Beispiel ist der Installationsrechner über den Domain-Namen "mygrid.com" aus dem Internet erreichbar. Wenn auf die gleiche Installation von Viewern im selben Netzwerk zugegriffen werden muss, muss es auch möglich sein, dass sie diesen Domänennamen erfolgreich auflösen (nicht alle Router, insbesondere Home-Router, haben diese "Loopback-Fähigkeit").
Wenn auf die Installation nur im selben LAN zugegriffen werden muss, könnte man die lokale IP-Adresse des Servers (zB 192.168.1.2) angeben.
Connecting to a standalone installation
To connect to your new sim with your user, start up a Second Life viewer with the following command line switches:
Client on same machine as OpenSim:
-loginuri http://127.0.0.1:9000
Client on same LAN as OpenSim:
-loginuri http://lan_ip:9000
Client on different machine or internet:
-loginuri http://external_ip:9000
Then enter the user name and password you set up in the previous step and your new user should login.
Be aware of loopback problems when Running viewer & server(s) on the same machine (LAN) by using the "external" configuration. (You might notice endless waiting for region handshake.) See also troubleshoot hints. If you're having Connectivity problems, be sure to read the Network Configuration Page. This is important if you see Region handshake issue.
IMPORTANT NOTE, DIVA DISTRO - 4 Apr. 2012 -
If you download the latest version of diva-r18611.tar.bz, it is necessary to first launch the setup program configure.exe
- In Linux or MacOSX : open a terminal and enter "mono /diva-r18611/bin/Configure.exe" (assuming that you have placed the Diva distro in /diva-r18611)
- In Windows, assuming they extracted Diva in My Documents, one would open "Run => cmd" and enter 'cd "%USERPROFILE%\My Documents\diva-r18611\", followed by "Configure.exe".
After issuing the command, you can set your sim's domain name, and carefully answer the program's questions, then start the program as instructed in above paragraphs.
The program will install the optimum configuration for OpenSim, example: http://<your_IP>:9000 and WiFi http:<your_IP>:9000/wifi In the standalone version, four regions will be set up. You can optionally add other regions later on, so make sure to use the same first name with the addition of a number (ex: "region 5", "region 6", "region 7", etc. otherwise you can't enter the region and you'd be placed in the nearest free location.
If you wish to enter a different region name, make sure that the "distance" between the island created by the Wifi configuration program and the next, will be at least 40 positions away from the first installed region) (command console: create region Johnnyland RegionConfigure.ini)
Running OpenSimulator in Grid mode
NOTE: 0.7 is the first OpenSimulator release that fully migrates all services to the ROBUST server shell. OpenSim.Grid.UserServer.exe and MessageServer.exe from OpenSimulator 0.6.9 are no longer necessary. Please see the 0.7 release notes for more details. For details on how to set up grid services in OpenSimulator 0.6.9 and earlier please see OpenSim 0.6.9 Grid Mode Configuration |
Running OpenSimulator in grid mode is considerably more complicated than running a standalone instance. Instead of running everything in the same process, backend data services (asset, inventory, etc.) run in one or more separate processes, often on a different machine. This allows multiple OpenSim.exe simulator instances to use the same asset and inventory data.
Step 1: Set up a ROBUST services instance
1. In the bin directory, copy Robust.ini.example to Robust.ini. The example file is configured to run all the services in a single ROBUST instance.
2. Configure the Database Settings in Robust.ini to use your MySQL database. Only MySQL is supported for running grid services.
3. Start up Robust.exe.
mono Robust.exe (Linux, BSD, Mac OS X)
or
Robust.exe (Windows)
If you don't see any errors (in red) on the console then you can move on to the next step.
4. Every region must belong to an estate, and every estate must have an owner which is a valid user account in OpenSim's user account service. Create a user on the ROBUST command console with the following command.
create user
This will ask you for the user's name, password and an optional e-mail. Remember this name since you will need it when you start up the simulator for the first time.
Step 2: Configure an OpenSim.exe to use the ROBUST services
In grid mode, as in standalone mode, you need to configure OpenSim.ini which controls the 3D simulator itself.
However, instead of using and configuring the file config-include/StandaloneCommon.ini, a simulator connecting to a grid needs to use and configure the config-include/GridCommon.ini file, in order to connect to the ROBUST hosted remote data services rather than in-process local ones.
The steps for both these operations are as follows.
1. Copy bin/OpenSim.ini.example to OpenSim.ini
2. Find the [Architecture] section at the very bottom of OpenSim.ini. Make sure that one of the following lines is uncommented:
Include-Architecture = "config-include/Grid.ini" (in OpenSimulator 0.7.1 and later)
or
Include-Grid = "config-include/Grid.ini" (in OpenSimulator 0.7.0.2 and earlier)
The others should remain commented.
3. Go to bin/config-include and copy GridCommon.ini.example to GridCommon.ini.
4. Open GridCommon.ini in a text editor. You will see lots of URL entries, each of which have dummy defaults of http://myassetserver.com:8003, http://myinventoryserver.com:8003, etc. You will need to change each of these to point towards the address of your ROBUST instance. For instance, if you're running ROBUST on a machine with a local IP address of 192.168.1.2, you will need to change AssetServerURI to the setting
AssetServerURI = "http://192.168.1.2:8003"
5. Run OpenSim.exe. If you're running OpenSim.exe for the first time you will get the same questions about setting up the region that occur on a first-run in standalone mode. Please see the standalone section for instructions on how to answer these, or read more information about the Regions.ini file on the Configuring Regions page.
If everything is set up correctly, when starting up OpenSim.exe you shouldn't see any errors. You should also see the ROBUST console display log lines saying that the region has registered with the grid service. For example,
21:43:45 - [GRID SERVICE]: Region t1 (176cc95e-f693-4b02-8e08-af86e2372faa) registered successfully at 256000-256000 21:43:47 - [GRID SERVICE]: region t1 has 0 neighbours
Network access for a grid installation
In standalone mode, a viewer connecting to your installation needs to access
- The login service over TCP and other configured public services (e.g. grid info, map).
- The http_server_port of each configured simulator over TCP.
- The InternalPort and ExternalHostName of each configured region.
The last two requirements are the same as for standalone installations, except that they apply to each server that hosts a simulator. Please see the standalone section above for more details.
The login service is a little different. Whereas in standalone this uses the same http_server_port as the simulator itself, in grid mode it's running in a separate ROBUST service.
The default port for the login service is 8002. You can see this used in the [ServiceList] section of Robust.ini.example.
[ServiceList] AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector" InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector" GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector" GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector" AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector" OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector" AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector" LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector" PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector" UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector" GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector" FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector" MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector" MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
Here all the public services (those where the viewer connects directly to the service) are served on port 8002, with internal services on 8003. So you need to make sure that the viewer can access port 8002 over TCP but you do not want to expose port 8003. Only simulators need to be able to connect to port 8003.
Connecting to a grid installation
Your client startup line will look something like
-loginuri http://mygrid.com:8002
The loginuri needs to be the address to the login service. In standalone mode, this was the same address as the region simulator and the port was 9000 by default. However, in grid mode it will be the address to login service hosted on the ROBUST instance. In this case, the address will be 192.168.1.2. The port number of 8002 is the traditional one for the grid login service and is the default in Robust.ini.example.
If the login is successful, you will see log lines on the ROBUST console (for the login itself) and then log lines on the region simulator console (as the login process tells the simulator to expect the avatar, tells the viewer the address of the region simulator and then when the viewer starts talking to the simulator directly).
Running multiple ROBUST service instances
If you are operating a grid, then you can run different services (e.g. asset, inventory) in different ROBUST instances, in order to spread the load. To do this, you will need to edit the ServiceConnectors parameter in the [Startup] section of Robust.ini (or Robust.HG.ini if you're running Hypergrid). The default ServiceConnectors parameter looks something like this
[ServiceList] AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector" InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector" GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector" GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector" AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector" OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector" AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector" LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector" PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector" UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector" GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector" FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector" MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector" MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
Each entry has the form
<port-number>/<dll>:<connector-class-name>
For instance, the first entry above
8003/OpenSim.Server.Handlers.dll:AssetServiceConnector
says to start an AssetServiceConnector (and hence an asset service) from the OpenSim.Server.Handlers.dll and to server that from port 8003.
By default, Robust.exe loads a configuration file with the same name but with .ini appended instead of .exe. So Robust.exe will look for an inifile called Robust.ini. You can change this by giving the parameter on the commandline. For instance, to start Robust with HG parameters, one would use
Robust.exe -inifile=Robust.HG.ini
So if you wanted to run every connector apart from assets in one instance of ROBUST and the asset connector in another instance, you would have two ini files. One could remain Robust.ini and have
[ServiceList] InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector" GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector" GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector" AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector" OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector" AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector" LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector" PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector" UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector" GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector" FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector" MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector" MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
The other could be called Robust.Assets.ini and have
[ServiceList] AssetServiceConnector = "8004/OpenSim.Server.Handlers.dll:AssetServiceConnector"
Note that this is using port 8004 instead of port 8003. This is necessary since only one executable can use each port at a time. You will need to make sure your simulator configuration files use port 8004 for the asset service as well.
You will also need to change the default network port to 8004 for this second copy of Robust.exe
[Network] port = 8004
Once you've created the two ROBUST configuration files (Robust.ini containing all services apart from asset and Robust.Assets.ini containing only the asset service), then you could start the first Robust.exe as usual.
Robust.exe
This will load Robust.ini, as we haven't specified a Robust.ini. Also, the logfile it will use will be Robust.log as we haven't manually specified one.
The second ROBUST instance we would start with
Robust.exe -inifile=Robust.Assets.ini -logfile=Robust.Assets.log
The -inifile switch tells the second Robust instance to load it's configuration from Robust.Assets.ini rather than Robust.ini. The -logfile switch tells Robust.exe to use Robust.Assets.log as its logfile rather than the default Robust.log. If you don't specify this switch then you may see errors on the console about a locked log file.
At this point you should have two running Robust.exe instances.
If you put the ROBUST instances on different machines then don't forget to change the relevant service URIs in each simulator to match.
Since OpenSimulator services are stateless (e.g. every request is unconnected with other requests as long as they affect the same persistent data where necessary), you can also load balance by starting more than one ROBUST instance with a copy of the same service (e.g. multiple asset services using the same database). Requests would be round-robined between the service copies using an HTTP reverse proxy implementation (e.g. nginx). See Performance#Services for more details.
Notes
Useful discussion about separating Robust instances
Attaching your sim to someone else's grid
To set up the region server (i.e., OpenSim.exe) to connect to an external grid, follow the Configuration#Step 2: Configure an OpenSim.exe to use the ROBUST services instructions above.
The grid will have already provided with the required services. In step 2 you will need to use the provided URLs for their services.
In your bin/Regions.ini file (or other region config file) you will also need to set the grid co-ordinates to your regions provided from the grid operator. See Configuring Regions for more information.
Running an OpenSimulator standalone or grid installation with Hypergrid enabled
Hypergrid is an emerging architecture supported by OpenSimulator that allows a user with an account on one standalone or grid to visit other Hypergrid-enabled standalones or grids, and for users from those grids to visit the home grid. This does not require the two installations to share a central set of data services (assets, inventory, etc.). Please see Installing and Running Hypergrid for more details.
Further notes
Troubleshooting
See Troubleshooting
Running OpenSimulator 0.6.7 to 0.7.6.1 in 64 bit Windows
NOTE: Commits 3e5bc75 and e8ca900 move these to the directory ./share/32BitLaunch as they should no longer be needed and are slated for removal from the project'
As of OpenSimulator 0.6.7 and up to release 0.7.6.1, the default physics engine for OpenSimulator was the ODE engine. This is because ODE was the most advanced physics engine plugin at the time in OpenSimulator. Unfortunately, it has the drawback in that its library is not compilable under 64-bit in Windows.
Therefore, in order to launch the region simulator under 64-bit Windows for versions 0.6.7 to 0.7.6.1 using ODE, users may need to run:
OpenSim.32BitLaunch.exe
instead of:
OpenSim.exe
An alternative is to use the basicphysics engine instead or one of the other alternative physics engines bundled with OpenSim, though all these were less functional than the ODE plugin.
From OpenSim 0.8 the default physics engine is BulletSim. '
Note About Mono
Mono and .NET have a built in threadpool. By default, OpenSimulator is instead configured to use a third-party threadpool called SmartThreadPool for many tasks, partly because of issues with early implementations of the Mono threadpool.
However, even with this setting, some other operations are carried out with the built-in threadpool. At least in some versions of Mono (chiefly prior to 2.6), the default configuration for this can cause issues with OpenSimulator - ThreadPool_Deadlocks at the mono-project website.
If this is an issue or if the threadpool runs out of available threads, then the operation of your sim will start to break in all sorts of different ways. A common symptom is the freezing of all activity upon login of a new avatar.
The MONO_THREADS_PER_CPU parameter affects the number of existing built-in threadpool worker threads below which Mono will always spawn a new thread when OpenSimulator adds a new task. This is MONO_THREADS_PER_CPU * 4. So if set to 50, the minimum number of worker threads will be 200.
Above this number, Mono will make an internal decision whether to spawn a new thread or wait for an existing thread to complete its task.
The effect of this parameter is extremely implementation dependent, and so dependent upon the version of Mono that you are using. Before 2.6 for instance, it was definitely worth setting a high MONO_THREADS_PER_CPU due to issues with the Mono thread pool. In theory, later versions of Mono should not be susceptible to this issue. Mono 2.10.8.1, for instance, has a default MONO_THREADS_PER_CPU of 1 (despite what the incorrect Mono manpage says).
However, people still report a benefit from setting MONO_THREADS_PER_CPU higher than default. The exact number depends on many factors including: the number of CPUs in your machine, what else you use that machine for, how many regions you have in your sim, how many of them are adjacent, how many scripts you have, and how many avatars you expect to serve at the same time. As a reference, Wright Plaza in OSGrid, which is running as a single region on a sim and routinely hosts meetings with 20 avatars, uses the value 125.
For example: $ export MONO_THREADS_PER_CPU=125
So if you are having problems with avatars freezing and you're hardware meets or exceeds recommended Performance requirements, then you may want to setting this environment variable.
There is a very basic program for displaying current threadpool configuration settings at https://github.com/justincc/opensimulator-tools/tree/master/analysis/threadpool-info.
All this applies to the min threadpool numbers, not the max thread numbers. OpenSimulator itself will attempt to adjust the max numbers. You can see the output from this very near the top of the OpenSim.log file.
Increasing the stack reserve level when using OpenDynamicsEngine on *nix
If you have problems using the OpenDynamicsEngine on *nix, try setting your stack reserve level higher than the default with the following command; ulimit -s 262144 Or, run the opensim-ode.sh to start up OpenSimulator.
Firewalls
Some operation systems or distributions run their own firewall by default. If you can't access to OpenSimulator from remote client, you'll need to check their settings. See Firewall Settings for details.
Legacy Configuration Information
These are some pages containing some legacy configuration information of unknown accuracy.
OpenSim 0.6.6 legacy configuration information
Additional Optional Configuration Tasks
Further configure OpenSimulator
If you've looked through OpenSim.ini.example or any other of the config files, you'll see that there's a very large number of configurable parameters spread across multiple files. See Configuring Simulator Parameters for more details about the configuration infrastructure and how settings in identically named sections (e.g. [XEngine]) are merged by OpenSimulator on loading.
Set up a second region to run on the same simulator
See Configuring Regions.
Run Multiple Standalone Instances of OpenSimulator on the Same Server
For each subsequent instance of OpenSim, change the 'http_listener_port' in OpenSim.ini to the value excluding 9000, and 'InternalPort' in Regions.ini to the value excluding 9000. Also, make sure your regions are using different ports, as explained in Configuring Regions.
Load region content
You can load content onto regions by using the load oar command. To load individual OAR files into each region, use the 'change region [regionname]' command and then 'load oar [oar-location]'.
OpenSim.exe command line options
OpenSim.exe has command line options which allow you to perform actions such as reading configuration files from a different directory. See OpenSim.exe Command Line Options for more details.
Script engine
OpenSimulator supports multiple script engines. See ScriptEngines for details. If you don't know what this means then the default script engine will be fine. In fact, recent versions of OpenSimulator only ship with one script engine, the XEngine.
Permissions Configuration
OpenSimulator has a quite elaborate set of permissions. See Permissions (Server) for details. By default, permissions are active on region simulators.
Logging
By default, OpenSimulator logs information to a file called OpenSim.log in the bin directory. See Logging for details on how to further configure this if required.
FSAsset Service
By default the OpenSimulator asset service will store assets in the robust database. If you expect your asset data to grow larger than 50Gb you should consider changing to the FSAssets Service. (FSAssets is a new service and is currently only available in the latest development branch)
Set up other optional modules
- IRCBridgeModule
- Freeswitch Module
- Offline Messaging
- Enabling Groups
- See also User_Documentation#Setup
Configuration of Web Server and Pages
OpenSimulator contains a web server that can serve up a variety of pages. Some which come from external files and some are generated internally.
Where to go from here
- NAT Loopback Routers Router and Nat Loopback Information
- Upgrading from an old OpenSimulator version to a newer one.
- Configuring_Simulator_Parameters cascading configuration structure, environment variables
- Server Commands for creating users and controlling the system.
- Fix the bent knees bug: FAQ#Why are my knees bent when I stand idle.3F