Now that I’m handing out IPv6 addresses to various VLANs on my network, I needed a way to see what percentage of my traffic was actually using IPv6. Enter pf, pflow, and ntop. pf is used by my router/firewall to process packets, and mark them for pflow processing. pflow is a psuedo device on the router/fw which exports pflow accounting data to a remote collector. ntop (and nprobe) is a collector and visualization application for digging into packet statistics. Below is the configuration to hook it all up. pf.conf snippet: ...

It all started with a Ubuntu Blog blog post about a slimmer Ubuntu server image. I play around with virtual machines at home, many based on Ubuntu’s full-size server ISO. It would take 20-25 minutes to spin up a new VM using some prebuilt preseed files I had constructed to automate user creation and SSH key copying. I knew there was a better way, and it turns out, using the pre-built Ubuntu minimal image (subsequently called cloud image), combined with cloud-init infrastructure, I was able to spin up Ubuntu Cloud Image minimal VMs in under 2 minutes. ...

I remember using he.net year ago for their IPv6 tunnels years ago, and have painful memories of configuring it, both on the router and to share to the subnets on my home LAN. Not this time. Years ago, I had Comcast Business Internet service, which along with providing a static IPv4 address, provided IPv6 connectivity. Not only just a single /128, but a whole /56 if you asked for it. After spending days/weeks configuring both dhcp client and servers for prefix delegation, and slaac/rtadvd to hand out addresses to my various LAN segments, I was in business. Flash forward to 2018, and I’m on a residential Verizon Fios connection, which provides a single dynamic IPv4 address, and no IPv6. Really, no IPv6 connectivity in 2018. Not here. Or here. Or here. Not here either. Your only option is to check out one of the IPv6 tunnel providers out there to wrap your IPv6 in IPv4 and go that direction. ...

Kubernetes has some incredible features, one of them being Ingress. Ingress can be described as a way to give external access to a Kubernetes-run service, typically over HTTP(S). This is useful when you run webapps (Grafana, Binder) in your Kubernetes cluster that need to be accessed by users across your network. Typically, Ingress integrates with automation provided by public cloud providers like GCP/GKE, AWS, Azure, Digital Ocean, etc where the external IP and routing is done for you. I’ve found bare-metal Ingress configuration examples on the web to be hand-wavy at best. So what happens when there are so many standards, but not sure which one to pick? You make your own. Below is how I configured my bare-metal Ingress on my CoreOS-based Kubernetes cluster to access Grafana. ...

Several months after my last post, and lots of code hacking, I can rebuild CoreOS-based bare-metal Kubernetes cluster in roughly 20 minutes. It only took ~1300 lines of Python following Kelsey Hightower’s Kubernetes the Hard Way instructions. Why? The challenge. But really, why? I like to hack on code at home, and spinning up a new VM for another Django or Golang app was pretty heavyweight, when all I needed was an easy way to push it out via container. And with various open source projects out on the web providing easy ways to run their code, running my own Kubernetes cluster seemed like a no-brainer. From github/jforman/virthelper: First we need a fleet of Kubernetes VM’s. This script builds 3 controllers (corea-controller{0,1,2}.domain.obfuscated.net) with static IPs starting at 10.10.0.125 to .127, and 5 worker nodes (corea-worker{0,1,2,4,5}.domain.obfuscated.net) beginning at 10.10.0.110. These VMs use CoreOS’s beta channel, each with 2GB of RAM and 50GB of Disk. ...