In the second post in my portable networking blog’s history, I talked about the WB4HRO Digital Repeater System I was managing at the time. This was my first “real” sysadmin experience, if I’m honest. It also taught me a lot about networking and the state of servers as it went along.
This all started in late 2008 as plans were made to use our club callsign and set D-STAR 70cm voice, 23cm voice, and 23cm data repeaters up at the store and take them to hamfests to set up in our booth. Once we got the frequency coordination taken care of, it was just a matter of waiting for the controller, repeaters, and the gateway server to show up. I’d elected to go with a 2U server because it would be quieter than a 1U but not by much. We had a couple of servers from the company in that room, so the additional noise was bearable. The gateway server ran on CentOS, so this was proper sysadmin stuff. I had to teach my manager how to use SSH and even located a decent SSH client for iOS. This system came online in January 2009, roughly 17 years ago.
Eventually, this first server was swapped out with a different one as we had to use the original one as a “temporary” loaner for another repeater site. This actually worked out for us eventually as it was a dual CPU machine, so a lot more powerful overall, and we eventually loaded it up with a whopping 32GB of RAM, I think, as needs eventually needed to be expanded.
This got used on the road a lot for a few years at hamfests, and many people got interested in D-STAR because of this. It was pretty cool to see something I had set up be used to push adoption of an exciting mode I had known about since around 2002. To this date I say my greatest claim to fame in ham radio is being indirectly responsible for the growth of D-STAR in the Southeast US. Once other hardware had come along and D-STAR repeaters had been deployed around the region, we stopped taking the repeater stack on the road. It’s a good thing we did that, as something was in the pipeline.
A few years later, a different manufacturer had developed their own digital voice system, and instead of using Linux for its equivalent Internet connectivity, it needed Windows. This is why we loaded the machine up with RAM, as I used PAE in the 32-bit CentOS we were running to allow VirtualBox to be used. It worked, but audio quality was absolute garbage, so I tried Proxmox, of all things, by first P2Ving the D-STAR gateway, then setting up a fresh Windows, but this had some issues with USB ports, so I ultimately used a Windows Server 2012 R2 license I had, installed the Hyper-V role so D-STAR would live on, and this became the machine for the other mode, which was System Fusion.
This actually worked out extremely well. I was able to load the D-STAR repeater controller software on the Windows server, so if I needed to use this I could. Also having the gateway server virtualized, as all of its communications uses standard Ethernet and TCP/IP, made my life incredibly easy a few years later. This was my first real exposure to “modern” virtualization and what an intro it was. Soon after this I started using virtualization in my homelab, which I’ve talked about on this blog a bit in the past.
In early 2017, a new version of the D-STAR Gateway software was released, and Icom, the manufacturer, stressed that it was best to do a brand new server. Well, being virtualized this was absolute cake. I created a new virtual disk, downloaded the appropriate ISO, which was CentOS 6 64-bit, I believe, ran the initial migration steps on the existing VM, exported them, then powered it down, changed the attached virtual disk, and ran the installer for the new OS.
Once the new OS booted up fully, I installed the new software and imported the existing settings and we were online completely painlessly. Virtualization allowed this.
Somewhere along these years I had decided to unify the “extra” networks we had running at the store, so I brought a spare machine from home, threw pfSense on it, bought a small managed switch from MikroTik, and a Ubiquiti UniFi AP. I stood a UniFi Controller VM up, and set up the employee-use-only network, the gateway server’s network, and a public network. I set the public network to have a schedule to be usable only during the store’s public opening hours.
It took time, but this eventually lead me to the company I currently work for, though in a different role than my current.
Would I do this again given the choice? Absolutely. Sure this was a relatively simple system, but it was one I was tasked with administering, so I did to the best of my ability. This included writing a collection of scripts that I ultimately combined into a single C++ program to more simply manage the repeater’s links.
While this is story started nearly two decades ago and ended nearly a decade ago at this point, it’s still something I look back on with pride.
I’ll write something about recent happenings with me and ham radio in a future post.
Until next time!