Hack23.Centralize X Window System Font Resources

Hack 23. Centralize X Window System Font Resources

Setting up a central X Window System font server simplifies font distribution and reduces clutter and resource use on X-based desktop systems.

The X Window System is the underpinning of most of the graphical desktops and window managers used on Linux and Unix systems today. While alternatives are under development and many people complain about the CPU impact of the X Window System's constant polling for keyboard and mouse events, it's hard to argue with successthe X Window System already works and is therefore used almost everywhere. Also, the demands it puts on modern systems with beefy processors are much less significant than they were on old workstations or systems running at 300 MHz. As an inherently network-aware client/server graphics system, X has a lot going for it in terms of usability and portability, as well as ubiquity, since it's available and supported on almost every system with graphical capabilities. Still, there are some aspects of X that can be optimizedspecifically, its font handling. This hack explores how you can set up a central font server to offload local font requirements to a central resource, saving CPU cycles, disk space on your desktop systems, and administrative headaches by ensuring that the same fonts are deployed on all desktop systems that might need them.

3.5.1. Billions and Billions of Fonts…

Obtaining and managing the fonts used by graphical applications has always been a problem, regardless of the type of system that you're using, and it certainly isn't limited to the X Window System. I can (painfully) remember choking older Windows and Mac OS boxes by installing too many fonts. Somewhat worse than the problem of loading and supporting zillions of fonts were aesthetic problems caused by people's zealous overuse of them. I can remember getting resumes from prospective employees that looked like they'd been blasted with a shotgun loaded with different fonts and wingdings. Such is lifeif you build it, they will abuse it. However, sysadmins are the wrong people to enforce aesthetics. Our job is typically to provide users with the resources they think they need and to do so in a manageable, easily administered fashion.

Today's X Window System deployments on Linux boxes typically come from either Xfree86.org or X.org. The latter is more prevalent and is probably "the X Window System of the future" (which some may view as an oxymoron, but that's another topic). Both of these X Window System implementations come with a variety of fonts located in subdirectories of /usr/X11R6/lib/X11/fonts. Each of these subdirectories can contain many different font families as well as individual fonts. The default X.org configuration on the SUSE system where I'm writing this provides 30 subdirectories of fonts, and running the fc-list command shows that there are 652 separate fonts available on the system. In comparison, my Fedora Core 4 systems (where I've installed everything, since disk space is cheaper than my time) have 185 fonts installed. The SUSE boxes devote around 100 MB of disk space to font storage, while the FC4 system uses a mere 50 MB. These values would be much higher if I'd installed all of the fonts that are available for different languages. The number reported by the fc-list command is also independent of any fonts that individual users may have installed locally in their ~/.fonts directories. Yikes!

Discrepancies between the number of fonts delivered with various Linux distributions and X Window System implementations make it desirable to share fonts between systems. Disk space is as cheap as dirt nowadays (certainly cheaper than potting soil), but making the same huge collections of wonderful fonts available to everyone's X Window System applications is certainly logistically attractive. In addition to the default sets of fonts provided with Linux distributions, some Linux applications that may not be part of default system installs come with their own sets of fonts.

Luckily, I'm not the first person to have wished for a centralized mechanism for delivering fonts to X Window Systems across the college or enterprise. For quite a while, most X Window System implementations have come with a font server known as xfs (X Font Server, not to be confused with the XFS journaling filesystem). A previous incarnation of a font server, fs, was provided with older Linux distributions, but this has since been supplanted by xfs. Most desktop Linux distributions use xfs to deliver fonts to the local system, but with a few changes to the xfs configuration file and a bit of organization, you can easily configure one or two centralized font servers to handle your organization's font requirements and make as many fonts as possible available to all of your X Window System desktops, window managers, and applications.

3.5.2. Setting Up an X Font Server

Setting up an X font server to serve fonts to your other systems is quite simple. As most modern X Window System implementations use a font server to deliver fonts to the local system, the most important step in the reconfiguration process is to open up the X font server to external TCP requests.

The configuration file that controls the behavior of the xfs font server is the file /etc/X11/fs/config. (Although the font server executable has a new name, they kept its old name in the path for consistency's sake.) We'll want to modify a few things in this file, but the critical one for turning a specific X font server instance into a centralized resource is to comment out the following line by using a text editor to put a hash mark at the beginning of the line:

 #no-listen = tcp 

By removing the no-listen directive, this tells the X font server to begin listening to incoming TCP requests from other hosts.

Setting up more than one font server is a good idea if you're going to be configuring your desktop systems to use centralized font resources. To identify other font servers, add an entry to the xfs configuration file that gives the comma-separated names or IP addresses of the other font servers on your network and the ports on which they are servicing requests. As an example:

 alternate-servers = font2.vonhagen.org:7100,font3.vonhagen.org:7100 

This entry tells the font server that it can redirect requests to the alternate font servers font2.vonhagen.org and font3.vonhagen.org on port 7100 if it has too many connections to handle itself. The standard port on which X font servers run, which you should probably use, is 7100. You can use a different port if you'd like, as long as you're consistent both on the font server and on any clients that want to connect to it.

Next, you'll want to set the port keyword in the xfs configuration file to the integer value of the port on which the X font server will be listening for incoming requests. Again, port 7100 is the standard and should thus be used unless you have some reason to use another port.

On some Gentoo Linux distributions, the X font server port is set by the XFS_PORT directive in the /etc/conf.d/xfs configuration file. If you are using Gentoo and your font server starts but you can't contact it, check this file to make sure the font server is actually following the directives that you specified in its configuration file.

Next, determine the appropriate limits for the number of clients that can connect to the font server and how the font server should behave when that limit is reached. This is done by a combination of the client-limit and clone-self settings in the xfs configuration file. The client-limit setting requires an integer value that determines the maximum number of clients that a specific font server will support before it refuses service to incoming requests. The clone-self setting requires a Boolean value and determines how the font server behaves when this limit is reached. If clone-self is on (true), the font server will start a new instance of itself when it reaches the maximum number of clients specified. If clone-self is off (false), the font server will attempt to contact any other servers identified in the alternate-servers entry, in order, until one can be contacted successfully. In environments with multiple centralized font servers that service large numbers of desktops, I'd suggest always having clone-self set to false, and starting out with a client-limit of 100. Once you see how well this performs, you can raise or lower this limit to best balance response time from the font server (affected by both system load and network bandwidth) with reasonable utilization of all of your font servers.

As the final step in creating your X font server's configuration file, you'll need to add each directory that contains X fonts to the comma-separated value for the catalogue statement. The next section explains how to copy font files from remote systems to the X font server system and create appropriate entries for them in the font server configuration file.

3.5.3. Copying Fonts to a Font Server

The next step in configuring your font server is to actually populate it with all of the fonts that you want it to deliver to your X Window System clients. The easiest way to do this is to examine the X Window System configuration files on each of your types of systems to see where they are currently getting fonts. This is specified in one or more FontPath statements in the Files section of the X Window System configuration file, which is either /etc/X11/xorg.conf (for X Window servers from X.org) or /etc/X11/XF86Config-4 or /etc/X11/XF86Config (for X Window servers from XFree86.org). If the Files section contains a single, uncommented statement such as the following, that system is using itself as a local font server:

 FontPath "unix/:7100" 

For each FontPath entry that points to an actual directory on the system you're examining, first check if the same directory (with the same contents) exists on the system where you'll be running your enterprise-wide X font server. If not, you'll need to copy the contents of that directory to the X font server system, creating the directory if necessary. Once any necessary directories have been cloned to the X font server system, make sure that those same directories are being identified in the catalogue statement in the X font server's configuration file. For example, the following are some sample statements from an X font server configuration file that refers to a local font directory:

 FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/local" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc/sgi:unscaled" 

After copying font directories to the machine that will be running the X font server, you will then have to update the X font server's configuration file, /etc/ X11/fs/config, to have equivalent statements. Each FontPath statement in the X server's configuration file translates into one of the comma-separated values associated with the catalogue keyword in the X font server's configuration file. Thus, an equivalent statement to the previous example would be the following:

 catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/misc/sgi:unscaled 

The last entry in the catalogue statement must not be followed by a comma.

If you copy fonts into an existing font directory on the machine that will be running the X font server, you should su to root or use the sudo command to re-run the mkfontdir command so that all the fonts in that directory can be identified and delivered by the X font server.

3.5.4. Starting or Restarting the X Font Server

Almost there! Before restarting the X font server to pick up the new settings and start offering fonts to any X clients that happen by, check the xfs startup script located in /etc/init.d/xfs to make sure that it doesn't explicitly specify a different port than the one on which your font server expects to listen. For example, suppose that your startup script contained a statement like the following:

 daemon --check xfs xfs -port -1 -daemon -droppriv -user xfs 

You would want to modify this statement to the following:

 daemon --check xfs xfs -port 7100 -daemon -droppriv -user xfs 

Some startup scripts use a variable to hold the port number. If this is the case in your font server startup scripts, make sure that the variable identifies port 7100 as the port on which to run the server.

You're now officially ready to go! To restart (or start) your X font server, simply execute the following command:

 # /etc/init.d/xfs restart 

If the font server isn't already running, the stop portion of the restart will fail, but the start portion will start your X font server with all your new options.

Make sure you add the X font server startup fairly early on in your various runlevels, especially if you start your machine in graphical mode. If the X font server isn't available when you try to start the X Window System itself, and no local fonts are available, X will fail to start.

3.5.5. Updating Desktop Systems to Use an X Font Server

While there's a bit of work involved in setting up your X font server and making sure it offers all the fonts your clients will need, switching a desktop system to use a remote X font server is easy. As mentioned previously, many modern desktop Linux distributions already use a local font server (i.e., a font server that is running on the same host as the X server) to deliver fonts. Switching these systems to use a remote X font server is extremely easy.

The key to where your X server gets its fonts is the Files section of its configuration file. As stated previously, if the Files section contains a single, uncommented statement such as the following, that system is using itself as a local font server:

 FontPath "unix/:7100" 

To switch this system to using the remote font server, change this line to something like the following:

 FontPath "tcp/fontserver1.vonhagen.org:7100" 

You should then restart the X server on your desktop system to ensure that it can contact the X font server and retrieve the fonts that it needs. If the system cannot contact the font server, starting X will fail, and you should follow some of the tips in the troubleshooting section of this hack. Otherwise, you're done!

Though I'm a fan of centralizing X resources such as fonts to make everyone's lives easier, I use a somewhat paranoid X server configuration file that provides some fallback in case a font server or the network goes down. For example, the FontPath entries in the xorg.conf files for machines on my home office network are the following:

 FontPath "tcp/fontserver1.vonhagen.org:7100" FontPath "tcp/fontserver2.vonhagen.org:7100" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/local" 

This tells my X servers to try two local font servers first and then fall back to a minimized collection of local fonts if the font servers don't work for some reason. The font servers are just CNAMEs in my DNS server, so I can easily move them to different hosts as my computing environment evolves. The fallback entries cover those rare cases when I just want to start a single machine.

3.5.6. Troubleshooting

If an X server can't contact your font server and that is the only font resource and you haven't provided any local fallback fonts, the X server will not start and will terminate with a message about not being able to contact the font server. Luckily, both Linux and the X Window System include some helpful commands to enable you to diagnose the problem.

First, on the font server, make sure that the font server is actually running by using the ps command, as in the following example:

 $ ps -ef | grep xfs root 13841 31053 0 04:39 pts/13 00:00:00 xfs wvh 13848 31053 0 04:39 pts/13 00:00:00 grep -i xfs 

Next, check that you can contact it successfully by retrieving a list of the fonts that it provides. You can do this using the fslsfonts command, as in the following example:

 $ fslsfonts -server  fontserver1 :7100 

This should display a long list of available fonts. If it doesn't, make sure that the font server is actually listening on the correct port, using a command like the following:

 $ netstat -an | grep 7100 tcp    0   0 0.0.0.0:7100 0.0.0.0:*  LISTEN tcp    0   0 :::7100 :::*  LISTEN unix 2  [ ACC ] STREAM LISTENING   862009 /tmp/.font-unix/ 

If you don't see this information and you can't contact the X font server using fslsfonts, make sure that you commented out the no-listen = tcp entry in your font server's configuration file.

If you see messages like the following when you start your X font server, some of the directories specified in its configuration file either don't exist or don't contain valid fonts:

 xfs notice: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) xfs notice: ignoring font path element /usr/X11R6/lib/X11/fonts/CID (unreadable) xfs notice: ignoring font path element /usr/X11R6/lib/X11/fonts/local (unreadable) 

These messages are nonfatal, but you should clean up your font server's configuration file so that no other sysadmin is confused about whether these directories were supposed to contain fonts that have somehow gotten "lost."

Finally, double-check that you have the right font server settings in your X server's startup file. You can use the fallback approach suggested in the previous section to start the X font server using a small collection of local fonts until you resolve your connectivity problems. While you're working on them, you can use the fslsfonts and xset fp (set font path for the X Window System) commands to, respectively, test connectivity to the font server and add it to your current X session for testing purposes. The xset fp command enables you to add a font server to the list of font sources that X applications search (known as a font path), using a command like the following:

 $ xset +fp tcp /fontserver1 :7100 

You may need to cause the X server to re-probe its font sources by using the xset fp rehash command. While testing, you can also remove elements from your X font path using a command like the following:

 $ xset -fp tcp /fontserver1 :7100 

You can determine the current settings for your X font path (along with other settings) by executing the xset -q command, which provides a variety of information about your working X Window System environment.

3.5.7. Summary

The X Window System is a great thing for Linux and Unix users, but the number of available (or required) fonts can quickly escalate, especially in internationalized (I18N) environments. Some X Window System applications, such as Wolfram Research's Mathematica, also take advantage of many custom fonts in order to display results as nicely as possible. (Wolfram's docs even identify a font server that they export over the Internet for this purpose.)

Centralizing resources such as fonts that are used by many of the machines in your computing environment can save local disk space and, more importantly, provide a single location where you can easily install custom fonts that multiple users may require. Be careful, thoughcentral resources simplify administration, but they can also provide single points of failure unless you architect your installation correctly.

The disk space required to install most fonts locally is no big deal (or expense) nowadays. However, centralizing custom fonts is always a good idea. Installing custom fonts locally isn't really a problem until you upgrade or replace the machine on which they live, at which point you may forget that the machine had custom fonts installed. Once bitten, twice shy! An X font server is easy preventative medicine for this sort of problem.

3.5.8. See Also

• man xset

• man xfs

• man fslsfonts

• http://www.x.org

• http://www.xfree86.org