– The Practice of System and Network Administration, Thomas A. Limoncelli and Christine Hogan.

Bingo. But can there be a third hybrid model?

I currently represent the decentralized model and I must agree with these two fine authors that the benefit of my close working relationship with the individual department/group is that the service provided is highly customized and focused. The central IT department(s) are understandably focused on large-scale issues (“Infrastructure”, “Communications”, “Collaboration”, “Applications”) and as such do not always represent the most ideal channel for delivery of IT services to the various research groups and departments on campus, often with more nuanced, specialized and micro-level issues.

One of my developing long-term goals is to (warning: business jargon) “bridge the gap” between the focused local support that I currently represent and the value proposition(s) of centralized IT services. I’m not yet entirely certain of how to accomplish this but I am certain that there is a way to improve the delivery of IT services to researchers across all our campuses and I want to be involved.

Does such an approach warrant the definition of a third hybrid model or is this so-called bridging of the gap already encapsulated in the model of centralized vs. decentralized?

Some of the challenges I face specifically as a “standalone” decentralized sysadmin on campus are:

• Dealing with all IT needs from desktop support to infrastructure development to data security
• Developing and maintaining vendor contacts and relationships
• No immediate peers in our environment to bounce specific ideas around with
• Weak purchasing power and negotiation leverage
• Duplication of effort
• Career progression is potentially limited
• All too easy to develop a “King of the Castle” attitude
• Complacency

Some of the concerns I hear about when introducing researchers to the idea of centralized IT support:

• General lack of trust/faith in the centralized IT department
• Perceived lack of personal attention and focus (turn around times, site knowledge, etc.)
• Perceived lack of “control” over their environment (and data!) under the centralized model
• Charge-back models for IT services are viewed as grant-unfriendly
• Physical hardware ownership appears to remain important for many researchers

Of course, this is but a snapshot of the challenges I face and the concerns I’ve been hearing but they do serve as decent examples. It must also be noted that I am seeing great progress is many of these areas already because there are very bright people here already working on these challenges. My interest in this field is absolutely not unique.

For the immediate future, I’m focusing on improving my collaborations and communication with centralized IT services by helping them out where I can and leaning on them more often for our localized problems. My hope is that by constantly forging a closer working relationship will increasingly expose me (and in turn, our group) to the benefits of the centralized IT model while providing the central IT group with greater insight into our environment and how we work.

The next steps are still a mystery to me but I’m keeping my eyes open for new opportunities to bring better IT to research.

No related posts.

Not for Domains

It’s important to keep in mind that these instructions are not for a integrating FreeIPA with a Samba domain controller but merely a Samba file server. My understanding is that FreeIPA will never conveniently/properly support the necessary bits to make it a suitable backend for a Samba 3 PDC. I believe FreeIPA will eventually look towards Samba 4 integration (using Domain trusts) for this kind of integration but don’t quote me on that. Either way, these instructions are not for Samba domain controllers, just Samba file servers.

The Assumptions

There are some basic assumptions that these instructions make.

• FreeIPA is installed and functional
• You have a general idea of how to use LDAP command line tools
• If you have a nice GUI LDAP browser, you can use it to apply the example LDIFs and edit the tree instead of the ldap CLI tools
• The LDAP commands are executed on the FreeIPA server
• Samba and FreeIPA are installed on the same server (although it shouldn’t be difficult to use TLS encryption with separate servers)
• Your LDAP suffix is “dc=domain,dc=tld”
• You know the difference between the “admin” account and the directory manager and their passwords

The Goods

Let’s not beat around the bush any further.

1. Determine your Samba server SID by executing the following command while smbd is running and jot it down:

root@ipaserver:~
# net getlocalsid
SID for IPASERVER domain  is: S-1-5-21-3180075094-3458813485-3821849995

2. With the “admin” kerberos ticket, add two attributes to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” that tell FreeIPA to setup each account as a Samba account and each group as a Samba group:

ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: modify
add: ipaUserObjectClasses
ipaUserObjectClasses: sambaSAMAccount
-
add: ipaGroupObjectClasses
ipaGroupObjectClasses: sambaGroupMapping
EOF

3. With the directory manager password and the Samba SID you jotted down from above, create an instance of the 389 DS DNA plugin that will automatically generate SIDs for your users and groups which are necessary for use with Samba:

ldapadd -x -D "cn=Directory Manager" -W <<EOF
dn: cn=SambaGroupSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
dnatype: sambaSID
dnaprefix: S-1-5-21-3180075094-3458813485-3821849995-
dnainterval: 1
dnamagicregen: assign
dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))
dnascope: dc=domain,dc=tld
cn: SambaSid
dnanextvalue: 15277
EOF

The thing to note here is that the “dnaprefix” is set to the SID your jotted down… PLUS a hyphen (“-”) appended to the end!

4. Now we have to start modifying the FreeIPA API, CLI and WebUI to allow us to specify the “sambaGroupType” attribute at group creation time. We have to set “sambaGroupType” because it is a required attribute for the objectClass “sambaGroupMapping” which we are automatically adding to every group with the “ipaGroupObjectClasses” setting from earlier.

Although the value is going to be “4″ for every conceivable case in this non-domain configuration, I was not able to figure out how to make the DNA plugin insert static values like it can set incrementing values so I decided to allow setting it through the CLI and WebUS with defaults enabled instead. If anyone knows how to setup 389 to automatically add an attribute with a static value upon DN creation of DNs with specific objectClasses, please tell me.

There are a few steps required to make this CLI/UI stuff happen but the FreeIPA developers have actually made this quite simple.

The rule is: Extend the FreeIPA schema first, then the CLI, then the WebUI.

4.1. Extend the FreeIPA schema with a custom field by adding the attribute “ipaCustomFields” with a value of “Samba Group Type,sambagrouptype,true” to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” with an “admin” kerberos ticket:

ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: add
add: ipaCustomFields
ipaCustomFields: "Samba Group Type,sambagrouptype,true"
EOF

As there can only be one “ipaCustomFields” attribute, if you have multiple custom fields you need to separate each definition with a “$” like so: “Samba Group Type,sambagrouptype,true$Description,attrname,isrequiredboolean”.

4.2. Extend the CLI for groups by editing the python file “/…/site-packages/ipalib/plugins/group.py” to define the custom field and specify a default if not implicitly defined (diff):

--- group.py.orig	2011-08-15 14:59:48.570715207 -0700
+++ group.py	2011-08-16 12:43:43.493236507 -0700
@@ -118,6 +118,13 @@
             label=_('GID'),
             doc=_('GID (use this option to set it manually)'),
         ),
+        Int('sambagrouptype',
+            cli_name='sgt',
+            label=_('Samba Group Type'),
+            doc=_('Samba Group Type (default is 4)'),
+            default=4,
+            autofill=True,
+        ),
     )

 api.register(group)

Important: Restart “httpd” at this point!

4.3. Test the CLI. With an “admin” (or equivalent priv) kerberos ticket, try creating a new group:

account@ipaserver:~
$ ipa group-add testgrp --desc="Testing the group.py CLI mods"
---------------------
Added group "testgrp"
---------------------
  Group name: testgrp
  Description: Testing the group.py CLI mods
  GID: 1234500010
  Samba Group Type: 4

4.4 With the CLI functioning properly, we can move on to extending the WebUI. To extend the WebUI for group attributes, edit “/usr/share/ipa/ui/group.js” like so (diff):

--- group.js.orig	2011-08-15 10:01:28.515209121 -0700
+++ group.js	2011-08-16 13:52:59.587352034 -0700
@@ -34,6 +34,7 @@
                 column({name: 'cn'}).
                 column({name: 'gidnumber'}).
                 column({name: 'description'}).
+                column({name: 'sambagrouptype'}).
                 dialog(
                     IPA.add_dialog({
                         'name': 'add',
@@ -41,6 +42,7 @@
                     }).
                         field(IPA.text_widget({name: 'cn', undo: false})).
                         field(IPA.text_widget({name: 'description', undo: false})).
+                        field(IPA.select_widget({name: 'sambagrouptype', undo: false, options: [{label: 'Local', value: 4}, {label: 'Domain', value: 2}]})).
                         field(IPA.checkbox_widget({
                             name: 'posix',
                             label: IPA.messages.objects.group.posix,
@@ -56,6 +58,7 @@
                     }).
                         input({name: 'cn' }).
                         input({name: 'description'}).
+                        input({name: 'sambagrouptype'}).
                         input({name: 'gidnumber' }))).
         facet(
             IPA.group_member_user_facet({

And then these the WebUI to ensure that you can both see the attribute in the group list, but also add it via the select widget added to the new/edit group dialog.

That should be it. Questions, comments, suggestions, correction and more… all are welcome!

Related posts:

1. LDAP User Management Tools and User Private Groups
2. Life Support!

Right now one machine is running an old way out of support RHEL4 installation and the other is on Fedora 12, which is no longer supported by the Fedora Project. Paid support/subscription is not a consideration yet for this project, but I do want to run a modern Linux distribution for the associated modern application software and maintenance.

I basically need to move these servers to something free and supportable. I’m finding out that there aren’t a lot of options in PPC Linux as when I was last interested in this architecture. It’s pretty much just:

• Debian
• CRUX PPC
• Gentoo

I realize there is RHEL and SuSE Enterprise for PPC64 but those are subscription products without free binaries available. I’m not prepared to build an RPM-based distro from source at this point so I need something with binaries or something where building from source is highly automated and integrated, such as Gentoo. Digression…

The question is which of these distros do I go with? To answer the question I suppose I need to define the roles.

These two pSeries servers a redundant pair running LDAP/Auth Service, NTP, DNS and DHCP. The load is low but I want a solid modern software platform on both these servers from now until they are replaced with in the future (which is likely to be integration into a centralized architecture).

With that said, and with my familiarity level of these distros, I would first lean towards Debian and then to Gentoo and finally to CRUX PPC.

Debian is a binary distribution, which is nice for maintaining a server. Debian is more familiar to me. What are the arguments for Gentoo or CRUX PPC?

Agree or Disagree?

No related posts.

At present I’m doing a technology review for implementing a new terminal server. Our existing terminal server is a 4-way AMD Opteron 848 system that’s about 5 years old right now. It runs CentOS 4 and has been so mega-customized over those 5 years, I’ve never wanted to go through the pain of in-place upgrading to CentOS 5. We also have a simple IBM 1U server running Windows 2003 Server for windows purposes. It’s ok but also about 5 years old.

The idea is to roll both these servers into a large single physical server with some kind of virtualization. The large system would also have the resources to run other VMs, as necessary. Development/test boxes or what not.

Hardware and Virtualization

The server is a 48 core AMD 6172 (2.1GHz) with 64GB of DDR3 ECC RAM with a bunch of 15K RPM SAS drives. I’m not sure whether the AMD solution is entirely the right solution. Intel does score amazingly well on virtualization workload benchmarks… but our workload is different than the benchmark workloads. What we need is one huge guest with a crap-ton of VCPUs and one guest with 2 VCPU and 4GB of RAM. The last NUMA node/cell is pinned to the Windows (smaller) VM and the Linux (large) VM is pinned across several NUMA cells. The Linux VM is a multi-user system where many users will want to run intensive computation but desktop as well. The existing server would sometimes be starved of resources when too many users would start intensive programs simultaneously.

What I can’t quite seem to figure out regarding this whole KVM this yet is if the guest is smart enough and if KVM allows for mapping the VCPUs and the guest memory according to physical NUMA topology thus reducing likelyhood of slow inter-cell memory access?

Software

Anyways… now that the server has arrived, I’ve started out with RHEL6 beta2 as the “hypervisor”, if you will. I’m obviously using KVM and libvirt as this is what RedHat is backing. So far, so good. I’ve only used virt-manager and virtsh thus far, I’ll explore other tools a little later. Fedora 14 is being used as the Linux VM and Windows 7 Enterprise for the guest… I’m going to try out using the Terminal Server multi-user hack and see how that goes. If it won’t go, I’ll recommend actually buying the correct Windows Server license, I suppose. Or buy into the VDI stuff that’s going on around me. I’ll check out the pricing I suppose… but I digress.

Linux Terminal Server: LTSP5

Fedora 14 with LTSP5 works pretty well. But there are some caveats.

1. The chroot

The current ltsp* packages in Fedora14 aren’t able to build Fedora 14 chroots. You can currently only build Fedora 13 or older because it takes some work to make a complete kickstart LTSP chroot from a new release. Instead of  invoking “ltsp-build-client” blindly, you’ll need to do something like:

# ltsp-build-client --release 13

This isn’t a huuuuuuge deal, but in an ideal world I would prefer to use the same release for clients and servers. It’s just cleaner and makes maintaing everything a bit come congruent for me. It also has some troubleshooting benefits. Bah!

2. The Display Manager Situation

LDM, the LTSP5 display manager is both wonderful and woeful. There are some really nice things that LTSP5 can tout due to LDM, but it’s also a step backwards compared to GDM (yes, even the new all-gtk GDM with reduced XDMCP functionality) or KDM in many ways.

What LDM does so well is proper setup and teardown of LOCALDEV and sound via pulse. It’s actually pretty slick, especially in GNOME where it gives the users desktop drive icons for portable USB drives/keys. The automatic unmounting of the drive is actually pretty slick but initially it was highly counterintuitive to someone like me who expects to require ejection/unmounting of the drive before pulling it out.

What LDM does poorly is… well frankly a few things. First off, the feedback from password prompt is poor. It can’t tell WHY your password failed due to the way it interacts with SSH. It’s a hard problem to solve, apparently but it’s a terrible user experience. Second, when you type your password incorrectly, it pauses for some time, tells you it can’t connect to the server and X restarts to load LDM again. Again, bad user experience. It’s also not highly customizable. As an example, the login box will span multiple monitors by default so it’s split across the bezels of your sweet dual monitor thin client. While you can “hack” it by providing a wide logo to force the login box off to the right, it’s not exactly super slick that way.

The last thing LDM doesn’t seem to do at all is allow for AIGLX/DRI2. If I login using LDM, glxinfo/glxgears barfs on a BadRequest related to DRI2/DRI2Connect. With an XDMCP connection to GDM on the same server, with the same client chroot, lts.conf and xorg configuration and glxinfo displays software rendering but that’s a different story. Even using a X11 forwarding to another server provides yet more different results. Either way, it appears LDM basically breaks functionality where it would otherwise run, but run fairly slowly. Could be the open source “radeon” driver I’m using on the test box, I suppose. I hear the intel driver works well…

Since the LOCALDEV and sound routing stuff is tightly integrated to LDM, it appears to be some work to get it working through GDM or KDM… then there is the problem that I haven’t had any success making the new GDM (~ >=2.30, I think) to act as an XDMCP chooser. I do have other XDMCP hosts that I want to connect to…

There is some hope to be had from this interesting post on the Ubuntu help/documentation wiki. It details how to install GDM on the LTSP chroot and get LOCALDEV working with it. They claim sound just works on that older version of Ubuntu but I don’t recall my sound device showing up when using XDMCP and remote GDM. Either way, LOCALDEV is more important.

Windows Terminal Server: Windows 7 Enterprise

I can’t start without saying that Windows 7 via RDP feels “slower” than Windows 2003 over RDP. I detect more mouse and menu lag from the same client systems and versions. I disabled aero and it helped but only a very little bit. I’m not ready to give up yet, there may be more things I can do here.

As mentioned, I’m trying the termsrv.dll hack that allows for multiple RDP users to non-Windows Server Terminal Services hosts. I wonder if it’s part of the performance issue I’m seeing… I should quickly revert the hack to test that possibility.

On the terminal server and with dual 4:3 monitors, not much of the GUI pizzaz in Windows 7 is all that interesting or useful. Some UI changes compared to XP make things a tad unfamiliar for me but overall it’s the same experience with a few nice things and seemingly better stability and driver support.

Related posts:

1. LTSP 5 and AIGLX
2. A Correction
3. Fresh Win2k Install and Windows Update Error

I’m well aware of the FreeIPA project and that project does in fact support UPG, probably because it’s a RedHat project but I’ve determined that FreeIPA is too comprehensive for my needs. Despite Kerberos being the “right” solution in every sense of the term, I’d rather have the simplicity of binding to the LDAP server for authentication, even though I know that using LDAP as an authentication service is “wrong”.

My question, loyalty challenged readers, is: Are there any LDAP user management tools out there that support UPG?

Let me start the list:

• LAM – NO
• phpLDAPadmin – NO
• Luma – NO
• LAT – NO
• Gosa – NO
• smbldap-tools – Maybe?

Not to bash any of those tools, but I’ve decided to start writing my own simple “useradd” script for now because the workflow for creating a user with the UPG scheme with any of these tools is an annoying multi-step process. While my solution is site-specific and non-comprehensive, it just exactly the job I need done, done. And fast. I used perl and Net::LDAP, among other modules. Once I figured out if I want to it keep it on the console or move it to the web, I’ll post the results… even if it won’t be useful to anyone as-is.

Related posts:

1. Which Distro for PPC64 Server?
2. FreeIPA and Samba 3 Integration
3. Migration Weekend: Success

The example is that of a very, very basic sudoers policy but the principles are easily extended to create much more complex policy. The general idea here is that we want cfengine to ensure that specific rules are always in place. Instructed properly, cfengine accomplishes this very well.

Warning: I don’t know anything. I’m just someone learning cfengine 3 and posting about it. If I’m wrong about something, let me know! If you find this at all useful, be my guest. That is all.

################################################################################
##
## FILE: sudo.cf
## DESC: Control /etc/sudoers file on various servers
##
################################################################################

bundle agent sudo
{

vars:

  "sudoers" string => "/etc/sudoers";

  "sudo"     slist => {
                      "%admin ALL = ALL",
                      "%sysadmin ALL = /sbin/mount",
                      "%devel ALL = /sbin/mount"
                      };

packages:

  Night::

  "sudo" -> "Security policy"
    comment               => "Ensure sudo is up to date every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "$(sys.arch)" },
    action                => if_elapsed("1440");

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

}

As with last snippet I posted, the above does not even resemble a complete cfengine policy/configuration, just a small portion that can be contained in it’s own bundle. It can be put in a separate .cf file, imported by promises.cf and added to the bundle sequence, inheriting variables and classes! Also, just like last time I’m using cfengine’s built in interface for package management systems to ensure “sudo” is always installed via yum at night, every 24 hours.

What’s new here is file editing with edit_line and the use of iteration which proves to be very powerful in cfengine 3.

Editing Files

Editing files with cfengine is supposed to be easy but initially it seemed a bit awkward to me.

First you have the promise file promise:

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

Which makes some reference to the edit_line facility and what looks like a function name with append_if_no_lines(…).

Then you have the edit_line bundle defined elsewhere:

bundle edit_line append_if_no_lines(list)
{
insert_lines:

 "$(list)";
}

Which describes what “append_if_no_lines” actually does.

Of course I’m just learning cfengine and new things can often seem strange and scary but I am finally warming up to editing files with cfengine… I think. What I seemed to have initial trouble with was with the bundles necessary for edit_lines, as described above. The bundle within a bundle concept. The append_if_no_lines and append_if_no_line bundles I’m using are implemented in the cfengine std library, which is highly recommended so that you may avoid re-inventing the wheel a little bit.

For basic promises, to add or remove, comment or uncomments lines and the such there are good edit_lines bundles available in the stdlib. For other more complex or customized file editing, writing your own bundles will be necessary. Either way, understanding what a bundle is and how to create your own is key to fully grasping file editing and getting the most out of it. This seems obvious in retrospect but something I didn’t pickup instantly.

See the cfengine documentation for more about editing files, check the cfengine documentation. There’s waaaaay more good information over there and it’s from the cfengine team, not some random newb.

Iteration

Iteration is powerful mechanism within cfengine that harnesses the power of lists to express a large possible number of actions/operations with very little amount of code. When lists are used, single actions can be made to repeat for every item in a list by using the $(varname) syntax to refer to the list… which as it turns out is the same for scalar values! Funny that!

So cfengine allows us to define X different lines of code to ensure are in a file using only a single file: promise all with the same simple syntax as scalar variables? Brilliant!

A demonstration of iteration can be seen with the $(sudo) slist and the “Append common configuration to sudoers” file: promise. With this single promise definition, up to 6 actual promises are made because the $(sudo) variable is an slist. Each element or item in the list is iterated over in sequence and the promise is evaluated and acted upon, if necessary. The reason that up to 6 promises will be evaluated is the ifvarclass property of promise, ensuring the promise will only be kept if we’re in the context of the class… and looking at the promise to find out which class, we see another example of iteration using the $(sudo) list and the canonify function that turns a string into a class. Thusly, if the host currently running this policy defines all the classes that are tested by the ifvarclass iteration, 6 promises will be made. If the host defines 3 of the classes, then 3 promises will be made and so on, and so forth.

As a beginner, using lists and iteration effectively and creatively seems fairly important to getting the most out of cfengine 3.

Editing Files vs. Copying Files

In my previous snippet, I demonstrated how to promise to copy a file from a secure remote server if the local file does not match the server’s file in order to manage a configuration with cfengine. This time, I’m promising to add lines to a configuration file if they do not already exist exactly as provided.

This represents two rather different takes on policy. The first says: “The configuration must always be exactly like this file, byte per byte!” the second says “These lines must exist but I don’t care about anything else in the file”. The file copy method is what I would call hard policy and the second is soft policy. In the cfengine community solutions, they recommend managing sudo by copying an /etc/sudoers from a remote server. That way is great (just like my DenyHosts example) but this is just another way if you have a use case for cfengine not owning every byte of your configuration file.

Conclusion

Yeah, that’s about it. Enjoy.

Related posts:

1. Cfengine 3 Snippets Part 1: DenyHosts
2. Nanorcs: Ultrasimplistic Configuration File Revision Control
3. RHEL/CentOS, NFS and Firewalls

I did discovery yet more small misconfigurations and strange behaviour along the way:

1. OpenLDAP’s syncrepl using “refereshAndPersist” wasn’t working how I expected it to, no new changes were replicating to the slave LDAP server! I changed the directive to “refreshOnly” and set a 10 minute interval. I made several changes and monitored the slave LDAP server. Changes propagated in about 10 minutes, every time.
2. Despite iSCSI’s maturity and the maturity of QLogic’s HBAs I still noticed strange, unexplained target drop outs. Two HBAs per server, two controllers in the IBM DS3300 and just one target out of four was dropping. At first, I couldn’t figure out how to properly reconnect the target on a live system so I rebooted. Later, I discovered you can “disable” and then “enable” the specific target in SANsurfer or iscli, which worked to bring back the dropped target on a live system. Multipath picked up the “new” path right away, as expected.
3. Always remember to leave free physical extents in any LVM Volume Group in which you are taking snapshots of the Logical Volumes. It’s freakin’ obvious but I forgot and when I went to do snapshot backups, the snapshots were failing. Now I’m growing some LUNs on the DS3300 so that my VGs have room for snapshots.

All in all, a good weekend that was mostly filled with success.

Related posts:

1. Migration Weekend
2. When using Syncrepl…
3. Atempo Time Navigator 4.2 Archive Media Selection Tunable

NOTE: IT Watchdogs has since released the SuperGoose II. Since I haven’t compared the two products, I can’t comment on any differences.

IT Watchdogs

I really don’t know a lot about these guys but they appear to be a fairly small company. Their name came up several times during my searches for environmental monitoring solutions. What I do know is that their support people get back to you fairly quickly and they aren’t demanding a product serial number before assisting you with your IT Watchdogs related product questions. Their support gives you the impression you’re speaking with people that understand the product very well.

They provide firmware upgrades on their website where you can download them and get instructions on the upgrade process. There is no service contract necessary to continue getting firmware updates, which is very nice considering one of the main points they seem to be competing on is price and thus you not only get good initial value for your dollar, you get long term value in the software improvements over the lifetime of the device.

It’s a plane, it’s a bird, it’s a SuperGoose!

IT Watchdogs have a wide range of monitoring products but the SuperGoose (also known as the WxGoos-2) is (was) their flagship product. With a $499 price tag, it’s not dirt cheap but comparing it’s feature list to much of the competition out there and it really does start to look like a bargain.

The unit itself is a tiny litte 1U rackmount box that is no deeper than it is tall. That is, it’s about 1U deep. The unit has an LCD on the front that will cycle through readings from your various attached sensors that provide visual stimulus for those lonely nights in the server room. The unit also has a audible alarm which is of no use to me, but we’ll come to that later.

The build quality of the SuperGoose is good. It’s made out of metal, which is always nice. Everything is solid and well manufactured. There is just one design feature of the SuperGoose that I just don’t get: It requires an external power adapter (included), the kind you use to charge your cellphone or to power your crappy D-Link hub you’ve got installed in your office that the IT guys keep ragging on you about. It really isn’t a big deal but I just don’t see why they couldn’t have integrated the power transformer (A/C to D/C) into the chassis of the device and allowed the common and standard IEC C13 plug for power. Such a solution would have been cleaner and more compliant with the existing power infrastructure in the average server room/data center. Not to mention that the current power adapter plugs into the front of the SuperGoose, another little design issue I don’t fully understand. Either way, this is a minor gripe but something worth noting regardless as you’ll need to have a suitable PDU or extension cable to power the thing.

The SuperGoose allows for two kinds of external sensors to be added in addition to the full set of built-in sensors. The first kind of sensor is connected via RJ-12 jacks. The sensors supported in the RJ-12 jacks are digital sensors which means there is some kind of tiny microchip in the sensor itself. It’s not “passive”, if you will. While only five physical RJ-12 ports are included, the SuperGoose supports up to 16 sensors by using an RJ-12 splitter. The second kind of sensor is analog. In our case, we’re only using digital sensors so I cannot comment on the analog sensor functionality at this point, unfortunately.

Setting up the SuperGoose

Setup is really quite easy:

1. Mount the SuperGoose in your rack (and cable it up).
2. Grab the MAC address from the front of the device and setup a DHCP address for it (or just leave the default IP and setup a host on that subnet to initially configure it).
3. Power it up.
4. Point your browser to the SuperGoose’s IP address and begin configuring!

Of course, you can add many sensors as well at this point, which is key to a general purpose environmental monitoring solution.

The SuperGoose has a robust web server where you can view the collected data and graphs and configure various things such as networking, NTP, email, SNMP, camera setting and the device information. You can also configure alarm thresholds for your sensors so that you can get an email or SNMP trap fired off in case of abnormal readings. While useful for smaller shops lacking a centralized monitoring solution, these built-in alerts are not a factor when integrating the SuperGoose into a larger environments where a centralized monitoring solution has been implemented. It’s nice to have them, but you might not need them.

The configuration page is clear and straight forward. The language used to describe configuration options should be totally familiar to anyone with cursory knowledge of the various technologies, standards and protocols in use. The SuperGoose provides three level of access to the device: View-only, Control and Administrative. Each access level has a configurable account name and password. The SuperGoose unfortunately does not support multiple accounts of the same level. That said, enterprise use of the SuperGoose will often involve SNMP data collection instead of users and admins logging into the SuperGoose web server directly and so, more fine grained per-user/admin accounts can be configured in the SNMP monitoring solution to control access to data while at the same time locking out access to the SuperGoose directly to all but the SNMP/env administrators in order to achieve “lock down” and logging on who can see/do what.

Digital Sensors & SNMP Monitoring

Digital sensors have unique IDs to which names can be assigned within the configuration interface. This means that when you connect/disconnect your digital sensors, or the SuperGoose reboots, the graphs produced by the SuperGoose and the data it has collected remain valid and consistent.

One snag I did run into momentarily is that although the SuperGoose will internally track the digital sensors correctly, the SNMP OIDs for each sensor were not consistent upon reboot of the SuperGoose! My SNMP monitoring station would collect false data when the SuperGoose was rebooted because the sensors were detected in a different order and thus the OIDs for each sensor changed! The reason this happened is because I was monitoring the OIDs in static fashion by associating a sensor definition in the monitoring software with a particular, static OID. When the OID for the any sensor changed (as it often does upon reboot), the monitoring station would be collecting information for a particular item in the monitoring database from the wrong physical sensor. The solution is to use SNMP monitoring software that supports using dynamic SNMP indexes. Zabbix is such an open source monitoring solution. It took me a little while to configure Zabbix correctly for dynamics SNMP indexes but it was worth it: no more collecting data from the wrong sensor and thus more consistent and correct long term trending data is collected.

For what it’s worth the following is an example of the “OID” string I use within a Zabbix “item” to implement the dynamic index feature:

IT-WATCHDOGS-MIB::tempSensorTempC[index,IT-WATCHDOGS-MIB::tempSensorName,Ambient Front]

Where “Ambient Front” is the name of the sensor, as set in the SuperGoose configuration.

Well Folks, that’s Part 1

Well, that’s part 1 of the review. Part 2 of the review will arrive sometime in the future… I’ve just been sitting on this much of the review for too long now and it needs to be posted. I hope everyone enjoys half reviews (for now)!

Related posts:

1. IBM Changed UPS Vendors
2. OpenGear CM4116 Review

The Problem

The initial difficulty lies in the requirement that the data must be consistently backed up at every interval, no matter which cluster node is currently the active node with the backend storage mounted. To do this, an agent is required to be configured as a cluster resource in order to “follow” the mounting/exporting of the storage to any cluster node. So in order to accomplish this,  N + 1 tina agents are required. That is, if you have two cluster nodes, you need three agents to successfully backup each node with the local agent and the storage, as it floats about the cluster nodes depending on failure or migration events.

Luckily for me, the good people at Atempo have engineered the agent in such a way that multiple agents can be ran on a single node, each binding to it’s own IP address and each individually controlled via it’s own init script. Of course, we need to make some file edits to make all this happen and that’s what I’m going share!

System Configuration

This configuration is based on CentOS 5.x and Time Navigator 4.2 but should the concepts should be mostly portable to other popular Linux or UNIX distributions. The underlying cluster software used for the majority of my experience with this configuration is Heartbeat 2.1.3, right before the Pacemaker split but has also been more recently tested on Pacemaker 1.0 / Heartbeat 3.0.x. DRBD is used to provide the active/passive cluster-aware state and configuration information to where I’ve installed the Atempo Time Navigator agent but it is possible to install a second agent on each cluster node and configure it identically but this just seems like more work. DRBD does a great job of making sure the latest cluster-aware tina agent is consistently configured and available on the active cluster node, no matter which node that actually is.

For the purpose of this post, I’m going to assume you already have a working Heartbeat/Pacemaker/DRBD configuration up and running with proper STONITH and all that good jazz. Maybe some other time.

Installing and Configuring the Agent on DRBD

The first thing that needs to be done is the tina agent must be installed to a filesystem hosted on DRBD. I generally just SSH around the Linux-X64.tar or Linux-X86.tar Time Navigator installation archive and then decompress and run the install script.

Assuming the dedicated (to this agent resource) DRBD filesystem is mounted as /cluster/tina on the active cluster node:

$ cd /cluster/tina
$ scp user@remote.fqdn:/path/to/Linux-X86.tar ./
$ tar -xf Linux-X86.tar
$ cd Linux-X86
$ ./install.sh

This will bring up the GUI installer. Alternatively use the batch install method, whatever works for you.

Set /cluster/tina as the installation directory and otherwise proceed normally as per site configuration. Unique ports do not need to be used for the second cluster agent as this configuration bind to a floating cluster resource IP address while the local agent binds to (one of) the servers “real” IP address(es).

Once installed, there is one important edit to make in the tina agent environment configuration scripts named .tina.sh (sh/bash) and .tina.csh (csh/tcsh) located in the installation directory (/cluster/tina). The key change to make in the relevant script is to modify the value where the $TINA environment variable is being set. In .tina.sh that would be changing the line:

TINA=tina

to instead read something like this:

TINA=tina_ha

where tina_ha is a unique identifier for this instance of the agent. Basically, it needs to be anything BUT tina. This is one of two key components that had me tricked for a while. I had first tried modifying the $TINA_SERVICE_NAME environment variable but that was a giant red herring because uniquely setting that variable to something other than tina does not produce the desired effect, despite what the looking through the tina environment scripts and init scripts might have you believe.

The second thing we must do is to create an LSB-compliant init script for the cluster-aware tina agent. The LSB compliance is very important to ensure the cluster can manage the resource properly. If any return codes are out of the LSB spec, the cluster will behave erratically and unpredictably when dealing with starting, stopping and monitoring the tina agent.

Since the installation creates a good init script for us, we can copy that script with a new name and edit it.

$ cp /etc/init.d/tina.tina /etc/init.d/tina.tina_ha
$ nano /etc/init.d/tina.tina_ha

First, replace every instance of the path to the local agent’s tina install path with that of the cluster agent’s installation path. A simple search (Ctrl-W) then replace (Cntrl-R) in nano should suffice.

Additionally, we need a small section at the top that will exit the script in case the DRBD filesystem is not mounted. The HA cluster will do resource status checks on all nodes in the cluster and we need the init script to be able to exit with a sane exit code, even if the DRBD filesystem is not accessible (as it is on all passive nodes). Something like this:

if [ -f /cluster/tina/.tina.sh ] ; then
  . /cluster/tina/.tina.sh > /dev/null 2>&1
else
  echo "Unable to start Time Navigator daemon"
  echo "because the \"/cluster/tina/.tina.sh\" file does not exist"
  retval=3
fi

In order to make the script LSB compliant, we need to ensure the correct exit status is returned during the correct operations. Instead of pointing out each specific place I had to edit in order for this to happen, I will simply post my entire “/etc/init.d/tina.tina_ha” init script:

#!/bin/sh
# UPDATED BY SETUP - BEGIN
########################################################
#WARNING :
#THIS FILE IS GENERATED AUTOMATICALLY
#AND WILL BE OVERWRITTEN WHEN UPGRADING
#YOUR VERSION OF Time Navigator PRODUCT
########################################################
PATH="$PATH:/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc"
export PATH
if [ "${TINA_HOME:+$TINA_HOME}" != "" ] ; then
	if [ "/cluster/tina" != "$TINA_HOME" ] ; then
		echo "Unable to start Time Navigator daemon for \"/cluster/tina\""
		echo "because the Time Navigator environment is already set by \"$TINA_HOME\""
		retval=3
	fi
fi
if [ -f /cluster/tina/.tina.sh ] ; then
	. /cluster/tina/.tina.sh > /dev/null 2>&1
else
	echo "Unable to start Time Navigator daemon"
	echo "because the \"/cluster/tina/.tina.sh\" file does not exist"
	retval=3
fi
# UPDATED BY SETUP - END
# @(#) $Id: rc.tina.orig,v 1.1.6.10.4.4.2.4 2007/09/20 16:26:50 dle Exp $
#
# Time Navigator startup script
# (C) 1999-2005 - Atempo
# tina_daemon starting...
#

OS_TYPE=`uname -s`

if echo "\c" | grep "c">/dev/null ; then
	ECHOMODE=Bsd
else
	ECHOMODE=Sys5
fi

ECHONOCR() {
	if [ "$ECHOMODE" = Bsd ] ; then
		echo -n "$*"
	else
		echo "$*\c"
	fi
}

PING() {
    os_type=`uname -s`
    case $os_type in
        HP-UX) result=`ping $1 -n 2 2>/dev/null`; return $?;;
        *) result=`ping -c 2 $1 2>/dev/null`; return $?;;
    esac
}

ISREDHATLIKE=1
# Source function library.
if [ -f /etc/init.d/functions ] ; then
	. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
	. /etc/rc.d/init.d/functions
else
	ISREDHATLIKE=0
fi

ISSUSE=1
if [ -f /etc/rc.status ] ; then
	. /etc/rc.status
else
	ISSUSE=0
fi

RCStart()
{
	if [ -x ${TINA_HOME}/Bin/ndmpd ] ; then
		echo "Starting NDMP Data Server..."
		${TINA_HOME}/Bin/ndmpd
	elif [ -x ${TINA_HOME}/Bin/tina_nts ] ; then
		echo "Starting NDMP Tape Server..."
		${TINA_HOME}/Bin/tina_nts
	fi

	TINA_DAEMON=$TINA_HOME/Bin/tina_daemon
	if [ -x "$TINA_DAEMON" ]; then
		ECHONOCR "Starting Time Navigator ($TINA_SERVICE_NAME)..."
		if [ -d /var/lock/subsys ] ; then
			touch /var/lock/subsys/tina.$TINA_SERVICE_NAME
		fi
		i=1
		while [ $i -le 60 ] ; do
			if [ $OS_TYPE = "Darwin" ] ; then
				echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon" >> /var/log/system.log
			fi
			echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon $i" >> ${TINA_HOME}/Adm/auto_start.log
			hostname=`hostname 2>/dev/null`
			if [ ! -z "$hostname" ] ; then
				echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon: hostname $hostname is defined" >> ${TINA_HOME}/Adm/auto_start.log
				PING $hostname
				status=$?
				if [ $status -eq 0 ] ; then
					echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon: ping $hostname is ok" >> ${TINA_HOME}/Adm/auto_start.log
					$TINA_DAEMON
					sleep 2
					RCStatus no_mess
					if [ ! -z "$is_running" ] ; then
						if [ $OS_TYPE = "Darwin" ] ; then
							echo `date` "tina_daemon ($TINA_SERVICE_NAME) daemon is started" >> /var/log/system.log
						fi
						echo `date` "tina_daemon ($TINA_SERVICE_NAME) daemon is started" >> ${TINA_HOME}/Adm/auto_start.log
						break
					else
						echo `date` "tina_daemon ($TINA_SERVICE_NAME) daemon is not started" >> ${TINA_HOME}/Adm/auto_start.log
					fi
				else
					echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon: ping $hostname is ko" >> ${TINA_HOME}/Adm/auto_start.log
				fi
			else
				echo `date` "Trying to start tina_daemon ($TINA_SERVICE_NAME) daemon: hostname is not defined" >> ${TINA_HOME}/Adm/auto_start.log
			fi
			sleep 5
			i=`expr $i + 1`
		done

		if [ $ISREDHATLIKE -eq 1 ]; then
			echo_success
			echo
		elif [ $ISSUSE -eq 1 ]; then
			rc_status -v
		else
			echo
		fi

		# Start ACSLS daemons (mini_el and ssi)
		if [ -d "$TINA_HOME/Vtl" ] ; then
			for VL_path in $TINA_HOME/Vtl/*
			do
				[ ! -d $VL_path ] && continue
				VL_name=`basename $VL_path`
				if [ $VL_name = "Install" -o $VL_name = "Bin" -o $VL_name = "Log" -o $VL_name = "Tmp" ] ; then
					continue
				fi

				# If there is no tina_stk.conf, give up
				[ ! -f "$VL_path/tina_stk.conf" ] && continue

				[ ! -x "$TINA_HOME/Vtl/Bin/ACSLS/start.sh" ] && continue

				ECHONOCR "Starting ACSLS client daemon for $VL_name virtual library ..."
				$TINA_HOME/Vtl/Bin/ACSLS/start.sh $VL_name
				echo
			done
		fi
	elif [ ! -f ${TINA_HOME}/.ndmp.sh ] ; then
		if [ $ISREDHATLIKE -eq 1 ]; then
			ECHONOCR "Starting Time Navigator (${TINA_SERVICE_NAME})..."
			echo_failure
			echo
		elif [ $ISSUSE -eq 1 ]; then
			rc_failed 1
		else
			echo
		fi
	fi
}

RCStop()
{
	#Stop ndmp daemon
	NDMPDAEMON=""
	if [ -x ${TINA_HOME}/Bin/ndmpd ] ; then
		NDMPDAEMON="ndmpd"
	elif [ -x ${TINA_HOME}/Bin/tina_nts ] ; then
		NDMPDAEMON="tina_nts"
	fi
	if [ ! -z "$NDMPDAEMON" ] ; then
		file="/var/tmp/$NDMPDAEMON.pid"
		if [ -f $file ] ; then
			if [ "$NDMPDAEMON" = ndmpd ] ; then
				echo "Shutting down NDMP Data Server..."
			elif [ "$NDMPDAEMON" = tina_nts ] ; then
				echo "Shutting down NDMP Tape Server..."
			fi
			kill `cat $file`
		fi
	fi

	#Stop Time Navigator daemon
	if [ -x ${TINA_HOME}/Bin/tina_stop ]; then
		if [ -d /var/lock/subsys ] ; then
			rm -f /var/lock/subsys/tina.$TINA_SERVICE_NAME
		fi
		ECHONOCR "Shutting down Time Navigator ($TINA_SERVICE_NAME)..."
		if [ $OS_TYPE = "Darwin" ] ; then
			echo `date` "Stopping tina_daemon ($TINA_SERVICE_NAME) daemon" >> /var/log/system.log
		fi
		echo `date` "Stopping tina_daemon ($TINA_SERVICE_NAME) daemon" >> ${TINA_HOME}/Adm/auto_start.log
		$TINA_HOME/Bin/tina_stop > /dev/null
		retval=0
		if [ $ISREDHATLIKE -eq 1 ]; then
			echo_success
			echo
		elif [ $ISSUSE -eq 1 ]; then
			rc_status -v
		else
			echo
		fi
	elif [ ! -f ${TINA_HOME}/.ndmp.sh ] ; then
		if [ $ISREDHATLIKE -eq 1 ]; then
			echo "Shutting down Time Navigator ($TINA_SERVICE_NAME)..."
			echo_failure
			echo
		elif [ $ISSUSE -eq 1 ]; then
			rc_failed 1
		else
			echo
		fi
	fi
}

RCStatus()
{
	## Check status with checkproc(8), if process is running
	## checkproc will return with exit status 0.

	# Status has a slightly different for the status command:
	# 0 - service running
	# 1 - service dead, but /var/run/ pid file exists
	# 2 - service dead, but /var/lock/ lock file exists
	# 3 - service not running

	if [ -f $TINA_HOME/Conf/hosts ] ; then
		host_to_ping=`cat $TINA_HOME/Conf/hosts | grep ^localhostname | awk '{print $2}' 2>/dev/null`
		if [ $? != 0 -o -z "$host_to_ping" ] ; then
			host_to_ping="127.0.0.1"
		fi
	else
		host_to_ping="127.0.0.1"
	fi

	is_running=`$TINA_HOME/Bin/tina_ping -host $host_to_ping -language English | grep "is running"`
	if [ $# -eq 0 ] ; then
		ECHONOCR "Checking for Time Navigator ($TINA_SERVICE_NAME): "
		if [ $OS_TYPE = "Darwin" ] ; then
			echo `date` "Checking tina_daemon ($TINA_SERVICE_NAME) daemon" >> /var/log/system.log
		fi
		echo `date` "Checking tina_daemon ($TINA_SERVICE_NAME) daemon" >> ${TINA_HOME}/Adm/auto_start.log
		if [ ! -z "$is_running" ] ; then
			echo "tina_daemon is running"
			echo `date` "Checking tina_daemon ($TINA_SERVICE_NAME) daemon: tina_daemon is running" >> ${TINA_HOME}/Adm/auto_start.log
			retval=0
		else
			echo "tina_daemon is stopped"
			echo `date` "Checking tina_daemon ($TINA_SERVICE_NAME) daemon: tina_daemon is stopped" >> ${TINA_HOME}/Adm/auto_start.log
                        retval=3
		fi
	fi
}

test "$ISSUSE" -eq 1 && rc_reset

case "$1" in
start)
	RCStart
	retval=0
	;;

stop)
	RCStop
	retval=0
	;;

start_msg)
	echo "Starting Time Navigator ($TINA_SERVICE_NAME)" ;;

stop_msg)
	echo "Shutting down Time Navigator ($TINA_SERVICE_NAME)" ;;

restart)
	RCStop
	sleep 3
	RCStart ;;

status)
	RCStatus ;;

*)
	echo "usage: /etc/init.d/tina {start|stop|restart|status}" ;;
esac

exit $retval

One final Time Navigator configuration change must be made. The tina agent “hosts” file must be configured to set the “localhostname” of our agent to the FQDN of the floating or virtual IP address service so that the agent will only try to bind to that IP address instead of all IP addresses on the system.

$ cd /cluster/tina/Conf
$ cp hosts.sample hosts
$ nano hosts

Add a line to the file specifying the “localhostname” like so:

localhostname myserver.company.com

For this to work properly, you must also set any other tina agents running on the cluster nodes to also have a “localhostname” set in their respective “hosts” file to prevent other host-based agents from binding to all IP addresses on the host, including the virtual IP address.

That’s it! The tina service can be added to the HA cluster as an LSB resource agent, grouped with your storage resource agents so it will always be running on the same node as your storage.

Conclusion

Ok, so I rushed the end. Big deal. Sue me. I doubt anyone cares anyways!

Related posts:

1. Atempo Time Navigator 4.2 Archive Media Selection Tunable
2. Nanorcs: Ultrasimplistic Configuration File Revision Control
3. Migration Weekend: Success

As part of my learning experience with cfengine, I’ve decided to start posting some of the code that I’ve begun developing in the hopes that by writing about it, I can learn better, faster and maybe even receive some helpful comments from readers along the way. Beware, I’m a cfengine newbie and so what I post here should NOT be copy and pasted into your environment unless you’re ok with the potential of wildly breaking things!

The first snippet of code I want to discuss is related to managing our DenyHosts configuration. As part of our “security policy”, I would like to ensure that every RedHat/CentOS system is running a properly configured DenyHosts instance. Here is what I’ve come up with so far.

################################################################################
#
# FILE: denyhosts.cf
# DESC: Install, update, configure and ensure DenyHosts is running
# DATE: May 2010
#
#################################################################################

bundle agent denyhosts
{

packages:

  "denyhosts" -> "Security policy"
    comment               => "Ensure denyhosts is installed once a week",
    package_policy        => "add",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("10080");

  Night::

  "denyhosts" -> "Security policy"
    comment               => "Check for update to denyhosts every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("1440");

files:

  "/etc/denyhosts.conf" -> "Security policy"
    comment   => "Standard base DenyHosts configuration",
    copy_from => mycopy("$(g.confdir)/denyhosts/denyhosts.conf", "$(g.cfserver)"),
    classes   => cdefine("denyhosts_restart", "denyhosts_conf_copy_failed"),
    perms     => mo("400", "root"),
    action    => if_elapsed("1440");

processes:

  "python /usr/bin/denyhosts.py" -> "Security policy"
    comment       => "Define denyhosts_restart class if denyhost is NOT running",
    restart_class => canonify("denyhosts_restart");

commands:

  "/sbin/service denyhosts restart" -> "Security policy"
     comment    => "Restarting DenyHosts after configuration change or death",
     ifvarclass => canonify("denyhosts_restart");

}

If you’re familiar with cfengine at all, you’ll quickly realize this is not a complete configuration. I am relying on the cfengine standard library for several body definitions as well as custom site variables defined in the common bundle named “g” (not shown). And of course, there are no control bodies, bundlesequence or many other things that make up a complete cfengine configuration, hence “snippet”.

Let’s ignore what’s lacking for now and focus on the meat of the promises.

Packages

The first part of the denyhosts bundle is dealing with packages. I’m making two promises regarding the “denyhosts” package. The first promise is that the package has been added to the system via yum and the second is that the package is up to date via yum. I’m not entirely clear on how to best manage promises like this yet so perhaps I’m missing some cute shorthand for both adding and keeping packages up to date. For now, I’ll stick with two separate promises.

You’ll also notice that I’m only checking to see if the package is installed once a week (via action => if_elapsed) and only checking to see if the package is up to date once every 24 hours (if_elapsed, again). The update promise is also subject to the Night class to ensure that package updates only occur at night and not during the work day. This is just a matter of preference. I’d prefer if updates occur at night, you may not.

Since I’m using a “smart” package manager to ensure that denyhosts is installed, I can count on having yum resolve any dependencies (such as python) for me automatically. I would loath to describe every dependency for every package I want control over by hand.

Files

There is only one file that I’m concerned with when it comes to denyhosts and that is the denyhosts configuration file in /etc/denyhosts.conf. Instead of doing file edits on the default denyhosts.conf file provided in the denyhosts packages that I’ve promised to install, I simply copy a pre-defined configuration from my cfengine server. This file has our site’s default denyhosts configuration all ready to go. If I needed to customize the configuration on a per-host or per-host-type basis, I could copy the base file to a temporary location then perform edits on the temp file and write out the changes to the final location of the default configuration file or simply maintain several pre-configured versions of denyhosts.conf and copy the appropriate file.

Also of note about files is that if the file promise must be repaired (if the file must be copied because it’s changed), I’m setting a class to be defined so that DenyHosts can be restarted. More on that later.

Processes

In this case, I’m only checking to see if the DenyHosts python process is running or not. If DenyHosts is running, we do nothing. If DenyHosts is not running, we define a class using the same name as the class we define if we have to copy the configuration file.

Commands

Finally, in the commands section we tell cfengine how and when to restart DenyHosts. If the “denyhosts_restart” class is defined, we instruct cfengine to restart DenyHosts with the “/sbin/service denyhosts restart” command. The canonify and cdefine special functions in cfengine provide a very powerful way of defining some rather complex relationships.

What is Missing?

Well, probably a lot of stuff. One obvious thing is that I’m not promising that DenyHosts is set to startup at boot time using the hosts’ native init system. Of course, this shouldn’t be a big deal because cfengine will start it up if it’s not running at the next cf-agent run, but perhaps it would be nice to make that promise anyways.

I’m also not using many (or any!) classes to limit the scope of where (to what hosts) these promises will apply. Right now, I’m just working with a test environment so it’s easy to get away with that but I’m learning that it’s good to be as explicit at possible from the start when building promises.

UPDATE: Ah, how could I forget.. Reporting is totally missing! I knew I was setting some of those classes for a reason. In the next installment, I’ll include the most basic of reporting functionality.

I think that’s all for now. Please critique my amateur use of cfengine 3 in the comments, I want to hear from you!

Related posts:

1. Cfengine 3 Snippets Part 2: sudo
2. RHEL/CentOS, NFS and Firewalls
3. Nanorcs: Ultrasimplistic Configuration File Revision Control