I have started working with transitioning a network to LDAP. I am still experimenting with this at home before implementing it "for real." This brings me to my concern. It appears that many groups are added to the system "willy-nilly." By that I mean, I have one system where part of the /etc/group file looks like this: gdm:x:101: man:x:12: sasl:x:45: ssh:x:102: crontab:x:104: xfntserv:x:103: postfix:x:105: Debian-exim:x:106: uml-net:x:107: messagebus:x:109: logcheck:x:108: lpadmin:x:110: plugdev:*:46: camera:x:111: postdrop:x:112: scanner:x:113: saned:x:114: sword:x:115: On another system, it looks like this: gdm:x:101: sword:x:102: man:x:12: sasl:x:45: ssh:x:103: crontab:x:105: xfntserv:x:104: postfix:x:106: Debian-exim:x:107: messagebus:x:109: logcheck:x:108: lpadmin:x:110: plugdev:*:46: uml-net:x:112: camera:x:113: postdrop:x:114: For instance, on one system the camera group has gid 111 and 113 on the other. That is a problem if I want to server everything up out of LDAP. There really should be a "reserved" range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. For example, of package foo wants to create a system group, it would need to first be assigned a gid out of this range. That way, the order in which packages are assigned does not make a difference, as for instance, group camera will always be assigned gid 117, for instance. I'm not sure if such a thing would be feasible or even possible. However, it is a rather significant annoyance to come up with a solution for this that wouldn't take a long time to implement. I guess that if the deployment were on a new network, it would be easier to affect how the gids are assigned, since you would be looking for issues like that. However, for an existing network, this can be more of a problem. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature