Tools for CLI Road Warriors: Remote Shells //at 19:44 //by abe

Most of my private online life happens on netbooks and besides the web browser, SSH is my most used program — especially on netbooks. Accordingly I also have hosts on the net to which I connect via SSH. My most used program there is GNU Screen.

So yes, for things like e-mail, IRC, and Jabber I connect to a running screen session on some host with a permanent internet connection. On those hosts there is usually one GNU Screen instance running permanently with either mutt or irssi (which is also my Jabber client via a Bitlbee gateway).

But there are some other less well-known tools which I regard as useful in such a setup. The following two tools can both be seen as SSH for special occassions.

autossh

I already blogged about autossh, even twice, so I’ll just recap the most important features here:

autossh is a wrapper around SSH which regularily checks via two tunnels connect to each other on the remote side if the connection is still alive, and if not, it kills the ssh and starts a new one with the same parameters (i.e. tunnels, port forwardings, commands to call, etc.).

It’s quite obvious that this is perfect to be combined with screen’s -R and -d options.

I use autossh so often that I even adopted its Debian package.

mosh

Since last week there’s a new kid in town^WDebian Unstable: mosh targets the same problems as autossh (unreliable networks, roaming, suspending the computer, etc.) just with a completely different approach which partially even obsoletes the usage of GNU Screen or tmux:

While mosh uses plain SSH for authentication, authorization and key exchange the final connection is an AES-128 encrypted UDP connection on a random port and is independent of the client’s IP address.

This allows mosh to have the following advantages: The connection stays even if you’re switching networks or suspending your netbook. So if you’re just running a single text-mode application you don’t even need GNU Screen or tmux. (You still do if you want the terminal multiplexing feature of GNU Screen or tmux.)

Another nice feature, especially on unreliable WLAN connections or laggy GSM or UMTS connections is mosh’s output prediction based on its input (i.e. what is typed). Per line it tries to guess which server reaction a key press would cause and if it detects a lagging connection, it shows the predicted result underlined until it gets the real result from the server. This eases writing mails in a remote mutt or chatting in a remote irssi, especially if you noticed that you made a typo, but can’t remember how many backspaces you would have to type to fix it.

Mosh needs to be installed on both, client and server, but the server is only activated via SSH, so it has no port open unless a connection is started. And despite that (in Debian) mosh is currently just available in Unstable, the package builds fine on Squeeze, too. There’s also an PPA for Ubuntu and of course you can also get the source code, e.g. as git checkout from GitHub.

mosh is still under heavy development and new features and bug fixes get added nearly every day.

Thanks to Christine Spang for sponsoring and mentoring Keith’s mosh package in Debian.

Update: I gave a lightning talk about Mosh and AutoSSH in German at Easterhegg 2012. The slides are available online.

autossh vs TCP resetter //at 00:08 //by abe

LUG-Camp 2007 in Interlaken is nearly over, and I’m reading my mail as usual using ssh, screen and mutt on the server. But the ssh connection resets every few minutes. According to the LUSC people (who are running the gateway) some script kiddie is running a TCP resetter somewhere in the network.

I remembered that I read about autossh in the Debian package list once a while and that it sounded cool but I had no use for it yet. Until now.

I’m writing this over the same crashing ssh connection and I’m typing without taking big notice of the quite often occurring connection resets:

autossh noone.org -t 'screen -rd'

It just works. :-)

SuSE sucks! //at 05:44 //by abe

Since SuSE closes the security support two years after release and the recent KDE JavaShit remote code execution hole wasn’t patched as fast as I would have expected it (the patch came out after the upgrade I’m writing about here) in the SuSE 9.0 which was installed on my 2.66 GHz AMD desktop at work (it started as in 2002 as a SuSE 7.3 on a 400 MHz box and has been upgraded since then to 8.0, 8.2 and 9.0 IIRC), I decided, it’s now really time to upgrade to SuSE 10.0. (Although 10.1 will be out soon, I just don’t want to wait for it.) And since my boss only wants SuSE boxes and neither Debian (which I would prefer) nor Gentoo (which a colleague prefers), I couldn’t simply install Sarge on this box although I would have chosen that option if it would have been available.

Since my former SuSE experiences told me that this would mean a lot of trouble, I took notes from the beginning, once for the blog and once for my boss to show him, that most trouble doesn’t come from me being a power user used to being allowed to touch any config file (like I am on Debian).

Preparations

So I begin with the preparations: Starting the 400 MHz Debian Woody box on my desktop (whose operating system is more than a year older than SuSE 9.0 and still has security support, yeah!) I usually need to build custom Debian packages for customers. There I could chat in IRC and took notes while trying to upgrade and get the whole thing working again.

When everything was ready, I put the SuSE DVD in — just to notice, that it’s just a CD-ROM. So I put the SuSE 10.0 CD1 in the CD-ROM drive and typed “sudo shutdown -r now” in the shell. The box starts shutting down and tells me:

Please stand by while rebooting the system…

But it didn’t reboot. I waited for several minutes, nothing happend. Well, seems as if the SuSE upgrade already starts as I expect it to end: Horrible.

Read more…

Screen and Emacsclient: Automatically switching to the Emacs window //at 10:38 //by abe

For a very long time, I use mutt with emacsclient as configured editor and a single GNU Emacs instance started from either .screenrc or .Xsession, depending on the system. And I’m very used to switching the virtual desktop or the screen window after starting a mail in mutt.

Since Debian 5.0 Lenny and Emacs 22, Emacs automatically grabs the focus and switches to the right virtual desktop. So after telling mutt recipient and subject of a new e-mail, it invokes emacsclient and immediately the focus has moved to the running Emacs instance. Because I was used to switch one virtual desktop to the right at that point, I often found my self two desktops to the right until I got used to it. :-)

I usually hate applications which grab the focus without being asked. But in this case I basically asked for it. And there’s no delay like with starting up an application which has to read in some database first – think of Liferea or Rhythmbox which take many seconds to minutes to start up, even on my 2.2 GHz dual core ThinkPad.

In the meantime I got so used to that automatic desktop switch that I forget to switch the screen window in the second scenario where I use this combination: My screen doesn’t automatically switch to the Emacs window (window 1) after I told mutt recepient and subject in window 2.

Knowing that screen is quite scriptable, I found out that only a very small change is needed to my mutt configuration to get that desktop feature to my everyday screen session. I simply replaced the editor setting in my .muttrc with the following line:

set editor="screen -X select 1;emacsclient"

Now mutt tells screen to switch to window 1 (where Emacs is running) and then tells Emacs to open the appropriate file to edit my new mail.

Update Friday, 2009-04-24, 18:22

Even though Zack surely is right with his comment about the multi-terminal feature of the upcoming GNU Emacs 23, I still have Etch (and therefore GNU Emacs 21) on the server where I have my screen session.

So the next step was to switch back to the mutt window (window 2) after I’m finished with editing the mail. Since mutt gives the the file to edit as argument to the contents of $editor, simply adding ;screen -X select 2 at the end of $editor doesn’t suffice.

So I wrote a small shell script (named ~/.mutt/editor.sh) as wrapper which calls all the commands and passes the parameters to the right command:

#!/bin/sh

screen -X select 1
emacsclient -a ~/.mutt/alteditor.sh "$@"
screen -X select 2

Of course, $editor is now set to that script:

set editor="/home/abe/.mutt/editor.sh"

Emacsclient of GNU Emacs 21 already supports the -a option to call another editor in case of not being able to connect to a running Emacs instance. Since I don’t want to switch to another screen window in that case, I wrote a second shell script (named ~/.mutt/alteditor.sh) which switches back to the mutt window and then calls GNU Zile, my preferred low-end emacs clone:

#!/bin/sh

screen -X select 2
zile "$@"
screen -X select 1

I love it!

How I use my virtual desktops //at 00:29 //by abe

Many months ago I stumbled upon this German written meme about how users use their virtual desktops. I use virtual desktops since my very early Unix times (tvtwm on Sun Sparc SLC/ELC/IPX with greyscale screens running SunOS 4.x), so in the meantime I use them nearly everywhere the same way.

Short Summary

3x5, no overlapping windows, either tiling or fullscreen, keyboard navigation, xterms, yeahconsole, FVWM, panel for systray.

Window Manager of Choice

My window manager of choice is FVWM since more than a decade. I tried others like Sawfish, Metacity and Compiz, but I couldn’t get them behave like the FVWM I got used to, so I always came back.

Since I hate overlapping windows, I use FVWM a lot like a tiling window manager. FVWM has this nice function to maximize windows so that they occupy as much space as available, but do not overlap other windows. This function was also often missing when I tried other window managers. I though do not want to use real tiling window managers since I have a few sticky windows around (e.g. the panner with the virtual desktops and xosview) and they shouldn’t be overlapped either.

Virtual Desktops

Switching between virtual desktops is done with the keyboard only – with Ctrl-Shift as modifier and the cursor keys. The cursor keys are usually pressed with thumb, ring and small finger of the right hand. Which hand presses Ctrl and Shift depend on the situation and keyboard layout, but it’s usually either ring and small finger of the left hand, or pointer and middle finger of the right hand. So I’m able to switch the virtual desktop with only one hand.

I have always three rows of virtual desktops and usually four or five columns.

The top row is usually occupied with xterms. It’s my work space. The top left workspace usually contains at least one xterms with a shell and one with mutt, my favourite e-mail client since nearly a decade. At home the second left virtual desktop in the top row usually contains a full-screen Liferea (my preferred feed reader) while at work it contains the GNU Emacs main window besides two xterms. Emacs and the emacs server are automatically started at login.

This also means that I switch the virtual desktops when I switch between mutt and Emacs for typing the content of an e-mail. Did this already during my studies. (At home mutt runs inside a screen, so there I just switch the virtual terminal with Ctrl-A Ctrl-A instead of the virtual desktop. Not that big difference ;-)

The other virtual desktops of the the top row get filled with xterms as needed. Usually one virtual desktop per task.

The middle row is for web browsers. One full screen browser (usually Conkeror or Opera) per virtual desktop, often opened with many tabs (tabs in Opera, buffers in Conkeror) related to the task I’m accomplishing in the xterms in the virtual deskop directly above.

The third row usually contains root shells for maintenance tasks, either permanently open ones on machines I need an administrate often (e.g. daily updates of Debian testing or Debian unstable machines), or for temporary mass administration (Linux workstations on the job, all Xen DomUs of one Xen server, etc.) using pconsole.

yeahconsole

Additionally I have a sticky yeahconsole running, an xterm which slides down from the top like the console in Quake. (It’s the only overlapping thing I use. :-) My yeahconsole can be activated on every virtual desktop by pressing Ctrl-Alt-Z (with QWERTY layout, Ctrl-Alt-Y with QWERTZ layout). It’s the terminal for those one-line jobs then and when, e.g. calling ccal, translate, wget or clive.

Changes over time

Of course the desktop usage changes from time to time:

At work I have more than one monitor, so in the meanwhile the second row with the web browsers “moved” to the second screen – with independent virtual desktops (multiple X servers, no Xinerama). The second row on the main screen at work is now used the same way as the third row with a slight preference for the permanently open shells while the third row is more used for mass administration with pconsole.

At home I used XMMS respective Audacious for a long time (my FVWM panner and xosview are exactly as wide as WinAmp2/XMMS/Audacious, guess why:-) which usually was sticky the same way as the panner and xosview are. But when I started using last.fm recently, I moved to Rhythmbox (after testing some other music players like e.g. Amarok) which I use in fullscreen as I do with web browsers and the feed reader. So it occupies a complete virtual desktop, usually the second one in the middle row – below the feed reader because I don’t need a corresponding web browser for the feed reader. (Just found out that there is a last.fm player for text-mode, so maybe that will change again. :-)

Another thing which changed my virtual desktop usage was the switch from a classical tabbed web browser (Galeon, Kazehakase, Opera) to the buffer oriented Conkeror. With a tabbed web browser I have either no overview over all open tabs (one row tab bar or truncated tab menu) or they occupy too much space of the browser window. That was another reason for more than one browser window and therefore more than one virtual desktop with fullscreen web browser windows. With Conkeror tabs are optional (and not even enabled by default), Conkeror uses buffer like Emacs and if you want to switch to another buffer, you press C-x b and then start typing parts of the buffer’s name (e.g. parts of the URL or the web page title) to narrow down the list of buffers until only one is left or until you have spotted the wanted buffer in the list and choose it with the cursor keys. So the need for more than one browser window is gone.

For a long time I didn’t need any task/menu/start/whatever bar on my desktop. But since neither NetworkManager nor wicd have a comand-line interface (yet) and bluetooth seems also easier handled from the system tray my laptops also use either gnome-panel (big screen, long sessions with FVWM) or lxpanel (formerly used trayer; use it on small screen, short sessions with ratpoison or matchbox) on my laptops. It’s sticky and always visible. (No overlapping, remember? ;-)

The panel is usually at the bottom on the screen as by default with Windows or KDE, not at top as with GNOME and MacOS. Only on the OpenMoko, I have the panel at the top to be close to what I’m used from Nokia mobile phones.

Things I tried …

… but didn’t survive in my setup:

• Desktop icons – nearly always covered if you use a tiling window manager. (I though use root window menus – mostly for starting applications later occupying that space where I clicked. ;-)
• A button to minimize all windows. Only sissies without virtual deskops need that. ;-)
• Automatically scrolling logfile content on the desktop (root-tail, root-portal, etc) – the space was too precious to not use it for xterms or web browsers. ;-)

Systems without Virtual Desktops

Anyway, there are systems where I don’t use virtual desktops at all. On systems with a screen resolution so small that there’s not enough space for two non-overlapping, fixed font 80x25 xterms on the screen (e.g. on my MicroClient with 8” touch screen, the 7” EeePC or the OpenMoko) I do not use virtual desktops at all. On such systems I use all applications in fullscreen, so switching between applications is like switching virtual desktops anyway. My window managers of choice for such systems are ratpoison for systems with keyboard and matchbox for system without keyboard. With ratpoison you treat windows like terminals in GNU screen, so there are no new keybindings to learn if you’re already used to screen (which I use nearly daily since more than a decade).

I love and hate Unicode //at 02:30 //by abe

When I first saw Joey’s wish for a Unicode bumper sticker, I just parsed

as a little bit sarcastic »I ♥ Unicode«, but when nion posted it, too, I noticed, that it may also be read as »I ☠ Unicode«. Maybe, that this — both — is exactly what Joey intended to say, and I have to acknowledge this: I hate Unicode in my mutt since Sarge because it doesn’t work with screen out of the box anymore, and I hate Unicode in my Emacs since Emacs 20 because it screws up everything. But I love Unicode in my irssi and on the web. Strange world. But this virtual bumper sticker expresses that feeling somehow perfectly.

Bei manchem Spam ist man froh, daß SpamAssassin ihn nicht erwischt… //at 01:38 //by abe

Mir ist zwar noch nicht klar, warum der SpamAssassin diesen Spam nicht erwischt hat, aber ich bin froh drüber. Denn diese automatisierte Übersetzung ist zum totlachen:

Date: Wed, 21 Sep 2005 13:17:30 +0000
Subject: LifeProfit Inc.
X-Spam-Status: No, hits=1.6 required=5.0 tests=BAYES_44,DNS_FROM_RFCI_DSN,
        HTML_MESSAGE,MIME_BOUND_NEXTPART,MIME_HTML_NO_CHARSET,NO_REAL_NAME
        autolearn=no version=2.64

LifeProfit Inc. kann Ihnen helfen, Ihre Traume zu zwingen, sich, bekommend
das monatliche Gehalt, das das Internet einwirkt, zu verwirklichen.

Um mit LifeProfit Inc. zu arbeiten, brauchen:
? Ein B?rger Deutschlands zu sein
? das Vorhandensein der Rechnung in der Bank
? die Vereinigung des Computers zum Internet
? ist ein wenig es Ihre freie Zeit

Wie es arbeitet:

Arbeitend f?r uns wie die Bezahlung, Die den Manager bearbeitet, werden Sie
Teil Aus der neuen Tendenz im weltumfassenden Banksystem. Die Pflichten Die
Lage ist einfach, und das Einkommen hangt nur von Ihren Bem?hungen ab.

Sie Sollen - die Zahlungen der Sendung zwischen unseren Kunden, die Ihr
Interesse von jeder Operation bekommen, machen.
Hauptsachlich werden es 5 %, mit jeder Sendung, die Ihr Interesse z?chten
wird. Unsere Kunden bekommen 1000 EURO zu 20000.

www.lifeprofit.com

LifeProfit Inc. sorgt sich um Ihr Bl?hen. Machen Sie Ihr Leben besser
zusammen mit der LifeProfit Inc.!

Und daß Postbank und Deutsche Bank jetzt zur Deutschen Postbank fusioniert haben, weiß ich auch erst seit dieser netten Mail:

From support@deutsche-bank.de Tue Sep 20 21:53:14 2005
From: PostBank <support@deutsche-bank.de>
Date: Tue, 20 Sep 2005 15:45:19 -0400
Subject: PostBank online banking
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-Spam-Level: ****
X-Spam-Status: No, score=4.7 required=5.0 tests=BAYES_50,FORGED_OUTLOOK_HTML,
        FORGED_OUTLOOK_TAGS,HTML_MESSAGE,MIME_HTML_ONLY,RATWARE_RCVD_PF
        autolearn=no version=3.0.2

[-- Attachment #1 --]
[-- Type: text/html, Encoding: quoted-printable, Size: 3.3K --]

[-- Autoview using /usr/bin/lynx -dump -force_html '/home/abe/Mail/tmp/muttu0uPo7' --]

   Sehr geehrte Damen und Herren,
   In Verbindung damit, daß wir in unserem Land in eine schwierige
   Situation mit online - Banking geraten sind, wurde uns empfohlen, alle
   online - Konten von unserer Bank zu kontrollieren, um die
   "Tageskonten" festzustellen, die von den Betrügern dazu benutzt
   werden, das gestohlene Geld zu waschen. Demzufolge bitten wir unsere
   Kunden inständig, das Formular einer Kontobestätigung, das sich auf
   unserer offiziellen Web-Seite befindet, auszufüllen.
   Jene Konten, die bis zum 27.08.05 auf diesem Formular nicht angegeben
   werden, werden bis zur Feststellung der Bedingungen ihrer Eröffnung
   und Benutzung blockiert. Diese Revision betrifft sowohl die
   Privatkunden, als auch die Firmenkunden.

   Wir bitten um Verzeihung für die Unannehmlichkeiten, die wir Ihnen
   bereitet haben, wir hoffen auf Ihre Hilfe und gegenseitiges
   Verständnis.
   Mit freundlichen Grüßen,
   Sicherheitsabteilung,
   Postbank.de
      © 2005 Deutsche Postbank AG

References

   Visible links
   Hidden links:
   1. http://postbanking.net/

[-- Attachment #2: Enkidu.gif --]
[-- Type: image/gif, Encoding: base64, Size: 2.8K --]

[-- image/gif is unsupported (use 'v' to view this part) --]

[-- Attachment #3: fray.jpg --]
[-- Type: image/jpeg, Encoding: base64, Size: 37K --]

[-- image/jpeg is unsupported (use 'v' to view this part) --]

Klasse, nicht?