Warning: this post is intensely technical, bordering on arcane. It’s about improving your user-experience as a command-line user on remote Unix-like systems. As such, it’s probably not intended for you, but my hope is that someone else will find it useful. The usual geeky stuff (food, travel, language, etc.) will follow again soon.
If you ARE the someone else, score!
Ours is a pretty geeky apartment. But we don’t always just stay there at home; often our geekery needs to travel with us.
- I’ve got five computers running some flavor of Unix (I’m counting Macintosh computers among those) at home in the apartment, 2 of which can travel with us and three of which stay in the apartment (two desktops and a tiny fileserver/webserver/webproxy). Some of them stay running while we’re out traveling.
- I’ve got a mifi we can use while traveling inside of Germany.
- I’ve got web hosts which allow/require me to use the command line to make certain kinds of updates to the design and functionality of this site and others.
- Cellular coverage in Germany along the train lines (around here, anyways) is lousy, even on the major carriers like Telekom and Vodafone. Don’t get me started on O2‘s network coverage in Regensburg (seriously, I can’t believe that people actually give them money).
- Sarah and I both still use an old-school bulletin board system (perhaps partially for sentimental reasons) via the command line.
All of these things add up to annoyance with slow network speeds for command-line tasks. You type a character on the keyboard, and during the time it takes to register that input and show it to you on the screen, you’ve hit that key several more times. Or you’ve tappy-tap-tapped merrily away and spot the typo only after the big stream of text finally registers on the remote machine and is echoed back to you. Correcting that typo may not be feasible.
Oh crap, I meant "all good men" of course, but on this entirely pokeyyyy
connection via command line it’s too much of a PITA to bother trying
to correct it.
~
~
~
~
— INSERT — 1,14 All
Enter mosh, the mobile shell. It’s designed specifically to make slow internet connections on the command line less annoying, without sacrificing anything in terms of security. It features an intelligent local echo, meaning that it will detect when your connection has taken a snooze and show you the results of the keys you’ve pressed in the meantime. Apparently you can even put your computer to sleep and wake it up on another network later, and mosh resumes the connection where you left off. I haven’t tried that aspect of it, but I am looking forward to it.
Prerequisites
- SSH: mosh runs on top of SSH, enhancing it and correcting known problems in it. But you can’t run mosh without it.
- UDP ports: at least one UDP port in your firewall, if you don’t have one you can use already available. Mosh expects to be able to use a random UDP port between 60000 and 61000 for each session by default, but you can make it work with an explicitly named UDP port via a command-line argument.
- UTF-8 locales: mixing 8-bit and multi-byte input can result in mild errors on fancy international characters (at best) or a bricked terminal window (at worst). Part of mosh’s approach to this is making sure all parties are on the same page, namely UTF-8. While getting it set up, this was the point that caused me the most hassle. In fact, I’m still not happy with changing my locale settings on the local machine to make mosh work with the remote machine. But it seems the developers are aware of this fly in the ointment.
- If you run SSH on a non-standard port (i.e., not on port 22), then you need the latest (as of this writing) version of mosh. The version in the Ubuntu repositories is 1.1.3-1; you’ll need to get version 1.2 or greater. I had to compile it from source, and THAT meant I had to install a few other packages, too.
Of particular note: mosh runs in user-space; you don’t have to set it up as a daemon or be root (you just have to make a UDP port available to it). That also means it’s not sitting around running on your server, waiting for you to use it. It only starts on the server when specifically called from the client. As such,you can run the mosh-server from your home directory or elsewhere if you don’t own the server machine, like this:
(In fact, I do own the server “bigmac,” but for whatever reason, installing the mosh package from macports.org put the mosh stuff in /opt/local/bin
instead of /usr/local/bin
— not sure if that’s supposed to be that way, or something that I caused when I installed macports. Either way, I can get around it with the client-side argument containing the path to the server-executable.)
It’s easy to tell mosh to use an arbitrary port for the SSH connection, too (starting with mosh version 1.2):
(And if you put a host-specific port parameter into your ~/.ssh/config
file, mosh will use that port, thereby keeping mosh and SSH consistent in the way you start them.)
Most of the time these days, dev work on the go is doable via GUI tools running locally, and sychronize local changes with the remote machine for you in a batch. But sometimes, there’s no substitute for logging in at the server and looking around in the logs directly or tweaking a config file. SSH is already really good for that. By reducing the effects of the lag associated with high latency networks (like via your cellular modem or crappy hotel WLAN), mosh makes it even better.
Could have used this five years ago, when in emergency I did have to maintain machines over iffy connections. Nowadays we’re in a BigCo network with all Windows on the other end. Not as much fun….
To make up for it I use homebrew for my *nix tools. Feels slightly more geeky to call a compiler than just install packages. :-)
I bow down to honor your geekdom.
If the compilation instructions are more complicated than
$ make
$ make install
…I’m lost, never having had serious programming experience.
Sorry it’s all Windows at work for you now.
I didn’t say I was calling the compiler myself! :-) It’s just
$ brew install foobar
and watch the compiler messages go by…
And here the link to Homebrew (an alternative to MacPorts): http://mxcl.github.com/homebrew/
Ooh, shiny!
I keep a Mac Mini running 24/7 for those need-to-ssh moments. Homebrew looks pretty fantastic for my usage pattern.
(Although, admittedly, most of what I use it for is to stream my iTunes collection to my work PC over an ssh tunnel.)
Interesting, I finally got a chance to play with it after getting my employer to install the server side component.
I have had times where I have needed this, but like brother Scott, now is not one of them. Maybe when I am travelling and subject to a slower interent I will need it more.
I like the way it underlines the text that has only been locally echoed. I also like that it even works inside a remote emacs session (make sense, but good to check/know).
The disappointing surprise is that it breaks scrollback. In other words, if I do an ls and the results scroll off of the top of the screen, I lose what was scrolled past. This is a known issue, my current-workaround is to pipe results to a pager like less (the recommend using screen). Hopefully there will be a fix/better answer in the future:
https://github.com/keithw/mosh/issues/122