[ Table of Contents ] [ Previous Chapter ] [ Next Chapter ] [ Index ]

Appendix C

Customizing Web Ten

The httpd.conf and squid.conf files are the main configuration database files manipulated by the Web Ten Administration Server. Features available to Apache and Squid but not yet configurable in the Administration Server may be added to these files, creating a customized Web site configuration. Some common site customization examples are described below.



Creating Virtual Domain-Specific CGI-BIN Folders


If a unique /cgi-bin folder is desired for each virtual host, a Finder duplicate copy of the /cgi-bin folder may be placed in the document root folder for each configured virtual host (see section See Virtual Host Configuration). A custom directive is then added to httpd.conf:


Place the following directive in the affected < VirtualHost > container:


ScriptAlias /cgi-bin/ /usr/local/etc/httpd/WebSites/vhost.com/cgi-bin/


where "vhost.com" is the root folder for the virtual host.



Adding Additional Plug-In Suffix Mappings


This feature permits suffix mappings for plug-ins beyond those registered by the plug-in at server start up. For example, to configure the NetCloak plug-in to handle all .html files:


Type " CLOAK_PI " in the Action field. The CLOAK_PI action is taken from the See Plug-In Administration.


Click on Save Handlers.


Click on MIME Extensions.


Type " .html " into the Extension field and select CLOAK_PI from the pull-down Action menu. Click on Save MIME Extensions.

Overriding a Plug-In Registered Suffix Mapping


This feature can be used to selectively disable an installed plug-in on a per-virtual host basis. Using the NetCloak plug-in as an example, we demonstrate how to prevent NetCloak from serving .nclk (the suffix automatically registered by NetCloak) files accessed from VirtualHost


In httpd.conf, place an AddHandler directive inside the < VirtualHost > serving the domain.


<Vi rtualHost>

AddHandler */* .nclk





Running UNIX CGIs Outside of CGI-bin


From the access controls page, set an action handler override to cgi-script for each directory where script execution is to be allowed.




Using Squid Proxy Services with WebTen


Under WebTen, the Apache server proxy module is configurable using the WebTen Administration Server. The Squid component of WebTen is used as a caching accelerator front-end to Apache.


But Squid can also provide a very powerful HTTP/1.1 proxy service. Squid proxy access control mechanisms are more extensive than those in Apache 1.2, particularly in the area of proxy blocking, or the ability to prevent access to certain undesirable sites based on URL, browser, day, hour of the day, even minute of the hour! A simple adjustment will enhance Squid's capabilities under WebTen to provide both acceleration and proxy service.


Because Squid proxy configuration is not yet exported into the WebTen Administration Server interface, direct manipulation of the Squid configuration file is necessary. While this may at first appear daunting to someone unfamiliar with UNIX database files, it is really quite a simple process using a text editor such as BBEdit.


First, using the Administration Server interface, verify these default

WebTen settings:


* ProxyRequests Off

* AcceleratorCache On


Next, put on UNIX scuba gear and dive into squid.conf:


The squid.conf configuration file is located in the tenon/squid/etc folder

in your WebTen distribution.


* Find and change the line containing 'httpd_accel_with_proxy' to


httpd_accel_with_proxy on


That's it! Restart the WebTen server using the Administration interface and

direct your clients to the proxy on port 80 of your WebTen system.


Setting up Squid Access Control


The access control lists (ACLs) in squid.conf determine what the client

browsers can access. The basic format of an acl record is:


acl aclname acltype string1 string2 ...


aclname is a unique identifying name you give to the acl


acltype is one of: src dst srcdomain dstdomain urlpath_regex

port proto method browser user time


For example:


acl aclname src ip-address/netmask ... (clients IP address)

acl aclname src addr1-addr2/netmask ... (range of addresses)

acl aclname dst ip-address/netmask ... (URL host's IP address)

acl aclname srcdomain foo.com ... (taken from reverse DNS lookup)

acl aclname dstdomain foo.com ... (taken from the URL)

acl aclname url_regex ^http:// ... (regex matching on whole URL)

acl aclname urlpath_regex \.gif$ ... (regex matching on URL path only)

acl aclname port 80 70 21 ... (port number)

acl aclname proto HTTP FTP ... (protocol)

acl aclname method GET POST ... (request method)

acl aclname browser Mozilla$ (browser regex)

acl aclname user username ... (string match on ident output)

acl aclname time [day] [h1:m1-h2:m2] (time of day)



S - Sunday

M - Monday

T - Tuesday

W - Wednesday

H - Thursday

F - Friday

A - Saturday


To activate an acl, use it in an http_accesss statement:


http_access deny aclname

http_access allow aclname

http_access deny !aclname


Deny will deny access to the aclname, while allow allows access to the aclname. A '!' preceding the aclname denies/allows access to all but the aclname.


There are some sample ACLs in the file which you can enhance using the examples shown below. In the examples, we block access to some less than desirable domains (aclname dirty_domains) and we restrict the downloading of files (aclname download_files) ending with .hqx, .bin, and .gz to all machines that access the proxy except for a trusted group of machines (aclname download_allowed).


Here is an example of ACL-based proxy blocking:



# These are some basic ACL definitions that come with Squid.



acl manager proto cache_object

acl localhost src

acl all src


acl SSL_ports port 443 563

acl Dangerous_ports port 7 9 19




# Now some custom ACLs






[ Table of Contents ] [ Previous Chapter ] [ Next Chapter ] [ Index ]