computaphile Posted November 4, 2010 Posted November 4, 2010 After installing oscommerce on a different server I was confronted with the situation where 'open_basedir restriction in effect.' This caused the error log to collect.... [Wed Oct 27 10:09:00 2010] [error] [client 66.249.65.243] PHP Warning: file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(/var/www/vhosts/XXXXX.co.uk/httpdocs/install) is not within the allowed path(s): (/var/www/vhosts/XXXXX.co.uk/httpdocs:/tmp) in /home/vhosts/XXXXX.co.uk/httpdocs/includes/header.php on line 19 etc., etc.... but worse the backups failed and other operations on files, images etc failed. So, after much browsing the web for a solution on oscommerce sites and php sites I gradually collected enough snippets of information to gracefully resolve the situation. I say gracefully, because it appeared that I needed to restart the server from time to time and the consequence of one restart failed to restart the web services (no one could see the store), leaving me with the need to rapidly find out what I had done incorrectly. Because I had such difficulty resolving this, and because it seemed a common issue, I though it would be useful on this forum to collect all actions together.. To sum up in beginners terms and describe the resolution of this problem see below. Background: (or what you need to appreciate) I am running oscommerce on a dedicated linux server using centos-5 with a plesk conrol panel for managing the system, as the server hosts a number of different domains. PHP initialisation and things: PHP uses a php.ini script generally in /etc/php.ini Depending on the system the php system configuration is further adjusted by additional scripts such as httpd.include and vhost.conf This allows the php configuration to vary depending on the hosted domain. So domain1 can remain very secure while domain2 can have less safe options set for php scripts. php.ini resides in /etc directory (don’t change this as it would effect all domains, which is probably not what is ideal). Plesk things: My plesk server hosts domains under /var/www/vhosts So in that directory resides domain1.co.uk domain2.co.uk etc Command 'cd domain1.co.uk' moves to that folder and we see a number of directories (folders) cgi-bin, httpdocs, conf, and statistics, etc. Directory httpdocs is where the web site files are held (index.php etc). the statistics directory holds the error_log within a logs sub directory. In the conf directory resides httpd.include. This appears to be the configuration file that is called for the domain. It has warnings within it as it is over written whenever changes are main to the domain set up from the plesk control panel. OK: lets start. Within the store admin, via ‘tools’ and ‘server info’ I can see that open_basedir was set to ‘/var/www/vhosts/domain1.co.uk/httpdocs:/tmp’ and from snippets I had determined it needed to be ‘none’. To do this I did the following….. 1. Logon to server via ‘putty’ as root. 2. Change directory; cd /var/www/vhosts 3. Command ls displays the domain names. 4. cd domain1.co.uk 5. cd conf 6. Command ls displays only ‘httpd.include’ (if vhost.conf already exists go to line 14) 7. Run command ‘touch vhost.conf’ 8. this creates an empty vhost.conf file. 9. Type less httpd.include 10. this displays the content of the https.include file, note that no reference is made to vhost.conf 11. Go to Plesk control panel for the domain and select ‘Web Hosting Settings’ 12. Exit via OK button (not cancel, this rewrites httpd.include and adds vhost.conf). 13. Now re-run less http.include command and note the addition of ‘Include /var/www/vhosts/domain1.co.uk/conf/vhost.conf’. Plesk has rebuilt the configuration file and detecting the existence of the vhost.conf file has included it. This means that when the server or the Apache service is restarted the php configuration for domain1.co.uk will now use vhost.conf. 14. The vhost.conf file needs to contain (from browse snippets): <Directory /var/www/vhosts/domain1.co.uk/httpdocs> php_admin_flag engine on php_admin_value open_basedir none </Directory> 15. Use vi (etc) to edit the vhost.conf file and then run the command apachectl –t This will test that the syntax of the apache configuration file are usable. It should respond Syntax OK or provide you with error information. 16. Correct any errors. 17. So to conclude we have created a final php initialisation file called vhost.conf for the appropriate domain and ensured that the Plesk control system has recognised it and includes it. We have checked that the scripts are acceptable. 18. We just need to restart the apache web service to use the vhost.conf file and set up php for this domain. 19. I used the command apachectl –k gracefully This restarts the web service with the new setting without interrupting your site operation. You are advised to wait 10 to 15 minutes after this command for all to settle, but I immediately reopened my store admin, viewed the server info via tools and there was the open_basedir settings set to no value. 20. I then ran a database backup and it worked! This was a ‘Eureka Moment’ for as it had taken quite a while for a newbie linux guy coming from windwows to finally resolve. Hope that helps. P.S. I just have a magic quotes issue to resolve now!
FIMBLE Posted November 5, 2010 Posted November 5, 2010 After installing oscommerce on a different server I was confronted with the situation where 'open_basedir restriction in effect.' This caused the error log to collect.... [Wed Oct 27 10:09:00 2010] [error] [client 66.249.65.243] PHP Warning: file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(/var/www/vhosts/XXXXX.co.uk/httpdocs/install) is not within the allowed path(s): (/var/www/vhosts/XXXXX.co.uk/httpdocs:/tmp) in /home/vhosts/XXXXX.co.uk/httpdocs/includes/header.php on line 19 etc., etc.... but worse the backups failed and other operations on files, images etc failed. So, after much browsing the web for a solution on oscommerce sites and php sites I gradually collected enough snippets of information to gracefully resolve the situation. I say gracefully, because it appeared that I needed to restart the server from time to time and the consequence of one restart failed to restart the web services (no one could see the store), leaving me with the need to rapidly find out what I had done incorrectly. Because I had such difficulty resolving this, and because it seemed a common issue, I though it would be useful on this forum to collect all actions together.. To sum up in beginners terms and describe the resolution of this problem see below. Background: (or what you need to appreciate) I am running oscommerce on a dedicated linux server using centos-5 with a plesk conrol panel for managing the system, as the server hosts a number of different domains. PHP initialisation and things: PHP uses a php.ini script generally in /etc/php.ini Depending on the system the php system configuration is further adjusted by additional scripts such as httpd.include and vhost.conf This allows the php configuration to vary depending on the hosted domain. So domain1 can remain very secure while domain2 can have less safe options set for php scripts. php.ini resides in /etc directory (don’t change this as it would effect all domains, which is probably not what is ideal). Plesk things: My plesk server hosts domains under /var/www/vhosts So in that directory resides domain1.co.uk domain2.co.uk etc Command 'cd domain1.co.uk' moves to that folder and we see a number of directories (folders) cgi-bin, httpdocs, conf, and statistics, etc. Directory httpdocs is where the web site files are held (index.php etc). the statistics directory holds the error_log within a logs sub directory. In the conf directory resides httpd.include. This appears to be the configuration file that is called for the domain. It has warnings within it as it is over written whenever changes are main to the domain set up from the plesk control panel. OK: lets start. Within the store admin, via ‘tools’ and ‘server info’ I can see that open_basedir was set to ‘/var/www/vhosts/domain1.co.uk/httpdocs:/tmp’ and from snippets I had determined it needed to be ‘none’. To do this I did the following….. 1. Logon to server via ‘putty’ as root. 2. Change directory; cd /var/www/vhosts 3. Command ls displays the domain names. 4. cd domain1.co.uk 5. cd conf 6. Command ls displays only ‘httpd.include’ (if vhost.conf already exists go to line 14) 7. Run command ‘touch vhost.conf’ 8. this creates an empty vhost.conf file. 9. Type less httpd.include 10. this displays the content of the https.include file, note that no reference is made to vhost.conf 11. Go to Plesk control panel for the domain and select ‘Web Hosting Settings’ 12. Exit via OK button (not cancel, this rewrites httpd.include and adds vhost.conf). 13. Now re-run less http.include command and note the addition of ‘Include /var/www/vhosts/domain1.co.uk/conf/vhost.conf’. Plesk has rebuilt the configuration file and detecting the existence of the vhost.conf file has included it. This means that when the server or the Apache service is restarted the php configuration for domain1.co.uk will now use vhost.conf. 14. The vhost.conf file needs to contain (from browse snippets): <Directory /var/www/vhosts/domain1.co.uk/httpdocs> php_admin_flag engine on php_admin_value open_basedir none </Directory> 15. Use vi (etc) to edit the vhost.conf file and then run the command apachectl –t This will test that the syntax of the apache configuration file are usable. It should respond Syntax OK or provide you with error information. 16. Correct any errors. 17. So to conclude we have created a final php initialisation file called vhost.conf for the appropriate domain and ensured that the Plesk control system has recognised it and includes it. We have checked that the scripts are acceptable. 18. We just need to restart the apache web service to use the vhost.conf file and set up php for this domain. 19. I used the command apachectl –k gracefully This restarts the web service with the new setting without interrupting your site operation. You are advised to wait 10 to 15 minutes after this command for all to settle, but I immediately reopened my store admin, viewed the server info via tools and there was the open_basedir settings set to no value. 20. I then ran a database backup and it worked! This was a ‘Eureka Moment’ for as it had taken quite a while for a newbie linux guy coming from windwows to finally resolve. Hope that helps. P.S. I just have a magic quotes issue to resolve now! Thats excellent, but why not just change /tmp to tmp? Im sure it would have worked. Nic Sometimes you're the dog and sometimes the lamp post [/url] My Contributions
computaphile Posted November 6, 2010 Author Posted November 6, 2010 Thats excellent, but why not just change /tmp to tmp? Im sure it would have worked. Nic Thanks for the reply, I will try that later and see what happens. 1. The previous server php setup indicated that the open_basedir settings should be 'no value', as were several posted articles, so I had hoped that obtaining the same setting would give me a working result, and it has. 2. No where did I see a suggestion to set open_basedir to just tmp. So although I have aquired a better appriciation of the problem, I'm not that competent to determine your alternative suggestion without some extra pointers. 3. Having been through the grind of resolving the problem for myself, and seeing so many part solutions to the problem, I felt a long explaination of what I had done may well help other newbies to osc/php/linux to resolve this fairly common problem. 4. Having discovered the graceful way of restarting the web service without disrupting my customers store access, (when I looked at who was looking at the store, it rarely displayed none), and how to test the configuration scripts before committing them, this removed all the 'fear' that making a change would disrupt my clients web site access, or cause the apache web service to fail on restart, I felt this more detailed trail would help other inexperienced linux users. Also the suggestion of changing the open_basedir to from /tmp to tmp, makes me wonder did you mean '/vat.www.vhost/domain1.co.uk/httpdocs:/tmp' to '/vat.www.vhost/domain1.co.uk/httpdocs:tmp' or just 'tmp' and if the later, would that mean that the system would use 'tmp' in the current domain or just to the servers '/tmp' directory and would there be any issues with the directory existing or permission issues? Any way, I dont need an answer to this ,I have the magic quotes problem to solve first and while I resolve this I will no doubt learn more about the above alternative. thanks Brian Computaphile
New 
Recommended Posts
Archived
This topic is now archived and is closed to further replies.