CQ / Hello World…

A quick introduction: by day, I'm a DevOps Engineer at Red Gate, a software company in Cambridge, UK. Outside of work, I enjoy both amateur radio (hence the callsign, M0VFC) and community broadcast radio at Cambridge 105. This blog aims to span all those interests - so feel free to ignore the posts that aren't relevant!

Feel free to get in touch on Twitter (@rmc47).

73 / Best wishes,
Rob

---

---

SOTA Kit

My first Summits on the Air (SOTA) activation was, apparently, 31st December 2007. It involved a 10m telescopic aluminium mast, 40Ah car battery and Icom IC-7000 lugged to the trig point on Detling Hill. Fine for a small summit like that, but entirely impractical for more challenging hills.

Since then, I've refined the equipment I carry. It's not as minimal as some folks, but it's working well for me at the moment:

The key bits are:

• Ordnance Survey map in waterproof map case. I pretty much never walk without one, even on "obvious" summits. I'd prefer to look a bit silly carrying a map than lost in the fog without one.
• Map compass, for the same reason.
• Bungee cords. Very handy for securing fibreglass poles to trig points, fences, or other convenient supports.
• Iridium Go satellite modem. Sends position beacons to APRS while I'm walking, and lets me send spots even if there's no mobile phone coverage. Also helpful for booking dinner at the pub when you're a bit later than you thought you would be.
• Snack bars.
• Waterproof log book.
• Kenwood TH-D72 hand-held and earpiece for V/UHF FM.
• 3-ele 2m fold-up yagi. Very quick to deploy and a useful improvement over the hand-held's own antenna.
• 2.2Ah 3S (11.1V) LiPo battery. More than enough capacity to run the KX3 for a couple of summits. A normal activation might consume 2-300mAh.
• 30m dipole, complete with RG-174 feeder and pegs, all wound on to a single winder.
• Garmin eTrex GPS and spare batteries. Like the map, I'd prefer to carry one and not need it than wish I had it. Also handy for track logging.
• Head torch, even if I don't expect to still be out in the dark.
• Pencils for logging.
• Electrical tape. Good for field repairs.
• Guying set - ring, string and pegs, all on a winder. I use 2mm Mastrant cord.
• Elecraft KX3, for HF.
• Headset for KX3.
• Palm Paddle for CW.
• Not shown: 10m DXWire short fibreglass pole.

All of the above packs into the blue rucksack, which also contains a CamelBack water pack. Including water, it weighs around 8.5kg.

Getting started with IPv6 in Amazon EC2

IPv6 has been around for many years, but until recently, support was lacking from a lot of providers, including the major public cloud players. Amazon launched it in one of their US regions at the back end of 2016, and have now rolled it out across all their regions.

I assume they may have enabled it by default in new accounts, but if you already have infrastructure, you'll need to turn it on in a few places:

1. On your VPC itself, use Edit CIDRs to allocate a /56 IPv6 subnet to the VPC as a whole.
2. On each of your subnets, Edit IPv6 CIDRs to allocate a /64 to the subnet.
3. On your route table, add a global route (::/0) via your internet gateway. If you currently use the default route table, you'll need to create a new one and associate your subnets with it.
4. For each of your security groups, define the behaviour you want for IPv6 connections. For IPv4 access control entries previously specified as 0.0.0.0/0, you'll want to append , ::/0 to allow equivalent connections over IPv6.
5. You may want to change the subnets to automatically assign an IPv6 address to newly-created interfaces. This is under Modify auto-assign IP settings.

You can assign an IPv6 address to an existing instance by using Networking -> Manage IP Addresses.

I found that when creating a new Ubuntu 16.04 LTS instance from the current template (as of 2017-02-01), the network interface doesn't acquire an IPv6 address even if the EC2 console shows it having one. I fixed this by creating /etc/network/interfaces.d/60-ip6.cfg with a single line, iface eth0 inet6 dhcp to enable DHCPv6. The current Amazon Linux AMI works straight out of the box.

With that, you should be able to start using IPv6:

It's worth noting (thanks @jen20 for the reminder) that anything with an IPv6 address is publicly addressible - you can no longer hide behind NAT as a security feature. If you want an instance to be internally-routable only, then check out Egress-only internet gateways.

Windows Nano Server

With the release of Windows Server 2016, there's a new version to play with: Nano Server.

Nano Server is a very lightweight, low surface-area server with no console access at all. It uses less disk space, less memory, and because there's less stuff in the box, there's fewer reboots for updates.

The flip side of this is that it doesn't do so much: there's no local console, not even the limited one you get with Server Core, and a bunch of other tools are missing - msiexec, for example. That means it's very much not for every workload. But I had something I thought would be suitable: a simple scheduled task running a .NET application.

To create a new Nano machine, a quick way of getting started is the Nano Server Image Builder. This is a friendly front-end to the PowerShell commands, and a good way of experimenting when you're first starting out. You'll need:

• Nano Server Image Builder, from the link above
• Server 2016 install media (the same ISO as the full-fat version), extracted or mounted
• Windows ADK (Assessment and Deployment Kit)

I installed the above directly on my (Windows 10) desktop PC; you might want to do them in a dedicated VM.

The image builder is mostly self-explanatory, but I tripped up a couple of times:

• You really want to domain join your Nano VM. It's a lot easier to do stuff to it if you do.
• If you do domain join it, create the computer account in AD first in AD Users & Computers, before running the image builder, or it will fail!
• If you're running the target Nano VM in VMWare Workstation, continue to the advanced configuration section, and under Servicing packages, add Microsoft-NanoServer-OEM-Drivers-Package.cab from the installation media, or you'll get a BSOD when the VM starts. I assume this doesn't apply if you're running it as a Hyper-V guest.

Having created the image and booted it, you're left at a basic login screen. There's not a lot you can do except enable and disable existing firewall rules - handy for turning on the ICMP Echo Request rule so it responds to pings!

So, how to actually use the new VM? Remote PowerShell, basically.

For interactive use, you can use New-PSSession -ComputerName foo then Enter-PSSession to get a remote console on the Nano VM on your desktop:

So far so good. But how to actually get code on there? We use Octopus Deploy for a lot of our application deployments, and it's great. Unfortunately, the agents (known as Tentacles) are .msi packages. Normally, that's a great thing, but with Nano there's no msiexec.

A bit of manual file copying later, and I realised the real blocker for my application: Nano is CoreCLR only - not the full .NET Framework. It's also 64-bit only (no WOW64), though that didn't affect me in this case.

Never mind, back to Server Core for now!

---

---