Cleaning up Old XenServer Patches The Easy (Lazy) Way

Cleaning up patches on XenServer isn’t difficult but it can be annoying if you have a large number of hosts. Here’s the easy way to clean up your old patch files on all hosts….if you’re an extra lazy Linux admin you can use tmux to do this to all of them at the same time 🙂

for i in `xe patch-list | grep uuid | awk '{print $5}'` ; do xe patch-clean uuid=$i ; done

I’ve been wrapping up some large projects on the work front and several audio/music related projects so apologies for not posting here for a while. I have lots of good stuff coming down the pipe in the near future!

Managing IIS With Puppet via Powershell DSC

Use Case:

Many of us in DevOps/Cloud/Site Reliability/System Engineering have long been using Puppet to manage our Apache and Nginx configurations. However it seems like every Windows deployment I come across using IIS is either not in any form of config management, or is managed through a series of VBScript and PowerShell scripts or System Center. If your organization is big enough to afford System Center this isn’t really much of an issue for you; however for those of us managing IIS web farms without SCCM, Microsoft has extended a nice olive branch with the delivery of PowerShell Desired State Configuration.

Given that most of us work with such broad toolsets, the idea of adding yet another configuration management platform into the mix seems less than ideal. However, there is an official Puppet Forge module that allows you to leverage PowerShell DSC within your Puppet code. What I found in my journey of doing this is that, while there is some decent documentation, there are pieces that clearly seem not to be well documented that required figuring it out the hard way. In this blog post I’ll cover and distill what I’ve learned in configuration of IIS through PowerShell DSC via Puppet.

Prerequisites:

This blog post will assume that you have already installed the PowerShell DSC forge module. I will link the module and its dependencies below; if you are unsure how to install Forge modules, see the documentation on the link to the module below.

This blog post will also assume that you have already installed IIS either in your AMI/Template or via Puppet. Great, now that that’s all out of the way, let’s get started.

 

Overview Example Class:

Before diving into the weeds in each section, I wanted to provide a code sample of a single application pool, website, virtual directory, and web application, complete with the DSC dependencies:

 

class webhosting::clientname::sites::dev {
 
dsc_windowsfeature{'iis':
  dsc_ensure => 'Present',
  dsc_name => 'Web-Server',
}
dsc_windowsfeature{'aspnet45':
  dsc_ensure => 'Present',
  dsc_name => 'Web-Asp-Net45',
}
dsc_windowsfeature{'iisscriptingtools':
  dsc_ensure => 'Present',
  dsc_name => 'Web-Scripting-Tools',
}
 
#App Pool Creation
dsc_xwebapppool{'dev.example.com':
  dsc_name => 'dev.example.com',
  dsc_ensure => 'Present',
  dsc_enable32bitapponwin64 => true,
  dsc_managedruntimeversion => 'v4.0',
  dsc_managedpipelinemode => 'Integrated',
  dsc_identitytype => 'ApplicationPoolIdentity',
  dsc_state => 'Started',
  require => Dsc_windowsfeature['iis'],
}
 
#Website Creation
dsc_xwebsite{'dev.example.com':
  dsc_ensure => 'Present',
  dsc_name => 'dev.example.com',
  dsc_state => 'Started',
  dsc_physicalpath => 'D:\\www\\dev.example.com\\webroot',
  dsc_applicationpool => 'dev.example.com',
  dsc_bindinginfo => [{
  ipaddress => '*',
    protocol => 'HTTP',
    port => 80,
    hostname => 'dev.example.com',
    },
    {
    ipaddress => '*',
    protocol => 'HTTPS',
    port => 443,
    hostname => 'dev.example.com',
    certificatethumbprint => '<certificatethumbprintgoeshere>',
    certificatestorename => 'WebHosting',
    }],
 require => Dsc_xwebapppool['dev.example.com'],
  }
 
#Web Applications
dsc_xwebapplication{'AwesomeApp':
  dsc_ensure => 'Present',
  dsc_name => '/AwesomeApp',
  dsc_website => 'dev.example.com',
  dsc_webapppool => 'dev.example.com',
  dsc_physicalpath => 'D:\\www\\dev.example.com\\webroot',
  require => Dsc_xwebsite['dev.example.com'],
  }
 
#Virtual directories
dsc_xwebvirtualdirectory{'AwesomeApp':
  dsc_ensure => 'Present',
  dsc_name => 'AwesomeApp',
  dsc_website => 'dev.example.com',
  dsc_webapplication => 'AwesomeApp',
  dsc_physicalpath => 'D:\\webapplicatons\\AwesomeApp',
  require => Dsc_xwebapplication['AwesomeApp'],
  }
}

DSC Windows Feature

Starting at the top and taking this a chunk at a time, we see after the opening Puppet class statement that there are several dsc_windows_feature statements. These statements install the PowerShell DSC packages on the endpoint nodes. PowerShell DSC wrapped in Puppet assumes that you are using the pull model style of using DSC. What essentially happens on the Puppet run is that your Puppet DSC code gets converted into PowerShell DSC code and run locally on the machine. DSC module can be found at https://gallery.technet.microsoft.com/scriptcenter. Note that modules beginning with an X are considered experimental. That said, most of the experimental modules in my experience have been stable.

 

Configuring The Rest

Beyond this point, the rest of the Puppet code you will see will be prefixed with dsc_. Essentially, to write DSC code in Puppet you will use the same values outlined in the DSC documentation, just prefixed with the dsc_ and using the Ruby hash rockets => instead of =. See the example below:

DSC Example:

    xWebsite DefaultSite
        {
            Ensure          = "Present"
            Name            = "Default Web Site"
            State           = "Stopped"
            PhysicalPath    = "C:\inetpub\wwwroot"
        }

Puppet Example:

     dsc_xWebsite{'DefaultSite':
            dsc_ensure       => 'Present',
            dsc_name         => 'Default Web Site',
            dsc_state        => 'Stopped',
            dsc_physicalpath => 'C:\\inetpub\\wwwroot',
        }

At this point, you can configure your applications specific to your environments. Much like any other Puppet code there are obvious dependencies (can’t create a website that depends on an application pool unless the pool already exists). For this you can use the normal Puppet meta parameters such as before and require statements to resolve dependencies. For IIS-specific DSC parameters see the readme for Microsoft’s XWebAdministration module here:  https://github.com/PowerShell/xWebAdministration

 

Don’t forget to prefix the parameters in the readme with dsc_ when converting to Puppet code. Happy configuring and Puppeting! Until next time, may your servers always be up and your coffee mugs never empty!

The Importance of Vacation

Burnout Is Real!

As a bit of a self-described workaholic, taking vacation is something that is honestly hard for me. There are always projects and an un-ending backlog of tickets to get done and so many other side projects competing for attention. Don’t fall into the trap of planning vacations around these things. If we’re being honest for a moment, the work will still be there when you get back and unless you’re a one person IT shop you do have a team you can count on. Burnout reveals itself all sorts of ways, it could be that your tolerance for issues and failures on the parts of others has become extremely thin, or that you start dreaming about work, or you get insomnia from worrying about work, or even worse you dread Sunday because you know you have to go back to work the next day.

 

The cost of burnout is high. It can show itself as irritability with customers and colleagues, not being able to get any one thing fully accomplished instead racing around trying to work on too many things at once while things fall through the cracks. Burn out can lead employees to leave their employer due to high stress levels and not maintaining a healthy work/life balance. I’ve heard of people leaving the industry completely citing burnout as one of the top reasons. Sure your co-workers will miss you and will be busier while you are on vacation, but as a matter of mental health and the well-being of your career vacations are certainly important.

 

Fully Unplugging

It’s best to truly unplug, if you are flying out of town or going somewhere, leave the laptop behind. As IT professionals we spend many of our waking hours in front of machines, take some time to enjoy the rest of the world without the laptop. Sure if there is a priority 1 fire and you are the only person who knows how to fix it you should absolutely answer your phone, however there are ways to minimize this, and as long as you continue to be the only one who knows how to fix specific things you will never get to fully unplug.

 

Some tips to prevent calls while on vacation include sitting down with your team before vacation and going over areas where there may be knowledge gaps. This is especially important if you have been silo’d on a project for a while or know some really nitty gritty details that others on your team may not. Also if you have an internal Confluence or wiki be sure to document tasks that colleagues typically turn to you for, as this will help them be more self-sufficient in your absence. Be sure to set an auto-responder on your emails with the dates you are out and contact details of how to reach your team (preferably via a support ticketing system, on-call phone number, or group email alias). Any tasks that have critical timelines that can threaten to delay a project should be sent out in a summary email detailing the deadlines (referencing ticket numbers) and who will be responsible for these tasks while you are out. If you are working with project managers or other stakeholders who communicate with you regarding the status of these tasks, be sure they know who will be covering these for you in your absence.

 

Resist The Urge To Respond

If you have work email on your phone you may want to remove it while you are on vacation, or if you are checking emails to avoid a mountain of emails when you get back there are a few helpful strategies, however the key here is to not respond to emails unless you absolutely have to. If customers and colleagues see you responding they will assume you are available and will begin contacting you, try to avoid this as much as possible. A good way to handle checking email on vacation if you so choose is to do so only once a day or once every couple days. Delete/archive all emails that do not require a reply. Star/flag any emails you need to respond to when you return from vacation. This will help make email more manageable upon your return. If you are one of the lucky ones who can and has decided to avoid email altogether while on vacation, when you return you can try sorting email by sender, which will help you to most easily weed through what is important and what is not. Chances are email alerts from monitoring systems are no longer relevant, along with any vendor spam, while emails from your boss or HR are probably worth prioritizing.

Also for the love of god remove or sign out of and turn off notifications on the mobile app for Slack, Hipchat, Skype, or whatever instant messaging platform used in your office.

Returning To Work

Once your vacation has ended and you’ve successfully had some R&R, confronting work and getting up to speed may seem daunting. If your team does stand-ups see if you can get a brief summary of project statuses and important events while you were away or schedule a short meeting with your team. Also allow yourself a few hours to catch up on email and start responding. In general at least half of your first day back should allow time to catch up on communications, and ensure you’ve removed all auto-responders, and updated your voicemail to remove any out of office greeting you may have recorded.