I recently updated my home desktop to Win7 - I wanted to get the 64 bit professional version and update my system memory to 8G. I managed to loose my Firefox config information - i.e., mainly my accounts and passwords. Not that big of a deal to recover from. I did have a recent backup of my bookmarks, so I didn't loose all of my favorite web comics.

Last night I updated my Linksys wireless router to an Airport Extreme and even though I had all of the config information, that was much more of a pain. Changing routers always is it seems.

I went with the Airport Extreme because I liked the Airport Express I carry around to quickly setup a wireless network when I travel. There was a Hilton Garden Inn in Austin that does not like my Mac Book Air, so the Express solved that issue.

I checked to make sure I could configure port translation (look in the NAT settings) and I assumed I could easily VPN out of it.

The earliest issues I had were all related to getting the internet connection established and understanding the Apple nomenclature. I could not figure out whether the DHCP pane was talking about the external connection or the internal one. I think the internal address is determined by the DHCP range that you offer.

The big problem was that the DSL modem and the Extreme didn't seem to want to communicate. I could ping the Extreme, but couldn't seem to see out. Note, make sure to record an external pingable IP before you change your network infrastructure. Don't count on DNS working!

I put back the Linksys, did some searching, and decided to reboot the DSL modem and then the Extreme. That did the trick. Note that with other routers you might try MAC address cloning to fix this issue. Evidently the DSL router I have is smart enough to detect the MAC address it is connected to upon reboot. But it will also only talk to that one device.

My other issues revolved with the Airport Utility software - making a simple change to the Extreme configuration requires a reboot. And then the Airport Utility software might not be able to detect the Extreme. I rotated among three different clients to make changes.

I got through all that and tried using my Express to extend the Extreme's network. Now I can't see it at all via Airport Utility. And searching the web does not make me feel comfortable about getting Airport Utility to work properly.

The last issue I hit was that my mail server started rejecting requests from my Thunderbird desktop mail client. I don't know how I had my earlier Thunderbird outgoing server set up, but the current one was set to my outside DNS name. The Linksys must have automatically short cut the packet back to my internal server. The Airport Extreme was sending the request back with the external address of my DSL router. And my sendmail config was rejecting the relay request.

The solution here was to modify my mail server account in Thunderbird to be in the internal DNS subdomain.

I'm happy enough with the Airport Extreme - like most Apple products, it takes some getting used to. BTW - the reason I replaced the Linksys was it started locking up - after one "We've lost the internet!" call on a business trip, it is just too much to deal with! :-> I wanted N, dual band, and GigE ports. We'll see if I stay happy with the Airport Extreme...

A colleague came to me with an interesting question. They had a share on a server which allowed root access and could not get chown(1) to work via NFS. They wanted to know why our NFS server implementation denied it.

I immediately ran the test and it worked right off the bat! So now the question was what was different on the two systems? First of all, I tried it with a Linux client:

root@silent:~# mount slammer:/export/slammer /slammer/slammer/
root@silent:~# cd /slammer/slammer/
root@silent:/slammer/slammer# touch sil
root@silent:/slammer/slammer# chown thud sil
root@silent:/slammer/slammer# ls -la sil
-rw-r--r--+ 1 thud root 0 2009-11-11 12:40 sil

To eliminate that as the culprit, I tried an OpenSolaris client:

[root@silver tdh]> mount slammer:/export/slammer /slammer/slammer/
[root@silver tdh]> cd /slammer/slammer/
[root@silver slammer]> touch ver
[root@silver slammer]> chown thud ver
chown: ver: Permission denied

While it appears to be an issue between OpenSolaris and Linux, it is far from the case. The issue is at the NFS protocol layer and I can easily show it by flipping the success on each client!

Working OpenSolaris:

[root@silver slammer]> cd
[root@silver ~]> umount /slammer/slammer/
[root@silver ~]> mount -o vers=3 slammer:/export/slammer /slammer/slammer/
[root@silver ~]> cd /slammer/slammer/
[root@silver slammer]> touch ver_3
[root@silver slammer]> chown thud ver_3
[root@silver slammer]> ls -la ver_3
-rw-r--r--   1 thud     root           0 Nov 11 12:50 ver_3

Broken Linux:

root@silent:~# mount -t nfs4 slammer:/export/slammer /slammer/slammer/
root@silent:~# cd /slammer/slammer/
root@silent:/slammer/slammer# touch sil_4
root@silent:/slammer/slammer# chown thud sil_4
root@silent:/slammer/slammer# ls -la sil_4
-rw-r--r-- 1 thud 4294967294 0 2009-11-11 12:53 sil_4

But wait, you are saying it worked for Linux. Well, no, it did not. If we look at this on the server, we see:

slammer# ls -la sil* ver*
-rw-r--r--   1 2008     root           0 Nov 11 18:40 sil
-rw-r--r--   1 nobody   root           0 Nov 11 18:53 sil_4
-rw-r--r--   1 nobody   nobody         0 Nov 11 18:44 ver
-rw-r--r--   1 2008     root           0 Nov 11 18:50 ver_3

So while the Linux client thinks that it worked, it did not. We can confirm that by remounting with NFSv3:

root@silent:/slammer/slammer# ls -la sil* ver*
-rw-r--r--+ 1 thud       root       0 2009-11-11 12:40 sil
-rw-r--r--+ 1 4294967294 root       0 2009-11-11 12:53 sil_4
-rw-r--r--+ 1 4294967294 4294967294 0 2009-11-11 12:44 ver
-rw-r--r--+ 1 thud       root       0 2009-11-11 12:50 ver_3

And for fun, if we remount with NFSv4:

root@silent:/slammer/slammer# cd
root@silent:~# umount /slammer/slammer/
root@silent:~# mount -t nfs4 slammer:/export/slammer /slammer/slammer/
root@silent:~# cd /slammer/slammer/
root@silent:/slammer/slammer# ls -la sil* ver*
-rw-r--r-- 1 4294967294 4294967294 0 2009-11-11 12:40 sil
-rw-r--r-- 1 4294967294 4294967294 0 2009-11-11 12:53 sil_4
-rw-r--r-- 1 4294967294 4294967294 0 2009-11-11 12:44 ver
-rw-r--r-- 1 4294967294 4294967294 0 2009-11-11 12:50 ver_3

The first thing we normally check in such cases is the mapid domain:

slammer# cat /var/run/nfs4_domain
internal.excfb.com
[root@silver slammer]> cat /var/run/nfs4_domain
internal.excfb.com
root@silent:/slammer/slammer# cat /proc/net/rpc/nfs4.idtoname/content
#domain type id [name]

So I need to get the Linux box in the right domain! Actually, I need to modify '/etc/default/nfs-common' on this Ubuntu system and tell it to run mapid!

Much better:

root@silent:/slammer/slammer# touch sil_4_2
root@silent:/slammer/slammer# chown thud sil_4_2
chown: changing ownership of `sil_4_2': Invalid argument

Now the Linux and OpenSolaris clients are agreeing to behave the same way with the server! What is the issue here?

In NFSv4, we change the owner with a SETATTR compound op:

NFS:  Op = 34 (SETATTR)
NFS:  State ID hash = SPECIAL_0
NFS:      len = 12    val = 000000000000000000000000
NFS:      State ID Sequence ID = 00000000
NFS:    0x00
NFS:    0x00
NFS:    0x00
NFS:    0x00
NFS:    0x10   OWNER
NFS:    0x00
NFS:    0x00
NFS:    0x00
NFS:  Owner = thud@internal.excfb.com

And in NFSv3, we try with this:

NFS:  Proc = 2 (Set file attributes)
NFS:  File handle = [86D5]
NFS:   A76A323408831F040A001500000000003F0C00000A000300000000002D000000
NFS:  Mode = (not set)
NFS:  User ID = 2008
NFS:  Group ID = (not set)
NFS:  Size = (not set)
NFS:  Access time = (do not set)
NFS:  Modification time = (do not set)
NFS:

So in the NFSv4 case, we need to be able to map 'thud@internal.excfb.com' to an user id. If that mapping does not exist, then we disallow the action. In NFSv3, we already have the user id, and we don't care if it is undefined on the server:

slammer# grep thud /etc/passwd
slammer# ls -la sil* ver*
-rw-r--r--   1 2008     root           0 Nov 11 18:40 sil
-rw-r--r--   1 nobody   root           0 Nov 11 18:53 sil_4
-rw-r--r--   1 root     root           0 Nov 11 19:18 sil_4_2
-rw-r--r--   1 nobody   nobody         0 Nov 11 18:44 ver
-rw-r--r--   1 2008     root           0 Nov 11 18:50 ver_3

If we add the user id of thud, we see:

slammer# useradd -u 2009 -g 10 -d /export/slammer thud
slammer# ls -la sil* ver*
-rw-r--r--   1 2008     root           0 Nov 11 18:40 sil
-rw-r--r--   1 nobody   root           0 Nov 11 18:53 sil_4
-rw-r--r--   1 root     root           0 Nov 11 19:18 sil_4_2
-rw-r--r--   1 nobody   nobody         0 Nov 11 18:44 ver
-rw-r--r--   1 2008     root           0 Nov 11 18:50 ver_3

Yes, I did an off by one error on purpose! What happens if we try to chown(1) via NFSv4 now:

root@silent:/slammer/slammer# chown thud base
root@silent:/slammer/slammer# ls -la base sil* ver*
-rw-r--r-- 1 thud   root    0 2009-11-11 13:29 base
-rw-r--r-- 1 nobody root    0 2009-11-11 12:40 sil
-rw-r--r-- 1 nobody root    0 2009-11-11 12:53 sil_4
-rw-r--r-- 1 root   root    0 2009-11-11 13:18 sil_4_2
-rw-r--r-- 1 nobody nogroup 0 2009-11-11 12:44 ver
-rw-r--r-- 1 nobody root    0 2009-11-11 12:50 ver_3

Those 'nobody's should be 'thud' and that 'thud' should not map! What does NFSv3 say:

root@silent:/slammer/slammer# ls -la base sil* ver*
-rw-r--r--+ 1       2009 root       0 2009-11-11 13:29 base
-rw-r--r--+ 1 thud       root       0 2009-11-11 12:40 sil
-rw-r--r--+ 1 4294967294 root       0 2009-11-11 12:53 sil_4
-rw-r--r--+ 1 root       root       0 2009-11-11 13:18 sil_4_2
-rw-r--r--+ 1 4294967294 4294967294 0 2009-11-11 12:44 ver
-rw-r--r--+ 1 thud       root       0 2009-11-11 12:50 ver_3

The NFSv4 listing shows you the username space of the server and the NFSv3 listing shows you the username space of the client.

The big difference is that NFSv4 enforces that both systems understand the name. It doesn't mandate that the names have the same userid, just that they have a mapping.

To get everything in sync, to have both NFSv3 and NFSv4 work the same, use either NIS or LDAP to maintain your user mappings.