Closed Ramius1701 closed 6 years ago
I don't really understand the previous comment at all. For a region to start, there needs to a be a single XML file in the Regions folder. A .new extension is not a .xml file, so yes, it won't be able to find the region to load. If it throws an exception, that's a fatal startup error, not really a crash, although it would definitely be better to report it more cleanly with a specific error for missing region file, if it wasn't clear.
Where did this .new file come from? Perhaps it's just a sample file provided, with the wrong extension so that you are forced to review it prior to startup? Or is that produced by the wizard that runs if there's no region file? We should really just document that you need to create the .xml file in the Regions folder. I call mine default.xml by the way, or default-1000-1000.xml for the map location. (I'm changing my region name and sometimes the UUID all the time depending on my testing needs.)
Some of the error cases have very little effort applied to them since they are one-time issues that never happen with a properly-configured installation. And to be honest, I'd rather see us automate the creation of a properly-configured installation rather than work on changes to the server to make misconfigured installations more user-friendly.
Fixing configuration issues is best done outside the core server (always runs) code. Part of that fix might be to just improve the setup documentation. To some degree, you folks are the first ones outside of the Halcyon developers and volunteers to really dive in and try to set up a new installation, so unfortunately you are on the bleeding edge. We can use your experiences, noting the things that trip up your setup, that aren't documented, or just don't work without changes, to make it smoother for the next folks to give it a try. I'd love to have a chance to do an installer with a wizard that prompted for any required configuration options.
On first run of Halcyon when it comes to create the region you enter the information either using the defaults or choosing you own, it creates a default.xml.new file in the regions folder automatically. You have to manually rename the file to default.xml and relaunch Halcyon for it to continue past creating the region. The Halcyon server will close and pop up a debug window when this happens, since the Halcyon server is looking for the default.xml file by default, but Halcyon is creating the xml file named default.xml.new
It looks for any .xml file in the Regions folder. We never use the "wizard" to create these region definitions; that's a bit of a legacy thing, and I didn't realize it created it with a filename extension that wouldn't then be recognized. I think the idea there is that it's likely something the original developers wanted to confirm first, although if the region starts up following the wizard prompts, it's already running and should be repeatable with a restart (and no new prompts). So that means we should probably change the wizard to produce a filename with the standard .xml extension.
I'd like to see all of that, the database initialization, etc all rolled into some kind of simpler installer wizard. Or alternatively it could just come with a default.xml file that has a default name and default "Administrator" kind of user predefined, so that it just starts up cleanly. An actual installer wizard could allow you to override those settings, name the region, etc.
Yikes. This was way too complex. Sorry about that.
The initial error you were getting:
"Exception: System.Exception: Asset server WHIP could not be loaded"
That doesn't mean it couldn't connect, but that the WHIP asset server client DLL couldn't be loaded for some reason. This can be a configuration error or, alternatively and what seems to be more common, is that the file is untrusted as can happen when you extract the builds from the zipfile. Windows does that whole "are you sure you want to run this" song and dance when you first try to run something downloaded off the internet. This will selectively block DLLs and EXEs from running until you trust each of them. See below.
As I think this caused the majority of your installation issue, i'm going to update our installation/run instructions to deal with some of this.
Thank you for the feedback and your patience.
This week I'm going to add an executable to the deployment package to unblock all the files in /bin and subdirectories.
This may have been a more complex issue then most, Im looking at this from the newbie perspective, as with opensim and whitecore they run right out of the box. Hopefully we can get Halcyon to do the same thing eventually. Getting the Wiki updated with the steps will help a lot as well since there isn't much there yet.
As with everything we have done so far, i was able to get one single region running in standalone mode, No inventory or default avatar is loaded, i was able to create inventory items but that is a far as i have tested. Switching it to gridmode = true in the Halcyon.ini presents a whole set of new problems i have been running into (more on that later when we can focus on that)
To sum it all up as we have so far, There is a lot of steps to get it running in standalone, a few code changes might resolve some of those, A few file changes to the defaults in the Halcyon.ini and whip.cfg files which can be included in future builds :)
@ddaeschler - Look forward to testing the executable :) @jimtarber - As for the regions default.xml.new issue seems like a code change, i have been trying to find it in the code and see if i can fix it for a test (haven't located it yet) since it a simple naming issue on creation. As for simple configuration file, Diva Distro has an executible that you can do all that with before you run, if thats what your thinking?
@Ramius1701 yes, I think either we should:
Since I don't like "polluting" core code with instructions that can be part of an external "runs once" process, I clearly lean to the latter case above. To me this is a clear example of where someone coded the first half of something and didn't finish it properly for production use. Having bootstrapping code that could suddenly run on Day 1000 of a region's lifespan just l leads to unexpected error situations that aren't handled. For example in this case, if the region.xml file was accidentally deleted by something in a production environment like the InWorldz main grid, rather than the region failing to start with some kind of clear error and an exception, it would sit there awaiting manual intervention at the console by grid operators. This is, to me, wholly unacceptable behavior for a server process, and has resulted in region down time for InWorldz regions in the past.
So quite frankly, I think the best long-term way to address this case is to remove the wizard code and replace it with an exception/fatal startup error, then solve the bootstrapping problem with an external configuration tool, which might even be different for each installation, depending on the needs of that site. We can try to provide a general-use configuration tool that satisfies the needs of the region startup along with any first-run requirements (like perhaps testing the MySQL connection configuration). I'd love to see that in the form of a native installer but for cross-platform use it could probably just be another executable like the halcyon.exe, but intended to be run only once for each installation. It could also build-on and thus take care of any platform-specific needs like the unblocking mentioned by @ddaeschler above. I'd like to see us pull the separate tools together into some kind of install/init process.
I'm away from home until July but this looks like a great topic of discussion that I think we could take care of quickly when I returned, once we pointed some guns at the problem. It's the kind of thing we have want to take better care of but often sits for some time because what we have is good enough for our use, since we use custom provisioning tools that copy/create the required files so there is not much sense of urgency. But it seems to me like it's not a large project to get started on, if someone just champions it (and I'm willing to give it some time when I return). Having others work their way though the installation steps is a good reminder of just how many gotchas there still are for third parties trying to set up regions (and a great help towards identifying and fixing those gotchas).
I'm going to jump in on this thread because I've run into some of the same issues.
I currently have halcyon up and running in grid mode by using the MOSES team wiki.
OpenSim.Grid.UserServer.exe OpenSim.Grid.MessagingServer.exe OpenSim.Grid.GridServer.exe Are running on a Linux VM on one computer. Logins are enabled, Region Registration is enabled.
Whip.exe Aperture.exe Halcyon.exe Are running on another Windows 10 computer. I've successfully created a default region and logged in. I have the no inventory issues, logged in as a cloud as well. I created two more regions though I was not able to walk/fly into them I had to TP to each one via the map. However once I restarted the Halcyon process it threw an error about not being able to run multiple regions and I had to remove the two other region files from the Regions directory.
As was mention above by @mdickson you need to run each region in a separate server process. I tried running a separate Halcyon on a different port (9002 instead of 9000) and it crashed and burned. Does this mean I need to run a each region on a separate computer? (That'll get expensive!)
I'm sure I'm missing some simple here.
If anything I'm persistent.
I did some thinking and chewing on the problem I copied the Halcyon directory then made some edits in Halcyon.ini.
Specifically here:
[Network]
; This is the block used to configure a region that is going to connect to
; a grid, aka when gridmode = true
http_listener_port = 9001
default_location_x = 1000
default_location_y = 1001
hostname = 192.168.2.100
I changed the Port to the next port in line 9001, then the default locations to the next position in the grid 1000x1001.
I edited the default.xml file in the Regions directory with the information from the region file that was created with the create region command in the original simulator instance.
Started up the first Halcyon.exe then the second Halcyon.exe and now I have 2 regions and I can walk/fly between them.
What needs to be figured out now is the method that needs to be followed to create new regions. apparently it's not by the create region command. Or is it? Then just manually moving the region file to a new Halcyon directory like I did?
Yes, because the Halcyon server doesn't support more than one instance of physics running (and you need one per region), we run each region in a separate Halcyon instance. They can be run on the same machine, but need unique ports assigned. The require unique ports include both the http_listener_port=
value in the Halcyon.ini
file, and the internal_ip_port=
value in the Region.xml
file (under the Regions
subfolder).
Here is an example, which I like to think of as our standard port usage (similat to that used on the InWorldz main grid). In this case, here's an example of the way regions and grid services use ports on the InWorldz Beta grid (which is a single Windows Server machine).
(Edit: GitHub table formatting doesn't seem to be working so I'm just going to "code" it.)
The usual assignment of ports for central grid services (where used) is:
Service Port
------- ----
User 8002
Grid 8009
Inventory 8004
Messaging 8006
Aperture 8000
Generally speaking, we reserve a range of 16 values for region-related ports. Depending on whether you start at 0 or 1, it's ports 9020 - 9036 for UDP, and ports 9500 - 9516 for TCP.
Region Region.XML Halcyon.ini
Name internal_ip_port http_listener_port
------- ---------------- ------------------
IBI 9020 9500
IB2 9021 9501
IB3 9022 9502
IB4 9023 9503
IB5 9024 9504
IB6 9025 9505
IB7 9026 9506
SB 9030 9510
Physics2 9032 9512
Note that all of the above beta regions are running on a single beta machine (VM instance). Hopefully that gives you an example to work from.
@jimtarber That gives me an idea of how to organize the regions. I've figured out how to run the multiple instances of Halcyon.
What I'm still left wondering is about the best practice to use to create new regions. You've mentioned above that you don't use the wizard. Care to elaborate?
I'm making headway, this has been a frustrating project since April, one that I keep coming back to every time a new idea comes to me. I keep getting further and further along each time. ;-)
We're in a state between processes at the moment. We plan to move to a new process as soon as we have time to complete it, but in the mean time part of our provisioning process copies over all the required bin files and folders, the updates the XML files and Halcyon.ini with database and port info. But if I was adding another region on the beta grid, all I would do is manually copy the bin
folder over (e.g. to a bin2
) and edit the Halcyon.ini
file and the Regions/Region.xml
file. Really it's just the two ports that need incrementing, the region name, and perhaps region owner if desired.
Using the information @jimtarber has given me and what I've figured out, we've got a nice respectable 8 region grid running.
Now I just have to figure out why my maptiles are acting all wonky. World map and mini-map shows nothing on the remote computers but works fine on the local host. Any ideas?
World map takes another setup. The Anaximander project ( https://github.com/kf6kjg/Anaximander) I've written can do the task in association with a web server.
I'm currently redesigning Anaximander using C#. One of the goals is to take the tile drawing process away from the simulator. It is planned to still work in cooperation with a http server however, as those are quite fast at what they do.
Whether you choose to use Anaximander or not, the Anaximander wiki should provide you with an idea of how things work.
On Friday, September 23, 2016, Sonja Thomas notifications@github.com wrote:
Using the information @jimtarber https://github.com/jimtarber has given me and what I've figured out, we've got a nice respectable 7 region grid running.
[image: grid_view_001_m] https://cloud.githubusercontent.com/assets/8279771/18802188/535c8d12-81b5-11e6-9aa1-8252ef40cc0e.png
Now I just have to figure out why my maptiles are acting all wonky. World map and mini-map shows nothing on the remote computers but works fine on the local host. Any ideas?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/InWorldz/halcyon/issues/232#issuecomment-249310190, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGoaOEiVqLiv-N2zBMAoz8oNtdVTuq5ks5qtEiXgaJpZM4Iy-sd .
We are porting our grid over to a new server, one that can handle the software (Dual Xeon 5639 with 32GB ram vs Home PC) and now we are running into the create user issue.
04:58:24 - [LOGIN END]: Error retrieving inventory skeleton of agent 846efc67-f643-4c56-9d1f-7d0e0d5f0d13 - OpenSim.Framework.InventoryStorageException: [LegacyMysqlInventoryStorage] Unable to retrieve folder skeleton: root folder
We are running in Grid Mode, @jimtarber, you mentioned that create user doesn't work in grid mode. So how do we go about creating users and the inventory skeleton in order to log in and use our grid?
Noticed this on one of my login tries on the UserServer Console:
19:56:53 - [LOGIN END]: Error retrieving inventory skeleton of agent e958c27f-05f6-49ea-8699-12c3443c2e4a - MySql.Data.MySqlClient.MySqlException: Unable to connect to any of the specified MySQL hosts. 20:00:53 - DIAGNOSTICS
I have the MySQL database configured in UserServer_Config.xml GridServer_Config.xml and MessagingServer_Config.xml as well as in Halcyon.ini I can't think of any other place it could be.
I did notice an oddity though. In MessagingServer_Config.xml you need to specify localhost for the user server, trying to use an ip address results in a connection failure of the MessagingServer. Not sure if this holds true for 127.0.0.1 though. But when I tried 192.168.2.100 or my actual machine's IP it resulted in a connection failure. MessagingServer would just try to reconnect every 5 seconds.
The Halcyon server code supports multiple inventory providers, and it's probably a lot more complex than it needs to be for a fresh installation but all of that was required for the InWorldz historical setup. Inventory was originally stored in MySQL tables, and presumably still is within your installation if you aren't using Apache Cassandra as we are now. MySQL is simpler for smaller use, if you don't need the huge scalability of Cassandra. There is an inventory "selector" which routes the requests to one of the possible inventory implementations, on a per-user basis. If it's MySQL-based, there are tables for inventoryfolders
and inventoryitems
. To log in, not only must there be a user entry defined (and authenticated), but the server must also then load the "inventory skeleton" for that user. This is comprised of a root folder and typically the common system folders such as Objects
and Landmarks
.
Here's the first user that came up in the inventoryfolders
table on my test system:
I don't know if the extra tools @ddaeschler has provided for Halcyon includes anything to create the skeleton for a user or not; normally our user registration page on our website creates both the
users
record and the default inventoryfolders
records.
If you manually create appropriate records in the inventoryfolders
table, that might be enough to satisfy the loading of the inventory skeleton. You'd need to give the items the appropriate types, unique folderID
uuids, and make sure the parent of the inventory root is a null/zero ID, and that the parent of the other records is the ID of the root folder.
Ideally we should just ensure that the create user
command works in all configurations. I can't remember the problem with grid mode; it might only have a problem with that when Cassandra is used: have you actually tried it? This might be a case of being better off not listening to me. :smile: The syntax is:
create user [<first> [<last> [<pass> [<x> <y> [<email>]]]]]
Anyhoo. I've managed to log in. I moved MySQL over to the machine that the grid/user/message services were running on and that seemed to make the log in process happy. Though I still have no skeleton inventory.
Another Issue, when I start a region it complains that it can't find a master avatar. Though when I create the region using both the wizard on start up and within the xml file I clearly have the information for a master avatar. What am I missing? Can I hit a setting in the DB?
So then it sounds like it was actually a real connection error, problem with the host name in one of the connection strings perhaps? There are several that would need to be updated with your actual MySQL connection info.
I know you've probably been through all this, but the other possibility is that you've got an internal and external IP address for the former MySQL machine and using something like a hostname (like db.mydomain.com
) that is resolving to the external IP, instead of the internal IP (or just using the external IP). When you moved it to be local, did you change it to localhost or 127.0.0.1 ? (If not, that's why it couldn't connect before, if it can now.)
The concept for master avatar (specified in the region.xml
file) is separate from that of the region owner, or estate owner in the estate settings. If there is no record for the region in the estate_settings
(via the estate_map
), it will create one automatically from the region owner or master avatar. Really it probably shouldn't warn about a missing master avatar at startup, since it is handled anyway, and a common approach for regions. But you don't need to worry about that as long as the Region/Estate form shows the correct owner.
If you still have no inventory skeleton, you'll need to create one in the inventory_folders
table as I described above (assuming you aren't using Cassandra inventory). I'd like to get the create user
command working on the console though, and perhaps add a new command to verify/create an inventory skeleton for an existing user, that skips the actual user creation. I'm wondering now if the reason it didn't work for me in grid mode was because it was referencing mode-dependent settings and I just didn't have them set. It seems unlikely to me that it would be a coding bug/limitation specific to grid mode, and more likely that was just a config error on my part. Have you tried the create user
console command? If I get a chance later, I'll take a look at that command. (We need it to work!)
Okay, so I had time to investigate the create user
command some more, and I have good news. It actually is implemented, and including the creation of the inventory skeleton. There are two important aspects to that though:
create user
on the User grid service, it will create the user and the inventory skeleton. I've done this and immediately logged in to the resulting account successfully. However, note that when you run the create user
command, it cannot check whether the user inventory is stored in MySQL or Cassandra, because the user doesn't actually exist yet, so it falls back to the default. In this case, that results in it unconditionally creating the inventory under MySQL. I think in this case though, that is what you want. Not so much in my case, or for InWorldz, but I believe you are using MySQL for inventory so this is just perfect for your use. The only catch is that you must type the command on the User grid server.So go ahead and just try it on the User console:
create user Firstname Lastname password 128 128 my@email.bogus
I downloaded the latest master, compiled and used the create user. Everything went well. Skeleton Inventory was created in the DB, no crashing when I ran the wizard so I was home free.....wrong....I log in, still a cloud still no default stuff though now I'm getting the following error in the halcyon.exe console.
17:34:04 - [GRID]: Error sent by user server when trying to get user profile: (a ccess_denied): Access is denied for this IP Endpoint
I have no firewalls running. I tried this with all processes running on a single machine and with the grid services running on a separate machine from the halcyon.exe processes. Same error gets thrown. I'm using real Ineternet accessible IP address not 192.168 or 10.0.0.
17:33:14 - [WORLD MAP]: JPEG Map location: http://192.187.114.10:9000/index.php?
method=regionImage443859a8d63c4a9b9577a1316ed87860
17:33:14 - [EnvironmentModule]: Environment GET handler for agentID 00000000-000
0-0000-0000-000000000000
17:33:14 - [InWorldz.Phlox]: Attaching to object events
17:33:14 - [SCENE]: Loading land parcel definitions from storage
17:33:14 - [SCENE]: Examining 0 parcels and repairing or applying restricted reg
ion product settings as needed...
17:33:14 - [WATCHDOG]: Started tracking thread "Heartbeat for region Moonlight L
anding" (ID 38)
17:33:14 - [WATCHDOG]: Started tracking thread "Timing for heartbeat for region"
(ID 39)
17:33:14 - [SCENE]: Loading objects from datastore
17:33:14 - [REGION DB]: Loading inventory items for region
17:33:14 - [REGION DB]: Loaded 0 objects using 0 prims, 0 items
17:33:14 - [SCENE]: Loaded 0 SceneObject(s)
17:33:14 - [STATS]: PHYSICS_PRIMS_VERTS,0,0
17:33:14 - [MAPTILE]: Generating Maptile Step 1: Terrain
17:33:14 - [MAPTILE]: Generating Maptile Step 1: Done in 78 ms
17:33:14 - [MAPTILE]: Generating Maptile Step 2: Object Volume Profile
17:33:14 - [MAPTILE]: Generating Maptile Step 2: Done in 0 ms
17:33:14 - [InWorldz.PhysxPhysics] Low physics FPS 3.265306
17:33:14 - [MAPTILE]: STORING MAPTILE IMAGE
17:33:14 - [SCENE]: Registering with InterregionCommsIn
17:33:14 - [OGS1 GRID SERVICES]: Attempting to register region Moonlight Landing
with grid at http://192.187.114.14:8001
17:33:14 - [OGS1 GRID SERVICES]: Region Moonlight Landing successfully registere
d with grid at http://192.187.114.14:8001
17:33:14 - [PRIM INVENTORY]: Starting scripts in scene
17:33:15 - [LLUDPSERVER]: Starting the LLUDP server in synchronous mode
17:33:15 - [UDPBASE]: SIO_UDP_CONNRESET flag set
17:33:15 - [WATCHDOG]: Started tracking thread "Incoming Packets (Moonlight Land
ing)" (ID 41)
17:33:15 - [WATCHDOG]: Started tracking thread "Outgoing Packets (Moonlight Land
ing)" (ID 42)
17:33:15 - [SUN]: Sun Settings Update: Fixed Sun? : False
17:33:15 - [SUN]: Sun Settings Update: Sun Hour : 9.325
17:33:15 - [SUN]: PosTime : 1476106395
17:33:15 - [RegionReady]: Disabled
17:33:15 - [REGIONMODULES]: PostInitializing...
17:33:15 - [!]STARTUP COMPLETE
Currently selected region is Moonlight Landing
17:33:15 - [STARTUP]: Version: 0.9.29.6127
17:33:15 - [STARTUP]: Startup took 0m 53s
Region (Moonlight Landing) # 17:33:38 - [CLIENT]: Incoming connection from Sonja
Galileo e9ac0f2d-fe6d-4595-86d1-58702b78a853, circuit 224278130: 4.7.9.50527
17:33:38 - [SCENE]: Incoming root agent Sonja Galileo e9ac0f2d-fe6d-4595-86d1-58
702b78a853 (circuit code 224278130): 4.7.9.50527
17:33:38 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:33:38 - [SCENE]: Region Moonlight Landing authorized incoming root agent Sonj
a Galileo e9ac0f2d-fe6d-4595-86d1-58702b78a853 (circuit code 224278130)
17:33:38 - [OBJECTADD]: /CAPS/OA/bd992f18-80d1-47bd-b6b6-f5e3ef3de3c8/
17:33:38 - [CAPS]: Registered seed capability /CAPS/f2b481ec-4bb1-46a0-a317-8de8
46aeb9fd0000/ for e9ac0f2d-fe6d-4595-86d1-58702b78a853
17:33:39 - [APERTURE] Could not contact the aperture texture server to register
caps on region Moonlight Landing. Server returned error Unable to connect to the
remote server
17:33:39 - [EVENTQUEUE]: Register caps for client e9ac0f2d-fe6d-4595-86d1-58702b
78a853 in region Moonlight Landing
17:33:39 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:33:39 - [SCENE]: Region Moonlight Landing could not find profile for incoming
root agent Sonja Galileo e9ac0f2d-fe6d-4595-86d1-58702b78a853
17:33:39 - [REST COMM] NewUserConnection: 1078 ms
17:34:02 - [LLUDPSERVER]: UCC Received for client e9ac0f2d-fe6d-4595-86d1-58702b
78a853 circuit code 224278130
17:34:02 - [SCENE]: Adding new child agent for Sonja Galileo in Moonlight Landin
g
17:34:02 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:02 - [APPEARANCE]: Appearance not found in Moonlight Landing, returning de
fault
17:34:04 - [SCENE PRESENCE]: CompleteMovement received for e9ac0f2d-fe6d-4595-86
d1-58702b78a853 (Sonja Galileo) in region Moonlight Landing
17:34:04 - [SCENE]: Upgrading child to root agent for Sonja Galileo in Moonlight
Landing
17:34:04 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:04 - [USER CACHE]: Could not fetch profile for: e9ac0f2d-fe6d-4595-86d1-58
702b78a853
17:34:04 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:04 - [SCENE PRESENCE]: CompleteMovement 109 ms
17:34:04 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:04 - [FRIEND]: exception on reply of GetUserFriendList2 for e9ac0f2d-fe6d-
4595-86d1-58702b78a853
17:34:23 - [LLUDPSERVER]: Received a resend of already processed packet #60, typ
e: CreateInventoryFolder
17:34:49 - [OGS1 USER SERVICES]: Error when trying to fetch profile data by uuid
from remote user server: The operation has timed out at OpenSim.Region.Commu
nications.OGS1.OGS1UserDataPlugin.GetUserByUUID(UUID avatarID)
at OpenSim.Framework.Communications.UserProfileManagerData.GetUserProfileData
(UUID uuid)
at OpenSim.Framework.Communications.UserProfileManager.GetUserProfile(UUID uu
id, Boolean forceRefresh)
at OpenSim.Framework.Communications.UserProfileManager.GetUserProfile(UUID uu
id)
at OpenSim.Region.OptionalModules.Avatar.FlexiGroups.FlexiGroupsModule.SendAg
entDataUpdate(IClientAPI remoteClient, UUID dataForAgentID, UUID activeGroupID,
String activeGroupName, UInt64 activeGroupPowers, String activeGroupTitle)
at OpenSim.Region.OptionalModules.Avatar.FlexiGroups.FlexiGroupsModule.OnAgen
tDataUpdateRequest(IClientAPI remoteClient, UUID dataForAgentID, UUID sessionID)
at OpenSim.Region.OptionalModules.Avatar.FlexiGroups.FlexiGroupsModule.SendAg
entGroupDataUpdate(IClientAPI remoteClient, UUID dataForAgentID)
at OpenSim.Region.OptionalModules.Avatar.FlexiGroups.FlexiGroupsModule.OnComp
leteMovementToRegion(ScenePresence SP)
at OpenSim.Region.Framework.Scenes.EventManager.TriggerOnCompletedMovementToN
ewRegion(ScenePresence presence)
at OpenSim.Region.Framework.Scenes.ScenePresence.<CompleteMovement>b__256_0(O
bject o)
at OpenSim.Framework.Util.SmartThreadPoolCallback(Object o)
at Amib.Threading.Internal.WorkItem.ExecuteWorkItem()
at Amib.Threading.Internal.WorkItem.Execute()
at Amib.Threading.SmartThreadPool.ExecuteWorkItem(WorkItem workItem)
at Amib.Threading.SmartThreadPool.ProcessQueuedItems()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionCo
ntext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C
ontextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C
ontextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [CLIENT]: Slow job: User: Sonja Galileo, Type: AgentUpdate, 00:00:45.
0169333
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [SCENE PRESENCE]: TriggerOnCompletedMovementToNewRegion 45125 ms
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [LLCV]: Avatar appearance update (1) for user Sonja Galileo
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AGENT INVENTORY]: Could not find user profile for Sonja Galileo e9ac
0f2d-fe6d-4595-86d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:49 - [AvatarProfilesModule]: Got null for profile for e9ac0f2d-fe6d-4595-8
6d1-58702b78a853
17:34:49 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:50 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:50 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:51 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:51 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:52 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:34:52 - [LLCV]: Avatar database update (1) committing for user e9ac0f2d-fe6d-
4595-86d1-58702b78a853
17:34:52 - [GRID]: Unable to update_user_appearance, UserServer didn't understan
d me!
17:35:11 - [AGENT INVENTORY]: Received request to create inventory item New Shap
e in folder a39d96c1-4203-4d88-a195-cf9aeb989b7b
17:35:11 - [XFER]: xferID=5000 packetID=0000 buffer=1000 +1000@0)
17:35:11 - [XFER]: xferID=5000 packetID=0001 buffer=1000 +310@1000
17:35:11 - [XFER]: xferID=5000 packetID=0001 buffer=1310 asset=1310 (COMPLETE)
17:35:11 - [GRID]: Error sent by user server when trying to get user profile: (a
ccess_denied): Access is denied for this IP Endpoint
17:35:11 - [ASSET TRANSACTIONS]: Could not find user e9ac0f2d-fe6d-4595-86d1-587
02b78a853 for inventory item creation
17:35:11 - [ASSET TRANSACTIONS]: Uploaded asset data for transaction 4df0536e-b7
0e-c255-f140-19ca83b419bf
Well color me stupid. After digging around I found the trustednetworks file and saw that I didn't have an entry in it for my subnet. DOH!
Errors are gone now. But still a cloud. Though I'm thinking this is part of the problem mentioned in issue 287?
Sorry I didn't get a chance to mention the trustednetworks file sooner, but I'm glad you noticed it.
The cloud may be related to having aperture configured, are you actually running the aperture.exe process?
17:33:39 - [APERTURE] Could not contact the aperture texture server to register
caps on region Moonlight Landing. Server returned error Unable to connect to
the remote server
And make sure that the aperture.cfg file has the same caps token as the one specified below:
halcyon.ini:
use_aperture_server = yes
aperture_server_port = 8000
aperture_server_caps_token = 2960079
...
aperture.cfg:
http_listen_port = 8000
caps_token = 2960079
...
Yup, running aperture. Config looks good too. I'm running everything on the same machine with the exception of the mysql server.
Whip Aperture OpenSim.Grid.GridServer OpenSim.Grid.UserServer OpenSim.Grid.MessagingServer Then the various Halcyon.exe processes for each region.
So far everything is running as expected with the exception of the new user and inventory creation.
Besides what I see above I miss God mode in Halcion it does not work, God mode will activate all Admin powers needed to have control over objects and complete control over land. If you have no level 200 but as Grid Owner also the same level as a regular user then both will have no effect, Admin powers can't be used and Grid Owner is the same as a normal user as you have no power over objects and of course that makes the whole purpose of being owner of the total grid to have control over that Grid. With that said not only console control but also in-world control in case that's Admin, if you think that God Power should be removed you have no Admin rights, and be aware this is not a Opensim or SL thing. You have God Mode also on Second Life every viewer has Advanced, Developer and in there Request and Leave Admin Status if you click on Request Admin Status and you are the owner you have all Admin powers if you say "I have never been able to get "god" mode in Halcyon to function." That means its a BUG!.. "It should be removed anyway" Why should it be removed "?, "it has no function that is needed." You clearly do not understand for what GOD MODE stands for, if you take God Mode away with that you take the admin powers away from any owner, so there are no owners and admins, even in the halcyon.ini file you see GOD back.
sonjamichelle With me my avatar was also first a cloud now not anymore ask Vin! I also miss now GOD MODE.
All the best, Ana Green
Second Life: Now leaving god mode, level 0
If Halcyon should or claims to be close to the Second Life structure why is this not enabled? Or is it a Bug?
http://wiki.secondlife.com/wiki/God_Mode
With respect, Ana Green
Landings Point issue:
Another issue is that I found out that if the landings point has be set to lets say 128,66,22 and you teleport to that region with these settings 128,66,22, you end up at 128, 128, 1
Regards, Ana Green
Hi Ana
God Mode: In order to allow users to have God Mode you actually have to change their user level. By default users are set to a UserLevel of 0. God User Levels range from 100 to 250. You can set the user level in the UserServer with the command set user level (command might be incorrect for Halcyon itself if they have changed that), or you can set the UserLevel manually in the database table for users (I recommend doing this via the UserServer however). You should be very careful who you give God Level permissions to on your grid as a user who has this level could abuse the privilege and cause all kinds of mayhem on your grid (Something I tell everyone when I set up grids for them using various architectures).
I found I did not need to enable anything in the ini file for this.
Landing Point Problem: I to have run into this issue. and have been working through in a separate issue report, trying to pin this down with the Halcyon devs. But at least I know now that I am not the only one who has run into that issue.
Best Regards,
Emperor
Ana, the teleport issue is being tracked in #403
As emperorstarfinder mentioned, god mode is fully supported, but you must first define the user as a god user. On the InWorldz grid, we use godlevel 250 in the database. (I didn't even know there was a console command to set it, but if that works, it may be easier.)
@appurist The console command was originally in OpenSim prior to InWorldz splitting away (if I got the historical info about the particular command correct). If InWorldz did remove it then it really should not be a hard command to restore to the UserServer.
Certain grid accounts such as the World Banker should not have a god level of 250, which would also be the same if the marketplace requires a marketplace account or even customer support staff. The way I usually handle God User Level Accounts on my grid is as follows:
World Banker = God Level 100 Marketplace Account = God Level 100 Library Account = God Level 100 Customer Support Staff = God Level 150 Assistant Core Developers = God Level 200 Core Developers = God Level 250
As I indicated before, you should always be very careful about giving any user god level permissions. Likewise, grid-level accounts must also have the same caution applied to them, especially the bank account and the marketplace and inventory accounts. Just like with a normal user account with god level abilities, if someone were to successfully hack into and gain control of a grid level account such as the world bank account they could do all kinds of potential damage to your grid including your grid's in-world economy. So as I said be very proactive and careful when assigning god level to people.
We would not have removed such a command, but if it wasn't there when we forked, it probably would not have been added, since admins have access to the database anyway. (And checking, that command doesn't seem to be present in Halcyon.)
In terms of godlevels, the Halcyon software only really distinguishes between zero and nonzero for most operations, and level 250 for the serious god stuff (like permissions). There are a couple of 200-level checks, but there's not really any reason to set accounts to 100 or 150. I'm not sure why you would ever make the banker account a god account. At InWorldz, gods are either 0 or 250 (and the banker is not one).
Well, I won't get into the specifics as to why my team has our settings a certain way on our grid here as it would not be appropriate nor would it keep our grid safe. InWorldz has settings and features that I am sure my team's grid architecture does not have and vice versa. Therefore our settings are specific to the requirements based on what we have in our architecture.
On our Halcyon test grid we do keep our settings pretty close to what are defaults in Halcyon itself that way should we find a bug that we can reproduce in Halcyon it makes it easier to let Halcyon devs know about. This is the same procedure for all the test grid setups we have for various architectures as well.
I gave the settings we use on our grid's architecture as an example (this does not mean these are the exact settings). There is not necessarily a right or wrong way to do god level settings so long as the grid owner is proactive and on the lookout for those that might seek to abuse the power the heightened user level gives them. At the end of the day, the settings and who is given grid god levels should be what the owner of each individual grid feels comfortable with. I am of course happy to have a conversation in private regarding why we have our god permissions settings the way we do if it helps to understand why another team might do something differently.
You are correct the command is not currently in the Halcyon codebase (per my checks this morning). However, it would be fairly easy to add it, which I can do a PR for that later in the week once I have tested and feel that I am certain the security risks are not present. The Halcyon users database table has actually two columns which appear to really be the same thing (godLevel, iz_level) I am going to go out on a limb here and guess these two columns are the same purpose relating to the user level (i.e. godLevel which is just really a heightened user level). If so this might be a bit redundant unless there is more of a purpose then just defining a user level.
This discussion is going a bit off-topic; an issue of startup errors that was closed over a year ago, reopened to report lack of god mode and the teleport issues of #403. The important aspect here is that god mode is very much supported in Halcyon. There is no issue.
Also, just to clarify the iz_level
column is completely unrelated to the godLevel
column; it is not redundant in any way.
The InWorldz currency is I'z$ and iz_level
refers currency purchase/cashout limits within a time period.
I believe this has been handled, even going off the original topic a mite.
Greetings, as i am not sure what i am doing wrong here with getting Halcyon to work. I have compiled and successfully run OpenSim and WhiteCore with no problems. I have been attempting to get this to run for over two weeks.
Windows 10, standalone, 127.0.0.1
So i started by downloading the latest master of Halcyon and compiled successfully (in 64Bit)
Downloaded the whip-win64-bin.zip and setup the whip.cfg file and the image below shows what happens
Next i did the halcyon.ini file, i only changed the ip address and setup the mysql information, and changed the whip url
I did the hc-database.exe --init --type core -h database_host -u database_username -p password (with correct mysql information) and verified tables were created in the mysql database
Then opps errors and Halcyon closes,
07:44:15 - [HALCYON MAIN]: configured log4net using default Halcyon.exe.config 07:44:15 - Performing compatibility checks... 07:44:15 - Environment is compatible.
07:44:16 - [CONFIG] Reading configuration settings 07:44:16 - [CONFIG] Reading configuration file D:\Servers\Halcyon\halcyon-master\bin\Halcyon.ini 07:44:16 - [STARTUP]: Beginning startup processing 07:44:16 - ==================================================================== 07:44:16 - ========================= STARTING HALCYON ========================= 07:44:16 - ==================================================================== 07:44:16 - [HALCYON MAIN]: Running in sandbox mode 07:44:16 - GC: Server mode: False, Interactive 07:44:16 - [DATASTORE]: Attempting to load OpenSim.Data.MySQL.dll 07:44:16 - [DATASTORE]: Added IRegionDataStore Interface 07:44:16 - [CLIENTSTACK]: Attempting to load OpenSim.Region.ClientStack.LindenUDP.dll 07:44:16 - [CLIENTSTACK]: Added IClientNetworkServer Interface 07:44:16 - [HALCYONBASE] Attempting to load asset server id=WHIP 07:44:16 - [PLUGINS]: Initializing addin manager 07:44:16 - [PLUGINS]: Loading extension point /OpenSim/AssetClient 07:44:16 - [APPLICATION]: APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs
Exception: System.Exception: Asset server WHIP could not be loaded at OpenSim.OpenSimBase.InitializeAssetCache() at OpenSim.Region.ClientStack.RegionApplicationBase.StartupSpecific() at OpenSim.OpenSimBase.StartupSpecific() at OpenSim.OpenSim.StartupSpecific() at OpenSim.Framework.Servers.BaseOpenSimServer.Startup() at OpenSim.Application.Main(String[] args)
Application is terminating: True
Unhandled Exception: System.Exception: Asset server WHIP could not be loaded at OpenSim.OpenSimBase.InitializeAssetCache() at OpenSim.Region.ClientStack.RegionApplicationBase.StartupSpecific() at OpenSim.OpenSimBase.StartupSpecific() at OpenSim.OpenSim.StartupSpecific() at OpenSim.Framework.Servers.BaseOpenSimServer.Startup() at OpenSim.Application.Main(String[] args)
I have consulted the wiki and the information is very limited for Halcyon and none for Whip.