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.

Today (yesterday?) is Blog Action Day '09, and the topic is "Climate Change". What a depressing, yet uplifting topic to blog about!

When you were just small kiddos, did you ever imagined how Earth would look like from space? Guess it would look like this:

And we are absolutely dwarfed by the immerse size of Earth!

What a wonderful world we live in!

Yet, we thoughtlessly pollute the environment. We create things that last forever and throw them away in an instant.

 

We breed animals in inhumane conditions, stacked up high like packed boxes. We clear acres of forests to grow lots of crops, and feed these animals for months. Just to slaughter them for a single meal.

And scoff when someone remarks about the sheer waste of energy producing so much food for so little gain.

Sigh...

How egoistic can we be? Somewhere between all the debate about global warming, we lost sight of the forest for the trees. The key issue is not about whether global warming is a natural phenomenon. It is about sustainable development.

We want our next generations to have a decent quality of life. We want them to see how beautiful this world is. We want them to experience snow falling softly around them. We want them to see the beautiful corals in the deep blue sea. We want them to be able to see the stars, and imagine how small they are if they look down to Earth.

Eat less meat. Dispose less garbage. Waste less paper. Waste less electricity. Recycle, reuse, reduce. Just live in moderation. Is that really so difficult?

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}

This is so cool! And looks more traumatising than $WORK!

Hmm, where's the coffee though...

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?!

Yeah, there's an Install Fest in NUS tomorrow, organised by linuxNUS.

Venue:SOC1 #03-17
Date: Feb 5 2009, Thursday (TOMORROW!)
Time: 6.30pm

More information at linuxNUS website.

Anyway, I think I may be going there at 7.30pm. It's a long time since I met the folks for dinner.

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