HPUX : Replacing a Mirrored Boot Disk

Replacing a Mirrored Boot Disk.

Overview

Replacing a Mirrored Boot Disk

Procedures

There are two additional operations you must perform when replacing a mirrored boot disk: 1. You must initialize boot information on the replacement disk. 2. If the replacement requires rebooting the system, and the primary boot disk is being replaced, you must boot from the alternate boot disk. In this example, the disk to be replaced is at lunpath hardware path 0/1/1/1.0x3.0x0, with device special files named /dev/disk/disk14 and /dev/rdisk/disk14. The system is an HP Integrity server, so the physical volume names must specify the HP-UX partition on the boot disk (/dev/disk/disk14_p2 and /dev/disk/disk14_p2). 1. Save the hardware paths to the disk. Run the ioscan command and note the hardware paths of the failed disk as follows: # ioscan –m lun /dev/disk/disk14 Class I Lun H/W Path Driver S/W State H/W Type Health Description ======================================================================== disk 14 64000/0xfa00/0x0 esdisk CLAIMED DEVICE offline HP MSA Vol 0/1/1/1.0x3.0x0 /dev/disk/disk14 /dev/rdisk/disk14 /dev/disk/disk14_p1 /dev/rdisk/disk14_p1 /dev/disk/disk14_p2 /dev/rdisk/disk14_p2 /dev/disk/disk14_p3 /dev/rdisk/disk14_p3 In this example, the LUN instance number is 14, the LUN hardware path is 64000/0xfa00/0x0, and the lunpath hardware path is 0/1/1/1.0x3.0x0. When the failed disk is replaced, a new LUN instance and LUN hardware path are created. To identify the disk after it is replaced, you must use the lunpath hardware path (0/1/1/1.0x3.0x0). 2. Halt LVM access to the disk. If the disk is not hot-swappable, power off the system to replace it. By shutting down the system, you halt LVM access to the disk, so you can skip this step. If the disk is hot-swappable, detach the device using the –a option of the pvchange command: # pvchange -a N /dev/disk/disk14_p2 NOTE: On an HP 9000 server, the boot disk is not partitioned so the physical volume refers to the entire disk, not the HP-UX partition. Use the following command: # pvchange -a N /dev/disk/disk14 3. Replace the disk. For the hardware details on how to replace the disk, see the hardware administrator’s guide for the system or disk array. If the disk is hot-swappable, replace it. If the disk is not hot-swappable, shut down the system, turn off the power, and replace the disk. Reboot the system. Two problems can occur: If you replaced the disk that you normally boot from, the replacement disk does not contain the information needed by the boot loader. In this case, interrupt the boot process and boot from the mirror boot disk, which is configured as the alternate boot path. If there are only two disks in the root volume group, the system probably fails its quorum check, can panic early in the boot process with the message: panic: LVM: Configuration failure In this situation, you must override quorum to boot successfully. Do this by interrupting the boot process and adding the -lq option to the boot command. 4. Notify the mass storage subsystem that the disk has been replaced. If the system was not rebooted to replace the failed disk, then run scsimgr before using the new disk as a replacement for the old disk. For example: # scsimgr replace_wwid –D /dev/rdisk/disk14 This command allows the storage subsystem to replace the old disk’s LUN World-Wide- Identifier(WWID) with the new disk’s LUN WWID. The storage subsystem creates a new LUN instance and new device special files for the replacement disk. 5. Determine the new LUN instance number for the replacement disk. For example: # ioscan –m lun Class I Lun H/W Path Driver S/W State H/W Type Health Description ======================================================================== disk 14 64000/0xfa00/0x0 esdisk NO_HW DEVICE offline HP MSA Vol /dev/disk/disk14 /dev/rdisk/disk14 /dev/disk/disk14_p1 /dev/rdisk/disk14_p1 /dev/disk/disk14_p2 /dev/rdisk/disk14_p2 /dev/disk/disk14_p3 /dev/rdisk/disk14_p3 ... disk 28 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol 0/1/1/1.0x3.0x0 /dev/disk/disk28 /dev/rdisk/disk28 In this example, LUN instance 28 was created for the new disk, with LUN hardware path 64000/0xfa00/0x1c, device special files /dev/disk/disk28 and /dev/rdisk/disk28, at the same lunpath hardware path as the old disk, 0/1/1/1.0x3.0x0. The old LUN instance 14 for the old disk now has no lunpath associated with it. NOTE: If the system was rebooted to replace the failed disk, then ioscan -m lun does not display the old disk. 6. (HP Integrity servers only) Partition the replacement disk. Partition the disk using the idisk command and a partition description file, and create the partition device files using insf, 1. Create the system, OS, and service partitions # vi /tmp/ipf 3E FI 500MB HPUX 100% HPSP 400MB # idisk -wf /tmp/ipf /dev/rdisk/disk28 2. Create device files for the new partitions # insf -eC disk 3. Verify that the device files were created properly # ioscan -fnNC disk  Check the Agile / persistent device # ioscan –fnC disk  Check the legacy device 7. Assign the old instance number to the replacement disk. For example: # io_redirect_dsf -d /dev/disk/disk14 -n /dev/disk/disk28 This assigns the old LUN instance number (14) to the replacement disk. In addition, the device special files for the new disk are renamed to be consistent with the old LUN instance number. The following ioscan -m lun output shows the result: # ioscan –m lun /dev/disk/disk14 Class I Lun H/W Path Driver S/W State H/W Type Health Description ======================================================================== disk 14 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol 0/1/1/1.0x3.0x0 /dev/disk/disk14 /dev/rdisk/disk14 /dev/disk/disk14_p1 /dev/rdisk/disk14_p1 /dev/disk/disk14_p2 /dev/rdisk/disk14_p2 /dev/disk/disk14_p3 /dev/rdisk/disk14_p3 The LUN representation of the old disk with LUN hardware path 64000/0xfa00/0x0 was removed. The LUN representation of the new disk with LUN hardware path 64000/0xfa00/0x1c was reassigned from LUN instance 28 to LUN instance 14 and its device special files were renamed as /dev/disk/disk14 and /dev/rdisk/disk14. 8. Restore LVM configuration information to the new disk. For example: # vgcfgrestore -n /dev/vg00 /dev/rdisk/disk14_p2 NOTE: On an HP 9000 server, the boot disk is not partitioned, so the physical volume refers to the entire disk, not the HP-UX partition. Use the following command: # vgcfgrestore -n /dev/vg00 /dev/rdisk/disk14 9. Restore LVM access to the disk. If you did not reboot the system in Step 2, “Halt LVM access to the disk,” reattach the disk as follows: # pvchange –a y /dev/disk/disk14_p2 On an HP 9000 server, use this command: # pvchange –a y /dev/disk/disk14 If you did reboot the system, reattach the disk by reactivating the volume group as follows: # vgchange -a y /dev/vg00 NOTE: The vgchange command with the -a y option can be run on a volume group that is deactivated or already activated. It attaches all paths for all disks in the volume group and resumes automatically recovering any disks in the volume group that had been offline or any disks in the volume group that were replaced. Therefore, run vgchange only after all work has been completed on all disks and paths in the volume group, and it is necessary to attach them all. 10. Initialize boot information on the disk. Set up the boot area and update the autoboot file 1. Populate the /efi/hpux/ directory in the new EFI system partition # mkboot -e -l /dev/rdisk/disk14 2. Change the auto file on both boot disks so the host can boot without quorum # vi /tmp/auto boot vmunix –lq # efi_cp -d /dev/rdisk/disk14_p1 /tmp/auto /efi/hpux/auto # efi_cp -d /dev/rdisk/disk15_p1 /tmp/auto /efi/hpux/auto 7. Verify the contents of the system partition # efi_ls -d /dev/rdisk/c5t2d0s1 8. Verify the contents of the auto file in the system partition # efi_cp -d /dev/rdsk/c5t2d0s1 -u /efi/hpux/auto /tmp/auto # cat /tmp/auto.

Keywords.

Mkboot,efi_cp,efi_ls,vgcfgrestore,pvchange.

HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

Overview

Using public key authentication while setting up Secure Shell (SSH) on HP-UX systems

Procedures

Public key authentication is a good choice for user authentication since it provides some of the best security available. The steps outlined below assume that both the client and server are running the HP-supplied version of Secure Shell. This version will interoperate with other platforms and implementations but specific configuration options may differ. On the client node: Generate a key pair using the SSH-keygen program while logged in with the regular user's ID. Generate at least one key pair. If SSH-2 protocol is being used (the default on HP-UX), key types of either DSA or RSA may be chosen. If SSH-1 protocol is going to be used, a key type of RSA1 will need to be used. Generate the keys as:      # ssh-keygen -t dsa        Generating public/private dsa key pair.       Enter file in which to save the key (/home/flyingfox/.ssh/id_dsa):       Enter passphrase (empty for no passphrase):       Enter same passphrase again:       Your identification has been saved in /home/root/.ssh/id_dsa.       Your public key has been saved in /home/root/.ssh/id_dsa.pub.       The key fingerprint is:       a9:11:f6:af:31:45:31:fc:52:25:a1:52:da:bc:0e:3e flyingfox@lei Take the default file name for the location of the key(s) by hitting the Enter key . It is also suggested to use a passphrase to protect the private key. The passphrase may be any string of characters or a phrase, including white space. The SSH-keygen program may be run once for each key type that needs to be generated. Unless there is a reason to use non-default values, just generate the single DSA key pair as shown above. The public key that was just generated must be copied over to the SSH server. The public key will have been placed in a file as noted by the SSH-keygen program but with a .pub at the end of the name. Example: /home/flyingfox/.ssh/id_dsa.pub . Any mechanism may be used to get the key over to the SSH server. For example:    $scp /home/flyingfox/.ssh/id_dsa.pub server:/home/flyingfox/client.key       wilfor@gozo's password:       id_dsa.pub           100% |*****************************|   601       00:00     $ On the server node: Append the client's public key copied over in step 2 above to the end of the file: # cat /home/flyingfox/client.key >> /home/flyingfox/.ssh/authorized_keys If the file or the .ssh subdirectory does not exist, they must be created manually. The SSH daemon (sshd) on the server will check the owner and permissions on the authorized_keys file to be sure it is writable only by the user (and root). If it is not safe , then sshd will ignore the file. A mode of 600 should work well. The SSH server will also check the modes and owners of all the directories in the path to the authorized_keys file to be sure that they are safe as well. Typically, /home should be writable only by root, and the users home directory and the .ssh subdirectory should be writable only by the user (and root). If both the client and server are set up correctly, then there should be a prompt for the passphrase when connecting from the client to the server via SSH (or scp/sftp). If the private key was not protected with a passphrase, then there will not be any prompt and will automatically log in to the server. If providing a passphrase each time the SSH is run is not desired, it is recommended to use the ssh-agent(1) program to cache the keys for an entire session rather than leave the private key un-protected (null passphrase). Leaving the private key un-protected is a security risk if anyone can obtain a copy of the private key file.

Keywords.

RSA,SCP.