Opsware Custom Attributes and You.

I realize most of the time I end up complaining about Opsware – that’s generally because it’s part of the human condition.  We say stuff when we’re upset or angry or don’t like something.  How many times have you ever called up the phone company to tell them ‘Great job!’

Yeah, I thought so.

So I figured I’d write an article on one of the great things I love about Opsware – Custom Attributes! Combined with Dynamic Groups, these puppies provide the ability to create scripts that I don’t have to duplicate for different hosts.

First, however, I should explain what Dynamic Groups are. Dynamic Groups allow the user to group systems based on certain criteria. For instance, you want all the systems in a certain network to be grouped together. Whenever you add a system from that network into Opsware, it automatically becomes a member of that group. Neat by itself but nothing extraordinary.

However, you can assign Custom Attributes ( further known as CAs ) to the Dynamic Group. So for my new dynamic group that I created ( for example, a group that pulls in all hosts in the 192.168.0.0/24 network ), I can assign some CAs to the group and the CAs get assigned to each host within the group.

You may ask yourself, ‘Why is this useful?’. It’s not yet. There’s one more piece that’s missing from the puzzle. The piece that is missing is a software package that Opsware comes with – Agent Tools. When you install the Agent Tools, it comes with a set of python Opsware APIs and small scripts that use the API to make calls back to the master Opsware system and get information – including those CAs!

Armed with these 3 pieces, it becomes easy to create a script that uses the CAs that are dynamically assigned to your host to do all sorts of things. For example, let’s say you want to create a script that checks your /etc/resolv.conf on any system in that 192.168.0.0/24 network. First, we’ll create the dynamic group and assign it the correct device membership.

Next, edit the group and add a CA named something like ‘DNS_SERVERS‘. For the value, put in a DNS server on separate lines and then save your group. Make sure you’ve got the agent tools package installed and we can run a simple test.

[root@frenzy1a.star.dev:~]# /opt/opsware/agent_tools/get_cust_attr.sh DNS_SERVERS
192.168.0.20
192.168.0.21

With that information, we can create a pretty simple shell or python script ( pick your poison ) to make sure that our /etc/resolv.conf has those servers defined. For kicks, here’s an example script that checks to make sure the IPs in the DNS_SERVERS CA are set in /etc/resolv.conf. You could easily modify this so that it actually inserts the values.

#!/opt/opsware/agent/bin/python

import sys
sys.path.append('/opt/opsware/agent_tools/')
import agenttools_common
import re
from string import split
from pytwist.com.opsware.custattr import NoSuchFieldException

def searchFile(file,pattern):
    found = 0
    search = re.compile(pattern)
    try:
        f = open(file, "r")
    except IOError:
        sys.stderr.write("Could not open file %s.n" % (file))
        sys.exit(3)

    for line in f.readlines():
        if search.match(line):
            found = 1
        break

    return found

def main(args):
    ts = agenttools_common.ts
    servers = {}
    result = 0
    hostref = agenttools_common.getServerRef()

    try:
        custattr = ts.server.ServerService.getCustAttr(hostref,
        "DNS_SERVERS", 1)
    except NoSuchFieldException:
        sys.stderr.write("Could not find custom attribute DNS_SERVERS.n")
        sys.exit(3)

    servers = split(custattr)
    for s in servers:
        found = searchFile("/etc/resolv.conf","^nameservers+" + s)
        if not found:
            sys.stderr.write("The server %s was not configured in"
            " /etc/resolv.conf" % (s))
        result = 1

    return result

if __name__ == '__main__':
    sys.exit(main(sys.argv[1:]))

Now if I have another network, say, 192.168.120.0/24, I can do the same thing. Make the group, assign the membership, create the DNS_SERVERS CA and assign the script and presto – it’s done! No duplication of work involved here and I can control the contents of the file from the Opsware console.

One last thing about CAs – they do support overrides. For instance, I can override the CA by creating the same named CA on the host itself. This will override the CA at the group level. One thing you need to be careful, however, is that you don’t assign a host into two groups that define the same CA – there’s no priority between the groups and they don’t combine the contents of the CA to make one CA, so you’ll get random results.