TUX & CGI

["Christians, Stefan Mr." <software@kkalice.com>]

After a few days of examining code, reading mailing lists (everybody
seems to have the same problem) and pure luck (because of a typing
error, it suddenly worked), I got my TUX to do CGI:

1) Configuration
================

a) file /etc/sysconfig/tux:
--
DOCROOT=/var/www/html
CGIROOT=/

If CGIROOT is not set to the root directory, TUX will spit out the
chroot error complaining that cgiroot is not set correctly.


b) file /etc/tux.mime.types:
--
make sure the line
TUX/CGI   cgi pl
is active (uncommented) and make sure the file extensions cgi and pl are
not also assigned to any other mime types. (If they are, just delete
them there).


c) /etc/sysctl.tux
--
net.tux.mode_allowed (default 4) and net.tux.mode_forbidden (default 0)
seem to be working fine, so I am not using any /etc/sysctl.tux file.


2) CGI scripts
==============

This is a little bit confusing. TUX requires the CGI scripts to be in
the cgi-bin subdir, which is relative to DOCROOT. So

mkdir /var/www/html/cgi-bin

and put all your *.cgi and *.pl files in there.

At the same time, however, TUX checks whether it is allowed to serve the
files, and these checks are done on files inside DOCROOT. So either

cp /var/www/html/cgi-bin/* /var/www/html/

or make sure that for each file in cgi-bin there is a file in DOCROOT
with the same name, user, group, and permissions. These copies can be
zero length, TUX only checks the attributes.


3) Binaries and Libraries
=========================

For reasons I do not comprehend (after all, we are chrooting into
CGIROOT, which is /) also the binaries and libraries used by bash (for
bash CGIs) and perl (for perl CGIs) have to be copied into DOCROOT.
Unfortunately, in this case zero-length files do not work, and it must
be the original files.
Symbolic links do not work because TUX will not follow them back from
DOCROOT, and hard links do not work if your /bin, /lib, /var, and /usr
are on different file systems. So you will need to make real copies.

a) Binaries
these are easy:

mkdir /var/www/html/bin
cp /bin/bash /var/www/html/bin/

mkdir -p /var/www/html/usr/bin
cp /usr/bin/perl /var/www/html/usr/bin/


b) Libraries

Running ldd /bin/bash or ldd /usr/bin/perl shows which libraries are
required. These are symlinks inside the /lib or /usr/lib directories
pointing to the actual library which has a version number in its name.
If we use a normal "cp /sourcedir/symlinkname /targetdir/", the actual
library will be copied with the name of the symlink, which is just what
we need.
It also does not seem to matter in what subdirectory the copied
libraries are placed, so I have just copied them into their respective
base directory. (That is because I hate having 10 subdirectory levels
for just one file).

According to which scripting language you want to use ...

common for both bash and perl:

mkdir /var/www/html/lib
cd /var/www/html/lib

cp /lib/ld-linux.so.2 .
cp /lib/libc.so.6 .
cp /lib/libdl.so.2 .


for bash: (still in /var/www/html/lib)

cp /lib/libtermcap.so.2 .


for perl: (still in /var/www/html/lib)

cp /lib/libcrypt.so.1 .
cp /lib/libm.so.6 .
cp /lib/libnsl.so.1 .
cp /lib/libpthread.so.0 .
cp /lib/libutil.so.1 .

mkdir /var/www/html/usr/lib
cd /var/www/html/usr/lib

cp /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so .


That should do the trick.



4) Conclusion
=============

The service I want to set up is really very primitive: delivering
kickstart configuration files to clients based on their IP number. (I do
not want to use the normal NFS way, because showmount -a keeps
displaying the kickstart clients until you remove them manually).
I thought TUX would be great for this job, since it is small and works
with almost no overhead. No other http requests will be made to this
server.

What really worries me here is that if some libraries are updated by new
rpms, the files in /lib and in /var/www/html/lib will not be identical
anymore, and I have no idea how TUX will react in such a case.

Even though TUX seems more appropriate for such a simple job than a
full-blown Apache, the Apache configuration for running CGIs is much
simpler and more "logical", and all binaries and libraries are where
fresh rpms expect them to be.

It might just really be better to have Apache installed and serve
kickstart scripts in overkill-mode than have a sysadmin worry and check
everyday whether TUX is still doing CGI correctly.