• Resolved ropezg

    (@ropezg)


    Hello,

    I’ve been using BulletProof security for a year and I like how it works, it’s a great plugin!
    Today I upgraded my site to wordpress 4.0 and soon after I noticed a lot of the same errors appearing in the apache error_log (never had these errors before):

    (9)Bad file descriptor: /home/ropezg/public_html/wp-content/cache/page_enhanced/www.mysite.com/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: https://www.google.co.uk/

    These errors only started to appear today and my impression is that they’re connected to the upgrade (I didn’t do any other changes on the site).
    First realized that something is wrong when I started receiving resource down notifications from HostTracker Notifier. Asked my hosting support what’s happening and they found those errors in the log file.

    After I turned off the Booleproof mode (turned on Default mode) these errors have stopped.

    As I would like to continue using this great plugin, could you please give me any tips on how to get rid of the above mentioned errors?

    Thanks a lot!

    ps. I did google for a solution before posting this, but didn’t find anything helpful

    https://wordpress.org/plugins/bulletproof-security/

Viewing 15 replies - 1 through 15 (of 21 total)
  • Plugin Author AITpro

    (@aitpro)

    I believe that is the location of the W3TC plugin .htaccess file.

    /wp-content/cache/page_enhanced/www.mysite.com/.htaccess

    Check that the permissions of the /cache/ folder are correct for your server type.
    Since it appears you are using W3TC go to this W3TC menu >>> Install and check that the .htaccess code you are using for the w3tc htaccess file is correct and that the htaccess code you are using in your root .htaccess file / BPS Custom Code is correct. Change / fix whatever code needs to be changed. If after using the htaccess code that is provided by W3TC and if you are still seeing that error message then you need to contact your host and send them the htaccess code so they can tell you if there is anything in that htaccess code that they no longer allow on their servers.

    Thread Starter ropezg

    (@ropezg)

    Hi,
    thanks a lot for the tips.
    I found some suggestion about renaming the .htaccess folder under page_enhanced/www.mysite.com
    I did that, plus recreated the bulletproof htaccess version and since then there are no such errors (for the last 5 hours at least, hope it will stay like that).

    The only errors I’m seeing now are like this one:
    [error] [client 173.245.50.177] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.google.co.in/search?q=vibereting%20ring%20condom/

    When googling I found that this could be connected to Bulletproof security plugin.
    I turned off logging in BulletProof security (found somewhere this tip), but the same errors are still appearing

    Any suggestions regarding this?

    Hope it’s OK to mention that here. I can open a new topic if necessary

    thanks!

    Plugin Author AITpro

    (@aitpro)

    IP Address: 173.245.50.177 is a CloudFlare IP address. So what you want probably want to check is if you have outdated or corrupt CloudFlare cache somewhere. I don’t really know much about CloudFlare so I cannot offer much more help then to say login to your CloudFlare account and check your settings and clear cache or whatever else is possible with CloudFlare settings. πŸ˜‰

    Plugin Author AITpro

    (@aitpro)

    My knowledge of both Cloudflare and W3TC is fairly limited and my knowledge of how they interact with each other is nill, but maybe this has something to do with how Cloudflare and W3TC are caching things? Totally taking a logical guess here πŸ™‚

    Thread Starter ropezg

    (@ropezg)

    I think you’re right, all the IPs in these errors that I’ve checked lead to Cloudflare.
    so that’s a good hint! will dig deeper in that direction…

    thanks for all the help, I appreciate it!
    cheers!

    Plugin Author AITpro

    (@aitpro)

    Very welcome. Please resolve this thread. You can still post back here after the thread is resolved if you want to add additional help info about W3TC or Cloudflare that would help other folks out. Thanks.

    Thread Starter ropezg

    (@ropezg)

    marked as resolved
    thanks!

    Thread Starter ropezg

    (@ropezg)

    Hello,
    here’s an update regarding the internal redirect errors.

    I tried all suggestions I could find online, which include:
    – commenting out these lines:

    ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
    ErrorDocument 401 default
    ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
    ErrorDocument 404 /404.php

    – adding this:

    # .htaccess Fix for Infinite Loops
    RewriteEngine On
    RewriteCond %{ENV:REDIRECT_STATUS} 200
    RewriteRule .* - [L]

    – turning off W3 plugin

    None of it worked.

    But after I removed the Bulletproof security code from my htaccess file those errors disappeared (W3 and cloudflare are still active).

    So it looks to me that some Bulleproof htaccess directives are causing this.

    Could you suggest any particular directives that I could try to comment out and see if there would be any effect?

    thank you!

    ps. below is one more example of this kind of error, this time with a referrer:

    [Fri Sep 12 03:30:43 2014] [error] [client 108.162.254.71] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.,
    referer: http://www.google.com/url?q=http://www.condom-sizes.org/condom-brands/condom-brands&sa=U&ei=3KASVJnMAYiCPbuegLAG&ved=0CDUQFjAH&usg=AFQjCNHrwQtcXx16PXsHhALTj-vwG2hUkA
    Plugin Author AITpro

    (@aitpro)

    This seems odd to me and could be the root cause. Your site is not SSL, but if you look at the ga settings it says to force SSL. This could cause a redirect loop problem if you are telling google you have SSL and you do not.

    This site uses the Yoast Google Analytics plugin v5.0.5 - Universal enabled - https://yoast.com/wordpress/plugins/google-analytics/ -->
    <script type="text/rocketscript">
    	(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
    		(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
    		m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
    	})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
    
    	ga('create', 'UA-21397667-1', 'auto');
    	ga('set', 'forceSSL', true);
    	ga('require', 'displayfeatures');
    	ga('send','pageview');
    
    </script>
    / Yoast Google Analytics 
    
    Your site is not SSL
    <link rel="canonical" href="http://www.condom-sizes.org/condom-brands/condom-brands" />
    Plugin Author AITpro

    (@aitpro)

    hmm maybe this does or does not cause a problem, but you should eliminate that as a possibility.

    https://developers.google.com/analytics/devguides/collection/analyticsjs/advanced

    Forcing SSL (HTTPS)

    “By default, Google Analytics will match the protocol of the host page when sending outbound requests. To force Google Analytics to always send data using SSL, even from insecure pages (HTTP), set the forceSSL field to true:

    ga('create', 'UA-XXXX-Y', 'auto');
    ga('set', 'forceSSL', true);        // Send all data using SSL, even from insecure (HTTP) pages.
    ga('send', 'pageview');
    Plugin Author AITpro

    (@aitpro)

    You could try turning off mod_security temporarily for troubleshooting purposes. It could simply be that there is a mod_security SecRule or SecFilter that is not happy with BPS htaccess code.
    http://forum.ait-pro.com/forums/topic/how-to-turn-off-mod-security-mod_security-secfilterengine-off/

    Plugin Author AITpro

    (@aitpro)

    Or another possibility is that you have a parent .htaccess file higher up in your hosting account folder structure that is still applying the ErrorDocument directive to this website from that parent htaccess file. To test if that is what is occurring you would Turn Off Security Logging on the Security Log page and then use this test URL in your Browser window: http://www.condom-sizes.org/index.php?sp_executesql If a Security Log entry is logged after Security Logging is turned Off on this website and using this test URL above then that means a parent htaccess file is applying its rules to this website and Security Logging is still turned On for this website.

    Reference (this topic reply is pending a move to its own Topic): http://forum.ait-pro.com/forums/topic/ok-to-use-brute-force-login-protection-if-need-login-in-subfolder/#post-16705

    Thread Starter ropezg

    (@ropezg)

    that’s a lot of suggestions, I appreciate it πŸ™‚

    first thing I deactivated Yoast plugin and inserted the code manually.
    It seems that it forces SSL by default and there’s no option to turn it off.

    I will now try your other tips and update here the result

    Plugin Author AITpro

    (@aitpro)

    Yep, no problem. The only tip I did not mention is to actually check for any htaccess redirect code that is redirecting back on itself == infinite redirect loop. πŸ˜‰

    Thread Starter ropezg

    (@ropezg)

    lol
    the problem is I’m kind of a dumb-ass when it comes to reading htaccess code :/ πŸ™‚

    anyhow, I turned off logging and tried that test URL several times, nothing happens (no log)

    I have a .htaccess file higher up in the hosting account folder but it doesn’t have the ErrorDocument directives.

    after removing the forceSSL, there are no new errors so far, but it’s too soon to tell if that was the cause.

    if they start to appear I will try turning off mod_security.

    the last resort is to dissect the BPS htaccess code line by line in search for the unwanted redirect…not looking forward to it, to be honest πŸ™‚

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘apache errors after upgrade to wordpress 4.0’ is closed to new replies.