I’m always messing around with Virtual Private Networks (VPN). I can’t quite bring myself to use the internet without VPN protection; my world-view just doesn’t acknowledge that un-encrypted internet traffic should exist. But, as someone recently stated, “deal with the world as it is, not how you want it to be, so I run a VPN 100% of the time from all my devices. Let me assure you, that level of VPNess can be a pain to maintain, so I am always looking for more reliable and cheaper ways to keep that VPN running all the time.

Unlike many people, I don’t use a VPN to access geo-restricted content – AKA, “the Netflix reason”. I use a VPN for a two different reasons:

1. To ensure my internet traffic is encrypted even when I am using services or sites that do not provide encryption natively,.

2. To deny my ISP and their “partners” access to my internet traffic.

image courtesy of Slack

My company recently moved from Slack to Microsoft Teams as our core communications tool. It was inevitable, really. Slack pissed Microsoft off 4 years ago with its silly full-page ad in the New York Times and that decision has come back to haunt Slack. When you poke the sleeping dragon, the dragon responds by giving its competing product away to its BILLIONS of users for free. Goodbye Slack, that was dumb.

Pushing the business case aside, as a technical Slack user working remotely for a tech company, I’ve really felt the burn. Microsoft Teams is orders of magnitude less capable than Slack. Some of that inferiority is simply because Teams is feature-poor compared to Slack, but some of it is just plain old Microsoft incompetence in its inability to fix bugs that have existed in its chat clients for years.

I’ve been playing with Expect lately. Expect is an extension of the TCL scripting language developed in the 1990s. Its main purpose in life is to automate terminal interactions and it does that job very well.

I spend most of my day in a shell and automate as much as humanly possible so that I can be as lazy as humanly possible. Using tools like ssh and scp it’s very easy to automate simple commands and simple file transfers. But when these tasks become complex enough that they need to respond to terminal prompts, or provide arbitrary changing input, those tools fall apart.

My particular use case was a need to grep through logs on multiple Linux servers. This would be a trivial task to achieve using plain old ssh except for the fact that I use a Yubi key to log on to the servers. I need to interactively provide the PIN for my Yubi at each login. The same problem exists for encrypted public keys. For a while I just copied the PIN and pasted it at every prompt, but that became a pain pretty quickly so I started casting around for other options.

Regular Death by Tech readers know that I just took a week off for some R & R. I always feel physically great after a week off. All my little aches and pains from work are gone, and I’m ready to get back into it. For the most part, my work-related strains and injuries are pretty minor. I work from home and because of that, I have a great deal of flexibility in my work environment which helps keep these work injuries at bay. But it got me to thinking: why do we live in a world where work-place repetitive stress injuries are even a thing? We should be past that by now.

Repetitive Stress Injuries (RSIs) were almost unheard of until the 20th century. I am sure some repetitive tasks caused them, but work wasn’t the all-consuming thing it is now and we did not have entire clinics and organizational units devoted to keeping us perpetually in that state of almost pain that our work lives create. People had more active lives before cars and computers shrunk the world. They had a thing called balance before we started cramming everyone into cubicles and rewarding those who worked longer than necessary hours. RSIs are created by the crappy work life that most of us have to endure in much the same way gyms are a self-licking ice cream cone. If we had healthy lives, we would not need gyms. If we have healthy lives, we would not get injuries from doing silly things like pushing a mouse back and forth all day.

My particular injuries are usually novel – I don’t normally get the exact same RSI repeatedly, but there are general categories that my injuries fall into. Eyes, arms, back and sometimes feet. OK, ok…that is pretty much my whole body.

image courtesy of Arista

There are some things in a sysadmin’s life that simply need to scale. If you’re working in a growing footprint, then switch wrangling is one of those things. I reached that point at about a dozen switches in 6 different locations but just got around to building something recently. We use Arista switches and they have a built in XMPP client which made this really easy.

The most well known implementation of XMPP is probably Jabber. Jabber is an instant messaging client/server system that operates using the XMPP protocol. It’s cross-platform — it probably has more clients and servers than any other IM system in existence, and as such it’s pretty easy to find the parts to get this running.

Jon’s note: Keen readers may notice that I am not publishing the audio portion of my blog posts anymore. I made that decision based strictly on usage: hardly anyone downloaded the podcast files, so I take that to mean there’s very little interest in them.

I recently had a need for a link shortener and that simple need quickly turned into an idea to build one from scratch. I figured it can’t be that hard, and I was right. Shortening the links is easy, but dealing with the unwashed masses of the internet that are going to use it is another problem entirely. I have lots of little internet-based projects that are locked down for only my use because the internet is rife with people who just want to watch the world burn, and they’ll try to destroy everything that comes across their path. I met some of them during my first week with Link Chomp.

Back in January, I decided to take my writing up a notch. I used to just “blog” which was this nice relaxed pace, writing only when I felt like I had something interesting to say. While that provided almost no stress, it also didn’t provide much content. It wasn’t that I felt I had nothing to say, I just felt like someone had already said it. I had no incentive to write about the things I like because a million other people were already writing about those topics. At around the same time, I started to become actively aware of the decline of quality in the mainstream media.

Data Centres are made for servers, not humans. Consequently, they are inhospitable places and prolonged exposure to this adverse environment can quickly take a toll on your productivity and your health. Once your health starts to go, your attitude and your deep-thinking abilities go with it and the quality of your work drops. You owe it to yourself and your team to remain as effective as possible while onsite, and here’s some tips to help. I’ve spent a few weeks in several different data centres around the globe this year, and here are some things I’ve learned that can help you out if your destined for one of these hell holes.

Make sure you can get in

Data Centres (DC) are very attractive targets to bad actors. DC operators know this and generally employ pretty stringent identification measures before granting access. Large companies also usually have the clout to enforce additional identification measures on top of what the DC requires, so you need to be prepared to prove yourself to get in. It’s not uncommon for the foyer in a DC to be filled with people on their cell phones calling back to the home office for some kind of authorization they need and if their home office is 15 hours time difference from the DC, they ain’t getting in today.

You should have some kind of customer service representative at the DC. Contact him or her prior to your visit to ensure you know what you need to get access. If you don’t know who your rep is, call your account manager (your billing department should know who that is) or call security directly at the DC and ask about their procedures. As an example, the access process I’ve most commonly seen is:

• A site visit ticket has to be filed prior to the site visit. It lists the full names of everyone who is coming, and what days they will be there.

• Passport is required onsite to prove you are who you say you are.

• Some companies also require you to show your company ID to the DC.

The subject of contact tracing is a hot topic in the infosec community. Privacy advocates have lots to say about it, and these days a lot of privacy-centric folks are also highly technical. That intersection produces a lot of really good discussion because it properly encompasses both the social and technical issues surrounding contact tracing. I live in that intersection and I think it’s worth extracting some of the salient points from that discussion into an article to give it more oxygen. Here we go…

Before I start into the topic I want to make a few points very clear. You are not about to read an article about why COVID-19 is not a big deal. You won’t find support for arguments such as “we’re overreacting” in this post. You won’t find sympathy for conspiracy theories that the pandemic is not real, and you won’t find a receptive ear if you think these things. Go somewhere else if you think these things. I don’t want you in my orbit.

Ok, now here we go for real this time…