I’ve been working with the Hosting Matters folks to get FastCGI up and running on the server I’m on.
The biggest problem (from a spam perspective) that Movable Type has is that it’s all script based, and everyone who hits a script spawns a new instance of it (as I vaguely understand), which, during heavy attacks, means a lot of serious overhead on the server. Since 99% of the anti-spam measures in MT are script-based (fired off after someone invokes the comment or trackback script), that’s a real problem.
MT supposedly works now with FastCGI. Under that setup, a script, once fired off, stays in memory, and is reusable from there. That would seriously reduce the impact of spam attacks. Problem is, I haven’t been able to get even a simple “Hello World” FCGI script to run.
I tried working this back last January and had no luck. Hopefully I can get it running now.
I’m also seriously pondering making the move over to MT4 while I’m off here in Faerie (but not these couple of days I’m in the office). It won’t specifically address the spam issue, but I’d like to be on something approaching the latest-greatest. My biggest question mark at this point is the fork between MT Open Source and MT4 proper.
UPDATE 1: HM reports they’ve gotten one of the Hello World scripts running, huzzah, and I’ve verified it, huzzah. That should mean, once I’m at a computer I can access the error log from (just to monitor) that I can try the general conversion to FCGI with my MT 3.34 installation.
UPDATE 2: And the server is under “attack” again, meaning I can’t do diddlysquat. *sigh*
UPDATE 3: Server is clear again. HM suggests (and is facilitating) the MT4 conversion, so I’ll be doing some testing tonight, with an eye toward converting sooner as opposed to later.
Hi Dave –
When the MT4 update is complete, you may also want to check out my MT-Approval plugin (updated from the old one) – it adds all sorts of anti-spammy goodness that might help you out.
You’ll also need an update to MT-Notifier. 🙂
Looks like a good bundle of features. A lot are on the back-end, which I don’t need as much*, but the comment hiding on the front end is something I definitely could use.
* Aside from a couple of stray hard-core human spammers, TinyTuring — essentially a challenge-response text CAPTCHA — has blocked every single comment spam from getting through for over a year. The stock SpamLookup stuff has also done quite well on the other intruders. The problem has been more with people flooding the TB and Comment scripts, trying to break through — and, specifically, on the system resources taken up fending them off.
Which MT really needs to address… Perl is just a bad language for something that allows outside access (ie. comment-leaving or forum-posting). Sure, it’s powerful/flexible, but so is PHP…
I’m seriously hoping that FastCGI (what I plan to play with tonight after someone stops bugging me about iTunes and iPod stuff) will help this mightily.
Okay, I have FastCGI versions of the scripts. Will they work?
Okay, I have FastCGI versions of the scripts. Will they work?
Okay, I have FastCGI versions of the scripts. Will they work?
will they?
Some sort of a delayed echo in here.
will they?
Hmmm. It does seem to be posting … but with a 500 error at the end, and after an apparent delay (which only fully reloading the comment, vs. the page, actually shows).
Irksome.
I take it back.
Okay, after renaming all the .cgi scripts to .fcgi, and making appropriate changes in the mt-config.cgi, it *appears* that the comment stuff works … but it errors out with a 500 at the end, instead of a clean close.
Which is, of course, NFG.
Mt.fcgi seems to work okay for calling up various internal functions — but trying to post a post ends in a 500 error, too (though the post is posted).
Can I find something about that, mebbe?
Hrm. No joy.
My suspicion is that it is a matter of things rolling over to a non-fcgi’ed add-in. The internal MT scripts seem to function okay, and the comments seem to function okay, too — except that they (and the normal posting function) both terminate in a 500 error, as if during the rebuild.
(LaunchBackgroundTasks is set to 0, btw, per instructions.)
Going to poke and prod a bit more, then roll back to the previous. Alas.
Hrm. No joy.
My suspicion is that it is a matter of things rolling over to a non-fcgi’ed add-in. The internal MT scripts seem to function okay, and the comments seem to function okay, too — except that they (and the normal posting function) both terminate in a 500 error, as if during the rebuild.
(LaunchBackgroundTasks is set to 0, btw, per instructions.)
Going to poke and prod a bit more, then roll back to the previous. Alas.
Hrm. No joy.
My suspicion is that it is a matter of things rolling over to a non-fcgi’ed add-in. The internal MT scripts seem to function okay, and the comments seem to function okay, too — except that they (and the normal posting function) both terminate in a 500 error, as if during the rebuild.
(LaunchBackgroundTasks is set to 0, btw, per instructions.)
Going to poke and prod a bit more, then roll back to the previous. Alas.
Various odd lot error messages in the Error Log:
[Fri Dec 28 01:42:28 2007] [error] [client 75.4.4.21] FastCGI: server “/home/dave/public_html/blog/mt/mt.fcgi” stderr: as needed at lib/MT/Plugin.pm line 465
[Fri Dec 28 01:42:28 2007] [error] [client 75.4.4.21] FastCGI: server “/home/dave/public_html/blog/mt/mt.fcgi” stderr: Maintain your weblog’s widget content using a handy drag and drop interface.
[Fri Dec 28 01:42:28 2007] [error] [client 75.4.4.21] FastCGI: server “/home/dave/public_html/blog/mt/mt.fcgi” stderr: maketext doesn’t know how to say:
[Fri Dec 28 01:42:27 2007] [warn] FastCGI: (dynamic) server “/home/dave/public_html/blog/mt/mt.fcgi” (pid 12043) terminated due to uncaught signal ’15’ (Terminated)
[Fri Dec 28 01:42:27 2007] [warn] FastCGI: (dynamic) server “/home/dave/public_html/blog/mt/mt-comments.fcgi” (pid 12014) terminated due to uncaught signal ’15’ (Terminated)
[Fri Dec 28 01:42:27 2007] [warn] FastCGI: (dynamic) server “/home/dave/public_html/blog/mt/mt.fcgi” (pid 12043) termination signaled
[Fri Dec 28 01:42:27 2007] [warn] FastCGI: (dynamic) server “/home/dave/public_html/blog/mt/mt-comments.fcgi” (pid 12014) termination signaled
[Fri Dec 28 01:42:00 2007] [error] [client 75.4.4.21] FastCGI: incomplete headers (0 bytes) received from server “/home/dave/public_html/blog/mt/mt-comments.fcgi”
[Fri Dec 28 01:42:00 2007] [error] [client 75.4.4.21] FastCGI: comm with (dynamic) server “/home/dave/public_html/blog/mt/mt-comments.fcgi” aborted: (first read) idle timeout (30 sec)
Yeah, that’s all looking pretty much like it’s time to back out the whole fcgi thing.
Plan 2: Get MT4 installed pronto.
I think I’ve restored all the fcgi scripts to cgi. Let’s see if this works.
Evidently. Though … slowly. Dagnabbit.
Well, I was under attack (again) at the time.
So, to summarize:
By renaming all of the .cgi scripts in the MT directory (other than mt-config) to .fcgi (and updating those entries in mt-config.cgi), I got FastCGI working … but while certain things (firing off mt.fcgi, going to various MT screens) worked fine, other things (saving a comment, saving a post) ended with a 500 error, even though the data was actually saved and eventually posted.
Backing things out worked okay.
So either I was missing something subtle in my MT installation, or I might as well go ahead and play with MT4 today.
I keep considering the change, but since I have multiple authors on the blog installation, I am still flummoxed by the pricing structure/changes. It’s a hobby blog, and while I paid for MT 3, I don’t know if I want to pay for MT 4…
From what I can tell, for personal use (including multiple blogs), MT4 is free.
Short of that, waiting for MTOS, which will be free even for commercial use, is also an option.