Bug#1051088: [PATCH] Remove extraneous words left behind by commit 522837f.
On 9/4/23 4:50 AM, James Youngman wrote: --- utils/mount/nfs.man | 1 - 1 file changed, 1 deletion(-) Committed... steved. diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man index 7a410422..c9850f29 100644 --- a/utils/mount/nfs.man +++ b/utils/mount/nfs.man @@ -986,7 +986,6 @@ file. See .BR nfsmount.conf(5) for details. .SH EXAMPLES -mount option. To mount using NFS version 3, use the .B nfs
Bug#651032: /usr/sbin/rpc.idmapd: rpc.idmapd referring to none existing library
Hello, On 12/05/2011 03:25 AM, Anibal Monsalve Salazar wrote: Hello Steve and Kevin, To fix Debian Bug#649491[1], I moved the .so files to /lib and applied the following patch: --- a/libnfsidmap.c 2010-12-09 04:07:53.0 +1100 +++ b/libnfsidmap.c 2011-12-05 11:23:46.0 +1100 @@ -61,7 +61,7 @@ static struct mapping_plugin **nfs4_plug static struct mapping_plugin **gss_plugins = NULL; #ifndef PATH_PLUGINS -#define PATH_PLUGINS /usr/lib/libnfsidmap +#define PATH_PLUGINS /lib/libnfsidmap #endif #define PLUGIN_INIT_FUNC libnfsidmap_plugin_init [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649491 Why not just use the --with-pluginpath configuration flag? That's how we do it in Fedora... steved. As Michael reported, libnfsidmap is still looking for the plugins in /usr/lib/libnfsidmap. What do I need to change in libnfsidmap to make it find the plugins in /lib/libnfsidmap? Please see Michael's report below. Cheers, Anibal As Michael has reported, libnfsidmap2 is still looking On Mon, Dec 05, 2011 at 08:18:08AM +0100, Michael Rasmussen wrote: Package: nfs-common Version: 1:1.2.5-2+b1 Severity: grave File: /usr/sbin/rpc.idmapd Justification: renders package unusable rpc.idmapd -v rpc.idmapd: libnfsidmap: using domain: midgaard rpc.idmapd: libnfsidmap: Unable to load plugin: /usr/lib/libnfsidmap/nsswitch.so: cannot open shared object file: No such file or directory rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not available rpc.idmapd: Unable to create name to user id mappings. rpc.idmapd is searching for libnfsidmap plugins in the wrong directory so bug #650904 must be reopen since the provided change made to libnfsidmap2 does not make any difference rpc.idmapd still uses /usr/lib/libnfsidmap. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 172 udp785 ypbind 171 udp785 ypbind 172 tcp786 ypbind 171 tcp786 ypbind -- /etc/default/nfs-common -- NEED_STATD=no STATDOPTS= NEED_IDMAPD=yes NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = midgaard [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- balder:/home /home nfs4 defaults,proto=tcp,retry=5,hard,intr,async,_netdev,rsize=32768,wsize=32768 0 0 -- /proc/mounts -- rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 balder:/home/ /home nfs4 rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.2.79,minorversion=0,local_lock=none,addr=192.168.2.2 0 0 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages nfs-common depends on: ii adduser 3.113 ii initscripts 2.88dsf-13.13 ii libc6 2.13-21 ii libcap2 1:2.22-1 ii libcomerr2 1.42-1 ii libdevmapper1.02.1 2:1.02.67-2 ii libevent-2.0-5 2.0.16-stable-1 ii libgssapi-krb5-21.10+dfsg~alpha1-6 ii libgssglue1 0.3-3.1 ii libk5crypto31.10+dfsg~alpha1-6 ii libkeyutils11.5.2-2 ii libkrb5-3 1.10+dfsg~alpha1-6 ii libnfsidmap20.24-3 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-21 ii lsb-base3.2-28 ii rpcbind 0.2.0-6 ii ucf 3.0025+nmu2 Versions of packages nfs-common recommends: ii python 2.7.2-9 nfs-common suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649491: Bug#651032: /usr/sbin/rpc.idmapd: rpc.idmapd referring to none existing library
On 12/05/2011 01:42 PM, Anibal Monsalve Salazar wrote:
On Mon, Dec 05, 2011 at 10:52:18AM -0500, Steve Dickson wrote:
Why not just use the --with-pluginpath configuration flag?
That's how we do it in Fedora...
The --with-pluginpath configuration option isn't in 0.24.
I run
./configure --help
and it doesn't list the --with-pluginpath configuration option.
The configure commands doesn't unrecognize the --with-pluginpath option.
See below.
CFLAGS=-Wall -g -O2 ./configure --host=i486-linux-gnu \
--build=i486-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info --with-pluginpath=/lib/libnfsidmap
configure: WARNING: unrecognized options: --with-pluginpath
The git repo has patches to add the --with-pluginpath configuration
option. Do you plan to release libnfsidmap 0.25 soon?
Sure.. I'll try to get one out asap...
steved.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: On Oct 9, 2008, at Oct 9, 2008, 11:48 AM, Steve Dickson wrote: Unfortunately, I'm failing miserably on reproducing this... Here is what I've done: Chuck Lever wrote: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22. I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed the nfs-utils-1.1.3 (F-10) package along with supporting packages (libgssglue, librpcsecgss and libnfsidmap). I did both mount commands mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home and was able to write to both mount points. bcwong's patch changes the server side too. Have you tried mounting a server running an old version of nfs-utils? Well it turns out bcwong's patch was rewritten by the following patch: commit 603017f2c1587d760e2649b889b581ca267ffee7 Author: J. Bruce Fields [EMAIL PROTECTED] Date: Thu Aug 28 11:23:05 2008 -0400 Determine supported pseudoflavors from export Instead of using a static list of supported flavors, we should be taking the list from the export. Signed-off-by: J. Bruce Fields [EMAIL PROTECTED] So this might be the problem... but To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). If this the case, we need a legacy mount command, then how can it be a bug in nfs-utils-1.1.3? Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by you need to force the use of the legacy mount command is that you need to force the use of the legacy binary mount interface. I have tried a legacy FC-5 mount binary (util-linux 2.13-pre7) on both a 2.6.21 kernel (FC-7) and a 2.6.25.14 kernel (F-9) mounting a F-10 server running nfs-utils-1.1.3 with out a problem. One oddity the mount binary fails when I used the '-o sec=none' flag with: Warning: Unrecognized security flavor none. Bad nfs mount parameter: sec So something else has to be going on here steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by you need to force the use of the legacy mount command is that you need to force the use of the legacy binary mount interface. I have tried a legacy FC-5 mount binary (util-linux 2.13-pre7) on both a 2.6.21 kernel (FC-7) and a 2.6.25.14 kernel (F-9) mounting a F-10 server running nfs-utils-1.1.3 with out a problem. Right, the old mount binaries don't have bcwong's fix, so they are not broken. The combination you need is an nfs-utils 1.1.3 mount command on an old kernel (or just wire the new mount command to use the legacy interface all the time). Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? One oddity the mount binary fails when I used the '-o sec=none' flag with: Warning: Unrecognized security flavor none. Try null maybe? I did... but its probably a red herring at this point... tia. steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? 'touch /mnt/home/tmp/foo rm /mnt/home/tmp/foo' works as expected... steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? 'touch /mnt/home/tmp/foo rm /mnt/home/tmp/foo' works as expected... I'm out of ideas then. Me too... :( The problem was with the mount command in nfs-utils 1.1.3 on older kernels doing automatic security flavor negotiation incorrectly. I believe you... Its just a bit frustrating I can reproduce it Maybe your exports file is set up differently? Maybe... thanks for your help! steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502122: (no subject)
(BTW, I had a look at the sourceforge mailing list for NFS-utils and it seems to be 100% spam. Is there a better upstream bug reporting channel?) The new upstream mailing list is [EMAIL PROTECTED] and upstream bug database is at https://bugzilla.linux-nfs.org... posting things there will get the attention of the nfs maintainers... steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Unfortunately, I'm failing miserably on reproducing this... Here is what I've done: Chuck Lever wrote: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22. I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed the nfs-utils-1.1.3 (F-10) package along with supporting packages (libgssglue, librpcsecgss and libnfsidmap). I did both mount commands mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home and was able to write to both mount points. To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). If this the case, we need a legacy mount command, then how can it be a bug in nfs-utils-1.1.3? At this point, this issue is the only one holding up the 1.1.4 release, so I would like to address it... one way or the other... tia, steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484861: nfs-common: rpc.statd --outgoing-port (-o) option broken
Aníbal Monsalve Salazar wrote: On Sat, Jun 07, 2008 at 01:53:02AM +, Richard A Nelson wrote: Package: nfs-common Version: 1:1.1.2-4 Severity: important In a fit of debugging spurious NFS problems I noticed this: # ps auxw | grep statd statd 4136 0.0 0.0 2056 652 ?Ss Jun06 0:00 /sbin/rpc.statd --port 32765 --outgoing-port 32766 # lsof | grep rpc.statd | grep : rpc.statd 4136 statd5u IPv4 10388 UDP *:920 rpc.statd 4136 statd7u IPv4 10396 UDP *:32765 rpc.statd 4136 statd8u IPv4 10399 TCP *:32765 (LISTEN) changing --outgoing-port to -o didn't help. This is causing issues with my firewalls Is this a known bug in 1.1.2? No... Please file a bug report at https://bugzilla.linux-nfs.org steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Aníbal Monsalve Salazar wrote: In my case I run Debian stable (nfs-utils 1.0.10) on the server and Debian unstable (1.1.3) on the client. I have not tried upgrading the server (which is probably not an option until Debian Lenny is released), but running the client with sec=sys solves the problem for me like here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970#40 This appears to be a debian only issues since with fedora I *always* get 'sec=sys' in /proc/mounts even when I specify -o sec=none which does not seem right I'm investigating that right now... Are there any other debian only patches out there that might be causing havoc?? steved -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
What is logged in /var/log/messages you turn on the in-kernel mount debugging via: rpcdebug -m nfs -s mount then do the following three mounts: mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home mount madhat:/home /mnt/home I got: Oct 2 09:23:10 rawhat kernel: NFS: nfs mount opts='sec=none,addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'sec=none' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:10 rawhat kernel: NFS: MNT request succeeded Oct 2 09:23:43 rawhat kernel: NFS: nfs mount opts='sec=sys,addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'sec=sys' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:43 rawhat kernel: NFS: MNT request succeeded Oct 2 09:24:00 rawhat kernel: NFS: nfs mount opts='addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman wrote:
--- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
+++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
@@ -101,7 +101,7 @@
char plgname[128];
int ret = 0;
- snprintf(plgname, sizeof(plgname), %s%s.so, PLUGIN_PREFIX, method);
+ snprintf(plgname, sizeof(plgname), %s%s.so.0, PLUGIN_PREFIX,
method);
dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL);
if (dl == NULL) {
Getting back to this. I'm curious if there is a specific reason why
the *.so symlink was not there? Adding the .0 shouldn't be
necessary. But there may be a reason for not including the .so
symlink that I am not aware of.
The reason the version (or a version) number is need is because
some distros only installed the .so with the -devel package which
is not normally installed... The question is how do we get the
version to change automagically when the soname changes?
steved.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
