Configuration/fr
From OpenSimulator
 |
Languages: |
|
Fichier de configuration d'un simulateur OpenSimulator
La configuration des régions du simulateur est gérée en utilisant un fichier appellé OpenSim.ini. Ce fichier est utilisé dans tous les cas, que le simulateur soit exécuté en mode grid ou standalone. Ce fichier fait référence à quelques configurations additionnelles depuis le dossier config-include/. Les informations sur les différents réglages se trouvent dans le fichier OpenSim.ini. (ou OpenSim.ini.example pour référence).
SVP notez que le nom OpenSim.ini peut être changé depuis les command line arguments.
Il est aussi possible de distribuer les reglages du fichier ini dans deux fichiers. Ceci est utile si vous voulez lancer plusieurs processus OpenSimulator quand la plupart de vos réglages sont identiques sauf pour quelques uns. Le fichier maître est lu puis le fichier ini est lu. Les reglages définis dans le fichier ini écrasent les réglages du fichier maître. Le fichier maître possède le même format et mêmes mots clefs que le fichier ini donc la même documentation y fait référence.
Base de données
Opensim supporte les moteurs de base de données suivants. Les informations sur les réglages peuvent être trouvés dans le fichier OpenSim.ini.example et les autres example du dossier bin/config-include. Si vous ne voulez pas utiliser la configuration par défaut en SQLite alors vous devrez configurer d'abord votre base de données avant d'aller plus loin. SQLite ne requiert pas de configuration supplémentaire. Voir Database Settings pour plus de détails.
- SQLite (par defaut) - base de données légère fournie avec OpenSimulator et pouvant être utilisée sans avoir besoin de configuration supplémentaire. Elle est surtout fournie pour vous permettre de rapidement faire vos premiers pas mais pas en mode de production. Elle est vraiment plus lente que MySQL. Quelques options (comme la persistance des attachements) n'ont pas été pleinement implémentées.
- MySQL (pleinement supportée) - C'est la base de données recommandée pour toute utilisation dépassant l'expérimentation ou de petites installations en standalone. La version minimale requise de MySQL est 5.1.
- Windows x64 systems: Il y a actuellement un bug non résolu bug_id=5294 trouvé en utilisant OpenSimulator avec MySQL 5.5 sur les systemes Windows x64.
- Opensim 0.7.0.2: Quelques utilisateurs ont reporté des problèmes avec MySQL 5.1.55 et supérieurs avec Opensim 0.7.0.2, voir cette discussion pour plus d'informations. Le probleme peut être résolu en utilisant une version mise à jour de MySql.Data.dll OU en installant une version plus ancienne de MySQL telle que MySQL 5.1.52 avec OpenSimulator version 0.7.0.2.
- MSSQL (également supportée) - le support de la persistance pour certaines fonctionnalités récentes de OpenSimulator peuvent ne pas avoir été implémentées cependant la plupart d'entre elles sont supportées.
Standalone contre. Grid
Nous vous recommandons de d'abord faire tourner OpenSimulator en mode standalone avant que vous assayiez de le connecter à une grille ou lancer votre propre grille. Sur les distributions binaires, OpenSimulator démarrera en mode standalone par défaut.
Une configuration de OpenSimulator consite en régions (lancées par des simulateurs de régions) et en de données tierces (comme les utilisateurs, les assets et la gestion de l'inventaire).
Un systeme lancé en mode standalone lance les régions du simulateur et tous les services de données tierces dans un processus unique quand vous lancez OpenSim.exe. Dans ce mode vous pouvez lancer autant de régions que vous voulez mais seulement sur une seule machine.
En mode grid, les services de données ne font pas partie du processus serveur de région. Au lieu de cela, ils sont lancés dans un exécutable séparé nommé Robust.exe. Une session Robust peut exécuter tous les services ou bien ils peuvent être séparés en plusieurs instances de Robust. Ceci les autorise à être exécutés sur des machines complètement différentes si nécéssaire. Dans ce mode, OpenSim.exe agit seulement en tant que serveur de régions, fournissant une ou plusieurs régions qui communiquent avec les services de données séparés. A cette étape, vous pouvez lancer plusieurs simulateurs de régions OpenSim.exe sur différentes machines.
Exécuter en mode grid est plus compliqué qu'en mode standalone. Ceci requiert une compréhension des UUID, emplacements X,Y, échanges entre les serveurs, mots de passe, estates et estates owners et quelques autres réglages. Ceux ci requierent plus d'attention et de patience à configurer. Nous recommandons énormément de ne pas tenter cela tant que vous n'êtes pas extrèmement patient(e) et tres chevronné(e) techniquement.
Exécuter OpenSimulator en mode Standalone
Les distributions binaires de OpenSimulator sont configurées par défaut pour être exécutées en mode standalone.
Cependant, si vous compilez OpenSimulator depuis les sources ou depuis le dépot git alors vous aurez besoin de:
- Aller dans le dossier bin
- Copier le fichier OpenSim.ini.example vers OpenSim.ini. Ceci configure le simulateur 3D en lui même.
- Aller dans le dossier bin/config-include
- Copier le fichier StandaloneCommon.ini.example vers StandaloneCommon.ini. Ceci configure les services internes de données utilisés par la configuration en standalone.
- Dans la section [Architecture] de OpenSim.ini, vers le bas du fichier, décommenter la ligne Standalone.ini. Pour décommenter une ligne de code, retirez le point virgule (;) précédant la ligne qui devient:
Include-Architecture = "config-include/Standalone.ini"
Exécuter OpenSimulator revient juste à lancer OpenSim.exe. Cependant vous devez avoir installé toutes les dépendances avant cela. Voir Dependencies pour plus de détails. Apres cela, ouvrez une ligne de commande (pour les utilisateurs de windows, menu démarrer > exécuter > cmd) et naviguez vers le dossier bin de OpenSimulator.
Sur Windows 32-bit:
OpenSim.exe
Sur Windows 64-bit, ODE ne peut pas encore être compilé pour le mode 64 bits, donc si vous utilisez le plugin de physique par défaut qui est ODE, exécutez :
OpenSim.32BitLaunch.exe
Sur Linux:
mono OpenSim.exe
Ceci peut être fait en 32 ou 64 bits avec le moteur de physique ODE.
Lancer OpenSimulator pour la première fois
Si vous lancez OpenSimulator pour la première fois, il va vous poser plusieurs question dans la console qui va configurer une seule région pour vous. Les options de configuration que vous entrez seront écrites dans le fichier bin/Regions/Regions.ini que vous pouvez ensuite éditer ultérieurement si vous avez besoin de faire des changements.
La plupart des questions ont des valeurs par défaut. Voici quelques explications des questions posées:
- New region name
- Le nom de votre région. Ne pas laisser vide!
- Region UUID
- L'UUID unique de votre région. Dans la plupart des cas, vous accepterez d'utiliser celui par défaut généré aléatoirement entre crochets. La seule fois quand vous ne voudrez pas le faire sera quand vous essaierez de définir une configuration pour des données de région spécifiques. Mais dans ce cas, vous feriez alors mieux d'editer directement le fichier Regions.ini.
- Region Location
- Ceci est l'emplacement de la région sur la grille. En mode standalone vous pouvez sans crainte laisser ces valeurs par défaut (1000,1000). Si vous souhaitez ensuite ajouter des régions additionnelles dans le Regions.ini alors elles doivent avoir des coordonnées de grille différentes (ex: 1000,1001). Les régions OpenSimulator peuvent être placées n'importe où sur une grille de 65536 par 65536 mais les régions Hypergrid ont besoin d'une attention spécifique concernant l'emplacement de la région. Voir Installing and Running Hypergrid#The 4096 Regions Limit pour plus d'informations.
- Internal IP address
- Dans virtuellement tous les cas, cette option peut être laissée sur 0.0.0.0 (c'est un joker qui autorise OpenSimulator à écouter les connexions UDP sur n'importe quelle interface réseau). Si vous voulez restreindre les connexions UDP à seulement une interface réseau alors vous pouvez spécifier une adresse IP. Cette adresse est seulement utilisée en interne - l'option External host name est celle qui est passée au client (et donc la plus importante)
- Internal port
- Ceci est le port IP pour toutes les connexions de client. Le nom est un peu trompeur car il sera utilisé en externe (par un client Second Life par exemple) autant qu'en interne. Vous pouvez choisir le port que vous voulez mais il est plus sûr de laisser celui par défaut qui est 9000. Chaque région sur votre serveur doit avoir un port unique.
- Allow alternate ports
- Ceci est actuellement expérimental. SVP laissez le par defaut ou bien False.
- External host name
- Si vous laissez cette option par défaut 'SYSTEMIP' alors ceci deviendra l'adresse de réseau local LAN de votre machine (ex: 192.168.1.2). C'est suffisant si vous vous connectez seulement depuis votre réseau local. Si vous voulez vous connectez depuis un client sur internet alors cette option doit contenir l'adresse IP externe de votre routeur. Des Fully Qualified Domain Names (FQDNs) peuvent aussi être utilisés sachant qu'ils seront convertis en adresse IP numérique avant d'être envoyés au client.
Les détails suivants sont aussi demandés dans les versions 0.6.9 et précédentes de OpenSimulator.
- Master Avatar UUID
- Ceci est une ancienne fonction de OpenSimulator qui peut être laissée par défaut : 00000000-0000-0000-0000-000000000000. Plus tard, vous pourriez vouloir changer cette valeur pour mettre votre propre UUID d'avatar dans le fichier Regions.ini directement si vous avez des problemes pour éditer le terrain.
- Master Avatar first name
- Ceci est une façon alternative de spécifier l'avatar maître par un nom plutot que son UUID. Si vous pressez entrée içi, le prénom et nom resteront vide. Acceptant que la valeur par défaut soit bonne - ceci peut toujours être changé plus tard dans le fichier Regions.ini.
- Master Avatar last name
- Le nom de famille de l'avatar maître.
- Master Avatar sandbox password
- Le mot de passe de l'avatar maître.
Dans OpenSimulator 0.7 et supérieur, OpenSimulator vous demandera d'assigner chaque région à un estate pendant le processus de configuration. Si un estate a besoin d'être créé alors il vous demandera aussi d'assigner un estate manager. En mode standalone, un estate manger peut aussi être créé durant le processus de configuration.
N'oubliez pas les détails du compte que vous avez entrés pour l'avatar maître (dans 0.6.9) ou l'estate manager (dans 0.7 et supérieur). Seulement cet utilisateur sera capable de configurer les réglages inworld pour cette région. C'est aussi un compte utilisateur que vous pouvez utiliser pour effectuer vos tests de connexion initiaux.
Voir Configuring Regions pour plus d'information sur le fichier Regions.ini généré par ces questions.
Si vous voulez créer un utilisateur autre que l'estate manager, vous pouvez alors taper dans la console:
create user
Ceci va vous poser une série de questions pour créer un utilisateur (comme le prénom, le nom et mot de passe).
Acces réseau pour l'installation en standalone
En mode standalone, un client se connectant à votre installation a besoin des accès réseau suivant pour accéder à votre machine contenant l'installation.
1. TCP sur le http_listener_port utilisé par votre simulateur. Ceci est défini dans la section [Network] de votre OpenSim.ini.
[Network] http_listener_port = 9000
La valeur par défaut est 9000 si vous ne l'avez pas changée.
2. UDP sur tous les ports de chaque région définis par InternalPort comme configuré dans vos fichiers de région (comme Regions.ini) Par exemple, si vous avez configuré
[test] RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c81 Location = 1000,1000 InternalAddress = 0.0.0.0 InternalPort = 9000 AllowAlternatePorts = False ExternalHostName = mygrid.com [test2] RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c82 Location = 1000,1001 InternalAddress = 0.0.0.0 InternalPort = 9001 AllowAlternatePorts = False ExternalHostName = mygrid.com
alors vous aurez besoin d'ouvrir les ports 9000 et 9001 au traffic UDP.
3. Les adresses réseau de la machine hébergeant l'installation de OpenSimulator doit être accessible aux client se connectant. Dans l'exemple ci dessus, la machine de l'installation est accessible depuis internet par le nom de domaine "mygrid.com". Si la même installation a besoin d'être accédée par des clients sur le même réseau, il leur doit être possible de résoudre ce nom de domaine (pas tous les routeurs, spécifiquement les routeurs grand public possèdent cette fonctionnalité de "loopback").
Si l'installation a seulement besoin d'être accessible depuis le même LAN alors vous pouvez utiliser l'adresse IP locale du serveur (ex: 192.168.1.2).
Se connecter à une installation en standalone
Pour se connecter à votre nouveau simulateur avec votre utilisateur, démarrez un client Second Life avec les options de ligne de commande suivantes : Client sur la même machine que OpenSim:
-loginuri http://127.0.0.1:9000
Client sur le même LAN que OpenSim:
-loginuri http://lan_ip:9000
Client sur une machine differente ou internet:
-loginuri http://external_ip:9000
Ensuite, entrez le nom d'utilisateur et mot de passe défini précédemment et votre utilisateur devrait se connecter.
Mefiez vous des problemes de loopback en lancant le client et serveur(s) sur la même machine en utilisant la configuration "external". (Vous devriez noter un "waiting for region handshake" infini.) Voir aussi troubleshoot hints. Si vous avez des problemes de connectivité réseau, assurez vous de bien lire la page sur le réseau. C'est important si vous avez des problemes de "Region handshake".
Running OpenSimulator in Grid mode
 NOTE: 0.7 est la première version de OpenSimulator qui migre entièrement tous les services vers le shell serveur ROBUST. OpenSim.Grid.UserServer.exe et MessageServer.exe de OpenSimulator 0.6.9 ne sont plus nécéssaires. SVP voir 0.7 release notes pour plus de détails. Pour les détails sur comment définir les services de grille dans OpenSimulator 0.6.9 et versions précédentes, voir OpenSim 0.6.9 Grid Mode Configuration |
Exécuter OpenSimulator en mode grid est considérablement plus compliqué que de lancer une instance en standalone. A la place de lancer tout dans le même processus, les services de données tierces (asset, inventory, etc...) sont exécutés sur un ou plusieurs processus, souvent sur des machines différentes. Ceci permet à plusieurs instances OpenSim.exe d'utiliser les mêmes données d'asset et d'inventaire.
Etape 1: Configurer une instance de services ROBUST
1. Dans le dossier bin, copier le fichier Robust.ini.example vers Robust.ini. Le fichier exemple est configuré pour exécuter tous les services dans une seule instance ROBUST.
2. Configurer les Database Settings dans Robust.ini pour utiliser une base de données MySQL. Seul MySQL est supporté pour exécuter les services de grille.
3. Lancer Robust.exe.
mono Robust.exe (Linux, BSD, Mac OS X)
ou
Robust.exe (Windows)
Si vous ne voyez pas d'erreur (en rouge) sur la console, alors vous pouvez aller à l'étape suivante.
4. Chaque région doit appartenir à un estate et chaque estate doit avoir un owner qui est un compte utilisateur valide sur le service de comptes de OpenSimulator. Créer un utilisateur sur la console de ROBUST avec la commande suivante :
create user
Ceci vous demandera son nom, son mot de passe et le mail optionnel. Souvenez vous de ce nom car vous en aurez besoin lors que vous lancerez un simulateur pour la premiere fois.
Etape 2: Configurer OpenSim.exe pour utiliser les services ROBUST
Dans le mode grid, comme en mode standalone, vous aurez besoin de configurer OpenSim.ini qui contrôle le simulateur en lui même.
Cependant, au lieu d'utiliser et configurer le fichier config-include/StandaloneCommon.ini, un simulateur se connectant à une grille a besoin d'utiliser le fichier config-include/GridCommon.ini qui doit aussi être configuré dans le but de se connecter aux services de données de ROBUST hébergés à distance plutot que les processus internes locaux.
Les étapes pour ces deux opérations sont comme suit :
1. Copier bin/OpenSim.ini.example vers OpenSim.ini
2. Trouver la section [Architecture] tout en bas du fichier OpenSim.ini. Soyez sûr(e) qu'une seule de ces lignes soit décommentée:
Include-Architecture = "config-include/Grid.ini" (dans OpenSimulator 0.7.1 et supérieur)
ou
Include-Grid = "config-include/Grid.ini" (dans OpenSimulator 0.7.0.2 et précédent)
Les autres devraient rester commentées.
3. Aller dans bin/config-include et copier GridCommon.ini.example vers GridCommon.ini.
4. Ouvrir GridCommon.ini dans un éditeur de texte. Vous verrez alors beaucoup d'entrées URL qui ont chacune des exemples par défaut comme http://myassetserver.com:8003, http://myinventoryserver.com:8003, etc. Vous devrez changer chacune pour pointer vers vos adresses d'instances ROBUST. Par exemple, si vous exécutez ROBUST sur une machine avec une adresse IP locale de 192.168.1.2 vous vous devrez alors changer l'adresse de AssetServerURI vers:
AssetServerURI = "http://192.168.1.2:8003"
5. Lancer OpenSim.exe. Si vous exécutez OpenSim.exe pour la première fois vous aurez les mêmes question sur la configuration de la région qui apparait la premiere fois en mode standalone. SVP voir la section standalone pour les instructions répondant à ceci ou lisez plus d'informations sur le fichier Regions.ini sur la page Configuring Regions.
Si tout est configuré correctement, au lancement de OpenSim.exe vous ne devriez pas voir d'erreurs. Vous devriez aussi voir la console ROBUST afficher des lignes d'historique dire que la région a été enregistrée par le grid service. Par exemple :
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
Acces réseau pour une installation de grille
En mode standalone, un client se connectant à votre installation a besoin d'accéder à :
- Le service de login par TCP et autres services publics configurés (grid info, map).
- Le port http_server_port par TCP de chaque simulateur configuré.
- Le InternalPort et ExternalHostName de chaque région configurée.
Les deux dernieres exigences sont les mêmes que pour les installations en standalone, excepté qu'elles s'appliquent à chaque serveur hébergeant un simulateur. SVP voir la section standalone pour plus de détails.
Le service login est un peu différent. The login service is a little different. Alors qu'en standalone il utilise le même port http_server_port que le simulateur lui même, en mode grille il est exécuté par un service ROBUST séparé.
Le port par défaut du service de login est 8002. Vous pouvez le voir utilisé dans la section [ServiceList] de 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"
Içi se trouvent tous les services publics (ceux vers lesquels le client se connecte directement au service) ecoutant sur le port 8002 avec les services internes sur le 8003. Alors vous devez vous assurer que le client puisse accéder au port 8002 par TCP mais vous ne voulez pas exposer le port 8003. Seuls les simulateurs devraient être capables de se connecter par le port 8003.
Se connecter à une installation de grille
Votre ligne de lancement de votre client ressemblera à ceci :
-loginuri http://mygrid.com:8002
La loginuri doit être l'adresse du service de login. En mode standalone c'etait la même adresse que le simulateur de région et le port était 9000 par défaut. Cependant en mode grid ceci sera l'adresse du service de login hébergé par l'instance de ROBUST. Dans ce cas, l'adresse sera 192.168.1.2. Le numéro de port de 8002 est le port traditionnel pour le service de login de grille et est celui par défaut dans Robust.ini.example.
Si le login se passe bien vous pourrez voir les lignes de la console de ROBUST concernant la connexion puis voir les lignes dans la console du simulateur de région (le processus de connexion demande au simulateur de se preparer à recevoir un avatar, dis au client l'adresse du simulateur de région puis le client commence à parler directement au simulateur.)
Exécuter plusieurs instances de services ROBUST
Si vous gérez une grille alors vous pouvez exécuter différents services (ex: asset, inventory) dans des instances différentes de ROBUST dans le but de répartir la charge. Pour faire cela, vous devez éditer le parametre de ServiceConnectors dans la section [Startup] de Robust.ini (ou Robust.HG.ini si vous utilisez Hypergrid). Les parametres de ServiceConnectors par defaut ressemblent à cela :
[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"
Chaque entrée est sous la forme :
<port-number>/<dll>:<connector-class-name>
Par exemple, la première entrée au dessus
8003/OpenSim.Server.Handlers.dll:AssetServiceConnector
dit de démarrer un AssetServiceConnector (et par conséquent un service d' asset) depuis OpenSim.Server.Handlers.dll et servir cela sur le port 8003.
Par défaut, Robust.exe charge un fichier de configuration avec le même nom mais avec .ini à la fin à la place de .exe. Alors Robust.exe va chercher le fichier ini appellé Robust.ini. Vous pouvez changer cela en lui donnant un parametre dans la ligne de commande. Par exemple, pour démarrer Robust avec les parametres HG, on devrait utiliser :
Robust.exe -inifile=Robust.HG.ini
Donc si vous voulez lancer chaque connecteur séparément des assets dans une seule instance de ROBUST et le connector d'assets dans une autre instance, vous devriez avoir deux fichiers ini. Un pourrait être nommé Robust.ini possédant :
[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"
L'autre pourrait être appellé Robust.Assets.ini et posséder :
[ServiceList] AssetServiceConnector = "8004/OpenSim.Server.Handlers.dll:AssetServiceConnector"
Noter qu'il utiliser le port 8004 au lieu de 8003. Ceci est nécéssaire car un seul exécutable peut utiliser un port à la fois. Vous devez vous assurer que votre configuration de simulateur utilise le port 8004 pour le service d'assets bien sûr.
Vous devrez aussi changer le port par défaut vers 8004 pour cette seconde copie de Robust.exe
[Network] port = 8004
Une fois que vous avez créé les deux fichiers de configuration de ROBUST (Robust.ini contenant tous les services autres que asset et Robust.Assets.ini contenant seulement le service d'assets) alors vous pouvez démarrer le premier Robust.exe comme d'habitude.
Robust.exe
Ceci va charger Robust.ini car nous n'avons pas spécifié de Robust.ini. Aussi le fichier de log qui sera utilisé sera Robust.log comme nous n'en avons pas spécifié un.
La seconde instance de ROBUST devrait être démarée par
Robust.exe -inifile=Robust.Assets.ini -logfile=Robust.Assets.log
Le parametre -inifile dit à la seconde instance de Robust de charger sa configuration depuis Robust.Assets.ini plutot que Robust.ini. Le parametre -logfile dit à Robust.exe d'utiliser Robust.Assets.log en tant que fichier de log plutot que Robust.log par défaut. Si vous ne spécifiez pas ce parametre vous devriez alors voir des erreurs en console à propos d'un fichier de log verrouillé.
A ce moment là vous devriez avoir deux instances de Robust.exe en cours d'exécution.
Si vous posez des instances de ROBUST sur différentes machines, alors n'oubliez pas de changer les URI des services correspondantes dans chaque simulateur.
Depuis que les services de OpenSimulator sont séparés (chaque requete est déconnectée des autres requetes tant qu'elle n'affecte pas la même donnée persistante quand nécéssaire) vous pouvez alors répartir la charge en démarrant une instance de ROBUST avec une copie du même service (ex: plusieurs services d'assets utilisant la même base de données). Les requetes peuvent utiliser du round robin entre les copies de services avec une implémentation reverse proxy http (nginx). Voir Performance#Services pour plus de détails.
Notes
Discussion intéréssante sur la séparation d'instances ROBUST
Attacher votre sim à une grille de quelqu'un d'autre
Pour définir un serveur de région (ex: OpenSim.exe) afin de se connecter à une grille externe, suivre les données citées précédemment Configuration/fr#Etape 2: Configurer OpenSim.exe pour utiliser les services ROBUST.
La grille aura déjà fourni des services requis. Dans l'étape 2 vous aurez besoin d'utiliser les URL fournies pour ses services.
Dans votre fichier bin/Regions.ini (ou un autre fichier de config de région) vous devrez alors avoir besoin de définir les coordonnées de région fournies par le gestionnaire de la grille. Voir Configuring Regions pour plus d'informations.
Exécuter une installation d'OpenSimulator en standalone ou grid avec Hypergrid activé
Hypergrid est une architecture émergeante supportée par OpenSimulator qui autorise un utilisateur avec un compte sur une standalone ou une grille de visiter d'autres standalones ou grilles compatibles hypergrid tout en permettant aux utilisateurs de chaque grille de visiter la sienne. Ceci ne requiert pas les deux installations pour partager des services de données (assets, inventory, etc...). SVP voir Installing and Running Hypergrid pour plus de détails.
Notes supplémentaires
Dépannage
Voir Troubleshooting
Exécuter OpenSimulator 0.6.7 à 0.7.6.1 en 64 bit Windows
NOTE: Commits 3e5bc75 et e8ca900 ont déplacé ce fichier vers le dossier ./share/32BitLaunch car ils ne devraient plus être nécéssaires et sont voués à disparaitre du projet'
Depuis OpenSimulator 0.6.7 et jusqu'à la release 0.7.6.1, le moteur physique par défaut a été défini comme étant le moteur ODE. Ceci car ODE etait le plugin de physique le plus avancé à cette époque. Malheureusement il y eut l'inconvénient que cette librairie n'etait pas compilable en 64 bits sous Windows.
Cependant, afin de pouvoir lancer un simulateur de régions sous Windows 64bits pour les versions 0.6.7 à 0.7.6.1 utilisant ODE, les utilisateurs avaient besoin de lancer:
OpenSim.32BitLaunch.exe
au lieu de:
OpenSim.exe
Une alternative est d'utiliser le basicphysics engine à la place ou bien une des autres alternatives de moteurs de physique fournis avec OpenSimulator. Cependant, tous étaient moins fonctionnels que ODE.
Depuis OpenSimulator 0.8 le moteur de physique par défaut est BulletSim.
Note à propos de Mono
Mono et .NET possèdent leur propre threadpool. Par défaut, OpenSimulator est configuré pour utiliser un threadpool différent appellé SmartThreadPool pour plusieurs tâches partiellement à cause de problèmes avec les implémentations récentes du threadpool de Mono.
Cependant meme avec ce reglage certaines opérations sont opérées avec le threadpool intégré. Au moins, dans certaines versions de mono (surtout celles avant 2.6), alors la configuration par defaut peut causer des problemes avec OpenSimulator - ThreadPool_Deadlocks at the mono-project website.
Si c'est un probleme ou si la threadpool s'exécute en dehors des threads disponibles alors le fonctionnement de votre simulateur commencera à s'effriter de toutes parts. Un symptome commun est le gel de toute activité lors de la connexion d'un avatar.
Le parametre MONO_THREADS_PER_CPU affecte le nombre de workers des threadpools internes existantes en dessous desquels Mono génèrera un nouveau thread quand OpenSimulator ajoute une nouvelle tâche. C'est MONO_THREADS_PER_CPU * 4. Donc si défini sur 50, le nombre minimum de workers sera de 200.
Au dessus de ce nombre, Mono fera une décision en interne qui est soit de générer un nouveau thread, ou attendre qu'un thread existant complete sa tâche.
L'effet de ce parametre est extremement dépendant de chaque implémentation et dépendant des versions de Mono que vous utilisez. Avant 2.6 par exemple, il etait définitivement meilleur de définir un MONO_THREADS_PER_CPU à cause de problemes avec le thread pool de Mono. En théorie, les versions suivantes de Mono ne sont pas susceptibles d'avoir ce problème. Mono 2.10.8.1, par exemple a une valeur par defaut de MONO_THREADS_PER_CPU de 1 (malgré ce que dit la page erronée de la doc de Mono).
Cependant, les gens reportent un bénéfice en définissant MONO_THREADS_PER_CPU plus grand que par défaut. Le nombre exact dépend de plusieurs facteurs incluant : le nombre de CPU dans votre machine, pour quoi d'autre utilisez vous votre machine, combien de regions avez vous sur votre simulateur, combien d'entre elles sont adjacentes, combien de scripts avez vous, et combien d'avatar vous attendez vous à accueillir en même temps. Comme référence, Wright Plaza sur OSGrid qui est exécutée sur un simulateur avec une seule région et frequemment héberge des réunions de 20 avatars utilise la valeur de 125.
Par exemple: $ export MONO_THREADS_PER_CPU=125
Donc si vous avez des problemes avec des avatars gelés et que votre hardware respecte bien les recommandations Performance, alors vous devriez définir cette variable d'environnement.
Il y a un programme tres basique pour afficher les réglages actuels de la configuration des threadpools sur https://github.com/justincc/opensimulator-tools/tree/master/analysis/threadpool-info.
Tout ceci s'applique aux nombres de threadpools minimums, pas la quantité maximale de threads. OpenSimulator lui même tente d'ajuster la quantité maximale. Vous pouvez voir la sortie de ceci pres du début du fichier OpenSim.log.
Augmenter le stack reserve level en utilisant OpenDynamicsEngine on *nix
Si vous avez des problemes en utilisant le OpenDynamicsEngine sous *nix, essayez de définir votre stack reserve level plus grand que celui par défaut avec la commande suivante: ulimit -s 262144 Ou, lancez opensim-ode.sh pour démarrer OpenSimulator.
Pare feux
Certaines systemes ou distributions utilisent leur propre pare feu par défaut. Si vous ne pouvez pas accéder à OpenSimulator depuis un client distant, vous aurez besoin de vérifier leurs réglages. Voir Firewall Settings pour plus de détails.
Information de configuration sur les versions précédentes
Il y a certaines pages contenant quelques informations sur les versions précédentes.
OpenSim 0.6.6 legacy configuration information
Tâches additionnelles optionnelles de configuration
Aller plus loin dans la configuration de OpenSimulator
Si vous avez regardé à travers OpenSim.ini.example ou n'importe quel autre fichier de config vous verrez qu'il y a un nombre tres large de parametres configurables éclatés dans les fichiers multiples. Voir Configuring Simulator Parameters pour plus de détails à propos de l'infrastructure de configuration et comment les reglages des sections nommées identiques (ex: [XEngine] sont mergées par OpenSimulator au lancement.
Configurer une seconde région à lancer sur le même simulateur
Voir Configuring Regions.
Lancer plusieurs instances de OpenSimulator en standalone sur le même serveur
Pour chaque instance consécutive de OpenSimulator, changer le 'http_listener_port' dans OpenSim.ini à une valeur excluant 9000 et 'InternalPort' dans Regions.ini à une valeur excluant 9000. Verifier aussi que vos régions utilisent des ports différents comme expliqué dans Configuring Regions.
Charger du contenu de région
Vous pouvez charger du contenu dans les régions en utilisant la commande load oar. Pour charger des fichiers OAR individuellement dans chaque région, utiliser la commande 'change region [nomdelaregion]' puis 'load oar [emplacement-oar]'.
options de ligne de commande de OpenSim.exe
OpenSim.exe possède des options de ligne de commande qui vous permettent d'effectuer des actions comme lire les fichiers de configuration depuis un autre dossier. Voir OpenSim.exe Command Line Options pour plus de détails.
Moteur de script
OpenSimulator supporte plusieurs moteurs de script. Voir ScriptEngines pour les details. Si vous ne savez pas ce que cela veut dire alors le moteur de scripts par défaut sera tres bien. En fait, les versions récentes de OpenSimulator sont fournies avec un seul moteur de script, le XEngine.
Configuration des permissions
OpenSimulator possede un ensemble de gestion de permissions assez élaboré. Voir Permissions (Server) pour les details. Par défaut les permissions sont actives sur les simulateurs de régions.
Historisation
Par défaut, OpenSimulator ecrit des informations dans un fichier appellé OpenSim.log dans le dossier bin. Voir Logging pour les détails sur comment configurer plus en détails.
Configurer les autres modules optionnels
- IRCBridgeModule
- Freeswitch Module
- Offline Messaging
- Enabling Groups
- Voir aussi User_Documentation#Setup
Configuration du serveur web et des pages
OpenSimulator contient un serveur web qui peut fournir une variété de pages. Certaines proviennt de fichiers externes et d'autre sont générées en interne.
où aller depuis içi
- NAT Loopback Routers Informations sur les routeurs et ne NAT loopback
- Upgrading depuis une vieille version de OpenSimulator version une plus récente.
- Server Commands pour créer des utilisateurs et contrôler le systeme.
- Fixe le bug des genoux pliés: FAQ#Why are my knees bent when I stand idle.3F
