Question

We're using a twiki.conf Apache configuration created by ApacheConfigGenerator in order to enable mod_perl on my site. But when we enable this configuration file, the entire TWiki site gives "302" (file moved) errors on every topic page. Even stranger: the error always reads "The file has moved here.", with no file name or path to wherever "here" is.

What are we doing wrong?

Environment

-- JohnDeStefano - 28 Sep 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

I read somewhere that not having the preference SystemWebName set may cause a problem. This was not set on my site (also not included in the LocalSite.cfg.txt template), even though the variable has a value under configure --> 'Store settings'. I tried to set this in bin/LocalLib.cfg, but I see no effect.

I also see errors like the following for each plug-in in my Apache error log: Could not write "Plugins: could not fully register , no plugin topic" to /warn200710.txt: Permission denied

I read that this indicates permissions issues in data/, but data/ and all its contents (and its directories' contents) are owned by the apache user.

-- JohnDeStefano - 01 Oct 2007

This looks like the absolute directory paths have not been set correctly in configure. Simple evidence: it tries to write to /warn200710.txt, where the correct configuration should be a concatenation of $TWiki::cfg{DataDir} and /warn200710.txt. Please check lib/LocalSite.cfg, it should contain five variables pointing to directories: $TWiki::cfg{xxxDir}, where xxx is Pub, Data, Templates, Locales, and Working, and all of them should contain absolute directory paths to your directories (including data).

Or re-run configure and check the warnings!

-- HaraldJoerg - 01 Oct 2007

When I run configure, I see only a warning that the value for {DefaultUrlHost} doesn'nt match HTTP_HOST; TWiki is running on a "back-end" server, which is proxied by an Apache server in front of it, so these values don't match (maybe they should anyway?). But that's the only warning; there are no errors.

When I look at lib/LocalSite.cfg, there are two sections that contain directory values: a $cfg section, and a $TWiki::cfg section, and some of the values are repeated:

...
$cfg{DataDir} = "/var/www/twiki/data"; # /home/httpd/twiki/data
$cfg{PubDir} = "/var/www/twiki/pub"; # /home/httpd/twiki/pub
$cfg{TemplateDir} = "/var/www/twiki/templates"; # /home/httpd/twiki/templates
...
$TWiki::cfg{DataDir} = '/var/www/twiki/data';
...
$TWiki::cfg{LocalesDir} = '/var/www/twiki/locale';
...
$TWiki::cfg{PubDir} = '/var/www/twiki/pub';
$TWiki::cfg{TemplateDir} = '/var/www/twiki/templates';
...

As you can see, although some of the values are repeated, not all are present: I don't have a Working directory set in either section. Is this critical, and what does it represent?

-- JohnDeStefano - 02 Oct 2007

The contents of your lib/LocalSite.cfg look good enough, the repetition is harmless. Sorry, forget about Working. It doesn't exist in your version of TWiki. I didn't read your data carefully enough.

It seems that your Apache setup needs a closer look. I had run a TWiki 4.0 with mod_perl proxied by an Apache until some months ago, but never had this problem. Unfortunately I'm not familiar with RHEL's configuration, so, until someone else steps in, I'll have to ask some questions. At first, let me explain how I interpret your information:

• The message Plugins: could not fully register , no plugin topic should have a name of a plugin between register and the comma, I assumed you left it out because it appears for every plugin. This message appears if TWiki can not read the "plugin topic" at /var/www/twiki/data/TWiki/XyzPlugin.txt, which usually holds some configuration data for the plugin.
• The wrapper Could not write "...." to /warn200710.txt: Permission denied appears if TWiki fails to write the error message above to /var/www/twiki/data/warn200710.txt, where it usually dumps its warnings.
• So basically, TWiki seems to find its libraries (because it could formulate the warnings), but fails to find its data directory for both reading and writing. That's why I guessed that the directory configuration in LocalSite.cfg is wrong.
• configure is the only script which does not need any other directories (other than lib), and per autogenerated configuration it is not invoked via mod_perl.

1. You write that you used ApacheConfigGenerator to enable mod_perl. Does this mean that you had a working TWiki up and running without mod_perl?
2. Do you have other mod_perl applications, or in particular other TWiki installations running on the same backend host (maybe another VirtualHost)? The latter won't work whatever you try, because they would use different sections of the Apache configuration, but the same TWiki code, and the same %TWiki::cfg configuration.
3. Did you restart the backend web server after running configure? Since the configuration data will be "compiled in" when you use mod_perl, you need to restart the server for every configuration change to take effect. Only configure itself is "immune" to that effect because it is run as cgi-script.
4. As a simple brute-force experiment you could check whether your local configuration is evaluated at all by adding a line to LocalSite.cfg (with an editor, configure can't do that):

        print STDERR "found the local configuration file\n";
        

   Then restart Apache, run a TWiki request (not configure), and have another look at the access and error log files.

Good luck!

-- HaraldJoerg - 02 Oct 2007

Harald, thank you for taking an in-depth look at this problem I'm having. Your interpretation is very much correct:

• I had included a placeholder for the plugin name for each plugin, but it wasn't in proper format and was stripped out of my code.
• I've made sure that the entire twiki directory is recursively owned by apache, including twiki/data and its contents.
• It's entirely possible that I've screwed something up in my LocalSite or LocalLib files; I've attached them here for your perusal.

1. We still have the TWiki running, but when I try to enable mod_perl using the parameters given by ApacheConfigGenerator, I get nothing but those "moved" messages when viewing any TWiki object.
2. This is the only TWiki instance running on this host. The only other VirtualHost is one on port 80 for TWiki content that has been published to HTML (TWiki is being served on port 443, protected by BasicAuth). I may as well include my Apache config files, in case you might spot something there too.
3. After each change, I restart Apache using apachectl graceful; of course, I have to do it again shortly thereafter when it breaks. To test mod_perl, I would un-comment the FilesMatch lines in the attached twiki.conf.
4. Adding that line seemed to work:

   [Wed Oct 03 09:34:53 2007] [error] [client [ip_address]] found the local configuration file

Please have a look and let me know if you see anything peculiar? Thanks!

-- JohnDeStefano - 03 Oct 2007

That's weird. TWiki with mod_perl seems to process your LocalSite.cfg and yet to be unable to correctly point to your directories. I didn't spot anything strange in your configuration which should be affected whether mod_perl is active or not. It is not quite clear to me whether the server is to be accessed via HTTP or HTTPS, and how your authentication works (you have TemplateLogin in the twiki configuration, plus Apache login in ssl.conf), but that shouldn't matter.

Some thoughts:

• Redirection is quite common in TWiki, especially with TemplateLogin, where the login "screen" is implemented as a redirection. You could check whether you see 302 status codes in your access log file immediately whether you start Apache without mod_perl (or generally compare access logs for both scenarios).
• A frequent trap with mod_perl is that the "current directory" is not guaranteed to be that where the initial program was located. I can't see any indication of TWiki assuming that, though.
• Some plugins have had, or maybe have, mod_perl issues. I do not know the plugins you use, but you could try disabling them, just to make sure that it isn't one of these which creates bogus redirections.

-- HaraldJoerg - 03 Oct 2007

The TWiki server is accessed via HTTPS on port 443, protected by Kerberos. The TWiki content is mirrored via publishing on port 80, unprotected.

With mod_perl disabled, I don't see any 302 codes after restarting Apache and viewing the TWiki site (a bunch of 304s, but not 302).

Not sure why login was set to TemplateLogin, as it was set to ApacheLogin ... I've changed that value back. As you said, not sure that will have any effect on this problem, and strangely, logins seemed to have been working fine with the 'wrong' setting.

If you have any ideas on where to print, I'd be willing to try.

Thank you for your help.

-- JohnDeStefano - 04 Oct 2007

I don't understand this at all... we had the following plug-ins installed and enabled:

• SpreadSheetPlugin
• CalendarPlugin
• CommentPlugin
• EditTablePlugin
• InterwikiPlugin
• PreferencesPlugin
• PublishWebPlugin
• RenderListPlugin
• SlideShowPlugin
• SmiliesPlugin
• TablePlugin
• TwistyPlugin
• WebPermissionsPlugin
• WysiwygPlugin

We also had these plug-ins installed, but not enabled:

• BlackListPlugin
• EmptyPlugin

I enabled the mod_perl block in twiki.conf, disabled all plug-ins, and restarted Apache. No errors. I then enabled each of the above plug-ins, one by one, and restarted Apache. No errors. But the TWiki pages took longer to load. I checked a perl-status script, which showed that "Embedded Perl" was running, but TWiki configure said "mod_perl is not loaded into Apache".

I then disabled the mod_perl bit in twiki.conf again, and all of the above held true still: perl-status says mod_perl is running, configure still says mod_perl isn't loaded.

I'm confused. How can I figure out what the heck is going on?

-- JohnDeStefano - 09 Oct 2007

In your case, configure can not detect mod_perl: The script itself is running under cgi-script, and you have ServerTokens OS in your httpd.conf, which prevents Apache from delivering information about its modules to scripts. The information of perl-status should be correct.

Enabling plugins can slow down the first request after restart (once for every process, to be precise), because on this occasion the modules for the plugin will be compiled. To avoid that, you can pre-load plugins in your mod_perl startup file.

You wrote that you enabled the modules again, restarted the server, and still have no errors? That would be good news (regardless of whether I understand what has fixed your problem)

-- HaraldJoerg - 10 Oct 2007

Right: the problem seems to have "disappeared," which doesn't seem to make much sense, since all the plug-ins that were previously loaded are now loaded again, and the configuration hasn't changed. That worries me a bit.

I changed ServerTokens OS to Full (on both the host and the proxy), and now TWiki's configure does say "mod_perl is loaded". Is there any other benefit to Full (other than giving away lots of info about your server?

But even though it's "working" now it's still very slow. How would you go about pr-loading the plug-ins (and are the plug-ins the real culprit for the site's lack of speed)?

Update: we've now implemented Webauth on the proxy in front of the TWiki. But if I enable the mod_perl block in twiki.conf, there aren't any errors, but TWiki thinks everyone is a guest [?] instead of recognizing the mapped names in TWikiUsers to their Kerberos names.

-- JohnDeStefano - 11 Oct 2007

Well, fine that it works now - I have to admit that I'm not overly concerned about not understanding why

The ServerTokens directive is not really needed by TWiki, with the exception of being evaluated when it tries to figure out whether mod_perl is loaded. Otherwise it isn't used by TWiki. Whether a particular request is run under mod_perl is being detected by checking the "correct" environment variable.

There are security scanners (Nessus etc.) which will issue a warning if the server gives away information, and for that reason I'm running with the most restrictive setting of ServerTokens Prod. No problem with TWiki, apart from its inability to detect mod_perl.

Pre-loading modules is best achieved by writing the appropriate code into your mod_perl_startup.pl. Something like:

use lib /your/path/to/TWiki/lib;
use TWiki;
use TWiki::Plugins::SpreadSheetPlugin;
use TWiki::Plugins::SpreadSheetPlugin::Calc;
# repeat ad libitum for other modules

The trick is to really load all the modules, because in many cases plugin code will be compiled "just in time", dynamically on the first request which needs it. The mod_perl processes will most likely compile all modules during their lifetime anyway, so there's no harm in compiling them from the start.

And finally, by compiling them into the startup routine, you get the code compiled before the processes fork, so the memory footprint should be smaller than if you compile "on demand" (I haven't verified that, though). Apache with mod_perl tends to be "fat" because every process has both Apache and Perl in his memory, whereas with CGI they have only either one.

Did I mention that I'm running my TWiki on a 256MB virtual machine, without ever having touched swap in 30 days uptime? I've reduced the number of initial processes to two because simultaneous access isn't happening very often, and that did the trick.

Since we're digressing from the original question (and topic name) I suggest to close the status of this question as of now - feel free to open another one for performance related stuff, with a title where answers are more likely to be picked up by other twikizens

-- HaraldJoerg - 11 Oct 2007

• twiki_apache_conf.files.zip: Our Apache and TWiki configuration files