Archive for February 2011
Structured log output from puppet
A post on puppet-users got me thinking about improved output. A simple method is to just JSON encode the log and parse the message objects on the other side. So here’s an easy way to do that.
This works pretty well with puppet master
& puppet apply
:
tmp donavanm$ puppet apply /tmp/test.pp --logdest json {"level":"notice","time":"Sat Feb 19 17:01:12 -0800 2011","tags":["notice"],"source":"Puppet","message":"this is a message"} {"line":1,"level":"notice","time":"Sat Feb 19 17:01:12 -0800 2011","tags":["notice","notify","class"],"file":"/tmp/test.pp","source":"/Stage[main]//Notify[this is a message]/message","message":"defined 'message' as 'this is a message'"} {"level":"notice","time":"Sat Feb 19 17:01:12 -0800 2011","tags":["notice"],"source":"Puppet","message":"Finished catalog run in 0.06 seconds"} |
It works less well with puppet agent
, unfortunately. If --verbose
or --debug
is specified the :console
destination is added, so you’ll get duplicate messages. Lame.
Currently there’s no way to load this as a plugin, see #6522. Appending this method to puppet/util/log/destinations.rb works. Meh.
Ideally I think we’d have different options for transaction reports. Currently the agent application always forces reports to the rest
terminus. Being able to set up multiple destinations, like nagios or a local cache, would be great.
Update I’d previously mentioned #4248, which is similar but not what I really want. Updated with the correct issue. Also opened #6523 to clean up logdest handling in applications like agent.
A simple IP Address reflector
Or, Why the hell do I have to build every tool myself. I find it incredible that no one else has wanted this before.
In the course of another side project I needed to determine a nodes externally visible IP Address and FQDN. After a while I eventually found this forum post. And their “bot” url does work, though it’s a bit limited. So I hacked up some simple PHP to do it in a flavor that I like.
donavanm$ curl https://strewth.org/ip.php {"ipaddress":"98.207.236.52","fqdn":"c-98-207-236-52.hsd1.ca.comcast.net"}
Will also accept source
and (reasonable) timeout
parameters. A simple TCP connection is attempted back to your IP and specified port. Handy to see if NAT/iptables/etc is functioning.
donavanm$ curl https://strewth.org/ip.php?port=80 {"ipaddress":"98.207.236.52","fqdn":"c-98-207-236-52.hsd1.ca.comcast.net","port":{"80":false}}
Managing Amazon Route 53 with Puppet
This has been sitting in a work dir for a month now. Hopefully posting it motivates me polish it up and release it to the internets.
A while back I got new DSL service at my house in Seattle. In the course of moving I had to reconfigure a few nodes, setup a gateway, etc. And in doing so I discovered that dynamic dns providers totally suck. It’s incredible. $20/year and you can’t even properly do delegations?
Coincidently I also noticed the new hotness from AWS at about the same time. DNS is part of my infrastructure, and puppet manages my infrastructure… So time to make puppet manage my DNS. After an evening hacking this up I present The AWS Route 53 type & provider:
Ensure a record:
tmp donavanm$ sudo puppet apply /tmp/r53.pp notice: /Stage[main]//Route53[foo.strewth.org.]/ensure: created |
Get a list of my current records:
tmp donavanm$ sudo puppet resource route53 route53 { 'foo.strewth.org.': ensure => 'present', value => ['192.168.0.1'], rtype => 'A', zone => 'strewth.org.', ttl => '360' } |
Change ensure => 'absent'
and remove that record:
tmp donavanm$ sudo puppet apply /tmp/r53.pp notice: /Stage[main]//Route53[foo.strewth.org.]/ensure: removed |
And yup, it’s really gone:
tmp donavanm$ sudo puppet resource route53
tmp donavanm$ |
Being a fully functional type and provider it should Just Work in any of the puppet applications. I think the most powerful model would be using something like exported resources with puppet agent and master. The clients would export a resource, like I’ve shown. A trusted master periodically collects and updates all of the entries.
# dynamic clients export their settings class r53::client::dynamic { @@route53 { "${fqdn}.": value => $ipaddress, rtype => 'A', zone => "${domain}.", ttl => '360' } } # A puppet master collects and updates class r53::server::dynamic { Route53 <<| tag == 'r53::client::dynamic' |>> } |
I could see this being a great tool for people with cloudy puppet deployments. Or when you just really want your laptops dns record to be current.
At a dollar a month its half the cost of those dynamic dns guys, totally automated, and a thousand times cooler.