tomdkat

Hi! Thanks for the info! I’ll run the above query and will send the results via e-mail in a few minutes.

Thanks! You’ve been VERY helpful!

Peace…

Thanks for the reply. No, the server isn’t behind a proxy. At this point, do you know what files or settings I should clear such that I can effectively “reset” Login Security Solution properly? As I wrote above, I uninstalled the plugin, then re-installed it and when I activated it, it immediately prompted me to reset my password even though I was already logged in to WordPress to uninstall and install the plugin.

So, Login Security Solution must be looking at something to determine my password needs to be reset. If I can get that fixed, I think I would be in good shape. Otherwise, I can’t use Login Security Solution.

Thanks!

Peace…

Thanks for the reply. I started this thread in the support forum for the plugin, so I didn’t attempt to contact you directly but to simply seek support for the plugin and see if this is an actual bug that should be formally reported or not.

The funny thing is, I agree with you that it’s not safe to unlock the .htaccess file but that’s exactly what the message suggests doing. ??

So, I’ll a bug report indicating the message needs to be corrected and the .htaccess file needs to be checked to see if the directives being warned about are actually in the file before stating the caching functions are not enabled.

As for my being unhappy, it’s due to the message simply being erroneous and not something I would have realized until I had actually looked in the .htaccess file in question. Others who don’t realize this message is erroneous could be putting their sites in jeopardy simply because the message suggests changing permissions to an unsafe state.

Peace…

I’ve done that in the past and doing so results in the message not appearing. Then, I upgrade BulletProof Security and the issue arises again.

However, I don’t understand how you can write this isn’t a problem. At the very least, the message being displayed is incorrect since it states the caching functions are not enabled because the .htaccess file couldn’t be updated, yet the directives for the caching functions ARE in the .htaccess file already.

It seems to me that W3 Total Cache assumes the caching functions will be disabled simply because it doesn’t have write access to the .htaccess file and it doesn’t actually check the .htaccess file to see if the cache directives are in it or not.

Right now, I can view my site, look at the HTML source and see that disk caching, either basic or enhanced, is enabled as stated in the HTML comments at the bottom of the HTML and then I can go into WordPress and W3 Total Cache will report that caching function isn’t enabled because it can’t update .htaccess.

How is that, at the very least, NOT a problem?

Thanks!

Peace…

I actually disagree. ?? Other backup applications and some WordPress plugins for backing things up offer built-in restore functions. If my site actually did crash, I could either restore all of it from a backup or I could get WordPress, itself, up and running and restore the database from whatever tool I used to generate the backup. Given how easy it is to install WordPress plugins, I would be able to get WordPress installed, get the backup plugin installed, and then be ready to restore the database through the backup plugin in a fairly short amount of time.

DBC Backup 2 looked like a great backup solution for me, but I wanted to clarify the retore issue before installing it. I’m not saying you NEED to add a restore function, or anything, but was simply ASKING if one existed since the documentation about DBC Backup 2 didn’t mention anything about a restore function (either existing or not existing) at all.

Take care!

Thanks for the info. I was mainly asking if DBC Backup 2 provided a restore facility and it appears it doesn’t.

Thanks!

Happy New Year!

Ok, just to make sure there isn’t any kind of obscure security issue at work here, I’m seeing entries like this in my raw Apache access log file:

[IP.ADDR.IN.CHINA] – – [03/Dec/2012:20:59:58 -0600] “GET /blog/wp-login.php?action=register HTTP/1.1” 200 1161 “https://www.(adult-site).info/wp-login.php?action=register” “Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1”

Is there any way to remotely login or register an account from one WordPress installation to another? Or would this be indicative of some kind of cross site scripting issue?

Thanks!

Happy New Year!

Peace…

My IP was shown on the list of failed logins are reported by the “Simple Login Log” plugin I use. However, ALL of the “failed logins” were from my attempts to login during the 20 min “countdown”. I had logged in to the same WordPress installation about a week ago with no problems then “suddenly”, I’m told I have to wait 20 mins due to too many login attempts. I’m a home user with no one else using my system or my network and I’m not running Windows as my primary platform.

After the 20 mins expired, I was able to login just fine and poke around and see a list of IPs with lockouts, one of which was mine. However, I had NEVER had a login problem from this IP address, so something’s wrong.

With regard to issue number two, I’m thinking it’s how the plugin tries to get the administrator e-mail address for notification. Which address does it use if more than one administrator is defined? Which address does it use if there is not an administrator account with the default account name?

When I was finally able to login, I noticed the plugin recorded at least 10 different IPs with lockouts. NONE of them had a login id listed, most had 1 lockout recorded (as did my IP address), and a few had more than one lockout recorded.

Since uninstalling this, I’ve switched to the “Login Security Solutions” plugin and there I was able to specify an e-mail address to use for notifications. We’ll see how that works out.

If the plugin author gets some of the outstanding issues with this plugin fixed, I would give it another try. Speaking of the plugin author, they seem to be “MIA”. ??

Thanks!

Ok, I can deal with that. ??

I looked at some of the URLs appearing in the AWStats report and they are all in the US but not on the same server as my site.

Thanks!

Peace…

Great question! I’ll see what I can find out about the URLs I’m seeing in my log. If the referenced sites are on the same server as my site, I’ll contact Hostgator support.

If they are not, what could that mean?

Thanks!

Peace…

Thanks. I do keep WordPress up to date, along with the plugins I have installed, and I have a very strong password in place. I was thinking maybe the refering page was being spoofed/forged by some bot to hide its tracks in the server logs but I wanted to make sure it wasn’t a case of them using a WordPress login.php script on some other site to try to hack into my blog.

Thanks!

Peace…

marking topic as solved.

Thanks for the info. That worked well!

Peace…

Fortunately, in the past 7 months, I haven’t experienced the lags or stalls I described above. Nothing really changed on the server side either, so I don’t know what the cause of the lag was. I’m running WordPress 3.3.1 now and it seems to be running just fine.

@wunderdojo, if you read the previous posts in this thread, I and others were experiecing these lags with WordPress 3.1.x and 3.2.x. The site I was having problems with is on a shared server and Hostgator support didn’t find anything unusual going on with the server, even while I had a support rep on the phone WHILE a stall was happening.

I can definitely understand how frustrating this can be, especially since no one knows why these stalls happen.

Here is my current WordPress configuration:

WordPress: 3.3.1

All in One SEO pack plugin: 1.6.13.8 (active)
BAAP Mobile Version plugin: 2.0 (active)
Contact Form 7 plugin: 3.1.1 (active)
Cron GUI plugin: 1.02 (active)
Lightbox Plus plugin: 2.4.6 (inactive)
Really Simple CAPTCHA plugin: 1.4 (active)
W3 Total Cache plugin: 0.9.2.4 (active)
WordPress Importer plugin: 0.5.2 (inactive)
WP-Cufón plugin: 1.6.10 (active)

Peace…

That’s not exorbitantly high but a load average of 1 on a CPU is relatively high vs a load average of 0.1. On my home Linux system, which I’m using right now, my load average is 0.4. That’s on a single core box. The site I’m having the WordPress issues with is on one of Hostgator’s shared servers, also with 16 cores, is reporting a load average of 8.76 (16 cpus) in cPanel. That’s about 0.5 per CPU (core). So a load average of 1 isn’t “bad”, just not necessarily optimal. Maybe your sites are simply busier than the shared box my site is on or you have more stuff running.

In any event, if Hostgator support is able to identify an issue we haven’t covered in this thread, let us know! ??

Peace…