I’m looking at Rockstor as a possible replacement for a Debian-based home server setup that’s been highly reliable but slightly laborious to configure.
My current config works so I was aiming to replicate it as far as possible, including user and group ids etc.
In my current config the “real” (human) user ids start at 1001, however the Rockstor initial setup created a user account for the initial admin user (me) with uid 1000
I don’t see way to change a username or uid from the web UI.
If I change the uid of myself (the initial, and admin user) via the shell, am I going to break a bunch of stuff and lock myself out of the system? I am early on in the setup process so a ground-up reinstall is not a big problem, I’m just curious to know if I am going to end up fighting assumptions in the admin tools if i try to maintain tight control of the config as i did in Debian.
@incans, welcome to the Rockstor community forum. You can change the goups and users at the shell level without breaking stuff if you do this essentially right after the install. Otherwise you do run the risk for some of the services, shares, etc. to be out of sync. and you’re correct that change is not supported at the WebUI level, so Shell access it is.
Not sure about changing the root user on the system, but you can definitely change the Rockstor created groups and users around, if you choose to do so.
I don’t know/think that exposing the groupmod or usermod commands via the WebUI is on the current roadmap. But there has been some conversation around some requirements to have the UID/GID start at a higher number than they currently do, you probably came across that in your search through the forum.
It’s a work-around, but if you create a dummy user, at the cli, before you do the initial Web-UI setup where a regular but Web-UI admin user is then created, it should end-up with a UID of 1001. We are “Built on openSUSE” so basically inherrit their defaults re UID, GID. And it’s been a while since I’ve used Debian but openSUSE, by default sets all users as members of the GID of 100 “users”. Another wrinkle. And as you guessed, and as @Hooverdan stated, it’s best to get this all straight before you get all setup. And remember that you can easily import a prior Rockstor pool. And a config backup if need be.
You can always experiment in a small KVM instance via say Virtual Machine Manager or VirtualBox as the installer/install is actually pretty quick, simple to repeat a few times to see what results from the suggestion of the dummy user work-around.
Yes I considered using a dummy user to “pad” the user ids, but that’s a fudge that only works because it’s an “off by one” situation. If I wanted my users ids to start at (say) 5001, the prospect of creating 450+ dummy accounts to get the next id correct would not be practical.
There also seem to be gaps in Rockstor’s interface as regards creating and assigning groups. In my current setup I use a couple of custom groups along with group memberships to manage access control to Samba shares. It seems I would need to administer that manually in Rockstor. I’m doing this all manually in Debian at the moment, and I was looking for something with less need to dive into the shell to get things set up.
@incans, agreed, there is definitely potential on the UI.
Since I wasn’t sure, I quickly tested the “auto-increment”.
Original user was uid 1000 - via cli used the usermod to move that to 5000.
Created a new user in WebUI without specifying the uid: uid = 5001 was assigned
Created another user in WebUI explicitly specifying uid 5100
Created another user in WebUI without specifying the uid: uid = 5101 was automatically assigned.
So, at the very least you should be able to control the automatic uid “start” for your human users to start at the number range you’re interested in.
Still a workaround at this time, but if that helps you to get closer to the goal for now …
If you wanted to, you could create an issue on the github repo (https://github.com/rockstor/rockstor-core) and outline what functions you’d be looking to execute.
In time, these could possibly be tackled and added to the WebUI (again, caveat being current dev capacity and the need to get to the next official release).