PHP LsPCI and APC ? ==> PHP LSAPI and APC ?

[Monarobase]

Edit : Sorry about the title, obviously not LSPCI but LSAPI !

Hello,

We're looking into purchasing a LSWS licence for our new server configuration and I've read your documentation about APC and am not sure which is the best configuration for this.

We run cPanel serveurs with CloudLinux 6 + CageFS.

I've already read this :

http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:opcode_cache

But have also read that Litespeed 4.2 added suexec support.

This is what we are lookind for :

1) PHP to be run with the same user as the FTP user (I've read that some hosts dont want this but we do because our customers like being able to run updates and installs without playing with chmods).

2) To have a single APC cache per user shared by multiple children.

3) To be sure that cache is not accessible between different user accounts.

Before looking at litespeed we looked at PHP-FPM but PHP-FPM's pools did not prevent users from accessing each other's cache and it was too complicated to run multiple instances of PHP-FPM (one instances with one pool per user).

Is Litespeed the miraculous solution to my problem ?

Thanks !

 

[NiteWave]

in lsws admin console,
Server->General->Cloud Linux
there are 4 choices:
Disabled
LVE
CageFS
CageFS without suEXEC

"CaseFS" can meet your requirement 1)

however 2) 3)
is not possible in shared host environment which may have thousands of user accounts -- at the time being.

there is a workaround to meet the requirements closely. choose xcache instead of apc, while one copy of opcode cache is shared by all accounts, only admin can see the cache's content.

 

[Monarobase]

By using the PHP_LSAPI_CHILDREN method, only a single APC shared memory slice will be created and shared by all children.

Does this mean that multiple children are allowed but all run from the root user so APC stores can communicate between each other ?

Does XCache have an object cache like APC ? If so would it be secured between users ?

Lots of scripts are compatible with APC, I'm not sure how many can nativly use Xcache object caching

 

[NiteWave]

xcache has opcode cache as well as variable cache, like apc.
xcache is popular and famous enough, no less than apc.

APC stores can communicate between each other ?

how can they communicate with each other (account?), can you give example?

it's like all accounts may store php session in /tmp, but it's regarded safe enough - php script can't make use of it to see other account's data.

 

[Monarobase]

Thanks

Will XCache prevent users from accessing each others Object cache code ?

Also

however 2) 3)
is not possible in shared host environment which may have thousands of user accounts -- at the time being.

Does Litespeed have a list of features that are planned for the next major release ? If not is this a feature that's being concidered ?

And is there some form of ETA for this feature ?

 

[Monarobase]

how can they communicate with each other (account?), can you give example?

Here's an example :
With APC and PHP-FPM, APC is launched at the startup of PHP when it is owned by root so when PHP-FPM forks an instance of PHP this instance accesses a global instance of APC.

If the unix user : UserA runs

apc_store ('foo', 'hello world');

Then unix user: UserB runs :

print apc_fetch('foo');

It will output 'hello world'

If unix user UserB then runs :

apc_store('foo', 'Goodbye world');

UserA expects the value to be Hello world but when he runs :

apc_fetch('foo');

it outputs 'Goodbye World'

 

[Monarobase]

I've just read that xcache caches per process just like APC.

If xcache has no protection to prevent users from accessing each other's cache set with xcache_set() and retrieved with xcache_get() then xcache has exactly the same problem as APC.

As far as I can see the only solution here to use Xcache or APC would be to either run one PHP process per user and fork this process for that user (Fastcgi can do this but fcgid can't from what I've understood LSAPI can't either

 

[NiteWave]

sorry for confusion.

however 2) 3)
is not possible in shared host environment which may have thousands of user accounts -- at the time being.

there is a workaround to meet the requirements closely. choose xcache instead of apc, while one copy of opcode cache is shared by all accounts, only admin can see the cache's content.

should add lsphp suEXEC daemon mode:

lsphp suEXEC daemon mode + xcache will meet the requirement closely.

however, it's close, not exactly as 2) + 3). since

2) To have a single APC cache per user shared by multiple children.

it's per user; while for lsphp + suEXEC daemon, all users share one lsphp parent process. assume there are 1 thousand users, 2) means need 1000 parent php process; while there is only 1 parent lsphp process in lsphp + suEXEC daemon.

If xcache has no protection to prevent users from accessing each other's cache set with xcache_set() and retrieved with xcache_get() then xcache has exactly the same problem as APC.

if this is confirmed, then there's really a problem in lsphp + suEXEC daemon mode regarding variable cache(or object cache).

however, there is no problem for opcode cache since the php scripts under each account has different path, so the opcode cache can't be accessed each other.

 

[Monarobase]

+1 the scripts would be quite simple :
On user 1 :

<?php
xcache_set("mona_test150112", 'This data was set by user 1', 120);
print('mona_test15112 was set by user 1 for 120 seconds');
?>

On user 2

<?php
if (xcache_isset("mona_test150112"))
{
    print xcache_get("mona_test150112");
}
else
{
   print ('mona_test150112 is not set.');
}
?>

I haven't tested them as I don't have xcache yet

 

[NiteWave]

tested on our cPanel box, unfortunately, the issue exists.

add following code to print out current user id:

$gid = `id`;
echo "<pre>gid=".$gid;
echo "</pre>";

restart lsws,
step 1: access http://www.lstest3.com/xcache.php

gid=uid=507(lstest3) gid=503(lstest3) groups=503(lstest3)

mona_test150112 is not set.

step 2: access http://www.lstest.com/xcache.php

gid=uid=504(lstestc) gid=501(lstestc) groups=501(lstestc)

mona_test15112 was set by user 1 for 120 seconds

step 3:access http://www.lstest3.com/xcache.php again:

gid=uid=507(lstest3) gid=503(lstest3) groups=503(lstest3)

This data was set by user 1

so test result: so far don't use variable cache in suExec daemon mode in shared hosting. opcode cache is ok.

it may not be difficult for xcache to add such feature: each user(by check php process's user id) to have its own name space to store variables. or may be it already has similar feature -- configurable, need read its manual first

 

[Monarobase]

Seems to be exactly the same issue with XCache as with APC.

I've seen some patches for Xcache 2 that say they do this but not for Xcache 3 or APC.

Do you know if it's possible to deactivate this function ?

 

[Monarobase]

Xcache 3 version says it has "namespace support" but I haven't found any documentation about this so I don't know if it works with gid's or not

 

[Monarobase]

Looks promissing in the xcache.ini for Xcache 3.0.1 :

; mode:0, const string specified by xcache.var_namespace
; mode:1, $_SERVER[xcache.var_namespace]
; mode:2, uid or gid (specified by xcache.var_namespace)
xcache.var_namespace_mode =    0
xcache.var_namespace =        ""

I presume we would use the following :

; mode:0, const string specified by xcache.var_namespace
; mode:1, $_SERVER[xcache.var_namespace]
; mode:2, uid or gid (specified by xcache.var_namespace)
xcache.var_namespace_mode =    2
xcache.var_namespace =        "gid"

Could you give it a go and see if it fixes the issue ?

 

[NiteWave]

hi, it took me much time to set up the test environment.

initially, same result as before -- but figured out it's because of xcache 2.0.1. it just ignore
xcache.var_namespace_mode = 2
xcache.var_namespace = "gid"

finally build latest php 5.4.11 + xcache 3.0.1, yes, just what we want!
in step 3, the output is

gid=uid=507(lstest3) gid=503(lstest3) groups=503(lstest3)

mona_test150112 is not set.

same as step 1.

this is a good news -- to summary in short:
lsphp5 suExec daemond + xcache 3.0.1, all users on a shared host can use opcode cache and variable cache in memory, and can't access each other's variables.
in php.ini, xcache.var_namespace_mode should set to 2:

; mode:0, const string specified by xcache.var_namespace
; mode:1, $_SERVER[xcache.var_namespace]
; mode:2, uid or gid (specified by xcache.var_namespace)
xcache.var_namespace_mode = 2
xcache.var_namespace = "gid"

 

[Monarobase]

Great, will be installing LiteSpeed + Xcache 3.0.1 soon (probably tomorrow).

Will be my first litespeed install, so I hope all goes well !

 

[Duplika]

Just to confirm, the ideal opcode cache for shared hosting clients with cPanel / CloudLinux / Litespeed is XCache, and they only change needed isxcache.var_namespace_mode = 2?

Since we limit memory usage via CloudLinux, I'd like to provide the best available resource usage to our clients.

 

[NiteWave]

there is lots of update in recent months regarding this topic, please refer
http://www.litespeedtech.com/products/litespeed-sapi/php/guide-to-suexec-setups

for latest status.