dvtm - a console based tiled window manager

In my last post, I outlined how to do some form of rudimentary multitasking in Bash, but I was still not satisfied. Further research showed that there would be no way around a terminal multiplexer, however screen sucks for me due to its steep and unintuitive learning curve. On K.Mandla's great blog I found the solution: dvtm, a very lightweight tiled window manager for the console. Its beauty lies in that it occupies just around 100k of disk space, does not hog the memory and does not try to accomplish more than it is supposed to.

Becoming familiar with dvtm is a matter of minutes. Install the package from your distribution repositories, go to a console or open an xterm, then input dvtm. You will see Bash within a blue frame. The blue frame indicates that this is the active window. Now press CTRL-G C (press CTRL-G, release the keys, then type a C). A new Bash window pops open next to the existing one and becomes the active window. You can close that window by either logging out of that instance (input exit or press CTRL-D), or by pressing CTRL-G X.

With multiple windows open, you can input CTRL-G <number> to activate window <number> (as designated by its "title bar" text), or CTRL-G J / CTRL-G K to activate the next/previous window. CTRL-G . minimizes or unminimizes the active window. CTRL-G M maximizes the active window. Use CTRL-G SPACE to toggle between grid layouts; this is also the only way to unmaximize a window. CTRL-G ENTER moves the active window in and out of the "master area", which is usually the tile of the biggest size. Finally, dvtm can be left by means of CTRL-G Q, or logging off all hosted shells.

If you need a lightweight multi-window shell environment, dvtm should be surely worth checking out.

How to work with multiple jobs in Bash

An important feature often overlooked by novice console users is job control. It allows some amount of multitasking on a shell by delegating processes to the background and resuming them at a later point. That way, you don't have to launch a second shell or use additional utilities like screen to manage multiple tasks.

Job control is easy. Let's say you have Midnight Commander running. Hit CTRL+Z and you end up back at the shell prompt. You will notice a line above the prompt stating that mc is suspended. The beginning of the line shows mc's job number in square brackets (1 in this case). Ok, let's use that job number to resurrect mc. Input %1 and voíla, mc is back! Similarly, you can use %1 & to unsuspend mc and continue running it as a background job. Note that background jobs are detached from the terminal and will be suspended as soon as they try to read from or write to it.

When working with multiple jobs, you will find the jobs command very useful, which lists the running jobs with their numbers and status.

A more intuitive way to unsuspend a job is to give part of its command line. %mc will unsuspend Midnight Commander, however if you have multiple instances running it will result in an error. Finally, just inputting % will unsuspend the most recently suspended job.

As you can certainly see, this feature is a real time-saver by allowing you to get running applications out of the way and resume them later.

How to recover lost data on an ext3/4 partition

I recently had a late-night oopsie with tar, overwriting the file I wanted to package (source code I had worked on for a week). After a few seconds of creepy feelings, I remembered that I use a journaling filesystem and thus, there would be a good chance that there would be several copies of the data still physically lying around on the storage medium.

So, what to do when you lost a file? For your first action, you have two options.

First option: Power off the system without shutting it down, then boot from a live CD. The foolproof option.

Second option: If you can ensure that no new files will be created on the filesystem where the loss occured while you are trying to recover the data, you can work from the running system and avoid further potential data loss from uncleanly powering down the system.

Next, become root and grep the filesystem where the data loss took place.

grep -a -B300 -A300 "searchString" /dev/sdb1 > dumpfile

searchString is a piece of text that preferably only occurs in your lost file. Try to be as specific as possible so you ideally only get results from the file's contents. The -B and -A options specify the number of context lines to output before and after each match. Choose values large enough to include the entire lost file, if possible. Replace /dev/sdb1 with the device node of the filesystem where the lost data is. You can find out the node by just running mount without parameters. dumpfile is the target file containing the found text. Of course the dump file should not be saved on the partition where you lost the data! Save it on another filesystem or a tmpfs if you have one set up. Mounting a USB stick or something for the dump file may be risky because a device node will be created on the root partition, which stinks if your lost data sits exactly there.

After grep is done, examine the dump file with a text editor. If you are certain that it contains your entire lost file in a usable or recoverable state, you can start copying and pasting into empty files, restoring various versions of your file of which a few will probably be current.

Set DRI driver options via the CLI using dritune (updated 2x)

Aaaah, what a nasty cold I catched that I could not blog for ten days. However, I have not been totally idle during that time and found out that enabling texture tiling in the Intel X.Org driver finally not only works properly on my 915 chipset, but gives a breathtaking speed boost! Warzone 2100 is now playable at high resolutions on my netbook with the attached LCD monitor.

No fiddling with xorg.conf is required for this tweak (in fact many distributions don't ship with that file by default anymore, but it is still supported for troubleshooting drivers). What we do today is setting screen resolution and orientation using RandR, and driver options via ~/.drirc. Look into that file if it exists on your system. Yuck! XML! Not very unixy.

Well, there is DRIconf, a GUI tool that lets you view and modify the driver options and also create profiles for different applications. On the other hand, there are people like me who don't like to install GUIs with many dependencies just for toggling one or two checkboxes. In fact, I was astounded by the absence of command line tools for setting DRI options, so I took over that job and created dritune.

Download v0.02 - tarball, .deb package

Copy the dritune script from the tarball to some location in your path. It has xmlstarlet as its only uncommon dependency, so you need to install it from the repository. Starting dritune without any parameters gives you some usage help. Typically you would do dritune list to get the list of DRI options for the first screen, then dritune info <option> to show a description and possible/current settings for an option, then dritune set <option> to modify the setting. There is much more it can do and it behaves very script-friendly. Best of all, it does a great job at keeping you away from XML :-)

Feedback, bug reports and intents of packaging are welcome.

Bugs so far:

• Running dritune on another machine over ssh will retrieve the driver options from the local machine/display and save changes to the remote machine. Baaad! As a fix, run dritune this way: DISPLAY=":0" dritune.

To do:

• Calling xmlstarlet is slow. In particular, it is subjectively slow when dumping all options to stdout, because it is called three or so times per option. Either the number of calls has to be reduced, or all information should be gathered on startup, or some sort of caching should be implemented.
• Fix Bash throwing seek errors when X is running but for some reason not accessible.

How to modify basic system settings with dpkg-reconfigure

You have probably been told at some point to dpkg-reconfigure a package. This command belongs to the debconf infrastructure and what it does is execute the package's configuration script. The script usually recreates data or configuration files belonging to the package, and it may ask you a few questions in the process. Reconfiguring packages is one way of configuring and customizing your installation besides editing configuration files directly, or using GUI tools like KDE systemsettings or GConf.

To get a nice formatted list of installed packages that can be configured, do

cd /var/lib/dpkg/info/ && ls *config | sed 's/\.config$//'

Here are the most useful of them, and what configuring them does.

apt-listchanges: This package is likely not preinstalled on your distribution but useful for displaying changelogs when upgrading your system. Configuring this package asks you how it should output the package changelogs (inline in apt's output, or in one of several viewers), whether and where to send mail notifications, as well as some other settings.

ca-certificates: Asks whether to trust new CA certificates, and presents you a list where you can select which certificate owners to trust. You probably will not want to change anything here.

console-data: Lets you select a keyboard map to use on the console.

console-setup: Lets you select a character set and font for the console. This comes in handy if the console does not display some extended characters, or the predefined font is a 512 glyph font (like Terminus) that prevents the console from using the full color palette.

debconf: Lets you select the desired frontend for debconf and how many questions you want to be asked when running dpkg-reconfigure. You probably want to select the dialog frontend which is easy to use and can run on a plain console.

fontconfig-config: Allows you to configure X font hinting, subpixel rendering and whether you prefer pretty outline or ugly bitmap fonts.

keyboard-configuration: Lets you select model and language of the keyboard, what to use as Alt Gr and Compose, and whether the X server can be terminated using Ctrl-Alt-Backspace.

libpaper1: Sets the system-wide standard paper size (default: A4).

linux-sound-base: Asks which sound system should be used by default (ALSA or OSS).

locales: Asks which locales should be supported on your system, then generates these locales. Unselecting locales you will not use results in a few less megabytes of wasted storage space.

man-db: Asks you whether to use preformatted manpages, then updates the manual database.

popularity-contest: Asks you whether to participate in the Debian package popularity contest. Anonymous package statistics are sent once a week so the Debian project can decide which packages are popular enough to be included in the main distribution.

resolvconf: Asks you whether /etc/resolv.conf should be updated dynamically, which is likely what you want if you get the DNS servers via DHCP.

tzdata: Lets you select your time zone.

x11-common: Sets who is allowed to start the X server. The default "console users only" is fine and not too insecure.

Build a secure home network using SSH

This Howto explains how to build a local network where communication between machines takes place over the Secure Shell Protocol. This is not only more secure (especially over wireless) but also enables you to conveniently get a remote shell on every machine.

I'm assuming the machines are connected to each other via a dedicated hardware router, but network topology does not really matter as long as all machines can see each other. Also I'm assuming all machines are on the same network segment, i.e. you have a typical small-scale home network.

First, install the ssh metapackage on the machines you want to connect. On Debian based systems, this will get the OpenSSH client, the OpenSSH server and the blacklist of insecure keys. All are required for the setup to function properly.

Next, we will add some basic network security. On the machines you want to connect make sure that /etc/hosts.deny contains the line

ALL: ALL

This blocks all inetd controlled services (most stuff except HTTP and Samba) coming from all hosts by default. In /etc/hosts.allow add:

ALL: LOCAL

This allows all services running on your local network (i.e. all hosts whose names don't contain a dot) to access the local host.

If you are paranoid and only want to allow ssh, instead use

sshd: LOCAL

You will likely not be running a DNS server on your network, so you will have to set the hostnames on each machine. The top of each /etc/hosts file should contain something like

127.0.0.1 localhost
127.0.0.1 nameofthismachine

Where nameofthismachine is the desired hostname for the local computer. In the same file, add the IP addresses and hostnames of all other machines that machine should be able to connect to, for example

192.168.0.2 anothermachine
192.168.0.3 yetanothermachine

You can find out the network IP address of a box either by running ifconfig on that machine or logging into the router and looking at the logs.

Changes to the hosts* files should come into effect immediately, but the router may be slow to pick up hostname changes, so it is a good idea to power cycle it now to renew the DHCP leases and update the routing table.

Now, at one of the boxes, try

ssh username@someotherbox

and if ssh can connect to someotherbox, you are asked for username's login password. Now you can work with that shell like you were sitting in front of the other computer. You can also start GUI programs when adding the -X switch (which enables X11 forwarding). For better performance but less local security you can add -Y to enable trusted X11 forwarding.

ssh -X -Y username@someotherbox

Then you can start xeyes or some other graphical app for testing. Depending on the processing power of your router and link speed, even watching DVDs over the SSH connection may work well.

Ok, what about transferring files? You have several options here. When working on a shell with Midnight Commander, you can establish a shell connection via the Left/Right menus. In KDE, Dolphin/Konqueror and file dialogs understand the fish:// protocol (example: fish://username@someotherbox). Similarly, you can use ssh:// in many Gnome applications. You can also mount the remote computer's filesystem using sshfs.

If you have a network service running on one of the machines, like a streaming server, you may want to tunnel the data through SSH too. To tunnel port 6666, with the local machine at the receiving end, do

ssh -R 6666:localhost:6666 username@server

Hopefully, this article has helped you secure your network a bit.

Store volatile data in RAM using tmpfs

There are several reasons why you might want to hold certain data in non-permanent memory. Applications that create a lot of temporary data, causing system slowdown and strain on the storage medium, are an example, or you want the data to be gone after every power cycle because it is of no use anymore at that point, or the data would simply eat up too much storage over time.

Unix-like platforms support a file system named tmpfs, which is a RAM filesystem growing and shrinking dynamically with its contents. Setup is straightforward. To mount /tmp as tmpfs, you add the following line to /etc/fstab, after the physical partition mounts:

none /tmp tmpfs defaults 0 0

Be sure to clear out the contents of the old /tmp directory before remounting, because the mount will "overlay" what was previously there and the data will not be accessible but still occupy space.

Other locations that are good candidates for a tmpfs: /var/tmp, /home/username/tmp, /var/cache/apt/archives, web browser and other caches in your home directory. Don't be tempted to put /var/log on a tmpfs because the logs are important information sources for troubleshooting and forensics. Use logrotate instead for limiting the amount of log storage.

When you are done setting up the temporary file systems, issue a mount -a to remount everything from fstab.