Getting Started With Puppet: How to Write Your First Module

1361349665_puppet-logoThis post will walk you through the process of writing your first, albeit, a very simple Puppet module. Nothing fancy here, that can come later once we get the basics down.

Before we get started let’s take a minute to go through a couple of prerequisites.

First, we will assume that you are doing your work some sort of Linux workstation or server. Second, we will assume that you have already installed and configured a Puppet Master and a Puppet Client. In this particular case, I am working on my Fedora 20 desktop. It serves as both my master and client. Last, we are assuming that have a basic site.pp and are able to run the Puppet agent without issue or error.

Now lets get down to the meat and potato. Note we are working with opensource Puppet, not Puppet Enterprise.

First lets change directory to our Puppet module directory.

#cd /etc/puppet/modules/

Now lets create a basic manifest from a template, to do this we need to generate a module. Our very simple module is going to be called harden-cron. Run the command below to generate our bare-bones module

#puppet module generate harden-cron

Now that our module has been generated lets change directories once again. This time we need to change to the manifests directory in our newly created module.

#cd harden-cron/manifests/ && vim init.pp

Now we need to edit our manifest. This is, more or less, our playbook. It defines what “work” puppet needs to do.

Our end goal is to create a manifest that will ensure that /etc/cron.allow exists, is owned by root, and has specific file permissions. We also need to make sure that /etc/cron.deny does not exist. In order to accomplish this we use the simple code shown below. Note that we have defined our class has “harden-cron”. This is the same name that we used when creating our module above.

[code language=”css”]

class harden-cron {

file {"/etc/cron.deny":
ensure => absent,
}

file {"/etc/cron.allow":
ensure => present,
owner => "root",
group => "root",
mode => "600"
}
}

[/code]

Now we need to test our syntax and make sure that we have not made any errors. Use the command below to accomplish this. No output from the script below means that you do not have any syntax errors.

#puppet parser validate init.pp

Excellent, so now we have a new module, but its not going to do anything for us until we declare it in our site.pp. So lets change directories and do a bit of editing

# cd /etc/puppet/manifests/ && vi site.pp

Continue reading

XenServer 6 – Deleting a Storage Repository From the Command Line

8-inch-floppy-disks

So before we get started deleting a Storage Repository, we need to know a few key terms.

In XenServer a Storage Repository is a storage target that contains virtual disks (VDIs) and isos.

A PBD (physical device block) is what they call the interface between a physical host and an attached SR, which is responsible for storing the device config that allows the host to interact with the storage target.

So now that we have gotten that out of the way, lets get started.

First list the SRs on a host.

#xe sr-list uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346

Using the uuid from the you got from the command above, run the command below using the UUID, which for some reason you are calling the sr-uuid.

#xe pbd-list sr-uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346

uuid ( RO) : a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a
host-uuid ( RO): 4a9971f7-1e59-4e02-b849-04d206ee7b2b
sr-uuid ( RO): 9a9e7903-7c0f-4f7e-f0a3-e39c54478346
device-config (MRO): device: /dev/disk/by-id/edd-int13_dev81
currently-attached ( RO): true

Now using the the UUID output of from the command above, unplug the pdb.

#xe pbd-unplug uuid=a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a

Then destroy it….boom.

#xe pbd-destroy uuid=a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a

Now tell Xenserver to “forget” the SR.

#xe sr-forget uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346