hi,
I’m new on RockStor, and I have a problem with active directory users.
Brief description of the problem
Rockstor don’t show all users of my domain.
I have one Domain (DOM1.local) with 200 users, and one subdomain (DOM2.DOM1.local) with 24000 users.
Rockstor is joined to the domain to DOM1.local, when i execute on shell “wbinfo -u” i can see all user of DOM1.local.
But when I want to list the users in the web interface, rockstor only shows some users of the domain DOM2.DOM1.local, not the users of domain DOM1.local.
It is possible to filter the users or the domain to consult?
When you join an AD Dom usually you get all users from that domain, how did you join dom1.local ?? (ex. did you use a user having right perms over dom1.local and sub domain?)
Rockstor is joined to dom1.local.
But DOM2.DOM1.local is a subdomain of dom1.local and between them there is a trust relationship. But the user who set up on web the SERVICES (Configure Active Directory) does not have specific permissions on the subdomain, and don’t exist in subdomain.
Hi @Barahona,
I know how this will end: I’ll have a new fake domain plus a sub domain with thousands of users and will check this
My knowledge: domain.local Administrator doesn’t have admin rights over subdomain.domain.local till you get it to Enterprise Admins group (Domain admins group has local scope on every domain)
Good Morning @Flyer,
You’re right, all users of the Primary Domain have permissions to query on the subdomain. So any user of the main Domain can consult the users of the Subdomain.
Is possible there any way to filter users that queries rockstor? Or expand the postgress tables with which you work? The system is only able to recover about 4900 users and gives the following error that I attached in an image:
Ok @Barahona let’s have fun with this!
While authenticated to your Rockstor machine on 192.168.1.222 open this address in a new tab : https://192.168.1.222/api/users
So doing we have a direct call to Django REST framework ( our Rockstor WebUI does same thing, but adding “prizes and amusement” aka buttons, tables, nice pagination, etc etc) and you should have a page like this
On my dev env (joined to a domain too) we have 77 users (count field), having both local and domain users, you should have expected number.
If your count field is ok → we have to check over Rockstor WebUI (maybe timeout?)
If your count field is not ok → my guess is timeout over join operation / join operation called from Django
Timeout probably on Domain users listing, check this:
When reading users page we perform a system query with getent passwd (output has system users and domain users too), if user exists on Rockstor db we update data (code on another upper module), if not we create a fake User object and append it to users list (Domain users don’t have a db entry, dynamic data on every request)
Probably with 24k users you fail vs max_wait 90 secs, can you try a getent passwd from shell and check secs/mins??
Mirko
Same probem… My AD is more that 4999 user, and i dont see all of them on web interface… Now i need to add a share to a user start with “Z” but i cant see it…
It is possible any hack to expand the showing number on GUI?
@vamp First off welcome to the Rockstor community.
Thanks for opening the following issue on GitHub (linking for context):
and for linking it back to your/this forum post.
I did see your forum thread at the time but was involved in a rather large git struggle that is now over. I’m also not that up on datatables that I am assuming is the issue here. But I’ll have a go at this one anyway.
From a quick look it may be that the following line could be where the limit you are experiencing is defined:
I’m assuming this is an arbitrary number set to cap the maximum db retrievals so as to limit (normally) required db requests. But in your case may be presenting as a bug.
In your circumstance what would be the minimum viable number here?
Since it will affect all tables we should keep it, for the time being at least, as low as is practically possible. At least until we have input from those that are more familiar with these technologies ie @Flyer.
I can prepare a pull request against your issue once we have the minimum viable maxPageSize for your foreseeable future.
@Flyer do you agree that this is the limiting factor here?
Also given your machine in presumably in production use I’m reluctant to suggest a rebuild (which I’m assuming will be required for any changes to take effect). But this change could be made and released as a stable channel update pretty quickly once we have a number that will work for you?
But, i think it is a good idea, if we somehow able to filter to the user folders (ie: now my AD only need my country users, the other country is not) @Flyer What do you think?
Now i use Rockstor 3.9.1-16 (testing updates) i will get your fix in this channel?
which increases this limit from 5000 to 9000 to accommodate your groups requirement.
And given your prior exclamation:
I have stuck to a simple fix for the time being as your fine suggestion for filtering facilities within the UI:
Would be a far larger endeavour and as such would take a lot longer to get around to and complete with appropriate testing etc, especially given outstanding ‘in queue’ issues. Nice idea though so maybe you could open a fresh issue defining exactly what might meet your requirements and how you think it would best be implemented UI wise: although you could consider first opening a fresh forum thread where ideas might first be exchanged/developed with other community members prior to a well defined issue being opened.
That is not likely as there are other blockers on the testing channel as it is no longer supported via rpm updates; although there are long standing plans to push a final rpm update, at some point, to transition it over to include git instructions etc on building direct from source from the various Rockstor repositories on GitHub. It may be that this final rpm update on testing may include all fixes to date as presented in the stable channel updates.
However the indicated fix, if it passes review, may well be available within a few days on the stable channel subscription, and I have noted in your issue to update this forum thread upon it’s inclusion, assuming I’ve not made a blocking mistake in my pull request.
Hope that helps and do consider the stable channel updates as it does help to sustain the projects development. Though please first take a look at the recent thread started by @KarstenV on a ‘bump’ moving from current testing to stable channel updates:
maxPageSize had that limit slicing AD users to 5k rows and I agree having some checks and users feedbacks before moving to a greater timeout on backend side
Glad you are now sorted and thanks for the update and for confirming the fix. I’ve added a note on the previously referenced pull request of your fix confirmation.
Thanks again for helping to make Rockstor better and for your additional financial support via a stable channel updates subscription.
Please report any other issues you find, probably best in their own forum thread, and hopefully, in time, we can sort those too.