Various Post Installation Questions

[Tony]

After a bit of work I managed to get LiteSpeed to run on a semi production server. I noticed several things along the way and hacked up my own solutions to the problems but I'm curious if these issues are normal or not.

Installation dir: /usr/local/lsws
cPanel System


I was unable to use the build matching PHP from the whm plugin until I compiled PHP5 through the compile PHP option in lsws. I copied the configure line from the cPanel build and put it into lsws and it compiled fine while the matching one would not. After I did this I was able to build the matching PHP. I am not sure if that's normal or not.

I also noticed after building the matching php the ini directory was now the cPanel one of /usr/local/lib/php.ini rather the lsws one.

The CLI's were not changed upon this build matching configuration. So /usr/bin/php could not use the newly built PDO modules as it threw various errors. I made a symbolic link to /usr/local/lsws/lsphp5/bin/php which I had previously built using the same configure line as the old cpanel apache system. This made so the CLI version had no problems with the PDO extensions.

Obviously using /usr/local/lsws/lsphp5/bin/php I had different ini's so I just made a symbolic link to the ini that cPanel makes.

So I am wondering is this at all normal? I worked around the problems to make a sane setup to a degree. I can see there being problems if PHP 5.2.9 was to come out. I'd need to build multiple PHP's in order to keep the setup working properly since the CLI version does not match that of what the web server is using. So timing could be a problem.

 

[mistwang]

Sometimes, user need to do "make clean" under /home/cpeasyapache/src/php-5.2.x
then build matching PHP.

When you build matching PHP from WHM, the PHP will share the same php.ini as Apache mod_php. With LSWS admin console, you have the flexibility to specify the location of php.ini .

To use the same php.ini or separate one is up to you. Some user may have difficulty to keep two php.ini in sync, so, we opted for using one php.ini .

When you need to update PHP for the whole server, you need to switch back to Apache, then update Apache setup with cpeasyapache, then build matching PHP for LSWS, then switch back to LSWS. If cPanel would like to add native support for LSWS, it is possible to update everything in one step.

CLI PHP is only get updated with cpeasyapache.

 

[Tony]

Okay that all makes sense.

So probably after the initial setup it be easier to just compile PHP through the lsws panel or even from the start through there. Adding Zend, Ioncube, PDO ect. ect. are trivial anyways. There shouldn't be a reason to switch back to Apache so I see no reason to keep it's PHP up to date anyways.

 

[mistwang]

Easy apache will install all libraries for you if anything missing on your server. For unexperienced people, it is a good idea to run easy apache first, then build matching PHP.

May not be necessary for experienced admins.

 

[Tony]

When you build matching PHP from WHM, the PHP will share the same php.ini as Apache mod_php. With LSWS admin console, you have the flexibility to specify the location of php.ini .

To use the same php.ini or separate one is up to you. Some user may have difficulty to keep two php.ini in sync, so, we opted for using one php.ini .

Throwing this up on a semi production environment now and I was hoping to just not do the hack up I did while testing. I'm close except for one thing.

It seems with the PDO modules the build matching library doesn't work out to well. You end up with the litespeed version being unable to load the pdo modules. At least in my environment that seems to be the case. If you drop in the ones generated from the build then you end up with the old php being unable to load the modules. This is a problem if you have say the CLI PHP still available.

So how can one specify a different php.ini via the admin console? I can't find where that's an option.

 

[mistwang]

That's why we recommend keeping PHP for Apache and LiteSpeed in sync. When you upgrade PHP, upgrade Apache first, then LiteSpeed.
If you want to the easiest soltuion, just "Build Matching PHP" from our WHM plugin.

Or, you need to setup LiteSpeed PHP completely independent to Apache PHP, build LSPHP through admin console and install it to $SERVER_ROOT/lsphp5, so it will use a different php.ini file.

To use a different php.ini without rebuild PHP, you can add a command line parameter to lsphp5 external application like ".../lsphp5 -c <path_to_php.ini>"

 

[Tony]

That's why we recommend keeping PHP for Apache and LiteSpeed in sync. When you upgrade PHP, upgrade Apache first, then LiteSpeed.
If you want to the easiest soltuion, just "Build Matching PHP" from our WHM plugin.

Hmm interesting I had the same versions running 5.2.8 on both. I did notice that it complained that the source folder was missing and it just grabbed a fresh one. I imagine that is what caused the problems with the pdo loaders maybe? I ended up copying the cli built and replacing the ones that cpanel built a week ago and also using the modules built when the litespeed version was made.

I have another machine lined up to do on Wednesday I'll rebuild php once from cPanel then do the matching php and see if it still has problems with the pdo loaders not being compatible.

 

[Tony]

The pdo's made by cPanel's easyphp were still not compatible after building right from the same source. So I am guessing that php will only use the modules that were compiled with it. Easy enough fix for me copy the CLI made by the matching litespeed library over the system php cli.

 

[mistwang]

Can you please post the whole PHP configuration parameters. we will try to reproduce the problem and automate the installation in our lab.

 

[Tony]

'./configure' '--enable-bcmath' '--enable-calendar' '--enable-dbase' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes' '--enable-mbstring' '--enable-pdo=shared' '--enable-soap' '--enable-sockets' '--enable-wddx' '--enable-zend-multibyte' '--enable-zip' '--prefix=/usr/local' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libexpat-dir=/usr' '--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-mime-magic' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=/usr/bin/mysql_config' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pgsql=/usr' '--with-pic' '--with-png-dir=/usr' '--with-pspell' '--with-sqlite=shared' '--with-tidy=/opt/tidy/' '--with-ttf' '--with-xmlrpc' '--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib' '--with-zlib-dir=/usr' '--with-litespeed'

No litespeed on the easyapache compile but everything else is the same for the php settings.

 

[mistwang]

Just upgrade our cPanel test server to 5.2.8 with similar configuration, then build matching PHP binary, seems lsphp5 works with the PDO modules built by ezapache. at least when we try "lsws/fcgi-bin/lsphp5 -i", there is no error message and PDO modules loaded successfully.

Does it show errors only when PDO being actively used by a PHP script?

 

[Tony]

Well on the phpinfo PDO does not actually load the modules.

The modules sitting in the extension directory are from ezapache and from my test they were not actually loading. You should see something like this if they are loaded properly:

/usr/local/lsws/fcgi-bin/lsphp5 -i | grep pdo
(configure line here)
pdo_mysql
pdo_sqlite
PECL Module version => (bundled) 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6.2.3 2007/12/31 07:20:10 sebastian Exp $

I'm not sure on the error messages that litespeed was seeing but since PDO was not actually loading. I grabbed the pdo modules from the php source folders modules folder from the php build. I dropped them into the extension directory for php.

Now this solved litespeed but then the CLI version from cPanel has errors which I assume are the same that litespeed had. Here's the errors that it encounters:

[31-Dec-2008 12:06:52] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-zts-20060613/pdo.so' - /usr/local/lib/php/extensions/no-debug-zts-20060613/pdo.so: undefined symbol: executor_globals in Unknown on line 0
[31-Dec-2008 12:06:52] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-zts-20060613/pdo_sqlite.so' - /usr/local/lib/php/extensions/no-debug-zts-20060613/pdo_sqlite.so: undefined symbol: executor_globals in Unknown on line 0
[31-Dec-2008 12:06:52] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-zts-20060613/sqlite.so' - /usr/local/lib/php/extensions/no-debug-zts-20060613/sqlite.so: undefined symbol: executor_globals in Unknown on line 0
[31-Dec-2008 12:06:52] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-zts-20060613/pdo_mysql.so' - /usr/local/lib/php/extensions/no-debug-zts-20060613/pdo_mysql.so: undefined symbol: core_globals in Unknown on line 0

I have no idea why it happens. But I've had it happen on each machine I've ran litespeed on.

 

[mistwang]

which version of apache are you using? suphp? mod_php?
There must be something different in the way how PHP was compiled.
We use Apache 2.2 with mod_php.

 

[Tony]

These machines previousy had Apache 2.2.11 and suPHP.

 

[Tony]

Okay I just did a fourth machine and well here's an interesting one LiteSpeed's PHP was able to load PDO. I'm officially very confused considering all these machines were almost identical in every way.

 

[mistwang]

Must be something different. Maybe cPanel ezapache update some parameter recently.
If you would like to find out why, you can try a fresh rebuild of Apache/PHP on those servers with those problem, then build matching PHP.

I am experiment with suphp option now.