And way to include in PHP across public_htmls?
November 3, 2011 11:55 PM   Subscribe

Is there any way to include_once() in php across different cpanels on a VPS?

Howdy,

I'm guessing the answer is no on this, but I figure I better double check just in case it'll work.

So I have a series of seven t-shirt websites all with their own domains but on a single VPS. They are currently all served as addon domains to a single cpanel and they are built in PHP from a single engine that relies heavily on shared.inc files. The checkout for each shop is through the secure servers at Spreadshirt.com placed in an iframe on my shop. My understanding is that while the checkout in the iframe is perfectly secure, browsers wont show the little lock icon unless both the iframe and the wrapping page are both ssl. So here I am looking to add SSL to each of the domains so I can get the little browser lock icon to show up.

To do this I'll need to split all of those domains onto their own cpanels in order for them to each have their own IP for the sake of assigning them the SSL. the problem is that by spawning their own cpanels I can't seem to access the shared .inc files by using includes in PHP.

For example currently I have a domain hosted on my server who's base path is: /home/wearscience/public_html/amorphia/

From this home directory I have no problem including the following file: include_once("/home/wearscience/public_html/shared/shared_functions.inc");

However, when I take that site and give it its own cpanel then its new base path becomes: /home/amorphia/public_html/ and any attempt to include a file located in a different /public_html/ throws permission errors.

Is there any way around this permission problem, or is that just how things work for necessary security reasons and that 'aint gonna change and time soon.
posted by Jezztek to Computers & Internet (7 answers total)
 
You could just change the permissions of the shared/ directory to 711, which means any users on that VPS can read the files.

You might find it easier to create a dedicated user/directory below /home/ for you shared files.
posted by Foci for Analysis at 1:13 AM on November 4, 2011


Is your php running in safe mode? It could be an open_basedir issue which would mean no matter what permissions you had on the files or folders, you wouldn't be able to access or include them.
posted by missmagenta at 2:09 AM on November 4, 2011


This is shared hosting or do you control the entire server? Agree with missmagenta that it sounds like it could be an open_basedir restriction. In a shared environment you likely won't be able to get around this and you wouldn't want to anyway for security reasons.

If shared hosting, have you tried symlinks? (Assuming shell access,) ln -s /home/wearscience/public_html/shared /home/amorphia/public_html/shared for each of the 7 sites. (Apache will need to be configured with the FollowSymLinks directive turned on.)

If you own the server, on the other hand, there's all sorts of ways to fix the permissions and/or include path. Knowing the exact error messages would help determine which direction to go in.
posted by Dano St at 5:31 AM on November 4, 2011


To do this I'll need to split all of those domains onto their own cpanels in order for them to each have their own IP for the sake of assigning them the SSL.

This isn't necessarily true, by the way. See if your SSL provider offers "Unified Communications" or "Multi-Domain" certificates.
posted by Dano St at 5:36 AM on November 4, 2011


If you're talking about cpanels as in cPanel, it's probably because you're running under the suPHP handler. See what handlers you have installed and which one you're using by running /scripts/rebuild_phpconf --current on the command line, or "configure PHP and suEXEC" from WHM. The other handlers are DSO, fcgi, and cgi. What cPanel calls DSO is also known as mod_php by the rest of the world.

suPHP is more secure for running a shared host, but slower. Users own their own files, and Apache in effect 'becomes' each user in order to serve that user's files.

To answer your question literally, you can use rebuild_phpconf to switch to DSO, which will permit you to set file permissions that would be unsafe on a shared host, but are fine on a one-man VPS, such as permitting users to read and execute each other's files.

If rebuild_phpconf doesn't show DSO as an option, you can use EasyApache (command line: /scripts/easyapache) to recompile Apache with DSO support.

Docs: PHP handlers, rebuild_phpconf

If I was you, I would think like this: PHP files are just text, they're not that big. You can afford to give each site its own copy of the files, but I sense that managing this and the hassle of keeping them in sync is the real issue stopping you from doing so. You my friend need git. Make a branch for the common code, and then make a branch for each site with the core as its parent branch. Deployment is a matter of `git clone myrepo`to grab a copy of the full repository, and then `git checkout branchname`, where the branch name is something that helps you tell the sites apart, like the domain name. If you update the core code, you can run `git rebase` or `git pull` to bring in the changes to each site. This is my favorite conceptual intro to git-don't let the "for computer scientists" title put you off. Alternative style of intro: how to use git to version your writing.
posted by evariste at 6:45 AM on November 4, 2011


Dano St says-
> See if your SSL provider offers "Unified Communications" or "Multi-Domain" certificates.

It's tricky, but possible, to get this working in a cPanel environment. You just have to work around WHM's assumptions.
posted by evariste at 6:52 AM on November 4, 2011


Response by poster: Thanks much all, a lot of great suggestions here. I'll start crunching through them to try and figure out which is the best for my situation, I'm sure between these options I'll get something to work!
posted by Jezztek at 10:30 AM on November 4, 2011


« Older How does power spikes work?   |   How should i fix an abrasive platform in my turtle... Newer »
This thread is closed to new comments.