That works fine and if I look in phpinfo() I can in fact see that in the current environment that it is the path.
Signed on as Admin, I set the permission for the sesshold directory to chmod 750 and that has taken fine. I can view that in my ftp client.
But no session variables are being stored in that directory. If I look in it while there is an active session, it is empty. And if I move from the first page of the site anywhere else in the site, I lose the session vars.
Obviously I am missing something here and have exhausted every thing I can think of to look at. I assume it is something stupid that I am overlooking but I am at the end. Any ideas would be greatly appreciated.
Regarding storing it above the web root, I got that recommendation from someone else on this forum. And also the chmod 750 for access writes. Is it better placed somewhere else? The structure of this is I have a sister web site that was the first site up and it’s settings are actually in php.ini and it is structured the same way and works fine. And by the way, I tried modifying php.ini to replace the working site with this one and it still didn’t work.
I think you are right, I suspect this is an ownership issue and a rights to write to that directory issue. So who actually owns it and where is that set? This is a vhosts environment where each site breaks off right under the /var/www/vhosts/ directory. And like I said, one of them works just fine and now that I have added the others, they don’t work properly.
Right now, I’m dead in the water. without session variables I can’t get from one page to another.
Regarding ownership, in an effort to actually understand more about what is going on, when php is running and the session is created, who does own it?
The more I look into this the more I think this is an Apache issue. If someone thinks not, I would appreciate a heads up but other than that I will move it to the Apache board.
PHP sessions are handled by PHP, Apache got nothing to do with it.
I too think that the ownership of the directory is incorrect. As quick test you could chmod it to 777 and see if that works. If it does, it is indeed an ownership problem, if it doesn’t work you at least know it has to be something else.
Once you’ve tested make sure to put it back to some other value, as 777 is a major security leak (having it on there for just a couple of minutes shouldn’t hurt though).
Why do you want separate session directories for separate projects btw? PHP normally works fine with just one session directory for both projects (or even 10, 20, 1000, etc).
I will try the 777 now but regarding multiple directories somewhere along the line I understood it was a security risk with hijacking sessions if they were mixed. If not, I have no reason to do it that way. So where should they go and what should the security settings be on that directory?
Again, my current structure is /var/www/vhosts/myapp1, 2, 3, 4/httpdocs/
Wow, I set it to 777 and it works like a champ. I set it back to 750 and it breaks it. So that is definitely where I need to focus but I still don’t really have a clue as to why 750 wouldn’t work?
So if I set the session.save_path in php.ini to somewhere above vhosts as the default directory with chmod 750 rights and let all the sites use it, will that resolve the problem and is it okay to do it that way?
I can’t help but think I am doing something wrong in the virtual host arena. These 4 sites all have their own IP addresses, so this is not really a virtual hosting environment, right?
When I set virtual host settings in httpd.conf, should I be using names or IP addresses or does it matter? And I am setting the save_path in the htaccess file, so when PHP goes to use that directory, who actually owns it and how does PHP get the permission to write to it? i.e. who owns PHP?
They are still Virtual Hosts, even though one could indeed argue they are not that virtual in this case
You’d still need to set them up with just <VirtualHost>, although you don’t have to use NameVirtualHost.
Who owns PHP depends. If PHP is used as a module in Apache (which is most common), the user who runs apache is the user running PHP (on most setups this user is either ‘apache’ or ‘www-data’). If PHP is used via fastCGI it’s most of the time (this is configurable) owned by the user who owns the PHP script.
Right now it sounds like if you could find out who’s running the process (you could use this script) for that, and chown the directory to that user.
And indeed having a seperate dir for each project is indeed better in terms of security, but having it all in one (usually just /tmp) is not as bad as some would make it out to be. Still, separate is still better :tup:
Here’s where I am now. I changed php.ini to use /var/lib/php/session/ which is an existing directory and the default in php.ini and has rwxrwx— rights and now myapp2 works great but myapp1 no longer works. Now I’m really lost. Neither site has settings in htaccess so everything else is now shared. Since it is above the vhosts directory, I would think they would both have the same access authority.
I tried the whoami.php script and it returns nothing. It’s just blank.
Here is an interesting tidbit from my hosting service.
The only possible item that I can directly think of is we are aware that the way Plesk loads PhP it makes Apache the only writable owner. Though this is not incorrect it can cause conflicts with some applications you load.
For a solution they recommend using FastCGI. Does that sound like it might be the problem I am having?
I am going to back up the server first and then try this I think. It seems like this is a recognized issue although it is not mentioned specifically as a session problem and they understandably do not provide application level support.
No that doesn’t sound like the problem you’re having. Like you say if app1 can write to the directory then so should app2, since PHP is running as a module (from what I figure from that mail you posted there) and is indeed run as the Apache user.
Either both can write or neither can write. So the problem probably lies somewhere else (oh, the joy of debugging :)). Are the cookie domains set correctly? And when you use Firebug or Live HTTP headers in firefox, do you see headers setting a cookie when you access app1?
Also, if you can list the contents of the directory where the sessions are stored, could you see if a file is created there when you access the app? (of course you need to restart your browser before you test this otherwise you’ll just the existing session and no new file will be created)
In FF I went into each app and deleted the cookies, closed the browser, reopened it and connected and the cookies are set to the correct domain and path “/”. Now I will test the other. Need to close to do that.
Yes, positive. App1 has been running for months without problems and only stopped working when I set the save_path to /var/lb/php/sessions/ a little bit ago. That was the same time app2 started working.
