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

import sys
sys.path.append("/opt/opsware/pylibs")
sys.path.append("/opt/opsware/agent/pylibs")

from pytwist import *
from pytwist.com.opsware.device import DeviceGroupRef

ts = twistserver.TwistServer()
ds = ts.device.DeviceGroupService
ss = ts.server.ServerService

# Enter your username and password here
ts.authenticate("username","password")

# Enter the device group object ID for the group you want to iterate over
# You can get this object ID from the GUI
dgref = DeviceGroupRef(#######)
srefs = ds.getDevices(dgref)
for sref in srefs:
    svo = ss.getServerVO(sref)
    print "Updating %s" % svo.name
    # Set the stage.  This has to be a valid option - these are always in caps.
    svo.stage = "PRODUCTION"
    ss.update(sref, svo, 0, 0)

There are a few ways you can go around doing this. You can use filters and the search capability, you can manually create your ref, or you can find the refs via other objects, like device groups. The last one I mentioned is actually a very good way to loop through a set of systems to perform a task.

I’ll display the first method in this article and write up the other two later.

The first thing we need to do is get our script reference. Every object you work with in SA generally has a reference object and what I call the ‘virtual object’ ( or whatever VO really stands for ). The VO contains all the important attributes where as the reference only contains the id of the object in SA and the name. There are some methods contained in the VO, but the pytwist API makes common use of a ‘Service’ interface for specific types of objects, like the ServerService, the ServerScriptService, the SearchService, JobService, DeviceGroupService and so on that contain the methods that really make use of the VOs.

This first script enables us to run a known SA script on a known host thru SA from a command line. Note that the command line can be any host that has an agent – this doesn’t need to be run from the core.

I’ll show the script first, then explain it. This script is a version that can be run from an agent that has the Python 2 API Access for Server module installed.

import sys
from optparse import OptionParser
from getpass import getpass
sys.path.append('/opt/opsware/smopylibs2')
sys.path.append('/opt/opsware/agent_tools/') 

import agenttools_common
from pytwist import *
from pytwist.com.opsware.server import ServerRef
from pytwist.com.opsware.script import ServerScriptRef
from pytwist.com.opsware.custattr import NoSuchFieldException

ts = twistserver.TwistServer()

ss = ts.server.ServerService
scs = ts.script.ServerScriptService

# This is the same basic authentication scheme used in most of
# my scripts.  You can tear this out and just use the
# ts.authenticate method with the values already filled in.
parser = OptionParser()
parser.add_option("-u","--user",dest="sauser",
                  help="SA login id")
parser.add_option("-p","--pass",dest="sapasswd",
                  help="SA login password")
parser.add_option("-r","--prompt",action="store_true",dest="readstdin",
                  help="Prompt for passwords instead of using arguments")

(options, args) = parser.parse_args()

if not options.sapasswd and not options.readstdin:
        print "You must specify a password to login to SA."
        sys.exit(1)

if not options.sauser:
        print "You must specify a username to login to SA."
        sys.exit(1)

if options.readstdin:
    options.sapasswd = getpass("Enter Opsware Password: ")

ts.authenticate(options.sauser, options.sapasswd)

# Now the real work starts

# Create a reference to a script we know the ID of
# The ID can be obtained from the SA Gui
scriptRef = ServerScriptRef(22530102)

# Create a reference to a server we know about
serverRef = ServerRef(730102)

# In order to run the script, we'll use the startServerScript method
# from the ServerScriptService.  It requires the script ref, an arugments
# object.  We can optionally give it a tag that it will put under
# the ticket ID.  There are also optional arguments for a job notification
# and job schedule that I won't cover here.
#
# We have the reference already, so we need to create the job argument
# object.  We only need to set the list of targets, although there are
# options for setting the username and password of the script

# Creates the object
scriptArgs = com.opsware.script.ServerScriptJobArgs()

# Requires a list of scriptableRefs, which can be ServerRefs,
# DeviceGroupRefs or HypervisorRefs.  In our case, ServerRefs
scriptArgs.targets = [serverRef]

# Now we can run the job
runScript = scs.startServerScript(scriptRef, scriptArgs, 'Ticket ID #001', None, None)
print "Job started as id %d" % runScript.id

So, besides the basic authentication and argument parsing, there isn’t too much to this script. We have to create the references needed and we do that by importing the references in from pytwist and then using them as constructors like so:

from pytwist.com.opsware.server import ServerRef
from pytwist.com.opsware.script import ServerScriptRef
...
scriptRef = ServerScriptRef(22530102)
serverRef = ServerRef(730102)

In order to run the script, we need to call the startServerScript, which is part of the ServerScriptService interface. But, in order to call it, we need to create one more object, the ServerScriptJobArgs object. We create the object by calling the constructor directly:

scriptArgs = com.opsware.script.ServerScriptJobArgs()

You should note that we could have done the same things with the ServerRef and ScriptRef constructors. Instead of importing them and then calling them, we could have simply done this:

scriptRef = com.opsware.script.ScriptRef(22530102)
serverRef = com.opsware.server.ServerRef(730102)

Generally I’m using alot of server refs, so I like to import to save on typing. Either way, we now have a blank ServerScriptJobArgs object that we need to fill. In our case, we only need to fill out the targets attribute, which is actually a list of any Scriptable Ref. This tells our script which targets it’s going to run on. As mentioned in the comments, a scriptable reference is either a DeviceGroupRef, a ServerRef or a HypervisorRef. Since we have a ServerRef, we just need to contain it in a list and assign it to the targets attribute:

scriptArgs.targets = [serverRef]

Everything is setup now, so I can just call the startServerScript method. The method takes 5 arguments, 3 of which are optional. The 3 optional requires are a ticket id tag, a job notification object and a job schedule object. The ticket id tag is just a string, so it’s easy to create but I’m not going to bother with the other two, so our call looks like this:

runScript = scs.startServerScript(scriptRef, scriptArgs, 'Ticket ID #001'
, None, None)

Remember that the ‘scs’ is just a shortcut to the ServerScriptService. We could have called this method another way:

runScript = scs.startServerScript(scriptRef, scriptArgs, 'Ticket ID #001', None, None)

Again, I prefer the former just to save on typing if I plan on using the service multiple times. The method returns a Run Server Script instance, which we can do other things with, but that’ll have to wait for another article. In the example, I print out the job ID so that I can find and verify the job in the GUI easily.

That’s it for now – in the next article I’ll show how you can use the filter to give the user a way to specify the name of the script they want to run and on which servers.

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.