OpenLiteSpeed 1.3 on Debian

[TPerry]

Just a heads up for anyone using Debian and installing/compiling OpenLiteSpeed 1.3.
On 1.2.9 to use php's built in opcache you had to add

zend_extension=/usr/local/lsws/lsphp5/lib/php/extensions/no-debug-non-zts-20121212/opcache.so

to the php.ini.
With 1.3 you MUST remove this from the php.ini since you now compile it in at run time as an option like you can with xcache, memcache, etc. If you fail to do this, you will probably run into the same problem I had - the site becomes either non-responsive or only loads partially.

Once I removed the line from php.ini it resumed working fine.

 

[Floren]

There is no /etc/php.d in Debian? You are not supposed to edit php.ini ever.

 

[Sheratan]

There is no /etc/php.d in Debian?

No.

You are not supposed to edit php.ini ever.

Why?

 

[TPerry]

There is no /etc/php.d in Debian? You are not supposed to edit php.ini ever.

This php.ini is specific to OpenLiteSpeed. It's installed at build time of OLS in /usr/local/lsws/php by default.
No different than the /etc/php5/fpm/php.ini setup with php5-fpm or the /etc/php5-fpm/cli/php.ini.

 

[Floren]

This php.ini is specific to OpenLiteSpeed. It's installed at build time of OLS in /usr/local/lsws/php by default.
No different than the /etc/php5/fpm/php.ini setup with php5-fpm or the /etc/php5-fpm/cli/php.ini.

I see, thanks for letting me know. There are no such files you mention above in Redhat/CentOS (highlighted in blue), there is only /etc/php.ini and /etc/php.d where you dump your custom .ini settings and PHP will grab them automatically for you. For some reason, I thought this is the standard on all Linux distros related to .d directories.

Why?

Simple, with every new release PHP introduces new variables or settings. Customizing your .php.ini will not allow the packages to update that file, resulting on deprecated variables. At least on Linux a new file will be created with .rpmnew extension so you have to do a diff every time and compare the changes. Which explains why PHP built into their compile code a php.d directory to be read for custom variables. I guess Debian does not find this important, which is.

 

[Slavik]

There is no /etc/php.d in Debian? You are not supposed to edit php.ini ever.

Litespeed build and maintain all settings / modules etc in self contained folders under the litespeed directory. Its a surprisingly logical approach actually as it makes running multiple php versions somewhat "cleaner" in my mind.

 

[TPerry]

Simple, with every new release PHP introduces new variables or settings. Customizing your .php.ini will not allow the packages to update that file, resulting on deprecated variables. At least on Linux a new file will be created with .rpmnew extension so you have to do a diff every time and compare the changes. Which explains why PHP built into their compile code a php.d directory to be read for custom variables. I guess Debian does not find this important, which is.

With Debian, it's smart enough to (when PHP is updated) update those files itself and will ask if you want to replace/keep/examine differences with it.

root@bart:/etc# aptitude safe-upgrade
The following packages will be upgraded:
  libapache2-mod-php5 php-pear php5 php5-cli php5-common php5-curl php5-fpm php5-gd php5-geoip php5-imagick php5-imap php5-intl php5-mcrypt php5-mysql php5-pspell php5-readline
  php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

Configuration file `/etc/php5/fpm/pool.d/www.conf'

 ==> Modified (by you or by a script) since installation.

 ==> Package distributor has shipped an updated version.

  What would you like to do about it ?  Your options are:

    Y or I  : install the package maintainer's version

    N or O  : keep your currently-installed version

      D     : show the differences between the versions

      Z     : start a shell to examine the situation

 The default action is to keep your current version.

 

[Jeremy P]

Simple, with every new release PHP introduces new variables or settings. Customizing your .php.ini will not allow the packages to update that file, resulting on deprecated variables. At least on Linux a new file will be created with .rpmnew extension so you have to do a diff every time and compare the changes. Which explains why PHP built into their compile code a php.d directory to be read for custom variables. I guess Debian does not find this important, which is.

As above, Debian's package manager let's you resolve such conflicts intelligently during the upgrade.

For what it's worth though, every Debian server I've used (though, to note, I don't use any sort of litespeed) has /etc/php5/conf.d/ which is pretty much the same thing you're going on about. Drop files in there and they're automatically pulled into the configuration.

The format is a little different from CentOS it looks like, but this isn't limited to PHP. The package manager itself uses directories like /etc/apt/sources.list.d/.

With that said I could see how it's worth placing your settings in those directories for easier maintenance, but it's pretty bold to make a sweeping generalization like "you should never edit php.ini." It's your server, you should set it up however makes you happy provided you understand the caveats.

 

[Floren]

The .d directories (plenty of them in Linux) were created specifically so you NEVER edit the config files. I don't see it bold at all (editing the config files), when I have to deal with upgrades on a constant basis. I would like to edit as little as possible the configurations, but again, that is me the lazy guy.

 

[Floren]

With Debian, it's smart enough to (when PHP is updated) update those files itself and will ask if you want to replace/keep/examine differences with it.

root@bart:/etc# aptitude safe-upgrade
The following packages will be upgraded:
  libapache2-mod-php5 php-pear php5 php5-cli php5-common php5-curl php5-fpm php5-gd php5-geoip php5-imagick php5-imap php5-intl php5-mcrypt php5-mysql php5-pspell php5-readline
  php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

Configuration file `/etc/php5/fpm/pool.d/www.conf'

==> Modified (by you or by a script) since installation.

==> Package distributor has shipped an updated version.

  What would you like to do about it ?  Your options are:

    Y or I  : install the package maintainer's version

    N or O  : keep your currently-installed version

      D     : show the differences between the versions

      Z     : start a shell to examine the situation

The default action is to keep your current version.

IMO, that is pretty cumbersome... I prefer the Linux approach where a new file is automatically created and you do a quick diff to see what changed. But stil, this is a matter of taste. I'm not familiar with Debian so what looks pretty convenient for me it might be the other way around for you are others. The only distros I really dealt with are Redhat, Suse and Solaris so please forgive my lack of knowledge on Debian.