Quick CentOS Inventory Script

Had a need to quickly grab inventory (sys config) information from a bunch of hosts on our network. Unfortunately, identifying the number of CPUs/cores and specific drive information isn't always clear cut. This script grabs the key information, which can be used to discern the basic system configuration.

A couple of notes:
1. This is CentOS or RedHat specific. Your mileage will vary with other flavors.
2. At the time of this post, all of our systems are using SCSI drives and the script only grabs SCSI disk info from dmesg.

#!/bin/bash
clear
echo "##################### SYSTEM INVENTORY ########################"
grep HOSTNAME /etc/sysconfig/network
cat /etc/redhat-release | awk -F "&&&" '{print "OS VERSION: " $1}'
echo
echo "NETWORK INFO:"
echo "#################################################################"
/sbin/ifconfig | grep -A1 eth0 |grep "inet addr" | awk '{print $2}' |awk -F ":" '{print "ETH0 IP ADDRESS: " $2}'
/sbin/ifconfig | grep -A1 eth1 |grep "inet addr" | awk '{print $2}' |awk -F ":" '{print "ETH1 IP ADDRESS: " $2}'
echo "#################################################################"
echo
echo "CPU INFO:"
echo "#################################################################"
cat /proc/cpuinfo |egrep "processor|model name|cpu MHz|physical id"
echo "#################################################################"
echo
cat /proc/meminfo | grep MemTotal | awk '{print "SYSTEM MEMORY: "$2"KB"}'
echo
echo "HARD DISK INFO:"
echo "#################################################################"
dmesg | grep SCSI | grep MB
echo
df -lTh
echo
echo "##################### END OF INVENTORY ########################"
exit 0

Finding all large files on a linux host

I ran across the common problem of one of our file systems running short on space and needed to figure out what was all of a sudden occupying most of the space. Google pointed me to a DZone Snippets post on the subject.

The command worked as written, but if the results list was long, it was fairly difficult to identify the worst offenders. Reordering the awk output fixed that and a quick sort puts the biggest files at the bottom of the results. The only other changes were to use the "M" option to specify megabytes vs. kilobytes and to remove the human readable switch from the ls command. This allows the results to be accurately sorted. Otherwise, files with sizes in the gigabytes would appear at the top of the results.

This is what I ended up using:

find / -type f -size +50M -exec ls -l {} \; | awk '{ print $5 " -- " $9 }' | sort -n

Update (8-11-09):

So the original command above works, but does not take into account directory and filenames with spaces in them. The following awk command resolves that problem, but does have one known issue. If the filename is the same as another value on the line (e.g. user/group is root and filename is root), it will spit out everything from the user/group field on. I have not seen this behavior using the full command.

find / -type f -size +50M -exec ls -l {} \; | awk '{ print $5 " -- " substr($0,index($0,$9))}' | sort -n

SATA hardware write blocker, anyone?

In the course of our automated malware analysis, we have made use of CorePROTECT's CoreRESTORE IDE hardware write blocker. Unfortunately, I bought the last four available and without a significant (i.e. 500+) order, they do not plan on doing another production run.

It is becoming increasingly difficult to buy modern systems with IDE drives. Enter the problem. No one seemingly makes hardware write blockers for SATA drives.

There are plenty of software options out there, such as Microsoft's SteadyState, DeepFreeze, Returnil, and CornerStone (see: SANS discussion of multiple products). All of these work with varying degrees of success and detectability. CoreRESTORE blockers work extremely well, but aren't foolproof when it comes to detection. Fortunately, we have not run across any malware that specifically looks for this hardware.

Why don't we use virtual systems, snapshots, etc...? We do. But we always have physical systems ready, in case the malware is VM aware.

If you are aware of anyone else manufacturing hardware write blockers, especially for modern drives, please reply.

Mounting cdrom in %post on RHEL/CentOS 5.x

Problem: The anaconda tarball contains(ed) a change that causes RHEL/CentOS 5.x installs to prematurely eject the cdrom/dvd before %post is executed in custom installs. There is discussion of what is affected here. In addition to the eject issue, /dev/cdrom no longer exists during the 5.x install process.

Solution Part 1: To resolve the cdrom eject issue, you need to modify the /usr/lib/anaconda/dispatch.py script in the stage2.img file from your custom install media. In order to mount and edit the stage2.img file, I did the following (based upon Ansari Imtiyaz's post here):

Copy the existing stage2.img file to the /tmp directory
# cp /images/stage2.img /tmp/old_stage2.img
# mkdir /mnt/old_stage2

Mount the old image
# mount -o loop /tmp/old_stage2.img /mnt/old_stage2

The old image is non-writable at this point, so we tar the files to move them to a writable folder
# cd /mnt/old_stage2
# tar -cvf /tmp/temp_stage2.tar .
# mkdir /tmp/new_stage2
# cd /tmp/new_stage2
# tar -xvf /tmp/stage2.tar

Once the tar file has been expanded, edit the /tmp/new_stage2/usr/lib/anaconda/dispatch.py file by flip-flopping the "methodcomplete" and "dopostaction" lines, as described here. Once editted, the "methodcomplete" line should follow the "dopostaction" line.

Create the new image file
# cd /tmp
# mkfs.cramfs stage2/ stage2.img.new

Copy the new image file into place
# mv /images/stage2.img /images/stage2.img.old
# cp /tmp/stage2.img.new /images/stage2.img

Solution Part 2: To resolve the issue with /dev/cdrom not existing during the install process, follow the instructions provided here (comment #3). I had to adjust Micah's sed command to properly provide the drive alias and to mount in a location that matches what is already in my kickstart:

### Insert into kickstart ks.cfg file after %post
cdrom=`cat /proc/sys/dev/cdrom/info | grep "drive name:" | sed 's/^drive name:\W*//'`
echo "CD ROM device is $cdrom; making dev link..."
ln -s /dev/$cdrom /tmp/cdrom
mount -t iso9660 -o ro /tmp/cdrom /mnt/cdrom