Recent versions of puppet do not add subjectAltNames to the server certificate when it’s generated by the puppetmaster process.  This means that if you do not use the same name as your masters hostname to connect to puppet you will get a lovely cert mismatch.  I posted a question on serverfault about this (here).  It looks like the common practice for EC2 in particular is to use a uuid as the certname for each puppet client.  This avoids name collisions and problems with hostnames changing everytime the instance is rebooted.  It’s a little harder to keep track of since they aren’t very easy to remember, so caveat emptor.

First get puppet installed.  I tend to use gems (even though I despise them) since they update much faster upstream than anything else.  Do NOT run puppet or start the puppetmaster.

Generate a uuid or pick some string/name/moniker that’s going to be uniq and consistent.  (uuidgen to get a uuid)

Setup a basic puppet.conf, rpm installs will do this for you, gem installs you are on your own.

[main]
logdir = /var/log/puppet
rundir = /var/run/puppet
vardir = /var/lib/puppet
ssldir = $vardir/ssl
pluginsync = true
server = puppet
environment = production
certname = ENTER_UUID_HERE
dns_alt_names = puppet
report = true

You can also manually generate the cert with the following.
puppet cert generate --dns_alt_names puppet ENTER_UUID_HERE
Your master cert will have the subjectAltNames field now, This is all addressed in http://projects.puppetlabs.com/issues/10739 and should be fixed in the next puppet release.

The concept of using the uuid for ec2 type instances is sound and will prevent ssl headaches in the future.

Several of the things I played with were adding a lun to a machine and getting it to show up without rebooting.  Translating docs gleaned from the web to my configuration was a bit tough at the beginning because we have a highly redundant fabric.  That meaning we have 2 HBAs in each host each with 2 fiber paths.  What this means is that when I get luns to show up I see them 4 times for each lun.  Apparently most people that write about their SAN experiences do it with a single path to their storage device through the fabric.   I also went through the rigamarole of removing a lun from a host (again without rebooting).  All in all it was pretty clean, a series of echo’s to the /sys subsystem, not nearly as ugly as adding and removing actual scsi devices.  It was also completely non-disruptive to other luns and overall performance.

There’s been quite a bit of debate among the other SAs at work about how we should handle luns at the host level.  Originally the thought was to add LVM on top of the LUN (which with multipath is kinda a bear) then create the filesystem on top of LVM.  The thought was originally that this would enable us to grow and shrink as needed and give us a similiar flexibility to the NFS volumes we are so used to dealing with.  Turns out shrinking is still iffy.  I’ve tried it twice now and had catestrophic failures both times.  The filer seems to handle it fine, but the host just flat out fails to see it as a valid filesystem once the lun gets smaller.

With multipath configured correctly what we see with an fdisk -l is 5 new ‘disks’.  sdX – sd{X+4} and dm-X.  So depending on how many existing scsi devices (including other luns) we have sde,f,g,h and dm-0 (assuing a, b, c already existing and no other san luns).  What’s a little confusing is that each of these devices is the same disk, you don’t want to use the sdX devices for anything (unless it’s a onetime operation) in case you lose a path.  So you do everything to the dm-X device created by multipath.  The other confusing thing is that while these are ‘disks’ they also are not.  You can create partitions on them but you don’t really need to, so it kinda confuses your brain in what you are used to dealing with.

So the original plan with LVM was to create a partition consisting of the entire disk, add it as a PV, create a volume group, then a LV on the volume group of the whole size.  It struck several of us that this really was overkill.  Where LVM shines is when you have lots of descrete storage objects and you want to group them all together.  Logically this ‘thing’ is a single lun where all the physical abstraction is already done (with about 4 levels of abstraction in the case of NetApp).  The other alternative, which I ended up doing for this particular implementation, was to just create a filesystem right on dm-0.  I didn’t create a partition, didn’t do LVM, just mkfs.ext3 /dev/dm-0.  Worked like a charm, no wasted space, very simple.

There is a gotcha though.  Multipath has the annoying habit of renaming the multi-disk device (dm-X) when the host reboots and it encounters additional luns.  So if you add a lun to a machine that already has one then reboot it’s possible, nigh on likely, that they will swap dm-1 and dm-0 to the opposite of what you expect.  This is pretty annoying from a mounting standpoint.  This is one potential winning point for LVM, since the LVM data is written to the disk itself you can have a consistent name which to use in fstab etc.  But all that overhead just for a consistent name?  Am I really getting anything else out of LVM in this scenerio?

Enter ext2/3 labels.  Most SAs I know don’t like labels because if you do things like label a disk ‘/’ and try to put it in another machine for recover purposes, you probably won’t get the disk you expect (it’ll depend on bus order).  However labels give us a way to consistently name a dm device regardless of what multipath wants to call it.  This also lets me give meaningful symbolic names to SAN disks that may move hosts (oracle volumes is their current use, so there are 2, 1 for primary and 1 for standby).  So I use e2label /dev/dm-0 FOO to label my san disk.  Then in fstab I use LABEL=FOO. An interesting side effect is that df output shows the uuid of the disk rather than it’s multipath name, but other than that it seems to work.

Next I need so spend a bunch of time with a non-critical volume and figure out all the ins and outs of growing and (maybe) shrinking the fileystem.  All of the above work was done on a RHEL5 system (64bit), my feeling is that all bets are off when it comes to RHEL4 and LVM might be a very real hard requirement.  I also wonder if multipath is the right way to go.  Would it be possible to use LVM to create a fault tolerant storage device?