OK, On a production server, I want an NFS share to mount automatically. What is the best practice to use?

Or

My understanding is that it is always best practice to use IP addresses in the fstab because the server will fail to mount the share upon booting if DNS is unavailable. I've also been told that if one MUST use names in the fstab, there should be a hosts file entry for it so that the server doesn't depend on DNS on boot.

So, what is the most appropriate best practice?

Hi,

Seems like you already know which is the industry standard, i.e. using IP address in the fstab.
On my client's production servers it's the IP addresses that are being used and the reason you have already mentioned.

Regards.

Actually, this is why you have redundant DNS servers, so that if one DNS server is down, you can use the next, and so on. If all of your DNS servers are unavailable, you probably have bigger issues.

Unless that IP address is a virtual IP used by a clustering solution, or front-ended by a load balancer, you've just given yourself a single point of failure. Also, if you need to re-assign the address to the file server for whatever reason, now you've got to change configurations in a hundred different places, instead of making the change just once in DNS, so you've raised the risk of outages for this otherwise simple configuration change significantly. Depending on your disaster recovery and DR-testing plans, you may have made those more difficult as well.

And I'd have to defer to their superior knowledge on this, but my security department quashed the idea of us using NFS due to security concerns. They were much happier with SMB.

So, without knowing the intimate details of your shop (big/med/small business, SLAs, etc.), I'd say this implementation is the opposite of industry standards.

For servers, one could include them in /etc/hosts and for some servers some people even include their entries in /etc/ethers, and load their mac addresses to help prevent arp spoofing on the LAN. The later would be most helpful for name servers and gateways to help prevent arp spoofing.

- I agree with SL00b: Using IP addresses makes a future address change a nightmare; I think it's better to use hostnames and let the redundant DNS system do the resolving.
- I like to use a timeo on NFS mounts; otherwise, if the NFS servers hangs, the client might too.

Noted Sl00b's correct comment on NFS (un)safety, but I don't care too much on my home network.
@amonamarth: can you explain 'timeo' to me? Is it a NFS option which I could add to fstab? If so, it might solve a NFS mount at boot time problem I'm struggling with.

That is a mount option on the client's side, I also use "soft mount" in conjunction with timeouts.
If the NFS server goes down, if you do a hard mount, the client will hang, sometimes requiring a reboot; whereas, if you use a soft mount with a timeout, the client will eventually "time out" and the file system simply gets unmounted.

For example, on the client's /etc/fstab:

nfs_server:/some/directory /mnt/nfs nfs defaults,timeo=14,soft 0 0

From nfs man page:
timeo=n
The value in tenths of a second before sending the first retransmission after an RPC timeout.
The default value is 7 tenths of a second. After the first timeout, the timeout is doubled
after each successive timeout until a maximum timeout of 60 seconds is reached or the enough
retransmissions have occured to cause a major timeout.

soft
If an NFS file operation has a major timeout then report an I/O error to the calling
program. The default is to continue retrying NFS file operations indefinitely.

@amonamarth Thanks for the RTM. Indeed I had overlooked the 'timeo=' option. (Probably reminded me of 'timeo Danaos et dona ferentis'...)

Meanwhile I've tried the 'soft', 'intr' and 'timeo=' options in various combinations, but they either didn't change the long time for mounting NFS shares, or returned error messages about rpc.statd not running or nolock/lock issues. Finally, after studying this Linux NFS-HowTo on Sourceforge.net, I concluded to mount with 'nosuid,hard,intr'. It's still slow, but works well.

Arguments:
- 'nosuid' keeps the client safer from the server
- 'hard' avoids data loss
- 'intr' should interrupt in case of hanging client/server communication

Still thanks for your comments -- they made me search better.