Package: nis Version: 3.17-31 Severity: normal Unfortunately, we have some groups containing enough users to exceed NIS's 1024-byte limit on the size of a map entry. (glibc no longer enforces this limit, but we have other NIS implementations on our network that do.) There is a workaround for this, documented in the NIS HOWTO <http://tldp.org/HOWTO/NIS-HOWTO/maps.html#AEN548>:
> 1. Break the entry into more than one line and name each group > slightly differnet. > > 2. keep the GID the same for all. > > 3. have the first entry with the right group name and the GID. > I don't put any user names in this one. > > What happens is that going by user name you pick up the GID when the code > reads it. Then going the other way it stops after the first match of GID > and takes that name. It's ugly but works! However, this description does not quite match the current behaviour of the nis package. As the data are fed to makedbm, each line replaces any matching entry already in the database, so it is in fact the _last_ line with a given GID that goes into the group.bygid map. Meanwhile, on the NIS master, lookups try /etc/group first, and find a GID by simple linear scan, stopping at the first match (as above). Therefore, if we want the "correct" group names in the NIS database, we must tolerate incorrect names on the NIS master. For the generated map to be consistent with file-based lookup, it must instead take the first entry for each GID. There are two fairly simple ways this could be achieved: * makedbm could insert entries into the database in no-replace mode, and simply ignore that particular error. That way, subsequent lines with the same GID would have no effect. (This may, however, have unwanted consequences for other maps. I have not checked.) * Alternatively, for group.bygid only, reverse the data before passing to makedbm, e.g. by piping through tac. For any given GID, the first entry in /etc/group is now the last one received by makedbm. Obviously, either of the above fixes would create some problems for package upgrades. Just going ahead and changing the behaviour, without reordering entries in /etc/group, could break existing installations. -- Package-specific info: -- System Information: Debian Release: 6.0 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 'oldstable'), (500, 'stable'), (50, 'unstable'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nis depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii hostname 3.04 utility to set/show the host name ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libdbus-1-3 1.2.24-4 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libgdbm3 1.8.3-9 GNU dbm database routines (runtime ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libslp1 1.2.1-7.8 OpenSLP libraries ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii make 3.81-8 An utility for Directing compilati ii netbase 4.45 Basic TCP/IP networking system ii portmap 6.0.0-2 RPC port mapper nis recommends no packages. Versions of packages nis suggests: pn nscd <none> (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
