Unlimited number of group members

[Timo Ruiter]

Is there a way to overcome the limit that the system (HP-UX 10.20 and 11.00) imposes on the number of users that can be member of a single group?
We have an application that runs with its own group ID and all users of that application have to be member of that group to be able to access its files. The number of users is steadily growing...
Editing /etc/group by hand (which seems to work locally) is no option since we're using NIS and ypxfr starts complaining when the maximum line length is exceeded.
The most obvious solution (making the application's group ID the default group ID for all its users in /etc/passwd) is also no option in this case since we have two such applications.

[Mark Greene_1]

If possible, create a new login ID for use exclusively with one of the apps, make the existing login ID exclusively for use with the other app, and then assign the default group ID's accordingly.

Alternatively, have you contacted the application vendor to see if they can change the group requirement to make it a range of groups, or at least more than one?

HTH
mark

[Steve Steel]

Hi


Does

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xfed7f841489fd4118fef0090279cd0f9,00.html

HELP


Steve Steel

[Timo Ruiter]

Changing group requirements is not possible, creating a single (pseudo) user for accessing the application is also not an option.

The link posted by steeve seems to be the answer but I'm not sure about this:

grp1:101:user1,user2
grp1:101:user3

When logged in as user3 (HP-UX 10.20) and giving the commands

$ groups -g
users grp1
$ newgrp grp1
Sorry
$

This is not what I would expect.

On HP-UX 11.00 this works fine, though.

However, when using SAM two entries in /etc/group for the same group are combined to one if the lenght of both user lists do not exceed the maximum line length.
Also, when adding users with SAM to a second entry for the same group, SAM still complains about the lenght of the first line. Probably adding the second group entry before the first will do the trick, but I cannot test this thouroughly since it might result in our production system being unavailable...

[A. Clay Stephenson · Accepted solution]

The problem is not so much with /etc/group as it is with the maximum size of an NIS map. You really shouldn't have a problem if you create multiple group entries. Only the first of the duplicate group entries will actually be picked up by the NIS map but as long as the other users have the same primary group id in their passwd entry all works well.

e.g.

bsp::125:tom,dick,harry
bsp2::125:mickey,donald,goofy

Only the first bsp entry will be displayed by ypcat groups but all those in the second bsp entry will still have gid 125 so that file permissions work.

If you have users which must be members of multiple groups via /etc/logingroup then you must make sure that they are listed in the first of the duplicate group entries since only that one will be known to NIS.

This is not a perfect solution but it does work given the maximum size of any NIS map (1024 bytes) entry.

[Sajid_1]

hello,

I had this same issue before with the NIS setup. What I did was exactly as Clay mentioned. I had to split the users to different group names, but with the same GID. Infact this was recommended by HP support too.

The reason is that when you assign same GID to different names, you will get the same permissions, plus you will have the restrictions about max. limit. This is a small eg: I had a group called dbuser which has 100 users in it. I created dbuser with GID 2600, then created dbuser1, dbuser2 and dbuser3 with same GID. This setup works well till now!

gl

[Timo Ruiter]

The solution as proposed by A. Clay Stephenson did the trick.

I've tested it with SAM and NIS and it worked all right.

Thanks a lot.

Timo