Date: Fri, 19 May 2000 16:06:08 +0100 From: Jonathan Laventhol <jonathan.laventhol@imagination.co.uk> To: freebsd-hackers@freebsd.org Subject: System management with large groups Message-ID: <39255860.FC0F2688@imagination.co.uk>
next in thread | raw e-mail | index | archive | help
Dear FreeBSD Hackers --
I've got a technically-straightfordward but nonetheless
business-critical problem with the groups structures in FreeBSD
which perhaps you kind souls can help me with.
*** BACKGROUND ***
My company is a 400-person design and communications agency.
We have approximately 15 NT servers giving file and print service
to mixed network of Macintosh / W95 / NT desktop machines with
a user community of graphic designers, architects, and business
people. The network is essentially pure IP and is global spread
over 5 offices in three continents.
I am looking at the technical feasibility of moving to FreeBSD
with Samba and Netatalk.
We currently use FreeBSD 3.3-RELEASE through 4.0-RELEASE via
Walnut Creek CDs for DNS, e-mail, web, ftp, various proxies,
tacacs and a number of custom web-delivered databases. There
are maybe 15 small FreeBSD machines doing these jobs. Only
systems management actually log in on the machines, the real
users have NOLOGIN shells.
We do not currently use NIS but I'm considering it.
*** HOW WE WANT TO USE GROUPS ***
We would want to use the groups in the following way:
Each user would have a group for themselves with UID=GID.
Each 'rank' would have a group eg board, vp, depthead, et cetera.
Each department would have a group eg finance, graphics et cetera.
Each project would have a group eg proj1000, proj1001
Then umask would be 775
chown ernie.ernie /home/ernie
chown boss.board /board/minutes
chown cfo.finance /dept/finance
chown whatever.proj1000 /projects/proj1000
Clearly there would be a lot of groups required: perhaps several
thousand. And a particular individual might be in a hundred
or more groups; perhaps a few unique individuals would be in
all the projects.
*** ISSUES ***
The most significant issue is the limits on groups. Part of this
is because of the inherent limits of user-group-world masks versus
ACLS -- which we can live with and would help us by simpifying
the problems -- and part is because of long-legacy limits within
4.4bsd.
Because of the size and structure of my company a person might need to
be in 20 or 30 groups anyway.
Because of working around the ACL issue, we'd need to have a large
number
of groups -- perhaps thousands -- and individual users in large
proportion
of those. Some users might even be in *every* group.
*** APPARENT CAUSES ***
1. I see that the 200-users-per-group limit is gone since 3.0-RELEASE.
2. I'm concerned about the 1+16 groups-per-user issue
3. I'm concerned about large numbers of groups in a flat group(5) file.
*** QUESTIONS ***
Question 0: Is this a sensible way to solve my access rights
issues? Anybody got a better way altogether? (Maybe just
hack Samba?)
Question 1: Is anybody planning any work on this for future
releases?
Question 2: What is the relationship between hard-coded NGROUPS
and NGROUPS_MAX, and the sysctl kern.ngroups?
Question 3: Can I just edit NGROUPS_MAX somewhere and make it
bigger? Which one do I fix? (Is there a 'make world faq? Never
done it before.)
Question 4: What do people think might break? Would it be better,
worse, or impossible to do this with NIS?
Question 5: Has anybody done anything like a vigr (like vipw)
for /etc/group? Our (locally-written) user database would be
changing the groups all the time.
Many thanks, my FreeBSD heroes, if anybody has anything to offer
on this.
Best regards,
Jonathan.
--
Jonathan Laventhol
Technology Director
____________________________________________________________________
Imagination 25 Store Street South Crescent London WC1E 7BL England |
Tel +44 171 323 3300 Fax +44 171 323 5801 |
_______________________________________________________|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39255860.FC0F2688>