Bootstrapping Windows with Chef

16-May, 2014

I will admit that generally I work with Linux hosts (generally Fedora and RHEL) but sometimes I also work with Windows hosts and would like to integrate them into my Chef environment. The official instructions for performing this task is here, but the following are my notes.

The first step to doing this is to install the knife-windows plugin on your Chef Server:

cd /opt/chef-server/embedded/bin
./gem install knife-windows

Note: to make this work I needed to install some additional libraries above and beyond the libraries that I tend to use in my Chef Server (which runs Fedora):

yum install gcc-c++ patch

You then need to repeat the installation on the workstation that you run knife from (if that is different from your Chef Server).

For the next step, on the windows host you need to install the Windows Management Framework Core Package, available at here for most platforms. This is done by downloading and installing the appropriate binary for your operating system.

Note The installation of the Windows Management Framework Core Package requires .Net Framework 2.0 SP1, so depending on your operating system you may need to install that prior to the installation of the Windows Management Framework Core Package. To update the .Net Framework you can install the .Net Framework 3.5 Service Pack 1 which includes the necessary patch for the .Net Framework 2.0.

Once that is installed you need to configure the individual windows host. This is done running the following command.

winrm quickconfig -q

The output of this command is as follows:

WinRM already is set up to receive requests on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

WinRM has been updated for remote management.

Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

Additionally, run some additional commands to configure the Remote Management:

winrm set winrm/config/winrs @{MaxMemoryPerShellMB="300"}
winrm set winrm/config @{MaxTimeoutms="1800000"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/service/auth @{Basic="true"}
netsh advfirewall firewall set rule name="Windows Remote Management (HTTP-In)" profile=public protocol=tcp localport=5985 remoteip=localsubnet new remoteip=any

Once this has been done you are ready to bootstrap the host into Chef, this is done by running the following command:

knife bootstrap windows winrm <hostname> -x <username>

Where hostname is the host to bootstrap and username is the usernmae to use to connect to the host.

The command weaves its magic and when it is finished you have a newly bootstraped windows host:

Chef Server with Windows Host

Comments

Updating Chef Certificates

15-May, 2014

I ran into a problem in my chef environment in that I was using the original certificate that it was installed with and I was getting some trust issues when using the infrastructure. So I decided to use a signed certificate from my internal CA. The following is a quick overview of getting that going.

Assuming that you have the public and private key. Log into your chef server and go to the following directory:

/var/opt/chef-server/nginx/ca

Replace the yourhostname.example.com.key with your private key and yourhostname.example.com.crt with your public key.

Reconfigure the Chef Server by running:

chef-server-ctl reconfigure

And then restart your server by running:

chef-server-ctl stop
chef-server-ctl start

And your Chef server should now be using your new certificate.

Comments

Mirroring Centos and Fedora Repositories

13-Mar, 2014

If you perform many Linux builds from bare metal, there can be a big advantage in mirroring the yum repositories, the biggest of which is speed. This is because when you mirror the repository all the files are moved off disks attached to your LAN rather than via Internet. We synchronize the repositories each night using Jenkins and generally speaking they complete within 30 minutes. If there is a large release (such as a new version of Fedora) then sometimes the downloads are still happening as we start work in the morning.

Some questions that weren’t clear when we started on this process, are what do you synchronize and how much space does it take up.

How much diskspace do you need for the mirror?

That question is difficult to answer directly, but we do the following:

  1. Only download 64 bit build, i.e.. ignore 32 bit and other platforms.
  2. Ignore ISO imagines.
  3. Only download the versions that you require, ignore the others.

Hence, our current exclude file for Centos rsync is as follows:

**/*.iso
**/isos
**/i386/**

This allows you to support Centos 5 and Centos 6.

For Fedora we use the following exclude file:

development
releases/10/**
releases/11/**
releases/12/**
releases/13/**
releases/14/**
releases/15/**
releases/16/**
releases/17/**
releases/18/**
updates/10/**
updates/11/**
updates/12/**
updates/13/**
updates/14/**
updates/15/**
updates/16/**
updates/17/**
updates/18/**
**/i386/**
**/debug/**
**/alpha/**
**/SRPMS/**
**/*.iso
**/test/**
**/source/**
**/testing/**

Given that the current version of Fedora 20, this means that we currently mirror version 19 and 20. When 21 comes out I will probably cease to mirror 19. We also exclude all testing, alpha and debug rpm’s.

So the current sizes for the repositories are as follows:

  • Fedora - ~ 200Gb
  • Centos - ~ 30Gb

These allow us to perform PXE based network installations (if you want the ISO’s for installation you will need to modify the excludes).

What command do you run to sync the mirror?

This will be dependent on where you are, but we use iiNet as our ISP and they provide an rsync server that contains a whole lot of repositories, two of which are Fedora and Centos. Our commands for syncing these repositories are as follows:

rsync --archive --verbose --delete --delete-delay --delay-updates mirror.internode.net::centos /opt/mirror/centos --exclude-from /etc/excludes/centos

and for Fedora:

rsync --archive --verbose --delete --delete-delay --delay-updates  mirror.internode.net::fedora /opt/mirror/fedora --exclude-from /etc/excludes/fedora

The advantage of delaying deletes and delaying updates is that it keeps the mirror in sync (much like wrapping multiple database transactions into a single commit). Failure to do this might mean that during a build (or an update) the mirror could be inconsistent.

We haven’t found a lot of documentation around that details this so we have detailed here in the hopes that it may help some people.

Comments

More Posts..