Question

This is sortof a mix between a bug/rfe report and a support request. I am trying to run TWiki in an environment where the ONLY way to access it is via rProxy. We are using Apache/2.0.48 as the rProxy, and Sun ONE Web Server 6.1 as the backend (sorry its used for some other stuff, TWiki is just one piece). I tried posting a question to ProxyConfiguration before reading SupportGuidelines (sorry). Our config stuff is below.

I am having this same exact problem: our "content" server is behind the firewall. It is only accessable via its "external" name, TWiki is setting the URL for "pictures" (stuff in /twiki/pub) to the internal hostname. I "worked around" the problem by "forcing" urlHost like this..

    # initialize $urlHost and $scriptUrlPath
    if( ( $theUrl ) && ( $theUrl =~ /^([^\:]*\:\/\/[^\/]*)(.*)\/.*$/ ) && ( $2 ) ) {
        if( $doGetScriptUrlFromCgi ) {
            $scriptUrlPath = $2;
        }
        $urlHost = $1;
        if( $doRemovePortNumber ) {
            $urlHost =~ s/\:[0-9]+$//;
        }
        # Added by TommyMcNeely to force urlHost because of rProxy
        $urlHost = $defaultUrlHost;
    } else {
        $urlHost = $defaultUrlHost;
    }

However, after reading ProxyConfiguration I have noticed that $defaultUrlHost was for shell scripts, which would explain why they don't work anymore :). I am running the latest beta (19 Jan 2004), and can see no mention of the word "proxy" anywhere in the config or TWiki.pm. Is something like this available in alpha code, or are we doomed to hack in our "external" host like I did above (perhaps using a different variable).. I kindof like the idea of having proxyHost .. then if ($proxyHost), see if proxyHost is in urlHost, if its not, set urlHost to ProxyHost .. right?

Also, even with my "hack" inplace to force urlHost to defaultUrlHost, the table plugin generates its "header links" using the incorrect hostname... so I am not sure what to do next, it would seem that TWiki just doesn't appreciate running behind an rProxy, and various parts of it use different base configuration.. Aiieeeeeee!

• only meaningful error from the newest testenv script (besides the nobody thing)

$defaultUrlHost:   https://external.domain.com
   Note: This must match the protocol and host part (with optional port number) of the TWiki URL.
   Warning: This does not match HTTP_HOST

• ofcourse it doesn't, HTTP_HOST is the hostname of the "internal" content server, not sure how the content server would recieve the proper information, as it will always see requests for https://internal.only.host.domain.com .. The only way I can think of (and I am not a developer) is to have a new variable in TWiki.cfg and replace the hostpart with that if its defined.

Apache rProxy Config

• relevent apache.conf section

<VirtualHost external.domain.com:443>
   SSLEngine on
   SSLProxyEngine on
   SSLCertificateFile conf/ssl/external.domain.com-cert.pem
   SSLCertificateKeyFile conf/ssl/external.domain.com.key
   SSLCertificateChainFile conf/ssl/cachain.crt
   DocumentRoot /var/apache/htdocs
   ProxyPass / https://internal.only.domain.com/
   ProxyPassReverse / https://internal.only.domain.com/
   ServerName external.domain.com   ErrorLog logs/BLAH-https-error_log
   CustomLog logs/BLAH-https-access_log common
</VirtualHost>

relevent Sun ONE Config

• fix mime.types (for attachments)
  • comment out all the magnus-internal and enc lines, replace them with good ones from a linux /etc/mime.types file (reformat to make them look like the other entries)
• section of obj.conf to "make TWiki work"

NameTrans fn="pfx2dir" from="/twiki/pub" dir="/path/to/twiki/pub"
NameTrans fn="pfx2dir" from="/twiki/bin" dir="/path/to/twiki/bin" name="cgi"

Environment

-- TommyMcNeely - 09 Feb 2004

Answer