Re: TUX & CGI

Hmmm.  I have CGI working on my boxes without all of
this, especially the CGIROOT=/ part.  I just simply
modified the mime types and that was that.  I am using
Apache 1.3.2x and the DOCROOT for it is different from
the default of var/www.  Other than that, my cgi-bin
scripts work just fine.

> 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.
> 
> 
> 
> _______________________________________________
> tux-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/tux-list


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com