nesv.ca

Corne

nicksaika@gmail.com (Nick Saika) — Thu, 23 Mar 2023 00:38:50 -0400

A few updates.

Baby

I am happy to announce that I am father to an absolutely wonderful, adorable little girl! Do not expect me to share too many details. All anyone needs to know is that my wife and I have a daughter, and as frustrating as the first few weeks of fatherhood have been, I wouldn’t trade it for anything in the world.

Work

As would appear to be quite fashionable in these times, I was let go from my job as part of a "reduction in force", back mid-February. There were so many people let go that it definitely didn’t feel personal, nor did it feel punitive (like I was being fired for being a substandard employee).

While I am currently looking around for new work, I am taking it really easy and not rushing anything. I received a decent severance which my family can happily float on for a few months.

I am someone who very much enjoys work, and practically require it for my sense of self-being. I enjoy the sense of duty that comes from doing work and providing for those who depend on me. Beyond the whole "it’s nice to have money" thing, I know I will start to get squirrelly if I don’t find work soon-ish. If I find anything before then, it will be very unlikely that I start work until May or June of this year. I am greatly enjoying the time I get to spend with my wife and our daughter, and I know I am going to look back on this time with a deep fondness.

Keyboard

A colleague from my most-recent job was also caught up in the "reduction in force", and built a few extra keyboards to kill some time. As a result, he sent me a snazzy Corne!

My daily driver keyboard has been the Keychron Q3. It is a fantastically heavy keyboard, and I outfitted it with some Wuque Studio WS Yellow key switches. I love typing on that thing, with those switches; it sounds like rain gently hitting a window.

This Corne is definitely taking a bit of time to get used to. It is my first split keyboard, and it is the first keyboard I have used that makes liberal use of layers. In fact, it is the first keyboard I have ever actually used layers on, and oh boy, do you ever need to use them!

In my usual typing style, my hands fly all over the keyboard; my wrists do not stay locked in position, and I contantly lift them to always position my hands into a comfortable pose to press the keys, or combination of keys, for the task at hand. The Corne is slowly breaking me of this habit. The more I type on the Corne, the more I find I want to keep my hands in a more-fixed position, otherwise I completely lose track of which keys I am hitting. Oddly enough, the one key I have a really hard time adapting my typing style to, is the C key; I always want to press it with my left index finger, but on the Corne, it is much easier to press it with your ring finger.

Ergonomically, the nice thing about the Corne is that I can space the two halves out. As a broader individual, it feels much easier on my shoulders to have my arms go straight ahead, instead of having them converge in front.

Until I get comfortable typing on the Corne, the WS Yellow switches are going to stay on the Keychron Q3. On the Corne, I currently have some Kailh Pro Purples which are fine, but after typing away on the WS Yellows for a few months, feel tight and none too fluid. I also have some truly cheap-feeling XDA profile kecaps I am using, only because the MT3 keycaps I have laying around are a bit too tall for my liking (on the Corne). I have some KAT profile switches in the mail, though.

Note

Since I started writing this blog post, I received a set of Gateron Oil Kings and they are absolutely fabulous. Much better than the Kailh Pro Purples. Even with the cheap-o XDA keycaps, typing on the Corne is a much nicer experience with the new switches.

I still think the WS Yellows are a little more to my liking, but the Gateron Oil Kings are really, really nice.

Setting up Caddy on Rocky Linux 9

nicksaika@gmail.com (Nick Saika) — Sun, 19 Feb 2023 13:43:32 -0500

Some quick ’n dirty field notes, adapted from setting up the server that hosts this website.

I recently decided to move clouding providers. The reasons are unimportant.

This blog post is going to go over setting up the Caddy web server, on a Rocky Linux 9 virtual machine.

What is not in this guide

When I set this up, I used:

Terraform for automating the infrastructure setup;
and Ansible for automating the infrastructure configuration.

I will not be including any of my Terraform .tf files, or links to my Ansible roles and playbooks, in this guide.

Instead, I will provide you the commands that you can run manually. This allows you to automate them however you desire.

Get a virtual machine

For this guide, I used Linode. You can use whatever cloud provider (or local hypervisor) you prefer. If you are doing this as a bare-metal install, that is fine too!

There are some important things to note about the Linode-provided virtual machine I set up:

SELinux was enabled and set to “enforcing”, by default;
firewalld was enabled by default.

These are important to note, because not every cloud provider provides Rocky Linux virtual machines with these enabled. On DigitalOcean for example, SELinux was enforcing, but firewalld was not enabled.

The rest of this guide assumes that SELinux is enforcing, and that firewalld is enabled as well. There are too many guides out there where the second or third step is disabling SELinux. This kind of stuff does not fly in the real world, so leave SELinux alone, and let it enforce stuff.

DNS

Once you have the virtual machine created, it is at this point I recommend creating any required DNS records for pointing your desired domain name, to your virtual machine.

Installing Caddy

dnf install 'dnf-command(copr)'
dnf copr enable @caddy/caddy
dnf install caddy

Before you start and enable caddy.service, you should configure it.

Configuring Caddy

The caddy package puts a bare-bones configuration file at /etc/caddy/Caddyfile. Edit this file to look something like this:

{
  debug
}

mysite.com {
  encode zstd gzip
  root * /srv/mysite.com/
  file_server browse {
    index index.html
  }

  log {
    output file /var/log/http/mysite.com.access.log
    format json
    level ERROR
  }
}

Remember how I said Caddy has a lot of sane defaults and an simple configuration file? This is what I am talking about. The mysite.com block has no details about fetching TLS certificates, or performing HTTP-to-HTTPS redirection. Caddy handles that out of the box for you. You can configure how it retrieves TLS certificates, and handles HTTP-to-HTTPS redirection, but that is an exercise for you, dear reader.

The important thing to note from this Caddyfile sample, is

mysite.com {
  root * /srv/mysite.com/
  ...

and even then, just the root * /srv/mysite.com/ line. That configuration “directive” sets the directory that content for mysite.com will be served from.

Next, let’s create that directory.

Creating the content directory

mkdir -p /srv/mysite.com

Managing SELinux file context mappings

Even though SELinux is enabled and set to enforce on the standard Rocky Linux image from Linode, I still had to install an extra package to get the semanage(8) tool.

dnf install policycoreutils-python-utils

Next, we will need to manage the SELinux file context mappings. To do this, we will use semanage(8):

semanage fcontext -a -t httpd_sys_content_t /srv/mysite.com

This command says:

We want to manage the fcontext (file context)
By adding -a
The httpd_sys_content_t type
To the /srv/mysite.com directory.

Lastly, we want to use the restorecon(8) command to restore the SELinux security contexts to our content directory:

restorecon -rv /srv/nesv.ca

Upload your content

Personally, I do this with rsync(1).

First, I had to install the rsync package on the remote host:

dnf install rsync

For rsync(1) to work, both your local host, and the remote host you are uploading your content to, must have rsync installed.

Then back on your local machine, push the files to the content directory:

rsync -vz public/ user@remotehost:/srv/mysite.com/

Allowing traffic

Again, as a detail about this Rocky Linux VM provided by Linode, firewalld(1) is enabled as well. If we tried to start Caddy and view our website, we would get an error in the web browser saying something about the connection being interrupted.

Punching a hole in the firewall to allow HTTP and HTTP traffic is simple enough:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https

The --permanent flag persists these changes so we do not have to run these commands again if the server is ever rebooted;
--zone=public says to issue this command against the public zone (read up on firewalld to learn about zones);
--add-service=http and --add-service=https is the important flag here, this adds the HTTP and HTTPS services to the firewall rules, effectively allowing traffic in on ports 80 (HTTP) and 443 (HTTPS).

Starting Caddy

Finally, start and enable the systemd caddy.service unit:

systemctl enable --now caddy.service

Postamble

Fantastic! At this point, if you pop open your web browser and go to your domain, you should be greeted by your snazzy website, being hosted by Caddy!

Hopefully, you remembered to create a DNS record to point your domain at the virtual machine’s IP address.

Govern

nicksaika@gmail.com (Nick Saika) — Mon, 02 Jan 2023 23:55:14 -0500

Nearly eight years ago, I complained about the lack of an adequate configuration management tool. So, I wrote one.

Eight years ago, in my Agent vs. Agentless post I wrote about how I wanted something new and/or different for a configuration management tool. And after eight years, I had an epiphany. Truth be told, I had the epiphany over a year ago, I am only writing about it now.

In the “Agent vs. Agentless” post, I already had a name picked out: govern. It’s a verb. It is written in Go. It starts with “g-o”. nice.gif

Without further delay, I would like to announce Govern.

This post is mostly about how Govern came to be. If you do not care about that, and just want to read the technical documentation, go here.

What is Govern?

Most configuration management tools provides swathes of built-in plugins that will allow the user to manage packages, manage the contents and properties of files, and do so much more.

Govern, on the other hand, keeps things as simple as possible. Govern is a configuration management tool that tries to do as little as possible and relies on external executables to accomplish the desired tasks.

Bootstrapping

When I initially started trying to write Govern, I ran into an issue where I needed it to actually do something. Sure, I could just start slogging away at writing individual actions like “install a package”, “make sure a service is running”, “template this file”, etc. I quickly lost all motivation, because at that point, I was repeating work that has already been done by dozens (if not hundreds) of people who have contributed to Ansible, SaltStack, Chef, and Puppet.

It stopped being fun. I had not done anything differently. I was left with something that was completely useless on its own.

And after some years of stewing on it, I had the epiphany that lead me to the initial implementation.

Epiphany

I don’t need to implement all of the actions myself. I don’t even need to provide them. All I needed was a way for people to be able to write them and their own.

To provide a brief detour of insight into how I happened upon this realization: at work, we were doing some work with Ansible. My coworker had just written a really, truly, very basic action that rendered a set of templated configuration file based on some predetermined paths. The argument could be made that it could have been done differently, but there were two things that really stuck out to me:

My coworker’s solution, of implementing the task as an action, was elegant as hell. With one task stanza in a playbook, I could generate the complete directory hierarchy, and render out all of the files that needed to be there.
The code was so ugly, its mother would have fed it with a slingshot.

My coworker did a really good job of only writing enough code to accomplish the task. It wasn’t a matter of programming taste. The code was fine, and it did the job in as few lines as required. What stuck out to me was how much boilerplate there was, and how impenetrable and opaque the boilerplate was. What really bothered me was how befuddling the code was. Most of the file was nothing but boilerplate. The code that was actually performing the intended function was maybe 10% of what was written.

That irritation, at how obtuse and cludgy the plugin system was, got me thinking about how this could be made easier.

Tenets

There are several established patterns for configuration management tools:

They need to be able to probe for details about the underlying system. Ansible calls these “facts”. SaltStack calls them “grains” (or “pillars”, depending on whether they are details that live on the host, or details that come from the Salt master node). Chef has ohai. Puppet has facter.
They need to have a templating language. This particular feature is arguable, and arguably, it should be pluggable, but meh.
They need to be declarative. Imperative configuration management is hardly acceptable if you do this kind of work professionally (maybe unless you’re a Windows administrator), and you quickly realize how big of a pain in the ass it is when you have to do it at really large scales.

NOTE: Yes, I know, Windows folks now have SCCM, or MECM as it is now known; and yes, I know Ansible and folks have somewhat supported Windows for a while. It does not change the fact that most Windows administrators I have met, typically did not want to shoehorn a UNIX-style configuration management tool into their GUI-driven lives. It is not a dig at them. It is an indication that “the UNIX way” is not universally accepted as the better approach. Windows distinguished itself by being “not UNIX-like”. It doesn’t mean I think they are right or wrong.

Solution

Instead of writing all of the plugins, or “things that do things” for Govern, I realized all it had to do was be able to execute something. This little realization opened up the world of possibilities for me.

As a brief aside, I do not manage Windows systems. I never have, and $DEITY willing, I never will have to. All of my work, for as long as I have been doing it, targets Linux systems. Once in a while, a snazzy little BSD box shows up, but for the most part, it is Linux day-in, day-out.

Facts

When Govern needs to check for facts, sure, it can probe the underlying system, but how scalable would it be if I needed to write all of those facts into the underlying system from the get-go? The answer is: not very. So, to jump to the conclusion, I thought, “all I have to do is walk a directory tree, and look for files with the executable bit set on their modes.” With that, I wrote some really simple code that crawled one or more directories, looking for executable files. In keeping with “the UNIX way”, each of these executables writes their output to STDOUT.

When you look at system facts gathered by other tools, there is some scrapping about with the names and hierarchies of those facts. In Govern’s case, the fact’s “name” is its position in the directory hierarchy.

For example, say our “facts” directory (holding our executables) is at /usr/share/govern/facts. Within that directory, we can create other directories holding executable files. name is a pretty generic fact name, and it does not tell us anything about what name that fact is providing. But, if we put it under the os directory, its name becomes os/name. This makes it pretty clear that this fact is going to return us the name of the operating system. Now, we are getting somewhere.

Runners

I followed the same approach for “runners”.

Runners, in Govern’s taxonomy, are the actions plugins, or the “things that do things”. If you are using SaltStack, you might invoke the pkg execution module to install a package. The Govern equivalent, is the pkg runner.

Runners are discovered the exact same way: when Govern starts, it looks at all of the runner directories it was configured with, and walks each of those directories looking for executable files.

Unlike facts, which are always expected to return output, runners only need to return output when something goes wrong. In this case, the error is expected to be written to STDERR. Information can be written to STDOUT, but this is expected to be purely diagnostic information in successful cases, and is ignored by Govern unless you explicitly ask for it.

The one different between the discovery of facts and runners, is that runner names are not hierarchical. Govern will start probing for executables in a given base directory, but once all executables under that directory have been found, the hierarchy is flattened, and all runners exist within the same “namespace”.

Conflicts

As I mentioned, you can configure Govern with multiple facts and runner directories. What happens if there are multiple facts or runners with the same name? In keeping with simplicity and prior art, I followed the example of the UNIX $PATH variable: if multiple executables exist with all searched directories, the last one wins.

For example, if you have two facts directories defined in this order:

/usr/share/govern/facts
/usr/local/share/govern/facts

and both of them contain an os/name fact, the last one will win. In this case, it means /usr/local/share/govern/facts/os/name will be the fact that is executed.

Templating

Again, the necessity of a templating engine is arguable. It is nice to have one, especially if it is documented. Ansible and SaltStack both use Jinja2, and it is really nice.

Fun fact: Python used to be my primary programming language. During the whole Python 2 → 3 changeover, I lost my patience with the whole PyPI ecosystem as some packages quickly updated to Python 3, and some dragged their heels. One day, I experienced my last UnicodeDecodeError, and said enough is enough. I heard about this nifty little language called “Go”, written by some UNIX juggernauts, and from that point on, Go has been my primary programming language.

Go has a built-in templating language: text/template. It has every feature you would want from Jinja2, even if it is juuuuust ever-so-slightly different in use. It is a perfectly functional substitute, in my opinion.

With that, Govern had a templating language.

Core

As I mentioned earlier, my one, big irritation with the existing systems was how opaque it was to extend it. You had to read its documentation, and understand exactly how to initialize your plugin and get it to register with the core system. This is partly fixed by allowing users to place an executable file in a directory (that they then configure Govern to look in).

If you are trying to extend Ansible or SaltStack, you have to write your plugins in Python. If you are using Chef or Puppet, you have to use Ruby. But if that weren’t enough, you also have to import packages or modules, and extend some base classes to have your new plugin be automagically recognized by the core system.

With Govern, you can write your facts or runners in any programming language. The only thing Govern cares about, is that its executable bit is set.

At the end of the day, this means that the Govern core can stay exceptionally small, and be infinitely flexible to the needs of its users. In the existing systems, if you found a bug in any of the existing plugins, you would have to wait for the bug report to be triaged, the bug to be reproduced, and for the maintainers to cut a new release. Depending on the project’s overall cadence, you may likely be waiting a while. With Govern, you have the option to add, replace, or completely remove any facts or runners!

Another note on templating

One thing I really liked from SaltStack, was how the .sls files were passed through the templating engine, before being applied. In Ansible, you have to carve out completely-separate tasks files, or conditionally override variables if, say, a pacakge name is different between two Linux distributions. In Salt, it kept a lot of that in one, very convenient place.

The templating engine in Govern, Go’s text/template package, is bundled into and provided by the core govern executable. With templating being something bundled in, this allowed me to bring along the “templated state files” approach I enjoyed so much, from SaltStack.

Declarations

As I mentioned earlier, declarative state is where it’s at. Imperative configuration management, in professional practice, is for masochists.

Govern needed a file format to allow its users to declaratively define their desired state of the system Govern is run on. After fiddling around with different formats, and eventually settled on HashiCorp’s configuration language, HCL.

While the hclsimple package lets you quickly unmarshal HCL from an io.Reader into a structure, you can also use other foundational subpackages to dynamically parse the read state files. This is important because Govern re-discovers all executable facts and runners each time it is started. In practice, there is no real concern of this being a slow operation, since a lot of filesystem operations are cached by the operating system, and doing something like walking a directory is just walking a bunch of direntry structs in a filesystem journal.

It’s the “dynamic” part that is important.

To help frame the rest of this section, here is an example of a resource declaration within a state file:

pkg "emacs" {
  state = "installed"
}

This resource defines a pkg resource called emacs, and says it should have the installed state.

A resource is structured like so:

runner-name "resource-name" {
  arg = val
  ...
}

So, with our pkg "emacs" resource, it tells Govern the emacs resource should be handled by the pkg runner.

Since runners and facts can come into, or be snuffed from, existence between any two executions of govern, it would not make sense to store any state about Govern’s runners or facts across executions. When Govern starts up, it first scans for facts and runners. Next, it will read in any state files from — you guessed it — one or more “state directories”. As each resource defined in a state file is parsed, Govern will attempt to match the resource’s runner-name to a discovered runner. Govern does not know the name of runners before it executes; it can’t.

If Govern cannot find a runner to hand the resource off to, it will print an error message to the screen, and exit before applying any state.

Similarly for facts, if a fact is explicity requested within a templated state file (and remember, all state files are technically templates), Govern will exit before doing anything else. Unfortunately, this currently does not hold true for templated files. If you attempt to use the template runner (which simply calls govern template) to render a templated file, and it cannot find a fact using the added fact template function, the resource itself will fail, but the rest of the state will still be applied.

What’s more, is that the key = value pairs within the body of a resource block are completely free-form. There are only two, reserved keys in a resource block: before, and after.

These currently-unimplemented features are intended to allow Govern to create a directed-acyclic graph (DAG) of the resources to apply, so that users can order the application of resource state across different state files.

Since the runner names are dynamic, and the key-value pairs within a resource name are relatively free-form, in combination with Go being a statically-typed language, the HCL libraries provide a nice set of tools to be able to flexibly parse structured data, without having to force them into a pre-declared struct.

Simplicity

There are a bunch of features in other configuration management tools that I know I did not want to replicate in Govern.

Scheduled execution

Configuration management processes like SaltStack’s minions, like to run as daemonized processes. Since a lot of these systems want to ensure the state declared by the user as often as possible, these processes like to periodically execute their declared state files on some regular cadence, and this means that these processes (since they are running as daemons), need to have some sort of timer to run on. Linux and other UNIX or UNIX-like systems have had periodic execution scheduling for a very long time. It’s called “cron”. Nowadays, you have systemd.timer(5) units. This does not need to be a thing in Govern, since Govern does not run as a daemonized process.

Version control system integration

This was one feature that always stuck out like a sore thumb to me, from SaltStack. Everyone wanted to use it, probably because “it was there”, but it was always such a chore to set up. The fact of the matter is, if you want to make sure the configuration management system applies the latest declarative state revision, you can pull that down yourself. Be smart about it. You know you already have a task scheduler like cron, or systemd, so write a script that runs git pull in the directory where you have Govern configured to look for state files, and make sure it executes before Govern does. Alternatively, write a wrapper script that pulls the latest revisions, then calls govern apply.

A fat core

As I have already pointed out, ad nauseum, the downside of bundling a lot of things into the core product just leads to a burden for the users when you do not get everything perfect out of the gate. At some point, as the developer and maintainer, I want to keep my job as easy and frustration-free as possible, and I do not want to have to deal with long-running email threads about “oh hey, people don’t use yum(8) any more to install packages on RHEL; they use dnf(8) now,” or suffer through conversations about what someone else thinks the best set of flags to pass to some command are. All that does is burden me with the task of keeping the product supportive of systems I probably do not use on a regular basis, and it makes users far less likely to want to adopt it if it does not support their preferred Linux distribution, out of the box.

Necessity

The most important goal of Govern, for me, is that it stays as a simple and flexible core executable, without being mired in too many features that maybe some people will use. I especially do not want to add features that are already provided by the underlying system. That is why Govern’s plugin system is not some complex internal machinery; it mimics a UNIX (or UNIX-like) system’s shell, where it essentially looks in directories for sets of executables to run, like $PATH. This is why Govern will likely never run as a long-running process. It does not need to. It does not need to replicate existing functionality, nor does it need to provide parity for all of the little, seemingly-convenient features that other systems have.

At the end of the day, Govern is intended to be a very basic, and very functional configuration management tool. It will reuse whatever the underlying system provides.

Conclusion

Govern has been my little hobby on the side, for the past year or so. I have experimented with writing runners and facts in various programming languages.

For facts, mostly, I will use good ole, “standard” POSIX sh(1). This has been fine for the most part.

For runners, I started writing them in POSIX sh(1), but it got really cumbersome as I started to add support for other Linux distributions and BSDs I use on occasion. Depending on the task at hand, if it is simple enough, I have really taken a shine to Lua. It is simple, and embeddable within Go, thanks to go-lua. Remember that one of my desires, in Agent vs. Agentless, was that I did not want to have to depend on an interpreter being installed on the managed host. With being able to embed a Lua runtime into a Go program, Govern becomes the interpreter.

For anything more complicated than feels comfortable writing in Lua, I have started putting together a package that handles all of the boilerplate for writing runners in Go. The upside to this, is that you can easily write runners in Go. The downside, is that it makes these runners impenetrable to a non-programmer (or a programmer or sysadmin who is not familiar with Go) that finds a bug. And despite disk space being cheap these days, it also results in runners being incredibly large, statically-compiled binaries.

The Govern core is very functional. Any time I have put into the project lately, has been mostly around adding runners as I need them. I hope you find Govern interesting and useful.

About

nicksaika@gmail.com (Nick Saika) — Mon, 02 Jan 2023 20:03:11 -0500

Hi! 👋

My name is Nick. I live in Canada. I enjoy cooking. I work in tech.

If you would like to reach out:

Shoot me a toot 🐘
Skeeeeeet 🦋
Send me an email 🖄

About the site

This site is generated using Hugo. The variable width font is Radio Canada. The fixed-width font is Commit Mono.

Resume

nicksaika@gmail.com (Nick Saika) — Mon, 02 Jan 2023 20:03:11 -0500

Who Am I?

I am a systems administrator-turned-software developer (and not the other way around), who enjoys working on backend systems, taking on architectural responsibilities, and approaching problems by decomposing them into smaller, more-approachable pieces. I am a quick learner, adaptable to short deadlines and fast-paced environments. While I do prefer to work as a productive member of a team, I do have a proven ability to work independently. I am seeking a position that will utilize my current strengths while allowing for professional growth in new skills and technologies.

A majority of my work over the past 10 years has been in the Go programming language, targeting Linux and BSD systems. Most of my time has been spent working on highly-scalable and reliable distributed systems and platforms, such as Kubernetes. I am currently learning the Rust programming language. In the past, I have also used Lua, Python, C, JavaScript, Common LISP, Erlang, TCL, and Ruby to varying extents.

When it comes to working with databases, I am most familiar with PostgreSQL, SQLite, Cassandra (and ScyllaDB), Redis, and etcd. I have a passing familiarity with Consul, memcached, InfluxDB, MongoDB, MySQL, and Elasticsearch.

Given my history as a systems administrator, I focus on automation and repeatable processes, using tools like Ansible, and Salt. I have also used Chef, Nomad, Puppet, and Terraform.

I have more than 10 years’ experience working remotely, and am only open to remote positions. I am not interested in working on contract terms; full-time employment only. I am not interested in management roles.

Specialities

Network API/RPC design (gRPC, HTTP) and message queues.
Concurrent software design patterns.
Relational and non-relational (“NoSQL”) database design.
Scalable system design techniques.
Continuous testing, integration, and deployment.

Experience

Lambda

Senior Engineer (July 2024 — )

Working on the Core Infrastructure team in the Platform Engineering organization.
Bootstrapping bare-metal and cloud-hosted Kubernetes clusters as shared, internal resources.
Developing deployment tooling that integrates with existing internal systems.

Skills

Go, Kubernetes, Kustomize, Ansible

Akamai

Senior Engineer II (May 2023 — July 2024)

Worked on the CNS (Cloud Native Services) team.
The team’s subject matter expert on the Go programming language, and Kubernetes controllers.
Contributed to various proofs of concept for potential projects.
Wrote a proof of concept Kubernetes informer to replicate custom resources between clusters.
Contributed to Flatcar Container Linux to provide better support for Akamai Connected Cloud (Linode), including contributions to Flatcar’s documentation, as well as dependencies such as afterburn and ignition.

DigitalOcean

Senior Engineer II (June 2022 — February 2023)

Technical lead of the Delivery team.
Part of a cross-functional team to increase safety around software deployments.
Technical reviewer for proposals focused on increasing developer productivity, and redesigning core, internal systems’ architecture.
Overhauled my team’s bare-metal provisioning and configuration tooling, to minimize operational toil. When upgrading ~230 hosts between major operating system versions (e.g. Ubuntu 18.04 → Ubuntu 20.04 → Ubuntu 22.04), this work resulted in the process going from approximately 4 months of full-time work for 2 engineers, to 3 weeks of part-time work for 1 engineer.
Technical advisor on a cross-functional project setting up a managed, multi-tenant, multi-region Cassandra cluster.

Senior Engineer I (July 2020 — June 2022)

Member of the Delivery team.
Maintained and extended an internal, Kubernetes-based deployment platform used by a majority of teams.
Maintained a bespoke service discovery system that spanned most of DigitalOcean’s regions.
Tuned a Cassandra cluster spanning more than 12 regions/datacenters, used to power DigitalOcean’s internal service discovery system.
Enhanced the documentation and automation around the team’s bare-metal host management.
Maintained an internal artifact storage service used by many continuous integration and deployment pipelines: “artifacts.internal”.
Maintained an internal Docker/OCI image registry: “docker.internal”.
Served as a steward of DigitalOcean’s monolithic repository: “cthulhu”.

Skills

Kubernetes, Go, Bash, GNU make, gRPC, Concourse CI, GitHub Actions, Debian packaging, Ubuntu, Chef, Ansible, Cassandra

NetApp

Senior Software Engineer (September 2019 — July 2020)

Worked on the Kubernetes Application Management Platform team, on the NetApp Kubernetes Service (NKS) project.
Worked on various applications that did not fall into the domain of any other teams. For example: a GraphQL API service, and an in-cluster agent service for reporting on Kubernetes cluster health.
The de facto maintainer of the services that maintained always-on connections/tunnels with deployed Kubernetes clusters, called dispatch.
Wrote and implemented a proposal to scale the dispatch server to more than one instance, in the NKS backplane, while still allowing other, existing services to communicate through the tunnels without modification.
Passively worked on standardizing build and test scripts, across the various repositories that composed NKS; bringing consistency to Makefiles, and transferring responsibility of tasks from Dockerfiles and CI configurations, into the projects’ Makefiles.

Skills

Go, Kubernetes, Helm, Kustomize, CircleCI, GraphQL, Amazon Web Services

Rose Rocket

Senior Software Engineer (September 2018 — September 2019)

Technical lead for a team responsible for site reliability, systems administration, and “continuous improvements”.
Led the effort to consolidate various deployment environments, each with their own deployment methods, hosted across several cloud infrastructure providers, to a single, managed Kubernetes cluster (Amazon EKS).
The company’s Go programming language subject matter expert, providing code reviews and guidance on how to improve the company’s code base, and make it more idiomatic.
Improving continuous testing, integration, and delivery for all developed services.
Providing technical guidance on HTTP API design, database schema design, and system architecture.

Skills

Go, Kubernetes, Docker, Amazon Web Services, Ansible, Ubuntu, PostgreSQL, Jenkins, DigitalOcean

Global Cyber Alliance

Software Developer, Contractor (May 2016 — September 2018)

Technical implementation lead for the Internet Immunity project, which later became Quad9 DNS.
Wrote threat intelligence collection, parsing, and exposition tools.
Wrote services to generate, transport, store, and export anonymized telemetry from received DNS queries.
Wrote a service providing threat intelligence providers access to near-real-time, anonymized notification streams. These streams are populated when a domain name was blocked due to an indicator provided by that threat intelligence partner.
Provisioned and managed internal systems running FreeBSD, using Ansible and Salt.
Used an intentionally-small technology stack, due to the small team size: FreeBSD, Go, PostgreSQL, and Kafka.
Designed a PostgreSQL database schema for storing malicious domain names with automatic record expiry, and optimized for a read-heavy workload.
Wrote a parser for structured DNS TXT records, used for evaluation/“scoring” sender policy framework (SPF) and domain-based message authentication, reporting, and conformance (DMARC) policies.

Skills

DNS protocol, Go, PostgreSQL, Kafka, InfluxDB, Ansible, Salt, FreeBSD, pf, CentOS, dnsdist, Microsoft Azure, Amazon Web Services, Jenkins, haproxy, gRPC

Novetta

Software Developer (February 2015 — March 2016)

Worked on the Novetta Cyber Analytics v5 project.
Developed tooling to launch several-hundred cloud VMs, across multiple hosting providers, in less than 10 minutes, and have them managed with Salt.
Set up and maintain servers and the services on them, using Salt.
Developed a centralized authentication and authorization system, as there were no preexisting solutions that met the project’s needs.
Implemented a service discovery and monitoring system using Consul.
Wrote a Go package that allows developers to store metrics data in Elasticsearch and InfluxDB.
Designed, developed, and managed a fully-automated, continuous integration pipeline that built project components, packaged them into Docker images, and published them to a private Docker registry.
Maintained most of the project’s development and testing infrastructure in Amazon Web Services.
Assisted other project component teams on how to manage their own automated builds, using Jenkins and Docker.
Lead the “Core Services” component team, whose tasks included systems administration, and the development of supporting services that provided HTTP APIs to inspect overall system health, handle centralized authorization, and wrap existing HTTP APIs to integration them with the authorization system.
Launched the (now defunct) Operation Blockbuster website; was required to make sure it would not be vulnerable to a DDoS attack. (Novetta blog post)

Skills

Go, Ansible, Salt, CentOS, Docker, Amazon Web Services, PostgreSQL, Consul, Jenkins, Ubuntu, DigitalOcean, SoftLayer, Python, Cassandra, Elasticsearch, NSQ, InfluxDB

FR8nex

Senior Developer (June 2014 — February 2015)

Developed an administrative HTTP API service in Go, which provided the backing service to all of the front-end applications. This service was the “single point of truth” for all data.
Optimized Python and Go codebases, as well as our datastores (primarily PostgreSQL).
Utilized Ansible to manage the configuration of staging and production systems, as well as for scripting code and service deployments.
Managed staging and production infrastructure on DigitalOcean, and Amazon Web Services.
Designed a distributed messaging layer for the company’s analytic systems.
Wrote all of the scripts and automation for building, packaging and deploying all in-house applications.

Skills

Go, Python, PostgreSQL, GNU make, Docker, Drone, NSQ, etcd, Elasticsearch, Logstash, Ubuntu, CoreOS, Ansible, Bash, Amazon Web Services, DigitalOcean

Synacor

Systems Administrator (March 2013 — June 2014)

Used PUppet, mcollective, facter, Ansible, and Fabric to automate all parts of Synacor’s infrastructure.
Responsible for packaging third-party software, and internal projects, into RPMs.
Responsible for maintaining internal YUM repositories.
Writeing intermediary tools to automate routine tasks that could not be automated using Puppet.
Managed internal and external DNS (BIND, Dyn).
Point of contact for high-availability systems managed by Corosync and Pacemaker, and for MongoDB infrastructure.
Wrote a generic data collection tool, called “Nebulous”, for gathering versioned information about every part of Synacor’s infrastructure.
Curated various administration scripts into a single package, using sub.

Lead Engineer (January 2012 — March 2013)

Lead the backend/API development team for Carbyn, post-acquisition.
Helped define technical and architectural designs.
Point of contact for the systems administration and release management teams.
Managed software builds, packaging, deployment, and configuration processes.
Managed development (non-production) servers.

Skills

Go, MongoDB, JavaScript, Puppet, Bash, Corosync and Pacemaker, Ruby, Python, Fabric, RPM packaging, RHEL/CentOS 4, 5 and 6, Kickstart, Facter, DNS, Redis

Previous Employers

Carbyn — Senior Engineer (September 2011 → January 2012)
Aboutown Transportation — Developer (May 2009 → September 2011)

Other Project and Open Source Experience

Quad9

A free, publicly-available anycast DNS service, that filters malicious domain names by returning non-authoritative NXDOMAIN responses for blocked domains. Operates in more than 130 points of presence, in more than 77 countries. I am currently a supporting alumnus.

yawal

“Yet another write-ahead logger.” A write-ahead logging package for Go, written due to a lack of quality, composable, write-ahead logging packages in the Go ecosystem.

Code

go-dynect

Go package for interacting with Dyn’s ECT DNS service. Was used in Hashicorp Terraform until the project took a more plugin-based approach to external service providers.

Code

Pull request adding go-dynect to Terraform

New new site

nicksaika@gmail.com (Nick Saika) — Mon, 02 Jan 2023 19:25:36 -0500

As is customary, every couple of years, I decide it is time to port my personal blog over to some other platform.

This time around, I am not relying on a third-party service for hosting. In the past, this blog was originally on Blogspot. All of the content there has been lost to the ether, and there is now some random spam taking its place. After that, I moved a little more towards self-hosting, and tried using Github Pages with Jekyll, and that was fine, but it didn’t really keep me engaged.

Now, I am just that much closer to self-hosting the whole thing. In essence, I sort of am self-hosting? The content you are reading is currently hosted on a droplet, and the site is generated with Hugo. The content (as always) is mine, but this is not being hosted on a server out of my basement.

Who knows, maybe in the future, it will be.

Agent vs. Agentless

nicksaika@gmail.com (Nick Saika) — Mon, 02 Jan 2023 19:14:41 -0500

There has been something kind of burning on my mind, lately, and it’s mostly Ansible’s fault.

Ansible is an amazing tool, this post isn’t harping on the quality of the project, in the slightest.

My biggest beef with Ansible (aside from the shaky promotion of variables), is is how they market the project as being “agent-less”. That’s kind of a crappy ploy. Have you ever tried to use Ansible on a system that does not have Python installed (or has an ancient version of Python installed)? The only sentiment I can offer is: good luck.

Agent-less?

So, what does “agent-less” mean? Heck, what does it mean to have an “agent”?

An agent may make more sense if you prepend the word “execution”: “execution agent”. With Puppet, you have the puppet agent command; Salt has minions, and Chef has something similar. In these other tools, the agent handles communication with the “master”, for the purposes of getting contextual settings, so that these settings can be applied to the system the agent is running on.

I get the impression, from Ansible’s marketing, that they merely celebrate the fact that you don’t have to install something extra onto the remote hosts you want to manage. Again, this isn’t entirely true. You basically need an SSH daemon running (which, fine, almost every system ever has this pre-installed), and an up-to-date Python interpreter. There are some cases, where a Python interpreter just isn’t installed on the to-be-managed node, by default (e.g. Arch Linux, OpenBSD). The argument is that you could use Ansible’s raw module to install Python, prior to running any other steps, but then you lose the niceness that comes from using the package-specific modules, like apt, yum, pacman, etc.

So, agents then?

If you’d like. Essentially, this all boils down to personal choice. Again, I would like to stress that I am not saying Ansible is a sub-standard product, in any way, shape, or form. For configuration management, it is definitely my go-to tool.

One of the big headaches with agent-oriented tools is setting up that master-minion relationship. You can set up the master, but then you have to, somehow, set up the minions so that they know about the master. In situations like these, I think a laughably-accurate solution would be to use Ansible to install Salt, or Puppet.

What would make you happy, Saika?

Here is my wishlist:

No more Python, or Ruby. Managing the dependencies for these is ghastly. How about no interpreted languages, at all?
Gimme a statically-compiled binary. In the worst-case scenario, all I would have to do is use scp(1) to copy, say a .tar.gz, to the to-be-managed node. This would also mitigate needing to have an up-to-date interpreter installed.

That’s it, really; two items. I don’t give a hoot if it the tool has a master-minion architecture with agents, or it is is agent-less.

I know it really cuts down on the development time to write these tools in an interpreted language, and you can do lots of nifty things like dynamically import other packages/modules/libraries, but you still run into the pain-in-the-ass situation of having to manage dependencies. For example, let’s say you want to use tool X. It has a dependency on json-module-1.2.3, but your operating system-du-jour comes with json-module-0.2.4. You may try to build your own package of json-module-1.2.3, but most often, you will find that a crap-ton of other system packages rely on json-module-0.2.4, for stability’s sake. You pretty much have to resort to doing something creaky, or downright hackish just to get things working.

Ultimately, let’s write something in Go, C, C++, or in any other language that can compile down, into a static binary, where the only run-time dependency, is that the system be powered on.

In closing

I have been stewing on this for a while, and started a GitHub repo: govern. I honestly haven’t puch much effort, or time, into the project, and the only explanation is that I have other things to tend to (work, family, friends, etc.).

Should you, dear reader, be interested in working on govern, I would whole-heartedly welcome it.

NOTE

Everything that is currently in the govern repository can be trashed. It has really only served as a bin for my thoughts, as I postulate on my ideal configuration management system.

End of transmission.

[ANN] go-dynect

nicksaika@gmail.com (Nick Saika) — Thu, 15 May 2014 00:00:00 +0000

This post is the first announcement of my DynECT client library for Go.

Link for the lazy: github.com/go-dynect/dynect.

This library is extremely simple and does nothing more than provide data structures, and authentication handling for the DynECT REST API. You should keep that link handy, as unlike most client libraries you will find, API endpoints are not mapped to functions of any sort; this will be explained further down.

The source for the library is on GitHub.

Installing the library

The library can be simply installed by running:

$ go get -u github.com/nesv/go-dynect/dynect

Breaking convention

I come from the Python world, where client libraries are usually classes upon classes, with API features mapped to class and instance methods. Even though Go allows you to pin methods to types, I find this approach tiresome, and in the end, the onus is on me — the developer of the library — to make sure the API-to-method mappings stay up-to-date.

The approach I have taken with go-dynect/dynect is slightly different. In this package, I am giving you:

Structs to hold the data returned by DynECT’s API
Convenience methods for authenticating with the API
A single method — *Client.Do() — for making API calls
Automatic response data-to-struct unmarshaling (and vice versa)

I have been trying to take this approach with more and more client libraries that I write, but it doesn’t always apply. What this approach means for you, the developer:

You have to keep a reference of the API provider’s endpoints handy
You have to know what kind of data to expect from calling the API

If you consider these impositions unfair, then you are free to implement your own client libraries that abstract the API to the extent that if something goes wrong (maybe because DynECT’s API changed), the users will have no idea as to what is wrong.

My rationale with this approach is that I want to provide you, the user of this library, with something that is as out-of-the-way as possible; I do not want you having to learn the API for my library, as well as the service’s upstream API. I am hoping, that by this take on things, you will only have to learn DynECT’S API, and my library will only serve as a bridge for your communications.

Examples!

Alright, here are the basics of using this library:

Create a client
Log in
Make requests
Log out

The Make requests point is really the only one that requires any sort of explanation here:

All requests to the API are done through the *Client.Do() method.

To the *Client.Do() method, you provide four arguments:

The HTTP verb as a string (“GET”, “PUT”, “POST”, “DELETE”, etc.)
The API endpoint as a string (without the /REST/ prefix)
Request data that can be marshaled to JSON, or nil
An interface{} to unmarshal the response data to, or nil

Here is a quick example of calling this method:

client := dynect.NewClient(...)

...

var zones ZonesResponse
err := client.Do("GET", "Zone", nil, &zones)
if err != nil {
	...
}

Fairly straight-forware, n’est-ce pas?

Here is a more-complete example where we create a new client, log in, make a request to get all of the zones we have setup, a second request to get all of the records in each zone, and then we print each record out:

In closing…

As always, if you feel the need to holler at me, you can hit me up on Twitter, Google+, or just flat-out send me an email. Also, if there are any issues with code snippets, or spelling errors, please do not hesitate to create an issue on GitHub, or send me a pull request.

Hack the planet!

Writing worker queues, in Go

nicksaika@gmail.com (Nick Saika) — Tue, 25 Feb 2014 00:00:00 +0000

Have you ever wanted to write something that is highly concurrent, and performs as many tasks as you will let it, in parallel? Well, look no further, here is a guide on how to do just that, in Go!

This isn’t new

For an absolutely riveting (to me) talk on concurrency patterns, I highly recommend watching the following videos:

Concurrency is not Parallelism by Rob Pike is a good video to start with, as it imparts the theory behind using concurrency to write applications that execute tasks in parallel. This is definitely my favourite video in the bunch.
Go Concurrency Patterns (again, by Rob Pike) gives more concrete examples of how to employ various concurrency…erm…patterns, in Go. It also provides a comparison on how Go’s concurrency model differs from those in other languages, like Erlang.
Advanced Go Concurrency Patterns by Sameer Ajmani takes Go Concurrency Patterns and extends on it, by showing you even more patterns you can employ in your code.

If all you want is a basic understanding of concurrency, then you could get away with only watching the first video.

Some assumptions

While this will not be covered in the code examples, we are going to make several assumptions about our system:

Under no circumstances will the clients issuing work requests wait for the work request to finish. This is simply to avoid over-complicating our examples.
A work request will take a person’s name, and a length of time by which to delay the printing of that person’s name. The length of time must be parseable by time.ParseDuration(), and must be between 1 (one) and 10 (ten) seconds, inclusively.
You have the Go compiler, and toolchain, installed.

Hopefully, by the end of this article, you will be able to figure out how we can add in support for clients to wait for a work reqeust to finish. I also hope to leave you with an example that is easy to extend beyond your wildest imaginations. :smileyface:

Some terminology

There are a few terms we are going to be using, in this article, to describe the various parts of our queueing system.

A collector is going to be responsible for receiving work requests, and adding them to the work queue.

The work queue is, in Go terms, a buffered channel, which just lets work requests collect. The work queue is buffered, so that we do not block the collector.

Our dispatcher are responsible for pulling work requests off of the queue, and distributing them to the next available worker. To keep things clear, and voodoo-free, we are going to have our dispatcher maintain several queues, the first of which, being the worker queue.

The worker queue is the weirdest part about all of this (if you are not familiar with Go, and maybe, even if you are). It is a buffered channel of channels. The channels that go into this channel, are what the workers use to receive the work request. If this does not make sense now, it probably will as we implement the system.

Lastly, workers are responsible for performing a unit of work. In our examples, we are going to make workers responsible for letting the dispatcher know when they are ready to accept more work.

Step 1: Defining our work request structure

We need to be able to send our work request to the workers, via the dispatcher. Now, due to Go’s strict type system, channels must be typed. Yes, channels are a type, but they are a type that is used to send values of other types around. To satisfy this behaviour, we are going to create a struct that holds our work request.

Step 2: The collector

The collector is nothing special; it receives client requests for work, builds a work request that the workers can understand, and pushes the work onto the end of the work queue.

Ideally, the collector should be responsible for running sanity checks on the incoming work requests, and alert the client if their work request does not fit within whatever acceptable boundaries you define. We also do not want our collector to hold an open network connection for any longer than it has to. Again, this imposition is in the name of keeping things simple.

Our collector is going to be a simple, HTTP handler function that we can register with Go’s default HTTP server.

Now, in this snippet of code, we have WorkQueue defined as a channel that can be used to send WorkRequest objects around on, and it has a buffer size of 100 (one hundred).

The buffer size of the channel is completely arbitrary, but you want to set it high enough so that sending work requests over it does not fill up, and block the send operation: WorkQueue <- work.

Step 3: The worker

Now, we need to implement a worker. What the worker needs to have, is a channel of its own that the dispatcher (which we will implement next) can use to give the worker a WorkRequest. We are also going to give our workers a numeric ID, so that we can see which worker is performing the work.

The NewWorker function does nothing more than create a new Worker object, and return it. The lone argument to NewWorker is the buffered channel of un-buffered, WorkRequest channels. In the creation of the Worker object, we also giving the worker an un-buffered channel for it to receive the work requests on. Truthfully, we really don’t need this channel to be buffered. The reason for this is that the worker can really only do one thing at a time, and what we want here, is for the dispatcher to only give out work requests to workers that are idle, and waiting for work.

The QuitChan is also un-buffered, only because it doesn’t need to be. We avoid the blocking nature of un-buffered channels in the Worker.Stop function by wrapping the send in an anonymous goroutine; we will not block the call to Worker.Stop(), but the worker will stop when we want it to.

Step 4: The dispatcher

It is now time to implement our dispatcher!

Deceivingly simple, isn’t it? At the top of the file, we have declared, and initialized, our WorkerQueue which is the buffered channel that holds the work channels from each worker.

Remember, the worker is responsible for adding itself into the workers queue.

Within the StartDispatcher function (to which we provide the number of workers we would like to start), we initialize the WorkerQueue channel with a buffer size the same as the number of workers we are going to start.

Then, we create and start the workers. In the NewWorker function, the first argument is an integer, which we use as a numeric ID for the workers, so that we can see which worker is doing the work.

The final block of code, the anonymous goroutine, is what actually dispatches the queued work requests. We pull a work request off of the WorkQueue channel (which we declared and initialized in collector.go), then we then fire off another, anonymous goroutine to send the received WorkRequest object to the worker.

The reason we send the work request to the worker in another goroutine, is so that we make sure the work queue never fills up. Goroutines are wonderfully inexpensive things; they are not threads, we can start as many as we want, and the scheduler in Go’s runtime will perform its namesake task. With this approach, we can pull a work request off of the work queue, then send the work request to a worker, but the worker := <-WorkerQueue will block.

It may seem silly, but because goroutines are cheap, we can care more about making sure the work queue never fills up, and that we give work to the workers as soon as possible. We would rather block on receiving a work request, than sending a work request to a worker.

Step 5: Putting it all together

At this point, we have:

A collector that receives, checks, and queues work requests
A worker that does the work
And a dispatcher that pulls work off of the work queue, and gives it to a worker

The last thing we need to do is tie it all together!

The main function is the entry-point for Go, when you write an application. We are also allowing the user to specify how many workers they would like to run, and what address the HTTP server should listen on. Both of the command-line flags are optional, and we provide sane defaults.

Since we took care to make things as simple as possible in the other files of our application, all we need to do is start the dispatcher, register the collector to the /work endpoint (remember, our collector was just an HTTP handler function), and then start the HTTP server.

Building the application

Each code snippet provided in this post can be put into its own file, and by Go’s coding standards, they should be in their own files, as each snippet provides an functional piece of our application.

So, assuming you put each of these code snippets into their own file, you should have:

work.go which holds our WorkRequest struct
collector.go which has our HTTP handler function, and also declares and initializes our work request queue WorkQueue
worker.go which implements our Worker struct, its Start and Stop methods, and our convenience function NewWorker
dispatcher.go which is where we implement our dispatcher, as an anonymous goroutine in the StartDispatcher function
main.go, where we call the StartDispatcher function, register the Collector HTTP handler function, and start the HTTP server

To build the application (let’s call it queued), run the following command:

$ go build -o queued *.go

Now, to run our application, how about we start it with 2048 workers, just for kicks?

$ ./queued -n 2048
...
Starting worker 2047
Starting worker 2048
Registering the collector
HTTP server listening on 127.0.0.1:8000

Sweet! Now, in another terminal window, let’s write a little Bash one-liner, to flood our collector with requests:

$ for i in {1..4096}; do curl localhost:8000/work -d name=$USER -d delay=$(expr $i % 11)s; done

This one-liner, will loop for 2x the number of workers we defined, and upon each iteration, it will call curl(1) to make an HTTP POST request to localhost:8000/work passing along our username, and a delay, which is calculated as the modulo of our current loop iteration and the number 11.

I chose the number 11 here, because it will allow us to send work requests to the collector with delays from 0..10 seconds, which means we are also testing whether or not our sanity checking works.

In the terminal window where we had queued running, you should see a flurry of messages scrolling past. You may also notice, that the workers are running out of order! This is because we employed a “first-come/first-serve” type of queue.

In conclusion

Hopefully this article made sense, if it didn’t (or if there is a typo, or error somewhere), please feel free to hit me up on Twitter, or Google+. Heck, you could even create a new GitHub issue if you’d like!

Two-legged OAuth 1.0 calls, in Go

nicksaika@gmail.com (Nick Saika) — Tue, 17 Sep 2013 21:41:00 +0000

Half-way through last week, I stumbled across context.io and thought it would be pretty decent to write up a nice, small API client for Go!

I am going to skip over what exactly it is that context.io does. I provided a link above so you can check it out for yourself.

After signing up, I started to read through their documentation and discovered that they use OAuth to authorize any API requests. Cool beans! Yeah, well, first of all, it’s OAuth 1.0. Secondly, it’s two-legged OAuth 1.0.

A brief explanation of OAuth 1.0

What is “two-legged OAuth” you ask? Well, to really simplify it, OAuth is typically a “three-legged” authentication, and authorization procedure. When you go to enter into a conversation with an OAuth “provider” your application must have two things in its possession: a consumer token and a consumer secret. In the realm of shared-key encryption schemes, you pass around your token to vouch that a message came from you, but you keep the secret to yourself, as it is used in encrypting your communications, as well as allowing you to definitively say “yes, this message is from me”.

In the OAuth scheme of things, your application is what is referred to as the “consumer”.

The first leg of the OAuth conversation is when you approach the service provider (in this case, context.io) with your consumer token and secret, you are effectively asking to be authenticated; you are proving to the service provider that you are who you say you are.

The second leg of the conversation - assuming your initial authentication request succeeded - is the service provider responding with your access token and access secret. These are similar to your consumer token and secret, however, they are temporary and will expire after a certain amount of time. The access token and secret are used to sign and encrypt your subsequent requests to the service provider.

The third, and final, leg of the OAuth conversation is any request you make to the service provider, with your access token and access secret to authorize your request, before the access token and secret expire.

Expiry times on access tokens vary by service provider.

So, what is two-legged OAuth 1.0 then?

Armed with that knowledge, you are probably asking, “well, which leg is not used in two-legged OAuth?” The answer to that, is “the first one”. The initial authentication request is “skipped” because you are assumed to already have your access key/token and secret.

I feel it necessary to inform you, dearest reader, that this wasn’t an “out of the box” process. I cannot remember how I started trying to figure this out, but I think it involved looking at how the rauth Python library handled such things, mixed with various snippets of things I had come across online. The final solution to this issue could not have been reached without a teeny-tiny patch to the OAuth 1.0 package I used: github.com/mrjones/oauth.

I just want to gush for a moment: I love the fact that I was able to make the small change necessary to make this work, and that the maintainer of the library merged in my pull request so shortly after I made it. Open development is wonderful.

Here is a working example of making a two-legged OAuth 1.0 call:

package main

import (
    "fmt"

    "github.com/mrjones/oauth"
)

const (
    Key    = "4AxhC3QDTFPJXSUE"
    Secret = "v6U7Dvz2T5jtKzdmUEZPDWrtAjA5MGNR"
)

func main() {
    consumer := oauth.NewConsumer(Key, Secret, oauth.ServiceProvider{})
    accessToken := &oauth.AccessToken{}
    response, err := consumer.Get("http://some/remote/endpoint", nil, accessToken)
    fmt.Println("Response:", response.StatusCode, response.Status)
}

I am not going to explain most of this code, because I am assuming that you already know your way around the Go programming language, and that you are here to learn about making two-legged OAuth calls, in Go. It is rather apropos, but if the above code sample is leaving you baffled, you should really work your way through the Go tour, and then read Effective Go.

That aside, here are the strange things about the code above:

We already know our access token (also referred to as a “key” in some cases), and access secret, however we are providing it to the oauth.NewConsumer() function, which we would typically feed our consumer token and secret into
We are not specifying the service provider’s URLs that would typically tell the library where to fetch our request, authorization, or access tokens (we are leaving them all blank)
We are leaving our request’s access token and secret blank

In conclusion, this works, and I am not entirely sure how. Additionally, I would like to thank Matt Jones for having done most of the hard work by writing an OAuth library for Go, and also for responding so quickly to my pull request.