realsysadmin.com

As part of a vertical consolidation and virtualization project, I had set up a Kickstart configuration in order to boot x86 servers and install the VMWare ESX Server software. While I wrote this document specifically for ESX installations, the underlying OS was a modified Redhat 7.x distro (or something that seemed awfully similar). So here are the steps to implement and use a PXEBooting Kickstart environment.

Prerequisites

1. Linux server (can use a manually built ESX server for this purpose) with dhcpd (dhcp daemon), tftpd (tftp daemon) and nfs server services turned on.
2. Have the dump of the ESX installation media CD in a directory/filesystem large enough to hold it.

An insightful member of the slashdot community had made this observation here (http://slashdot.org/comments.pl?sid=189778&cid=15623704). Thought I’d spin it off and blog it.

Praise

1. The power of perl is irrefutable — it helps slap together quick and clean solutions to irritating admin problems. The flip-side of being a perl jockey I guess is that one tends to try and create a solution to many a problem that already has a solution - because searching CPAN can be a pain at times.
2. Use of the more flexible features of the languages (such as Hashes, hash of hashes etc) data/number munging and organization becomes more manageable.
3. Using Perl’s almost endless modules, a lot of relatively complicated tasks can be simplified.
4. Annoyance factor of numerous tasks (especially Administrative and reporting) can be reduced drastically with the help of Perl.

Beefs

1. The beef I guess is that unlike Python or Perl’s other competitors, Perl modules don’t come tightly integrated with the core distro. Agreed that Perl probably has a lot more modules than any of those other languages do, but a larger than ordinary de facto distribution (why not include important modules like Digest::MD5, Crypt modules, SSH modules etc?) would be desirable (especially in those situations where you don’t have access to the internet directly from within corporate networks and can’t install the modules with the “perl -MCPAN -e shell” option) . There might be those Perl veterans who would say — “build your own distro with your custom modules already packaged” — and while that might be a very smart thing to do, many a time (when one keeps moving from one environment to another — some call it job hopping, it helps to be able to download one single perl distro package or rpm or the source+compile and have basic administrative scripts work — especially those that rely on centralized automation (ssh-based trusts, copies across the network, etc).
2. Also, perl’s syntax can be terse and difficult for noobies to understand (or even older perl-hands for that matter — when someone has written code without appropriate comments, etc).
3. Tinkering with Python recently, I found it’s simplicity refreshing and it’s syntax easier to comprehend (especially when compared with Perl’s (imho) complicated “scoping” requirements, etc).
4. Sometimes (and I guess it depends on the person writing the code) Perl tends to over-complicate things that can be easily handled via Shell scripts.

That much said (several months back), I’d have to say (after having written a pretty big (by my standards) application in Python, I like certain aspects of Python a lot (comprehensibility of code lists at the top) but I still found myself wanting to revert back to Perl at the slightest opportunity. I was irritated with the way you have to declare the variable type in Python (eg: can’t do a floating point operation on two numbers unless you qualify the variable as type float whereas in Perl it is automatically detected) — now I know there are those who will say “Perl does it wrong” and while that might be true, it is also true that a pressed-for-time Systems Admin could do with worrying about other things in the larger scheme of things…

I guess I must’ve have internalized the terse syntactical idiosyncrasies of Perl somewhere along the way and thinking in “Python” seemed a wee bit alien.

What I did like about Python is the ease with which one could develop GUI interfaces .
I actually had to write a reporting tool on the windows platform — and using the win32com.client module, coding was a piece of cake. I also played with the Tkinter module on UNIX and coding with it was a breeze as well.

While this might be totally redundant, I couldn’t for the love of God remember how range operators were used within the various shells (and specifically the Korn shell). Tried various tricks but I guess I must’ve gotten “perl-ized” somewhere along the way. So here’s my workaround for quick shell scripts (usually fired off from the command line on the fly) that require range operators (say you want to iterate through the numbers 1 - 100 and do some activity with each value.

for i in `perl -e ‘foreach $i (1..100) { print “$i \n”; }’`
do
echo “I is $i”;
done

Here we’ll invoke a perl one-liner to print out the values of $i in the range 1 to 100. We read that and do something with it within a “ksh for loop”. It’s easier than having to type in:

for i in 1 2 3 4 5 …. 100
do
echo “I is $i”
done

Sidenote: Hopefully I’ll get to update this blog more often that I usually do — if there’s no one watching, at least it’s something for me to refer to (as a cheatsheet on the fly).