From owner-freebsd-fs@FreeBSD.ORG Tue Oct 2 07:47:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D09106566B for ; Tue, 2 Oct 2012 07:47:23 +0000 (UTC) (envelope-from ulysse31@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D98F48FC16 for ; Tue, 2 Oct 2012 07:47:22 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so6334377obb.13 for ; Tue, 02 Oct 2012 00:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v44DeOhO/dSduYdX04sZ2bx5P0TB25lNbixUfcDTNws=; b=KLEtOmbF/pRjMtmkE7TEAIQiTsJ/lQ8jDro8vyZvAoiwy0lVikQDwx/By2UwkMbftb WLD8SXU3tGld9gHMkDuUAAZDSFRIYdlfZi3OiH2BHMC1Bqi7+iAGyhr/hgsXsS3IvJbj oRHIbIsOOlULNXyHtLEMYGmMfN/OjADzmNRNMsfcgXbrCsdICk8oxtso4utH3sCXWDfk 1DwJpqaKQ8e9FNgSH9IlQ/JO38iWya0m7mCYyhCkNNHECGFFlPvS7//c7bBFm8osgDEX 9hevoHAotyNMccbjZgtqNbsuPwZsLVaMxcGKPD1oiJcPE5Qq+mdITtVp/sWAjSTIwm0K ecnQ== MIME-Version: 1.0 Received: by 10.60.26.133 with SMTP id l5mr13919839oeg.60.1349164042057; Tue, 02 Oct 2012 00:47:22 -0700 (PDT) Received: by 10.182.80.200 with HTTP; Tue, 2 Oct 2012 00:47:21 -0700 (PDT) In-Reply-To: <933684392.1422908.1348879198470.JavaMail.root@erie.cs.uoguelph.ca> References: <933684392.1422908.1348879198470.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 2 Oct 2012 09:47:21 +0200 Message-ID: From: Ulysse 31 To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: nfsv4 kerberized and gssname=root and allgsname X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 07:47:23 -0000 2012/9/29 Rick Macklem : > Ulysse 31 wrote: >> Hi all, >> >> I am actually working on a freebsd 9 backup server. >> this server would backup the production server via kerberized nfs4 >> (since the old backup server, a linux one, was doing so). >> we used on the old backup server a root/ kerberos identity, >> which allows the backup server to access all the data. >> I have followed the documentation found at : >> >> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup >> >> done : >> - added to kernel : >> >> options KGSSAPI >> device crypto >> >> - added to rc.conf : >> >> nfs_client_enable="YES" >> rpc_lockd_enable="YES" >> rpc_statd_enable="YES" >> rpcbind_enable="YES" >> devfs_enable="YES" >> gssd_enable="YES" >> >> - have done sysctl vfs.rpcsec.keytab_enctype=1 and added it to >> /etc/sysctl.conf >> >> We used MIT kerberos implementation, since it is the one used on all >> our servers (mostly linux), and we have created and /etc/krb5.keytab >> containing the following keys : >> host/ >> nfs/ >> root/ >> >> and, of course, i have used the available patch at : >> http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch >> >> When i try to mount with the (B) method (the one of the google wiki), >> it works as expected, i mean, with a correct user credential, i can >> access to the user data. >> But, when i try to access via the (C) method (the one that i need in >> order to do a full backup of the production storage server) i get a >> systematic kernel panic when launch the mount command. >> The mount command looks to something like : mount -t nfs -o >> nfsv4,sec=krb5i,gssname=root,allgssname > fqdn>: >> I have activated the kernel debugging stuff to get some infos, here is >> the message : >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x368 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80866ab7 >> stack pointer = 0x28:0xffffff804aa39ce0 >> frame pointer = 0x28:0xffffff804aa39d30 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 701 (mount_nfs) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff808ae486 at kdb_backtrace+0x66 >> #1 0xffffffff8087885e at panic+0x1ce >> #2 0xffffffff80b82380 at trap_fatal+0x290 >> #3 0xffffffff80b826b8 at trap_pfault+0x1e8 >> #4 0xffffffff80b82cbe at trap+0x3be >> #5 0xffffffff80b6c57f at calltrap+0x8 >> #6 0xffffffff80a78eda at rpc_gss_init+0x72a >> #7 0xffffffff80a79cd6 at rpc_gss_refresh_auth+0x46 >> #8 0xffffffff807a5a53 at newnfs_request+0x163 >> #9 0xffffffff807bf0f7 at nfsrpc_getattrnovp+0xd7 >> #10 0xffffffff807d9b29 at mountnfs+0x4e9 >> #11 0xffffffff807db60a at nfs_mount+0x13ba >> #12 0xffffffff809068fb at vfs_donmount+0x100b >> #13 0xffffffff80907086 at sys_nmount+0x66 >> #14 0xffffffff80b81c60 at amd64_syscall+0x540 >> #15 0xffffffff80b6c867 at Xfast_syscall+0xf7 >> Uptime: 2m31s >> Dumping 97 out of 1002 MB:..17%..33%..50%..66%..83%..99% >> >> ------------------------------------------------------------------------ >> >> Does anyone as experience something similar ? is their a way to >> correct that ? >> Thanks for the help. >> > Well, you're probably the first person to try doing this in years. I did > have it working about 4-5years ago. Welcome to the bleeding edge;-) > > Could you do the following w.r.t. above kernel: > # cd /boot/nkernel (or wherever the kernel lives) > # nm kernel | grep rpc_gss_init > - add the offset 0x72a to the address for rpc_gss_init > # addr2line -e kernel.symbols > 0xXXX - the hex number above (address of rpc_gss_init+0x72a) > - email me what it prints out, so I know where the crash is occurring > > You could also run the following command on the Linux server to capture > packets during the mount attempt, then email me the xxx.pcap file so I > can look at it in wireshark, to see what is happening before the crash. > (I'm guessing nr_auth is somehow bogus, but that's just a guess.:-) > # tcpdump -s 0 -w xxx.pcap host Hi, Sorry for the delay i was on travel and no working network connection. Back online for the rest of the week ^^. Thanks for your help, here is what it prints out : root@bsdenc:/boot/kernel # nm kernel | grep rpc_gss_init ffffffff80df07b0 r __set_sysinit_set_sym_svc_rpc_gss_init_sys_init ffffffff80a787b0 t rpc_gss_init ffffffff80a7a580 t svc_rpc_gss_init ffffffff81127530 d svc_rpc_gss_init_sys_init ffffffff80a7a3b0 T xdr_rpc_gss_init_res root@bsdenc:/boot/kernel # addr2line -e kernel.symbols 0xffffffff80a78eda /usr/src/sys/rpc/rpcsec_gss/rpcsec_gss.c:772 for the tcpdump from the linux server, i think you may are doing reference to the production nfs server ? if yes, unfortunately it is not linux, it is a netapp filer, so no "real" root access on it (so no tcpdump available :s ). if you were mentioning the old backup server (which is linux but nfs client), i cannot do unmount/mount on it since its production (mountpoint always busy), but i can made a quick VM/testmachine that acts like the linux backup server and do a tcpdump from it. Just let me know. Thanks again. -- Ulysse31 > > rick > >> -- >> Ulysse31 >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"