(Testprojekt) Aufräumen in den Konfigurationsdateien

13

Comments

  • Pius Noel
    Pius Noel
     Member
    Hallo Mareta,

    zu Frage 1: ich hatte PostgreSQL vor längerer Zeit mal benutzt, aber nach diversen Problemen wieder aufgegeben. Ich denke, wer es unbedingt benutzen will hat genügend gute Kenntnisse um es wieder in seine .ini Files aufzunehmen.

    zu Frage2: ich finde auch, dass EstateConnectionString weg kann. Ich benutze mehrere Simulatoren, aber ich sehe das auch eher als Sonderfall und hatte bisher trotzdem für die Estates noch nie eine eigene Datenbank angelegt. 

    zu Frage3: kann aus meiner Sicht weg.

    Bis jetzt finde ich deine Vorschläge, insbesondere in Ergänzung mit den Anmerkungen von Eryn Galen, alle recht gut. Soweit ich das sehe, kann ich bis auf den nachstehenden Sonderfall alles ohne weitere Anpassung übernehmen.

    Da bei mir seit der Umstellung von Metropolis jede Region unter einer eigenen Simulator-Instanz läuft und auf Ausfall überwacht wird, ist bei mir "InworldRestartShutsDown = true" gesetzt. Dies ermöglich bei einem Restart der Region den Simulator vollständig neu zu starten. Auch das ist ein Sonderfall, der ohnehin weiterreichende Kenntnisse erfordert.

    /Pius 
    Thanked by: Mareta Dagostino
  • Eryn Galen
    Eryn Galen
     Member edited May 7
    Huhu Mareta,

    Groups so ok. Einzig die Variable:

        MessageOnlineUsersOnly = true
    finde ich seltsam. Ist die wirklich in der ini so gesetzt? Dann würde ich vermuten, dass Offine Messages gar nicht funktionieren und das halte ich für eine unrichtige Grundeinstellung, denn es hat sich gezeigt, dass nur bei ganz großen Gruppen wirklich Performance-Probleme auftauchen, deshalb würde ich für eine Beispieldatei immer "= false" setzen wollen, aber die Umschaltversion z.B. für Clubs, etc. lassen.

    Für NPC: Die Option "; AllowCloneOtherAvatars = true" kann zum Kopieren ganzer Avatare herangezogen werden. Ich persönlich schalte die immer aus, um Mißbrauch zu vermeiden. Sonst einverstanden.

    Ein Anwendungsbeispiel für die Architektur "Grid.ini" ist z.B. eine private Sandbox, auf die man zwar ggf. mal Freunde einlädt, die aber nicht direkt aus dem HG angesprungen werden soll.Aber da du das ja drin lässt - habe ich so verstanden - kann man das ja immer noch ändern. Und wer das möchte, braucht in der Regel nicht viel Erklärung dazu.

    Zu deiner Frage bzgl. "EstateConnectionString" musste ich erst einmal recherchieren, da ich das noch NIE genutzt habe. Hat sich herausgestellt, das ist wohl für eine separate Datenbank im Grid Modus. Damit wird das für eine Beispieldatei für Regionsbetreiber, die an ein öffentliches Grid andocken meiner Meinung nach irrelevant.

    Und zu deiner letzten Frage: <strike>Bin gerade nicht zuhause, aber ich schaue mal, ob die angegebenen Werte in der Default stehen oder ggf. unr Metro-Typisch sind. Wenn es sie schon gibt, dann würde ich ebenfalls für eine Beispiel-Datei die Variablen weglassen.</strike>

    EDIT: Nun habe ich etwas recherchiert und folgendes gefunden:

        ; AssetCaching = "CenomeMemoryAssetCache" - Laut Opensim.org: "Flotsam is both the default cache and the only one that gets development attention". Wer einen anderen als Flotsam nutzt, möge bitte etwas sagen, sonst scheint es, dass das sowieso bald rausfliegt.

        ; Include-CenomeCache = "config-include/CenomeCache.ini" - Damit ist das auch obsolete

        ; Setup_LLProxyLoginModule = "9090/" - ist für ein eigenes Grid gedacht, kann also meiner Meinung nach raus

        ; AuthorizationServices = "RemoteAuthorizationServicesConnector" - ist für ein eigenes Grid gedacht, kann also meiner Meinung nach raus

        DefaultAssetLoader = "OpenSim.Framework.AssetLoader.Filesystem.dll"
        AssetLoaderArgs = "assets/AssetSets.xml"
    - diese beiden sind nicht auskommentiert, also keine Optionen. Ich würde denken, die Zeilen sollten lieber drin bleiben

        ; MaxRetries = 50 - Dieser Eintrag kann meines Erachtens Sinn machen bei langsamem Internet oder schlechter Verbindung. Dann würde ich das aber kommentieren, z.B. mit "Only change if continuous problems with assets are encountered" oder so...

        AllowHypergridMapSearch = true
        MapTileDirectory = "./maptiles"
    - diese beiden sind nicht auskommentiert und ich habe sie auch sonst nicht gefunden, deshalb würde ich davon ausgehen, dass sie benötigt werden.

        ; LocalServiceModule = "OpenSim.Services.Connectors.dll:EstateDataRemoteConnector"
        ; EstateServerURI = ""
    - das ist soweit ich sehe noch gar nicht implementiert "Not used yet". Für heutige Verhältnisse könnte das also raus, müsste dann nur angepasst werden, wenn es mal aktiv werden sollte

        ; OutboundPermission = True - Auf meiner Bastelsim hatte ich das auf "false" und macht meiner Meinung nach auch Sinn für Regionen, die nur zur Show sind und auf denen ggf. viele gekaufte Assets verwendet wurden, würde ich persönlich also drin lassen

        ; CheckSeparateAssets = false
        ; RegionHGAssetServerURI = ${Const|BaseURL}:${Const|PublicPort}
    - laut Kommentar für Grids gedacht, die Inventar, Presence, etc. teilen, ist also für Regionen, die an ein öffentliches Grid angehängt werden, wohl nicht relevant

        ; DisallowExport ="LSLText"
        ; DisallowImport ="LSLBytecode"
    - wie Outbound Permissions finde ich, das ist Geschmackssache. Aber das das eigentlich Grid-Variablen sind, bin ich mir gerade unsicher, ob sie im einzelnen Simulator geändert werden können.

        ; LevelHGFriends = 0; - das das auskommentiert ist, denke ich, das wird vom Grid vorgegeben und könnte raus

    [AuthorizationService].... (komplett) - Hier würde ich widersprechen. Dies kann z.B. für Rollenspiele oder private Regionen sehr nützlich sein.

    VG Eryn










    Thanked by: Mareta Dagostino
  • Manfred Aabye
    Manfred Aabye
     Member edited May 7

    Hi Mareta, mit Python kannst du direkt ini Dateien bearbeiten oder erstellen.

    Das heißt du kannst einen Konfigurator damit schreiben,

    der dir eine opensim.ini aus ausschnitten der opensimdefault.ini erstellt.

    So wie die gridcommon.ini einstellt und das für verschiedene Grid´s.

    So wird dem Benutzer nur ein paar wenige fragen gestellt

    und er muss sich nicht durch das ganze slang Gelaber durchwühlen.

    Dies ist auch nicht viel mehr aufwand als das ganze zu reduzieren.



    Thanked by: Mareta Dagostino
  • Mareta Dagostino
    Mareta Dagostino
     Member edited May 7
    Naja, es geht ja hier um die Beispieldatei, die (hoffentlich) demnächst der Metro-Edition beigefügt wird. Drei Gründe fallen mir dagegen ein, sowas automatisch zu generieren:

    1) Die "paar Fragen" würden sich auch aufsummieren, denn es gibt ja schon hier so einige optionale Sachen, die alle abgefragt werden müssten. Und wenn jemand doch noch was mehr drin haben will als ich berücksichtigt habe, würde er/sie schließlich an die generierte ini doch wieder irgendwas dran hängen müssen - und beim nächsten Lauf des Generators wieder überschreiben oder löschen. (Letzteres wäre mit geschickter Programmierung vermeidbar: Erst vorhandene Ini parsen, Änderungen des Users außerhalb des Tools identifizieren und sichern. Sowas betriebssicher zu implementieren ist nicht ganz ohne, aber machbar.)

    2) Ich hatte vor Jahren mal einen Konfigurator programmiert (zwar in einer anderen Sprache, die ich nicht wie Python erst neu lernen müsste), das hat keine Socke interessiert. Genauer: Im Forum fanden das alle Kommentatoren toll, benutzt hat das aber niemand. Es war sogar ein Fertigpaket mit OpenSim Metro-Edition und ein paar Fragen als Debian-Installer, zur Verfügung gestellt als Ubuntu PPA. Ich zumindest werde keinen Programmieraufwand mehr in ein separates Konfigurationstool stecken.

    3) Wenn sich die Einwohner untereinander helfen, kennen sie sich am ehesten mit den Ini-Dateien aus. Automatisch generierte Konfiguratinsdateien müsste dann wohl ich supporten, weil alle im Metaversum sich denken "sieht irgendwie anders aus als gewohnt" und auf mich zeigen.

    Bitte nicht persönlich nehmen Manfred, andere sehen es vielleicht anders und nehmen sowas doch in Angriff.

    Liebe Grüße,
    Mareta
    Thanked by: Pius Noel
  • Mareta Dagostino
    Mareta Dagostino
     Member
    @Pius:

    "InworldRestartShutsDown = true" setze ich bei mir auch immer und finde es wichtig genug für eine Beispieldatei. Dann kann man nämlich mal schnell inworld OpenSim durchstarten. Es ist auch bereits in meinem Vorschlag enthalten, braucht also nicht mehr ergänzt zu werden.

    Ansonsten sind deine Vorschläge eingearbeitet.

    @Eryn:

    "MessageOnlineUsersOnly = true" ist derzeit in Metro tatsächlich so gesetzt, im OSgrid steht es auf false (default). Ich habe die Settings von Metro in meinen Vorschlägen exakt übernommen, das können wir aber gerne mit den Admins diskutieren und ggf. ändern.

    * AssetLoaderArgs = "assets/AssetSets.xml"
    * DefaultAssetLoader = "OpenSim.Framework.AssetLoader.Filesystem.dll"
    * AllowHypergridMapSearch = true
    * MapTileDirectory = "./maptiles"
    Das sind Defaultwerte, obwohl sie nicht auskommentiert sind. Ich habe das sowohl im Quellcode nachgeschaut als auch selber getestet.

    "DisallowExport/DisallowImport" sehe ich skeptisch. Wie du schon erwähnst, könnte das effektiv nur gridweit verhindert werden: Selbst wenn es auf einer Region unterbunden werden könnte (was noch zu testen wäre), brauchen Besucher ja nur den Hypergridsprung von/nach einer anderen Region machen. In einer Beispieldatei hat so ein Spezialkram meiner Meinung nach nichts verloren, außer jemand liefert einen tatsächlichen Usecase.

    Ansonsten sind deine Vorschläge eingearbeitet bzw. zu [AuthorizationService] siehe folgenden Beitrag.

     Liebe Grüße,
    Mareta
  • Mareta Dagostino
    Mareta Dagostino
     Member edited May 7
    GridCommon.ini
    Eryn hat zwei optionale Parameter in der GridCommon.ini gefunden, die wohl doch unter Umständen sinnvoll sind zu setzen, hier bereits mit Kommentar-Ideen ergänzt.
        ;; Retry loading assets, default is 0.
        ;; Only change if continuous problems with assets are encountered.
        ; MaxRetries = 50

        ;; Allows Hypergrid export of objects on the region, if copy is allowed. Default is true.
        ;; Setting this to false maybe useful on regions without any vendors or copyable objects.
        ; OutboundPermission = true
    Gegenrede zu Eryns Meinung: Wegen des [AuthorizationService] möchte ich noch mal explizit nachfragen, ob das jemand wirklich tatsächlich real verwendet!
    Grund: In diesem Abschnitt kann man normalen Residents den Zugang verbieten oder Hypergriddern. Schön und gut. Normalen Residents den Zugang verbieten kann aber ein Region Owner inworld über die Accessliste sogar viel granularer. Dafür braucht keiner sich auf einem Server einloggen, in der Konsole rumeditieren und OpenSim durchstarten. Auf einzelnen Regionen Hypergrid zu verbieten wäre das einzige, wofür sich meiner Meinung nach der Aufwand lohnen könnte in der Datei rumzufrickeln. Benutzt diesen [AuthorizationService] wirklich jemand, gibt es diesen Fall irgendwo in Metro zu besichtigen?

    Frage: In derGridCommon.ini steht ganz dick mit Sternchen umrandet: "Die nachfolgenden Zeilen nicht veraendern! Do not change the following lines!" Wie gehen wir damit um, wenn wir dann unterhalb dieser Warnung optionale Einstellungen bewerben?
  • Eryn Galen
    Eryn Galen
     Member
    Hallo Mareta,

    genau deine letzte Frage habe ich mir auch gestellt. Ich würde die optionalen Dinge als Sonderoptionen über den "Bitte nicht ändern" Absatz nehmen wollen. Ich denke, wenn das steht, bitte nichts ändern, sollten dort keine Werte mehr stehen, die dazu einladen.

    VG Eryn
  • Mareta Dagostino
    Mareta Dagostino
     Member
    Die Idee hatte ich auch, dann sind wir schon zwei :) . Man darf ja die Sektionen mehrfach angeben. Wir könnten die beiden Sektionen mit den oben angegebenen optionalen Parametern aufführen, dann den Spruch "ab hier nichts ändern", und darunter eben u.a. die selben Sektionen noch mal mit den Pflichteinträgen. Dem Parser ist das egal, der sammelt nur ein.
  • Manfred Aabye
    Manfred Aabye
     Member

    Mareta

    Ich nehme das nicht persönlich, das wäre ja schrecklich, wenn andere nicht eine eigene Meinung haben dürften.


    Zu 1. Python hat einen ms ini Parser das ist ja das gute. Mit Python kannst du direkt die Konfiguration öffnen/erstellen, ändern und speichern.


    Zu 2. Wenn du wie du mal sagtest mit C# klar kommst, haste Python in 10 Minuten drin.

    Aber genauso wenig interessiert es die Leute ob du hier eine minimal Version machst, die nutzen eh die Original Metro Konfiguration.


    Zu 3. Das sehe ich immer wieder das die Einwohner sich falsch helfen und so ihren OpenSimulator instabil oder gar unbrauchbar machen.


    Fazit: Die meisten nutzen die Original Konfiguration der Grid´s, direkt an zweiter stelle kommt der Konfigurator von Diva.

    Aber egal war nur ein gut gemeinter Vorschlag.


    Das gute an dem was du hier machst ist der Lernfaktor für Beginner.


    Hier noch Diverses:


    Wenn du die osslEnable.ini änderst solltest du diese immer umbenennen, sonst ist die bei einem upgrade weg.


    Dann fehlt hier das absolut wichtigste, den Datenstrom pro Viewer begrenzen (Das ist das mindeste).

    Der Spruch „Das hier angegebene Beispiel ist 1,5 Megabit“ ist natürlich aus alten Zeiten, das doppelte kann es schon sein heutzutage.

    Hast du mehrere OpenSim Instanzen laufen solltest du diese auch begrenzen, sonst reist eine die andere bei Problemen runter.

    (siehe in der OpenSimDefaults.ini [ClientStack.LindenUDP])


  • Manfred Aabye
    Manfred Aabye
     Member

    Ich habe mir mal die OpenSim Version von der Metro Download Seite heruntergeladen.


    Dabei sah ich in der OpenSim.ini, das hier viele Einstellungen sind, die in der OpenSimDefaults.ini bereits genauso eingestellt sind.


    Dann so etwas wie ConsolePrompt rein zu nehmen und so einzustellen wie in der OpenSimDefaults.ini ist schon sehr merkwürdig, denn so etwas kann man komplett aus der OpenSim.ini löschen, das ist überflüssig da stellt niemand etwas ein (Deswegen ist das auch normal nicht vorhanden).


    Auch async_call_method, hat man so etwas ohne nachzudenken aus der 0.8.3 Version übernommen?


    Das ganze ist verwirrend für Anfänger.


    Wenn die Robust.ini genauso aussieht, ist das kein wunder das alles so lange dauert und so schlecht läuft.


  • Mareta Dagostino
    Mareta Dagostino
     Member edited May 11
    Manfred Aabye schrieb:

    ... Fazit: Die meisten nutzen die Original Konfiguration der Grid´s...

    ... sah ich in der OpenSim.ini, das hier viele Einstellungen sind, die in der OpenSimDefaults.ini bereits genauso eingestellt sind. Dann so etwas wie ConsolePrompt rein zu nehmen ... überflüssig ...
    Eine Intention dieses Forenthreads ist, die Metro-Versionen der Ini-Dateien zu verbessern. Ich hoffe schon, dass wir hier einen Konsens finden, der in die nächste Metro-Edition als Beispiel übernommen wird. Wohl niemand wird in ein paar Monaten diesen Forenthread hier ausgraben und danach die eigenen Regionen aufsetzen.
    Manfred Aabye schrieb:

    Wenn du die osslEnable.ini änderst solltest du diese immer umbenennen, sonst ist die bei einem upgrade weg
    Danke für den Hinweis, den Trick sollte ich später in meiner neuen Anleitung erwähnen. Selber bin ich da bisher nicht drauf gekommen, weil ich immer alles lösche und meine Konfig-Dateien danach erst hin kopiere. Hier würden wir ja einen Vorschlag für eine geänderte Metro-Beispieldatei diskutieren.

    Persönlich bin ich eh sehr zwiegespalten, ob man an der osslEnable.ini viel herum drehen soll. Schließlich erwarten Besucher innerhalb eines Grids ein halbwegs ähnliches Verhalten, gerade wenn sie sich gescriptete Freebies/Fahrzeuge von Region A holen und dann auf Region B laufen lassen wollen. Wir sollten da sehr vorsichtig sein mit Empfehlungen zum individuellen Herumschrauben.

    Aber die osslEnable.ini ist ja aktuell noch nicht Thema. :sleeping:
    Manfred Aabye schrieb:

    Dann fehlt hier das absolut wichtigste, den Datenstrom pro Viewer begrenzen (Das ist das mindeste). Der Spruch „Das hier angegebene Beispiel ist 1,5 Megabit“ ist natürlich aus alten Zeiten, das doppelte kann es schon sein heutzutage. Hast du mehrere OpenSim Instanzen laufen solltest du diese auch begrenzen, sonst reist eine die andere bei Problemen runter. (siehe in der OpenSimDefaults.ini [ClientStack.LindenUDP])
    Was meint ihr zu Manfreds Vorschlag, einen anderen Beispielwert in der Kommentarzeile zu erwähnen? Ich weiß jetzt allerdings nicht, ob das linear skaliert und eine Verdoppelung des Wertes auch genau einer Verdoppelung der Megabits entspricht. Das müsste man noch irgendwie messen.

    Das Kriterium "hast du mehrere OpenSim Instanzen laufen solltest du diese auch begrenzen" hätte ich gedacht, mit den beiden aufgeführten Variablen anwenderfreundlich erschlagen zu haben. "scene_throttle_max_bps" begrenzt das Maximum pro Region, "client_throttle_max_bps" das Maximum pro Avatar. Zwei Performance-Stellschrauben durch Ausprobieren zu justieren, ist auch für Anfänger noch machbar. Andere Meinungen? (Hinweis: Sehr viel Traffic geht inzwischen über TCP und kann mit LindenUDP Einstellungen eh nicht mehr begrenzt werden.)
    Thanked by: Pius Noel
  • Christoph Balhaus
    Christoph Balhaus
     Member edited May 11
    (Hinweis: Sehr viel Traffic geht inzwischen über TCP und kann mit LindenUDP Einstellungen eh nicht mehr begrenzt werden.)
    Ja genau das ist das Problem dabei. Über UDP kommen im wesentlichen noch die Statusupdates und die müssen mit hoher Priorität übermittelt werden, machen aber nur einen geringeren Anteil an der gesamten Bandbreite aus. Da dieser Anteil essentiell ist, andererseits aber auch nicht beliebig wachsen kann, sind diese UDP Einstellungen für eine 'gerechte' Verteilung der Bandbreite auf die Nutzer inzwischen ziemlich irrelevant.

    Die TCP Bandbreite ist leider nicht einstellbar und im Code in 'GetMeshModule.cs' und 'GetTextureModule.cs' in ziemlich unbefriedigender Weise hart codiert. Viele Grids haben da eigene Lösungen für entwickelt, vielleicht auch Metro (?). Das Thema wurde schon oft im IRC und in den Office Hours thematisiert und würde jetzt das Thema des Threads sprengen, da sie derzeit eh nicht konfigurierbar sind und sich auch die verschiedenen 0.9er Versionen signifikant unterscheiden.

    Zudem, selbst wenn es in den .ini Dateien wirksame Einstellungen gäbe, sind die Unterschiede in den Bandbreiten zwischen einem 1+ GBit/s Server und einer Home-Installation so groß, dass sie sich IMHO nicht mit einer einzigen Einstellung sinnvoll erfassen liessen (nicht solange Opensim mit statischen Vorgaben arbeitet).

    /Chris

  • Eryn Galen
    Eryn Galen
     Member
    Manfred Aabye schrieb:

    Wenn du die osslEnable.ini änderst solltest du diese immer umbenennen, sonst ist die bei einem upgrade weg

    Das gilt übrigens auch für die eigenen Einstellungen in region.ini und gridcommon.ini (Datenbank!). Ich löse das immer so, dass ich diese Dateien (und da ich faul bin auch die Opensim.ini) als Kopie in form einer .bak Datei speichere. Wenn ich upgrade, muss ich die neuen Datei nur noch neben die jeweilige .bak Datei legen und bedarfsweise rüberkopieren...
    Thanked by: Pius Noel
  • Mareta Dagostino
    Mareta Dagostino
     Member edited May 26
    In meiner Anleitung ist das folgende optionale Feature für die OpenSim.ini:

    Wenn jemand ein Objekt rezzt, das größer oder kleiner ist als die angegebenen Limits, dann wird es automatisch verkleinert/vergrößert. Ohne dieses Feature ist es nämlich ziemlich egal, welche Maximal- bzw. Minimalwerte man in der OpenSim.ini angibt, das wird dann geflissentlich ignoriert.

    Vorteil: Wenn man versehentlich oder absichtlich ein riesiges Teil rezzt, verteilt sich das nicht unter Umständen auf mehrere Regionen.

    Nachteil: Bei mir ist das Limit 64 Meter statisch und 10 Meter physikalisch. Wenn jemand ein Objekt rezzt und danach wieder ins Inventar nimmt, dann ist es ggf. deformiert.

    Was meint ihr, sollen wir dieses optionale Feature mit in die Beispieldatei aufnehmen oder ist das Spielkram?
    [Startup]
      ClampPrimSize = true

    [Permissions]
      permissionmodules = DefaultPermissionsModule,PrimLimitsModule

    [PrimLimitsModule]
      ;# {EnforcePrimLimits} {} {Enforce parcel prim limits} {true false} false
      ;; Enable parcel prim limits. Off by default to emulate pre-existing behavior.
      ;; Effective only if PrimLimitsModule is selected in [Startup] section.
      EnforcePrimLimits = true
    Damit das Feature wirksam ist, sind Einträge in drei Sektionen erforderlich, was vielleicht etwas zu kompliziert für eine Beispieldatei ist?
  • Pius Noel
    Pius Noel
     Member
    Mir persönlich gefällt die bisherige und einfachste Variante am besten. Den Nachteil, dass die Limits dabei ignoriert werden, hast du bereits erwähnt. Mich störte das bisher nicht.
    Thanked by: Mareta Dagostino
Sign In or Register to comment.

Welcome

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions

© Copyright 2019 - Metropolis Metaversum
All times are GMT