From Wiki-UX.info

Wiki-UX / How to troubleshoot make net recovery NFS mount errors
Jump to: navigation, search

How to troubleshoot make net recovery NFS mount errors

Abstract

This article present how to perform basic NFS configuration and troubleshooting of the Ignite-UX make_net_recovery command. On the examples following example, swtape01 is the Ignite-UX server and delta is the client.

Contents


Ignite-UX and NFS

The Ignite-UX make_net_recovery commands uses NFS for primary task.

  1. Ignite-UX client install and recovery configuration files under /var/opt/ignite/clients
  2. Ignite-UX client recovery archives under /var/opt/ignite/recovery/archives/<hostname>

The NFS problems can be classified in three categories:

  1. Incorrect directory permissions
  2. Missing NFS share entries
  3. Host name resolution

Incorrect directory permissions

Both /var/opt/ignite and /var/opt/ignite/recovery/archives/<hostname> directories must be owned by bin:bin. The archive directory must be writable by the owner.

d 0555  12 bin        bin           8192 Oct 12 13:17 /var/opt/ignite
d 0755   2 bin        bin             96 Oct 13 18:27 /var/opt/ignite/recovery/archives/delta

Missing NFS share entries

The first time that an Ignite-UX client is added for recovery using the GUI or TUI interface (/opt/ignite/bin/ignite), NFS share entries /var/opt/ignite and /var/opt/ignite/recovery/archives/<hostname> are added to /etc/exportfs or /etc/dfs/dfstab (HP-UX 11i v3). For each successive client client, the correspondent archive share will be added.

Is very uncommon to have problems related with the NFS share /var/opt/ignite. This directory is created during the product installation and the NS share added the first time that a client is added with the administration interface. Since is write open for every client, no permissions errors occur. Occasionally, when the Ignite-UX server has just be installed, but not client has been added, it may be required to manually add the entry.

Verify that the /var/opt/ignite directory exists, is owned by bin:bin and its permissions are set to 0755.

if [[ -d /var/opt/ignite ]]; then
 ls -ld /var/opt/ignite
else
 mkdir -m 0755 /var/opt/ignite
 chown bin:bin /var/opt/ignite
fi

Likewise, the corresponding NFS share will be:

/var/opt/ignite/clients -anon=2

The anon=2 ensures that the root NFS mount sessions initiated during the make_net_recovery are mapped to the bin user.

A more usual situation, is that the GUI or TUI interface has not been used to add the clients for recovery, but the make_net_recovery is executed directly on the client. While all the client data will be correctly saved because of the existence of the /var/opt/ignite NFS share, the command will a failure to mount the NFS archive share /var/opt/ignite/recovery/archives/<hostname>.

The error message will be similar to:

# make_net_recovery -n 1 -x inc_entire=vg00 -s swtape01
       * Creating NFS mount directories for configuration files.

=======  10/21/09 18:27:02 CDT  Started make_net_recovery. (Wed Oct 21 18:27:02
         CDT 2009)
         @(#)Ignite-UX Revision C.7.9.260
         @(#)ignite/net_recovery (opt) Revision:
         /branches/IUX_RA0909_WEB/ignite/src@78846 Last Modified: 2009-08-13
         14:15:12 -0600 (Thu, 13 Aug 2009)

       * Checking Versions of Recovery Tools
       * Scanning system for IO devices...
       * Boot device is: 0/1/1/0.0x1.0x0
       * Creating System Configuration.
       * /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
         0156004A2FA/recovery/2009-10-21,18:27/system_cfg vg00
       * Backing Up Volume Group /dev/vg00
       * /usr/sbin/vgcfgbackup /dev/vg00
       * Creating Map Files for Volume Group /dev/vg00
       * /usr/sbin/vgexport -s -p -m /etc/lvmconf/vg00.mapfile /dev/vg00

       * Creating Control Configuration.
       * Creating Archive File List
       * Creating Archive Configuration

       * /opt/ignite/lbin/make_arch_config -c /var/opt/ignite/recovery/client_m
         nt/0x00156004A2FA/recovery/2009-10-21,18:27/archive_cfg -g /var/opt/ig
         nite/recovery/client_mnt/0x00156004A2FA/recovery/2009-10-21,18:27/flis
         t -n 2009-10-21,18:27 -r pa -b 64 -d Recovery\ Archive -L
         /var/opt/ignite/recovery/arch_mnt -l
         swtape01:/var/opt/ignite/recovery/archives/delta -i 1 -m t
       * Saving the information about archive to
         /var/opt/ignite/recovery/previews
       * Creating The Networking Archive

nfs mount: swtape01:/var/opt/ignite/recovery/archives/delta: Permission denied
ERROR:   Unable to mount or write
         swtape01:/var/opt/ignite/recovery/archives/delta
         On swtape01 you may need to:
         mkdir -p /var/opt/ignite/recovery/archives/delta
         chown bin:bin /var/opt/ignite/recovery/archives/delta

         If the OS on swtape01 is 11.31 or later, vi /etc/dfs/dfstab. The
         /etc/dfs/dfstab file on "swtape01" should contain the entry: "share -F
         nfs -o sec=sys,anon=2,rw=<client>
         /var/opt/ignite/recovery/archives/delta". Where <client> is replaced
         by a fully qualified client name.
         After editing the /etc/dfs/dfstab file, run "shareall -F nfs"
         If you need to change the owner of the directory,
         you will also need to re-share the directory.

         Otherwise, vi /etc/exports. The /etc/exports file on "swtape01" should
         contain the entry: "/var/opt/ignite/recovery/archives/delta
         -anon=2,access=delta".
         After editing the /etc/exports file, run exportfs -av
         If you need to change the owner of the directory,
         you will also need to re-export the directory.

         See make_net_recovery(1M) for more information.
ERROR:   Failed to Create NFS mount Archive directory.


=======  10/21/09 18:29:02 CDT  make_net_recovery completed unsuccessfully

Under this condition, normally the error can be corrected creating the client archive directory and adding the missing NFS share to the /etc/exportfs file. The following script can be used to verify that boot the archive directory and NFS share entry exists. Replace <hostname> with your Ignite-UX client host name.

cat >> /tmp/uxshare.sh << EOF
export uxclient=<hostname>
 
if [[ -d /var/opt/ignite/recovery/archives/$uxclient ]]; then
 ls -ld /var/opt/ignite/recovery/archives/$uxclient
else
 mkdir -m 0755 /var/opt/ignite/recovery/archives/$uxclient
 chown bin:bin /var/opt/ignite/recovery/archives/$uxclient
fi
 
grep $uxclient /etc/exports
if [[ $? -gt 0 ]]; then
 echo "/var/opt/ignite/recovery/archives/$uxclient -anon=2,access=$uxclient" >> /etc/exports
 exportfs -auv
 exportfs -av
fi
EOF
# sh /tmp/uxshare.sh

Host name resolution

To prevent network archives from other Ignite-UX client to overwrite previously create ones, the access=<hostname> security option is added to the NFS archive shares.

The Ignite-UX server NFS server must correctly resolve the client host name to the entry provided NFS share. A quick way to test resolution, is login from the client into the Ignite-UX server and user the who -R command to verify how is the client host name is resolved.

This situation is of special consideration on multi-homed Ignite-UX servers, when the client may establish a NFS connection from a IP Address different than the expected client host name. Perform any required updates on your name resolve service (files, dns, ldap, nis).

Consult your network administrator in case of doubt.

Example:

# ssh -Y -l root swtape01
Password:

(c)Copyright 1983-2000 Hewlett-Packard Co.,  All Rights Reserved.
(c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California
(c)Copyright 1980, 1984, 1986 Novell, Inc.
(c)Copyright 1986-1992 Sun Microsystems, Inc.
(c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology
(c)Copyright 1989-1993  The Open Software Foundation, Inc.
(c)Copyright 1986 Digital Equipment Corp.
(c)Copyright 1990 Motorola, Inc.
(c)Copyright 1990, 1991, 1992 Cornell University
(c)Copyright 1989-1991 The University of Maryland
(c)Copyright 1988 Carnegie Mellon University
(c)Copyright 1991-2000 Mentat Inc.
(c)Copyright 1996 Morning Star Technologies, Inc.
(c)Copyright 1996 Progressive Systems, Inc.
(c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved.


                           RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause in DFARS 252.227-7013.

                           Hewlett-Packard Company
                           3000 Hanover Street
                           Palo Alto, CA 94304 U.S.A.

Rights for non-DOD U.S. Government Departments and Agencies are as set
forth in FAR 52.227-19(c)(1,2).
You have mail.

Value of TERM has been set to "xterm".
WARNING:  YOU ARE SUPERUSER !!

root@swtape01:> # who -R
root       console      Oct 16 09:34  (swtape01)
root       pts/0        Oct 16 09:34  (swtape01:0.0)
root       pts/ta       Oct 21 16:16  (amarin3.americas.hpqcorp.net)
root       pts/1        Oct 21 17:57  (delta)

root@swtape01:> # ping delta -n 4
PING delta: 64 byte packets
64 bytes from 16.90.154.233: icmp_seq=0. time=0. ms
64 bytes from 16.90.154.233: icmp_seq=1. time=0. ms
64 bytes from 16.90.154.233: icmp_seq=2. time=0. ms
64 bytes from 16.90.154.233: icmp_seq=3. time=0. ms

----delta PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/0

root@swtape01:> # exit
logout root
Connection to swtape01 closed.

Section 3

Reference

Authors

This page was last modified on 22 July 2011, at 16:04. This page has been accessed 6,926 times.