FastCGI implementation Issue

tmcleroy · 01-20-2010, 01:23 AM

Hi Laurence,
I am having a bit of an issue getting FastCGI working with a Modx Content Management System that I am implementing. CGI and ISAPI work but FastCGI is throwing errors on pages that have dynamic links.

I would like to run CGI/FastCGI for the security that it offers. After reading your article on the subject of security I took note of this several months ago. Gumblar - How To Avoid Getting Hacked | HostNexus Blog Though I think the security issue dealt more with the Apache side of things.

Secondly, I would like to run FastCGI as I think it will deliver sites much faster and more efficiently, especially for a CMS like Modx. And it will provide less of a load on the server.

These two articles have some excellent points:
FastCGI | FastCGI -
Robust and High Performance PHP with IIS: Using FastCGI | PHP Everywhere

However, I am experiencing an error with FastCGI that I do not get with CGI. I wondered if you might be able to offer any thoughts. I am using the Modx default site code to test so I can have a sense that everything is working properly before implementing my own code. I think their code has been pretty well tested.

Here is the error: It indicates no such file but the file is definitely there.

Quote:

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: require_once(manager/includes/sniff/phpSniff.core.php) [function.require-once]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: D:\inetpub\vhosts\mydomain.com\httpdocs\manager\in cludes\sniff\phpSniff.class.php
Line: 22
Line 22 source: require_once($modx->config['base_path'] . 'manager/includes/sniff/phpSniff.core.php');

Parser timing
MySQL: 0.1320 s (21 Requests)
PHP: 6.7835 s
Total: 6.9155 s

Thank you.

tmcleroy · 01-20-2010, 02:09 AM

Hi Laurence, this has bugged me and so I continued to check into it. I may be answering my own question, but I found some code that FastCGI did not like. Let me do some more checking and get back with you.

**NexDog** · 01-20-2010, 08:39 AM

Bit of a complex issue but one thing to consider is that you really don't need to run PHP in Fast CGI on Windows if your concern is security. On Linux running PHP in the Apache module is not secure but the equivalent on Windows (ISAPI) is just fine. Running in CGI will probably give you a performance boost and generally Fast CGI is faster (funny that) but is also more finnicky. I wouldn't worry about getting it to work in Fast CGI is CGI if working as intended (or even ISAPI). Just one less thing to worry about.

tmcleroy · 01-23-2010, 05:44 PM

Hi Laurence,
This is what I found. From the coder of the Modx CMS: "The problem is the PHP process does not have sufficient permissions to write to the /temp/ directory, which is configured as the PHP session_save_path location."

My content management system, Modx, and I think a number of others too as I see references to Drupal also, use a Session_save that writes to the temp directory. I see from my info.php this is set in session.save_path as C:\WINDOWS\Temp. Yet at HN we do not have permission to write to this directory and therefore I am throwing this error:

Quote:

Warning: session_start() [function.session-start]: open(C:\WINDOWS\Temp\sess_5af283eda9015252ae5c0cae 546d2237, O_RDWR) failed: Permission denied (13) in D:\inetpub\vhosts\my.domain\httpdocs\ModX\manager\ includes\config.inc.php on line 60

In the code, line 60 is the session. session_start();

I am finding that FastCGI and CGI both are throwing the same errors. I have tested on different setups on different domains and from three separate computers. I am not sure that entirely this has been the problem but I think much can be pointed at session_start() attempting to write to C:\Windows\Temp

From php.net:

Quote:

A note on Windows installations with an NTFS file structure:
Make sure you give your Internet user account (usually IUSR_MACHINENAME) "Modify" access to the session.save_path directory. Otherwise session_start() will silently - and oh, so slowly - fail.
("Modify" is a Win2k term, but the concept translates to older IIS installs).

PHP: session_start - Manual

Possible resolutions are to either have permission to write to the C:\windows\temp directory or point to another directory to write temp files to. For now I put a directory in my path and it is working. However, the coders also said for security reasons, and I concur, that it would be best to set up a /Temp/ directory on the same level as httpdocs or outside of the domains root. I tried, however, Plesk does not allow me to set up read write permissions to a directory on that level.

Can we get a temp directory setup there with permissions to point Session.save_path to? Do you have any other thoughts?

By the way, getting this set right is like replacing that 2 barrel with a 4 barrel on the 60's muscle car. I like the performance I am seeing so far. From so so page loads to almost instant.

**NexDog** · 01-23-2010, 09:00 PM

I know on linux we can do this quite easily. As for Windows, I will have to defer to the techs. But you be doable for sure. If windows techs say otherwise let me know and I'll follow up.

tmcleroy · 02-23-2010, 02:08 PM

Hi Laurence, I am getting from the windows techs that they do not have the ability to create a directory outside of the document root. (Ticket WJR-543247) They indicate this is for security reasons and also because Plesk security does not allow creation of folders outside of the document root. I am doing this for security reasons. I am caught between the smart people, coders on one side and windows techs both telling me it is for security reasons. Maybe it is not that big of a deal. I defer to you.

**NexDog** · 02-25-2010, 05:45 AM

Seems that Plesk will just override any permissions on the folder created there anyhow. I don't see that big of a deal having a writable directory under httpdocs. Running a 777 folder is pretty standard. If everyone was really concerned with security programs would be coded in safe_mode and register_globals on. So looks like you'll have to make that writable dir somewhere in httpdocs.

tmcleroy · 03-01-2010, 12:44 AM

Thanks Laurence,

From the one of the coders:

It is a security measure to move your session files elsewhere than the default if you're on shared hosting (usually /tmp or something) because it's possible for someone to log in, get his session ID, then get into that shared /tmp folder and mess with his session, giving himself permissions we would prefer he not have.

And also, "You'll need to have some way of clearing out old sessions (maybe those a day or more without activity?) since they won't be getting deleted and will fill up the filesystem eventually."

Do sessions stay in this folder I created--since it is not a system temp--until I clear them?

tmcleroy · 03-01-2010, 01:36 AM

NexDog, I am curious, what are people with Drupal & Joomla installations here doing with their session_save paths? I know there are probably not many Modx folks here, but the other CMS's still have to do session save somewhere? If they are using C:/Windows/Temp what permissions do they need or are they getting?

tmcleroy · 03-04-2010, 03:07 AM

Still working on it. There are definite issues with running FastCGI at the root at HN. Right now every thing works with CGI but switch to FastCGI and session.save, base path and other things fall apart. There is something about the root that it does not like. Even my ini file is picked up with CGI but not FastCGI, and as noted above I have session.save redirects that I need to run through an ini file.
I am still working on it though because it runs the back end so much faster in FastCGI. And that is with a relatively small database.