Packing lighter for travel

or “I regret ever ounce I am carrying. I think this is working correctly.”

On my most recent trip, I decided to carry hand luggage only. Specifically, bags that have no wheels. And to limit it even more, when I left, I was only carrying one bag.

Within a day, I regretted packing all this stuff. I’m choosing to use this as a learning experience.

On this trip, I packed the following ‘gadgetry’:

  • Laptop (usb-c)
  • Tablet with keyboard (usb-c)
  • Kindle (micro-usb)
  • Cell Phone (usb-c)
  • Backup Cellphone (usb-c)
  • Laptop Charger (usb-c)
  • Two port phone charger (usb-c)
  • Cabling to connect all of the devices to both chargers and other devices

What I should have packed:

  • Laptop (usb-c)
  • Cell Phone (usb-c)
  • Backup Cell Phone (usb-c)
  • 2 Laptop chargers (usb-c)
  • cables to connect laptop to phones (usb A to C)

The tablet and kindle have been entirely unneeded. The kindle has been light enough, but the tablet is heavy. Ultrabook laptop heavy. In addition, the cabling to both charge and connect these devices is heavy. Finally, the two port phone charger is entirely redundant, and does not charge the laptop while it’s being used, only while the laptop is sleeping or off.

The laptop charger is capable of charging the phones and the laptop. At night, the single charger can charge the laptop and the phone through the laptop.

The only time the tablet and keyboard for the tablet become viable is if you are using it as a complete replacement to the laptop. I expect I can make this a reality eventually, but not right now.

Contingencies:

An astute reader may have noted that I have a backup cell phone listed above. The core element of packing light that I need to get my head around is that your backup is money. The vast majority of problems you encounter can be solved with money. This is, to say the least, uncomfortable for me. I carry a backup cell phone because I can’t walk into any store and get a replacement Google Fi device. I can, however, carry a spare cell phone with me that I can bring online with Google Fi rapidly.

Having a large number of devices that charge on USB-C makes the backup charging problem easier. If I just carried two laptop chargers, everything can charge off of them, and I don’t have to worry about one of them breaking at an unexpected time. I’ve seen good reviews regarding Dart but those appear to be unobtainable right now.

On the contingency front, I need less clothing than I think. I have at least 2 too many shirts with me, and too many pairs of boots. You need one pair of good boots. That’s it. Also, learn to dress and operate in layers, rather than alternate clothing. Two t-shirts is easier and more versatile than an t-shirt and a flannel shirt.

Just one notebook is enough. I like notebooks that can also double as file folders to protect papers, something hard backed, that way it’s one less item to carry.

I went uncomfortably light packing this trip, and I think I can make it even more uncomfortably light, and enjoy the results, with just a little more work. Better planning next trip, I suppose.

HAProxy, Chrome, tcp-preconnect and error 408

This is my guide to making haproxy work reasonably with the deployment model I’m constructing.

In broad strokes, I’m looking to have haproxy running on a host which is acting as an http and https front end for a large number of web servers living on a private network, each hosting an individual web site.

But first I had to make haproxy work with the modern web browser Chrome.

Starting with default settings led to a series of werid failures, where I would either get flashes of grey blank pages while loading, or error pages loaded when I clicked on content that I knew existed. Of course, this wasn’t generating logs on the webserver, and the logs from haproxy were equally weird, with nothing showing up that was temporally aligned with the action that created the result.

I knew this couldn’t be a just me problem yet. That generally takes me a few more hours of digging into a corner nobody else has ever gone into.

So off to google I go and type “haproxy chrome” and it suggests “haproxy chrome 408”. Well, that’s an omnious sign.

The first hit is https://www.haproxy.com/blog/haproxy-and-http-errors-408-in-chrome/ which starts to explain what’s going on.

Related is this Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=377581

A brief aside. Standing around with provisional sockets open burns resources on the server and the client, all for a few round trips of latency in client reaction. Well, I can totally understand reducing client latency by 1.5 round trips, but getting broken pages back, when I click links is a terrible result. Additionally, responding with a error when you’ve never seen a request is a wonderfuly grey area of the http spec, as noted in the chromium issue.

Why would google think this isn’t a big deal? Based on @dakami’s Defcon presentation from 5ish years ago, he was scanning the internet and realized that only one side of the connection actually had to keep state. His high volume scanner decided to be the side of a tcp link that wasn’t keeping state. This worked great, until he scanned google, where he discovered that google isn’t actually tracking state for tcp either. TCP doesn’t work right when neither party is tracking state. That said, there’s the reason provisional connections aren’t considered a big deal. If your tcp stack doesn’t keep state for clients on the internet, there’s no cost for having them open provisional sockets. So, it all hangs together, I don’t know that it’s offical reasoning.

This commment is enlightening as well: https://bugs.chromium.org/p/chromium/issues/detail?id=377581#c47
The implication I see in this is that you’ve added a new race condition, the question of what’s a ‘fresh socket’. That’s likely a timeout of some sort, or an event of some sort, but that’s not clear.

Right then, what to do about it.

As of December 2017, when I’m writing this, HAProxy 1.7.9 has the following configuration option:
https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#option%20http-ignore-probes
which fixes most things.

Is this perfect? No, the hiding of timeouts in the logs can cover up all sorts of errors and hides actual activity. Additionally, I experience flashes of the grey error page when Chrome has to re-connect to the server because it used an already closed socket.

It seems Chrome will only sit on a provisional socket for 5 minutes, so if you are willing to carry the load of idle client sockets for 5 minutes, I’d suggest also setting your timeout client to more than 5 minutes. Current chrome will open up to 6 sockets to a server. So scale the number of sockets you are willing to let sit idle accordingly.

That said, that still can create failures, because if your server timeout isn’t as long, the live client connection might be attached to an already timed out server socket, thus requiring the whole error 408 thing again. Thus you need to set your server timeouts to be just as long, and that means possibly holding open sockets on the servers for the same length of time. I suspect this is one case of what is being covered in the manual by “it is highly recommended that the client timeout remains equal to the server timeout in order to avoid complex situations to debug.” – https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4.2-timeout%20server

Summary:
If you are running small websites ( 1 server or less of load, and less than 100 simultanious clients), I suggest the following settings.

timeout server 302s
timeout client 302s
timeout connect 10s
option http-ignore-probes

Other things that I learned along the way:
The first work around was to make the error 408 page /dev/null, resulting in no data being forwarded to chrome and triggering a reload. That still works to some extent.
You can get haproxy to serve single static small pages by declaring them to be a backend at a particular url on error 200. This is a terrible plan.

Migration to WordPress

Since I have a new job where I’m running several hundred WordPress sites, I decided I should seriously dogfood this plan.   The infrastructure running this blog is now a small scale version of the stuff I’m building for work.

Expect experimentations.  Disruptive diagnostics will happen here.