I have been using CDM to log into X on my Arch machines and, if I were to continue to require the ability to access different window managers with any frequency, I would use this approach. However, on my EeePC, I really only ever login to a dwm session or the console, so having a login manager seemed like an unnecessary step.

Consequently, over the weekend, with the help of the Start X at Boot article on the Arch Wiki, I removed CDM and arrived at a secure, flexible approach to logging into X (or the console).

My /etc/inittab already boots me into runlevel 5:

1
2

# Boot to X11
id:5:initdefault:

So it was just a case of putting a couple of lines in the correct invocation file. I chose $HOME/.bash_profile because I only use Bash; if you use another shell you should probably go with $HOME/.profile. The recommended lines from the Arch Wiki are:

1
2
3
4
5

if [[ -z $DISPLAY && $(tty) = /dev/tty1 ]]; then
  exec startx
  # Could use xinit instead of startx
  #exec xinit -- /usr/bin/X -nolisten tcp vt7
fi

…and this works as advertised. If you are in TTY1 and you login, X is started. The disadvantage for me, though, was that when you shutdown, you must manually change to TTY7 (if that is your last agetty) to see the shutdown messages.

After rummaging around through various man and web pages, I finally alighted on this helpful option: -novtswitch. So, my entry to start X now looked like:

1
2
3
4
5

# startx if on tty1
if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then
    exec xinit -- :0 -novtswitch &>/dev/null &
    logout
fi

Now, on shutdown and reboot, I see all of the shutdown messages. All that remained was to add an option to log into a tmux session if I didn’t want to use X. The final code looks like this:

1
2
3
4
5
6
7

# startx if on tty1 and tmux on tty2
if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then
    exec xinit -- :0 -novtswitch &>/dev/null &
    logout
elif [[ $(tty) = /dev/tty2 ]]; then
    tmux -f $HOME/.tmux/conf new -s secured
fi

Logging in from TTY1 takes me into my dwm session, if I switch to TTY2 I am logged into a tmux session with keychain running. To start consolekit with dwm, I have this in my $HOME/.xinitrc:

1

exec ck-launch-session $HOME/Scripts/dwm-start.

You can see my full $HOME/.bash_profile in my mercurial repo.

Updated 4/2/12

For various reasons, I moved my environment variables from $HOME/.bashrc into $HOME/.profile; this meant that these variables were only inherited in interactive shells if xinit was called with exec.

I have also ditched consolekit - for all of the processes it was spawning, it actually wasn’t performing any critical functions; or indeed any functions that I really needed at all…

I recently threw caution to the wind and changed my shell over to vi mode. I wanted to take advantage of the superior command editing ability that this mode offered, and also to continue to bake vi[m] methods into every aspect of my working environment.

The change has been relatively straightforward; the only issues I have experienced are really just around a couple of keybinds that I had become accustomed to in normal/Emacs mode:

• Alt.: to recall the last argument of the previous command(s)
• Ctrll: to clear the screen in insert mode

The first, the ability to recall the final arguments of previous commands was a showstopper for me: I really struggled without this. Being able to recall a long file path and append it to a new command is invaluable. Fortunately, there is the yank-last-arg command that does exactly this. Why it is not bound by default in vi mode is beyond me…

The other was purely cosmetic, really. I am an inveterate clearer of the screen—unless I am referring to something printed to stdout, I always prefer to work at the top of the console.

In any event, with the bindable readline commands, it was a trivial exercize to restore this functionality to my bash shell in vi mode. I created $HOME/.inputrc, and added the requisite binds:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$include /etc/inputrc

# for vi mode
set editing-mode vi
$if mode=vi

set keymap vi-command
# these are for vi-command mode
"\e[A": history-search-backward            # arrow up
"\e[B": history-search-forward             # arrow down
"\ep": yank-last-arg                       # bind to Alt-p
Control-l: clear-screen

set keymap vi-insert
# these are for vi-insert mode
"\e[A": history-search-backward
"\e[B": history-search-forward
"\ep": yank-last-arg
Control-l: clear-screen
$endif

There is an extensive list of readline commands and variables with which you can customize your shell environment.

After setting up my server, I wanted to use it as a torrent box. The version of rtorrent in the Debian stable repositories is 0.8.6, which is unfortunate as support for magnet links was introduced in 0.8.7.

To remedy this, I decided to build the current stable version of rtorrent, 0.8.9. At the same time—seeing as I was getting my hands dirty anyway—I thought I’d patch in colour support.

This is a straightforward two-step process. First, build the current version of libtorrent, 0.12.9:

1
2
3
4
5

wget http://libtorrent.rakshasa.no/downloads/libtorrent-0.12.9.tar.gz
tar -xvf libtorrent-0.12.9.tar.gz
cd libtorrent-0.12.9/
./configure && make
sudo checkinstall

Once libtorrent is successfully built and installed, you can begin the rtorrent build:

1
2
3

wget http://rtorrent.rakshasa.no/downloads/rtorrent-0.8.9.tar.gz
tar -xvf rtorrent-0.8.9.tar.gz
cd rtorrent-0.8.9/

Then, if you want colour support, you need the patch. I used the version in the AUR, but you can also grab a copy from a paste site:

1
2
3

wget -O canvas_colour.patch http://paste.geekosphere.org/twy7
mv canvas_colour.patch src/
patch -uNp1 -i canvas_colour.patch

The patch should apply cleanly. Then specify where libtorrent is installed to ensure that it is linked during the rtorrent build:

1
2
3

./configure --libdir=/usr/local/lib
make
sudo checkinstall

Once again, this should compile cleanly and you will now have rtorrent with colour and magnet link support installed in /usr/local/bin/rtorrent.

Notes

I prefer to use checkinstall so that self-installed applications are tracked by Apt.