Location: Larnaca International Airport
“Why I left my new MacBook for a $250 Chromebook” is a nice write up of a new Chromebook user. Even though I don’t own a MacBook (or any Mac products for that matter), I have been considering a Chromebook for a while now too.
My biggest concern is obviously programming and system administration tools – editors, terminals, remote access, etc. But it’s getting there.
Apart from the experiences and wishlists, I found these two links useful:
- SnoozeTab, which I just installed and will keep an eye on for the next few days.
- 10 best Chromebooks 2016: top Chromebooks reviewed, which I will use as my shopping guide.
Here is a tutorial that will come handy one day, in the moment of panic – How to Recover an Unreachable Linux Instance. It has plenty of screenshots and shows each step in detail.
- Start a new instance (or pick one from the existing ones).
- Stop the broken instance.
- Detach the volume from the broken instance.
- Attach the volume to the new/existing instance as additional disk.
- Troubleshoot and fix the problem.
- Detach the volume from the new/existing instance.
- Attach the volume to the broken instance.
- Start the new instance.
- Get rid of the useless new instance, if you didn’t reuse the existing one for the troubleshooting and fixing process.
Git from the inside out – must be the best thing I’ve ever seen on how git works. Everybody knows that git is awesome. Most know that git is implemented with graphs. But not many know how exactly git stores the project history and how it is affected by different git commands.
And if you are feeling adventurous, there is this:
Which, among other things, includes “Git in six hundred words“.
It never ceases to amaze me how even after years and years of working with some technologies I keep finding out about super useful features in those technologies, that could have saved me lots of time if I knew about them earlier. Today was a day just like that.
I was working on the Ansible setup for a new hosting environment. One particular thing I wanted to utilize more was a bastion host – a single Linux machine with exposed secure shell (SSH) port, which will be used for managing the configurations of all the servers within the environment. I sort of done that before, but the solution wasn’t as elegant as I wanted it to be.
So, I came across this article – Running Ansible Through an SSH Bastion Host. Which, among other things taught me about a feature that I didn’t know nothing about. Literally. Haven’t even heard about it. Multiplexing in OpenSSH:
Multiplexing is the ability to send more than one signal over a single line or connection. With multiplexing, OpenSSH can re-use an existing TCP connection for multiple concurrent SSH sessions rather than creating a new one each time.
This doesn’t sound too useful for when you are working in command line, one server at a time. Who cares how many TCP connections do you need? It’ll be one, or two, or five. Ten, if you are really involved. But by that time you’ll probably be running background processes, and screen or tmux (which are apparently called “terminal multiplexers“).
It’s when you are going deeper into automation, such as in my case with Ansible, when you’ll need OpenSSH multiplexing. Ansible, being a configuration manager, can run a whole lot of commands one after another. It can run them on multiple servers in parallel as well. That’s where reusing the connections can make quite a bit of a difference. If every command you run connects to the remote server, executes, and then disconnects, you can benefit from not needing to connect and disconnect multiple times (tens or hundreds of times, every playbook run). Reusing connection for parallel jobs is even better – and that’s a case with bastion host, for example.
Here are a few useful links from that article, just in case the ether eats it one day:
- Empowering OpenSSH
- Using SSH Multiplexing
- Managing OpenStack instances with Ansible through an SSH bastion host
Armed with those, I had my setup running in no time. The only minor correction I had to do for my case was the SSH configuration for the bastion host. The example in the article is NOT wrong:
Host 10.10.10.* ProxyCommand ssh -W %h:%p bastion.example.com IdentityFile ~/.ssh/private_key.pem Host bastion.example.com Hostname bastion.example.com User ubuntu IdentityFile ~/.ssh/private_key.pem ForwardAgent yes ControlMaster auto ControlPath ~/.ssh/ansible-%r@%h:%p ControlPersist 5m
It’s just that in my case, I use hostnames both for the bastion host and the hosts which are managed through it. So I had to adjust it as so:
Host *.example.com !bastion.example.com ProxyCommand ssh -W %h:%p bastion.example.com IdentityFile ~/.ssh/private_key.pem Host bastion.example.com Hostname bastion.example.com User ubuntu IdentityFile ~/.ssh/private_key.pem ForwardAgent yes ControlMaster auto ControlPath ~/.ssh/ansible-%r@%h:%p ControlPersist 5m
Notice the two changes:
- Switch of the first block from IP addresses to host names, with a mask.
- Negation of the bastion host configuration.
The reason for the second change is that if there are multiple Host matches in the configuration file, OpenSSH will combine all options from the matched configurations (something I didn’t find in the ssh_config manual). Try this example ssh.conf with some real hosts of yours:
Host bastion.example.com User someuser Host *.example.com Port 2222
You’ll see the output similar to this:
$ ssh -F ssh.conf bastion.example.com -v OpenSSH_7.2p2, OpenSSL 1.0.2h-fips 3 May 2016 debug1: Reading configuration data ssh.conf debug1: ssh.conf line 1: Applying options for bastion.example.com debug1: ssh.conf line 4: Applying options for *.example.com debug1: Connecting to bastion.example.com [188.8.131.52] port 2222. ^C
Once you negate the bastion host from the wildcard configuration, everything works as expected.
You might also try using “%r@%h:%p” for the socket to be different for each remote username that you will concurrently connect with, but that’s just nit-picking.