hylafax+debian or Ubuntu = No font metric information found

We were recently going through a server migration. Moving from FreeBSD to Ubuntu Linux. One of the apps required to be moved was hylafax. On Debian and Ubuntu there is a hylafax-client package that provides sendfax which is really what we needed. I installed the package and we tested our app but all we got was failure.. We were greeted with the following:

textfmt: No font metric information found for “Courier-Bold”.
Usage: textfmt [-1] [-2] [-B] [-c] [-D] [-f fontname] [-F fontdir(s)] [-m N] [-o #] [-p #] [-r] [-U] [-Ml=#,r=#,t=#,b=#] [-V #] files… >out.ps
Default options: -f Courier -1 -p 11bp -o 0
Error converting document; command was “textfmt -B -f Courier-Bold -Ml=0.4in -p 11 -s default >’/tmp//sndfaxUSNM632′ <'/etc/issue.net'"

It took a a little bit of poking and prodding to figure this one out but to fix it I had to edit the following file:


In this file there is a setting for the FontMap. I appended /var/lib/defoma/gs.d/dirs/fonts. You will also need the gsfonts package but that is a listed as a dependency so you should already have it installed.

Ubuntu Linux CUPS server with legeacy LPD support using cups-lpd

We recently upgraded a few of our servers. Some of them are still stuck on older FreeBSD and we can not upgrade them for a while longer. These older systems need to be able to print to printers that are shared on Windows desktops. One way of doing this is to setup CUPS. Some of the servers I replaced were replaced with the latest Ubuntu Server. I picked one of them and setup Samba. Next I setup CUPS on it. At this point I was really hoping that the lpd stuff would just start working.. That was and is not the case. A tad more configuration is required to get the lpd support. To get the lpd support you need to install an inetd server. I tried xinetd but never could get it working, so I opted to try openbsd-inetd. This worked perfect. To get the cups-lpd working I had to edit /etc/inetd.conf and I added the following:
printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd
Now everything is working fine from my legacy FreeBSD machines.

Beginning Ubuntu Linux, Fourth Edition
CUPS: Common UNIX Printing System
Absolute FreeBSD: The Complete Guide to FreeBSD, 2nd Edition

Hide your Lighttpd Version and Supress the X-Powered-By info given by PHP

A simple first step to some basic security on your web server is to make the response headers say as little as possible. This is not going to be the end all only thing you need to do to secure your web server, but hey like I said its a basic first step. When you hit a website and are looking at the content you might find your self wondering “What OS, and what web server is this person using.. And hey I see the pages end with .php I wonder what version of that they are using too..” Well this is all (by default on most systems) just pushed out to everyone who visits the site. You can find this with out even having to have any command line skills or know how to use wget or curl. A simple Firefox Plugin can tell anyone this. The typical output will look something like this:

X-Powered-By: PHP/5.2.6-1+lenny4
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Transfer-Encoding: chunked
Date: Sat, 27 Feb 2010 16:18:09 GMT
Server: lighttpd/1.4.25
200 OK

Wow thats a lot of info about this persons server… We can see here that they are running Debian Lenny, and they have php 5.2.6 with a patch set or 2 on it, and they have Lighttpd version 1.4.25. That now lets a possible attacker know which security lists to go hit up looking for possible exploits in any of the above mentioned software.. And a simple nmap command can automate this whole process of looking for a “mark” through entire net blocks in a matter of seconds.

Lets start by telling less info about our web server. The default response from Lighttpd is lighttpd #current-version# To change this all we need to do is edit our lighttpd.conf file. Using your favorite text editor lets open up lighttpd.conf and look though it for server.tag Odds are its not in there but thats OK we will add it and define the value.

server.tag = “WebServer”

Now that we have done that we will need to restart the web server. Next time we check our site it will look more like this:

X-Powered-By: PHP/5.2.6-1+lenny4
Content-Type: text/html
Transfer-Encoding: chunked
Date: Sat, 27 Feb 2010 15:56:46 GMT
Server: WebServer

Ah now that is much better but that pesky PHP is still telling everyone what OS and version of PHP we have.

Now lets shut PHP up. Using your favorite text editor open your php.ini file and lets look through it for expose_php By default the value will be set to On. We need to set it to Off. Now we need to restart Lighttpd again. Now our response headers will look like:

Content-Type: text/html
Transfer-Encoding: chunked
Date: Sat, 27 Feb 2010 16:02:47 GMT
Server: WebServer

Now again.. This is not the end all.. you still need to sercure the box with iptables or some other type of firewall because this did not make your server any more secure than it was before. All we did was HIDE the info making it harder to find out what you have. There are many other things you can do like running these services in a chroot jail, but this is not going to hurt to do.

Troubleshooting Bind9 Queries

Yesterday I was adding a new domain to our servers to slave. While looking though syslog to make sure this was all working I noticed a whole flood of requests for a site that was busted.

unexpected RCODE (REFUSED) resolving ‘www.examplesite.com/A/IN’: x.x.x.x#53

This was just filling my logs like crazy. I wanted to know who on my network was making so many requests for this site.. I was really hoping I didnt have some infected PC on my LAN. To find out I turned on the query log. This is not on by default on Debian, or on Ubuntu, or CentOS which is what I use for all of my DNS. To turn on query log is pretty simple. I added the following to my named.conf.options file

logging {
channel “querylog” {
file “/var/log/bind9-query.log”;
print-time yes;
category queries {

Once added you need to make sure this directory is present. If you are in a chroot environment like a good sysadmin remember this path is relevant to your chroot so /var/log/bind9-query.log might really be /chroot/bind9/var/log/bind9-query.log Next make sure your bind user had read/write access to the file.

chown bind:bind /chroot/bind9/var/log/bind9-query.log

Next simply

rndc reload

and go watch that puppy fill up in a hurry. I do not like to keep this turned on because it fills up so fast and I only seem to need it when there is a problem. If you do decide to keep it turned on make sure you set up a logrotate for it. In my environment this log will get to be several megs in under an hour. Sure hope this will help you figure out who is querying what on your network.

Sample output from the log file

05-Feb-2010 09:08:25.524 client query: claimlj2.my.domain.com IN AAAA +

DNS and BIND (5th Edition)