Centralized user.db?

Hey is anyone using one user.db for all of their Flames?

Was thinking about moving the user.db and all the preference directories off the local storage on to the server and using symlinks to point the Flames at a central user.db file. Besides only being able to open the users on one Flame at a time are there any other pitfalls that I’m not thinking of?

I did this back in the day at another place and I think I remember eventually settling on a single user.db that was distributed to the individual Flames on a nightly basis. Can’t remember why though. Would be good to hear if anyone has experience with this before I grind the entire place to a halt messing with the users.

Centralized S+W has this capability inherently.

1 Like

You might run into user hotkey issues if the flames are not all the same hardware and version.

1 Like

This comment caused me to watch Let’s Get Stone’d and while I think you’re absolutely right that a central stone workflow is entirely underappreciated, its a smaller ask to get the user.db centralized than it is to have our entire Flame setup reworked.

It did remind me why I used a sync’d user.db instead of symlinking everything to one location. Its the exact issue that you come up against in the video. The user can’t be open on two Flames at once. While there’s nothing wrong with just creating additional users like you do in the video it recreates the issue that I’m trying to avoid which is multiple usernames per user and default user settings. My inelegant solution last time was to compare the local users against the central database each night, write them back to the central database if any changes were detected, and then redistribute the users to all of the Flames.

I would love to change the method slightly but I’m not sure if its even possible. Ideally the application would “load” the central user by pulling a copy locally when booting into a project and then write the local user back to the server when exiting the application. Seems like it would have to load every user through the application start hook and then write them all back out on the exit hook which seems like a prohibitive amount of data to be moving each time. Also since Flame crashes so frequently on exit it probably wouldn’t be the most reliable solution.

Ultimately its a lot easier to not worry about any of that which is why I’m hoping to just read and write from a single central location. Its relatively rare that anyone would need to log in at two Flames concurrently so I’m willing to accept that as a downside in order to get the benefits. Just hoping there aren’t too many other downsides.

Do you manage your users in any way beyond the centralized stone and wire?

at the OS level in Linux we use FreeIPA for central user authentication/management… In Flame, no, just Central S+W.