In my previous post, I started exploring how to pull information from a puppet stored config DB to use in capistrano, inspired by joe-mac's post.

Well, it seems that the query I used was overly complex. Here's the simplified version:

select h.name
from hosts h
join resources r on h.id = r.host_id
where r.restype = 'Class'
and r.title = 'site::profile::dnscache::local'
order by h.name;

Having established this, I then modified joe-mac's ruby script to look up based on Class rather than facts. Here's the modified script:

#!/usr/bin/env ruby

require 'getoptlong'
require 'puppet'
require 'rdoc/usage'

ActiveRecord::Base.establish_connection(
   :adapter  => 'mysql',
   :database => 'puppet',
   :host     => 'localhost',
   :password => 'secret',
   :username => 'puppet'
)

class Hosts < Puppet::Rails::Host; end

opts = GetoptLong.new(
   [ '--class',    '-c', GetoptLong::REQUIRED_ARGUMENT],
   [ '--help',     '-h', GetoptLong::NO_ARGUMENT ],
   [ '--print',    '-p', GetoptLong::REQUIRED_ARGUMENT]
       )

printtype = "name"
opt_hash = Hash.new()
opts.each do |opt, arg|
   case opt
      when '--class'
         opt_hash['class'] = arg
      when '--help'
         RDoc::usage
      when '--print'
         printtype = arg
   end
end

query = "(resources.restype = \'Class\' AND resources.title = \'#{opt_hash['class']}\')"

puts Hosts.find(:all,
                :include    => [ :resources ],
                :conditions => query
               ).map { |host| host.send(printtype) }

Next step: build this into my capistrano configuration as per joe-mac's example.

I recently enabled stored configs for my puppet installation. My primary aim for doing this was to use the collected infomation to dynamically generate lists of nodes to use with capistrano based on joe-mac's recent blog post.

The concept is simple, but very powerful: run a query on the puppet stored config database to return a list of host names matching some criteria. In my case, I just need a list of hosts that have a specific puppet class applied. So, without further ado, here's the SQL needed to produce just such a list:

select h.name
from hosts h
join resources r on h.id = r.host_id
join resource_tags rt on r.id = rt.resource_id
join puppet_tags pt on rt.puppet_tag_id = pt.id
where pt.name = 'class'
and r.restype = 'Class'
and r.title = 'site::service::dnscache::local'
order by h.name;

This example returns a list of nodes that have a local dnscache service.

To find all nodes running a mysql service I use the same query, replacing the class with site::service::mysql.

I can also modify the query slightly to find all nodes that have apache installed:

select h.name
from hosts h
join resources r on h.id = r.host_id
join resource_tags rt on r.id = rt.resource_id
join puppet_tags pt on rt.puppet_tag_id = pt.id
where pt.name = 'class'
and r.restype = 'Package'
and r.title = 'httpd'
order by h.name;

However, be aware that this does not actually tell me all nodes that have apache installed; it tells me all nodes that have the httpd package included in their puppet definitions. For example, on my LVS master node, I include the piranha package, which pulls in httpd and php as dependencies. The above query doesn't return the name of my LVS master node.

More to follow...

When (re-)building RPMS on CentOS, you need one of the buildsys-macros packages to be installed so the correct macros are defined:

http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64

So, you want a list of sshd processes you have running? Chances are, most people would do this:

# ps -ef | grep sshd
root      3223     1  0 Sep18 ?        00:00:00 /usr/sbin/sshd
root      9771  3223  0 17:27 ?        00:00:00 sshd: root@pts/2 
root      9837  9773  0 17:28 pts/2    00:00:00 grep sshd

You might even be clever enough to lose the grep process by doing something like:

# ps -ef | grep '[s]shd'
root      3223     1  0 Sep18 ?        00:00:00 /usr/sbin/sshd
root      9771  3223  0 17:27 ?        00:00:00 sshd: root@pts/2

Suppose you're only interested in child processes, ie. you want to ignore the /usr/bin/sshd process spawned by init. Hmmm, gets a bit tricky... Something like this should do it:

# ps -ef | grep '[s]shd' | grep @pts
root      9771  3223  0 17:27 ?        00:00:00 sshd: root@pts/2

Now, let's reduce that to a list of process Ids so we can send a signal to them:

# ps -ef | grep '[s]shd' | grep @pts | awk '{print $2}'
9771

But, this is all getting a bit long-winded. You're using the wrong tool for the job. Enter: pgrep

# pgrep -f sshd:
9771

What if you want a full process listing? Simple: pass the list of process Ids from pgrep to ps:

ps -fp $(pgrep -d, -f sshd:)
UID        PID  PPID  C STIME TTY          TIME CMD
root      9771  3223  0 17:27 ?        00:00:00 sshd: root@pts/2

For the full process listing it's arguable which is the best approach, but that's sort of the point I'm making. You can use either approach depending on the job in hand.

In a previous article I showed where to find SNMP MIBs for a Fortinet Fortigate firewall device. Here's how to add a new MIB to net-snmp so the toolset can use it.

FIrst, download the MIB files and copy them to /usr/share/snmp/mibs

Look at the top of the file for a line like: YOUR-MIB-NAME DEFINITIONS ::= BEGIN

"YOUR-MIB-NAME" is the name of the MIB.

Edit /etc/snmp/snmp.conf (or /etc/snmp/snmp.local.conf) and add the line:

mibs +YOUR-MIB-NAME

Full details on the net-snmp site:

http://www.net-snmp.org/wiki/index.php/TUT:Using_and_loading_MIBS

I'm monitoring a Fortinet Fortigate 310B firewall device with OpenNMS and needed the appropriate MIBs.

I found them here: ftp://support.fortinet.com/FortiGate/

Click your FortiOS version (v4.00 in my case) then the MIBS directory.

The full path is: ftp://support.fortinet.com/FortiGate/v4.00/MIBS/

Now all I need to do is get snmpwalk to use them!

We're in the process of rolling out a redundant switch configuration in the data centre. As a part of this, we're re-configuring all our servers with bonded NICs. I ran into a bit of a problem with our xen machine in that I couldn't add a bonded interface to a bridge, which is required for xen networking.

It turns out that a patch to the ifcfg-eth script fixes the issue by creating the bonded interface before creating the birdges.

The patch is here:

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=f9cfaa365ee15b7cb4585f5220702ac5f39c2743

I recently followed this guide to create a custom CA root certificate: http://sial.org/howto/openssl/ca/

One thing that is missing is how to install the certificate on all client machines.

The best I could come up with was to append the certificate to the CA bundle supplied with openssl:

openssl x509 -in ca-cert.pem -text >> /etc/pki/tls/certs/ca-bundle.crt

Anyone got a better idea?

I wanted to create a secure place to store ssl keys, etc. I decided to create an lvm logical volume and encrypt it. Here's what I did:

1. Create the logical volume (LV):
   lvcreate --size 5G --name lv_secure vg_name
2. Encrypt the LV:
   cryptsetup luksFormat /dev/vg_a001/lv_secure
3. Verify the LV is encrypted:
   cryptsetup isLuks /dev/vg_a001/lv_secure && echo Success
4. Open the secure volume and create a mapped device named "secure":
   cryptsetup luksOpen /dev/vg_a001/lv_secure secure
5. Get info about the mapped device:
   dmsetup info secure
6. Create an ext3 file system on the mapped device:
   mke2fs -j /dev/mapper/secure
7. Mount the mapped device:
   mkdir /mnt/secure
mount /dev/mapper/secure /mnt/secure
8. When you are done, unmount and close the secure device:
   umount /mnt/secure
cryptsetup remove secure
    

When reporting project status, be succinct and straight-to-the-point:

1. Punch line: The facts; no adjectives, adverbs or modifiers. "Milestone 4 wasn't hit on time, and we didn't start Task 8 as planned." Or, "Received charter approval as planned."
2. Current status: How the punch-line statement affects the project. "Because of the missed milestone, the critical path has been delayed five days."
3. Next steps: The solution, if any. "I will be able to make up three days during the next two weeks but will still be behind by two days."
4. Explanation: The reason behind the punch line. "Two of the five days' delay is due to late discovery of a hardware interface problem, and the remaining three days' delay is due to being called to help the customer support staff for a production problem."

Full article here.