Ed Wilts wrote:
Unfortunately, I don't have an out-of-pocket answer to that. Although I'm sure there's a way, I've just never had to deal with the situation.On Sat, Feb 08, 2003 at 10:51:03AM -0500, Ric Tibbetts wrote:I've run into this on other *nix's as well, in a couple of very large environments. It's a problem with reading long group lists.
Work-around #2
-------------------------
This is ugly, but it works:
In /etc/group
Create the group. We'll call it "Work" for this conversation.
Add in the number of users that it will take.
Then create a group called "Work2" WITH THE SAME GID as "Work", and add more users to that.
When that one is full, Go with "Work3" ... etc... Keeping the GID the same on all of them. It's the GID that's important, not the group name.
Hi Ric, This works if you have a large number of users to add to one group. What can I do if I have a single user that needs access to a large number of groups? Have you found good workarounds for this? Thanks, .../Ed
I always thought that "group" should be a tree structure, rather than a flat file.
Then you could assign "classes" of users, to a default (pre-defined)set of groups.
For example:
The base class of "Admin_Users" would automatically be assigned to sub groups:
Group:
Admin_Users
group1a
group2a
group3a
etc.
Reg_Users
group1r
group2r
group3r
Web_Admins
group1w
group2w
group3w
etc.
And on.
There may already be a way to automate this, but I've not worked with it. But it seems a reasonable approach.
It could no doubt be set up as a script fairly easily...
Anyone?
Ric
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
