Your message dated Thu, 5 Jul 2007 00:54:34 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#428108: assertion failure in nss_nis when using netgroups
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: nfs-kernel-server
Version: 1:1.0.10-6
Severity: important
Perhaps this is a bug in the NIS package but since the fault affects
rpc.mountd I am filing here first. Feel free to reassign...
Summary
-------
I have a system which exports one filesystem.
Access to the export is controlled via NIS netgroups.
Mounting by clients is done via a NFS automount, using a NIS automount map.
Running /bin/ls from a remote system kills rpc.mountd on the exporting system.
This state of affairs renders the package basically unusable for us.
The same behaviour is observed for 'sarge' and 'etch' autofs clients.
Background
----------
I have a new 'etch' box, acting as the NFS server. Hostname 'oort'.
The export setup is fairly simple:
oort% cat /etc/exports
/data/OORT_1 @somenetgroup(rw,sync,root_squash,subtree_check)
The relevant package versions are shown at the bottom of this report.
The server setup is the default from the package
oort% grep -v \# /etc/default/nfs-kernel-server
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
oort% grep -v \# /etc/default/nfs-common
STATDOPTS=
NEED_LOCKD=
NEED_IDMAPD=
NEED_GSSD=
The client system has these versions:
autofs 4.1.3+4.1.4beta2-10
nfs-common 1.0.6-3.1
nfs-kernel-server 1.0.6-3.1
Description of Fault
--------------------
On the server, mountd is there at the start
oort# /etc/init.d/nfs-kernel-server
oort# ps -fade|grep mountd
root 2811 1 0 11:48 ? 00:00:00 /usr/sbin/rpc.mountd
root 2825 2769 0 11:48 pts/1 00:00:00 grep mountd
Then the client tries to automount the filesystem with an NIS-based mount map
client% ls /DATA/OORT_1
/bin/ls: /DATA/OORT_1: No such file or directory
On the server, the rpc.mountd just dies.
oort# ps -fade|grep mountd
root 2919 31400 0 11:56 pts/1 00:00:00 grep mountd
The same fault system occurs if I try from an 'etch' client system.
autofs 4.1.4-13
This does not occur if I do the automount on the server system, ie
oort% /bin/ls /DATA/OORT_1
lost+found
The client systems are able to retrieve rpcinfo from the server system,
and are able to automount exports from other Debian and Solaris systems,
all via the same NIS automount map.
client% rpcinfo -p oort
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 911 ypbind
100007 1 udp 911 ypbind
100007 2 tcp 914 ypbind
100007 1 tcp 914 ypbind
100021 1 udp 32768 nlockmgr
100021 3 udp 32768 nlockmgr
100021 4 udp 32768 nlockmgr
100021 1 tcp 39414 nlockmgr
100021 3 tcp 39414 nlockmgr
100021 4 tcp 39414 nlockmgr
100024 1 udp 33415 status
100024 1 tcp 37982 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100005 1 udp 654 mountd
100005 1 tcp 667 mountd
100005 2 udp 654 mountd
100005 2 tcp 667 mountd
100005 3 udp 654 mountd
100005 3 tcp 667 mountd
I ran strace of the rpc.mountd process and the client /bin/ls process.
I can send those by separate email, but the bottom line is this:
(strace -f /tmp/foo -p 2811)
2811 poll([{fd=10, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
2811 recvfrom(10,
"o.\336>\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 8800, 0,
{sa_family=AF_INET, sin_port=htons(794), sin_addr=inet_addr("130.155.1
92.40")}, [16]) = 32
2811 close(10) = 0
2811 write(2, "rpc.mountd: nss_nis/nis-netgrp.c"..., 87) = 87
2811 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
2811 tgkill(2811, 2811, SIGABRT) = 0
2811 --- SIGABRT (Aborted) @ 0 (0) ---
When I try changing the exports file to use network addresses instead of
netgroups, I get normal behaviour:
# showmount -e
Export list for oort:
/data/OORT_1 130.155.194.207
client# mkdir /mnt/test
client# mount -tnfs oort:/data/OORT_1 /mnt/test
client# /bin/ls /mnt/test
lost+found
and rpc.mountd does not die.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages nfs-kernel-server depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libcomer 1.39+1.40-WIP-2006.11.14+dfsg-2 common error description library
ii libgssap 0.10-4 A mechanism-switch gssapi library
ii libkrb53 1.4.4-7etch1 MIT Kerberos runtime libraries
ii libnfsid 0.18-0 An nfs idmapping library
ii librpcse 0.14-2 allows secure rpc communication us
ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra
ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip
ii nfs-comm 1:1.0.10-6 NFS support files common to client
ii ucf 2.0020 Update Configuration File: preserv
nfs-kernel-server recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
forcemerge 369536 428108
thanks
On Thu, Jul 05, 2007 at 08:24:13AM +1000, Vincent McIntyre wrote:
> Hi,
>
> It's been almost a month now since I filed this, with no response apart
> from Steinar kindly forwarding it to the right place.
>
> Can you give any indication of when it is likely to be addressed?
> How can I help resolve it?
> This bug is a serious blocker for us moving our systems to etch.
The bug is already fixed in 2.3.6.ds1-13etch1.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpAOAoP2SJyI.pgp
Description: PGP signature
--- End Message ---
