I have Solaris-10 with kernel patch 142900-03, Update 7 Sparc server.
root@ddlomps40:/# uname -a
SunOS ddlomps40 5.10 Generic_142900-03 sun4u sparc SUNW,SPARC-Enterprise
root@ddlomps40:/# cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009
root@ddlomps40:/# cat /etc/group | wc -l
102
root@ddlomps40:/# zoneadm list -icv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
root@ddlomps40:/# cat /etc/passwd | wc -l
1043
root@ddlomps40:/# cat /etc/group | wc -l
102
root@ddlomps40:/#
As group file is increased huge, so whenever I am adding new person to group, few old user is getting removed from group. Since /etc/group file is huge, it does not allow "usermod -G" and we have add user in that group manually with vi. Is there any way to increase this limit with any kernel patch level or update ?
Any any other way to fix this issue ?
Most big sites use NIS or YP to handle this stuff remotely and centrally, and probably with more scalability.
Purging groups is fine if there are no users and file entangled with it, so first you need to purge quiescent users and their files. If their files are readable or writable to others, that can affect them. Once you have purged the files and then users, you can safely remove groups.
Pragmatically, most people move to a new server and make a lame but convenient excuse of incompatibility against migrating all users and groups. Active users move their files, and then you can say goodbye. Disks and related server technologies have a finite life, so this is many ways good. It's like converting code: writing new is an opportunity to clean lots of stuff up, using the old for reference.
We have plans to move it to NIS, but is going to take 6 months from now. Seems like as of now only option for us to find out non-existing user in organization and remove their id's from passwd, shadow and group file to cleanup.
I am not getting any document which can tell me limit of characters in each group or any way to increase it.
NIS has such limits, too.
With the file /etc/group, try the following:
have two lines with the same group name and the same GID, and distribute the group members on them!
LDAP is an alternative to using /etc/shaddow and /etc/passwd, or NIS. The advantage that LDAP has over password file is all information about users and groups can be held on one (centrally administered) server so the user information does not have to be replicated. The advantage over NIS is that LDAP can be used to store information besides user information (such as Netscape Roaming Profiles) and can be used on multiple platforms (NT, Novel, Solaris, and Linux for starters).
Set one system up and then make a mirror on the second, and put all the others on it until the other guys want to merge.
I'd love to see something with real RDBMS logic under it. An XML interface would be nicer, too. It'd be nice to have persistent-caching slave LDAP servers on each host, so they can run without the masters short term.
You could also set the system to lock an account after X days of no logins. I suspect a 30 day lockout period would quickly identify a large group of users who are no longer using the system regularly.
---------- Post updated at 11:48 PM ---------- Previous update was at 11:48 PM ----------
