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

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

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

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

Contents

  where to put a php library shared between (virtual) sites. The Natural Philosopher <tnp@invalid.invalid> - 2013-05-24 15:20 +0100
    Re: where to put a php library shared between (virtual) sites. "J.O. Aho" <user@example.net> - 2013-05-24 20:11 +0200
      Re: where to put a php library shared between (virtual) sites. "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-24 17:49 -0500
        Re: where to put a php library shared between (virtual) sites. Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-24 19:19 -0400
        Re: where to put a php library shared between (virtual) sites. The Natural Philosopher <tnp@invalid.invalid> - 2013-05-25 08:31 +0100
          Re: where to put a php library shared between (virtual) sites. "J.O. Aho" <user@example.net> - 2013-05-25 15:05 +0200
            Re: where to put a php library shared between (virtual) sites. The Natural Philosopher <tnp@invalid.invalid> - 2013-05-25 16:29 +0100
              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

#9587 — where to put a php library shared between (virtual) sites.

Situation: LAMP installation,. Multiple sites some of which use 
identical scripts, and many of which could (with a bit of parameter 
tweaking) use identical included scripts.
                 Multiple sites under /var/www.whatever.whatever and so on

Desired: a place that can be used to PUT these scripts.
Obviously: anywhere on the server is POSSIBLE.

But where is the most normal place, that e.g. anyone might EXPECT to 
find them?



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [next] | [standalone]

#9607

On 24/05/13 16:20, The Natural Philosopher wrote:

> Situation: LAMP installation,. Multiple sites some of which use
> identical scripts, and many of which could (with a bit of parameter
> tweaking) use identical included scripts.
>                  Multiple sites under /var/www.whatever.whatever and so on
>
> Desired: a place that can be used to PUT these scripts.
> Obviously: anywhere on the server is POSSIBLE.
>
> 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 
way could be to add a README.txt in /var/www.whatever.whatever and 
hopefully you have a htdoc directory under there in which the site is 
located.

If you have many sites that shares the same libraries, I would go with
include_path in php.ini, there are some default paths already added 
which are commonly used by php extensions provided through the package 
management system. The paths may be different depending on which 
distribution you use.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#9621

"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.

[toc] | [prev] | [next] | [standalone]

#9628

On 5/24/2013 6:49 PM, 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.
>

Once again, wrong, Sanders.  But then once again you don't understand 
the question.

J.O. is correct.  And you are incorrect (hint: how do you include php 
source from another server without making the source available to the 
whole world?).

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

[toc] | [prev] | [next] | [standalone]

#9639

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?


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9645

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.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#9649

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 :-)


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#12259

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] | [prev] | [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