Configuration/fr

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 Options de ligne de commande de OpenSim.exe.

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ées dans le fichier OpenSim.ini.example et les différents fichiers "example" du dossier bin/config-include. Si vous ne voulez pas utiliser la configuration par défaut avec 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(entièrement pris en charge) - C'est la base de données recommandée pour toute utilisation au-delà de l'expérimentation ou des petites applications autonomes. La version minimale de MySQL est la 5.1.


 * MariaDB(entièrement pris en charge) - Une alternative à MySQL. Vous devez vous assurer que le jeu de caractères sélectionné est utf8mb3 (c'est-à-dire 3 octets). Certaines installations sont configurées par défaut sur uft8mb4 (4 octets) et cela échouera


 * MSSQL (assez bien 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:


 * 1) Aller dans le dossier bin
 * 2) Copier le fichier OpenSim.ini.example vers OpenSim.ini. Ceci configure le simulateur 3D en lui même.
 * 3) Aller dans le dossier bin/config-include
 * 4) Copier le fichier StandaloneCommon.ini.example vers StandaloneCommon.ini. Ceci configure les services internes de données utilisés par la configuration en standalone.
 * 5) 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.

Sous Windows lancez : OpenSim.exe

Sous Linux lancez : mono OpenSim.exe

Lancer OpenSimulator pour la première fois
Si vous lancez OpenSimulator pour la première fois, il va vous poser plusieurs questions 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 qu'il ne faudra 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/fr ont besoin d'une attention spécifique concernant l'emplacement de la région. Voir Installing and Running Hypergrid 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 à 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.

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 manager 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'informations 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.

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é

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 doit être accessible par des clients sur le même réseau, ils doivent pouvoir 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 mode 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".



NOTE IMPORTANTE, DIVA DISTRO - 4 avril 2012 -
Si vous téléchargez la dernière version diva-r18611.tar.bz, tout d'abord il faudra lancer le programme de configuration configure.exe Après avoir envoyé la commande, vous pourrez définir le nom de domaine de votre sim, et répondre soigneusement aux questions du programme, puis démarrer le programme comme indiqué dans les paragraphes ci-dessus.
 * Sur Linux ou MacOSX : ouvrez un termibal et entrez "mono /diva-r18611/bin/Configure.exe" (en supposant que vous avez placé la distro Diva dans /diva-r18611)
 * Sur Windows, en supposant que Diva soit extrait dans My Documents, d'abord vous ouvrirez "Run => cmd" et entrez  'cd "%USERPROFILE%\My Documents\diva-r18611\", suivi de "Configure.exe".

Le programme va installer une configuration optimum pour OpenSim, exemple:  http://:9000  et WiFi  http::9000/wifi  En mode standalone, quatre régions seront installées. Par la suite, vous pourrez ajouter en option d'autres régions, ainsi, veuillez utiliser le même sufixe suivi d'un nombre : (ex: "region 5", "region 6", "region 7", etc. sinon, vous ne pourrez pas entrer dans la région et vous atterrirez dans l'endroit libre le plus proche.

Si vous souhaitez entrer un nom de région différent, assurez-vous que la "distance" entre l'île créée par le programme de configuration Wifi et la suivante, sera à au moins 40 positions de la première région installée) Si vous souhaitez entrer un nom de région différent, assurez-vous que la "distance" entre l'île créée par le programme de configuration Wifi et la suivante  soit au moins à 40 positions de la première région installée. (commande de console: create region Johnnyland RegionConfigure.ini)

= Utiliser OpenSimulator en mode Grid =

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 :


 * 1) au service de login par TCP et autres services publics configurés (grid info, map).
 * 2) au port http_server_port par TCP de chaque simulateur configuré.
 * 3) à 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. 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.

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

ATTENTION : C'est une question délicate et contrairement aux allégations passées, opensim n'est pas bien adapté à ce type de concepts de microservices. Vous pouvez diviser certains services sur différentes machines, s'ils n'ont pas d'interdépendances. Par exemple, XBakes actuel peut fonctionner n'importe où. Exécuter plusieurs instances d'un même service est une invitation à l'échec. Certains services partent du principe qu'ils sont la seule instance, comme les actuels PresenceService, GriduserService, etc, et font même leur propre cache pour réduire la charge sur le moteur de base de données, et ce cache ne peut pas être synchronisé entre les instances. La plupart des services n'offrent qu'un service http en parallèle, plaçant la même chose, et la plupart de la charge, sur le même moteur de base de données. Ainsi, à moins que ce service de base de données ne soit un système distribué, effectuant une mise en cache locale et une synchronisation appropriées avec une base de données principale, les gains liés à l'existence d'instances multiples ne sont pas très importants, voire inexistants, si ce n'est un échec total. Une autre chose importante à noter est qu'actuellement plusieurs services ont besoin de lire les données de la configuration d'autres services. Par exemple, Gridservice doit lire les données de sa section, GridService, et des sections LoginService, Hypergrid et GridInfoService. Donc le fichier ini de l'instance robuste qui l'exécute doit avoir ces sections, et bien sûr être mis à jour. 

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 :

Chaque entrée est sous la forme :

/ :

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 :

L'autre pourrait être appellé Robust.Assets.ini et posséder :

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 pour plus de détails.

Dépannage
Voir Troubleshooting

Exécution d'OpenSimulator en 32 bit dans Windows 64bit
Windows 64Bit peut faire tourner plusieurs instances d'OpenSim en mode 32Bit, permettant à chacune d'entre elles d'utiliser jusqu'à environ 2 Go de RAM physique totale.

C'est presque la mémoire totale disponible sur les versions 32Bit de Windows, pour tous les programmes (environ 3GB)

En mode 32Bit, le simulateur utilise moins de mémoire et peut être un peu plus rapide, donc à moins que vous n'ayez de très grandes régions, vous pouvez l'exécuter en mode 32Bit, il suffit d'exécuter :

OpenSim32.exe au lieu de OpenSim.exe

Vous pouvez également exécuter Robust en mode 32Bit :

Robust32.exe à la place de Robust.exe

Linux 64Bit ne fait fonctionner le simulateur qu'en mode 64Bit

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

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.

Service FSAsset
Par défaut, le service d'assets d'OpenSimulator stocke les assets dans la base de données de Robust. Si vous vous pensez que vos données de ressources dépasseront 50 Go, vous devriez envisager de passer au service FSAssets.

Configurer les autres modules optionnels

 * IRCBridgeModule
 * Freeswitch Module
 * Offline Messaging
 * Enabling Groups
 * Voir aussi User_Documentation

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.
 * External Files
 * Internally Generated

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


 * Configuring_Simulator_Parameters structure de configuration en cascade, variables d'environnement


 * Server Commands pour créer des utilisateurs et contrôler le système.

= References =


 * Fichier du dessin OpenOffice du schéma d'OpenSimulator en mode standalone
 * Fichier du dessin OpenOffice du schéma d'OpenSimulator en mode grille