ISPConfig with Zend Server?

Hello!

I am curious if ISPConfig and Zend Server can be made to function side-by-side. Judging by the lack of viable Internet search results on the subject, I am perhaps the first person in the world to endeavor upon such an ambitious feat.

After installing Zend Server 8.0.1, and upon cursory inspection of the overall configuration, filesystem locations, etc., it's clear that it will not be trivial to get ISPConfig and Zend Server to coexist peacefully, never mind "play together nicely".

Has anybody ever tried this? Or is this a pipe-dream?

Thanks for any insights...

 

I'm making pretty respectable progress on this.

I have both ISPConfig and Zend Server running side-by-side, but I'm snagged in one particular spot. The problem I'm seeing is that ISPConfig isn't processing the Jobqueue, and presumably this is because it is unable to interact with php-fpm.

Zend Server has more or less taken control of the entire PHP environment, including php-fpm. To enable ISPConfig to deal with this change, I can think of at least two PHP-specific adjustments that will need to be made:

1.) Symlink-ing the PHP CLI executable, so that ISPConfig is able to find it:

Code:

# ln -s /usr/local/zend/bin/php /usr/bin/php

2.) Tailoring the php-fpm upstart script and/or init-script so that ISPConfig is able to use it.

I'm poking-around in the ISPConfig source code, trying to determine what might be the best method for enabling ISPConfing to control Zend Server's custom php-fpm executable.

On line 229 of /usr/local/ispconfig/server/mods-available/web_module.inc.php appears the restartPHP_FPM() function.

Should I:

a.) Override this function in some fashion?

b.) Leave this function alone and instead modify the value of the System -> Server Config -> Web -> PHP-FPM init script field, so that it points to Zend Server's fpm management script?

c.) Take some other measure entirely?

I'm not looking to be spoon-fed; I write PHP for a living. I'm just looking for some general guidance, as I know very little about how the ISPConfig server components are structured. I simply wish not to introduce problems that may be intermittent, introduced only after an upgrade, etc., by going about this in a way that that ISPConfig developers would not recommend.

Thanks for any hints...

 

Thank you for the quick reply, Till. I very much appreciate it!

Understood. But certain configuration changes to a hosted website require the php-fpm process to be reloaded, correct? Wouldn't it be problematic if ISPConfig could not call the restartPHP_FPM() function successfully? Undoubtedly, this call is failing in my setup because the init-script to which the ISPConfig is pointing, "php5-fpm", does not exist at the moment. (But reading ahead, your next suggestion may eliminate this issue...)

Ahh! That's the good advice for which I was hoping when I posted! Simply adding a new Custom PHP Version looks very promising.

The problem I'm having after adding it, however, is the same: items in the Jobqueue are not being processed. I have set the Loglevel to Debug and am tailing /var/log/ispconfig/ispconfig.log, in which the following entries are repeated indefinitely:

Code:

19.01.2015-15:41 - DEBUG - There is already an instance of server.php running. Exiting.
19.01.2015-15:41 - DEBUG - There is already a lockfile set. Waiting another 10 seconds...

If I manually kill (sigterm) the instance of server.php that is running, it seems to be respawned almost immediately and the messages continue.

What's the best way to troubleshoot this?

To be clear, in order to install Zend Server, I had to completely remove the php5 packages. In the process, the PHP executable was removed from /usr/bin/php. At that time, ISPConfig began logging the following message repeatedly, once a configuration change was added to the Jobqueue:

Code:

Mon Jan 19 10:46:01 EST 2015 /usr/local/ispconfig/server/server.sh: line 20: /usr/bin/php: No such file or directory

So, I created a symlink, as mentioned in my previous post:

Code:

# ln -s /usr/local/zend/bin/php /usr/bin/php

Is there a more appropriate way to inform ISPConfig about the new (Zend's) "php" executable location?

Thanks again for your sound advice and assistance!

UPDATE: Okay, fixed! I just had to find the lock file (turns-out it's located at /usr/local/ispconfig/server/temp/.ispconfig_lock) and delete it. As soon as I did that, all of the jobs were processed and the Jobqueue cleared-out. Now, when I edit a Website, the changes are committed to disk and seem to be effective.

I'll post more complete details of my implementation once I confirm that everything is working as designed...

 

To preface my next question, I had to create a symlink to get the ISPConfig interface itself running in this setup:

Code:

# ln -s /etc/php5/fpm/pool.d/ispconfig.conf /usr/local/zend/etc/fpm.d/ispconfig.conf

Is there a better way of achieving the same?

Given that the PHP executables that are bundled with the Zend Server packages are the only PHP executables on this server now, I considered modifying the "global" PHP settings under System -> Server Config -> Web -> PHP Settings, so that ISPConfig will write the ispconfig.conf and apps.conf files to the Zend Server pool directory (along with the other vhost configs that are already there as a result of assigning a Custom PHP Version to them). But when I tried modifying the global PHP Settings, I noticed that only apps.conf is written to the alternate location.

This makes sense, because ISPConfig itself has to be able to run, from a static and reliable location, in order to make changes to other vhosts.

Ultimately, my question is this: should I bother changing these global PHP settings? Or should I just create symlinks for ispconfig.conf and apps.conf, as demonstrated above?

My primary concern with either approach is that ISPConfig is able to manage the php-fpm daemon correctly, so that the php-fpm configuration can be reloaded when a vhost is modified.

To this end, I tried entering a custom value in the "PHP-FPM init script" field, "/usr/local/zend/bin/php-fpm.sh", but the ISPConfig validation mechanism rejects this value with "ERROR Invalid php-fpm init script." What about this value does ISPConfig not like?

UPDATE: I dug into the source code and found applicable regex on line 854 of /usr/local/ispconfig/interface/web/admin/form/server_config.tform.php and the pattern allows a basic file name only (no preceding path):

Code:

/^[a-zA-Z0-9\.\-\_]{1,128}$/

Maybe this is for a good reason; it threw me for a bit of a loop because earlier versions of ISPConfig appear to have allowed a path prefix (see screenshot at bottom of https://www.howtoforge.com/how-to-u...and-fastcgi-with-ispconfig-3-debian-wheezy-p3 ).

The obvious concern is that if I modify the source code, it will be overwritten upon update, but maybe there is a way to extend/override it safely. Also, there is the possibility that other code that references this value assumes a prefix already (e.g., "/etc/init.d/"), in which case adding one would produce unexpected results.

Also, I see that there are some workarounds employed in web_module.inc.php that are specific to Ubuntu 14.04. While I am indeed on Ubuntu 14.04, those workarounds are not necessary because the Zend Server stack already includes the patches required to fix the problem cited in the Launchpad bug. I am speaking specifically to this line:

Code:

$initcommand = '/sbin/start-stop-daemon --stop --signal USR2 --quiet --pidfile /var/run/php5-fpm.pid --name php5-fpm';

Does this command stop the daemon completely? If so, I want to avoid this, especially given that this issue does not apply to the system in question.

Also, the hard-coded PID file location in this command does not match the location on this system.

What is the best way of reconciling these issues?

Thanks again for your continued assistance with this, Till!

 

I have a couple of notes and observations to add, as a follow-up to my previous post.

1.) While the "PHP-FPM init script" field in the "global" PHP Settings limits the input to a basic executable name (with no path prefix), the same does not appear to be true of the equivalent field under "Additional PHP Versions". This appears to be a bug, however, because further analysis of this mechanism reveals that the path prefix appears to be stripped when the init script is actually called.

For example, if I enter "/usr/local/zend/bin/php-fpm.sh" into this field, the log entries look like this whenever I modify the vhost's PHP configuration:

Code:

20.01.2015-13:17 - DEBUG - Restarting php-fpm: service php-fpm.sh reload

Of course, this does not work, because "php-fpm.sh" is an invalid service name.

This observation harkens back to a concern that I expressed in my previous post around what type of input, exactly, these fields labeled "PHP-FPM init script" expect. I believe that this observation answers that question and allays that concern: a simple service name should be entered into these fields, not a full path to an executable file or script.

So, the regex cited in my previous post is correct, but it should really be applied to the second instance of this field, under "Additional PHP Versions", too. I'm happy to open an issue on the tracker if this is, in fact, a bug.

I implemented a simple solution to this:

Code:

# ln -s /etc/init.d/php-fpm-zend /usr/local/zend/bin/php-fpm.sh

Then, I entered "php-fpm-zend" into both "PHP-FPM init script" fields, and configuration changes to my vhosts are indeed reflected as soon as the Joqueue is processed. Awesome!

Is there any non-obvious "downside" to this approach? I am thinking along the lines of ISPConfig relying upon some functionality that the "stock" PHP-FPM init script provides, e.g., the /usr/lib/php5/php5-fpm-checkconf executable (which is no longer present on this system).

2.) With regard to the workaround for the FPM reload bug in Ubuntu 14.04, it looks like that will be simple enough to avoid.

An unintended side-effect of fixing the issue above is that it fixed this issue, too. I noticed that this conditional logic was no longer applied once I changed the "PHP-FPM init script" value from "php5-fpm" to "php-fpm-zend". I didn't have time to analyze the underlying PHP code to determine under which conditions, exactly, the workaround logic is skipped.

So... this is looking pretty good! I'm sure there will be other issues to iron-out, but I'm feeling pretty optimistic about this.

 

That makes perfect sense. Thank you for clarifying that field's underlying behavior.

I know that you're a busy guy, so I created a task for this:

http://bugtracker.ispconfig.org/index.php?do=details&task_id=3796

How do you feel about me creating a proper How To for integrating Zend Server with ISPConfig? Is this a worthwhile topic that will be of broad interest?

 

It looks as though I have a couple more wrinkles to iron-out.

Zend Server 8 utilizes something called Z-Ray (you know, x-ray, with a "Z", for Zend), which provides deep insight into a PHP application's inner-workings; it's one of the best features of Zend Server to date.

This feature does not work correctly (or at all, really) unless the ISPConfig-controlled php-fpm pools (e.g., "[web1]", "[web2]", etc.) are modified to have less restrictive permissions.

The default values

Code:

listen.owner = web1
listen.group = client1
user = web1
group = client1

must be replaced with the following values

Code:

listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data

I don't like this at all, for the obvious reason that it mitigates the well-placed security measures that ISPConfig implements, in the way of keeping pool configurations isolated and bound to specific system users.

Zend Server makes no such effort; all vhosts are lumped into a single pool. It should make you proud to know that you've done a much better job of implementing a secure stack than Zend has, with all its corporate resources, Till. Cheers to you.

I would rather approach this the other way round: modify the Zend Server configuration to allow Z-Ray to work with ISPConfig's default approach to separation-of-privileges. Unfortunately, as yet, I have not been able to determine, what, exactly, would need to be changed on the Zend Server side.

Another, related complication is that ISPConfig and Zend Server each has its own web-server document root. The only way (that I've found) to deal with this gracefully is to use bind-mounting (in /etc/fstab) to "trick" Zend Server into looking at the ISPConfig-controlled web-root, e.g., /var/www/[website_domain]. This approach is nice because it makes it unnecessary to manage vhosts through Zend Server at all; everything is controlled via ISPConfig. There are a couple of small steps required to enable so-called "Application Deployment" in Zend Server for vhosts that are controlled through ISPConfig, but they are not an obstacle. And it remains possible to add vhosts through Zend Server, if one were so inclined; Zend Server designates each type of host with a distinct icon and a tooltip, "System Defined" or "Zend Server defined".

Also, for reasons beyond those stated above, the bind-mount approach is necessary for one specific use-case (development), which requires me to mount Windows shares (that contain the PHP application source code) to the Linux filesystem. One limitation of bind-mounting that I've encountered is that when a network share is mounted via CIFS (or Samba, presumably), its effective owner/group and permissions cannot be changed by remounting, a la `mount -o remount`. Normal filesystem mounts seem not to have this limitation; it must be specific to network-based mounts.

The long-and-short of this entire post is that I can't find any way around changing those pool configuration parameters to "www-data", across-the-board. That seems to be the only "solution" that satisfies all requirements: functional Z-Ray; no double-entry for vhost definitions (in ISPConfig and Zend Server); and no duplicate web-server root directories on the filesystem.

I made this change by overriding the master configuration file

Code:

# cp /usr/local/ispconfig/server/conf/php_fpm_pool.conf.master /usr/local/ispconfig/server/conf-custom/php_fpm_pool.conf.master

and then modifying the values therein accordingly.

As a final note, I have not tested this with the other four PHP modes, and have no idea whether or not it would work.

I realize that this is complicated and outside the scope of normal ISPConfig operation, so I don't expect much assistance in this regard. But if you do happen to have a better approach or an alternate suggestion, I'm all ears.

For now, I'm "calling it good". Thanks for all your help!

 

Thanks, Till.

I will add a more complete, step-by-step walk-through once I've tested the integration process several more times, end-to-end, and have let it run for a while.

 

Till, is there any means by which to set the "Zend Server" entry that I created under "Additional PHP Versions" to be the default PHP version, such that if I create a new Website and do not explicitly change the PHP version from "Default" to "Zend Server", the latter will still be used?

Basically, I wish to eliminate the non-Zend-Server PHP version altogether, as I see no use for it with the Zend Server stack in place.

Thanks!

 

Thanks for the speedy reply! I'm happy to create the Feature Request, if that would be helpful.

 

It looks like somebody already created a Feature Request for this a couple of years ago:

http://bugtracker.ispconfig.org/index.php?do=details&task_id=2873

I simply added my vote!

 

Just a quick update on this.

I've had the Zend Server + ISPConfig stack running for a few months now and it seems to be 100% stable. I have yet to find any issues.

In the near future, I'll post the full HOW-TO.