|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.
[Older Fedora Users Mail] [Home] [Fedora Legacy] [Fedora Desktop] [iPod Nano] [ATA RAID] [Fedora Bible] [Fedora Marketing] [Fedora Mentors] [Fedora Packaging] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools] [Fedora Docs]