Ops-Tools-Build release - V0.2.0

Sunday, May 14, 2017 | Posted in Ops-Tools-Build

Version 0.2.0 of the Ops-Tools-Build toolkit was released.

This release was focussed on providing the capabilities to use the Chef toolset to create new resources. All the work items that have been closed for this release can be found on github.

New functionality

  • 5 - A new function which provides the ability to execute ChefSpec tests.
  • 6 - A new function which invokes the Chef linting tool Foodcritic on the selected Chef cookbooks.
  • 7 - A new function which invokes the Ruby linting tool RuboCop on selected Ruby source files.
  • 20 - A new package restore script was added to allow restoring Chef cookbooks via Berkshelf.
  • 21 - A new switch was added to the packer function which allows keeping the resources generated with packer in case the packer build fails. This improves the ability to debug issues in the packer build.

nBuildKit release - V0.9.2

Sunday, May 14, 2017 | Posted in nBuildKit

Version 0.9.2 of nBuildKit has been released. This release fixes a number of bugs and adds a few new improvements

All the work items that have been closed for this release can be found on github.

Bugs fixed

  • 280 - The deploy.pushto.gitbranch script called the GitCurrentBranch task with a WorkingDirectory property which did not exist, thus causing the pushing to a git branch deployment step to fail.
  • 281 - The deploy.pushto.gitbranch script did not create the directory into which the repository should be cloned. This caused the step to fail.
  • 286 - The GenerateTargetsFile custom task applied a custom assembly resolver which did not resolve references to the MsBuild assemblies. This is a problem for MsBuild 15.0 and higher because from that version onwards the MsBuild assemblies, e.g. Microsoft.Build.XX are no longer located in the GAC and can thus not be found by the standard assembly resolver.
  • 287 - The shared.prepare.copy.files task did not correctly copy the directory hierarchy.
  • 290 - The build.prepare.generatefiles script only generated the files if they did not exist. This has been changed so that generated files are always created and updated.

Improvements

  • 254 - All warnings and errors have been given a proper error code for easier parsing of errors from the log.
  • 282 - The Git, Powershell and NuGet base tasks have been moved to the Core targets assembly so that they can be used in third party custom tasks as well.
  • 284 - A new task has been added that allows extracting files from one or more ZIP archive files.
  • 285 - Additional conditions have been added to all ItemGroup elements to ensure that these item groups are only loaded when they are required. This reduces build times and improves stability.
  • 288 - A new task has been added that allows downloading files from a HTTP URL. If the file in question is an archive file it can additionally be unzipped before the final copy takes place.

Additionally the first steps to better documentation have been taken. The readme, the introduction and the contributing documents have been updated.

nBuildKit release - V0.9.1

Sunday, April 9, 2017 | Posted in nBuildKit

Hot on the heels of the last release version 0.9.1 of nBuildKit has been released. This release fixes two bugs and adds a few internal improvements.

All the work items that have been closed for this release can be found on github.

Bugs fixed

  • 273 - The CalculateSemanticVersionWithGitVersion task used the current directory as the working directory. While that is correct in most cases there are some cases, especially when running the integration tests, where that is not correct. This has been fixed by requiring the specification of the working directory.
  • 277 - In the same way all NuGet tasks now need a working directory specified in order to make sure that the correct workspace is used when interacting with the NuGet command line.

Improvements

  • 272 - The TestFunctions.PrepareWorkspace.ps1 and the TestFunctions.Git.ps1 have been updated with additional functions and checks so that when creating a test workspace the existing git flow process is only completed if the specified branch exists on the remote. This changes the completion of the git flow process from mandatory to optional.
  • Additionally the IsMasterBranch and IsDevelopBranch properties have been defined in the settings file. These two properties indicate whether or not the current branch is the master or develop branch respectively.
  • 69 - The documentation for nBuildKit itself is being moved from the wiki to a GitHub pages website. As of this release the build for nBuildKit will generate the website using Wyam.

Ops-Tools-Build release - V0.1.0 and V0.1.1

Sunday, April 9, 2017 | Posted in Ops-Tools-Build

Last week version 0.1.0 of the Ops-Tools-Build toolkit was released. With the recent 0.9.1 release of nBuildKit version 0.1.1 of the Ops-Tools-Build toolkit was released.

All the work items that have been closed for this release can be found on github.

New functionality

  • 3 - New scripts have been added to allow the creation of an ISO file using the MakeIsoFS command line application.
  • 4 - New scripts have been added to allow invocation of the packer command line tool used to generate VM and container images from a set of configuration files.
  • 10 - New scripts were added to allow calculation of the hash of one or more files

Setting up a home network with Ubiquiti

Friday, April 7, 2017 | Posted in Hardware Home network Ubiquiti

A little while back we finally got fibre in our street. After spending many years on ADSL (we don't talk about the time of dial-up ...) it was finally time for some decent network speeds at home. As the fibre was being installed in my house it was also time to evaluate the networking gear I was using. Until now I had always used the modem / router provided by the ISP with an additional cheap switch. The gear always worked fine, but didn't provide configuration options other than the ones that describe the connection to the ISP. As I was starting to use my Hyper-V server a lot more and was starting to run multiple VM's it would be nice to get some better control over the network. Additionally based on one of Troy Hunt's blog posts I would also like to set up a separate guest network.

The selection

The prolific Troy Hunt has written about his network setup so I used that as my starting point for finding some new network gear. Fortunately (or unfortunately) I don't have as much area to cover as Troy does so I didn't need nearly as much hardware. The parts I got are:

  • Unifi security gateway: The router which provides amongst other things a firewall, subnet capabilities and DHCP.
  • Unifi switch 8 (US-8-60W): The managed switch which has 4 PoE ports.
  • Unifi AP AC LITE: The smallest indoor access point available from Ubiquiti. Given that my apartment is relatively small I don't have to worry about covering a lot of area, and smaller access points are cheaper.
  • Unifi cloud key: The management device which runs the Unfi software for managing the network.

Except for the cloud key this is pretty much the minimal set of hardware required. The cloud key runs the unifi software which is used to manage the network configuration. You can install the unifi software on a PC but then you need an extra PC or VM running. While I have a Hyper-V server it was easier just to pay for the cloud key and have a separate controller for the network. Note that the network functions just fine without any configuration. However if you want to make changes the easiest way to do so is through the unifi software, although you could do it by SSH-ing into each device.

Another thing to note is that the the 60W switch has 4 PoE ports of the 802.3af kind. Unfortunately the access point requires 24V passive PoE. So either you have to:

  • Power the access point of the converter that you get with the access point.
  • Upgrade the access point to the UAP-AC-PRO
  • Upgrade the switch to the US-8-150W switch which has both 802.3af PoE and 24V passive PoE.

As much as I would like to power the access point of the switch I still opted for the first option, the additional investment wasn't quite worth having one less cable around.

Configuration

The actual configuration was pretty easy, plug in all the parts and things start working, at least for the internal network. Once this is done you can configure the network through the unifi software. To do so the first thing to do is to to find the cloud key. There's a useful plugin for chrome that allows you to find any Ubiquiti devices on your local network, otherwise you can try to guess the IP address of the cloud key. If you only have 4 devices like I do that shouldn't take very long. The gateway by default assumes you are using the 192.168.1.0/24 subnet and the gateway is always the first one.

Once you are logged on to the unifi software it makes sense to give the cloud key a fixed IP address I gave mine the 192.168.1.2 IP address as I am using the 192.168.1.1/24 subnet for all my networking gear. And yes I know I don't have enough networking devices for them to warrant being on their own subnet but it makes things a little easier and it allows me to learn about subnetting and vlans.

Subnetting adventures

As mentioned in the introduction one of the changes I wanted to make was to create a separate guest network. By default a vlan only guest network is created, however I wanted to move the guests onto their own subnet so I created a new network with the 192.168.5.1/24 subnet. I also set the vlan specifier to 1685. And finally I marked this network as a guest network so that the controller applies the guest firewall rules.

Then I created a wireless guest network with the same vlan. What confused me initially is that there is no relation between the wireless network and the subnet other than the vlan tag. Somehow having the same vlan tag is enough to direct the clients onto the the correct subnet.

The last step of the configuration of the guest network is to configure the switch. Because the access point has three different subnets going to it, the managment subnet for the access point itself, the guest wifi and the internal wifi, you need to create a custom ‘network’ on the switch which carries all three networks, making sure that the untagged network is the one on which you want the access point to get an IP address.

Another item I found was that for some purposes the standard IP lease of 24 hours is a bit long. One of the things I'm currently working on is building VM images of different services for use in a test build environment. While doing that I'm creating base boxes for Windows and Linux which involves spinning up a VM, installing the OS, configuring it and capturing the image. While working on the code to automate this process I spin up and shut down VMs quite a lot. If you're using the gateway as the DHCP server and use the standard IP lease time then you run through IP addresses quite quickly. So I created have a separate IP subnet for those VMs where the IP lease time is 2 hours (which is more than long enough to create a VM and capture a base image).

In the end

In conclusion it's a good set of hardware and software and as a bonus, there are updates which apply without problems. There is something reassuring in the fact that the manufacturer actually cares enough about their product that they want to keep it running, unlike much of the consumer gear.

The unifi software provides a lot of useful and interesting capabilities and it's obviously aimed at the business / educational environment. There are a lot of of features that I don't need, but they are fun to play with