Just a quick post. If you are running kickstart, you may find yourself looking for the list of installation groups and their associated packages. I certainly did.

Following a tip from http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg04644.html, here's the entire comps.xml file for Redhat Enterprise Linux 5.4.

I have been using this script to check for updates on my Redhat systems for quite some time. Put this into your cron.daily, and you have a daily nag to update your system.

#!/bin/bash                                                                                       

#########
## Yum Check Update Script
##
## This script checks for system updates and sends email
## to sysmin team if there are any updates.
##
## Changelog
## ---------
## 24 Oct 2008 (Junhao)
## - Initial commit
##
#########

_CAT="/bin/cat"
_DATE="/bin/date"
_HOSTNAME="/bin/hostname"
_MAILX="/bin/mailx"
_RM="/bin/rm"
_TOUCH="/bin/touch"
_YUM="/usr/bin/yum"

HOSTNAME=`${_HOSTNAME}`
DATESTAMP=`${_DATE} +%Y%b%d-%H:%M:%S`
EMAIL=root
MAILSUB="RHEL Update Available for ${HOSTNAME} on ${DATESTAMP}"

TEMPLOG=/tmp/yum-check-update.tmp

${_TOUCH} ${TEMPLOG}
${_YUM} check-update 1> ${TEMPLOG} 2>&1

if [[ $? != 0 ]]; then
        ${_CAT} ${TEMPLOG} | ${_MAILX} -s "${MAILSUB}" ${EMAIL}
fi

${_RM} ${TEMPLOG}

Recently, I have started to migrate my scripts to use Puppet. Everything from initial system provisioning to manual failover systems had been converted. Wee~

The idea behind Puppet is to consolidate and standardise configuration across multiple servers. By centralising configuration, a standard security and provisioning baseline is maintained. Configuration for each service can be standardised and reused across an entire infrastructure. Even better, puppet ensures the system remains as configured. Locally configured files are reverted, services are restarted, etc. The end result? Less headache and easier knowledge sharing.

Someone once commented about me using a "commandline webmin". I don't think Puppet is like webmin at all. Webmin pre-defines the fields for configuration. Puppet is, well, blank. It simply provides an API for defining my systems, and then helps me push/maintain it across the infrastructure.

Who says system administrators can't code?

Okay, back to coding...

I am on twitter, under the name jmarki! Do add me, and let me know who you are.... My memory is failing me...

On a side note, someone from $WORK found my blog while searching for my $WORKPLACE on yahoo.com. How did that happen?!

I suddenly have the urge to thank my family and friends for all the help and advice they have given me throughout the years. Putting up with my idiosyncrasies is no easy thing, I know. The guidance each of you have given me every time I got confused is really appreciated too.

Thank you, thank you! May Buddha bless you, always. May Buddha be a shining light to guide you through troubled times, just like He has guided me too. Amitabha.

Solaris 10 update 5 is out! Check out the "what's new". Strangely, nothing on ZFS. Oh well...

All the same, download it at the usual place.

Question: What is an IT career all about?

Answer: To be paid to make other people's problem your problem, so that their life will (supposedly) e better. So who fixes the plumber's pipes?

I was at the SUN-NUS Opensource Day on Friday, and after the event, we all adjourned for dinner. You know, when geeks gather, we inevitably will start discussing the hacks we are deploying for one reason or the other. Or thorny problems. And hence, I brought up my "huge dataset" problem.

Now, the traditional way of doing storage carving is to do RAID-5 on the SAN, cut each RAID-5 set into smaller luns to map to the operating system. If need be, some of the luns will be RAID-1/striped together in the OS. Why? RAID-5 for redundancy, smaller luns as the RAID-5 set is too big, and striped luns to expand storage when required.

So, what's the big problem? Wee Yeh (http://prstat.blogspot.com) pointed out that lun carving is done ACROSS the RAID-5 disk set. It simply follows the way RAID-5 parity is done.

"ACROSS"!!!! Wait a moment... Doesn't this mean if a disk fails, performance is impacted across all the luns in the disk set? And if 2 disks fails, ALL the luns in the disk set are dead! So, if one lun is for applications, another is for data storage, and the third is for user directories, the entire computing stack is down. Unrecoverably dead. Geebes!!!!! <head rolls>

Of course, being a nice guy, Wee Yeh suggests using JBOD disk sets + RAID-Z using ZFS. Since ZFS will do the parity checks, there is still redundancy. If a hard disk fails, the ZFS pool continues to work. If 2 disks fail, at least the damage is contained to this ZFS pool. Added advantage is that both the SAN storage and ZFS will scream when the first hard disk dies, as opposed to only the SAN storage screaming, while the OS remains oblivious. And ZFS has parity checks during disk read/write, nicely overcoming the lack of parity read/write checks on SATA disks.

Okay, time to do some hard thinking

Now that I am doing cross platform system administration, it is getting critical to have lists of equivalent commands across the *nixes. Found 2 guides so far:

1. Unix toolbox: http://cb.vu/unixtoolbox.xhtml
2. Tom's Hardware Universal Command Guide: http://www.tomshardware.com/ucg/

Will be adding more as the time goes by.

Somehow, there is no opposition to the data reorganisation plan.Yeah!!

And I found out, from a post to the LUGS mailing list, 3+ Terabytes file sharing through SAMBA and NFS(v3) has already been done. So, no more drastic hacks, for now. Wee~

Anyway, I just did a Redhat Enterprise Linux 5 kickstart file. May be posting that soon.