Following on from Adrien’s wonderful post on syntax checking and writing tests, you have a way of checking the syntax and style guide from the command line. Using this approach, even on a mature (like a fine wine) Puppet code base, you can move towards having beautiful, aligned, ordered manifests—the type of manifests you’d be happy taking home to meet the family.

Puppet-lint takes the Puppet Labs Style Guide and places it nicely in a command line tool. Think of it as a programmatic PEP-8 for those from a Pythonic world. Now, where this comes in handy is when you’re using revision control (which is all the time, obviously!), because you can tie the two together. Yes, every time you try and commit your code to your RCS, it checks the files you’re committing, and makes sure you haven’t used a tab where there should be a space.

In Puppet Labs’ kickass Operations department, we’re ever so slightly keen on Git, not least due to the wonderful GitHub. RCSHub just doesn’t cut it for us these days.

With Git, as with many an RCS, you’re free to define hooks to do weird and wondrous things upon certain actions. This chapter on git hooks from Customizing Git explains them in detail. If you’re using Subversion, then this pre-commit documentation suggests what you can do on the server side to accomplish the same thing.

For this, the pre-commit hook is the one we want to utilise. I first make a bash script to get a list of the files that change in the commit. Then, the hook script goes through them one at a time, seeing if they’re Puppet manifests by name, and running puppet-lint on them as it goes. If any of the manifests fail linting, it exits there and then I may go fix them at my leisure!

#!/bin/bash
# Requires bash, as it uses the [[ ]] syntax.
#
# If it's puppet code, lint it up.
 
# I we don't have puppet-lint, so just exit and leave them be.
which puppet-lint >/dev/null 2>&1 || exit
 
# Variables goes hither
declare -a FILES
IFS="
"
FILES=$(git diff --cached --name-only --diff-filter=ACM )
 
for file in ${FILES[@]}
do
  if [[ $file =~ \.*.pp\$ ]]
  then
    puppet-lint --with-filename "$file"
    RC=$?
    if [ $RC -ne 0 ]
    then
      exit $RC
    fi
  fi
done
 
exit 0

I save that file to .git/hooks/pre-commit in my repository, give it a light sprinkling of ‘chmod +x’, a dash of ‘gem install puppet-lint’ and I am ready to roll.

Exhibit A, the Larch

So let’s see this bad-boy in use, I hear you cry! Let’s take a manifest that breaks all of the rules, and see what happens…

node 'hubert.humphrey.edu' {
 
	user{ "mhunter":
	   managehome => true,
	   home => "/home/mhunter",
	   comment => 'Mark Hunter',
	   ensure => 'present'
   }
 
}

[enlil:puppetlabs-modules]% git commit hubert.pp
hubert.pp - WARNING: double quoted string containing no variables on line 3
hubert.pp - WARNING: double quoted string containing no variables on line 5
hubert.pp - WARNING: => on line isn't properly aligned for resource on line 5
hubert.pp - WARNING: => on line isn't properly aligned for resource on line 6
hubert.pp - WARNING: => on line isn't properly aligned for resource on line 7
hubert.pp - ERROR: two-space soft tabs not used on line 4
hubert.pp - ERROR: two-space soft tabs not used on line 5
hubert.pp - ERROR: two-space soft tabs not used on line 6
hubert.pp - ERROR: two-space soft tabs not used on line 7
hubert.pp - ERROR: two-space soft tabs not used on line 8
hubert.pp - ERROR: trailing whitespace found on line 2
hubert.pp - WARNING: ensure found on line but it's not the first attribute on line 7

Woah, that’s a lot of errors. By default, puppet-lint will let warnings through, but stop dead on errors, and we got them all! I’ll tidy this manifest up…

node 'hubert.humphrey.edu' {
 
  user{ 'mhunter':
    ensure     => present,
    managehome => true,
    home       => '/home/mhunter',
    comment    => 'Mark Hunter',
  }
 
}

Much more readable, and now when I try and commit it, I get:

[enlil:puppetlabs-modules]% git commit hubert.pp
[master 6020331] Add in a new pupil to the school!
 1 file changed, 10 insertions(+)
 create mode 100644 hubert.pp

Clean, and the best part is I don’t have to alter my workflow, I can just carry on editing with Vim, commit my work as normal, and just be kindly reminded when a manifest has things that need tidying up.

Learn More

• Puppet Labs style guide
• puppet-lint
• Verifying Puppet: Checking Syntax and Writing Automated Tests
• Puppet-lint SubVersion commit hook by Jason Hancock

To use the module you need to download it from the Puppet Forge onto your Puppet master using the module tools:

# puppet module install puppetlabs-boundary

You can then use the module to install and manage the Boundary meters that monitor your network traffic and send the results to Boundary.  To create a new meter you will need your Boundary ID and API key and create a `boundary_meter` resource like so:

boundary_meter { "db.example.com":
  ensure => present,
  id => "abcde12345",
  apikey => "abcde12345",
  tags => [ "production", "newyork", "mysql", "appcluster1" ],
}

This resource will create a meter called “db.example.com” and add the tags production, newyork, mysql and appcluster1 (or the tags of your choice).  After you run Puppet you will be able to see your meter in the Boundary console.  We can also easily delete the meter by ensuring it is `absent`.

You can find the source code on GitHub and we welcome bug reports, ideas and features from the Puppet community. Thanks to Joe Williams, Jeff Hulten, W. Andrew Loe III, Alessandro Franceschi and Scott Smith for their contributions to the current module.

The major areas of advance are below:

• Complete messaging protocol rewrite to enable direct style connectivity that would allow programs to bypass normal discovery instead using their own data sources
• An additional more robust messaging paradigm supporting a more assured addressing and delivery scheme
• Batched mode allowing users to address machines in small groups thus avoiding thundering herd and enabling more granular changes
• A more complete language for expressing discovery that includes and/or/not style queries across the infrastructure
• Improved Stomp connection security using normal industry standard Certificate Authority validated TLS
• New connector that uses ActiveMQ-specific features for better performance and scalability
• Security of the SSL and AES security plugins have been improved for tamper protection by middle men
• A message validity period has been introduced to lower the window of message replay attacks
• Better error handling and better logging for Stomp connections
• JSON output from the ‘rpc’ application
• Ability to pipe RPC requests into each other creating a chain of related RPC calls
• Better validations, better error handling and better documentation creation from the DDL
• Performance improvements in the CLI, more consistently formatted output of received data
• A Ruby GEM of the client is now made available on rubygems.org
• The rc script for Debian based systems have been improved to prevent duplicate daemons from running
• Built in packager for plugins into native OS packages—RedHat and Debian supported
• MS Windows Support

The full release notes for this release expands on key areas of the above list and you can download this release from our download area, Yum repository or our Apt repository.

May 19 – Puppet Camp Los Angeles: Senior Developer Deepak Giridharagopal will introduce PuppetDB, and the Puppet projects team lead Daniel Pittman will share the Puppet roadmap for 2012.

May 21 – Find us at EMC world, we’ll be around and looking to find you. Follow us @puppetlabs to find out where we are.

We’ve announced new Puppet Camps for June and July:

• Southeast Asia in Kuala Lumpur on June 5th
• Sydney on June 8th (tickets are almost gone!)
• District of Columbia on June 19th
• Puppet Camp Boston on June 22
• Chicago on July 23rd

And don’t forget about our previously announced our European camps in Dublin, Ireland on July 6th and Geneva, Switzerland on July 11th.

After the end of July we’ll be working to produce an epic PuppetConf in San Francisco on September 27th and 28th. Register now to guarantee a seat. Like many of our Puppet Camps, PuppetConf is sure to sell out.

We’re also happy to offer you a 10% discount to Velocity on June 25-28. Just use code PUPPETLABS when you register and then come find us at booth #517 and check out presentations from James Turnbull and Luke Kanies at Velocity.



We’re looking forward to connecting with you this summer.

]]> http://puppetlabs.com/blog/upcoming-puppet-events-new-camps-puppetconf-and-velocity/feed/ 0 http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-2/ http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-2/#comments Mon, 07 May 2012 13:51:56 +0000 Kelsey Hightower http://puppetlabs.com/?p=13884 This week we’ll wrap up our coverage of the Puppet Module Tool (PMT) by exploring the install, upgrade, and uninstall commands. Lets jump right in.

PMT Install

The install command installs modules from the Forge using the full name of the module (author-module). We can install the “puppetlabs-apache” module like this:



Installing a specific version

We can also install a specific version of a module using the --version (-v) flag:



PMT now enforces SemVer when installing modules. If a module does not meet SemVer requirements it will fail to install.

Automatic dependencies resolution

One of the major enhancements to PMT is the ability to automatically resolve and install module dependencies. Once a manual process is now completely automated:



Notice that the install command grabs the requested module, puppetlabs-bacula, and its depenedencies: puppetlabs-mysql, puppetlabs-sqlite, and puppetlabs-stdlib.

PMT Upgrade

PMT also sports the ability to upgrade installed modules:



From the output we can see that we have upgraded the “puppetlabs-stdlib” module from version 2.2.1 to 2.3.1.

PMT Uninstall

Before this release of PMT, users had to manually remove modules from their module paths. While something like “rm -rf /etc/puppet/modules/stdlib” works, it’s not what we call user friendly. This version of the module tool greatly improves the experience around uninstalling modules.

Be sure to use the full module name when uninstalling modules or you’ll get the following error:



Notice the helpful error message suggesting that maybe you meant “puppetlabs-stdlib”, and in fact we did:



Look before you leap

The uninstall commands also checks for local changes and broken dependenices before uninstalling a module. Check out what happens if I try and uninstall the “puppetlabs-mysql” module:



PMT stops you with an error because uninstalling puppetlabs-mysql would leave the puppetlabs-bacula module with an unmet a dependency. You can by-pass this error by using the --force flag, but you can’t say we didn’t warn you!

Conclusion

PMT has been greatly enhanced to provide a much better experience when consuming modulew from the Puppet Forge. With the new list, search, install, upgrade, and uninstall commands managing modules couldn’t be easier.

Additional Resources

• Puppet Module Tool Part 1
• SemVer
• Previous Modules of the Week
• Puppet Forge – Module Repository
]]> http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-2/feed/ 3 http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-1/ http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-1/#comments Mon, 30 Apr 2012 20:12:50 +0000 Kelsey Hightower http://puppetlabs.com/?p=13761 This week we’re going to begin our coverage of the Puppet Module Tool (PMT). The PMT is the command-line interface to the Puppet Forge—an online repository for re-usable Puppet modules. As of Puppet 2.7.14 and Puppet Enterprise 2.5 PMT is no longer a separate product; it’s now part of Puppet Core. What this means for you is that PMT is ready-to-go out of the box.

New features

The latest version of PMT offers a few new features over the previous stand-alone tool:

• Search the Puppet Forge from the command line
• List, upgrade, and uninstall modules
• Automatically resolve and install module dependencies

In this post we’ll take a look at the new search and list commands.

PMT Search

The search command searches a repository for modules whose names, descriptions, or keywords match the provided search term. For example, if we search for the term “tomcat”, we would get the following output:



Notice the results include modules that match based on keywords and the module name.

PMT List

The list command lists the installed Puppet modules in our modulepath.



Notice the apache module has a version number of (???). This is because an apache module is installed but does not have a valid metadata file. If you would like to see how the installed modules relate to each other, use the --tree flag:



Highlighting problems

The list command will also report any issues with your module path:



The warning message is telling us that we are missing the puppetlabs-mysql module, which is required by the puppetlabs-bacula module. The PMT list command even lets us know which version of puppetlabs-mysql is required. A lot of work when into making the output communicate effectively. Notice the visual label used to highlight the “UNMET DEPENDENCY” in the tree output.

Conclusion

The new PMT is now bundled with Puppet and is ready to use out of the box. The new list and search commands allow you to search for modules on the Forge, and list currently installed modules. The list command also sports the ability to report issues with our installed modules.

Join us next week as we discover how to streamline the installation and maintenance of modules available on the Puppet Forge. We’ll wrap up our coverage of the PMT by taking look at the new upgrade and uninstall commands. We’ll also explore the enhancements made to the install command which greatly simplifies installing modules and their dependencies.

Additional Resources

• Module Metadata File
• Previous Modules of the Week
• Puppet Forge – Module Repository
]]> http://puppetlabs.com/blog/module-of-the-week-puppet-module-tool-part-1/feed/ 3 http://puppetlabs.com/blog/announcing-puppet-labs-cto-nigel-kersten/ http://puppetlabs.com/blog/announcing-puppet-labs-cto-nigel-kersten/#comments Thu, 26 Apr 2012 16:37:39 +0000 Nigel Kersten http://puppetlabs.com/?p=13695 This week I took on the role of CTO at Puppet Labs, and started reflecting on the awesome journey that led me here.



It was 2006, and I was scrambling to make it onto the last bus back to San Francisco from the Apple WWDC Beer Bash down in Cupertino. I’d been to quite a few Beer Bashes and knew the drill: forget the lineup for the campus store, just concentrate on finding beer and the few Apple employees who could fix the OpenDirectory bugs that were making my life hell. Both objectives were completed, leaving me only minutes to avoid having to spend way too much money getting a taxi back up to the city.

Fatefully, I found a seat next to this intensely opinionated sysadmin, Jeff McCune (later to become one of the first pro services guys at Puppet Labs, and now one of our core developers). He recognized me from my WWDC presentation that year and started grilling me about how I ran my university campus, particularly the file-based configuration management system I used, Radmind, and the hacked up framework I’d put in place to try to manage higher level objects than mere files.

He’d been to a talk by Luke Kanies (now the CEO of Puppet Labs) at LISA and was very excited about this guy who had built a tool that worked the way sysadmins actually needed to work with a pragmatic, model-based approach. Even more importantly though, Luke was serious about fostering adoption, and had helped Jeff write some useful extensions for Puppet. Jeff had already gotten religion about idempotent, declarative approaches for sysadmins, and spent pretty much all of the bus ride bending my ear about this new project called “Puppet” and how it was going to change the world of operations.



After WWDC, I flew back to Australia, fully intending to try out this magical Puppet project, but got distracted by the day to day life of running campus IT operations on a shoestring budget for users who were academics and artists.

I was even more distracted a few months later when one of the MacEnterprise community members came out of lurking and told me I should apply for a role at Google in Mountain View. Several of the toughest interviews of my life followed, and within a couple of months, I was moving my young family to the other side of the world to run Mac Operations at Google HQ.

It was clear that tools like Radmind simply weren’t going to work at Google for the many thousands of corporate Macs. Opinionated engineers who demanded a high degree of customization, immense growth, globally distributed offices and a very small team meant that it was completely insane to even think about trying the old methods of file-based config management of the entire system.

We needed a better and more sustainable way, a solution that gave us higher levels of abstraction with meaningful entities such as users, groups, services and packages, and that didn’t require you manage the entire machine.

Jeff and I had kept in contact, and he was presenting on Puppet at WWDC that year. I popped up to San Francisco with some of my coworkers, and made sure we turned up to his talk.

10 minutes into his presentation we were getting pretty excited, and we started experimenting over VPN. By the time Jeff finished his talk, we had a working Puppet master back at Google managing the contents and permissions of a few critical files in /etc, and knew we had a great match.

As it turned out, the Mac deployment was such a rapid success that one of the Linux Ops team started a skunkworks project to manage the internal Linux distro with Puppet, as there had been a few failed CFEngine attempts. This worked so well that Puppet eventually managed all the Google corporate Mac and Linux desktops, laptops and servers.

Puppet was a much younger project in those days. We were building a lot of custom Puppet extensions for Mac OS X that went back into the core, and were having to scale Puppet to manage tens of thousands of nodes, so I spent a lot of time on the mailing lists and IRC channels brainstorming with Luke and the community. I quickly fell in love with the community. It was full of thoughtful sysadmins, people who were frustrated with the unreliable state of operations tools, and knew there was a better way out there than continually reinventing arcane bash/ssh frameworks.

We have some great technology with Puppet, but one of our greatest strengths is our outstanding community.

I ended up at the first ever Puppet Camp, San Francisco, 2009. It was small, but was one of the most exhilarating conferences I’ve ever been to. I love looking back at those photos and seeing how many of that group are now part of the Puppet Labs team. Dan Bode, James Turnbull, Ben Hughes, Gary Larizza, Michael Stahnke, Carl Caum, Deepak Giridharagopal (Little known fact: his last name is actually Tamil for “Grid Computing”).





That’s an awesome group of people to end up working with, let alone all the other great people we have here at Puppet Labs.

I had an amazing couple of years at Google, surrounded by super sharp minds and working on truly interesting operations problems at a scale greater than anything I’d ever touched before, but I was starting to look enviously at friends who left for early stage startups and the breadth of knowledge they were acquiring. Luke had poked me a couple of times about coming to work for him, but I didn’t seriously consider it until late 2010 when he, Teyo and James made a much more concerted effort.

“You’re opinionated about Puppet. Want to put your money where your mouth is?”

One visit to Portland and I knew I wanted to live in this awesome food, beer, and cycling-obsessed city full of people following obscure passions. I jumped ship from Google and we moved north, where I dived headfirst into being responsible for Product at a very quickly growing startup.

It’s been an immense 18 months. We started with our first commercial release, Puppet Enterprise 1.0, and followed that up with several great releases, all solving real problems for real users. We’ve brought on the open source MCollective and Hiera projects from the incomparable RI Pienaar, released Puppet 2.7.0, and grown at an amazing pace. We’ve grown from 2 events a year to 15, including the incredibly successful PuppetConf `11 and are building up to an even bigger PuppetConf this year. Nothing like startup speed to quicken the blood.



From the original 20 odd folks I started with in the tiny office in the seedy and urine-drenched Old Town to our shiny digs in the Pearl, with over 80 employees. From a distinct lack of in-house beverages to decent espresso and delicious local beer. From a company that knew the user experience was critical, to one with a growing UX/Design department headed up by Randall of the impenetrable Gandalf gaze.



I love this company. I love what we’ve done already to change the face of operations, I love the ambition we have to change it even more, and I especially love the people I get to do it with.

I’m thrilled to take on the role of CTO, and to concentrate on fostering our culture of technical innovation so that we continue to build applications and platforms that truly advance the state of IT infrastructure. The world of operations is undergoing radical change right now. The cloud, pervasive virtualization, corporate adoption of FOSS, BYOD, IaaS, PaaS and SaaS are all forcing sysadmins to be truly agile and adaptive. Some of the brightest people in our industry work in operations, and it’s going to be incredible to see what they come up with when IT automation gives them space to concentrate on genuinely important matters.

]]> http://puppetlabs.com/blog/announcing-puppet-labs-cto-nigel-kersten/feed/ 13 http://puppetlabs.com/blog/module-of-the-week-jmcdonagh-clamav/ http://puppetlabs.com/blog/module-of-the-week-jmcdonagh-clamav/#comments Fri, 20 Apr 2012 18:05:10 +0000 Joe McDonagh http://puppetlabs.com/?p=13648 Purpose Comprehensive clamav and freshclam classes Module jmcdonagh/clamav Puppet Version 2.6+ Platforms Ubuntu 10.04 LTS+

ClamAV is an open-source scanning engine for malware, virus, and trojan detection. It is often used in conjunction with an MTA such as Postfix. It comes with a built-in service for AV signature updates called freshclam.

This module is intended to offer a comprehensive interface for Puppet to configure both freshclam and clamav services. Each class takes many parameters, all of which are down-cased versions of clamav or freshclam configuration options. Both the clamav and clamav::freshclam classes are also intended to be easily removed from a system, by setting their $ensure parameters to ‘absent’.

Installing the module

Complexity	Easy
Installation Time	5 minutes

This module is on Puppet Forge and can be installed with puppet’s module sub-command:

puppet module install jmcdonagh/clamav

Note that if you run this as a regular user, the module will be installed in your home directory. If you are root, it will probably go into /etc/puppet/modules.

Module and Resource Overview

First, you should either check out the code from GitHub (https://github.com/thesilentpenguin/puppet-clamav), or install the module with the module tool as outlined above and browse the code with your favorite editor. I recommend having the manifest open while I walk you through the code.

Let’s have a look at the clamav base class in manifests/init.pp. Scroll down to the beginning of the class and you will immediately notice that there are many parameters. These parameters were taken from the clamav man pages on Ubuntu 10.04 LTS systems, and down-cased to maintain status quo code style.

After all the parameters, we’ve got some sanity checks. We’ll fail the catalog compilation (using the fail() function) if we get passed any bizarre values or we’re trying to compile a catalog for an incompatible system. One of my stock checks is a minimum OS version. This is a pretty good practice for numerous reasons. For one, it helps consumers know where your code is intended to be used. That is absolutely crucial if you will be supporting this code. Before someone breaks a Solaris system using a Debian-only manifest, the compilation simply fails and outputs a clear error.

After the sanity checks, various variables are set based on the value of $ensure. This will alleviate the need to use selectors inside resource definitions, which can lead to hard-to-read and thus hard-to-understand code. Here is the code that I am referring to which sets all of these variables based on $ensure:

   if ($ensure == "present") {
  	$file_notify    = Service["clamav-daemon"]
  	$file_require   = Package["clamav-daemon"]
  	$svc_before	= undef
  	$svc_enable	= "true"
  	$svc_ensure	= "running"
  	$svc_require    = Package["clamav-daemon"]
   } else {
  	$file_notify    = undef
  	$file_require   = undef
  	$svc_before	= Package["clamav-daemon"]
  	$svc_enable	= "false"
  	$svc_ensure	= "stopped"
  	$svc_require    = undef
   }

You may have noticed that some of these variables appear to be relationship targets. This is because I always attempt to include the ability to remove all of a class’ resources properly. You’ll notice that, if removing the clamav class by setting $ensure to ‘absent’, the resource requirements go the opposite direction of the way they go with $ensure set to ‘present’. You might get away with using $ensure in this manner and not reversing relationships, but for me it’s not worth taking that chance, and I just do it right the first time.

Now onto the actual resources. The clamav and freshclam classes are what I call FPS classes. That is, File-Package-Service classes. What I mean by this is that there is a Package to install, configuration File(s) to set up, and a Service to manage. The Service and File(s) Require(s) the Package, and the File(s) Notify the Service. This paradigm is likely common to you if you have been using Puppet for some time now.

So first you’ll notice clam’s configuration file. This is a template that references all the class parameters to configure clamav. It uses some of the variables defined above to set up relationships and notify the service.

Next is the Package resources, which include a couple of extras. I include the dev packages because a lot of my work involves the rubygem ecosystem. This means that when I have a requirement for software on a system, I often need the -dev packages to compile extensions. Remember, now that you have parameterized classes at your disposal, it is trivial to add boolean features to your modules such as ‘$dev_packages = “true”’. That could serve as an option to include or not include the management of the -dev packages.

Finally we have the service. Not much here, mostly all configured via the variables defined based on $ensure. All our resources look nice and compact thanks to that variable setting stanza.

The clamav::freshclam class is also an FPS class. It is similar in the sense that it has every freshclam configuration option down-cased as a class parameter. The only noticeable difference between the two classes is the actual clamav and freshclam configuration options.

Testing the module

This module is most easily tested by using ‘include clamav’, which will by default set up clamav on the current system.

puppet apply -e ‘include clamav’ clamav/manifests/init.pp

If you do this on an incompatible system, you should see something like this:

Your OS (Darwin) is not supported by this code! at /etc/puppet/modules/clamav/manifests/init.pp:104 on node goldmember.microcosm.thesilentpenguin.com

After this successfully finishes on a compatible system, you should be able to see the clamav daemon running:

[~] > sudo service clamav-daemon status
 * clamd is running

You can test the config by scanning a test file by using the clamdscan program:

[~] > clamdscan website.erb
/home/jmcdonagh/website.erb: OK
 
----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.017 sec (0 m 0 s)

The freshclam class can be tested in the same way.

Configuring the module

Complexity	Easy
Installation Time	5 minutes

The module configuration should be sane by default. Every parameter available in the Ubuntu 10.04 LTS repo version of clam should be available. The default values for the various parameters should match the defaults in Ubuntu 10.04 LTS. If you need to tweak any setting whatsoever, simply look up the configuration option in the clam man page, down-case all upper-case letters, and pass that as a parameter to the class. For example:

class {
   “clamav”:
      ensure    => “present”,
      logsyslog => “true”;
}

Would set up clamav with the LogSyslog clamav configuration option set to true.

Example usage

The same usage outlined above for testing is a typical use case of clamav. Simply enable those classes in the node definition and you will have a working clam setup, ready to check for malicious content coming in through e-mail. You could even potentially integrate clam with other services, like scanning user uploads to your custom webapp. Freshclam will update from the canonical repo every day with the default settings, ensuring you have the latest virus definitions.

Conclusion

To me, this module is an ideal example of module design. It is small in scope, yet as complete as possible of an interface to the clam configuration. This allows for you to easily set up clamav and freshclam on a node with nearly no tweaking or external dependencies necessary. If you end up needing some tweaking, as you have seen it is trivial to make small changes to clam with this module. It also has some basic compatibility checks to ensure your consumers know where this module will work.

This module would probably work on Debian 6, but I haven’t tested. To add Red Hat support some variables for the package and service name(s) would probably have to be added, and all of my gigs that use clam are on Ubuntu 10.04 LTS.

Additional Resources

• ClamAV HomePage
• Puppet Forge Module Page
• Previous Modules of the Week
• Joe McDonagh’s Blog
]]> http://puppetlabs.com/blog/module-of-the-week-jmcdonagh-clamav/feed/ 0 http://puppetlabs.com/blog/join-us-for-puppetconf-2012/ http://puppetlabs.com/blog/join-us-for-puppetconf-2012/#comments Thu, 19 Apr 2012 15:19:23 +0000 jose http://puppetlabs.com/?p=13637 Registration for PuppetConf ’12 is now open. We’re in a new city and a new facility, with new tracks and new programs. Look forward to 5 concurrent tracks over 2 days focusing on all things operations. Our new venue offers one large theater for keynotes, while our second auditorium will be dedicated to Puppet Community presentations and hacking space. We’re introducing a hands-on lab component to the conference, and we’re happy to announce that we’ll be offering the first ever Puppet Admin and Puppet Developer Certification exams at PuppetConf.

With over 70 speakers, 600+ community members, and the Puppet Labs team, PuppetConf is a must-attend event. We’re looking forward to seeing you in San Francisco!

Here’s a quick recap of last year:

All 2011 talks can be viewed on the Puppet Labs YouTube Channel.

]]> http://puppetlabs.com/blog/join-us-for-puppetconf-2012/feed/ 0 http://puppetlabs.com/blog/april-2012-new-york-events/ http://puppetlabs.com/blog/april-2012-new-york-events/#comments Mon, 16 Apr 2012 18:46:41 +0000 jose http://puppetlabs.com/blog/april-2012-new-york-events/ Spring is the time to be in New York. We know it, and apparently so do our partners. Whether you live in or around New York or just happen to be in town visiting over the next two weeks come find us at these awesome events:
• Wed 4/18 – Come meet us at the AWS Cloud for Start-Ups & Developers social hosted by Amazon Web Services!
• Thur 4/19 – Stop by booth “S2″ at the AWS Cloud Summit to talk to our Puppet experts, or get some free schwag.
• Fri 4/20 – Meet Ohad Levy at the PuppetNYC meetup.
• Wed 4/25 – Check out our presentation at the inaugural EucaDay conference.

And, last but not least:

• Fri 4/27 – Join us for an awesome Puppet Camp NYC featuring Puppet Labs’ own Luke Kanies, James Turnbull, Kelsey Hightower and Eric Shamow!
]]> http://puppetlabs.com/blog/april-2012-new-york-events/feed/ 1