Over riding puppet modules

I've discovered that you can overload parts of puppet modules.  This means I can still use the module but just overload what I need.

Of course, modifying the module may be tidier but modifying a module used by lots of production servers is not a trivial undertaking.

Here's how it works:

class systems::section::authssh inherits auth::ssh {
   File['/etc/pam.d/sshd']{

      content=>"blah"

  }

}

This means I get all the good stuff from auth::ssh but I can override the sshd pam configuration for this server/group of servers.

The case I was dealing with was a bit more complicated (though same concept), in modules I have auth::thistype which includes auth::pam

I would normally include auth::thistype and just to complicate things the setting I want to change is in auth::pam.  Unfortunately (in this case) puppet won't let you modify an argument in a class that isn't the one setting it (or a sub class thereof) so I can't set it in the class as above, I need to set it in the correct class, like this:

class systems::section::auththistype inherits auth::thistype {

  include systems::section::authpam

}

class systems::section::authpam inherits auth::pam {
   File['/etc/pam.d/sshd']{

      content=>"blah"

  }

}

(Please note, code sections were genericised and should be used as reference only) 

Install TSM on Debian / Ubuntu

I've had to do this a few times and normally kludge my way through.  The internet seems full of older versions and convoluted/partial instructions.

I decided I should just fix it properly.

The script I put together takes the tar ball from IBM and turns it into debian packages.

I tested on Precise server but it should work on most debians.

You can download it from http://nzgeek.com/install_tsm.sh

OSX VPN issue

For a while I've noticed that if VPN dies while connected (eg. If you put your computer to sleep before disconnecting) it won't reconnect until after a reboot.

I checked routing tables and logs etc with little success and I JUST realised that when it starts 'racoon' (a key management daemon) starts up.  A stale racoon process causes issues when trying to connect hence if you kill it first then try and connect it works fine.

Something like this should do it (from terminal):
 sudo kill `ps -U root -o "pid,comm"|grep racoon|cut -d" " -f1`

SCCM PXE and WDS

Last weekend I started setting this up and had a few problems.  As is my way I checked the docs which appear to be non-existant and then the community and finally found one page with some details.  Basically these are the hints you need.  The last two are the ones that caused my troubles.

• As is always the way in SCCM, check the package status before assuming a package is available or removed
• Check the pxesetup log before assuming pxe is (de)installed
• If everything is in one subnet and you can probably leave DHCP options alone
• Start with WDS and PXE uninstalled, then install wds, reboot, install pxe, reboot
• Make sure you have both 32 and 64 bit PE images, even if you will ever use them both
• No matter how much windows tells you off for not configuring WDS, don't configure it

IBM vs Dell

*sigh* this is why I buy Dell.

A few months ago I had a component fail on a dell datastore, from me reporting the issue to me having the part - one hour.

Eight days ago I had a part fail on an IBM datastore, from me reporting the issue to having the part - 8 days and counting.

Both had 4 hour response warranty bought with them.

Shrinking a windows volume in VMWare ESX

I searched and found some disruptive and complicated ideas on doing this.  Most involved using VMWare converter offline but some suggested using robocopy etc.

The problem is I didn't want to have to reboot or disrupt services but I needed to shrink the SCCM DP volume so I could move it to smaller, faster disk.

So, I figured out another way:

1. In the storage MMC
1. Defrag the disk - you can't shrink past existing fragments
2. Shrink the volume
2. In VM settings, make a new volume the size of the now shrunk volume
3. In the storage MMC
1. Make a mirror
2. Wait for it to sync
3. Delete the old volume from the mirror
4. In the VM settings, delete the old volume

Hey, it's me

As happens from time to time, today I figured out a cool way to do something.  I figured it was about time I found somewhere to share this.  So begins my blog.

The first few posts are likely to be windows focused, SCCM is central to my current key project.  But fear not!  I use whatever tools suit the purpose and a few upcoming projects are OpenBSD and Ubuntu based with some web, DHCP, DNS, firewall etc stuff mixed in :)