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

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
chestertb
Posts: 3
Joined: 2007-02-09 06:13

Path to a PHP script

#1 Post by chestertb »

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
CTB

User avatar
Optional
Posts: 326
Joined: 2007-02-05 05:02

#2 Post by Optional »

You could always create a symbolic link.
ln -s /usr/share/suite/includes/ /var/www/sites/user/domain.com/subdomains/www/html/wroof/includes/
That will create a "includes" folder under wroof, but inside that includes folder you will see the contents of /usr/share/suite/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

User avatar
hcgtv
Posts: 500
Joined: 2006-11-17 23:03
Location: Charlotte, NC

Re: Path to a PHP script

#3 Post by hcgtv »

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 don't do it this way, I treat web based software differently than Debian Operating System software.

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

User avatar
kink
Debian Developer, Site Admin
Debian Developer, Site Admin
Posts: 248
Joined: 2006-01-02 16:47
Location: Utrecht, The Netherlands
Been thanked: 1 time

#4 Post by kink »

Giving you the problem of having to upgrade each copy separately when there's a security issue. My motto is that if something is packaged I use that package, and only deviate from that if there's a very compelling reason to do so.

User avatar
hcgtv
Posts: 500
Joined: 2006-11-17 23:03
Location: Charlotte, NC

#5 Post by hcgtv »

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.
Bert Garcia - When all you have is a keyboard

Post Reply