XF 1.1 Cache Rebuild Problem

[Gene Steinberg]

Since moving to a server, I'm getting curious messages when trying to rebuild caches.

Somewhere along the line during the process, it'll interrupt and report:

Forbidden

You don't have permission to access /forum/admin.php on this server.


I have reinstalled all the software, run the install process to rebuild master data. I have also checked permissions, and they appear to be OK.

is there a master cache file somewhere I can just delete and have it start over?

 

[Jake Bunce]

I replied to your ticket. The rebuild is working fine for me. Let me know if you still have the problem.

 

[Gene Steinberg]

Wrong cache rebuild. Go to admin and try the post or search cache.

 

[Jake Bunce]

Ok, I have confirmed the 403 error when rebuilding the search index. I was able to avoid the error by setting a "Page delay in seconds" of 1 second. Your server may have some sort of limiter that is triggering the 403.

 

[Gene Steinberg]

Progress, but the other options don't have page delay settings. I played with a few numbers and got some to work, but not daily statistics, for example, which fails whatever I do.

 

[Jake Bunce]

You can try adding the delay to the file:

library/XenForo/CacheRebuilder/DailyStats.php

	/**
	 * Rebuilds the data.
	 *
	 * @see XenForo_CacheRebuilder_Abstract::rebuild()
	 */
	public function rebuild($position = 0, array &$options = array(), &$detailedMessage = '')
	{
		usleep(1 * 1000000);

		$options['batch'] = isset($options['batch']) ? $options['batch'] : 28;
		$options['batch'] = max(1, $options['batch']);

		/* @var $userModel XenForo_Model_Stats */
		$statsModel = XenForo_Model::create('XenForo_Model_Stats');

That is a 1 second delay. This is what the search index rebuild uses.

 

[Gene Steinberg]

So I then have to do this with all the other files impacted by rebuilding?

Which ones do you suggest?

 

[Jake Bunce]

So I then have to do this with all the other files impacted by rebuilding?

Yep. All rebuild classes are in the CacheRebuilder directory. Edit the files for the caches that give you problems.

Keep in mind this is a workaround to an apparent limit in your server config. The other option is to get with your host or server person to identify and remove the limit.

 

[Gene Steinberg]

Well, how about telling me what I should ask of the host to fix the server configuration? Maybe I could do it myself if I know which setting to mingle with.

We had a server admin harden the server, so they probably tightened things up to keep the hackers out, but it doesn't help me. I just need some direction here so I can ask the right question, or do the appropriate fixes. Is it PHP perhaps?

 

[Jake Bunce]

It would be something with the web server (Apache in your case). Probably mod_security or some similar module. I do not know what or where the limit is. You would have to examine the logs on the server for that request (admin.php?tools/cache-rebuild). The logs will reveal the nature of the 403 error. But if you are in contact with the person who setup your server then he might know right away what the problem is.

 

[Gene Steinberg]

Well, I asked them to tell me what it might be. But if anyone else has a suggestion, I'd love to follow it. My feeling is that they harden these services using default config files and templates, and thus getting them to center on any one culprit for this phenomenon may be difficult. But if anyone in these forums has a clue as to what to look for, or wants to volunteer to poke around with serious discretion, let me know via a private conversation.

 

[melbo]

Most every time I move servers or re-OS, the mod_security settings (exclusions) seem to get reset and we have to have the sec folks continue to ease them until the forum is usable again. What I do is give them my IP and the exact date and time of the error which allows them to go into the mod_security logs and find what triggered the 403 - then ease it at my request.

 

[Gene Steinberg]

Thanks but they disabled mod_security with no change. They are still looking.

 

[Gene Steinberg]

OK, it appears that the cause of this problem -- and I hope it helps others -- is mod_evasive, a script used to help reduce DDOS attacks on a server. When the admin disabled mod_evasive, the problem disappeared. It reminds me of anti-virus software slowing down a personal computer, doing things that harmed the user experience in exchange for protection.

In any case, I asked the admin to check the standard settings to see if something can be done to reduce the harmful side effects.

These are the defaults if anyone wants to suggest something:

DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 3600

 

[Gene Steinberg]

And if you have mod_evasive installed, and want to do cache rebuilds and such, you can, apparently, whitelist mod_evasive with your IP, so you can keep it running and still get your board maintenance done.

This suggestion comes from Ideamine Technologies (www.ideaminetech.com/), a third-party system admin service we hired to harden our server, and requires a cPanel installation with root and SHH access:

1. Open Apache configuration file /usr/local/apache/conf/httpd.conf
2. Search DOS, you will find DOSWhitelist entry. TypeDOSWhitelist <IP>. (If you don't have this entry, add it.)
3. Type the command /usr/local/cpanel/bin/apache_conf_distiller --update ( to make changes permanent)
4. Type /usr/local/cpanel/bin/build_apache_conf
4. Finally restart httpd. (/etc/init.d/httpd restart )

If your ISP constantly refreshes your IP number, you'll have to keep changing this setting accordingly. In my case, I ordered a static IP from the ISP (they charged me $5.95/mo. for the privilege), to avoid the aggravation.

Oh, and I asked Ideamine if they knew of a way to tweak the mod_evasive settings and not run afoul of cache rebuilding and other processes, and they said they didn't. So I'm still open to suggestions.