Hi all,
I am a complete novice when it comes to Debian (or any other Linux). In fact, I so totally don't know what I'm doing that I'm about 3 minutes from walking away, and going back to an awful shared server.
Here's the problem of the day...
I've installed php5 in a folder
/etc/php.
I've installed a content management suite in \suite within /usr/share (where all of the other shared software lives)
The domain has a root
/var/www/sites/user/domain.com/subdomains/www/html/
Within the /html/ folder, I have index.php, which needs to pull some included files from the suite installed into /usr/share/suite/includes/
When I try the absolute path,
$pathtoroot."suite/includes/filename.inc.php"
I get an 'Unable to access /var/www/sites/user/domain.com/subdomains/www/html/wroof/includes/file.inc.php' error
When I try the real path, /usr/share/suite/includes/filename.inc.php I get
'File(/usr/share/suite/includes/file.inc.php) is not within the allowed path(s):'
When I try the relative path, suiteincludes/file.inc.php, I get
'File(/etc/php/suite/includes/file.inc.php) is not within the allowed path(s):'.
I am relatively certain this is either a Debian path issue, or a php path issue but I am totally clueless as to where I should even start looking for the problem.
Any suggestions?
Thanks
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Path to a PHP script
You could always create a symbolic link.
For this to work, you need "Options FollowSymLinks" in the <Directory> block for that VirtualHost (aka your site defined in /etc/apache(2)/sites-enabled)
That's how I would approach the problem anyways. If you get errors when trying to include the file, make sure the apache user (www-data by default) can read the directory.
Good luck
That will create a "includes" folder under wroof, but inside that includes folder you will see the contents of /usr/share/suite/includes/ln -s /usr/share/suite/includes/ /var/www/sites/user/domain.com/subdomains/www/html/wroof/includes/
For this to work, you need "Options FollowSymLinks" in the <Directory> block for that VirtualHost (aka your site defined in /etc/apache(2)/sites-enabled)
That's how I would approach the problem anyways. If you get errors when trying to include the file, make sure the apache user (www-data by default) can read the directory.
Good luck
Re: Path to a PHP script
I don't do it this way, I treat web based software differently than Debian Operating System software.chestertb wrote:I've installed a content management suite in \suite within /usr/share (where all of the other shared software lives)
The domain has a root
/var/www/sites/user/domain.com/subdomains/www/html/
I grab the .tar.gz or .zip file of a CMS, Blog or Forum software and uncompress it to the /var/www/whatever/ directory. The PHP files and all associated files are kept together under the web root, no symlinks, etc.
Bert Garcia - When all you have is a keyboard
kink,
I hear you, I trust the Debian security update process for my servers.
But a web app is a different animal:
a) Not all web apps have debs, in fact very few do.
b) The available debs are usually older than the current release.
c) Many web apps may require you apply your own mods, thus deviating from the packaged scripts.
d) On the web, you have to be proactive, not reactive. A couple of days waiting for a security update could mean Goatse fun on your domain.
Whatever I run on my domains, I follow the projects - support forums, mailing lists, etc. I'm usually patching a security issue the minute it comes to light, cause when it hits Secunia or any of the other security related sites, the script kiddies are firing off the bots and going down their list of Powered by Sites.
I hear you, I trust the Debian security update process for my servers.
But a web app is a different animal:
a) Not all web apps have debs, in fact very few do.
b) The available debs are usually older than the current release.
c) Many web apps may require you apply your own mods, thus deviating from the packaged scripts.
d) On the web, you have to be proactive, not reactive. A couple of days waiting for a security update could mean Goatse fun on your domain.
Whatever I run on my domains, I follow the projects - support forums, mailing lists, etc. I'm usually patching a security issue the minute it comes to light, cause when it hits Secunia or any of the other security related sites, the script kiddies are firing off the bots and going down their list of Powered by Sites.
Bert Garcia - When all you have is a keyboard