Reuben's personal website

tmux in GCP Cloud Shell

Thu, 07 May 2020 00:00:00 +0000

GCP Cloud Shell runs tmux. And if you’re a regular user of both then this video I made a while ago in January might be of interest to you.

Side note: I’ve come to like instructional videos as documentation. Many don’t have the patience and energy to read lengthy written documentation. For some aspects short videos work better and engage your fellow project members. But I haven’t found a routine, quite yet.

Background: GCP Cloud Shell has many use cases. For me it’s often ETL-ing a lot of data from cloud to cloud, long batch processing, suffering from unreliable mobile connectivity, or simply not having the Google Cloud SDK readily available in my current environment. tmux for me personally provides a reliable and consistent tiling experience throughout different environments.

Conferencing advice

Sun, 22 Mar 2020 00:00:00 +0000

I’ve been involved with A/V conferencing for the majority of my career. As a user, systems integrator, and developer. With COVID-19 I’ve often been asked for input. This is my subjective take on the most important aspects.

Practice

Don’t embarrass yourself in front of 15 colleagues and waste their time. Especially as a host. Practice extensively beforehand. Don’t make any assumptions about network, sound quality, desktop sharing, interactive collaboration and test what you intend to do in advance. Start your client a couple of minutes early to check that everything is working.

Hardware

Cable over wireless, Battery will fail. Bluetooth will fail. You’re dongle will go missing.
USB over analogue. Avoid bad audio jacks and missing ground. USB variants have a convenient mute button, instead of finding the app and using your mouse.
Headset with boom mic. Avoid using your webcam, laptop, or earpiece microphone. See sports commentators. Get it near to your mouth, but not directly under your nose.
Use a dedicated webcam. Using additional screens, your laptop will always be placed awkwardly. And dedicated webcams still provide a better picture quality.
Light source from the front. Try and have your face flooded with natural light from the front. All cameras work better with more light. Avoid bright lights and windows in the background.

Experimenting is fine, but these brands will deliver. Preference based on compatibility, affordability, build quality:

Headsets: 1. Logitech, 2. Plantronics (now Poly), 3. Jabra

Webcams: 1. Logitech, 2. Microsoft

Advanced

If you don’t want to go the simple route of investing in a $40 USB headset, there is plenty of advice out there. It can become a time sink as well as a source of frustration and joy.

HopeRF RFM95 breakout pinout

Fri, 28 Feb 2020 00:00:00 +0000

The breakout board for the RFM95 (and RFM92) chip from HopeRF is not well documented. And if you’re stuck without a multimeter, like one of our local fellow TTN community members was, this can be frustrating.

Rather than it’s technical complexity, the uncertainty of not having official documentation will be nagging your conscience. So hopefully the PNG or SVG can help.

PSA: I quit Twitter

Tue, 17 Dec 2019 00:00:00 +0000

Yeah, I don’t think I have to elaborate on the pros and cons of Twitter. The internet has better places to offer.

DNS, the DevOps way

Sun, 03 Feb 2019 00:00:00 +0000

Gareth Dwyer delivers entertaining talks one could describe as tech talk standup. I very much enjoy them. He’s a brilliant software engineer and reignited my respect for technical writing. At a recent DevOps Cape Town meetup he presented a simple set of tasks and their realisation. In the end sparking a discussion with the question: “Is this the DevOps way?”.

As it is typical for backoffice applications, email plays a central role, which in turn means dealing with dangerously unusable web UI of rent-seeking local registrars. Uncertainty starts creeping up and how to get some DevOps in the mix.

Instead of defining DevOps culture and practices, let me set out two personal objectives I’d see for this case:

Transparency. Avoid not knowing who changed what when.
Reliability. Automate tests and deployments.

I’m a fan of “infrastructure as code” where you have everything originate from a git repo and let automation take care of the deployment. On the code side you reap the benefits in regards to permissions, review, change log, documentation. On the automation side one enjoys determinism and repeatability.

How could this look like for DNS?

In order to automate things you’ll need DNS with an API. Next to running your own BIND or djbdns, examples are: Amazon Route 53, Cloudflare, Dyn … or GCP Cloud DNS. With all GCP services, including Cloud DNS, you get the holy trinity of API, command line, and Web UI.

Here “DNS” is not “registrar”. You’d have your registrar point to a DNS service of choice.

In terms of CI/CD tooling everything is possible with GCP. I like GitLab and Travis very much and tend to opt for Cloud Build which naturally works well with GCP Cloud Source Repos where we will store the zone file for this example.

For simplest implementation we assign the DNS Administrator role to the Cloud Build service account within the project. Then we define a trigger for any push of the zone file to the master branch in the repo as follows:

The above referenced cloudbuild.yaml looks as follows. Instead of assembling our own image we use the readily available gcloud cloud builder to clone the repo and import the zone file:

steps:
- name: gcr.io/cloud-builders/gcloud
  args: ['source', 'repos', 'clone', 'honigwachs-info-zone']
- name: gcr.io/cloud-builders/gcloud
  args: ['dns', 'record-sets', 'import', 'honigwachs.info', '--zone=honigwachs-info', '--zone-file-format', '--delete-all-existing']

The tool gcloud dns record-sets is quite nifty and validates your input files at execution. Dependent on your testing strategy, this already might be sufficient. With --zone-file-format we can use the BIND format instead of yaml and make use of bind9utils such as named-checkzone to test zone files. But do note that in this example the --delete-all-existing flag is set to include SOA info and allow for a “pure” BIND experience when dealing with the zone file.

Cloud Build publishes update messages to a Cloud Pub/Sub topic called cloud-builds which is automatically created when enabling the Cloud Build API. From there other actions such as notifications can be triggered. In general we’re talking about a very low deploy time and once it’s in GCP Cloud DNS we enjoy an astonishing propagation time we’re used to from Google ;-).

Oh, yes, this is what a BIND zone file looks like:

$ cat honigwachs.info 
honigwachs.info. 21600 IN NS ns-cloud-b1.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b2.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b3.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b4.googledomains.com.
honigwachs.info. 21600 IN SOA ns-cloud-b1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

www.honigwachs.info. 300 IN A 151.101.1.195
www.honigwachs.info. 300 IN A 151.101.65.195

yetanother.honigwachs.info. 300 IN A 151.101.1.195