Anyone using TUX?

[Website Rob]

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.

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).

http://www.linuxgazette.com/issue85/vinayak.html


Anyone using this? Sounds like it might be better than &caching& but hesitant to use on a working Server.

 

[extremeskins]

This is the exact question I came here to ask!

Let me preface this by saying that I am a relative noob when it comes to linux, so there are syntax issues that I am sure I am clueless about.

From looking over the documentation on TUX, there appears to be two issues that could be problematic:

1. cPanel creates new accounts in the /home dir. with the extention /username/public_html leading to the webpages. TUX requires a DOCROOT to take you to the folder containing the webapges, and it also has some options to consider for virtual hosting and IP hosting, and its within these options that things get confusing/potentially problematic:

From the following URL:
http://www.redhat.com/docs/manuals/tux/TUX-2.2-Manual/virtual-hosting.html

Red Hat Content Accelerator supports mass virtual hosting, which enables a very high number of virtual hosts.

There are three tunables that deal with virtual hosting:


virtual_server — Valid values are 0, 1, 2, or 3.

mass_hosting_hash — Valid values are 0, 1, 2, or 3.

strip_host_tail — Value must be an integer.

These three tunables depend on each other, and the strip_host_tail tunable is only used if host based virtual serving is enabled. Otherwise, it is ignored.

virtual_server
If the value is set to 0, virtual hosting is disabled:

http://www.example.com/a.html => $DOCROOT/a.html


If the value is set to 1, host-based virtual hosting is enabled:

http://www.some.site.com/a.html => $DOCROOT/some.site.com/a.html



Note
Red Hat Content Accelerator strips off the www. prefix variants and transforms the hostname to lowercase.


If the value is set to 2, IP-based virtual hosting is enabled:

http://www.some.site.com/a.html => $DOCROOT/1.2.3.4/a.html


If the value is set to 3, a mixture of host-based and IP-based virtual hosting is enabled:

http://www.some.site.com/a.html => $DOCROOT/1.2.3.4/some.site.com/a.html


mass_hosting_hash
The mass_hosting_hash tunable modifies the hostname mapping to be more effective for a large number of hosts.

If the value is set to 0, mass_hosting_hash is disabled.

If the value is set to 1:

http://www.some.site.com/a.html => $DOCROOT/s/some.site.com/a.html


If the value is set to 2:

http://www.some.site.com/a.html => $DOCROOT/s/so/some.site.com/a.html


If the value is set to 3:

http://www.some.site.com/a.html => $DOCROOT/s/so/som/some.site.com/a.html


string_host_tail
The strip_host_tail tunable strips off hostname components, starting at the end of the hostname.

If the value is set to 0, this tunable is disabled.

If the value is set to 1:

http://www.some.site.com/a.html => $DOCROOT/some.site/a.html


If the value is set to 2:

http://www.some.site.com/a.html => $DOCROOT/site/a.html

Based on the above, there doesnt appear to be a way to append the /public_html folder to the $DOCROOT/sitename/

As I said before, I am a noob when it comes to linux syntax, so I do not know if this is a problem or not... If linux interprets $DOCROOT/username/public_html/a.html == $DOCROOT/domainname.com/a.html then there should be no problem here... I am hoping someone with more knowledge/experience can answer this.

To whomever helps us on this, Thanks for your time in advance!