Tuesday, June 12, 2007

Bug in JET

I've recently started using JET to do Custom Jumpstarts on all of my systems. Its really a wonderful tool, and I can have a system deployed much more quickly than doing an Interactive Jumpstart. Today, I stumbled upon a particularly annoying bug in JET. One of my systems that I hadn't used JET to Jumpstart wasn't able to mount NFS exports from a system I had used JET to Jumpstart. On the system I was trying to mount the exports from, I would get this error message on the console after each attempt:

Jun 12 15:17:34 galileo nfs: [ID 609956 kern.warning] WARNING: NFSMAPID_DOMAIN does not match the server: alnitak domain.
Jun 12 15:17:34 galileo Please check configuration

I looked at /etc/default/nfs on the NFS client everything looked OK; however, when I looked on the server I discovered:

# Specifies to nfsmapid daemon that it is to override its default
# behavior of using the DNS domain, and that it is to use 'domain' as
# the domain to append to outbound attribute strings, and that it is to
# use 'domain' to compare against inbound attribute strings.

That's something I've definitely never noticed in /etc/default/nfs before, so next, I looked at the JET template for the NFS server and found this:

# NFSv4
# Set up the NFSv4 domain to prevent being prompted at first reboot.
# If not set, this will default to the entry in base_config_dns_domain,
# and if that is not set, to the value 'domain', which is the default
# in /etc/default/nfs

This makes sense, but base_config_dns_domain isn't set in my template for the NFS server. So the sum of the bug is that JET should set base_config_nfsv4_domain to 'domain' if base_config_dns_domain is nil; however, it does not do this, and instead, sets it to 'dynamic'. Once I changed the NFS client's NFSMAPID_DOMAIN in /etc/default/nfs to 'dynamic' everything was back to normal.