First grab the newest driver from NVidia, and install in whichever kernel you intend to run on the workstation. Next modify your xorg.conf, adding:

Section "Extensions"
   Option         "Composite" "false"
EndSection

This section is required for running any Stereo, whether it be on a CRT or an LCD on RHEL 5. For the description of what it does, I’d suggesting heading over to Archlinux’s Wiki.

Next you’ll need to setup the Screen section to allow for Stereo (Mode of 10 with LCDs):

Section "Screen"
   Identifier     "Screen0"
   Device         "Videocard0"
   Monitor        "Monitor0"
   DefaultDepth    24
   Option         "metamodes" "DFP: 1920x1080_120 +0+0"
   Option         "Stereo" "10"
   SubSection     "Display"
      Depth       24
      Modes      "nvidia-auto-select"
   EndSubSection
EndSection

You’ll also need your monitor and video card setup correctly:

Section "Monitor"
   Identifier     "Monitor0"
   VendorName     "Alienware"
   ModelName      "AW2310"
   HorizSync       30.0 - 140.0
   VertRefresh     56.0 - 120.0
   Option         "DPMS"
EndSection

Section "Device"
   Identifier     "Videocard0"
   Driver         "nvidia"
   VendorName     "Videocard vendor"
   BoardName      "NVIDIA Quadro FX (generic)"
EndSection

At this resolution there is not enough bandwidth in a single channel DVI cable to run Stereo, so you will need a dual channel cable. Take note that if you run the system through a KVM, it too will need to support dual channel. I have a single setup running the IOGear GCS1782 and it has functioned flawlessly so far.

For a list of supported hardware, hit up NVidia’s site. Don’t forget to order your 3D Vision Kit.

Using 1 Core:

[user@server source]$ pbzip2 -p1 -v -m1000 source.tar
Parallel BZIP2 v1.1.1 - by: Jeff Gilchrist [http://compression.ca]
[Apr. 17, 2010]             (uses libbzip2 by Julian Seward)

# CPUs: 1
BWT Block Size: 900 KB
File Block Size: 900 KB
Maximum Memory: 1000 MB
-------------------------------------------
File: 1 of 1
Input Name: source.tar
Output Name: source.tar.bz2

Input Size: 445163520 bytes
Compressing data (no threads)...
Output Size: 80063773 bytes
-------------------------------------------

Wall Clock: 95.100318 seconds

Using 64 Cores:

[user@server source]$ pbzip2 -p64 -v -m1000 source.tar
Parallel BZIP2 v1.1.1 - by: Jeff Gilchrist [http://compression.ca]
[Apr. 17, 2010]             (uses libbzip2 by Julian Seward)

# CPUs: 64
BWT Block Size: 900 KB
File Block Size: 900 KB
Maximum Memory: 1000 MB
-------------------------------------------
File: 1 of 1
Input Name: source.tar
Output Name: source.tar.bz2

Input Size: 445163520 bytes
Compressing data...
Output Size: 80063773 bytes
-------------------------------------------

Wall Clock: 3.795763 seconds

Needless to say I’ve found a new utility for my compression needs.

You just need to:

1. Copy over ‘puppet_dashboard.rb’ with a modified HOST line to the other host.
2. Modify /etc/sysconfig/puppetmaster.
3. Turn on reporting on the clients.
4. Restart puppetmaster.

Since the puppet_dashboard.rb is just making an HTTP post to the dashboard server, it can be coming from anywhere.

My next trick is useful for getting around having your HTTP usage tracked and filtered, this is just taking advantage of the “-D” option within the ‘ssh’ program.  When you invoke the -D option, followed with a port number you not only connect to the remote machine via SSH, but you also create a SOCKS proxy server on the port specified.  Setting up your browser’s proxy settings to point at that port on your local machine will securely forward any requests over to the remote machine, where they will then go out to their final destination.

When you combine corkscrew with ssh -D, you end up with a single, secure connection through the HTTP proxy to your remote machine with a SOCKS proxy through it.  This effectively gives you an easy unfiltered hole through to the outside.

Disclaimer: Check with your IT policies before attempting any of the above to make sure its allowed!

./asu64 set SYSTEM_PROD_DATA.SysInfoSerialNum serial_number
./asu64 set SYSTEM_PROD_DATA.SysInfoProdName type_model

Now obviously you’ll be replacing serial_number and type_model with what you want to update the machine too, so don’t just run those commands outright.

Another note of interest was that the machine originally did not have the latest UEFI or IMM firmware on them – and the update would not take – so update everything before attempting this.

For those interested you can also run a ‘show’ on the above information to get the serial and model – I mention this because it does not look like dmidecode works for reading that information any longer.

Creating a chroot environment is fairly easy. You’ll need a folder to put it in, and root access to the machine your on to create it. For this example lets use /rhel4_chroot/, so first just create that directory. Next you’ll need access to RPMs from a RHEL4.8 DVD, or really just have a place to pull them from – so it can be a repo or whatever. You’ll want to install a few rpms to that root to make the basic linux environment available when you chroot to that directory. You can do this a number of ways, what I found that you’ll need on a most basic level is the following (from Centos 4.8 Base):

rpm --root "/rhel4_chroot/" -i \
binutils-2.15.92.0.2-25.x86_64.rpm \
glibc-2.3.4-2.43.x86_64.rpm \
glibc-common-2.3.4-2.43.x86_64.rpm \
tzdata-2009f-1.el4.noarch.rpm \
libgcc-3.4.6-11.x86_64.rpm \
basesystem-8.0-4.noarch.rpm \
setup-2.5.37-3.el4.noarch.rpm \
bash-3.0-21.el4.x86_64.rpm \
mktemp-1.5-20.x86_64.rpm \
filesystem-2.3.0-1.x86_64.rpm \
info-4.7-5.el4.2.x86_64.rpm \
libtermcap-2.0.8-39.x86_64.rpm \
ncurses-5.4-15.el4.x86_64.rpm \
zlib-1.2.1.2-1.2.x86_64.rpm \
termcap-5.4-3.noarch.rpm \

This will give you an environment you can chroot too and have a very basic set of tools available. To get to a point where you can run Insight II you’ll need a few more. In my case I didn’t want to play the dependency game, so I just installed everything needed to run yum from within the enviroment:

rpm --root "/rhel4_chroot/" -i \
yum-2.4.3-4.el4.centos.noarch.rpm \
coreutils-5.2.1-36.el4.centos.x86_64.rpm \
python-2.3.4-14.7.el4.x86_64.rpm \
libacl-2.2.23-5.4.el4.x86_64.rpm \
python-elementtree-1.2.6-5.el4.centos.x86_64.rpm \
python-sqlite-1.1.7-1.2.1.x86_64.rpm \
libxml2-python-2.6.16-12.6.x86_64.rpm \
yum-metadata-parser-1.0-8.el4.centos.x86_64.rpm \
grep-2.5.1-32.4.el4.x86_64.rpm \
pam-0.77-66.26.x86_64.rpm \
pcre-4.5-4.el4_6.6.x86_64.rpm \
sed-4.1.2-7.el4.x86_64.rpm \
rpm-python-4.3.3-32_nonptl.x86_64.rpm \
rpm-4.3.3-32_nonptl.x86_64.rpm \
glib2-2.4.7-1.x86_64.rpm \
elfutils-0.97.1-5.x86_64.rpm \
popt-1.9.1-32_nonptl.x86_64.rpm \
beecrypt-3.1.0-6.x86_64.rpm \
rpm-libs-4.3.3-32_nonptl.x86_64.rpm \
findutils-4.1.20-7.el4.3.x86_64.rpm \
db4-4.2.52-7.3.el4.x86_64.rpm \
libxml2-2.6.16-12.6.x86_64.rpm \
libstdc++-3.4.6-11.x86_64.rpm \
audit-libs-1.0.16-4.el4.x86_64.rpm \
shadow-utils-4.0.3-66.RHEL4.x86_64.rpm \
elfutils-libelf-0.97.1-5.x86_64.rpm \
cracklib-2.8.9-1.3.x86_64.rpm \
cracklib-dicts-2.8.9-1.3.x86_64.rpm \
libselinux-1.19.1-7.4.x86_64.rpm \
bzip2-libs-1.0.2-14.el4_7.x86_64.rpm \
sqlite-devel-3.3.6-2.x86_64.rpm \
sqlite-3.3.6-2.x86_64.rpm \
chkconfig-1.3.13.5.EL4-1.x86_64.rpm \
python-urlgrabber-2.9.8-2.noarch.rpm \
centos-release-4-8.x86_64.rpm \
openssl-0.9.7a-43.17.el4_7.2.x86_64.rpm \
krb5-libs-1.3.4-62.el4.x86_64.rpm \
initscripts-7.93.34-1.centos4.x86_64.rpm \
udev-039-10.29.el4.x86_64.rpm \
ethtool-6-1.x86_64.rpm \
SysVinit-2.85-34.4.x86_64.rpm \
gawk-3.1.3-10.1.x86_64.rpm \
net-tools-1.60-39.el4.x86_64.rpm \
lvm2-2.02.42-5.el4.x86_64.rpm \
device-mapper-1.02.28-2.el4.x86_64.rpm \
util-linux-2.12a-24.el4.x86_64.rpm \
audit-1.0.16-4.el4.x86_64.rpm \
hotplug-2004_04_01-7.10.x86_64.rpm \
usbutils-0.11-7.RHEL4.1.x86_64.rpm \
hwdata-0.146.33.EL-17.noarch.rpm \
e2fsprogs-1.35-12.24.el4.x86_64.rpm \
libsepol-1.1.1-2.x86_64.rpm \
sysklogd-1.4.1-28.el4.x86_64.rpm \
module-init-tools-3.1-0.pre5.3.11.x86_64.rpm \
kernel-2.6.9-89.EL.x86_64.rpm \
mkinitrd-4.2.1.13-4.x86_64.rpm \
kudzu-1.1.95.26-1.x86_64.rpm \
cpio-2.5-16.el4.x86_64.rpm \
gzip-1.3.3-17.rhel4.x86_64.rpm \
hal-0.4.2-8.EL4.x86_64.rpm \
dbus-0.22-12.EL.9.x86_64.rpm \
dbus-glib-0.22-12.EL.9.x86_64.rpm \
tar-1.14-12.5.1.RHEL4.x86_64.rpm \
mingetty-1.07-3.x86_64.rpm \
less-382-4.rhel4.x86_64.rpm \
iputils-20020927-22.el4.x86_64.rpm \
iproute-2.6.9-4.el4.x86_64.rpm \
psmisc-21.4-4.1.x86_64.rpm \
procps-3.2.3-8.17.x86_64.rpm \
which-2.16-4.x86_64.rpm \
MAKEDEV-3.15.2-3.x86_64.rpm \
gdbm-1.8.0-24.x86_64.rpm \
gmp-4.1.4-3.x86_64.rpm \
libattr-2.4.16-3.1.el4.x86_64.rpm \
readline-4.3-13.x86_64.rpm \
expat-1.95.7-4.x86_64.rpm \
newt-0.51.6-10.el4.x86_64.rpm \
libcap-1.10-20.x86_64.rpm \
slang-1.4.9-8.x86_64.rpm

Now you see what I mean by “the dependency game”. Now if you don’t want to waste the space you can skip yum and figure out the exact dependencies for Insight, its really up to you since its just an issue of space and what you want available. After yum was installed I went ahead and chrooted to the enviroment and added the “Compatibility Arch Development Support” yum group along with openmotif21-2.1.30-11.RHEL4.6, bind-utils, compat-libstdc++-296.i386, xorg-x11-Mesa-libGLU and copied over the basic network files (hosts, resolv.conf and nsswitch.conf). If from within your chroot enviroment yum gets upset about the rpm database, this is due to RHEL5 rpm using a different database than RHEL4 – you’ll just need to clear them out:

rm -rf /var/lib/rpm/__db*

You’ll want to remount your systems /dev and /tmp folders for use within the chroot environment, for example:

/bin/mount -o bind /dev /rhel4_chroot/dev/
/bin/mount -o bind /tmp /rhel4_chroot/tmp/

At this point Insight should run, you’ll need to devise an easy way for your users to do it – likely some sort of sudoers allowances to run the mount/unmount of the above directories along with the command to run insight as them within the chrooted environment.  Don’t forget to run a ‘yum clean all’ to clean out the rpms yum downloaded.

The environment ended up being about 700MB in this state – which was fine for us.

rm -rf /var/lib/rpm/__db*

I’ll start with the tripwire.pp file for puppet, in this file you’ll define your tripwire class and associated files and packages:

class tripwire {
        file { "/etc/tripwire/Makefile":
                owner => root,
                group => root,
                mode => 440,
                source => "puppet:///etc/tripwire/Makefile",
                require => Package[tripwire],
        }
        file { "/etc/tripwire/site.key":
                owner => root,
                group => root,
                mode => 440,
                source => "puppet:///etc/tripwire/site.key",
                require => Package[tripwire],
        }
        file { "/etc/tripwire/twcfg.txt":
                owner => root,
                group => root,
                mode => 440,
                source => "puppet:///etc/tripwire/twcfg.txt",
                require => Package[tripwire],
        }
        file { "/etc/tripwire/twpol.txt":
                owner => root,
                group => root,
                mode => 440,
                source => "puppet:///etc/tripwire/twpol.txt",
                require => Package[tripwire],
        }

        file { "/etc/cron.daily/tripwire-check":
                owner => root,
                group => root,
                mode => 755,
                source => "puppet:///etc/cron.daily/tripwire-check",
                require => Package[tripwire],
        }

        file { "/var/lib/tripwire/tripwire.twd":
                owner => root,
                group => root,
                mode => 440,
        }

        package {
                "tripwire":
                        ensure => "installed",
        }

        exec {
                "make -C /etc/tripwire":
                        cwd => "/etc/tripwire",
                        path => ["/bin", "/usr/bin" ],
                        creates => "/var/lib/tripwire/tripwire.twd",
                        timeout => 10000
        }

        exec {
                "tripwire --update-policy -Z low --local-passphrase '' --site-passphrase '' --quiet /etc/tripwire/twpol.txt":
                        cwd => "/etc/tripwire",
                        path => ["/sbin", "/usr/sbin" ],
                        timeout => 10000,
                        refreshonly => "true",
                        subscribe => File["/etc/tripwire/twpol.txt"],

        }
}

You’ll notice there is a Makefile defined, this will make remote management much simpler, it contains some simple house keeping items. I do not use all these within my puppet implementation, however:

all: tw.cfg tw.pol /var/lib/tripwire/tripwire.twd

clean:
        /bin/rm -f /etc/tripwire/local.key /etc/tripwire/tw.cfg /etc/tripwire/tw.pol /var/lib/tripwire/tripwire.twd

init: clean /var/lib/tripwire/tripwire.twd

local.key:
        /usr/sbin/twadmin --generate-keys --local-keyfile local.key --local-passphrase ''

tw.cfg: site.key twcfg.txt
        /usr/sbin/twadmin --create-cfgfile --site-keyfile site.key --site-passphrase '' twcfg.txt

tw.pol: tw.cfg twpol.txt
        if [ -f tw.pol -a -f /var/lib/tripwire/tripwire.twd ]; \
        then /usr/sbin/tripwire --update-policy --local-passphrase '' --quiet --secure-mode low --site-passphrase '' twpol.txt; \
        else /usr/sbin/twadmin --create-polfile --site-passphrase '' twpol.txt; \
        fi

/var/lib/tripwire/tripwire.twd: local.key site.key
        /usr/sbin/tripwire --init --local-passphrase ''

My twcfg.txt is very simple:

# required
DBFILE                 = /var/lib/tripwire/tripwire.twd
LOCALKEYFILE           = /etc/tripwire/local.key
POLFILE                = /etc/tripwire/tw.pol
REPORTFILE             = /var/lib/tripwire/report/$(DATE).twr
SITEKEYFILE            = /etc/tripwire/site.key

# e-mail notification
EMAILREPORTLEVEL       = 3
GLOBALEMAIL            = email@domain.tld
MAILMETHOD             = SENDMAIL
MAILNOVIOLATIONS       = false
MAILPROGRAM            = /usr/sbin/sendmail -oi -t

# other
EDITOR                 = /usr/bin/vim
LATEPROMPTING          = false
LOOSEDIRECTORYCHECKING = false
REPORTLEVEL            = 4
SYSLOGREPORTING        = true
TEMPDIRECTORY          = /var/tmp

Other than including the tripwire class within your site.pp file, thats about it.

Credit: The makefile was created by Steve Coile.

To do this you’ll need to copy over the following binarys from the server installation into your client’s bin directory:

• bbtest-net
• hobbitping

You’ll also need a copy of your bb-hosts and bb-services file, you’ll need to place these in your client’s etc folder. In your bb-hosts file you’ll only need the hosts that are within the private network you intend to ping, you really don’t need any grouping information within it either since when the data is sent in to your xymon server it will be assigned to the correct hosts there.

At this point you need to add a section for bbnet within your clientlaunch.cfg, yours may be different since your file locations my vary, so edit to fit your situation:

[bbnet]
ENVFILE /usr/lib/hobbit/client/etc/clientlaunch.cfg
CMD /usr/lib/hobbit/client/bin/bbtest-net --report --ping --checkresponse
LOGFILE $BBSERVERLOGS/bb-network.log
INTERVAL 5m

Since bbtest-net needs to know what to do you’ll need to copy its configuration section from hobbitserver.cfg to hobbitclient.cfg:

# For bbtest-net
CONNTEST="TRUE"
IPTEST_2_CLEAR_ON_FAILED_CONN="TRUE"
NONETPAGE=""
FPING="/usr/sbin/fping"
NTPDATE="ntpdate"
TRACEROUTE="traceroute"
BBROUTERTEXT="router"
NETFAILTEXT="not OK"

And there you have it – restart your client and it should be able to ping the clients within the private network and send to your Xymon server.  You’ll notice a column for bbtest show up for the client you setup to ping as well.   This should work for all network tests, however I’ve just tested ping.

Total Slots: 2
Total Used Slots: 2

Queue: MainQueue
Slots: 2
Reserved Slots: 0
Used Slots: 2

The master is the same, but contains information for the entire cluster. When all slots are taken, the test icon/color turns to ‘green’, when some are available the test icon/color changes to ‘clear’ I’ve also created an easy to understand graph which consists of a green area that is the total number of slots, which a red area over it showing the used slots. As slots free up the green shows itself noting there are slots available.

The Script is available for download here.

The Graph definitions are:

[sge]
TITLE SGE Used Slots
YAXIS # Used Slots
DEF:SlotsUsed=sge.rrd:TotalUsedSlots:AVERAGE
DEF:SlotsTotal=sge.rrd:TotalSlots:AVERAGE
AREA:SlotsTotal#00CC00:Total Slots
AREA:SlotsUsed#FF0000:Used Slots
COMMENT:\n
GPRINT:SlotsUsed:LAST:Used Slots  : %5.1lf (cur)
GPRINT:SlotsUsed:MAX: : %5.1lf (max)
GPRINT:SlotsUsed:MIN: : %5.1lf (min)
GPRINT:SlotsUsed:AVERAGE: : %5.1lf (avg)\n
GPRINT:SlotsTotal:LAST:Total Slots   : %5.1lf (cur)
GPRINT:SlotsTotal:MAX: : %5.1lf (max)
GPRINT:SlotsTotal:MIN: : %5.1lf (min)
GPRINT:SlotsTotal:AVERAGE: : %5.1lf (avg)\n

Update: I’ve modified my script to NOT change colors.  Seems xymon really ignores whatever you sent in since it really thinks you have no data when you turn to ‘clear’ – it was breaking my graphs.

• Modified JavaScript so it would load & function in IE
• Changed “class” to “clas” within JS, Perl, and the database. IE didn’t like using the word “class” as a variable name, changed else where for consistency.
• Stopped opening of “right-click” menu when pressed on an interface folder
• Fixed DB Schema to include basic information for default OIDs and Interfaces.
• Modified Apache configuration so SSIs would work correctly in Apache 2, changed the SSIs to only execute on .shtml files
• Renamed index.html to index.shtml

There is a database change, so you must run the sql file located in the upgrade folder!

You can download it here.