Ball Dawg! http://www.balldawg.net Just some ninja monkeys, nothing to see here. Move along. Fri, 13 Jan 2012 02:02:53 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Using HAProxy and Keepalived for HA Puppet http://www.balldawg.net/index.php/2010/12/haproxy-keepalived-puppet/ http://www.balldawg.net/index.php/2010/12/haproxy-keepalived-puppet/#comments Thu, 02 Dec 2010 19:30:43 +0000 Andrew Rankin http://www.balldawg.net/?p=359 I’ve had a “backup” puppet server for some time now, but the fail-over was completely manual. Meaning if the main puppet server failed, I’d actually need to change DNS to point to the other server. This if fine for environments where a bit of downtime does not hurt, but in a production environment it’s less than ideal. When I had a bit of spare time recently I decided to implement an automatic fail over for our environment. To do this I decided to use HAProxy for the load balancing and keepalived to manage a virtual IP.


This setup assumes that when you setup your puppet master you didn’t use the actual machine name as the puppet server name in your puppet.conf. For example, in my case I used puppet.domain.com, as apposed to the actual DNS name of the machine it lives on. puppet.domain.com is just a CNAME to the machines DNS name, but since web based SSL is based off the DNS name you are connecting too I can float different machines behind puppet.domain.com and the client is none the wiser. To do it you’ll need to sign puppet.machine.com with puppetca and mirror your CA to your backup machine.

To make this setup work, first you’ll need a virtual IP to point puppet.machine.com at and setup keepalived to manage it. The keepalived setup was fairly straight forward, both machines were on the same network so I just picked an IP and configured keepalived on each machine. In my case the configurations were as follows:

vrrp_instance VI_1 {
        interface bond0
        state MASTER
        virtual_router_id 51
        priority 101
        authentication {
            auth_type PASS
            auth_pass PASSWORD
        }
        virtual_ipaddress {
                192.168.33.61/26 dev bond0
        }
        notify_master /sw/keepalived/scripts/notify_master.sh
        notify_backup /sw/keepalived/scripts/notify_backup.sh
        notify_fault /sw/keepalived/scripts/notify_backup.sh
}

Basically for bonded interface 0, add the virtual interface of 192.168.33.61/26, and this machine has a priority of 101, or master. The three entries at the bottom are what to run if the machine should fail over or fail back. The other machine has a similar setup, except it has the priority of 100, or backup.

After starting up keepalived on both machines, they negotiate and the machine with the higher priority ends up with the IP enabled on bond0 as a secondary address.

Next I needed something to manage fail-over of the puppet “service” should the interface/IP stay up and just the puppet service fail. For this I decided to use HAProxy. It’s configuration is, again, fairly straight forward. You need to setup a front end to listen on the default puppet master port, and a back end that has both your puppet master machines in it. The configuration is as follows:

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     10000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    log                     global
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 8000

frontend        puppet 192.168.33.61:8140
    mode tcp
    default_backend     puppet0

backend puppet0
    mode        tcp
    option      ssl-hello-chk
    balance     roundrobin
    server      server1 192.168.33.17:8140 check
    server      server2 192.168.33.27:8140 check backup

This configuration and the installation of haproxy is mirrored on the second server.

Now if you recall I had some scripts that were to run should keepalived feel the need to fail to/from the backup server. Because haproxy binds to the address on start up, you can’t have it running on your backup server. To work around the script is run upon keepalived starting that IP on the system, the script starts haproxy.

With the complicated part done, it was just a matter of mirroring my puppet manifests and files between the two machines, and making sure they stay up to date. Ideally you’d have them on some sort of NAS which is just mounted on both machines which would make them being out of date impossible.

]]> http://www.balldawg.net/index.php/2010/12/haproxy-keepalived-puppet/feed/ 0 NVidia, Stereo (3D) and LCDs http://www.balldawg.net/index.php/2010/09/nvidia-stereo-3d-and-lcds/ http://www.balldawg.net/index.php/2010/09/nvidia-stereo-3d-and-lcds/#comments Wed, 01 Sep 2010 13:35:22 +0000 Andrew Rankin http://www.balldawg.net/?p=300 Back in December 2009 NVidia finally released a graphics driver for Linux that supported Stereo/3d graphics on a few LCD monitors. Since then we have purchased a few different brands of monitors but have decided to standardize on the NVidia supported Alienware AW2310. The Monitor appears very well built and has a fantastic image. When the driver was initially released there was some confusion on how to get the Stereo working on Linux under CentOS or RHEL 5. Since it’s quite simple, I thought I’d share our configuration.

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.

]]> http://www.balldawg.net/index.php/2010/09/nvidia-stereo-3d-and-lcds/feed/ 0 Parallel BZIP2: pbzip2 http://www.balldawg.net/index.php/2010/07/parallel-bzip2-pbzip2/ http://www.balldawg.net/index.php/2010/07/parallel-bzip2-pbzip2/#comments Wed, 07 Jul 2010 18:53:22 +0000 Andrew Rankin http://www.balldawg.net/?p=321 I find myself compressing files for archival purposes constantly – today I was sitting, waiting on one such compression on a SMP box and thought it seems silly that bzip2 does not use more than one CPU. After a quick flip through the man page for bzip2 I found no way to force it to use more than one core. A quick web search yielded pbzip2 (http://compression.ca/pbzip2/) – another project that does indeed allow you to use more than one CPU for compress and decompression of bzip2 files. A quick test showed a huge reduction in compression time:

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.

]]> http://www.balldawg.net/index.php/2010/07/parallel-bzip2-pbzip2/feed/ 1 Puppet Dashboard with Multiple Puppet Masters http://www.balldawg.net/index.php/2010/05/puppet-dashboard-with-multiple-puppet-masters/ http://www.balldawg.net/index.php/2010/05/puppet-dashboard-with-multiple-puppet-masters/#comments Wed, 26 May 2010 14:38:02 +0000 Andrew Rankin http://www.balldawg.net/?p=310 Mike Zupan’s blog has a nice how to on installing puppet’s dashboard on CentOS 5, following it I was able to get the dashboard up and running with ease.  Since I have two puppet master’s that I’d like to report to the dashboard I found you can easily accomplish this without a full dashboard install on each master.

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.

]]> http://www.balldawg.net/index.php/2010/05/puppet-dashboard-with-multiple-puppet-masters/feed/ 0 Breaking out of a HTTP proxy enviroment http://www.balldawg.net/index.php/2010/02/breaking-out-of-a-http-proxy-enviroment/ http://www.balldawg.net/index.php/2010/02/breaking-out-of-a-http-proxy-enviroment/#comments Tue, 09 Feb 2010 18:24:47 +0000 Andrew Rankin http://www.balldawg.net/?p=302 Being in a large corporate environment has positives and negatives, one of those negatives is that many companies use HTTP proxies to control and track internet usage from your work machines.  While in most cases this is very important from the HR and workplace productivity side, it can become a headache if you actually need something outside your companies firewalls that is blocked.  In my case I wanted to backup some configurations and code to my home machine.  To do this I’d generally just rsync over ssh or scp the files over to an off site machine.   Sadly with a full firewall up and all traffic required to go through HTTP proxies, I had to find a different solution.  In my case, I decided to use ‘corkscrew’.

Corkscrew tunnels SSH connections through HTTP proxies, you can find it at agroman.net/corkscrew/.  It was quite easy to setup, and with some tweaks to your ssh config you can seamlessly use it.

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.

You can also use this trick for getting rsync through a http firewall that might otherwise block it.  To accomplish this you just have setup your RSYNC_CONNECT_PROG environment variable to “/path/to/corkscrew <proxy> <proxy_port> %H 873 <auth_file>”.

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

]]> http://www.balldawg.net/index.php/2010/02/breaking-out-of-a-http-proxy-enviroment/feed/ 0 Setting Blade Type & Serial on IBM HS22 http://www.balldawg.net/index.php/2009/09/setting-blade-type-serial-on-ibm-hs22/ http://www.balldawg.net/index.php/2009/09/setting-blade-type-serial-on-ibm-hs22/#comments Tue, 22 Sep 2009 18:35:20 +0000 Andrew Rankin http://www.balldawg.net/?p=290 So you’ve had to replace a main board in your IBM blade, we’ve all been there.  Generally, should you have asked for your friendly neighborhood tech to come out, he will kindly update your fresh motherboard with the original machines serial number and machine type/model number.  If you’ve ever watched him do his work, you know on earlier blades he used the BIOs update utility from IBMs website to update that information.  Well times have changed, this is no longer an option on UEFI and IMM based blades.   Before you go and call IBM, you can use IBM’s ASU utility to update them.   When I called they actually sent me an in house bootable ISO, which ended up just booting Linux and running a shell script that ran the following two commands:

./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.

]]> http://www.balldawg.net/index.php/2009/09/setting-blade-type-serial-on-ibm-hs22/feed/ 1 How To: Accelrys Insight II 2005 on RHEL5 http://www.balldawg.net/index.php/2009/08/how-to-accelrys-insight-ii-2005-on-rhel5/ http://www.balldawg.net/index.php/2009/08/how-to-accelrys-insight-ii-2005-on-rhel5/#comments Mon, 31 Aug 2009 20:40:20 +0000 Andrew Rankin http://www.balldawg.net/?p=274 So you want to move your Linux workstations to RHEL5 but still use Insight II? If you have tried (and I know you have), you know that because of the jump in the version of GLIBC to version 2.5, Insight II won’t run. As much as we wish Accelrys would go and compile it against RHEL5, that won’t happen either. So, what does it take to get it to run? RHEL4… No, really. But we are going to be cute about it. Since all Insight needs is a few libraries to run, its just a matter of putting it in a place where it can get to them. My solution to this was making a small chroot environment in which to start up Insight in.

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*
]]> http://www.balldawg.net/index.php/2009/08/how-to-accelrys-insight-ii-2005-on-rhel5/feed/ 7 A Simple Puppet Recipe for Tripwire http://www.balldawg.net/index.php/2009/08/puppetizing-tripwire/ http://www.balldawg.net/index.php/2009/08/puppetizing-tripwire/#comments Wed, 12 Aug 2009 13:43:40 +0000 Andrew Rankin http://www.balldawg.net/?p=262 Since I failed to find a good description of how to do this on the web, I thought I’d share my recipe for using puppet to manage tripwire. This method will take care of running the initialization on the first puppetd run on a new machine, and update the policy file if its changed. It also has puppet managing your site.key, twcfg.txt, twpol.txt, and the daily cron to run the checks. Its an extremely simple setup, but gets the job done.

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.

]]> http://www.balldawg.net/index.php/2009/08/puppetizing-tripwire/feed/ 1 Pinging Xymon clients on an unreachable network http://www.balldawg.net/index.php/2009/07/pinging-xymon-clients-on-an-unreachable-network/ http://www.balldawg.net/index.php/2009/07/pinging-xymon-clients-on-an-unreachable-network/#comments Sun, 19 Jul 2009 22:21:34 +0000 Andrew Rankin http://www.balldawg.net/?p=252 I recently ran into an issue where my I had Xymon clients on a network which was unpingable from the Xymon server.  The clients could could send data to the server, but they were hidden behind network address translation and only on a local network.  I had one box (the gateway for the unreachable clients), that saw both networks.  I played with the idea of running bbproxy on it, but didn’t really want an entire Xymon server and it really was not necessary since the other clients could get their data out.  Looking at hobbitlaunch.cfg I noticed it was really just a larger clientlaunch.cfg, which gave me the idea of just copying over bbnet and using on a client install – which worked perfectly.

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.

]]> http://www.balldawg.net/index.php/2009/07/pinging-xymon-clients-on-an-unreachable-network/feed/ 0 Monitoring Sun Grid Engine with Xymon http://www.balldawg.net/index.php/2009/07/monitoring-sun-grid-engine-with-xymon/ http://www.balldawg.net/index.php/2009/07/monitoring-sun-grid-engine-with-xymon/#comments Mon, 06 Jul 2009 17:13:01 +0000 Andrew Rankin http://www.balldawg.net/?p=239 After a recent job switch I’ve had the opportunity to setup Xymon from scratch and start developing even more scripts for new pieces of software and work flows. One of my first tasks was to setup a new “cluster” using all the software I felt most comfortable with as a show case in order to determine if my preferred tools worked as well or better than the currently used ones – or not. After a week or so of setting up a full Cobbler installation, Xymon and my own Glovebox, I presented it to my new employers with positive responses. After all that work I wanted to make sure that the people using the system were as happy as possible with the monitoring needs – one thing was mentioned more than others, which was the ability to easily see the status of Sun’s Grid Engine running on the cluster. I immediately set to work and came up with a quick solution for them using Xymon and a script that parsed the output of ‘qstat -f’ As with my Xen monitoring script, it runs in one place and sends in data for all the associated machines. Meaning for each execution node you’ll have a column with just its information, and a combined column for the qmaster. The output is as follows:

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.

]]> http://www.balldawg.net/index.php/2009/07/monitoring-sun-grid-engine-with-xymon/feed/ 0