That's a phrase I heard for the first time when I became a manager; my boss would tell me I needed to "inspect what I expect." To be honest, I don't think I fully understood the phrase until a lot later. In the context of leadership, it means that if you have certain expectations for your team, you should actively verify that those expectations are being met and investigate the cause if they're not. Don't wait until eval season to say "You failed to meet expectations", instead, review expectations regularly, and if someone isn't meeting them, it's your job to figure out why. Have you defined the expectations in a way that they understand? Are your expectations realistic? Did you provide the resources they needed to meet the exceptions? Did you provide guidance when needed? And so on.

You might be asking: "Sure, but why is this on a blog about computers and stuff?"

Expectations

You might have the expectation that your network is secure. You don't remember adding any firewall rules or forwarding any ports, or maybe you followed some YouTube tutorial and they told you to proxy your incoming connections through Cloudflare. Maybe you set up a "deny all" line in that NGINX config or you only access your network through a VPN. You expect that your network is safe from outside actors.

To use a real world example, my father set up several Lorex brand CCTVs on his home network to save video to an NVR. He configured a VPN to allow secure remote access to the NVR and assumed that everything was safe. He didn't create any firewall rules or port forwarding to allow access by anything other than the VPN. He expected that this was safe, and in theory, it should have been.

Inspection

We traveled together for a holiday and while drinking coffee one morning, I showed him Censys. Censys is search engine, but unlike Google or Bing, which search for webpages, Censys searches for the actual devices. It indexes the IP addresses of everything on the internet and everything about them. You can write queries to search this index for almost anything you can think of.

For a quick demonstration, I just searched for his home IP address, and we were both surprised when we saw the results:


Umm... What?

For those who might not know RTSP stands for Real-Time Streaming Protocol. It is a protocol designed to stream video over a network, commonly used for CCTV cameras. The HTTP port was the HTML login screen for one of his cameras. We clicked it and I sarcastically tried a default login (admin, admin) and we found ourselves staring at his basement.
As far as he knew, he took all the appropriate steps to secure the devices on his network and expected that nothing was unsafely exposed, but he hadn't inspected that expectation. We found that the camera was factory configured to expose itself via uPnP, a technology which allows devices to request changes to port-forwarding and firewall rules without user involvement. This is supposed to allow for easy set-up by inexperienced users, but it can also create significantly compromise security without the use knowing about it. In our case, my father is not an inexperienced user, he's been a computer engineer since the 80s and has even worked for one of the major producers of networking equipment. He took all the right steps to get his expected result, he just hadn't inspected it ensure that his expectation was being met.

Inspect What You Expect

Censys can be a great starting point when evaluating your network by helping you to understand what you have exposed to the internet. Censys queries can be as simple as an IP address if you just want to see a single point, or they can search broadly for very specific things.

Here are the results of a very simple query looking for exposed FTP servers based out of japan:


There's a lot of FTP servers, obviously, but did you notice that SSH server on port 10022? Some people expect that services will be hidden if they run them on non-standard ports, but don't inspect to see if that's actually the case. Here, we can see that the SSH server is still quite visible, despite being on a non-standard port, just like those non-standard HTTP servers on the other entries. Clicking into an entry will provide even more information, like the software versions, request responses, and so on.

Through Censys, I realized that I was running an older version of Nginx than I thought I was, and that this older version had a number of vulnerabilities that were patched in later versions. I expected that I was running the a current version, but my inspection showed me otherwise.

Final thoughts

While a tool like Censys isn't the only tool you should use to inspect your security expectations, it's a great starting point, since it can show you what your network looks like to the internet. t's also a fun tool to use to explore the internet from a different angle. Instead of just searching the surface of the web for youtube videos and news stories, try searching deeper for Roombas, smart lights, or security cameras.

The important takeaway, though, is that just because you think that something is working how you expect it to, doesn't always mean that it is.
The only way to know for sure is to inspect what you expect.

What is it?

The Lynx Browser (not to be confused with the later Links Browser), is the oldest actively maintained web browser, initially developed in 1992 and still being maintained today. What makes lynx look a bit different from other modern browsers is the fact that even in 2025, it can only display basic text. The lynx browser ignores all of the ads, pictures, JavaScript, fancy formatting, and annoying infinitely-scrolling slop, to just delivery the content you want to read. Not only does this reduce distractions, but it's also great to use if your internet connection has limited bandwidth.

Using lynx

Lynx is included in the repos of most Linux distributions, so installing it is just a matter of running install lynx via your favorite package manager. Lynx runs in the terminal emulator, and can be started by the command lynx or you can directly open a specific website with lynx {website you want}.

Here's an example of Google.com:

And here's Wikipedia:

The formatting has obviously changed quite a bit, but all of the content is still there. This makes lynx great for sites where you just want to be able to read the content quickly, without distractions. Lynx also supports the gopher protocol, and since gopher is a text-based service to begin with, browsing the gopherspace from lynx feels completely natural.

Super Dimensional Fortress's User's Gophersites:

Pitfalls

There are, however, a few downsides to accessing the modern W3 through a text-only browser. The things that many of us would like to avoid (ads, JavaScript, endlessly scrolling slop, etc) have been so deeply entrenched in some sites that the they simply can't function without it. You might think that this could be a great way to revisit pages that you used to enjoy, like Facebook, but here's how the modern Facebook (even m.facebook) looks on Lynx:

In fact, even some some simple websites might not display well in lynx built if they're built with certain older formatting tools, like frames. Here's my own website as an example. It's worth noting, though, that while my site doesn't look correct without displaying frames, it can still be fully navigated by using the FRAME: links at the top:

Thoughts

So, while lynx is unlikely to fully replace your graphical browser on the modern web, it's still surprisingly useful for focused reading, navigating gopherspace, and for situations with limited bandwidth. Installing lynx is simple and the entire browser is only 6 MiB in size, so it's a great tool to have on your system.

While trying to write the script mentioned in a prior post, I decided that I would use an XML parsing module of some sort rather than writing my own.  A quick google search turned up a number options, but I wasn't quite sure which would be best for my use-case.  I knew that I wanted to specifically read RSS feeds, so using a general purpose XML parser was probably overkill if there was a more RSS-focused option available. I found several RSS-focused modules to choose from, including XML::RSSLite; which sounded promising as a light-weight RSS-specific module. 

The documentation was rather sparse, though, and I thought I might get a better idea of how to use it if I could see some examples. When a google search didn't turn up much in the way of results, I decided I would just ask an AI to create an example for me.

In its example, it makes this call:

my $rss = XML::RSSlite->new();

...Which might look reasonable on the surface, but it didn't actually work. Now, instead of understanding how the module works by reviewing a working example, I get to learn by trying to troubleshoot something else's broken code. After actually checking the documentation, it seems that "XML::RSSlite" isn't an object and the module never uses a "new" method.   After I pointed this out, the AI gave it another go:

my $rss = XML::RSSlite->parse_url($feed_url);

Closer, I guess?  It still doesn't work, though, because it's still trying to call on objects and functions that don't exist. I pointed that out again and let it try one more:

my $rss = XML::RSSlite->new();

Really?

Despite trying to prompt it into a correct answer, it kept admitting that each answer was wrong and then produced the same incorrect code again and again.

For reference, here's how the module is intended to be used:

use XML::RSSLite;
parseRSS(\%result, \$content);

This blog is also available via gopher! And here's how:

Gophernicus

As I mentioned in my previous post, my gopher server of choice is Gophernicus. One of the benefits of Gophernicus is that it will automatically generate gophermaps based on the files in it finds in a directory. This means that adding entries is as simple as dropping a file into the directory. The next time that server is accessed, the new file will appear automatically.

Mirroring

All that remains is finding a way to easily add files to the gopher directory. Since I already have this blog, I decided the first thing I wanted to do was to mirror these posts into the gopherspace. This blog uses Dotclear, which provides a plugin to access an RSS feed for the blog. By fetching (and then parsing) this feed, I can export the contents into text files accessible to gopher. I wrote a perl script to accomplish this and created systemd units to execute that script on a recurring schedule to pull in new entries. The full source code is available on my github. The script uses LWP:Protocol:https to fetch the RSS feed and XML::Feed to extract the title, date, and body of each entry. The date and title are used as the file name, and the body is reduced down to plain text and then written to the file.

If you'd like to use the script, it should, probably, maybe work with other RSS and ATOM feeds, but some feeds can be a bit loosey-goosey about how they handle their XML, so no guarantees.

Background

After setting up my home server, I found that I wanted a way to securely access and manage my system when I was away from home. I could have opened the SSH port to the internet, but the idea of having such a well-known port exposed to the internet made me wary not only of attempts to gain unauthorized access, but even just simple DOS attacks. I decided the far better option was to use a VPN, specifically, Wireguard.

Wireguard is a simple, lightweight VPN, with clients for Linux, Android, Windows, and a handful of other operating systems. In addition to the security offered by its encrypted VPN tunnel, Wireguard is also a "quiet" service; that is, the application will entirely ignore all attempts to communicate with it unless the correct encryption key is used. This means that common intelligence gathering tactics, such as port scans, won't reveal the existence of the VPN. From the perspective of an attacker, the port being used by Wireguard appears to be closed. This can help prevent attacks, including DOS, because an attacker simply won't know that there's anything there to attack.

Now, when I set about trying to install and configure Wireguard, I found that many of the online guides were either overly complex, or so incredibly simple that they only provided a list of commands to run without ever explaining what those commands did. The overly complex explanation turned out to be too confusing for me, but on the other hand, I'm also not someone to run random commands on my system without understanding what they do. I did eventually figure it out, though, so I thought I'd try writing my own explanation to hopefully offer others a middle ground.

Introduction

Wireguard uses public key encryption to create a secure tunnel between two "peer" machines at the network layer. It's free, open source software, and is designed to be simple to use while still providing a minimum attack surface.

In essence, wireguard creates a new ipv4 network over an existing network. On a device running wireguard, the wireguard network simply appears to be an additional network interface with a new IP address. On a typical laptop, for example, one might have several network interfaces, like lo, eth0 and wlan0, with an additional interface for wireguard appearing as wg0.

Installation

Installing Wireguard is typically done through your package manager, i.e. apt, dnf, pacman, etc, or optionally installed via a container package, via podman, flatpack, snap, appimage, or docker.

For example, apt install wireguard-tools. Depending on your system setup, you may need to preface this and some of the other commands in this walkthrough with the word "sudo".

Configuration

Once installed, wireguard will need to be configured. Wireguard considers devices to be peers, rather than using a client/server relationship. That means that there is no "primary" device that others connect to, rather, they can all connect to each other, just like a typical LAN. That said, for the sake of explanation, it is sometimes easier understand if we use the server/client labels, despite the devices not technically functioning in that relationship. In other words, I'm going to say "server" and "client" because I find it less confusing than saying "peer A" and "peer B".

We'll start on the "server" (aka. Peer A, not technically a server, yada yada) by running wg genkey | tee private.key | wg pubkey > public.key.
wg genkey produces a random "Private key", which will be used by the peer to decrypt the packets it receives. tee is a basic linux command that sends the output of one command to two destinations (like a T shaped pipe). In this case, it is writing the private key to a file called "private.key" and also sending the same data to the next command wg pubkey. This command creates a "public key" based on the "private key" it was given. Lastly, > is writing the output of wg pubkey to the file public.key. After running that command, we now have two files: private.key and public.key.

We can view the actual key by running cat private.key or cat public.key.

We'll repeat those same steps on the "client".

Next, let's decide what IP network address we want to use for the wireguard network. Remember that this needs to be different from your normal local network. There are several different network ranges available, but the most common is 192.168.1.0/24. Those first three "octets", 192, 168, and 1 define the network in this IP address, while the last one defines the device's address within that network. So, what's important here is that if your primary network is 192.168.1.0/24, that we assign the wireguard network a different address, like 192.168.2.0/24. By changing that 1 to a 2, we're addressing an entirely different network.

Now, we'll create the configuration files themselves. On the server, we'll create a configuration file by using a text editor, such as nano. nano /etc/wireguard/wg0.conf will create a file called wg0.conf and open it for editing. The name of this configuration will be the name of the network interface. It doesn't need to be wg0, but that's a simple, easy to remember option.

Here is an example configuration file for the server:

[Interface]
PrivateKey = (Your server's private key here)
Address = 192.168.2.10/24  
ListenPort = 51820

[Peer]
PublicKey = (Client's public key here)
AllowedIPs = 192.168.2.0/24
Endpoint = (see below)

PrivateKey is one that we generated on this server.

Address is the IP address that we're assigning to this server on the wireguard interface. This is our wireguard network address.

ListenPort is the "port" that wireguard is going to "listen" to. If you're not familiar with ports, think of it this way: an IP address is used to address packets to a specific device, and a port number is how you address those packets to a specific application on that device. In this case, Wireguard will be "listening" for packets that come in addressed to port number 51820. That number is somewhat arbitrary, but for uniformity, certain applications tend to use certain port numbers and 51820 is typical for wireguard.

The [Peer] section defines the other system/s on the network, in this case, our "client" system.

PublicKey is the public key created on the client device.

AllowedIPs tells wireguard which IP address it should forward to this peer. Here, we're telling it that any packets addressed to the 192.168.2.0/24 network should be forwarded out to this peer (our client system).

Endpoint is how we reach this peer. Because wireguard creates a network on top of an existing network, we need to tell wireguard how to get to the peer on the existing network before it can use the wireguard network. If you're connecting two devices on your LAN, we would just enter the normal IP address of the peer, such as 192.168.1.123. If you're connecting to another device over the internet, you will need to have a way to address packets to that device, such as a public IP address or a domain name. This will be specific to your network situation. Following the IP or domain name is a colon and the port number. For this example we'll assume the other machine is on your LAN at address 192.168.1.123 so we can just enter the IP address and the port number, like so: 192.168.1.123:51820. Lastly, save the file.

We'll then reverse this process on the 'client', assigning it a different IP address on the same network, such as 192.168.2.10/24 and using the clients PrivateKey and the server's Public Key. Once we've completed the configuration files on both device, we can use the command wg-quick up wg0, telling wireguard to start (bring up) the wg0 interface we just configured.

Final Notes

It should be noted that the "Endpoint" setting is only required on one of the two peers. This can be useful if you want to use wireguard while you're away from your home. My "server" at home may keep the same public IP all the time, but my portable laptop will have a different public IP address every time I move to a new network. In this case, I would remove the "endpoint" setting entirely from the configuration file on the server, and only use that setting on the laptop. Remember, the one system needs to be able to connect to the other system over an existing network before wireguard can create the VPN connection between them. Most of the issues a user might encounter while trying to set up wireguard isn't actually related to wireguard itself, but rather the underlying network. Firewalls and Network Address Translation (NAT) are the most common causes of problems, but the steps to address these issues will vary significantly depending on your network situation.

It recently occurred to me that as I update each Linux container or VM, I'm downloading a lot of the same files over and over again.  While the downloads aren't huge, it still seems wasteful to request the same files from the repo mirrors so many times... So why not just download the update once and then distribute it locally to each of my systems?  

That's the purpose of a caching proxy.

I chose apt-cacher ng as it's very simple to setup and use, so I spun up a dedicated LXC and installed apt-cacher ng via apt. Once it was up and running, it was just a matter of following the included documentation to point all of my other systems to that cache.

After upgrading just a couple of systems, I can already see the cache doing it's job:

Those "hits" are requests that were able to be fulfilled locally from the cache instead of needing to download  the files from the repo again. Since this is caching every request, it actually becomes more efficient the more that it's used, so hopefully the efficiency will increase even more over time.

So what exactly is happening?

First, this is not a full mirror of the Debian repos. Rather, apt-cacher ng acts as a proxy and cache. When a local client system wants to perform an update, it requests the updated packages from apt-cacher instead of the Debian repo directly. If the updated package is available in apt-cacher's local cache already, it simply provides the package to the requesting client. If the package is not in the local cache, then the proxy requests the package from the repo, provides that package to the client, and then saves a copy of the package to the cache. Now it has a local copy in case another system requests the same package again.

Some packages, like Crowdsec, are only installed on a single machine on my network, so the cache won't provide a benefit there. However, since most of my systems are all running Debian, even through they may be running some different services,  they will still all request a lot of the same packages as each other every time they update, like openssh or Python.  These will only have to be downloaded the very first time they're requested, and all of the subsequent requests can be filled from the proxy's local cache.

Do you use a cache in your homelab? Let me know below!

Ah, Cities Skylines 2:

I recently got back into Cities Skylines 2 after leaving the game for a while due to the release of PDX Mods essentially breaking all of the mods I had been using via r2modman at the time.

Now  that some time has passed, I decided to give it another go. I was quite interested to see that the Skyve mod manager has now come to C:S2, meaning that I didn't actually have to directly interact with PDX mods and could use a proper mod manager instead. Installing Skyve is supposed to be a two-step process, first you install the Skyve "mod", which is essentially just an installer, then you use that installer to install the actual Skyve program. Once installed, Skyve is a free-standing application that interacts with the C:S2 data without requiring steam or C:S2 to be running at the time. Not only can Skyve install and uninstall mods without needing to launch C:S2, but it also alerts you when other users have flagged a mod as broken or incompatible with another mod you have installed. 

Unfortunately, while C:S2 runs beautifully on Linux without any additional configuration (likely better than it does on Windows), Skyve was a different story. Skyve requires the Microsoft dotnet framework and doesn't appear compatible the opensource alternative Mono, which is commonly what would be used on Linux. It took a bit of trial and error to get Skyve running, so I thought I would share the process which ultimately worked for me:

The first step is simply installing the Skyve "mod" via PDX Mods. After installing the Skyve mod and restarting C:S2 twice, the "Install Skyve" button appeared in the menu as it was supposed to and clicking on it did bring up an installer interface. The installer appeared to run, but ended with an error message.  I switched from Proton Experimental to Proton GE 9.20, using ProtonUP to download and active the new Proton version. ProtonUp isn't needed, but it does make the process very simple.

After switching, the installer ran without any errors, but Skyve itself would not start.

Next, I used ProtonTricks to install the .Net 4.8 framework:

Open ProtonTricks and select the game:

Then select the "default" Wine prefix:

Then install component:

Then select .Net 4.8 (other 4.x versions might work):

That installed .Net, but when I tried to launch Skyve, I received an error about the .Net "RootInstall" registry not being found, so my next step was to install that:

In ProtonTricks, select "Run regedit"

Once in regedit, I navigated to

HKEY_LOCAL_MACHINE/Software/Microsoft/.NETFramework

There, I created the missing registry key, pointing to the .Net framework path:

Finally, my last step was to run Skyve.
I ran the binary via ProtonTricks' application launcher, which ensures that the program is run in the correct prefix. Skyve started and immediately recognized the C:S2 install and correctly listed all of my current mods and even suggested a few I should remove. After confirming that I wanted to remove the mod, I booted up C:S2 and found that the mod had been successfully removed. I tried installing a new mod as well, and that worked exactly as intended.

Hopefully this might be helpful to someone else who finds themselves struggling to get Skyve running.

Thanks for reading!

So, while surfing the web and reading up on how I wanted to configure my new BananaPi R3, I encountered a sudden issue with my network connection:

It seemed like I could reach the internet, but I suddenly lost access to my home network services. I tried to SSH into my webserver and was met with a "Permission denied" error.  Since I had earlier attached an additional USB NIC to connect to the BPI, I thought that perhaps the laptop had gotten the interfaces confused and was no longer tagging packets with the correct VLAN ID for my home network. Most of my servers are configured to refuse any requests that don't come from the management VLAN, so this explanation made sense. After poking around in the network settings, all of the VLAN settings appeared correct, but I did notice that the link was negotiated at 100 mbs, instead of the usual 1000. I tired to reconfigure my network settings, manually setting the link to 1000 mbs, resetting interfaces, changing network priorities, etc.  I then tired the classic "reboot and pray" technique, only to find that my wired network connect was down entirely. I wasn't receiving an IP from the DHCP server and the laptop kept reporting that the interface was UP, then DOWN, then UP again, then DOWN again.

Now I started to think that perhaps the issue was hardware related. My usual NIC is built into the laptop's dock, so I thought I would try power cycling the dock itself. This didn't seem to have any effect, besides screwing up my monitors placement and orientation. My next thought was that there might be an issue with the patch cable. "Fast Ethernet" (100mbs) can theoretically function on a damaged cable, so that might explain the lower link speed, and if the damage is causing an intermittent issue, that could also explain the up/down/up/down behavior.  

Being the smart homelabber that I am, I disconnected both sides of the cable and connected my ethernet cable tester. All 8 wires showed proper continuity, though, suggesting that the cable was fine.  When I plugged the cable back in, however, I noticed that I was suddenly getting the normal 1gbe again, but the link was still going up and down. This lead me to the conclusion that the cable likely was the issue, despite it passing the cable test.  I tried replacing the cable entirely with a different one, and found that I now had a stable, 1gbe connection, an IP addresses, and I could now access my network like usual.

Looking back, I think replacing the cable should have been troubleshooting step 1 or 2.

Also, in retrospect, there were some clues that might have let me fix the issue before this point, if I had only put the pieces together. I had noticed another day that the link speed had dropped to 100mbs, but it seemed to correct itself, so I ignored it instead of investigating. While working, I found that Zoom and other applications had started to report my internet connection as "unstable" and that a "speedtest" showed that my internet bandwidth to be drastically lower than it used to be. I assumed this was due to my ISP just being unreliable, since reduced speeds and entire outages are not unusual where I live. 

In hindsight, I think these were all indications that there was a level 1 issue in my network. In the future, I'll have to remember to not over-think things, and maybe just try the simplest solutions first.

I've been using a consumer router from from 2016 (with OpenWRT hacked onto it) all the way here in 2024, and felt that it might finally be time for an upgrade. I settled on a BananaPi R3 because it was a reasonable price and seemed like it would be a fun project.

Here's the bare board as received:

You can see most of the physical features in this photo, including a USB3 port, two SFP ports, 5 RJ45 ports, an m.2 slot for a cellular modem, and a 26-pin GPIO header. On the bottom, there's also a m.2 slot intended for nvme storage, as well as slots for a micro SD and a micro SIM.  The CPU is a quad-core ARM chip paired with 2gb of RAM, and there's a handful of flash chips, providing NAND, NOR and eMMC.   Quite a lot of options!

My plan is to install OpenWRT to the NAND storage. I suspect the nvme might be useful if I wanted to run a small file server or something, but that's not in the plan for now.

The first step I took in assembly was to apply some thermal pads to the chips and then attach a cooler and fan.

The thermal pads are "OwlTree" brand, but I don't have any specific preference to them, I just happen to already have them on-hand from a previous project. The CPU is a 0.5mm pad applied, and I applied 1.5mm pads to the remaining chips.

After applying  pads to all of the chips, I attached the cooler and plugged in the fan.

The next step was to install the board into the case. I went with the official BPI-R3 case. The quality is surprisingly nice and looks great once assembled. After installing the board I then installed the pigtails for the eight (yes, eight) antennas and applied some basic cable management.

Now, I can't finish putting the case together quite yet, since I'll need access to the UART pins to install Openwrt to the NAND flash. The  UART header can be seen on the right side of this photo, but there is no way to access it once the case is assembled.

But, that's enough for today. I'll post an update once I make some progress towards getting OpenWRT flashed.