Webserver in a NutShell

I've been playing around with the Debian-Installer recently, while setting up a live HDD.

The graphical installer lets you capture screen shots during the installation process, and I wanted to retrieve these to another PC. The way to do it is to switch to one of the virtual consoles, and launch the script httpd. With the webserver up and running, you can access to the box being installed over the network, using a web-browser, and download screenshots and log files.

You read it right. It's a webserver. Yup. Written in sh. Ain't it cool!? Well, granted, sockets are done using netcat and it isn't scalable, robust or flexible. But it serves its purpose, and it fascinates me in its simplicity. Is it crudeness that I mistake for genius? Maybe. I think it's neat.

I'm currently using a hacked version of this script at work, to serve a few static HTML pages. I had to modify the port being listened to from 80 to 8080 (the first is the default HTTP port, which is privileged, and thus can only be bind'ed by root). I also modified the web root directory to point to a directory in my user account, and added support for the text/html mime-type, by injecting the following bit into the large conditional statement at the end of the script:

   elif [ "${page%.html}" != "$page" ]; then
           header 200 "OK" "text/html"

You can use something similar to serve files with different extensions and mimetypes.

Alternative Window Managers and Dots Per Inch

I'm currently experimenting with different window managers. I'd like to ditch GNOME for something better suited for my old laptop. I'm also an Ion3 refugee (that's a tiling X window manager that I use at work). So I'm looking for a keyboard centric, low on resources, window manager that can also handle floating windows.

If it weren't for the floating windows bit, I would probably use ratpoison (I would actually go for stumpwm, but it's too slow on my box). I've narrowed it down to wmii, awesome and xmonad. But enough about that - I'll post here as soon as the dust settles down.

What I found out so far was that my X server was not configured properly. Under any of these window managers, fonts look too small when compared to GNOME. At first I attributed it to the fact that the GNOME settings daemon was not running.

I found out that I couldn't just run gnome-settings-daemon - it complained that gnome-session wan't running, so I launched it. This did seem to solve the font size problem, but created a new one - it automatically launched all the GNOME cruft with it: panels, desktop/nautilus, etc.

I fiddled a bit with ~/.gnome2/session, trying to setup a minimal session, without losing the original default session. No luck. GNOME is a stubborn beast. Sigh.

Applying Google thinking to the problem hinted that this was a DPI issue. On GNOME I found out (through the oh-so-obvious System->Preferences->Appearance->Fonts->Details...) that it was configured as if 96 pixels spanned one inch. The X server, on the other hand, decided that 75 dots per inch is the correct value (I checked this with the oh-so-toolkit-approach xdpyinfo | grep dots ).

Turns out that both values are incorrect. I used a measuring tape and Google Calculator to calculate the actual DPI: 90x90 (1024x768 pixels, 289x217 mm physical size). X was not detecting the screen size (it was set to 0x0 mm), so it picked 75 DPI. GNOME was not following suit for some reason (I may have modified the value manually at some point, but I'm not sure).

The solution was to force the X server to 90 DPI:

1. In GNOME: System->Administration->Login Window
   or, from the GDM login screen: Actions->Configure the login manager (tick, press OK)
   or, from a terminal
   gksu -u root gdmsetup
   
2. go to Security->Configure X Server...->Command
   
3. add -dpi 90 (or whatever value matches your setup), to get:
   /usr/bin/X -audit 0 -dpi 90
4. logout
5. restart GDM:
   invoke-rc.d gdm restart
   
6. login again

Make sure you configure GNOME to use the same DPI.

With the DPI set correctly you should be able to clearly read text rendered with a 10pt font, as long as your (assisted) eyesight is 20/20.

[6 Mar. 2008] UPDATE: even after solving this issue I got huge fonts showing up in OpenOffice.org menus. The fonts were OK in GNOME.

While trying to resolve the issue I launched gnome-settings-daemon by mistake under ratpoison, and, contrary to my previous attempt (see text above), it just worked - the fonts in OOo are OK now. A recent upgrade of gnome-control-center must have fixed the behavior of gnome-settings-daemon.

So I now launch gnome-settings-daemon when ratpoison is launched, with this line in ~/.ratpoisonrc:

exec gnome-settings-daemon

This also has a nice side effect - the GNOME control center can be used to control stuff: screensaver, keyboard shortcuts, mouse handedness, background image, themes, etc. Doing these manually using xscreensaver, xmodmap, xsetroot, etc. can be quite a PITA.

It's interesting to note that if it weren't for my problem to launch gnome-settings-daemon, I wouldn't have hit the DPI problem.

[15 Mar. 2008] UPDATE #2: well, guess what? my DPI troubles continue... Let's just say that you need to put the following line in ~/.Xresources for correct font rendering (got this from a nice article about X Server DPI):

Xft.dpi: 90

(replace 90 with the correct DPI settings).

OpenOffice.org / Java Problem

I tried exporting a spreadsheet to XHTML in OpenOffice.org Calc. About 30% into the process, according to the progress bar, oocalc informed me that there's a problem with the Java installation on my machine. It instructed me to select an operational Java runtime environment in Tools->Options->OpenOffice.org->Java. I did. It didn't help.

But it used to work. It did work just a week ago. I installed Sun JRE 6 an hour before that, trying to get a Java applet on a certain website working (to no avail). So I assumed it caused my troubles. But removing it had no effect.

I launched oocalc from a terminal window, hoping to see error messages, and actually got one:

javaldx failed

This seemed relevant, but quite meaningless. I searched around for this phrase, and got quite a few hits, the first of which was the source code for javaldx.cxx at the OpenOffice.org Cross-Reference. Simply put - OpenOffice.org never found the JRE.

I went through ~/.xsession-errors and found the following message:

[Java framework]sunjavaplugin.so could not load Java runtime library:
file:///usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/client/libjvm.so

which made sense - there's no such file, and the version installed is 1.5.0.14. So why is OO looking for an older version?

I looked at /var/log/apt/term.log and realized that both OO and Java5 were upgraded a few days ago. Aha. Ahhem. Err, what do I do now?

Maybe this is some local configuration issue - in my user account?

Turns out it's my lucky(?) day. I found the above mentioned file path in ~/.openoffice.org2/user/config/javasettings_Linux_x86.xml, so I moved the file away, and fired up oocalc, hoping it won't just crash. It didn't. It actually worked.

Sometimes I wish I didn't upgrade that often. I'm probably addicted to the pain - I have no other explanation. Fact is I'm feeling high now. I need some Java. I need some sleep.

(Almost) Disable Outlook Express Folder Compacting

Ever since my last debacle with Outlook Express, it insists on asking my wife if she'd like to compact its folders. I definitely wanted to disable this mis-feature, but found no obvious way (read: menu item or dialog option) that does that.

I spent a few minutes searching for a solution on the Internet, and found the following FAQ. The behavior I encountered is definitely an OE bug: it's only supposed to ask the user to compact folders after being closed 100 times. The count isn't zeroed after the first time, which makes OE ask every time it's closed, even if the folders have been compacted.

The workaround is to reset the counter to zero in the registry:

1. run regedit
   
2. navigate to
   HKEY_CURRENT_USER\Identities\{GUID}\Software\Microsoft\Outlook Express\5.0
3. edit the key "Compact Check Count" and set its value to zero.
   

I also exported the content of this key to a file, so that I can double click it and fix this again next time OE decides it's a good idea to compact folders.

I should probably automate this...

Backup/Restore Package Selection States

I tend to install documentation packages that aptitude lists as suggested for installation. I rarely read the documentation though, which is a pity.

One of these packages - debian-reference - was upgraded today. On a whim I started going through it, and I stumbled on a solution to a problem that was nagging me for a while:

I only backup a restricted set of files, under the assumption that if I ever need to restore a system from scratch I'll simply install a new system and configure it using the restored configuration files. The problem here is that I need a way to re-install all the packages that I'm already using. I don't have a good way of doing this, and even if I had, there's the issue of configuring all these packages upon installation - a tedious if not impractical process.

Section 6.4.9 of the Debian Reference provides the solution. To backup your system package configuration, install debconf-utils and run

dpkg --get-selections "*" > myselections
debconf-get-selections > debconfsel.txt

I intend to run these commands as part of the nightly backup process.
To restore it run the following commands

dselect update
debconf-set-selections < debconfsel.txt
dpkg --set-selections < myselections
apt-get -u dselect-upgrade

(I haven't tested the latter, and I hope I don't ever need to do it...)

Syntax Highlighting Pager, Reloaded

This comment prompted me to search for an alternative way to list source code with syntax highlighting. So I searched for a Debian package with "highlight" in its description:

aptitude search "~dhighlight"

and sifted though the results for anything interesting. I hit upon highlight, installed it and played with it a bit.

It can highlight many types of files, but out of the box it doesn't highlight some file types (I tried listing emacs lisp files and its own configuration files). By default it reports an error if the file type is not recognized, instead of just listing it (which makes more sense to me) - the --force command line option fixes this. You may also need to edit /etc/highlight/filetypes.conf in order to have more file extensions recognized.

If you just want to dump a file to the console:

highlight --ansi --force <filename>

To page through it:

highlight --ansi --force <filename> | less -R

It also doesn't transparently open gzip/bzip2 compressed files (which is the default behavior of less, vim and emacs on a default Debian user account).

All in all, I find it handy - highlight can generate several output formats (xhtml, LaTeX, etc.), can re-indent some file types, can add line numbers, has color themes and more. My only gripe is that it's somewhat painful to configure and use when compared to vim as a pager.