Thursday, August 22, 2013

Puppet: Defining A System, Adding A Package And Launching A Service

Previously I wrote a simple blog post about setting up a Puppet master and agent. In this post I'm going to write about how to add a simple service to your puppet master that will be installed (if necessary) and started (if necessary) on systems.

Step 1: Define the system on your Puppet master

Before your Puppet master can do its work, it needs to first know what needs to be done and to whom.

In your /etc/puppet/manifests directory you'll want to create two files with the following content (remember: in my case the Puppet master's name is earth and the Puppet client's name is halo):

site.pp

  import 'nodes.pp'
 
  filebucket { main: server => "earth.gateway.2wire.net" }
 
  File { backup => main }
  Exec { path => "/usr/bin:/usr/sbin:/bin:/sbin" }

nodes.pp

  # nodes.pp
 
  node default {
    include ntp
  }
 
  node 'halo.gateway.2wire.net' inherits default {
  

  }

In this example the default system definition will install the sudo module. The definition for a server will inherit that definition and add to it the ntp module. And finally the definition for halo inherits the server definition and adds to it the bip module.

In later posts I'll expand on the above to do more involved server definitions, specifically add modules that include files. But let's not get ahead of ourselves.

Step 3: Add the module definition

Before Puppet can do anything on the client it has to have more details on, in this case, the ntp module.

To do that we first create the file /etc/puppet/modules/tests/init.pp with the following content:

  class { 'ntp': }

Next we'll create the file /etc/puppet/modules/ntp/manifests/init.pp with the following content:

  class ntp {
 
    package { ntp: ensure => installed }
 
    file { "/etc/ntp.conf":
      owner => root,
      group => root,
      mode => 640,
      require => Package["ntp"],
    }


    service { 'ntp':
      name => 'ntpd',
      ensure => running,
      enable => true,
      subscribe => File['/etc/ntp.conf'],
    }
 
  }


In the configuration we ensure the package is installed, that, if the file /etc/ntp.conf exists, the configuration is owned by user root and group root, that it has the proper file modes, and that if it doesn't exist the package named ntp is installed to provide it.

The service stanza adds to the above a check for the actual service itself. If Puppet doesn't see a process named "ntpd" then it knows that the service isn't up and will launch it for you.

Conclusion

That's it! If you then launch the puppet agent on your client machine, you should see it apply the above configuration by installed the package named ntp.

Sunday, August 18, 2013

A Simple Puppet 3.1 Setup

Recently I got the notion of setting up a puppetized configuration system for my computers at home. I have two machines:
  • earth - a Linux desktop, which will be the puppet client
  • halo - a Linux server, which will be the puppet server as well as a client

My biggest frustration, though, was find a simple tutorial that would help me get Puppet up and running, the two machines talking, and a configuration pushing down onto the client.

So after pulling from a few separate sources, here's what I found works. In a future post I'll write about how, after more frustration, I was able to get configurations pushing down onto the systems and how I setup version control on the puppet configurations themselves.

Step 1: Install Puppet (Fedora 19)

Not the hardest part, but you do need to be aware of what packages are out there. The two packages are puppet and puppet-server. The former is what you need on any system that will act as a client or agent, the latter on any system that will be offering up puppetized data.

So, obviously, I installed puppet on halo, and puppet and puppet-server on earth.

Step 2: Configuring The Puppet Master

This is the first part that gave me headaches. Since I don't want to deal with external certificates, I just wanted something that would work for me in my private network.

What I did was to configure earth to be it's own certificate authority with the following in /etc/puppet/puppet.conf:
[main]
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    ssldir = $vardir/ssl

    # self-signing certificates
    server = earth.gateway.2wire.net
    certname = earth.gateway.2wire.net

[master]
    reports = store, http
    modulepath=/etc/puppet/modules:/usr/share/puppet/modules

[agent]
    classfile = $vardir/classes.txt
    localconfig = $vardir/localconfig

Step 3: Exchanging SSL Certificates With The Agent

Here is where there was a decided lack of examples online. And the Puppet website didn't help at all, especially with recovering things after a failure occurred.

The steps to follow are:
  1. unless you have your own DNS, add the fully qualified hostnames of each machine in the other's /etc/hosts file; i.e., for me I had to put earth.gateway.2wire.net in halo's file, and halo.gateway.2wire.net in earth's, then
  2. open two terminals on your puppet master (in my case, on earth) and one on your puppet agent (in my case, on halo), then
  3. start up in one puppet master terminal a master using the command line:
    1. puppet master --no-daemonize --verbose
  4. on the puppet agent terminal start an agent using the command line:
    1. puppet agent -t --no-daemonize --verbose
  5. you'll see some messages about exchanging the SSL credentials and then a note that no certificate is waiting, at which point in the other puppet master terminal window you'll do:
    1. puppet cert sign halo.gateway.2wire.net
At this point your machines will have shared SSL credentials and will be able to talk to each other.

Step 4: How To Recover If Something Goes Wrong

If you start getting messages about the keys being wrong on the agent side, the easiest thing to do is to delete the /var/lib/puppet/ssl/ directories on BOTH machines. This way you no longer have any data about the other system and can start over with a clean slate.

Sunday, August 4, 2013

Grouping Channels In Weechat By Network

One of the things that's kept me from switching from Xchat to Weechat for IRC was that I couldn't keep my channels grouped together by network. Where I work we have internal IRC channels with the same name as public IRC channels, and it was confusing to look at the window and figure out which was internal or not.

Fortunately, I found a way to change that in Weechat and so have switched over to it exclusively. Here's how:

Install the buffers.pl plugin.

The buffers plugin lets you configure how the various buffers are displayed.

  /script install buffers.pl

Tell buffers.pl to show the IRC network name.

By default buffers.pl only shows the channel name (#name). To group channels together, you need to enable showing the fullly qualified channel name (network#name):

  /set buffers.look.short_names off

Sort channels by name and not numbers.

This groups the channels together by their server name. Otherwise they're grouped by the order in which they were opened. So if you open a channel in Freenode, say, after opening one in OFTC then the channel in Freenode will fall after OFTC and not get put with the other Freenode channels.

  /set buffers.look.sort name

That's it! Now your channels are grouped together by network.