kvanals.org Weblog

UPDATE: Apparently there is some hope left in the world for consumers. I think it is worth noting that Dell has contacted me regarding this matter and has refunded my credit card the difference (a little over $90). I applaud Dell’s diligence regarding this matter. Hopefully Dell’s online ordering system will be corrected in the future to not give over-optimistic ship dates.

–

First, I would like to say how happy I have been with the Alienware M11x R2. There are plenty of favourable reviews floating around on the internet, so I won’t waste anyone’s time with that here. Having said that, the lack of nVidia Optimus support on Linux (or anything other than Windows, such as Solaris) is discouraging, but the integrated graphics seem to do fine with most everything I need — I boot into Windows for gaming. I’m looking forward to the day that I can do everything from Linux, but I imagine that will be a long road.

Now for the real reason I’m posting this: I must say I am completely discouraged by Dell’s attitude throughout the process of purchasing this machine. If Dell is wondering why they are doing so poorly as of late, I would imagine that this would have a great deal to do with it. I decided upon the the Alienware M11x R2 after a few nights of research. On 7/18/2010, I was ready to place my order. I originally was going to purchase the M11x R2 under my employee purchase plan with the organization that I work with. For the sake of comparison, I checked out the Dell Home page as well. I was surprised to see that the price difference was negligible — only about $50 more for Dell Home. Another surprise was the estimated ship date — the estimated ship date was 7/20 for Dell Home and 7/28 for Dell Government. Being as eager as I was to actually use the machine that I was about to charge almost $2K to my credit card for, I opted to purchase the machine from Dell Home. The difference was only about $100. Thinking that it would be great to get all of this in by the end of the week, I opted for 2-day shipping, so that the equipment would arrive by Thursday, 7/22.

This is when it all started to go horribly wrong. Immediately after placing my order, I received an order confirmation email and shipment update email. Immediately after charging my credit card, the estimated ship date changed to 7/28 — exactly what it had been for Dell Government. Needless to say, I was a bit offended. The entire ordeal felt like a bait-and-switch campaign to me. Being only about a week later, I decided to not give it another thought, until 7/28 rolled around and I received an email update that my order had been delayed another week. My new estimated ship date was 8/3. I called Dell support, knowing well that they would be able to do nothing. They stated that they would note that my order should be expedited. Upon querying if I could cancel my order, I was told that there would be a 15% restocking fee, because the order was “In Production.” At this point, I either had to just wait and get my machine after being lied to twice or pay almost $300 for the privilege of trying to purchase a machine from Dell.

My machine ended up shipping on 8/2 and I received it on 8/4. I have been quite happy with the performance of the machine overall, but the ordeal of dealing with Dell will likely cause me to never purchase or recommend the purchase of another Dell machine ever.

Kenneth Van Alstyne
Systems Administrator

(In This Case, Solaris)

Moving your NetBackup Master Server from Windows to UNIX presents some interesting challenges.

NOTE: This is meant as a rough overview and not a comprehensive guide for how to do this. Neither Symantec, nor I will support you in your actions.

- Pathnames change (C:\Program Files\VERITAS) to (/usr/openv)
- Text files have CR/LF line endings, rather than just LF
- NTFS is NOT case-sensitive, while most filesystems on UNIX are

To further disourage you, Symantec has the following stance on the subject:

DOCUMENTATION: How to migrate the NetBackup catalog information from one platform to another (UNIX to Windows or vice versa), rename a Master Server, cluster an existing Master Server, or merge multiple NetBackup domains.

While migration and merging is possible, NetBackup Support does not have the necessary resources and experience to properly execute this process. NetBackup Support can assist in restoring the data back to the same original platform in the event of a failed attempt, but is not equipped to assist in these sorts of activities. To insure data integrity and seamless operation, operations of this type must be performed by Symantec Consulting Services. (From http://seer.entsupport.symantec.com/docs/267137.htm)

Don’t give up hope! The migration is possible and not really all that challenging. Just keep in mind, you’re on your own here. Symantec Technical Support will NOT help you with these actions. (Trust me. I tried.) I also do not have the resources to help with these kinds of things — I’m busy as it is.

Steps:
First things first.. slap yourself around a bit for putting your Enterprise’s well-being on a Windows server to begin with. Then, after the tingling goes away, slap yourself again. This time really mean it. I mean, seriously — what were you thinking? Below is a rough overview of what needs to be done:

- The easiest method for moving platforms is to keep the same server around during the migration. Restoring from a disaster recovery image is not covered here. I may cover it at a later date, but it adds further kinks into the equation, since the Windows DR image will be a “Windows_NT” backup, rather than “Standard.”

- For the purpose of this writeup, keep your server names the same. You can change your server name, but this adds more problems to an already-existing interesting problem.

- Have the new server up and running with NetBackup installed. This will go much more smoothly if both NetBackup instances are at the same patch level. Bring NetBackup down on the new server before getting started. (/etc/init.d/netbackup stop)

- I would make a catalog backup to disk of the old server before getting started. Just make a new DSSU pointing to a local disk and configure and run a catalog backup to that DSSU.

- From the old server, delete all devices from the Media Manager. Delete all tape drives, robots, disk staging units, storage unit groups, etc.

- Bring the old NetBackup instance down, so that no data changes during the move. (C:\Program Files\VERITAS\NetBackup\bin\bpdown)

- Copy the important directories to the new server. I used “tar” and “scp” to accomplish this. The important directories are:

The following directories make up what NetBackup calls your "catalog:"
Record of all previous backup images -
C:\Program Files\VERITAS\NetBackup\db\images
Policies, schedules, and hosts - 
C:\Program Files\VERITAS\NetBackup\db\class
EMM database (tapes, devices, etc) - 
C:\Program Files\VERITAS\NetBackupDB\data

- On the new host, create a filesystem for your images that is case-insensitive. On Solaris, for instance, I did something similar to:

zfs create NETBACK_DP/netbackup/images -o casesensitivity=insensitive
zfs set mountpoint=/usr/openv/netbackup/db/images NETBACK_DP/netbackup/images

- You could also solve this issue later on by comparing the entries in your classes to the directories in images and moving the directories in /usr/openv/netbackup/db/images/ into their correct locations.

- Move the copied over directories into their correct places on the UNIX host:

C:\Program Files\VERITAS\NetBackup\db\images -> /usr/openv/netbackup/db/images
C:\Program Files\VERITAS\NetBackup\db\class -> /usr/openv/netbackup/db/class
C:\Program Files\VERITAS\NetBackupDB\data -> /usr/openv/db/data

- Link the EMM database to its original location, so that it will start initially:

ln -s /usr/openv/db/data/EMM_DATA.db /usr/openv/db/data/C\:\\Program\ Files\\VERITAS\\NetBackupDB\\data\\EMM_DATA.db
ln -s /usr/openv/db/data/EMM_INDEX.db /usr/openv/db/data/C\:\\Program\ Files\\VERITAS\\NetBackupDB\\data\\EMM_INDEX.db
ln -s /usr/openv/db/data/NBDB.log /usr/openv/db/data/C\:\\Program\ Files\\VERITAS\\NetBackupDB\\data\\NBDB.log

Your original NBDB.db from Windows points to those absolute paths, which will become relative paths on UNIX, making this method work. You can fix this so that you don’t need these links anymore with nbdb_move, but that’s not covered here.

- All that’s left now is to strip the CR (^M) from all of the text files. Keep in mind, that when you see “^M”, use it literally. In bash, this will be Control-V, then Control-M.

/usr/openv/netbackup/db/images - 
All files, except those endind with just ".f" or ".f_*" - 
cd /usr/openv/netbackup/db/images
for i in `find . -type f ! \( -name '*.f_*' -o -name '*.f' \)`; do  sed 's@^M$@@' "${i}" > "${i}.__TMP__"; cat "${i}.__TMP__" > "${i}"; rm "${i}.__TMP__"; done

/usr/openv/netbackup/db/class - 
All files - 
cd /usr/openv/netbackup/db/class
for i in `find . -type f`; do  sed 's@^M$@@' "${i}" > "${i}.__TMP__"; cat "${i}.__TMP__" > "${i}"; rm "${i}.__TMP__"; done

/usr/openv/db/data - 
vxdbms.conf - 
cd /usr/openv/db/data
for i in vxdbms.conf; do  sed 's@^M$@@' "${i}" > "${i}.__TMP__"; cat "${i}.__TMP__" > "${i}"; rm "${i}.__TMP__"; done

This is about all I can remember. I’m going to duplicate this process in the near future and update with anything that I missed. Assuming I didn’t miss anything, you should be able to start NetBackup with:

/etc/init.d/netbackup start

All of your old backup images should be searchable, your old tapes should be listed, and your old policies and schedules should be present and active. At this point, you should be good to go to configure your devices on the new server and start running backups.

Keep Solaris Express Community Edition (SXCE) alive! We’re now down to the last few builds (according to http://www.opensolaris.org/jive/thread.jspa?threadID=116145&tstart=0)

The current plan for Solaris Express Community Edition is that it will
be delivered though build *130*, which is scheduled for *late-December*
2009.

I consider SXCE the “best of both worlds” between OpenSolaris (Indiana) and Solaris 10 and an invaluable part of the Solaris community. I know quite a few people feel the same way. Listen to your customers, Sun!

I’m not entirely sure how useful such a thing would be, however I was presented with an opportunity to move from QLogic Fibre Channel switches to Brocade recently. In an effort to cut down on work, I realized that this could be easily scripted. Doing a brief search on the internet offered little support, so this is what I came up with. Hopefully it can help someone out there. It’s pretty silly easy, however.

On the QLogic switch, run “zoning list”:

qlogic-fc-sw-1 #> zoning list
              somehost1_zone
                        array_port1 (Alias)
                                  50:00:00:00:00:00:00:00
                        somehost1_hba1 (Alias)
                                  21:00:00:00:00:00:00:00
	
              somehost2_zone
                        somehost2_hba1 (Alias)
                                  21:00:00:00:00:00:00:00
                        array_port2 (Alias)
                                  21:00:00:00:00:00:00:00

If your zoning is somewhat sane, you’ll get output similar to the above. Save all of the output into a text file for future use to feed to a script. An example script to convert that information to Brocade commands is below:

#!/bin/bash
while true; do
        read zone || break
        read alias1 junk || break
        read wwn1 || break
        read alias2 junk || break
        read wwn2 || break
        read junk || break
        alias1=`echo "${alias1}" | tr - _`
        alias2=`echo "${alias2}" | tr - _`
        zone=`echo "${zone}" | tr - _`
        echo "alicreate \"$alias1\", \"$wwn1\""
        echo "alicreate \"$alias2\", \"$wwn2\""
        echo "zonecreate \"$zone\", \"$alias1;$alias2\""
        echo "cfgadd \"SAN_CONFIG1\", \"$zone\""
done

The script is fairly obvious and you’ll want to modify it for your environment, obviously. An example of this script running against the output from above is below:

-bash-3.2$ cat example.txt | ./convert.sh 
alicreate "array_port1", "21:00:00:00:00:00:00:00"
alicreate "somehost1_hba1", "20:00:00:00:00:00:00:00"
zonecreate "somehost1_zone", "array_port1;somehost1_hba1"
cfgadd "SAN_CONFIG1", "somehost1_zone"
alicreate "somehost2_hba1", "21:00:00:00:00:00:00:00"
alicreate "array_port2", "20:00:00:00:00:00:00:00"
zonecreate "somehost2_zone", "somehost2_hba1;array_port2"
cfgadd "SAN_CONFIG1", "somehost2_zone"

You would then run these commands on the Brocade switch, assuming the configuration was called “SAN_CONFIG1.” The zoneset “SAN_CONFIG1” would then need to be activated.

This post is not meant to be a comprehensive guide about fibre channel switch zoning and should not be used as such — it should be used as a brief overview about moving your existing QLogic fabric to Brocade.

Great success! This box is now running on a SunFire X4100 on a metro-ethernet link. During the migration, I also took the opportunity to migrate to Xen domains and upgrade various software packages, including Flatpress.