Editing Rights.

[Ashember]

Shared editing rights is not operational on Halcyon Grid. This is True for any Viewer we have tested.
So we need to see if we can re-enable folks to share edit rights.

Not having the ability to grant these rights is slowing development a great deal.

I have reached out to the Firestorm Team and they have told me this.
"
Ash, I talked to some of the top people and they said that you will need to file a jira and give them the info they need to work on it. They also said that they don't do "hot fixes" so it is not something you will have immediately, but you were already aware of it. They also pointed out a couple of known bugs and asked that if it is one of those, you don't file it. They also had a few specific things they wanted to know in the jira.
I am going to paste that conversation here.. I hope that it will be readable from the paste....
here is the chat with support ... discord wants me to upload it as a file
Attachment file type: document

FS_Dev_Conversation.txt

gonna paste the links they gave me one at a time just incase hard to read in uploaded text file
link on wiki page explaining how to file jira: https://jira.firestormviewer.org/
known server bug on permissions: https://jira.secondlife.com/browse/BUG-9699?focusedCommentId=476020&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-476020
workaround for that bug: Workaround is to change active group tag to reset the caps(edited) http://opensimulator.org/mantis/view_all_bug_page.php
open simulator bug that they hope it is not: http://opensimulator.org/mantis/view.php?id=6667
they also wanted to make sure you are aware of this:
https://wiki.firestormviewer.org/firestorm_change_log_6.0.1.56538#opensim_new_features_and_improvements

No OS changes in 6.0.2
https://wiki.firestormviewer.org/firestorm_change_log_6.0.1.56538#opensim_new_features_and_improvements"

[emperorstarfinder]

Are any of your objects set or deeded to group when you have tried to do shared editing?

According to the Secondlife Jira there are some known issues with this dating back to 2014 in which one of the bugs reported a comment indicates some residents had to make sure their group tag was the same as the actual object.

Additionally, another comment indicates editing objects on a region border is having similar issues (this one is a little more understandable). It is not known yet if this was fixed by Linden Labs or any of the TPV viewers.

[Ashember]

no, and we are not setting them to group that is way to much trouble. There is no shared editing rights working. And we do not want to assign objects to group because if they accidently set one piece to no mod we can't do anything with it.. so we need to fix the proper edit rights. I even tried using the Inworldz Viewer and many others and it didn't work.. so there is something in the code preventing it.

[emperorstarfinder]

Okay, I am just checking to see if the behavior is similar to bugs being reported on other architectures and grids. It would appear this is an issue dating back to at least 2014 so it may not necessarily be just Halcyon that is affected by this as Secondlife among other grids is reporting similar issues.

[Ashember]

OS can share, so can Second Life. we tested. so it is only a Halcyon issue.

[appurist]

This isn't missing functionality in Halcyon per se, as these friend edit rights were implemented and working fine in InWorldz. I believe what has happened is that LL has changed the interface and viewers and OpenSim have updated their code to switch to the new interface. I'm not sure exactly what the changes are but this is one of those areas where Halcyon needs an update to stay parallel with SL on this feature. In the meantime, you can probably use an older viewer such as ye olde InWorldz or Islandz viewers or Alchemy 5.7 or an older Firestorm to change friend edit permissions on Halcyon grids.

I am looking into this problem though, as my top priority now, that an earlier security issue has been addressed.

[appurist]

I believe I have identified the problem; and the reason is unexpected, related to the way database configuration strings are read from the Halcyon.ini file within the friends-related code in the server. The problem prevents the friends permission change from being committed to the database.

While it seems to be a bug -- and so I may have a new commit soon to fix it -- there may also be a change that can be applied to the Halcyon.ini file on existing regions to work around the problem in the meantime. This may also explain why it worked in InWorldz; the breakage may have been a "cleanup" of the Halcyon.ini file for more generalized use outside IW. Still investigating.

[Ashember]

Are you meaning to Email me or Bob?

…

On Sat, May 8, 2021 at 9:01 PM Appurist (Paul) ***@***.***> wrote: I believe I have identified the problem; and the reason is unexpected, related to the way database configuration strings are read from the Halcyon.ini file within the friends-related code in the server. The problem prevents the friends permission change from being committed to the database. While it seems to be a bug -- and so I may have a new commit soon to fix it -- there may also be a change that can be applied to the Halcyon.ini file on existing regions to work around the problem in the meantime. This may also explain why it worked in InWorldz; the breakage may have been a "cleanup" of the Halcyon.ini file for more generalized use outside IW. Still investigating. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFTGXFCMQA2V7QMDQ7BBZVTTMXNHFANCNFSM4LAFCWVQ> .

-- Ashley Love ***@***.***

[appurist]

Ash, I'm updating the Halcyon issue that you filed, and you're probably being notified via email because you have notifications enabled there at #99

Update: The quick answer is that friend edit permissions (and the others) are working if the Halcyon.ini includes a correct database configuration string in ConnectionString under the [UserService] section. Perhaps InWorldz INI files had this option and it was removed on MyWorld grids as a false optimization, thinking it was redundant. (It was not.)

So in fact as far as I can tell, this was a configuration error on the grid rather than a Halcyon bug.

That said, having the database configuration string in so many places is certainly sub-optimal. So with the approval of @kf6kjg I would also proceed on a pull request for a change to used this existing [UserService] ConnectionString option if it was present, but fall back to what I consider to be the main/primary connection string, the [Startup] section's core_connection_string entry, if the UserService entry isn't present (as was the case on EG and probably Ashember's grid). That way it would continue compatibly, but suddenly start working everywhere (and be more concise) after a software update, even if they don't add this redundant connection string.

Eventually I'd like to see a full review of all of the database connnection strings and consolidate those into a single pair of connection strings, one for the main database core_connection_string and the one for the region database (RDB): rdb_connection_template.

[appurist]

The executive summary for anyone running a Halcyon grid:

This problem can be avoided with a configuration change to the halcyon.ini file:

Copy the connection string text from [Startup] section's core_connection_string to the [UserService] section (which is probably empty) as an entry named ConnectionString. It should look something like this:

[UserService]
ConnectionString = "Data Source=1.2.3.4;Database=something;User ID=userid;password=secret;Min Pool Size=5;"

All of those fields in the ConnectionString should match whatever text is in your core_connection_string.

[appurist]

This is now running this way on EG (WinReg16 where my Nova region is) and the region restarted. Raven and I tested and confirmed the change.

We also confirmed the semantics with many combinations, including cross-region changes, non-updated regions, multiple viewers, offline receiver, removing and adding, etc. All working as long as the granting of privileges is done from a region with the ConnectionString specified.

[kf6kjg]

I'm always open to useful PRs.

[emperorstarfinder]

Ideally, you really do not want to have database connection strings throughout the entire configuration file. All the services should really be tapping into one configurable section for the database as shown in the example below:

[Database] ConnectionString = "Data Source=1.2.3.4;Database=something;User ID=userid;password=secret;Min Pool Size=5;"

Therefore the real fix for this would be to refactor the codebase to point to one configurable section for the database configurable options in the INI file. Plus by doing it this way you are limiting the potential of bugs getting reported due to people forgetting to configure all the configurable items for the database (it does happen).

[sonjamichelle]

I applied the "work-around" to The Moonlight Grid and editing rights are now working as expected.

NOTE!!!
If you are using Bob's MyWorld as your management/configuration base and you follow his setup guide and directory structure you need to make the change in TWO Halcyon.ini files.

The first would be in your main MyWorld directory and the second in your Grid Services directory (I think he has you call it "bin").

eg: On my server;s D: drive I have my main grid directory as D:\MyWorld. In that directory I have a Halcyon.ini file. THEN, I have a directory d:\MyWorld\bin in which I run the GridServer, UserServer, MessagingServer and ApertureServer exe files. the same change needs to be made to the Halcyon.ini in that directory too.

Once done all should be good. Of course, shut down your regions and your grid services to make the change and restart them. I can't confirm if just issuing a restart command will fully apply the changes. Personally, when I make ini or conf changes I shut down and restart manually just to be sure.

Of course this will disrupt any online users so the process should be planned out and users given ample notice.

I do have to add that this was done on a single server grid. Grids with MANY regions across SEVERAL servers have to change the Halcyon.ini in each server's root world directory. IF I REMEMBER CORRECTLY that is. Been a while since I ran multiple servers and I forget the exact setup.

On that single server with 80 regions started by using 6 batch files (1 for grid service (Whip,aperture,Grid,User,Messaging) then 5 more with blocks of 10 or so regions per file with a sleep delay of 35 seconds between each Halcyon.exe call takes at least 30 to 45 minutes to complete. I haven't sat here with a stop watch so I can't tell you an exact time. You'd just have to do the math.

[appurist]

@emperorstarfinder That refactoring is exactly what I was suggesting with my "Eventually" paragraph. We are on the same page here. The only clarification I have is that there still needs to be more than one, for scalability reasons, the concept of the RDB was added and the RDB mapping, to allow region loading to be spread across multiple db servers. Thus my suggestion for core_ and rdb_ configuration strings. However, the RDB string could continue to work as it does today, and fall back to the core string if not present, leaving only one. When I do the update (hopefully today) to make the [UserService] optional (fall back to core), I'll take look at a full refactoring.

[appurist]

@sonjamichelle Yes, on all of that, but one correction. Loading the User service should always come before the Grid and Messaging service. The code assumes that it comes first and does extra startup work including deleting the contents of the dependent folders shared with the other two, namely the add-ins. This isn't likely going to cause a noticeable problem, but the code is designed and coded to be ordered as: User, Grid, Messaging.

[appurist]

Oops, mobile reply, bumped the Close button.

[kf6kjg]

Thank you for your investigations. I'm open to a PR to change the semantics of the INI file or even enhance the documentation. Per the above discussion this issue is now known to be working as intended. [Though not necessarily the best way or documented well enough)

[Vinhold]

I am making the suggested temporary changes to the MyWorld instructions and Halcyon.ini configuration process to be applied to currently running worlds. I will schedule with their owners on restart processing. If the consolidation PR is able to be included in the testing release for security update, I will apply that change to the Next Halcyon update to the worlds to use the one DB entry only.

It is a curious thing, but the UserServer_Config.xml also has its own DB connection string, why is that not being used for the DB access when dealing with the users edits, instead of reading Halcyon.ini for a duplicate copy? Being reduced to one DB Access entry in Halcyon.ini is great for maintenance management, but the Grid services each has their own config xml files also. Some way to have that cleared up as well?

[emperorstarfinder]

Because the UserServer, GridServer, InventoryServer, and WHIP servers are technically separate grid servers that by default will read from their own configuration files first so logically speaking they need that connection string right now. However, the configuration files should really be updated to INI files. Especially seeing these servers appear capable of reading from the Halcyon.ini file. and potentially considering updating the INI files to be a bit more user friendly (potentially splitting them up into individual files (i.e. one for scripting known as Scripting.ini, one of physics such as Physics.ini) to make reading and understanding the files easier for end-users (world owners) may not be a bad consideration to make down the road.

[Vinhold]

I would also suggest that the idea which had been started partially a couple of years ago - to put in the process order to use the command line options to provide the same override options as is in Halcyon.exe to get Halcyon.ini file location and any local override copy or use option to get it from a web file.
I would very much like to see all the configs become DB driven web page source to give to the services as needed, providing one centrally managed configuration source, and use any actual ini files as alternate options.

[emperorstarfinder]

@Vinhold I think that idea is a valid idea to have a conversation about. I would recommend creating a separate issue ticket for that so it doesn't get lost in the mire of old issues

[appurist]

@emperorstarfinder @Vinhold I was going to reply but it is off-topic, especially on a closed issue, so I've opened the new issue for you at #120.