11.31 & nfs

[Doug O'Leary]

Hey;

I think it's great that HP's replaced something that was working and solid with something that now, doesn't seem to do anything I tell it.

Can someone explain what's going on here?

I have three servers:
usilap19
usilap22
usilign3

I have a filesystem on usilap19 shared out thusly:

share | grep temp01
- /testing/temp01 rw=usilap22.myco.com,root=usilap22.myco.com,ro= ""

My understanding, is that usilign3 shouldn't be able to mount or read anything in there... Yet:

# h
usilign3
# mount usilap19:/testing/temp01 /mnt
# cat /mnt/usilap19
four score and seven years ago
our fathers brought forth

While working through this thing, I did have usilap19:/testing/temp01 shared out to the world. Are the old permissions cached somewhere? If so, is there a way to zero out that cache?

While I haven't worked through all the testing yet, I'm also having some difficulty getting short hostnames to work. Some of my nfs exports have access lists that are quite extensive. I'm assuming short names should work, yes?

Any info you can provide will be greatly appreciated.

Doug O'Leary

[OldSchool]

if I understand correctly, the line in the exports file is commented out or indicates that it is shared to usilap22 only, correct?

If it was originally open to all the servers, then you restricted it, you need ot run
"exportfs -u -a"

which "unexports" everything, then re-exports it.

doing "exportfs -a" will not remove the existing export on the filesystem (until reboot)

[OldSchool]

FYI...If the root cause is as I described, then its nothing new...

[OldSchool]

also, if by short names, you mean DNS aliases, yes, they should work as long as forward and reverse lookup work as well.

[Tim Nelson]

Other than 11.31 switching to ONCPlus I have had no issues with it.

edit (syntax is a little different)
/etc/dfs/dfstab

shareall = exportfs -a

unshare = exportfs -u

share = exportfs

[Doug O'Leary]

Hey;

There's something tweaked here:

According to the man page, the unshare isn't supposed to be required:

"If share commands are invoked multiple times on the same file system, the last share invocation supersedes the previous; the options set by the last share command replace the old options. For example, if read-only permission was previously given to usera on somefs, use the following share command to also give read-only permission to userb on somefs:"

But, for the sake of testing: I completely unshared it:

-------
# umount /mnt
# mount | grep /mnt
# h
usilap22
---
# umount /mnt
# mount | grep /mnt
# h
usilign3
-----------
# h
usilap19
# unshare /testing/temp01
# share | grep temp01
#

And, then reshared it out:

# h
usilap19
# share -F nfs -o rw=usilap22.myco.com,root=usilap22.myco.com /te>
# share | grep temp01
- /testing/temp01 rw=usilap22.myco.com,root=usilap22.myco.com,ro
= ""

and remounted:
# h
usilap22
# mount usilap19:/testing/temp01 /mnt
# ll /mnt
total 2
drwxr-xr-x 2 root root 96 Oct 6 11:27 lost+found
-rw-rw-rw- 1 oleary infra 0 Oct 6 11:38 testies
-rw-rw-rw- 1 root sys 0 Oct 6 11:40 testies01
-rw-rw-rw- 1 root sys 0 Oct 6 14:39 testing02
-rw-r--r-- 1 root sys 57 Oct 6 11:46 usilap19
# touch /mnt/testies03 ## should work
# ll /mnt
total 2
drwxr-xr-x 2 root root 96 Oct 6 11:27 lost+found
-rw-rw-rw- 1 oleary infra 0 Oct 6 11:38 testies
-rw-rw-rw- 1 root sys 0 Oct 6 11:40 testies01
-rw-rw-rw- 1 root sys 0 Oct 6 14:50 testies03
-rw-rw-rw- 1 root sys 0 Oct 6 14:39 testing02
-rw-r--r-- 1 root sys 57 Oct 6 11:46 usilap19

and, from usilign3:
# h
usilign3
# mount usilap19:/testing/temp01 /mnt #shouldnt work
# ll /mnt
total 2
drwxr-xr-x 2 root root 96 Oct 6 11:27 lost+found
-rw-rw-rw- 1 oleary infra 0 Oct 6 11:38 testies
-rw-rw-rw- 1 root sys 0 Oct 6 11:40 testies01
-rw-rw-rw- 1 root sys 0 Oct 6 14:50 testies03
-rw-rw-rw- 1 root sys 0 Oct 6 14:39 testing02
-rw-r--r-- 1 root sys 57 Oct 6 11:46 usilap19
# touch /mnt/testies04
touch: /mnt/testies04 cannot create

At least the roto privilegs aren't available.. I need to get to the point where usilign3 can't mount it at all. Does anyone see what I'm doing wrong?

Thanks for the responses.

Doug O'Leary

[Tim Nelson]

Something like this will restrict access and root only to the listed entities.

share -F nfs -o anon=2,access=servera:serverb,root=servera:serverb -d "APP NFS" /my_app/my_directory

[Doug O'Leary]

And, once again, according to the man page, access= is a no-no...

"To support compatiblity with scripts that still invoke the exportfs command using the access= option, the share command will not fail when the access option is used and the syntax matches the usage of exportfs(1M) from a release of HP-UX that does not support the share(1M) command. Attempts to use the access option with new share options, (i.e. sec=), may result in the access option begin rejected by the share command. It is highly recommended that the access option not be used with the share command. Instead, use the ro= and rw= option to achieve the desired access restrictions. This support of the access= option will be removed in a future release of HP-UX."

Now, I'm having problems with users being able to write to the directories - it says it's a read only filesystem. It's not mounted that way, exported that way, or in any way indicates that. I have to say, I find this incredibly frustrating. This seems indicative of some pretty piss-poor testing.

Doug O'Leary

[Tim Nelson · Accepted solution]

If you specify rw= then it will be write to those listed and ro to the rest of the world.

rw=client[:client] ...
Share the pathname read-mostly if sec= option is not
provided. Read-mostly means read-write to those
clients specified and read-only for all other
systems. If a sec= option is provided, pathname is
shared read/write only to the listed clients. No
other systems can access pathname.

[Doug O'Leary]

Hey;

I got my user write permission problem resolved - turned out to be a name resolution issue. Back in the exportfs/access= days, name resolution issues were easy - it flat out would let you in.

I missed the section about the read-mostly. That sounds like what I'm experiencing so is probably the key to getting the behavior I want. I skimmed over the various types of sec earlier. Looks like it's time to dive a little deeper.

Thanks for the tip.

Doug O'Leary

[Doug O'Leary]

Hey;

Turns out the answer is to use the sec= on both the share and mount commands. sec=sys is the way things work pre 11.31 and is the default for systems that don't support the sec= statement.

The share command looks like

share -F nfs -o sec=sys,rw=${fqdn},root=${fqdn} ${mp}

and mount looks like:

mount -o sec=sys ${sys}:${dir} ${mp}

I appreciate the hints/tips/suggestions.

Doug O'Leary