Maybe not slighty...
Following on from setting up the basics of our router, here's how I add a second WAN connection via a 4G router, and use Andrews & Arnold's L2TP service to keep my public IPv4 and IPv6 networks available in the event of a failure of my fibre service.
You can simplify the configuration here to just use the 4G connection directly if you don't have an ISP that's quite so fancy. Let me know if you'd like me to write about that.
I use NixOS as a router for my FTTP ISP in the UK. The details in this post should apply to most PPPoE-delivered services.
In a later post I'll add 4G failover in a way that's more specific to my ISP, then add multiple VLANs and 1:1 NAT to make the most of the additional IPv4 addresses my ISP offers.
This started as a post about how I use NixOS to build a router, but the aside on AAISP was getting a little unwieldy. I'll get back to that post another time.
Earlier this year, Fibre To The Premises (FTTP) arrived in my street, and so I took the opportunity to end my 23 year relationship with Virgin Media (previously ntl), the UK's last cable operator standing, and jumped at the chance to switch to Andrews & Arnold (AAISP), probably the nerdiest generally available ISP in the country.
Here's a snapshot of the services I'm currently running for myself, and approximately how. Some will go, new ones will be added, but here we are for December 2024.
Many, if not all are strictly unnecessary, there are free/cheap hosted alternatives available, but there's something very satisfying about knowing these are sitting on a shelf in the cupboard in my office. Not least that for the most part, these services are incredibly responsive!
In the past I've run a lot of these things in a single-node Kubernetes cluster, mostly using Helm charts. NixOS modules have made things much simpler, whilst still allowing a declarative approach to managing most of these services.
I typically have /services/<service>/<subcomponent> directories on host machines, and have these mounted into the various containers and VMs as necessary to store state. This means the rest of the container/VM is usually ephemeral, and can be re-created at any time. Indeed, I've been able to migrate between machines very easily thanks to this. It also provides a gives me a single volume to back up from each host.
I recently got to grips with microvm.nix, so am starting to migrate things to VMs where that level of isolation feels appropriate.
One thing to be mindful of when using a single Nix expression to define a system composed of many containers/VMs is that nixos-rebuild is pretty expensive in CPU and RAM, taking around 2 minutes to make a simple change and using approaching 10Gb RAM on the machine that hosts the majority of the services below!
I've often heard code review spoken of as a chore, and have witnessed (and myself been guilty of) reviews that reflect this attitude. Cursory skims of the proposed changes, nitpicking small but obvious faults, rushing to get the review done to move on to matters more pressing.
But this attitude, or culture where it's pervasive, denies the reviewer a great opportunity to learn.
As someone a couple of decades in to my career, I've noticed that whilst I still get excited to learn a new tool, it can be easy to overlook how the tools I'm most comfortable and familiar with continue to evolve.
I've found myself learning new things about the tools I thought I knew best whilst reviewing the code of someone who's earlier in that journey and discovering all the features of those tools for the first time as they are today, and that's brilliant!
Code review is also a great opportunity to get some insight into how other folks think and solve problems. Doing my job well as a reviewer demands that I understand the problem being solved, and is often rewarded by discovering an approach or techniques I may never have considered.
Regardless of experience, we have so much to learn from each other. So make time for and give reverence to your code reviews. And if your organisation doesn't allow for that, that sucks! If you're able, find one that does.
After a few months of getting comfortable with NixOS as my desktop operating system, I decided it was time to try it out for servers. But first I wanted to write about the setup I had before.
Disclaimer: This post is likely full of bad ideas – you probably shouldn't setup anything you care about like this. It is my opinion that my most valuable learning is when I'm learning what not to do, and I know there are some gems lurking in here.
My home network is effectively in two segments, with the cable modem, router/server and access point wired together downstairs and another access point acting as a bridge, connected to a wired network in my office upstairs.
I'd been wanting to up my security game and split out dedicated networks (VLANs) and SSIDs for trusted devices, guests and untrusted IoT things for a while. One of the frustrating things about using Wi-Fi to bridge the two wired networks is that this typically precludes VLAN functionality.
I could just do things right and run a cable between the two wired islands, but my willingness to venture into technical escapades vastly exceeds my willingness to drill holes in walls and ceilings. And so, I spent a full day of my 2023 Christmas holiday messing around with OpenWrt.
Updated 2023-11-13 with Preview.app features, prompted by Neil's helpful response Desktop Linux: the software I'm currently using
With my new laptop coming in a few days, I'm finally thinking through the implications of moving away from macOS whilst still having an iPhone. These are some questions I need to answer:
I guess I'll find my answers in the coming weeks.
That whole writing more thing went well, didn't it? ?
Let's try a little brain dump of the nerdy things I've assigned myself to do:
I can't help think of Amelie's father and his toolbox.
I want to improve my writing, so I need to do more of it.
Improving means that I can communicate effectively, efficiently and engagingly. It means you can understand me, that I'm not wasting your time, and that I can hold your attention long enough to impart what I wanted you to know.
Part of my job as a software engineer is to express ideas in a way that is understandable by machines. More importantly, those ideas can be understood by other engineers who work with me now and in the future, whether I'm present or not. That is what good code means to me.
When I write for a machine I'm able to get feedback near instantly. Frequently that feedback is unambiguous. I was either successful in communicating my intent, or I was not. Code reviews help ensure I'm successfully communicating with other engineers too.
Much of my work is useful to people who shouldn't need to understand the details of it’s construction to find it helpful. I should be able to describe it in a way that respects their time and attention. Documentation matters.
Career progression requires I am able to communicate ideas in a way that places them in a wider context to demonstrate their value. I distill the ideas of multiple people and in doing so am representing them as well as myself.
I need to write to justify advancements, to mediate conflict, to convince others to invest their resources, to give candid feedback kindly, to explain failure, and to celebrate success.
I need to be able to do all of that in a timely manner that leaves room for all the other things to be done. Improving also means writing more quickly when that's necessary.
Success will be hard to measure here. Improvement needs feedback as well as practice. That's why I'm writing this publicly.
The most uncomfortable part is convincing myself that this is good enough, when I know that it could be better. If the only outcome is that getting easier, then this will be worthwhile.