|Anonymous | Login | Signup for a new account||2021-01-15 22:08 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008217||opensim||[REGION] OpenSim Core||public||2017-07-26 21:42||2020-11-21 21:15|
|Platform||Any||Operating System||Any||Operating System Version||Any|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0008217: Add functionality to handle Estates through Regions.ini|
|Description||OpenSim out of the box does not provide a solution to pre-configure estates other than DefaultEstate in OpenSim.ini or direct SQL. Especially for multiple regions per instance user-interaction is required. This results in the need for dealing with the console, which scares some users for fear or bricking their installation.|
Add EstateID line to Regions.ini for local or remote estates to link individual regions to.
If EstateID is not supplied, but EstateName, EstateOwnerFirstName and EstateOwnerLastName is supplied create the estate locally or remotely and link the region to it.
If neither is supplied or the supplied configuration mismatches the entries in the estate_settings and estate_map either local or remote, give an error and default to user interaction to resolve the conflict. Same goes if the remote estate cannot be created for some reason.
Alternatively if DefaultEstate is set the regions with conflicts could default to that instead.
This functionality should not disrupt any estate handling already present, it merely would allow the pre-configuration of standalones and simulators before initial startup. Removing the need for user-interaction out of the box.
With local and remote I mean either the simulators or standalones own database and remote for grid-managed estates using the remoteestate connector.
RegionUUID = 0521b16d-165e-4873-90d4-80127508868b
EstateID = 102
RegionUUID = 67564553-e9f1-4bdd-beb4-a3bc135bbf19
EstateID = 104
RegionUUID = 56103720-6c9a-43a2-9873-5d18acfd28fd
EstateName = Mine
EstateOwnerFirstName = Test
EstateOwnerLastName = Resident
|Steps To Reproduce||-|
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX|
This is definitely a good suggestion and also something that would make it easier for people to provision regions.
Only question that I have, would it have to read the EstateID each time or just the first time when the region is being registered at the grid.
|The current config system reads when it cannot find the data in the database, example being estate name and owner, so I would think this should work the same, check database first, if not found read from file.|
Gavin Hird (reporter)
In an open connect grid configuration, how would you prevent anyone from just attaching a region to an estate via Regions.ini?
There must be guards in place that actually authorize a region to join an estate.
|@Gavin , I agree, but centralized estate management really should not be used in open connect grids, if not using centralized estate management then the estate data is only stored in the instance. When the estate data is only local to the instance it is not possible to join another persons estate.|
Well could always had a random hash as a sort of estate_secret to it that gets generated on estate creation and can be retrieved from a simulator that is already connected to that estate.
You'd then have to supply that when you want to map a region to an estate or make changes to your estate.
It's essentially just a password auth for estates, but that seems to be the simplest method.
Not really a good idea to have grid-wide estates on an open grid, but one can always just add a config option on robust end to prevent any changes to estates, though then you'd have to make a website interface for people and require them login, which is basically just the same as having to supply a secret hash key to do that.
|2017-07-26 21:42||tampa||New Issue|
|2017-07-26 21:46||tampa||Description Updated||View Revisions|
|2018-07-11 05:15||Fly-Man-||Note Added: 0032769|
|2018-07-11 05:15||Fly-Man-||Status||new => acknowledged|
|2018-07-11 05:40||tampa||Note Added: 0032771|
|2018-08-19 05:15||Gavin Hird||Note Added: 0032864|
|2018-08-19 10:19||BillBlight||Note Added: 0032865|
|2020-11-21 21:15||tampa||Note Added: 0037254|
|Copyright © 2000 - 2012 MantisBT Group|