Few commands I use often in HP-UX; Coming from over 15 years of Linux experience, the quirks in HP-UX can get annoying at first, but hopefully this will help you through it!

Sick of your backspace key not working? Here’s your answer:


stty erase ^?

Annoyed with the shitty output of df?


bdf

Trying to figure out what the model/arch of the server is?


model

This lists a few different thing… disk related, and/or fibre channel cards:


ioscan -fnNkC disk
ioscan -fnkC disk
ioscan -fnkC
ioscan -m lun
ioscan -m dsf

How do I configure which mirror to boot from!?


setboot -v (verify/list)
setboot -a (alt)
setboot -p (primary)

I miss yum/apt-get:


swinstall -s /full/path/to/depotfile.depot \*
swinstall -x autoreboot=true -s /full/path/to/depotfile.depot \*

The \* is pretty cool, it prevents the TUI/GUI from loading, but continues the install/dep check. Makes it feel more like yum or apt-get, instead of aptitude or a GUI update manager.

AHHH usermod and passwd are missing flags in HP-UX! No, just use modprpw instead!


/usr/lbin/modprpw -v (refresh/validate all accounts)
/usr/lbin/modprpw -k -l username (unlock/enable [k] a local account [l])

This will reset the expiration of a locked account.

Where the fuck are the init.d and rc scripts?!


/sbin
/sbin/init.d/

How can I figure out the current runlevel?!


who -r

I miss bash, how can I auto-complete a command?!


Like bash, type a few letters of the prefix, but instead of tab, hit:
esc twice

WTF?! No history command?!?! Lies, hit esc+k – then use j/k to cycle forward/backwards respectively. To edit a line you scroll to, it’s interactive vi in ksh… so ‘l’ to move foward, shift+R to replace, etc…

Here are my notes on how to remove and replace a dead mirrored drive on HP-UX 11i v3:

Remove bad mirrored boot disk HP-UX:

Check for stale LEs:


lvdisplay -v -k /dev/vg00/lvol# (1-7 is normal, however your system might have more) (to get key for the next command)

Next we need to remove the bad drive from the LVM, so let’s reduce the lvols (the last integer is the key from the last lvdisplay command):


lvreduce -m 0 -A n -k /dev/vg00/lvol1 0
lvreduce -m 0 -A n -k /dev/vg00/lvol2 0
lvreduce -m 0 -A n -k /dev/vg00/lvol3 0
lvreduce -m 0 -A n -k /dev/vg00/lvol4 0
lvreduce -m 0 -A n -k /dev/vg00/lvol5 0
lvreduce -m 0 -A n -k /dev/vg00/lvol6 0
lvreduce -m 0 -A n -k /dev/vg00/lvol7 0

Now that we’ve reduced the mirror, let’s remove partition 2 from the volgroup:


vgreduce /dev/vg00 /dev/disk/disk62_p2

If we can’t reduce because it’s critically failed, then we need to do this:


vgreduce –f /dev/vg00 /dev/disk/disk62_p2
vgscan –f /dev/vg00

Then confirm:


vgdisplay -v vg00

Here’s an example of a DEAD drive from ioscan:


disk 62 64000/0xfa00/0xd esdisk NO_HW DEVICE offline HP 36.4GST336753LC
2/0/0/2/0.0x6.0x0
/dev/disk/disk62 /dev/disk/disk62_p2 /dev/rdisk/disk62 /dev/rdisk/disk62_p2
/dev/disk/disk62_p1 /dev/disk/disk62_p3 /dev/rdisk/disk62_p1 /dev/rdisk/disk62_p3

Example of REPLACED drive with the old DEAD DSF – Map DSF then Re-add to VG:

STEP1: In order to see the new drive, you need to do this first (AFTER NEW DRIVE IS INSERTED): scsimgr replace_wwid –D /dev/rdisk/disk62


...
disk 62 64000/0xfa00/0xd esdisk NO_HW DEVICE offline HP 36.4GST336753LC
/dev/disk/disk62 /dev/disk/disk62_p2 /dev/rdisk/disk62 /dev/rdisk/disk62_p2
/dev/disk/disk62_p1 /dev/disk/disk62_p3 /dev/rdisk/disk62_p1 /dev/rdisk/disk62_p3

disk 219 64000/0xfa00/0x20 esdisk CLAIMED DEVICE online HP 36.4GST336753LC
2/0/0/2/0.0x6.0x0
/dev/disk/disk219 /dev/rdisk/disk219
...

STEP2: Formart disk219


echo "3" > /tmp/partitionfile
echo "EFI 500MB" >> /tmp/partitionfile
echo "HPUX 100%" >> /tmp/partitionfile
echo "HPSP 400MB" >> /tmp/partitionfile

idisk -wf /tmp/partitionfile /dev/rdisk/disk219
ioscan -fnNC disk
insf -e -C disk

STEP3: Then you can map the new DSF to the old one:


io_redirect_dsf -d /dev/disk/disk62 -n /dev/disk/disk219

STEP4: Make Bootable and fix EFI partitions:


mkboot -e -l /dev/rdisk/disk62
efi_ls -d /dev/rdisk/disk62_p1
lifls -l /dev/rdisk/disk62_p2
mkboot -a "boot vmunix -lq" /dev/disk/disk62
efi_cp -d /dev/rdisk/disk62_p1 -u /EFI/HPUX/AUTO /tmp/x; cat /tmp/x;rm /tmp/x

STEP5: Create PV, Extend VG, and Extend LVs:


pvcreate -f -B /dev/rdisk/disk62_p2
vgextend /dev/vg00 /dev/disk/disk62_p2

lvextend -m 1 /dev/vg00/lvol1 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol2 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol3 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol4 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol5 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol6 /dev/disk/disk62_p2
lvextend -m 1 /dev/vg00/lvol7 /dev/disk/disk62_p2
lvlnboot -r /dev/vg00/lvol3
lvlnboot -b /dev/vg00/lvol1
lvlnboot -s /dev/vg00/lvol2
lvlnboot -d /dev/vg00/lvol2
lvlnboot -R
lvlnboot -v

STEP6: Verify VG and boot paths


vgdisplay -v vg00
setboot -v

If the mirrored disk fails to boot from EFI, boot off the alternate working one, and re-execute setboot -v with the device path (even though it might already be set, set it again since the wwid change).

Extend an LVM volume in Linux

April 24th, 2012 | Posted by spritian in Linux | LVM - (3 Comments)

One of my clients needed to expand their DB since it was at 96% utilization. Thankfully, it was already in a volume group. Here are the steps I took to add a new LUN to the VG and expand it.

First, use fdisk to find the new LUN that doesn’t have a partition table and then use fdisk to create a new partition on it as Linux LVM:


[root@redhat ~]# fdisk -l
[trimmed]

Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdf doesn't contain a valid partition table

[root@redhat ~]# fdisk /dev/sdf
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 52216.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-52216, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-52216, default 52216):
Using default value 52216

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdf1 1 52216 419424988+ 8e Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

[root@redhat ~]# fdisk -l
[trimmed]

Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdf1 1 52216 419424988+ 8e Linux LVM

Now that the partition table is setup correctly, let’s create a new LVM on the drive, and extend our existing volume group using the new physical LUN.


[root@redhat ~]# pvcreate /dev/sdf1
Physical volume "/dev/sdf1" successfully created

[root@redhat ~]# vgextend ora_vg1 /dev/sdf1
Volume group "ora_vg1" successfully extended

Here you can see our physical extents has increased due to the addition of the new physical drive to the volume group:


[root@redhat ~]# vgdisplay
--- Volume group ---
VG Name ora_vg1
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 1.18 TB
PE Size 32.00 MB
Total PE 38555
Alloc PE / Size 25728 / 804.00 GB
Free PE / Size 12827 / 400.84 GB
VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY

[root@redhat ~]# lvdisplay
--- Logical volume ---
LV Name /dev/ora_vg1/lvol_d03
VG Name ora_vg1
LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar
LV Write Access read/write
LV Status available
# open 1
LV Size 749.00 GB
Current LE 23968
Segments 4
Allocation inherit
Read ahead sectors 0
Block device 253:4

I only wanted to allocated ~75% of the new LUN to lvol_d03, so I took the Current LE 23968 from the previous lvdisplay. I prefer to actually distribute via Extents, rather than the easy way of +G, etc. So I added 9827 extents (from a total of 12827 free) to the existing 23968, totaling 33795:


[root@redhat ~]# lvextend -l 33795 /dev/ora_vg1/lvol_d03
Extending logical volume lvol_d03 to 1.03 TB
Logical volume lvol_d03 successfully resized

[root@redhat ~]# lvdisplay
--- Logical volume ---
LV Name /dev/ora_vg1/lvol_d03
VG Name ora_vg1
LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar
LV Write Access read/write
LV Status available
# open 1
LV Size 1.03 TB
Current LE 33795
Segments 5
Allocation inherit
Read ahead sectors 0
Block device 253:4

[root@redhat ~]# vgdisplay
--- Volume group ---
VG Name ora_vg1
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 10
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 1.18 TB
PE Size 32.00 MB
Total PE 38555
Alloc PE / Size 35555 / 1.09 TB
Free PE / Size 3000 / 93.75 GB
VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY

Above you can see we still have 3000 extents available. I tend to leave a little as wiggle room so if we ever get into a position of running out of space we aren’t screwed. 🙂

Now that LVM has extended the volume group, we need to have the filesystem recognize it:
(This box didn’t have ext3online (older kernel; 2.6.9), so just decided to do it the old school way…)


[root@redhat ~]# resize2fs /dev/mapper/ora_vg1-lvol_d03
resize2fs 1.35 (28-Feb-2004)
/dev/mapper/ora_vg1-lvol_d03 is mounted; can't resize a mounted filesystem!

[root@redhat /]# umount /prod/d03

[root@redhat /]# e2fsck -f /dev/mapper/ora_vg1-lvol_d03
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/ora_vg1-lvol_d03: 128/98172928 files (14.8% non-contiguous), 195569167/196345856 blocks

[root@redhat /]# resize2fs /dev/mapper/ora_vg1-lvol_d03
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/mapper/ora_vg1-lvol_d03 to 276848640 (4k) blocks.
The filesystem on /dev/mapper/ora_vg1-lvol_d03 is now 276848640 blocks long.

That’s it, now the moment of truth…


[root@redhat /]# mount -a

[root@redhat /]# df -h
[trimmed]

/dev/mapper/ora_vg1-lvol_d03
1.1T 735G 306G 71% /prod/d03

Woot, all good! (749GB to 1.1TB)

Rescan SCSI bus on Linux

April 24th, 2012 | Posted by spritian in Linux - (0 Comments)

Thought this might be helpful:


echo "- - -" > /sys/class/scsi_host/host0/scan

or if you have an HP storage array (EVA, etc)


hp_rescan -a

Then just do fdisk -l to see if it’s presented or not!

HP IRTC / HP-UX Patch Management Link

April 23rd, 2012 | Posted by spritian in HP-UX - (1 Comments)

For those who manage HP-UX, the new IRTC link is at https://h20566.www2.hp.com/portal/site/hpsc/patch/home/

No password sudo

April 23rd, 2012 | Posted by spritian in Linux - (1 Comments)

For those who are lazy, or sick of typing your password everytime… append the following to /etc/sudoers:


%yourusername ALL = NOPASSWD: ALL

Please don’t do this on any production boxes, lol.

Pretty easy, but does need some requirements. You have to be root; Installing via sudo won’t keep the export variables listed below:


sudo su -
cd /root
apt-get install perl-doc libssl-dev libxml-libxml-perl
tar -zxvf VMware-vSphere-CLI-5.0.0-422456.x86_64.tar.gz
cd /root/vmware-vsphere-cli-distrib
export http_proxy=""
export ftp_proxy=""
./vmware-install.pl

Here’s an old article I wrote on how to do a DLE on Solaris with Veritas…

This article will give you a step by step guide on how to configure a DLE with VeritasVM on Sun Solaris. In a recent scenario for one of our clients, it was imperative that we manage this via DLE, rather than spanning an existing disk group with another LUN. It is always a good idea to perform and sucessfully execute a test first. In our findings, this is what we came up the second time around (Our first test, well, was rather interesting – When it comes to DLE, you must execute it with the VX tools, traditional Solaris volume managing will DESTROY the volume groups). The key thing to understand when expanding a diskgroup that only has 1 diskgroup, is that you need a temporary diskgroup before you can resize successfully. That is what this article will cover.

First things first, you need to unmount and deport your disk group before having the expansion done on the SAN:


root@solaris [/] # umount /p01

root@solaris [/] # vxdg deport oraproddg

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk - - online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online

root@solaris [/] # vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk - (oraproddg) online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online

Above you can see the disk group removed from the first vxdisk list. The second command appends -o alldgs, which shows you all disk groups deported or exported – very handy.

At this point, we waited for our SAN engineer to expand the volume on the device itself and represent it back to us.

NOTE: IN ORDER TO DO A DLE, YOU NEED ANOTHER DISK/LUN IN THE DISK GROUP YOU WANT TO EXPAND. THIS IS NEEDED FOR RESIZING ONLY! IT CAN THEN BE REMOVED/DESTROYED.

After our first test, we realized we needed another disk/lun presented so we could add it to the disk group. Our SAN engineer then presented LUN0 with added space, and a NEW TEMPORARY LUN (LUN5) for expanding LUN0.

Once it’s presented, do the usual devfsadm -vC, cfgadm -al, and vxdctl enable. Make sure that after you format/label the temporary LUN, that you vxdisk scandisks. this should prompt it from going to error to online invalid. Finish up by initializing the new temporary LUN (vxdisksetup -i). Here’s a list of the commands I executed to get the new LUN up and added to the oraproddg.


root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online
c2t54d5s2 auto - - error

root@solaris [/] # format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
[trimmed]

9. c2t54d5/pci@7c0/pci@0/pci@8/SUNW,emlxs@0/fp@0,0/ssd@w50060e80141a5051,5
Specify disk (enter its number): 9
selecting c2t54d5
[disk formatted]

format> label
Ready to label disk, continue? y

format> quit

root@solaris [/] # vxdisk scandisks

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online
c2t54d5s2 auto:none - - online invalid

root@solaris [/] # vxdisksetup -i c2t54d5

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online
c2t54d5s2 auto:cdsdisk - - online

root@solaris [/] # vxdg -g oraproddg adddisk temp=c2t54d5s2

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online
c2t54d5s2 auto:cdsdisk temp oraproddg online

Now that the temporary LUN is assigned to the main diskgroup (temp->oraproddg), you can run the resize commands and remove the temp diskgroup:


root@solaris [/] # vxdisk -g oraproddg resize c2t54d0s2

root@solaris [/] # vxdg -g oraproddg rmdisk temp

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online
c2t54d5s2 auto:cdsdisk - - online

Before removing the temporary LUN, I like to finish up the rest of the resizing process. Next we want to run vxprint -g oraproddg -htr to obatain the new size of the volume group.


root@solaris [/] # vxprint -g oraproddg -htr
[trimmed]

dg oraproddg default default 17000 1208985048.25.solaris

dm oraproddg01 c2t54d0s2 auto 65536 291551488 -

v volp01 - DISABLED ACTIVE 209627136 SELECT - fsgen
pl volp01-01 volp01 DISABLED ACTIVE 209627136 CONCAT - RW
sd oraproddg01-01 volp01-01 oraproddg01 0 209627136 0 c2t54d0 ENA

Here you can see the difference from the DM (291551488) and the V (209627136). It’s best to use vxassist to get the correct block value for expanding. (Also, make sure your volumes are started if you haven’t done so already):


root@solaris [/] # vxvol -g oraproddg startall

root@solaris [/] # vxassist -g oraproddg maxgrow volp01
Volume volp01 can be extended by 81924096 to: 291551232 (142359Mb)

root@solaris [/] # vxassist -g oraproddg growto volp01 291551232

root@solaris [/] # vxprint -g oraproddg -htr
[trimmed]

dg oraproddg default default 17000 1208985048.25.solaris

dm oraproddg01 c2t54d0s2 auto 65536 291551488 -

v volp01 - ENABLED ACTIVE 291551232 SELECT - fsgen
pl volp01-01 volp01 ENABLED ACTIVE 291551232 CONCAT - RW
sd oraproddg01-01 volp01-01 oraproddg01 0 291551232 0 c2t54d0 ENA

You can now see that veritas sees the filesystem growth… last step is we need to mount the volume, and grow it on the solaris side:


root@solaris [/] # mount -F vxfs /dev/vx/dsk/oraproddg/volp01 /p01

root@solaris [/] # fsadm -b 291551232 /p01
(Note: The blocksize specified here is exactly the same as the total value used with vxassist growto!)

Lastly, let’s remove our temporary LUN…


root@solaris [/] # vxdisk rm c2t54d5s2

root@solaris [/] # vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t54d0s2 auto:cdsdisk oraproddg01 oraproddg online
c2t54d1s2 auto:cdsdisk archlogsdg01 archlogsdg online
c2t54d2s2 auto:cdsdisk oraproddbdg01 oraproddbdg online

Now that we’re all cleaned up… check the data! Everything should be good to go. 🙂

Mac OSX 10.7.3 on ESXi 5

April 18th, 2012 | Posted by spritian in Mac OSX | VMware - (1 Comments)

So, I know this can be done by using a USB drive and VT-d, but that’s meh. I’ve been working on getting my Workstation image working on my ESXi host, and getting close… anyways, here’s a good start for booting it on ESXi:


boot -v -f -x rd=disk0s2 npci=0x2000

Still seems to stall after DMOS has arrived, will have to mess with it later!

Teradici Management Console 1.7.1

April 17th, 2012 | Posted by spritian in PCoIP | VMware - (1 Comments)

Just a quick note to help other ESXi 5 admins… The package Teradici provides for this gives an ollllld vmx and vmdk. The simplest way to get it to work on ESXi 5 is to convert the disk like so:


vmkfstools -i teradici.vmdk teradici-new.vmdk -d thin

Do this via ssh on the ESXi host… Next, edit the settings of the vmx in vSphere, remove the unsupported devices, and add a new Hard Drive attaching the converted disk. Lastly, upgrade the Hardware to version 8 and it should work flawlessly!