Getting started with TUX LG #85

...making Linux just a little more fun!

Getting started with TUX
By Vinayak Hegde

Meet TUX - "The Webserver"

If you did come to the site to read an article about Tux the Penguin -- the lucky mascot of Linux -- you might be disappointed. But don't go away just yet: read on to find what TUX the webserver can do do for you in terms of performance and you will be delighted. You might just discover something to hack on and tweak. This is an article about TUX - the webserver embedded within the Linux kernel.

The name TUX comes from 'Threaded linUX webserver'. TUX was written by Red Hat and is based on the 2.4 kernel series. It is a kernel-space HTTP subsystem. As you may have guessed by now TUX is released under the GNU GPL. So in the free software tradition, you are free to tweak it and modify it to meet your own specific needs. One of the ways of adapting TUX for our needs ,is by writing TUX modules, which can be user-space or kernel-space modules. The main goal behind writing TUX was to enable high-performance webserving on Linux. This was especially important as Linux is extremely popular in the webserver market.

TUX is not as feature-filled as Apache and has some limitations. But nevertheless, TUX is a complete HTTP/1.1 compliant webserver supporting HTTP/1.1 persistent (keep-alive) connections, pipelining, CGI execution, logging, virtual hosting, various forms of modules, and many other webserver features. TUX is now officially known as the Red Hat Content Accelerator (RHCA).

What can TUX do for me ?

Though quite some amount of today's webcontent is dynamic generated, most of the webcontent is static. Take for example static webpages and images. This leads to quite a overhead as user-space webservers such as apache have to be use some system calls for actually serving the content. The frequent context switches between kernel-space and user-space programs is quite a performance hit. TUX is a saviour here. TUX can be built into the monolithic kernel or dynamically loaded as a module. The first approach is preferable for servers which are dedicated to webserving. When built as a loadable module, it can be dynamically inserted and removed, as when the service is started or stopped respectively. This approach affords some amount of flexibility.

TUX is used primarily for serving static content, leaving generation and serving of dynamic content to backend webservers such as Apache. Now, newer versions of TUX have the capability to cache dynamic content as well. TUX modules can create "objects" which are stored using the page cache. To respond to a request for dynamic data, a TUX module can send a mix of dynamically-generated data and cached pre-generated objects. Thus, most of the requests which are just "network-copy" operations can be handled efficiently by TUX. The new version of TUX uses zero copy block IO instead of a temporary buffer as in TUX 1.0. Also virtual hosting support has been enhanced for TUX and the number of virtual hosts that can be supported is only limited by disk space and RAM.

Getting started with TUX

Now that we know what TUX is capable of, we can move to installing and configuring TUX. All the information that follows has been tested on Red Hat 7.2 with TUX-2.1.0-2. Due to ease of use and familiarity Apache has been used as the user-space webserving daemon.

Step 1. Installing TUX

Check whether you have tux installed using the command :-

# rpm -q tux

You may get messages similar to the ones below :

tux-2.1.0-2 (TUX is installed and the version number is printed)
package tux is not installed (obvious!!)

If TUX is not installed, download the rpm (or source package) you can install it using the following command:

for RPM packages
```
# rpm -ivh tux-2.1.0-2.i386.rpm 
```

for Source packages
patch the kernel

# patch -p0 < tux2-full-2.4.10
# make oldconfig (enable tux here,recompile and install the kernel)

Install the user-space utilities

# tar xzvf tux-2.1.0.tar.gz 
# cd tux-2.0.25 
# make 
# make install

Step 2. Setting the stage

Create the directory /var/www/html (or some other directory of our choice) and make it the root directory of TUX by changing the value of DOCROOT in /etc/sysconfig/tux. Also you can give the path where your CGI-scripts are stored to CGIROOT. Also the TUXTHREADS variable can be set to an appropriate number here. Also create the index.html page in the root directory. This will be used for testing later.

Step 3. Starting TUX

TUX can be started by using the command. (As superuser)

# service tux start (on RH systems)
# ./tux.init start (on non-RH systems)
# lsmod
Module	size 	Used by
tux 	75568	0	
....
....

Now point your favorite browser to localhost and you should see the index.html page we created earlier. If not something has gone wrong or the configuration is not proper. Check step 8 for details.

# lynx localhost

Step 4. Enabling Logging

By default, logging is disabled. To enable logging and referrer logging, give the following commands.

# echo 1 > /proc/sys/net/tux/logging
# echo 1 > /proc/sys/net/tux/referer_logging
# cat /proc/sys/net/tux/logfile
/var/log/tux (this is the default logfile)

For each request, TUX logs the address of the requester, a date and time stamp accurate to at least one second, specification of the file requested, size of the file transferred, and the final status of the request. The log files for TUX are stored in /var/log/tux (as seen above) in binary format. In this binary format, the log files are approximately 50% smaller than standard ASCII text log files. To view log files issue the following command

# tux2w3c /var/log/tux
127.0.0.1 - - Wed Nov 20 00:22:24 2002 "GET /manual/sections.html HTTP/1.1" - 5523 200
127.0.0.1 - - Thu Nov 21 01:36:55 2002 "GET / HTTP/1.0" - 2890 200
127.0.0.1 - - Thu Nov 21 01:37:20 2002 "GET /manual/index.html HTTP/1.0" - 5557 200
127.0.0.1 - - Thu Nov 21 01:37:24 2002 "GET /manual/mod/index-bytype.html HTTP/1.0" - 6186 200

The tux2w3c program converts the binary log files into into standard W3C-conforming HTTPD log files.

Step 5. Enabling Gzip Compression

As we already know TUX is all about speeding up the response time. Using Gzip compression, it is also possible to reduce the download time as well as save some bandwidth. But for this feature to work the client must support Gzip compression. By default, this data compression is disabled. To enable it, do the following:

# echo 1 > /proc/sys/net/tux/compression

To enable it at startup add the following line to /etc/sysctl.conf

net.tux.compression=1

Also Gzip file with the extension .gz must be in the same directory as the uncompressed versions of the pages you wish to serve.

Step 6. Tweaking TUX

We are not finished with configuration yet. There are some more interesting features/tweaks which you can use. (Some of these are available only in RHCA v2.2)

application_protocol
If set to 1 this enables the RHCA FTP server. By default it is set to 1.
virtual_server
When set to 1 ,it turns on mass virtual hosting. Hosts are headers from the browser that are directly turned into $DOCROOT/ (virtual docroots) This way any number of hosts can be served by TUX without any performance penalty at all.
max_backlog
Maximum size of SYN backlog of the TUX listening socket. This has to be set sensibly to prevent SYN attacks. Default is 2048.
http_dir_indexing
If set to 1, TUX will list files in readable directories if an index file does not exist. (auto-generation of index.html)

There are lots of more parameters that can be configured to maximize the performance of the TUX webserver. Explore and tweak them to your heart's content.

Step 7. Configuring Apache to work with TUX

As mentioned before, the recommended configuration is to use TUX as a front-end Web server listening on port 80(the default http port) and to use a back-end Web server (Apache is used here as an example) on port 8080 for answering requests that TUX does not understand (generally dynamically generated content eg.PHP pages). For this configuration, some changes have to be made to the httpd.conf file of Apache webserver.

Replace the line
Port 80 

with
Port 8080 (port on which Apache will listen)

Also to prevent users from bypassing TUX and directly accessing apache make the following changes. This may be necessary for security reasons.

Replace the line
BindAddress *

with
BindAddress 127.0.0.1 (loopback address)

Finally, restart httpd using

# service httpd restart

Step 8. Debugging and Restarting TUX

You can stop/restart TUX using the following commands:

# service tux stop (for RH-Systems)
OR 
# ./tux-init stop (for non-RH Systems)

# service tux restart
OR
# ./tux-init restart

For debugging purposes you can use the gettuxconfig script in the /usr/share/doc/tux-version/ directory. If you have an SMP system you can check whether all the interfaces have been setup properly using the checkbindings scripts. It is also present in the same directory.

Conclusion

As we have seen above, TUX helps a lot to improve the efficiency of webservers by shifting some of the operations from user-space to kernel-space. This results in better performance and better use of server resources. TUX is very configurable and has a number of interesting features. Hope you enjoyed the article. Happy Hacking!!

Resources

Red Hat TechSupport for TUX (RHCA)
Latest Patches for TUX
Local Documentation in /usr/share/doc/tux-version/