How does CMSMS determine session save path is writeable?

[JohnnyB]

Hi, if this isn't a good board for this topic, please move it.

More often, I'm installing CMSMS on servers running PHP from CGI. It seems to be the popular trend - hardly any servers are set up running PHP as an Apache module lately.

I find that I have to upload a custom php.ini file to assign the session save path when I never had to do that before. 

What I'm wondering is how does CMSMS determine if the default session save path is writeable?  Does it look at the path reported by phpinfo and then check for 0777 permissions?  PHP run out of CGI will only have a max of 0755 on directories.

It just seems odd that on set ups using PHP as an Apache module do not have session problems, but those running out of CGI do have session problems.  The modules that consistently have problems are the Module Manager and TinyMCE.  I have to upload php.ini files into any of those directories with PHP files.

Thanks!

[Wiedmann]

how does CMSMS determine if the default session save path is writeable?

Code: Select all

is_writable(session_save_path())

(Of course, this test can fail, because session.save_path must not be set to have working sessions. In this case you can still ignore the message from the cmsms installer)

but those running out of CGI do have session problems.

You have also session problems without CMSMS (e.g. a session example from the php manual)?

[Ted]

More often, I'm installing CMSMS on servers running PHP from CGI. It seems to be the popular trend - hardly any servers are set up running PHP as an Apache module lately.

Slightly off-topic, but do you have any idea why that is?  I've tried setting it up as a cgi in the past because of the faster apache threading model, and it caused nothing but issues.  Do you think it's a performance thing?  Or just something to allow php4 and php5 to coexist?

[JohnnyB]

Host companies claim that it provides better security on their shared machines because they are using phpSuExec.

...PHPSuExec ... will enhance the security of scripts being executed on our servers (such as a PHP script or application). PHPSuExec works by modifying the execution user to match your user, instead of everyone sharing the common “apache” user, for example. Basically, it will allow for tighter control over executed scripts to prevent others from “snooping”. This change will also help us track resource utilization to enhance the stability of our shared server environment.

Just to clarify.. I don't see 'login' session problems.  They are only problems related to the session save path that some modules need to access.

[Wiedmann]

Slightly off-topic, but do you have any idea why that is?

Well, this should be normal for a shared hosting company... As "mww" said, only with a CGI setup you can controll the privileges from the PHP process.

And on IIS, fast-cgi is the prefferd installation methode.

Or just something to allow php4 and php5 to coexist?

And that's the main reason for me on my dev boxes... to have several PHP versions (including snap) coexistent (and using diffent PHP verisons, but just using another hostname (vhost)).

They are only problems related to the session save path that some modules need to access.

That's curious, because a module must not access the session save path directly. They just use the session functions. Thus, if sessions are working (login), they should also working in modules.

[JohnnyB]

They are only problems related to the session save path that some modules need to access.

That's curious, because a module must not access the session save path directly. They just use the session functions. Thus, if sessions are working (login), they should also working in modules.

That's what I had thought... and didn't understand why I had to add a session directive.  Although, looking back at a few sites, I later added the following:
memory_limit = 20M
setting session.auto_start = 1

So, I might have been barking up the wrong tree.  It may be have been a case of memory limit when TinyMCE and Module Manager were not responding correctly.

The next site I set up on a PHP/CGI server, I'll actually do some quick testing to see what directives are really needed in each case: 1. the install wizard, 2. Module manager and TinyMCE, and 3. what ever other anomalies I notice. LOL.

[Wiedmann]

setting session.auto_start = 1

I don't think that's a good idea... CMSMS and most modules want use their own session name. And they can't set this name, is a session is allready started.

memory_limit = 20M

Maybe that's not enough (PHP default is 128). Or maybe your ISP limits the process memory.

and didn't understand why I had to add a session directive.

That's really curious, if sessions are working for login, but not for the rest of the admin page.

The next site I set up on a PHP/CGI server,

Well, personally I have no problems with cgi (and use most times this setup).
That is not your own (root) server? Maybe you can see something special, if you put a phpinfo() in the cmsms dir.

[JohnnyB]

I don't think that's a good idea... CMSMS and most modules want use their own session name. And they can't set this name, is a session is allready started.

goo dto know thanks!  I read a post once and that was a fix for TinyMCE. Can't remember where I read it - might have been a TMCE or Joomla board.

I usually get by on 20 to 32M memory limit.  But it is shared hosting, and I think they have a max that I can't overide. Although, depending on the client, it could be one of a handful of shared host companies and each one is slightly different.

I upload a phpinfo() file with every install - couldn't live without it 

[Ted]

Well, technically logins will work without sessions.  There is a cookie backup for when a session expires.  In the case of a bad session setup, then it's just going to go back and use the cookie on every page request.

[JohnnyB]

Thanks Ted.  That makes perfect sense.

That's curious, because a module must not access the session save path directly. They just use the session functions. Thus, if sessions are working (login), they should also working in modules.

I think the reason that a custom php.ini file has to be added to every directory is because each hosts approaches it differently.  Some require that it is in every directory  of which you want to override settings and other hosts only require one in the root.

Tiny MCE usually needs it in the connections directory of the simple browser as well:
/modules/TinyMCE/tinymce/jscripts/tiny_mce/plugins/simplebrowser/connectors/php/

I still plan to test if it is session save path or memory limit that making TinyMCE functional. 

[Wiedmann]

I think the reason that a custom php.ini file has to be added to every directory is because each hosts approaches it differently.

Hmm, if you host your sites at a hosting provider (or have a managed server), and sessions are not working without creating an own php.ini, it's better the change the hosting provider. (that's really a basic functionality)

If it's your own (root) server, check the configuration.

I still plan to test if it is session save path or memory limit that making TinyMCE functional. 

Session functionality you can still test with a short test page outside cmsms. If this works, you have an other problem.

[JohnnyB]

Hmm, if you host your sites at a hosting provider (or have a managed server), and sessions are not working without creating an own php.ini, it's better the change the hosting provider. (that's really a basic functionality)

I work with a lot of different hosts.  What happens is when it is a CGI/PHP setup, the session path is there per phpinfo(), but CMSMS doesn't see the path as writeable. It will see the path, but doesn't see it as writeable.

So, I add a custom php.ini with a new path (above the root).  Being PHP/CGI, the directory is wrteable (0755) by default.

But, yes, I should find out why the shared hosts session save path is not writeable. It is odd that default path/directory is not seen as writeable, but when I create my own custom session directory, it is seen as writeable.  So, the original question, how does CMSMS see a directory as writeable, is solved. 

I'll do some more homeworks - thanks!

[Wiedmann]

the session path is there per phpinfo(), but CMSMS doesn't see the path as writeable.

There is really a session.save_path set in phpinfo() and cmsms writes "not writable" during installation?
- what is the value of session.save_path?
- you are also have safe_mode = on?
(we assume that sessions are working with a test script)

What happens is when it is a CGI/PHP setup,

Regarding sessions there is no real difference for a PHP coder, if you are using PHP mod_php or cgi.

[JohnnyB]

I'm still seeing different behavior when using PHP5 run via CGI and I see that my original post was a little bit confusing.  I don't mean to say that there is a problem with sessions, just the session.save_path.  Sessions work.

There is really a session.save_path set in phpinfo() and cmsms writes "not writable" during installation?

CMSMS doesn't recognize the default save path.  For example, before modifying php, the default save path is above the root (set by web host) /tmp and it does not recognize it.  When uploading a php.ini to the root (or cms subdirectory) and assigning session.save_path = /home/username/public_html/tmp/cache , CMSMS sees that as writeable.

- what is the value of session.save_path?

- varies per client and server and host, but looks like the above paths

- you are also have safe_mode = on?

- Almost always set to off and if not, I set it to off

(we assume that sessions are working with a test script)

- not sure how to set up a test script for sessions. But, sessions work after setting the session.save_path in a custom php.ini file.

But... Here's another related issue that seems to be specific CMSMS.  Any file, text, img, html, inside of the directory set as the session.save_path can not be found by the browser.  And this only occurs in the CMSMS environment running PHP/CGI.

I've tested servers with and without CMSMS and with and without PHP/CGI and this behavior only occurs when CMSMS is installed on a server with PHP/CGI.  It does not occur when CMSMS is installed on a server with PHP as Apache module.  And it doesn't occur on non CMSMS sites with PHP/CGI.

The significance of this is that the Captcha module can not read the images inside of tmp/cache. The images are created; they are just not visible.  The image exist yet you can not browse directly to it.  If a txt file is uploaded to the directory, it can not be browsed.  I've ruled out it being an image path problem.

Again, this only happens with CMSMS on PHP/CGI.  Static sites and sites using other CMS's with PHP/CGI have no problem displaying the contents of the session.save_path directory.

I'm at a loss b/c I'm really not sure if it is a session.save_path issue, a PHP/CGI issue, a CMSMS issue, or a server issue. I don't think it is a server issue b/c I've tested on different platforms running CMSMS with PHP/CGI.  Although, I just remembered an installation that has PHP/CGI running FastCGI and the captcha module works... ?

So, what can I look for to keep trouble shooting?  Has anyone else experienced anything similar with PHP/CGI and CMSMS?  Could it be the PHP version number?  5.2.4 vs 5.2.5 vs 5.2.6

[JohnnyB]

Hi,

Just following up.  The following directories need to have the session.save_path defined in a custom php.ini file.  By the way, is it odd that other CMS do not have the same problem with session.save_path and seeing it as writable?  I can install Joomla, WordPress, and CMSMS on the same server, same account, and CMSMS is the only that requires a php.ini file with the session.save_path.

Here are the directories:

CMSMS root directory
/modules/TinyMCE/
/modules/TinyMCE/tinymce/jscripts/tiny_mce/plugins/simplebrowser/connectors/php/
/modules/FileManager/
/modules/FileManager/postlet/
/lib/
/lib/filemanager/
/lib/filemanager/ImageManager/
/lib/filemanager/ImageManager/Classes/
/admin/

And it needs to be inside of the /install/ directory if you want to see the 'green' light during installation.

And for some reason, no matter what I do, I can not get Captcha module to work on these server settings.  I've tried everything.  The directories that need to be writable are writable.  I can't even browse to the image set by captcha.  It may not be related to this, so I'll open another post.

Now, I have to admit, I'm just an HTML/CSS guy with limited knowledge of PHP.  And, in some cases, the php.ini files might also include allow_url_include = On.

I'm just trying to post what I've had to do while troubleshooting why a module doesn't work after install or just why install doesn't see the session path as writable.

Any help would be great!  I know it is a very vague request, so if someone wants to see what happens, I can provide access to one of these servers for testing.