Chris Rodgers | 2 Mar 2009 09:10
Picon
Picon

[NFS] Using kerberos NFSv4 with Fedora 10

Hi,

I am trying to get two Fedora 10 machines to talk to each other using 
NFSv4 and sec=krb5p, but I do not seem to be having much luck. I would 
appreciate any suggestions for trouble shooting.

Thanks in advance!

Chris

P.S. Here's what I've done so far:

1) I installed following a guide at 
http://www.citi.umich.edu/projects/nfsv4/2.4-nfsv4/release1/install.html 
and with as much other Googling as I could muster.

2) I now have these modules on the server (mango):

[root <at> mango ~]# rpm -qa | egrep '(rpc|nfs|krb)'
krb5-workstation-1.6.3-16.fc10.x86_64
rpcbind-0.1.7-1.fc10.x86_64
krb5-workstation-clients-1.6.3-16.fc10.x86_64
nfs-utils-lib-1.1.4-1.fc10.x86_64
pam_krb5-2.3.2-1.fc10.x86_64
krb5-auth-dialog-0.7-7.fc9.x86_64
krb5-server-1.6.3-16.fc10.x86_64
libtirpc-0.1.10-2.fc10.x86_64
nfs-utils-1.1.4-8.fc10.x86_64
krb5-workstation-servers-1.6.3-16.fc10.x86_64
krb5-libs-1.6.3-16.fc10.x86_64
(Continue reading)

Ben Myers | 2 Mar 2009 17:36
Picon
Favicon

Re: [PATCH] sunrpc: xprt is not connected until after sock is set

Hi Trond,

On Sat, Feb 28, 2009 at 01:09:28PM -0500, Trond Myklebust wrote:
> On Fri, 2009-02-27 at 21:07 -0800, Aaron Straus wrote:
> > It seems like xs_sendpages does check if sock is NULL and returns
> > -ENOTCONN in that case.

Here's a trace that shows the above:

Starting kernel based NFS server: idmapd mountd statd nfsdrpc.nfsd[4502]: NaT co
nsumption 17179869216 [1]
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ib_ipoib ib_cm
 ib_sa ipv6 ib_uverbs ib_umad iw_cxgb3 cxgb3 mlx4_en mlx4_ib mlx4_core binfmt_mi
sc fuse dm_crypt crypto_blkcipher nls_iso8859_1 loop dm_mod sr_mod cdrom ib_mthc
a tg3 ib_mad shpchp sg ib_core button libphy pci_hotplug qla2xxx mptctl usbhid h
id ff_memless ohci_hcd ehci_hcd usbcore sd_mod crc_t10dif ide_generic mptfc scsi
_transport_fc scsi_tgt mptspi scsi_transport_spi qla1280 sata_vsc sgiioc4 ioc4 x
fs fan ide_pci_generic siimage ide_core mptsas mptscsih mptbase scsi_transport_s
as thermal processor thermal_sys hwmon pata_sil680 libata scsi_mod dock
Supported: Yes

Pid: 4502, CPU 2, comm:             rpc.nfsd
psr : 0000101008526030 ifs : 800000000000040d ip  : [<a0000002044acf30>]    Not 
tainted (2.6.27.15-2-default)
ip is at xs_udp_send_request+0x270/0x340 [sunrpc]
unat: 0000000000000000 pfs : 000000000000040d rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr  : aa99aaa6aa5aa999
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a0000002044acd30 b6  : a0000002044accc0 b7  : a0000002044c8fe0
(Continue reading)

Chuck Lever | 2 Mar 2009 17:39
Picon
Favicon

Re: [PATCH] sunrpc: xprt is not connected until after sock is set

On Mar 2, 2009, at Mar 2, 2009, 11:36 AM, Ben Myers wrote:
> Hi Trond,
>
> On Sat, Feb 28, 2009 at 01:09:28PM -0500, Trond Myklebust wrote:
>> On Fri, 2009-02-27 at 21:07 -0800, Aaron Straus wrote:
>>> It seems like xs_sendpages does check if sock is NULL and returns
>>> -ENOTCONN in that case.
>
> Here's a trace that shows the above:
>
> Starting kernel based NFS server: idmapd mountd statd  
> nfsdrpc.nfsd[4502]: NaT co
> nsumption 17179869216 [1]
> Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs  
> ib_ipoib ib_cm
> ib_sa ipv6 ib_uverbs ib_umad iw_cxgb3 cxgb3 mlx4_en mlx4_ib  
> mlx4_core binfmt_mi
> sc fuse dm_crypt crypto_blkcipher nls_iso8859_1 loop dm_mod sr_mod  
> cdrom ib_mthc
> a tg3 ib_mad shpchp sg ib_core button libphy pci_hotplug qla2xxx  
> mptctl usbhid h
> id ff_memless ohci_hcd ehci_hcd usbcore sd_mod crc_t10dif  
> ide_generic mptfc scsi
> _transport_fc scsi_tgt mptspi scsi_transport_spi qla1280 sata_vsc  
> sgiioc4 ioc4 x
> fs fan ide_pci_generic siimage ide_core mptsas mptscsih mptbase  
> scsi_transport_s
> as thermal processor thermal_sys hwmon pata_sil680 libata scsi_mod  
> dock
> Supported: Yes
(Continue reading)

Benjamin Coddington | 2 Mar 2009 18:32
Picon
Favicon

NFS4ERR_RESOURCE in setclientid_confirm

Should we be checking for EREMOTEIO in nfs4_proc_setclientid_confirm 
instead of NFS4ERR_RESOURCE to get the delay/retry, because its 
converted in decode_op_hdr?  Would it be safe to remove this entry from 
the error table?

Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kevin Coffman | 2 Mar 2009 16:46
Picon
Favicon

Re: [NFS] Using kerberos NFSv4 with Fedora 10

On Mon, Mar 2, 2009 at 3:10 AM, Chris Rodgers
<christopher.rodgers@...> wrote:
> Hi,
>
> I am trying to get two Fedora 10 machines to talk to each other using
> NFSv4 and sec=krb5p, but I do not seem to be having much luck. I would
> appreciate any suggestions for trouble shooting.
>
> Thanks in advance!
>
> Chris

The client machine must be running rpc.gssd.  I don't see any mention
of that anywhere in your message.  (/etc/sysconfig/nfs should have
SECURE_NFS="yes")

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
NFS maillist  -  NFS@...
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@... is being discontinued.
Please subscribe to linux-nfs@... instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

(Continue reading)

J. Bruce Fields | 2 Mar 2009 18:41

Re: redundant reverse DNS on NFS mount or umount

On Tue, Feb 17, 2009 at 03:22:35PM +0000, Pádraig Brady wrote:
> I've a problem where reverse DNS is being done by the NFS server.
> This is very problematic when the DNS server goes away.
> As far as I can see there should be no lookups being performed
> because I've nothing in /etc/hosts.{allow,deny} and just
> numeric hosts in /etc/exports.
> 
> I can simulate this easily by putting a bad nameserver in /etc/resolv.conf
> and restarting the nfs server. Any mounts will take then take ages.
> Others seem to have had this issue as well, but possibly with
> non numeric names in /etc/exports:
> http://marc.info/?l=linux-nfs&m=110977757630297&w=2
> http://marc.info/?l=linux-nfs&m=111015343008456&w=2
> 
> Here are my config details:
> 
> # rpm -q nfs-utils
> nfs-utils-1.1.0-6.fc8
> 
> # cat /etc/resolv.conf
> search company.com
> nameserver 192.168.2.110
> 
> # cat /etc/exports
> /home   192.168.2.25(async,rw,all_squash,anonuid=500,anongid=500)
> 
> Any ideas appreciated.

I agree that DNS lookups shouldn't be required in this case.

(Continue reading)

Chuck Lever | 2 Mar 2009 18:44
Picon
Favicon

Re: redundant reverse DNS on NFS mount or umount

On Mar 2, 2009, at Mar 2, 2009, 12:41 PM, J. Bruce Fields wrote:
> On Tue, Feb 17, 2009 at 03:22:35PM +0000, Pádraig Brady wrote:
>> I've a problem where reverse DNS is being done by the NFS server.
>> This is very problematic when the DNS server goes away.
>> As far as I can see there should be no lookups being performed
>> because I've nothing in /etc/hosts.{allow,deny} and just
>> numeric hosts in /etc/exports.
>>
>> I can simulate this easily by putting a bad nameserver in /etc/ 
>> resolv.conf
>> and restarting the nfs server. Any mounts will take then take ages.
>> Others seem to have had this issue as well, but possibly with
>> non numeric names in /etc/exports:
>> http://marc.info/?l=linux-nfs&m=110977757630297&w=2
>> http://marc.info/?l=linux-nfs&m=111015343008456&w=2
>>
>> Here are my config details:
>>
>> # rpm -q nfs-utils
>> nfs-utils-1.1.0-6.fc8
>>
>> # cat /etc/resolv.conf
>> search company.com
>> nameserver 192.168.2.110
>>
>> # cat /etc/exports
>> /home   192.168.2.25(async,rw,all_squash,anonuid=500,anongid=500)
>>
>> Any ideas appreciated.
>
(Continue reading)

Qiuyang Wu | 2 Mar 2009 22:53

pread/pwrite bug on linux?


Hi All,

Are there any known bugs with pread/pwrite on RHEL Linux when the disk partition is close to full?

Reduced a complex application fatal down to a simple program just opens a regular file and performs 1M
sequential pwrite() of size 8KB blocks; at every 100th write, does a pread() to load the very first 8KB
block and validate its content still matching what was originally written.

What I observed are the following when running on different machines and writing/reading to a disk
partition nearly full with slightly more than 1GB of free space according to 'df' (the program is the only
process accessing the disk) -

* Linux 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux  (RHEL4)

BEHAVIOR: pwrite() works for many iterations, then pread() suddenly returns data of the requested size
but filled with 0's, and strerror shows errno="No such file or directory", condition
      if(size_to_read != pread(fd, buf, size_to_read, ...)) ...
is not triggered and application has to check errno immediately after every call to pread.

CONCLUSION: serious bug, why does pread() return the expected size filled with 0? and why doesn't pwrite()
fail earlier so application has a chance to bail out and stop pushing more data to the file?

* Linux 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux (RHEL5)

BEHAVIOR: pwrite() works for much fewer iterations, then pread() errors out again with errno="No such
file or directory", and condition (size_to_read!=pread(...)) is asserted at the meantime, which is
slightly better but application still very hard to recover.

CONCLUSION: Bug, still, pwrite() should error out earlier if not enough space to commit data, instead of
(Continue reading)

Jon Mason | 3 Mar 2009 00:22

[NFS] mount.nfs kernel version check override

I am working on backporting NFS-RDMA to older versions of Linux for the
Open Fabrics Linux kernel stack (OFED).  I have backported NFS-RDMA to
RHEL5.2 (which has a kernel based on 2.6.18), and others are working on
backporting to other older kernels.  The issue that I have and they will
discover is that there is a check in the mount command for kernels
greater than 2.6.22.  If it is older than this version, it will not pass
args to the kernel.

I have come up with a patch to add an additional flag to the mount
command to allow this kernel version check to be over-ruled.  Please
consider adding it to the next release of the nfs-utils.

Thanks,
Jon
Attachment (nfs-utils-mount.patch): text/x-diff, 1025 bytes
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
NFS maillist  -  NFS@...
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@... is being discontinued.
Please subscribe to linux-nfs@... instead.
(Continue reading)

Chuck Lever | 3 Mar 2009 01:02
Picon
Favicon

Re: [NFS] mount.nfs kernel version check override

Cc: corrected.

On Mar 2, 2009, at Mar 2, 2009, 6:22 PM, Jon Mason wrote:
> I am working on backporting NFS-RDMA to older versions of Linux for  
> the
> Open Fabrics Linux kernel stack (OFED).  I have backported NFS-RDMA to
> RHEL5.2 (which has a kernel based on 2.6.18), and others are working  
> on
> backporting to other older kernels.  The issue that I have and they  
> will
> discover is that there is a check in the mount command for kernels
> greater than 2.6.22.  If it is older than this version, it will not  
> pass
> args to the kernel.

That's because those older kernels don't support text-based mount  
options.  That will always be true of those upstream kernels.

> I have come up with a patch to add an additional flag to the mount
> command to allow this kernel version check to be over-ruled.  Please
> consider adding it to the next release of the nfs-utils.

I am not the maintainer of nfs-utils, however:  In general, features  
for backports like this are not considered for upstream.  They are  
usually your responsibility.  In this case, you would maintain your  
own copy of the mount command (or nfs-utils) that alters the kernel  
version check as needed.

Also, there used to be a "-i" switch that forced the mount.nfs command  
to send text-based mount options to the kernel.  The reason it was  
(Continue reading)


Gmane