In <ccfj.789307572@hippo.ru.ac.za> ccfj@hippo.ru.ac.za (F. Jacot Guillarmod) writes:
>Running on SunOS 4.1.1, I get this problem when trying to distribute a
>new /etc/group file:
>=======================================================================
>hippo:/var/yp# make
>updated group
>pushed group
>/usr/etc/yp/mknetid: 's groups exceed 17
>/usr/etc/yp/mknetid: 's groups exceed 17
>sh: 11507 Bus error
>*** Error code 138
>make: Warning: Target `all' not remade because of errors
>Current working directory /var/yp
>hippo:/var/yp#
>=======================================================================
Thanks to Tony Heskett and Barry Margolin for talking me through this
one!
The problem turned out to be due to extraneous commas in the masters
/etc/group file. Our user registration process adds user names to the
relevant group in a simple minded way, and produced stuff of the form:
wheel:*:0:,user1,user2
nogroup:*:65534:,user3,user4
daemon:*:1:,user5,user6
kmem:*:2:,user1
...
Deleting the leading "," in the entries resolved the problem.
Appended is a summary of the hints and tips from Barry and Tony that led
to the solution.
Thanks again for the assistance.
=======================================================================
From: Tony Heskett <heskett_tony@jpmorgan.com>
Date: Thu, 5 Jan 1995 12:57:08 -0500
To: ccfj@hippo.ru.ac.za
Subject: Re: Problem with NIS and mknetid
Organization: J.P. Morgan Inc.
It's in /usr/include/sys/param.h:
#define NGROUPS 16 /* max number groups */
Unfortunately, unless you've got kernel source, you can't recompile
enough of the system to fix your problem: assume you're stuck with
the limit.
If you let me know *why* you need more groups, maybe I can give
you a workaround.
Have fun
-- Cheers - Tony (theskett@jpmorgan.com)Work: 212 235 9867 Home: 212 888 8324 Portable: 917 853 6938 Beep: 917 649 7537 touchtone. 800 800 7759 alpha, PIN = Tony Heskett
=========================================================================
From: barmar@nic.near.net To: ccfj@hippo.ru.ac.za Subject: Re: Problem with NIS and mknetid Organization: NEARnet, Cambridge, MA
You can have more than 17 groups, but the kernel limits the number of groups that a single process can be in to 16. This limit also exists in the RPC protocol (and many old implementations have a limit of 8 groups), which is used by NFS, so even if you patched mknetid and the kernel, you'd be violating the protocol when the packets went out onto the net. --
Barry Margolin BBN Internet Services Corp. barmar@near.net
======================================================================= From: Tony Heskett <heskett_tony@jpmorgan.com>
> OK, the idea is to cluster users from various departments at the > university into their own group in order to "lock out" other > departments. All of these users will only ever belong to one group, > and in fact no user (even the administrators) belongs to more than 5 > groups... or at least this is what I thought.
So that should work fine and doesn't hit the 16 limit...
> The problem is that it doesn't look like the NIS slaves are getting hold > of the masters /etc/group file. I tried FTP'ing it over to the slaves, > and this seemed to sort out some of the hassles, even though the slaves > /etc/group file reverted after a few seconds.
Avoid ftp'ing NIS maps, they're hole-y and will get lots bigger. Make sure that you build the netid map i.e., use
touch /etc/group; cd /var/yp; make
rather than just making the group map, otherwise you *will* see probs.
Check you've got a '+:' line in the slaves' and clients' /etc/group files.
Check the binding is to the right server (ypwhich). If there's any confusion/likelyhood of confusion, kill ypbind on the clients showing the prob, and restart:
ypbind -ypsetme /usr/etc/yp/ypset nis-master-name-goes-here
Check that all the slaves are listed in ypservers map, or they won't get updates. If you don't have them all, add the lines in the system & network admin manual.
> I'm still puzzled, but not as desperate.
Sounds like your problem's moved, anyway. This *should* all be easy, so if it's not something's being overlooked.
> Thanks for getting back to me.
You're welcome, drop me a line if you get a definite prob. to address.
======================================================================
From: Barry Margolin <barmar@nic.near.net>
From: "F. Jacot Guillarmod" <ccfj@hippo.ru.ac.za> Date: Thu, 5 Jan 1995 23:03:43 +0200 (GMT+0200)
I'm not clear why mknetid is bitching, though? Unless it's in some special mode when it tries to distribute the /etc/group file?
Mknetid builds the netid map from the group file. The netid map is the inverse of the group map -- for each userid it lists the groups they belong to. The message you got indicates that some user is listed in multiple groups.
The message you got was: "/usr/etc/yp/mknetid: 's groups exceed 17". I think it's significant that there's no name before the "'s". Maybe you have an extraneous "," at the end of lots of lines, i.e. something like:
wheel:*:0:user1,user2, nogroup:*:65534:user3,user4, daemon:*:1:user5,user6, kmem:*:2:user1, ...
Mknetid is probably interpreting the commas at the ends as delimiting another user name, which is empty, and trying to put that user in all the groups.
In any case, it looks as if the /etc/group file on the master NIS server is copied via FTP to the slaves then the various users can get hold of the appropriate permissions even though the slaves /etc/group file gets overwritten at a later stage. It's a frig, but it's worked round my problem.
The /etc/group file on the slaves isn't used for much, though, so I don't see how this helps. A client looks in its local /etc/group, and when it sees the "+" line it looks in the group NIS map, but the /etc/group file on the slave is never consulted (except when client applications run on the slave).
========================================================================= -- F.F. Jacot Guillarmod PO Box 94 \ | ccfj@hippo.ru.ac.za Computing Services Grahamstown 6140 \ / Fax: +27 461 25049 Rhodes University South Africa ;___*/ Phone: +27 461 318284 The views expressed above are not necessarily those of Rhodes University
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:13 CDT