Converting VMAX NAA Values

Quick bash script I put together to convert VMAX NAAs into the values seen within PowerPath on Linux hosts. There's a PowerShell script floating around the internet to do the same thing but nothing in bash.

#!/bin/bash
# (C) 2014 Derek Morton
# Licensed under GPL 2.0

naa=$1  
naalen=${#naa}

if [ $naalen == 32 ]; then  
        device1=${naa:24:2}
        device2=${naa:26:2}
        device3=${naa:28:2}
        device4=${naa:30:2}
        echo "Frame/Symmetrix ID: ${naa:16:4}/${naa:8:12}"
        echo -e "Logical Device: \x$device1\x$device2\x$device3\x$device4"

elif [ $naalen == 36 ]; then  
        device1=${naa:28:2}
        device2=${naa:30:2}
        device3=${naa:32:2}
        device4=${naa:34:2}
        echo "Frame/Symmetrix ID: ${naa:20:4}/${naa:12:12}"
        echo -e "Logical Device: \x$device1\x$device2\x$device3\x$device4"

else  
        echo "NAA Value must be 32 or 36 characters"
        echo "ex: 6090a038f0cd4e5bdaa8248e6856d4fe"
        echo "or: naa.6090a038f0cd4e5bdaa8248e6856d4fe"
fi  

Sample output:

$ ./naa_to_powerpath.sh 60000970000295700173533034373635
Frame/Symmetrix ID: 0173/000295700173  
Logical Device: 4765

# powermt display dev=emcpowera
Pseudo name=emcpowera  
Symmetrix ID=000295700173  
Logical device ID=4765  
state=alive; policy=SymmOpt; queued-IOs=0  

HBA/bfa bio.c panic on boot

Came across a server with dual Broadcom/QLogic 815 HBAs that was failing to boot with the following error and dropping into debug mode:

LOG Firmware heartbeat failure at 0
LOG bfa panic bio.c:1233: 0

hba-boot-error

Entering the HBA BIOS with CTRL+B or ALT+B was also failing with the same error; I was able to get the server to boot by holding down the 'x' key when the HBA BIOS appeared.

Once actually SSH'ed into the server I discovered that the HBAs had different versions of the HBA Boot Code/Option ROM (3.0.1.0 vs. 3.0.3.1) which caused the error message on boot:

[root@db1 ~]# bcu adapter --query 1
Adapter Information:  
    model info:        Brocade-815
    OEM info:          N/A
    num ports:         1
    hw path:           0000:06
    Serial Num:        xxxxxxxxxx
    name:
PCI Information:  
    vendor id:         0x1657
    device id:         0x0017
    ssvid:             0x1657
    PCIe Gen:          Gen2
    PCIe lanes:        8(Initial number of lanes = 8)
    PCI function0:
            ssid:      0x0014
            port:      0
            type:      FC
Port Information:  
    Port 0:
            name:
            pwwn:      xxxxxxxxxx
            nwwn:      xxxxxxxxxx
            hwpath:    0000:06:00.0
Flash Information:  
    status:            good
    option ROM version:
            current:   3.0.1.0
            flashed:   3.0.1.0
    fw version:        3.2.1.0
[root@db1 ~]# bcu adapter --query 2
Adapter Information:  
    model info:        Brocade-815
    OEM info:          N/A
    num ports:         1
    hw path:           0000:07
    Serial Num:        xxxxxxxxxx
    name:
PCI Information:  
    vendor id:         0x1657
    device id:         0x0017
    ssvid:             0x1657
    PCIe Gen:          Gen2
    PCIe lanes:        8(Initial number of lanes = 8)
    PCI function0:
            ssid:      0x0014
            port:      0
            type:      FC
Port Information:  
    Port 0:
            name:
            pwwn:      xxxxxxxxxx
            nwwn:      xxxxxxxxxx
            hwpath:    0000:07:00.0
Flash Information:  
    status:            good
    option ROM version:
            current:   3.0.3.1
            flashed:   3.0.3.1
    fw version:        3.2.1.0

Once the HBA boot code was updated to the current versions on both cards the server is now booting properly again.

raxmon - Malformed Response

From Github Issues Page

When using the latest version of raxmon (a.k.a. Rackspace Monitoring CLI) you might get the following error:

$ raxmon-entities-list
Traceback (most recent call last):  
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/raxmon-entities-list", line 23, in <module>
    run_action(None, None, 'entities', 'list', callback)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/raxmon_cli/common.py", line 119, in run_action
    instance = get_instance(username, api_key, api_url, auth_url)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/raxmon_cli/common.py", line 136, in get_instance
    instance = driver(username, api_key, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/rackspace_monitoring/drivers/rackspace.py", line 173, in __init__
    self._initialize_connection_base_url(constructor_kwargs=kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/rackspace_monitoring/drivers/rackspace.py", line 187, in _initialize_connection_base_url
    self.connection._populate_hosts_and_request_paths()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libcloud/common/openstack.py", line 602, in _populate_hosts_and_request_paths
    osa.authenticate()  # may throw InvalidCreds
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libcloud/common/openstack.py", line 155, in authenticate
    return self.authenticate_2_0_with_apikey()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libcloud/common/openstack.py", line 240, in authenticate_2_0_with_apikey
    return self.authenticate_2_0_with_body(reqbody)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libcloud/common/openstack.py", line 264, in authenticate_2_0_with_body
    driver=self.driver)
libcloud.common.types.MalformedResponseError: <MalformedResponseException in None 'Malformed response'>: 'code: 405 body: {"methodNotAllowed":{"code":405}}'  

The simple fix is to add '/tokens' to your auth_api section in your .raxrc file or on your command arguments:

[auth_api]
url=https://identity.api.rackspacecloud.com/v2.0/tokens  

apachectl Alternate Location

Quick snippet for when Apache isn't listening on 127.0.0.1 or on an alternative port.

On RHEL/CentOS add the following to /etc/sysconfig/httpd:

STATUSURL=http://<IP>:<PORT>/server-status  

On Ubuntu add to /etc/apache2/envars:

STATUSURL=http://<IP>:<PORT>/server-status  

awscli 'unknown encoding' error

Just installed the AWS CLI on my Mac and encountered the 'unknown encoding' error when I first tried to use it:

$ aws ec2 describe-instances

unknown encoding:  
$

This is caused by the default encoding not being set in Python. There's a couple different ways to go about setting it but the easiest I found was just adding the following to my ~/.bash_profile:

export PYTHONIOENCODING=utf-8  

Open up a new terminal or source the your .bash_profile again and everything will be working swimmingly:

$ aws ec2 describe-instances | head
{
    "Reservations": [
        {
            "OwnerId": "", 
            "ReservationId": "", 
            "Groups": [], 
            "Instances": [
                {
                    "Monitoring": {
                        "State": "disabled"

Fixing Cloud Servers stuck at gPXE Boot

With Rackspace Cloud Servers there's currently an issue with PVHVM resizing images smaller that causes them to lose their MBR; when this happens you'll see the following in the Java console:

gPXE Boot

If you see this your MBR is gone and you'll need to get the server in Rescue Mode (Actions menu -> Enter Rescue Mode) to re-install GRUB to the MBR.

After your server has booted up into Rescue Mode your original hard disk is at /dev/xvdb; you'll need to chroot into your old OS:

# mount /dev/xvdb1 /mnt/
# mount -t proc none /mnt/proc
# mount -o bind /dev /mnt/dev
# mount -t sysfs sys /mnt/sys
# chroot /mnt/

Once you get into the chroot you'll then need to drop to the grub prompt to re-install GRUB to the MBR (the grub-install command doesn't seem to work with Xen guests):

# grub
grub> device (hd1) /dev/xvdb  
grub> root (hd1,0)  
grub> setup (hd1)  
grub> quit  

After GRUB is re-installed to the MBR exit Rescue Mode and your server should boot up normally again; if you're seeing this issue after building a server from an image (extreme edge-case) you've still got a bit more work to do.

While still in the Rescue Mode chroot you'll want to reset the root password (it didn't get set on the initial boot since the server didn't boot):

# passwd
Enter new UNIX password:  
Retype new UNIX password:  
passwd: password updated successfully  

Once the password has been updated you can now exit rescue mode (yay!!!).

After the server boots up normally you'll still need to do some work via the Java console (Actions menu -> Connect via Console) to reconfigure the networking stack since that also wasn't done on the initial boot:

# uuid=$(uuidgen)
# xenstore-write data/host/$uuid '{"name":"resetnetwork","value":""}'

Wait a few seconds and run the following to ensure things went through successfully (should get a return code 0 as below):

# xenstore-read data/guest/$uuid
{"message": "", "returncode": "0"}

The networking reset will re-read the networking configuration from the hypervisor and get the server network accessible.