This means if you want to concentrate on just the Critical problems, you can tell SCM to use --rule-level critical, and it will only run the audit rules that are marked as being critical. If you’ve got a lot of audit issues, this can help you focus on specific problems.

Alternately, you might want to just run the Info rules to learn about the environment, and don’t want any noise about Warnings or Errors. No problem: --rule-level info

You can chain some rule levels together if you want to see just Warnings and Errors, or Info and Critical, or any combination you want.

The default is still to run all the rules you load.

Until now, the audit logic was based on the Rule condition evaluating to False. This was actually the opposite of what it should have been. It was originally written from a perspective of “check that this is true. If it isn’t, that’s a problem”, which makes a certain kind of sense if you think about it in that way.

The problem with this logic is that it’s usually the opposite of what you expect it to be. When writing an audit rule, you’re generally checking for something that’s broken. The logic in your head is “if this happens, that’s bad, so tell me”, which is the exact logical opposite of the original logic.

Several times I’ve found myself writing a new audit rule and having it fail in testing, and then doing a facepalm and thinking “oh yeah, that’s right. This thing wants it to be the other way around.” If I have trouble with this, what chance do you have?

So I changed it. And it’s much better this way.

Sometimes you have devices that suddenly spew forth a bunch of errors. They may have been nudging along generally ok, only to suddenly reach a tipping point where all hell breaks loose. No doubt you’ve encountered this yourself.

Until now, SCM was rather noisy in the way it reported on this sort of situation. The report screen would contain a seemingly endless list of errors. Anyone who’s used NetApp devices with poorly configured clients will know all about the spamming FC partner path errors that fill up the message logs.

When everything is mostly ok, SCM reports were easy enough to read. But the real strength of SCM is automatically telling you every little thing that’s broken. You need to be able to filter this to concentrate on what you want to fix.

Now you can.

SCM reports now have some funky Javascript that lets you collapse down sections of the report so they don’t clutter your view. You can get a quick idea of where the problem areas are, and drill into the details if you really want to.

Sometimes just a count of how many times the audit rule was broken is all you want to know. SCM now does that too.

A big thankyou to the folks from jQuery who made this possible with their excellent library.

easy_install ModiPy

Easy!

What’s New?

This version of ModiPy is the most stable yet. It’s still beta, since there are some areas that don’t have enough test coverage yet, but we’re definitely getting there. We’ve also added a bunch of much wanted features.

Iterators

Iterators are like a for loop wrapped around a change. Unlike a standard for loop, and iterator uses dictionaries, so you can define a whole set of variable that can all change for each iteration.

So you can define a change that runs the same set of commands, but over 3 different base directories. Or you can add a series of license keys to a program, with the one change.

It’s variable substitution on steroids.

There’s support for manually defined iterators, where you type it all out yourself, or you can use a CSV file to define variables as columns, and the values in rows. Database support is coming, so you can integrate more easily with your CMDB. For now, you’ll have to manually export as CSV.

Complex Dependency Trees

You can define really complex trees of changes that will all execute in the right order, even in backout mode.

We’ve also added the noop flag for changes, so you can define an empty change with no targets (which would normally be an error) to act as a synchronisation point in your dependency tree.

Handy Command Line Options

We’ve added a few commandline options to help with testing, which we use ourselves.

–only will run just the changes you specify on the commandline

–skip is the opposite of –only, and will not run the change you specify. It is marked as successful for dependency purposes.

–sessionlog allows you to set the name of the logfile used for logging what happened.

Logging

All sessions are now logged by default, so you can audit what changes are applied to your environment. We’ll be adding an option to disable logging for those who need to run things unlogged.

Stay Tuned

We’re working hard on getting another version out soon. Please let us know if you hit a bug, or if you want a feature we haven’t already noted down in the tracker.

Until then, have fun automating your world!

I’ve been adding a bunch of test cases to ModiPy to make the code quality better, and to chase down some corner cases that were really annoying me.

I’m pleased to say that I’ve got bunch of tests written, and the code passes most of them.

Most interestingly, the real world example that kicked off this bughunt was my desire to automate the installation and baseline configuration of a NetApp simulator. I do this a bunch, and wanted to stop having to remember all the steps to set one up, get some disks connected to it, configure both nodes, license the cluster, etc., etc. Yawn.

In my professional life, we get installation engineers to do this for physical Filers by following a written, printed document, called a Build guide. It’s a manual process. Some parts of it have to be, like getting it plugged in and connected to a network. But from then on, it could be automated. Better yet, we can then automate the testing of the configuration to make sure it’s correct, before the engineer leaves the site. People make mistakes, so do installation engineers. Having to manually check all the settings are correct on a newly installed 6070 cluster is a major pain in the ass.

Sure, you could write your own custom Makefile or shell script. But that sucks, and doing all the error checking is the biggest pain. Wouldn’t it be great if you could just grab a template from somewhere that does 95% of what you want, and just tweak a few variables?

Show me the code

That’s one of the goals of ModiPy. So, I’ve uploaded the configuration I just used to successfully install a NetApp simulator as a 2 node cluster, configured with an IP address, hostname and the cluster licensed. It’s even had secureadmin configured so once you boot it up from now on, you can talk directly to the simulator via ssh, just like a real Filer. You can check out the example ModiPy config by clicking here.

The next stage will be to add some change templates that give me a few test lab setups so I can quickly run up some test configs whenever I need to test, say, iSCSI, or moving volumes between physicals using ndmpcopy.

And, of course, I’ll be sharing them with you. Aren’t you lucky?

Just wanted to let you know that we’ve just added the capability to send SNMP traps to the seafelt Configuration Manager auditor.

So What?

What does this mean? Well, let’s say you have a nightly audit process that generates the usual audit reports. Great. They’re probably stored on a webserver somewhere for historical purposes, or so people can go back and find out what broke when. You might also email the report to someone, maybe even a list. Someone might even read them.

When we first install the audit tool at a customer’s site, they’re often amazed at all the things they didn’t even know were broken. There’s a flurry of enthusiasm. Cool.

But after a while, complacency sets in. It’s really easy to ignore an email, particularly when you get hundreds each day. You set up a filter that puts the audit reports into a folder, and you fully intend to read them. One day.

A Sense Of Urgency

Now you can immediately send a trap from the auditor into your enterprise fault management system. The alarms will go off. You know that this is something that you must fix. Particularly if you flag that particular trap type as a Sev 1 or Sev 2 incident.

All your existing fault management processes come to bear on the problem. And the problem will get fixed. Which is the entire point of having the audit there in the first place: To detect and fix brokenness.

Configurable

Of course, you don’t want to create a Sev 1 incident for every audit rule that fails. Yes, the SNMP trapping facility is fully configurable, with sensible defaults. You can send traps on just one rule, a whole group of rules, or all rules, if you like. You can even send the traps to different destinations, if you want. No problem.

Shed some light into the dark corners of your IT operation.

Email us at scm@seafelt.com for more information!

If you haven’t signed up, go do it right now, or you’ll miss out.

Secondly, those who have signed up will be seeing some added audit information about errors reported in the NetApp /etc/messages file. No more hunting for errors on the syslog server, you can now see them all in the audit report you get from us.

We can help.

Free Auditing Service

We’ve set up an exclusive service, available for a select few people who sign up really soon, that will automate the auditing of your NetApp filers.

If you’d like to get audit reports like this, direct to your Inbox, using a free service from seafelt.com, click here.

Hurray! Limited Offer

We’re really serious about this being a limited offer. If you want in on this, don’t muck about.

Click here now or you might miss out!

It looks like this:

An example SCM audit report

This was generated by sending an AutoSupport message to SCM, using the default ruleset, just as a demo. You can change the error levels, disable some rules, whole sets of rules, define your own rules, whatever you like.

You need to upgrade the NetApp filers to a new version of Data ONTAP. You fail over one head so that you can work on it, only to discover that some of your servers have lost connectivity to their storage. Some of the configuration wasn’t right! You’d set up some of the interfaces online, but hadn’t correctly configured the cluster partner! Bugger. Now you have to figure out what was missing, and get the right config settings applied.

Sound familiar? If you’ve had to deal with all the different NetApp configuration files (/etc/snapmirror.conf, but no /etc/snapvault.conf? What the?) and the various ways you can have inconsistent clusters, you’ll know the pain of manually auditing your settings to make sure they’re correct.

If you’re a premium autosupport customer, you’ll be familiar with the tools available via NetApp’s NOW website that highlight potential problems with your configuration. You’ll also have received an audit report telling you all the potential issues with your filer fleet.

If you’re not a premium autosupport customer, you won’t have had access to these sorts of tools. Until now.

seafelt Configuration Manager can audit your equipment and tell you if your settings are inconsistent. It can detect if you’re running downrev disk firmware. It can tell you that you’ve configured interfaces online, but haven’t added the commands into /etc/rc to make them come up after a reboot.

Even if you are a premium autosupport customer, SCM can do things that the NOW website reports can’t. You can customise SCM validation rules for your site. Want to make sure your filers have the right mailhost settings? No problem. Want to check that no one has enabled rsh by mistake? Ok.

SCM can perform audits by talking directly to your filers over HTTP or HTTPS, or you can send it the same autosupport emails that you send to NetApp. You can run audits every day, rather than the default once a week for autosupport.

Don’t find configuration problems after an outage. Protect your environment with SCM.

For more information, go to scm.seafelt.com or email us at scm@seafelt.com.