Steve Ruiz wrote: > We have an opensolaris server with a bunch of disks acting as our office > storage, and it has been working beautifully - we use it as a back end for > Xen, vmware, and general NFS and CIFS. I am trying to get our xen domU > instances to boot with an NFS share as their root volume, and I am running > into strange issues when using opensolaris as the nfs server. I am to the > point where I have this working with a linux nfs server as the backend, so I > know my kernel is capable of booting properly via nfs. It looks like the > mount of the opensolaris share is successfully completing, but any file > access is denied with the error "Can't authenticate (too weak)". The system > I am trying to boot is a linux system, basically the latest version of red > hat enterprise with nfsroot built into the kernel. > > I've tried playing with everything I can think of, verifying DNS forward and > reverse lookups work correctly for the hosts in question, that the dns domain > is identical, playing with the default and max nfs version under solaris, > setting different version of nfs on the client side mount, etc. Is there > anything I can do in solaris to allow this client no matter what, i.e. > anything beyond anon=0 in the export?
I suspect that your client is trying something other than AUTH_SYS, perhaps AUTH_NONE? > Of note, I notice in my linux boot log that it is picking up mycompany.com > as the NIS domain instead of dns domain, and haven't been able to fix that. > > > If that were an issue, you would see another error message. What matters is that the server can resolve the name of your client from the incoming IP. I don't think that is the issue here. > Background information: > opensolaris server: 10.10.3.26 > Linux nfsboot client: 10.10.3.147 > Linux nfs server for testing: 10.10.3.171 > > root at solarisstorage:/etc/dfs# sharectl get nfs > protocol=ALL > lockd_retransmit_timeout=5 > grace_period=90 > server_versmin=2 > client_versmin=2 > server_versmax=3 > client_versmax=3 > servers=16 > lockd_listen_backlog=32 > lockd_servers=20 > server_delegation=on > nfsmapid_domain= > max_connections=-1 > listen_backlog=0 > > > root at solarisstorage:~$ sharemgr show -vp > default nfs=() > ?.. > zfs/datavol/nfsboottest nfs=(anon="0") > nfs:sys=(rw="nfstest.mycompany.com:10.10.3.191" root="nfstest.mycompany.com") > /volumes/datavol/nfsboottest > > Does 10.10.3.191 need access for this test? Or is there an error between it and 171? > > Here is the output of my system trying to nfs boot against the opensolaris > share: (shortened) > IP-Config: Complete: > device=eth0, addr=10.10.3.147, mask=255.255.255.0, gw=10.10.3.3, > host=nfstest, domain=, nis-domain=mycompany.com, > bootserver=1.2.3.4, rootserver=10.10.3.26, rootpath= > md: Autodetecting RAID arrays. > md: autorun ... > md: ... autorun DONE. > Looking up port of RPC 100003/3 on 10.10.3.26 > Looking up port of RPC 100005/3 on 10.10.3.26 > call_verify: server 10.10.3.26 requires stronger authentication. > call_verify: server 10.10.3.26 requires stronger authentication. > VFS: Mounted root (rootfs filesystem). > Write protecting the kernel read-only data: 525k > Kernel panic - not syncing: No init found. Try passing init= option to > kernel. > > > Here is a snoop on the opensolaris server of the above conversation (when > the client is trying to boot): > nfstest.mycompany.com -> solarisstorage.mycompany.com PORTMAP C GETPORT > prog=100003 (NFS) vers=3 proto=UDP > solarisstorage.mycompany.com -> nfstest.mycompany.com PORTMAP R GETPORT > port=2049 > nfstest.mycompany.com -> solarisstorage.mycompany.com PORTMAP C GETPORT > prog=100005 (MOUNT) vers=3 proto=UDP > solarisstorage.mycompany.com -> nfstest.mycompany.com PORTMAP R GETPORT > port=63175 > nfstest.mycompany.com -> solarisstorage.mycompany.com MOUNT3 C Null > solarisstorage.mycompany.com -> nfstest.mycompany.com MOUNT3 R Null > nfstest.mycompany.com -> solarisstorage.mycompany.com MOUNT3 C Mount > /volumes/datavol/nfsboottest > solarisstorage.mycompany.com -> nfstest.mycompany.com MOUNT3 R Mount OK > FH=92A5 Auth=unix > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C NULL3 > solarisstorage.mycompany.com -> nfstest.mycompany.com NFS R NULL3 > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS_ACL C NULL3 > solarisstorage.mycompany.com -> nfstest.mycompany.com NFS_ACL R NULL3 > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C FSINFO3 FH=92A5 > solarisstorage.mycompany.com -> nfstest.mycompany.com NFS R FSINFO3 OK > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C PATHCONF3 FH=92A5 > You can change the addresses and all that, but could I get as much of the output from snoop -v for these two packets and the ones that fail down below? BTW - what build does your OpenSolaris server correspond to? Either of these approaches would tell us: [th199096 at ultralord ~]> uname -a SunOS ultralord 5.11 snv_109 i86pc i386 i86pc [th199096 at ultralord ~]> more /etc/motd Sun Microsystems Inc. SunOS 5.11 snv_109 November 2008 > solarisstorage.mycompany.com -> nfstest.mycompany.com RPC R (#65) > XID=243372054 Can't authenticate (too weak) > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C GETATTR3 FH=92A5 > solarisstorage.mycompany.com -> nfstest.mycompany.com NFS R GETATTR3 OK > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C FSINFO3 FH=92A5 > solarisstorage.mycompany.com -> nfstest.mycompany.com NFS R FSINFO3 OK > nfstest.mycompany.com -> solarisstorage.mycompany.com NFS C ACCESS3 FH=92A5 > (read,lookup,modify,extend,delete) > solarisstorage.mycompany.com -> nfstest.mycompany.com RPC R (#71) > XID=293703702 Can't authenticate (too weak) > > > > > This is the NFS export configuration on my linux nfs server, against which > booting works properly: > [root at localhost ~]# cat /etc/exports > /export/nfsboot > 10.10.3.147(rw,no_root_squash,async,anonuid=0,anongid=0) > [root at localhost ~]# exportfs -v > /export/nfsboot > > 10.10.3.147(rw,async,wdelay,no_root_squash,no_subtree_check,anonuid=0,anongid=0) >
