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.

GUI vs. CLI: Apples vs. oranges

I have never managed to wrap my mind around the tired old GUI (graphical user interface) vs. CLI (command line interface) debate and which is "better", and why you should try to avoid or strictly stick to the one or the other.

It is like comparing a brush and a hammer. Both are tools, but for different purposes, and if you want to be prepared for a wide variety of home improvement tasks, you better have both in your tool chest and a basic understanding of how to use them.

If you are good at building furniture but suck at painting, you call a friend who glazes your table for you, or you practice on a piece of leftover wood. Your friend may be a good painter with a steady hand and a great sense for color but completely clueless on how to fix a broken door hinge. But with only a little bit of learning and practice, he could become proficient enough to do small repairs himself.

Along the same lines, life can be easier if you have a basic understanding of both the GUI and CLI environments available on your computing platform, because each is included for the purpose of helping you with specific tasks.

GUIs shine when it comes to interactive workflow, especially editing on-screen data, like an image or a spreadsheet. Essentially, complex spreadsheets and desktop publishing were the applications that made graphical interfaces necessary in the first place. Navigation within the environment is highly interactive too; you activate menus or buttons, working your way to the target. A lot of information can be presented on the screen at once, which is great for working with multiple applications or pieces of data at the same time.

CLIs allow calling commands or starting applications with a few keystrokes and also have built-in scripting mechanisms which allow for building heavily customized command pipes and conditional/repeated execution. The vast majority of processing is done non-interactively (you only have the "upfront cost" of constructing a suitable textual expression). Navigating the environment is a minor matter; you change directly into a directory if you really need to be there, but commands are callable regardless of your location within the directory tree. Sophisticated means of auto completion and history search are available via simple key combinations, so you don't have to type any more than absolutely necessary.

It can be said that CLIs are designed to spare you time with generic tasks that do not need to be interactive, while GUIs are designed as an efficient way to do interactive document centric tasks. You should use a CLI for: Capitalizing text that has to fit some specific pattern, in some files scattered randomly over several partitions, and the filenames and file modification times have to fit a specific pattern too. That's a sed one-liner in a Unix shell and will waste hours when done in a GUI. You should use a GUI for: Adding some nice gradient borders to an object group in a SVG graphic, and make a text element run along it. Requires high-level wizardry in a CLI, better done in five minutes in Inkscape.

You should be able to see now that both user interfaces are highly efficient and mature solutions for getting different sets of tasks done. What you will end up using depends on what you want to accomplish, and use of an unsuitable interface will likely cause frustration and an "it can't be done" feeling. Call a knowledgeable friend then, or better, spend some time getting accustomed to the more suitable tool.

How to generate PHP code from Bash

If you are into server side web programming, you will probably have had some exposure to PHP. Advantages of the language are that it is very widely supported, and that it can be freely mixed with HTML within the same file.

You might want to have some script running on the server for the purpose of generating PHP code. Unfortunately, you cannot throw everything at Bash's string functions as-is because some special characters are used to denote expansion or redirection. One totally unexciting but have-to-know bash feature comes into play here, called quoting.

Quoting is the art of using single or double quotes or backslashes to protect a range of characters in a string from being interpreted by Bash. In short, single quotes protect everything inbetween them so the input is taken 1:1, double quotes allow variable expansion (via $dollar sign) and command substition (via `backticks`) and protect mostly everything else, and the backslash protects the character following it. Mixed or nested quoting is often necessary and one of the most unintuitive things on earth, but for this howto, I will keep it as simple as possible.

Ok, let's do a "Hello World" in PHP, via Bash.

echo -e "<?php\n  echo \"Hello World\";\n?>"

Output:

<?php
  echo "Hello World";
?>

Why do I use the -e parameter? It allows the echo command to interpret C-style backslash escape sequences (like \n for a newline, \t for a tab). In addition, I'm enclosing the whole string in double quotes, as this allows for interpreting shell variables and escapes without messing up on most other stuff. The \n after the opening PHP tag is a line break, then two spaces follow for intendation. I have to escape the double quotes around "Hello World" ("protect" them) to not have them interpreted as string quoting, and output them literally instead. After that comes the semicolon that ends the PHP command, another newline and the closing PHP tag.

But, you might complain now, the PHP code itself might contain backslash quotes too! How to escape that, dude? Well, in that case we protect the backslash by writing a double backslash.

echo -e "<?php\n  echo \"Hello \\\"World\\\"\";\n?>"

Output:

<?php
  echo "Hello \"World\"";
?>

The parts with three backslashes in a row are a backslash protecting a backslash, followed by a backslash protecting a double quote.

Because of the "weak" double quoting, we can use shell variables and command substitution.

echo -e "<?php\n  echo \"Script generated by $SHELL\";\n?>"

Output:

<?php
  echo "Script generated by /bin/bash";
?>

<?php\n  echo \"Script generated by $SHELL on `uname`\";\n?>"

Output:

<?php
  echo "Script generated by /bin/bash on Linux";
?>

You can build on this from this point on: Just keep in mind that quoting with double quotes protects all characters except ", \, $, and `, so you have to escape them with a backslash if you want to output them literally.

Howto: Plasmoid that shows your online Kopete contacts

Together with Pidgin, Kopete is certainly one of the top choices for a multi-protocol messenger in a Linux environment. Although it doesn't support all of the (usually rather annoying) extra features of some protocols, it allows me to keep in touch with my family and fellows without having to install three different chat applications. What sort of bugs me is the currently missing IRC support, besides of that it does everything I need it to and integrates well with other KDE based software.

Now what if I want to start a chat quickly without opening the contact list, you might have asked yourself? Well, you are not out of luck. What you need to do is install an additional plasmoid that contains a few detachable widgets. It is called Lancelot and can be obtained by installing kdeplasma-addons.

Unlock the widgets if necessary by right clicking on the desktop, then right click again and choose "add widgets" (I'm using German KDE, so it might read differently in the English localization). Select the Lancelot launcher (not the component) and drag it to some free space on your desktop or the panel.

That's a nice menu, isn't it? The best thing about it is that you can drag the title of a section and tear off a copy, which can then be placed anywhere as an independent plasmoid. Tear off the contacts section and place it on the desktop or in the panel, and you have a nice widget that displays your online contacts and allows for starting a conversation with a click, or by just hovering the mouse over the right hand arrow (that no-click behavior can also be switched off if it sucks for you). You can remove the Lancelot launcher afterwards if you don't need it anymore.