vkz

Tailscaling git.ht

This [hoot][] you're about to read started its life as a gist of technical minutae I had to discover to Tailscale cloud and on-prem resources. It'd be too boring for me to just publish it, so I thought I'd give a little bit of context as a preamble. I get to rant some and you can simply skip to the technical sections below if you'd rather not indulge me.

Ranty preamble

How much of what AWS gives you do you really truly need? It's become Kubernetes this, Docker that. I rarely question it when contracting because contractors usually arrive after the fact to pick up and carry the pieces. You get to target the infrastructure that may as well have been installed by alients before humankind ascended in Amazon. All in the cloud, can't touch, jumpbox this, terraform that, re-create the world every time you sneeze, etc. It's different when you're hired fo

vkz

What if ...

sharing your

• thoughts and
• findings

with others was as simple as writing a Github gist?

Got gists?

vkz

What if ...

sharing your

• thoughts and
• findings

with others was as simple as writing a Github gist?

Got gists?

vkz

vkz

Calibrating and troubleshooting your web-server (Jetty) performance

Before [git.ht][] got released I thought it'd be good to get an estimate of how much load it could handle. rps is the obvious first mentric that comes to mind, but then I caught myself thinking that I honestly had no idea what it was supposed to be. My brain wasn't calibrated to even make a guess. I did make a guess and as always it turned out way off. What do you expect it to be? 1K? 5K? 50K? 100K? 1mio?

What follows isn't some comprehensive blogpost but rather a [hoot][] - a gist of my findings and observations at the time - the kind of impromptu publication [git.ht][] was created for. Don't expect any deep insights or thorough analysis.

To give some context. This was pretty vanilla Clojure ring with Jetty project. Nothing fancy. Well, almost. This did rely on my homegrown web cough framework *cou

vkz

How to debug web resource routing behind a load-balancer

Assume we have a web-server deployed on-prem behind AWS Application Load Balancer. AWS's docs re [how elastic load balancing works][] is the best source of info re balancing. Note, that ELB requires at least two nodes, but ideally as many as many availability zones in your region. London has 3, so lets go with that. What this means is that ELB is in fact 3 EC2 instances doing the load-balancing.

Ore setup:

1. ELB in eu-west-2 (London) with 3 availability zones, each with an instance of our ELB.
2. Web server serving our website on prem accessible via Tailnet IP address.
3. Each availability zone runs a Tailsale relay nano-instance, so that ELB may have access to our on-prem server via Tailnet.
4. Each subnet (each availability zone gets its own subnet by default) has a routing table (defined via VPC console) that routes Tailnet 100.64.0.0/10 to a tailnet-relay instance deployed in that subnet.
5. Target group, with our taillnet on-prem IP address

vkz

test gist

vkz

# Space is Shift modifier when pressed with any other key, usual SPACE otherwise

# https://github.com/alols/xcape
# only works in X

# Map an unused modifier's keysym to the spacebar's keycode and make it a
  # control modifier. It needs to be an existing key so that emacs won't
  # spazz out when you press it. Hyper_L is a good candidate.
  spare="Hyper_L"
  xmodmap -e "keycode 65 = $spare"

vkz

status_cmd();
^
bld/checkin.h:260:1: error: conflicting types for 'status_cmd'
bld/checkin.h:258:6: note: previous declaration is here
void status_cmd(void);
     ^

vkz

  (defn apply-to-column-n
    "Apply f only to column N in each table row. Columns start from column 1.
  Gracefully do nothing for rows that are too short."
    [f N table]
    (map (fn [row]
           (map (fn [n cell]
                  (if (= n N)
                    (f cell)
                    cell))
                (drop 1 (range))