Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12259 > unrolled thread

Re: where to put a php library shared between (virtual) sites.

Back to article view | Back to comp.lang.php

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: where to put a php library shared between (virtual) sites. Moon Elf <moonelf@moonelfsystem.net> - 2013-12-15 20:06 +0000
    Re: where to put a php library shared between (virtual) sites. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-15 15:12 -0500

#12259 — Re: where to put a php library shared between (virtual) sites.

On 2013-05-25, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 25/05/13 14:05, J.O. Aho wrote:
>> On 25/05/13 09:31, The Natural Philosopher wrote:
>>> On 24/05/13 23:49, Sanders Kaufman wrote:
>>>> "J.O. Aho"  wrote in message news:b09oq8FmkvvU1@mid.individual.net...
>>>>> On 24/05/13 16:20, The Natural Philosopher wrote:
>>>>
>>>>>> But where is the most normal place, that e.g. anyone might EXPECT to
>>>>>> find them?
>>>>>
>>>>> There is no "most normal" place. You should document the location, one
>>>>
>>>> Actually, a named server is the industry standard - just like with
>>>> database servers, static content servers, web servers and app servers.
>>>> (e.g. db.kaufman.net, static.kaufman.net, www.kaufman.net,
>>>> apps.kaufman.net)
>>>> I think it's even codified in the latest ISO9xxx standard.
>>>>
>>> Thanks for that. A most interesting idea. But wouldn't that make them
>>> PUBLICLY accessible to anyone on the net?
>>>
>>>
>> Sure, Sanders example here would require you to have a copy in each 
>> virtual host, with other words what you already done.
>>
>> Using the include_path option in php.ini, then if it's a global 
>> php.ini the modules would be accessible by all vhosts on that server, 
>> if you sites has individual php.ini (as you can have in a suExec 
>> setup), then those modules would only be accessible by those vhosts 
>> with the right php.ini.
>>
> I suppose another example would be to hard link the files to 'copies' in 
> each vhosts directory.
>
> And make em readonly :-)
>
>

LAMP installation : use /usr/local as the php5.5.6 build will use 
--with-config-file-path=/path/to/php.ini or /usr/local/lib/php.ini

Then if you're not an admin run your server above port 1024 e.g. 8080 and
load from a shared object file somewhere, then load php files in a user's 
public_html directory. This means you compile your own apache and php
installation.

ME
-- 
Member of the DR rogue circle. 
Search and you will find. 

[toc] | [next] | [standalone]

#12260

On 12/15/2013 3:06 PM, Moon Elf wrote:
> On 2013-05-25, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 25/05/13 14:05, J.O. Aho wrote:
>>> On 25/05/13 09:31, The Natural Philosopher wrote:
>>>> On 24/05/13 23:49, Sanders Kaufman wrote:
>>>>> "J.O. Aho"  wrote in message news:b09oq8FmkvvU1@mid.individual.net...
>>>>>> On 24/05/13 16:20, The Natural Philosopher wrote:
>>>>>
>>>>>>> But where is the most normal place, that e.g. anyone might EXPECT to
>>>>>>> find them?
>>>>>>
>>>>>> There is no "most normal" place. You should document the location, one
>>>>>
>>>>> Actually, a named server is the industry standard - just like with
>>>>> database servers, static content servers, web servers and app servers.
>>>>> (e.g. db.kaufman.net, static.kaufman.net, www.kaufman.net,
>>>>> apps.kaufman.net)
>>>>> I think it's even codified in the latest ISO9xxx standard.
>>>>>
>>>> Thanks for that. A most interesting idea. But wouldn't that make them
>>>> PUBLICLY accessible to anyone on the net?
>>>>
>>>>
>>> Sure, Sanders example here would require you to have a copy in each
>>> virtual host, with other words what you already done.
>>>
>>> Using the include_path option in php.ini, then if it's a global
>>> php.ini the modules would be accessible by all vhosts on that server,
>>> if you sites has individual php.ini (as you can have in a suExec
>>> setup), then those modules would only be accessible by those vhosts
>>> with the right php.ini.
>>>
>> I suppose another example would be to hard link the files to 'copies' in
>> each vhosts directory.
>>
>> And make em readonly :-)
>>
>>
>
> LAMP installation : use /usr/local as the php5.5.6 build will use
> --with-config-file-path=/path/to/php.ini or /usr/local/lib/php.ini
>
> Then if you're not an admin run your server above port 1024 e.g. 8080 and
> load from a shared object file somewhere, then load php files in a user's
> public_html directory. This means you compile your own apache and php
> installation.
>
> ME
>

Where to put include files has nothing to do with the port being used. 
And there is no need to compile either Apache or PHP to do this.

It's simply a matter of putting the files in a directory outside of any 
one website, but accessible to all.  This is often in the /var/lib 
hierarchy, but could be other places, also.

And by making the files owned by a different user but with read but not 
write access to a group the web server user (i.e. www-data) is in, 
read-only access is assured.

However, none of this has anything to do with PHP, anyway, which TNP 
doesn't understand.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web