AIX Network Sniffing With Wireshark

Wireshark is a real good GUI packet capture and analysis tool. I have a portable version on a thumbdrive that I occasionally use to diagnose problems on AIX servers.

First, capture the data with iptrace. Refer to the iptrace man page for options. For example, to capture rsh (port 514) from hosta and write it to /tmp run:

startsrc -s iptrace -a "-s hosta -p 514 /tmp/hosta.out"

After your done capturing your data, run:

stopsrc –s iptrace

Then download the output file to your desktop and open the resulting file with Wireshark. Wireshark will automatically determine that the file is from AIX iptrace.

Saving The Structure Of A VG

This process uses the savevg command to backup the VG structure information. I used to to this by first excluding any filesystems from the backup by populating the /etc/exclude.vg files with all the filesystems, but IBM introducted the “-r” flag that does the same thing.  We purposely exclude rootvg from this because all the rootvg filesysetems will be in the mksysb backup.

#!/bin/perl
#
# Author: Patrick Vaughan - http://patrickv.info
#
# Purpose:
# Saves VG structure to files for easy recovery
#
# Restore with:
# restvg -f /vgdata/savevg.VGNAME DISKNAME
#
$test=1;
$DEBUG=0;
$" = "";
$GREP = "/usr/bin/grep";
$LSVG = "/usr/sbin/lsvg";
$EXCLUDE_VGS = "rootvg"; # VGs to exclude in a REGEXP
$VGDATA_DIR = "/vgdata";
if ( ! -d "$VGDATA_DIR" ) {
         mkdir("$VGDATA_DIR") || die("Could not create directory $VGDATA_DIR: $@ \n");
}
@VGS = grep(!/$EXCLUDE_VGS/, `$LSVG -o`);
for ( @VGS ) {
         chomp;
         $vg = $_;
#       exclude files are no longer necessary since the -r flag was introduced
#       if ( -f "/etc/exclude.$vg" ) {
#               unlink("/etc/exclude.$vg") || die("Could not remove file /etc/exclude.$vg: $@\n");
#       }
#       (@LVs) = grep(/^\//, split(/\s+/, `$LSVG -l $vg`, -1 ) );
#       open(EXCLUDE_VG, ">/etc/exclude.$vg") or die("Could not create file /etc/exclude.$vg: $@\n");
#       for (@LVs) {
#               # populate /etc/exclude.vg with ^./filesystem/ because we don't want the data
#               print EXCLUDE_VG ("^.$_/\n");
#       }
#       close(EXCLUDE_VG);
#       undef(@LVs);

         print "savevg of $vg to $VGDATA_DIR/savevg.$vg starting.\n";
         system(`savevg -irf $VGDATA_DIR/savevg.$vg $vg`);
         print "savevg of $vg to $VGDATA_DIR/savevg.$vg complete.\n";

# We're done with the exclude files, lets delete them
#       unlink("/etc/exclude.$vg") || die("Could not remove file /etc/exclude.$vg: $@\n");
}

This will create one file in the directory /vgdata for each volume group on the system.  You can then use the restvg -f /vgdata/savevg.xxx to restore the VG data.  Check the restvg man page for more information.

To get information about the backup run:

restvg -l -f savevg.X
VOLUME GROUP:           sharedGvg
BACKUP DATE/TIME:       Tue May 29 09:33:56 EDT 2007
UNAME INFO:             AIX cnpg 3 5 002680EF4C00
BACKUP OSLEVEL:         5.3.0.50
MAINTENANCE LEVEL:      5300-05
BACKUP SIZE (MB):       15008
SHRINK SIZE (MB):       1727
VG DATA ONLY:           no
sharedGvg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
shareGlv            jfs2       938   938   1    open/syncd    /shared

You can see the VG size and LV info to make decisions on restoring the VG.

Multi-VG mksysb Tape

More than one VG can be saved on a mksysb tape, which makes restoring things like your TSM or NIM master servers much easier.   We’ll need to use the rmt tape devices that do not rewind after their operation (rmtX.1).   First, rewind the tape (just to be sure we’re at the beginning) and do the mksysb as normal:

/usr/bin/tctl -f/dev/rmt0 rewind
/usr/bin/mksysb -p -v /dev/rmt0.1

Then just append your VGs on the end of the tape with savevg:

/usr/bin/savevg -p -v -f/dev/rmt0.1 vg1
/usr/bin/savevg -p -v -f/dev/rmt0.1 vg2
/usr/bin/tctl -f/dev/rmt0 rewind

To restore, just do the mksysb restore as normal, then do:

/usr/bin/tctl -f/dev/rmt0.1 rewind
/usr/bin/tctl -f/dev/rmt0.1 fsf 4
/usr/bin/restvg -f/dev/rmt0.1 hdiskX

The “fsf 4” will fast forward the tape to the first saved VG after the mksysb.  To restore the 2nd saved VG, use “fsf 5”.

If you need to restore individual files, you can do it like this:

/usr/bin/tctl -f/dev/rmt0 rewind
restore -x -d -v -s4 -f/dev/rmt0.1 ./[path]/[file]

“-s4” is rootvg, use “-s5” for next VG. The files are restored in your current directory.

Using this you can make a mksysb tape with your OS, your TSM application VGs, and your NIM VGs all on one tape.  And, if you save the VG structure into your rootvg, you can restore your extra filesystems as well.  Then you just have to restore the files from TSM.  I wouldn’t try to backup the TSM log, archivelog, or DB this way, but those can be created with your TSM DB backup.  Just be sure to do a “backup devconfig” and “backup volhist” regularly.

NIM Quickstart

I muddled through my first NIM install, and got it working okay. But, I’ve since heard Steve Knudson several times deliver his NIM sessions? and that has really solidified the concepts better than trying to read the manuals. You can see a replay of Steve’s presentation at the AIX Virtual User Group, which I highly recommend.

I recently had to build a new NIM server, so I thought it was a good time to post my cliff notes version.

Install these on the NIM Master:

  • bos.net.tcp.server
  • bos.net.nfs.server
  • bos.sysmgt.nim.master
  • bos.sysmgt.nim.spot

Make these directories:

  • /export
  • /export/61 ( or 53, or something representative of your AIX version)

Make these filesystems:

  • /export/61/lpp_6100-01-07
  • /export/61/spot_6100-01-07
  • /export/mksysb

The lpp filesystem will be the lppsource for AIX 6.1 TL1 SP7, and the spot filesystem will be the coresponding spot. For AIX 6.1, the lppsource is about 4G and the spot is about 600M.  The mksysb directory is good for customized base install images and mksysb images.

Initialize the NIM master:

smitty nim

Configure the NIM Environment / Advanced Configuration / Initialize the NIM Master Only

Network name:  something like 192_168_1

Primary Network Install Interface: enX

I also let the clients register themselves, it’s just easier that way.

Create the lppsource:

Insert DVD 1

smitty bffcreate

input device: /dev/cd0

directory for storing software: /export/61/lpp_6100-01-07

extend filesystems: yes

process multiple volumes: yes

You’ll be prompted to change DVDs.

Define to lppsource to NIM:

smitty nim

Configure the NIM Environment / Advanced Configuration / Create Basic Installation Resources /  Create a New LPP_SOURCE Only

Resource SERVER: master

LPP_SOURCE Name: lpp_6100-01-07

LPP_SOURCE Directory: /export/61/lpp_6100-01-07

Create new filesystem for LPP_SOURCE: no

Make the SPOT:

smitty nim

Configure the NIM Environment / Advanced Configuration / Create Basic Installation Resources /  Create a New SPOT Only

Resource SERVER: master

Input device: hit F4 and select your lppsource

SPOT Name: spot_6100-01-07

SPOT Directory: /export/61

Create new filesystem for SPOT: no

And, that’s about it.  Just register your clients. I don’t use a hardware address, I just populate the IP.  I also use nimsh instead of rsh.  Nimsh is the newer protocol, and doesn’t require you to setup a .rhosts file on every client.

mksysb Backups w/ NIM

NIM is great for backing up systems and pushing out packages, but there isn’t a included system for managing mksysb images.  I’ve got a little script that runs on the NIM server and either does a mksysb on all the clients registered or you can specify certain clients.  It also keeps X number of old mksysb images and purges the remaining ones.  It’s needs a little cosmetic work, but you can use it as a basis for your own system.

get_mksysb

Now, since you have NIM working, you really should run a mksysb backup to tape so you have bootable media to get your NIM server back up.  I have two of them, which happen to also be my TSM servers, that I also backup to eachother.  Since you can’t have your NIM master be a client on another NIM server, I have a little script that generates a mksysb on disk (plus any extra VGs) and uses scp to copy the images to the other server. It’s stupid simple, and could use come cosmetics, but it works:

#!/bin/ksh
# Usage: mksysb.ksh dest_hostname [ extra_vg ... ]

hostname=`hostname`
dest_host=$1

shift

scp_file() {
        /usr/bin/scp $1 $dest_host:/export/mksysb/$hostname/

}


/usr/bin/mksysb -e -i -X /shared/mksysb.$hostname

if [ $? -eq 0 ]
then
        scp_file /shared/mksysb.$hostname 
else
        echo "mksysb backup failed!"
        exit 1
fi

if [ $? -eq 0 ]
then
        rm /shared/mksysb.$hostname
fi

while [ "$1" != "" ]
do
        savevg -f /shared/$1.savevg $1
        if [ $? -eq 0 ]
        then
                scp_file /shared/$1.savevg
                rm /shared/$1.savevg
        else
                echo "savevg of $1 failed!"
                exit 1
        fi
        shift
done

If you need to restore this mksysb, you just have to register it as a NIM object, then register the client on the NIM master and do the restore as normal.

Mounting ISO Images On AIX

UPDATE – Chris Gibson pointed out that with AIX 6.1 you can use a loopback device like Linux.

I recently heard someone discuss how to handle ISO images on AIX. On Linux, you can mount the ISO image as a filesystem, which is pretty slick.

Starting in AIX 6.1, you can use the loopmount command to create a loopback device and mount an ISO directly:

loopmount -i cdrom.iso -o “-V cdrfs -o ro” -m /mnt

And, loopumount unmounts the ISO and removes the loopback device:

loopumount -i cdrom.iso -o "/mnt"

There are a couple of gotcha’s, but nothing unusual. An ISO can only be associated with one loopback device at a time, the mount is only readonly, and it’s not supported in WPARs.

But, AIX previous to 6.1 doesn’t support mounting ISO images directly. The recommendation was to mount the ISO as a virtual optical drive on the VIOS. But, I don’t use VIOS because it hasn’t gained uptake in our environment and with our vendors. You can always burn the image and mount the CD, but if your optical drive is tied up on another LPAR you may not be able to move the optical drive to the right LPAR.

There is another way to mount those images, but it’s not a one-step process. What you need to do is create a LV at least as big as your ISO image, then copy the ISO data to that LV, and then mount the LV:

mklv -y cdlv -s n rootvg 704M hdisk0
dd if=cdrom.iso of=/dev/cdlv
mount -v cdrfs -o ro /dev/cdlv /mnt
        

Why I hate the HTC Evo

The HTC Evo on Sprint is a nice phone. Big screen, fast processor, a fast network, and so on…. but I hate it.

I have both the HTC Hero and the Samsung Moment. The Hero is a nice phone, the sense UI is cool, but it’s a little buggy and it mystery dials random contacts on it’s own. The Moment is okay. It’s fairly fast, but the UI is still sluggish sometimes. The screen is really nice, though. But, it’s flaky if the GPS is running, and reboots or crashes on it’s own randomly once in a while.

So, I should LOVE the HTC Evo, it’s the new hot phone with none of the problems of the previous phones (that we know of). The problem is the plan, and the word “unlimited”. I already pay for the “unlimited” data plan. And, it’s pretty unlimited. I can download data as fast as the phone can pull it, and download as much as I care to.

But, the Evo has a $10 a month surcharge to cover the extra data that Sprint is SURE you’ll use…. Wait, what? My plan is already unlimited. Why is there a surcharge for more data? I actually would be much happier if they came out and said because more people are using data heavy services, rates are going up. Even if they went to a tiered plan where the current rate has limited data transfer and the unlimited plan is $10 more a month I would be happier.

But don’t call my plan unlimited, then when I want a new phone make me pay for a MORE unlimited plan. I have the same problem with ISPs that have an unlimited plan, but when you download over a certain amount they cut your bandwidth. That’s not unlimited.

When I asked our local sales rep if they’re getting any flack from customers for it. The answer was “it’s better than AT&T, and where are they going to go? Verizon?” The price is still lower than Verizon or AT&T, and the service is better than AT&T. But I’m at the point where I would pay more money on Verizon for a Droid X with a limited data plan than stay with a company that uses this kind of BS.

Switching VGs from concurrent mode without varyoff?

I recently got an Email asking:

In HACMP, is it possible to pass a vg varied on in enhanced mode to varied on in non-enhanced mode without any varyoff ?

As far as I know, it’s not. There are some operations that cannot be performed on a VG varied on in concurrent mode, usually anything modifying the VG structure.

If we need to do something that will modify the structure of the volume groups, we do it during a regularly scheduled downtime. This ensures that the applications aren’t writing to the VG, and we can safely make modifications. You don’t even necessarily have to bring down the HACMP resource groups. Simply unmount all the filesystems, or stop all the applications that may have any raw LVs open, varyoff the VG on all the nodes, then do a varyonvg on just one node. After you’ve made your changes it’s again simple to varyoff the VG, and run the appropritate commands to vary it back on in concurrent mode on the appropriate nodes. Just be sure that the VGs are in active or passive mode appropriately before you bring the applications back up.

TSM Backup Client Data Encryption

In TSM 5.4+, there is an option for backup encryption. Unlike SSL encryption, the data is stored on the server in an encrypted format. So, your tapes are finally, really, secure. Without paying for encryption capable libraries and drives. I always thought it was kind of lame of IBM to say that the TSM backup takes are useless without the TSM database. It looks to me like the data is in the clear on the tape, there’s no reason you couldn’t read the whole tape into a huge file and text search it if you really wanted it bad enough.

WARNING: If you lose your encryption pass phrase, the data is un-recoverable from TSM. Really. Gone. For good. You can save the key to the server in the TSM database (that’s what I’m doing), or you can just make REALLY sure you have it safely documented. Oh, and this will break your de-duplication because the data is encrypted as far as the server is concerned. It’s only de-crypted on the client in the event of a restore.

This is SUPER, and I do mean SUPER simple to setup. Just add this to your client option file:

ENCRYPTKEY generate

You can also specify prompt (which will prompt every time), or save (which will save the passphrase to a file on the client). If you specify generate, a pass-phrase will to automatically generated, and store on the TSM server. The encryption type is AES128 be default, but you can over-ride it and use DES56. The only reason I can think of to use DES56 is for performance.

There are 2 new include/exclude options too:

Exclude.Encryption
Include.Encryption

By default NO data is encrypted, so you’ll have to use the Include.Encryption option to add directories and files. IBM isn’t recommending you encrypt OS system files because of the possibility that you might lose your encryption pass-phrase file and not be able to restore. There are a couple of things you can do to mediate this. You can use the “ENCRYPTIONKEY generate” option, so the passphrase is in the TSM database. If you still don’t feel safe about that, you can only encrypt the really sensitive files like /etc/security/passwd. Or, you can enable SSL to encrypt the data over the wire, and only encrypt the sensitive application data (which doesn’t encrypt the data on the actual TSM server media).

Oh, and if you lose the encryption key the data is NOT RECOVERABLE. No, really, they mean it.

TSM LAN Backup SSL Encryption

I haven’t looked at TSM backup encryption before, even though it’s been in TSM since version 5.4 (maybe earlier). But, if you think about it, there isn’t any data MORE important than your backup data. Data that is usually encrypted on the wire, is most likely sent in the clear by the TSM client. There are a couple of ways to slice this, but I started with the SSL encryption feature. There is a client encryption option in TSM 6.1 (possibly earlier) that encrypts the data with an encryption passphrase, but that has more issues and isn’t very compatible with server-side de-duplication.

Enabling the SSL features in the server is as simple as adding the following line to the dsmserv.opt and restarting:

SSLTCPPORT xxxx

When the server sees this option, it checks to see if there is a SSL key already generated. If there isn’t one, it creates it automatically. You can specify any port you like, as long as it’s not already being used by something else. If you don’t run the admin client on the same TCP port as the clients, you’ll also need to add:

SSLTCPADMINPORT xxxx

Now, on the client side, you need to copy the newly generated key from the server. It’s named cert.arm, and should be located in the server home directory (that’s the home directory for the instance owner in 6.1 and above). Once you have that, you just have to create an empty keyring and add the server key to it:

gsk7capicmd -keydb -create -db dsmcert.kdb -pw  -stash
gsk7capicmd -cert -add -db dsmcert.kdb -pw  -label "TSM server  self-signed key" -file cert.arm -format ascii -trust enable

The password can be anything and you can add more than 1 keys to your client keyring if you have more than one server as long as the labels are unique.

After that, you have to change the TCPPort option in the client option file (dsm.sys on Unix), and add the option “SSL yes”. Un-encrypted clients can’t talk to the SSL enable server port, and vise-versa. Just restart your client, and you should be in business.

There is a new feature in 6.2 where you can use a well-known certificate, if you want to pay Verisign or Thawt for a SSL certificate. Those certificates are included with the 6.2 clients, so you don’t need to hassle with copying the certificates. I haven’t tried that, because it’s easy enough to copy the self-signed key from the server and setup the keychain on the clients and save the money for a yearly SSL certificate renewal.

Now, I haven’t been able to verify this, but it appears to me that this DOES NOT interfere with de-duplication. The way I read it is the data isn’t stored in an encrypted format on the server, it’s de-crypted on the server before it hits the storage pools. The performance seems pretty good. You will spend some extra CPU cycles, but SSL is pretty light-weight and I haven’t seen a noticeable impact.

Note: this doesn’t encrypt the Webclient, GUI, client-to-client backups, or server-to-server backups. This only encrypts the actual data transfer from the client to the server.