Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: easyapache

  • EasyApache 4, PHP, and WP-CLI

    EasyApache 4, PHP, and WP-CLI

    Way back in March, I upgraded my server to use EasyApache 4. I did this because I wanted to have multiple versions of PHP on my server and be able to segregate it by domain. I also wanted to be able to upgrade PHP without having to rebuild Apache.

    For the most part, it’s been great. There were a couple odd snafus, like when it accidentally installed the wrong wp-cli on a minor upgrade for me, but it magically fixed it.

    PHP Breaks WP-CLI

    The problem was when I ran wp-cli commands, I got this error:

    PHP Warning:  array_slice() expects parameter 1 to be array, null given in phar:///usr/local/bin/wp/php/WP_CLI/Runner.php on line 610
PHP Warning:  Invalid argument supplied for foreach() in phar:///usr/local/bin/wp/php/WP_CLI/Configurator.php on line 132
PHP Warning:  proc_open(): Descriptor item must be either an array or a File-Handle in phar:///usr/local/bin/wp/php/commands/help.php on line 111
PHP Warning:  proc_close() expects parameter 1 to be resource, boolean given in phar:///usr/local/bin/wp/php/commands/help.php on line 111
Content-type: text/html; charset=UTF-8

    Scary! I tried reinstalling and that didn’t work

    I took a note of what version of PHP I had running on command line and so something weird:

    PHP 7.0.10 (cgi-fcgi) (built: Aug 22 2016 20:34:53) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.10, Copyright (c) 1999-2016, by Zend Technologies

    The Wrong PHP

    PHP 7.0.10 (cgi-fcgi) sounds like it should be okay, except I knew two thing:

    1. Fast CGI (fcgi) isn’t supported on EA 4 yet. It’s not even supported today. They’re working on it but it shouldn’t have been a thing installed.
    2. That should be cli not cgi-fcgi!

    I pinged a friend at cPanel who said “Oh no!” and promised to look into it for me. The next day I got an email that there was a minor PHP update to my server last night. I knew that meant PHP had been rebuilt. When I went to look, wp-cli was working again.

    Ergo – Something was wrong in PHP 7.0.10. It pushed the wrong version of PHP for command line somehow.

    Risk vs Reward

    Obviously this is a risk, having a server auto-update itself. It could install a rogue package or someone could typo or worse. At the same time, having PHP apply it’s own security patches for me means I don’t have to worry that I’m in Japan for a week and forget to do something. The risk, knowing that EA will roll out a fix for me, is less than the reward of being secure.

  • EasyApache 4

    EasyApache 4

    While we use Ubuntu and Debian things at work, I have a CentOS server that is (as of today) on CentOS 7. Which means not only is it weird and uses yum, but it has cPanel and WHM installed.

    Over the last year or so, cPanel has been working on EasyApache 4 (EA 4). EasyApache is their … easy way to manage Apache and upgrade things. It’s an interface to help make things like your LAMP stack easier to comprehend, and it’s actually pretty nice. EA 3 has been around for a while, and it has serious limitations. Like you have to re-run EasyApache to upgrade PHP (always annoying), and you can’t have multiple versions of PHP. That means when you upgrade PHP to 5.6, everyone is upgraded to 5.6, and damned be the conflicts.

    This … was a problem.

    I have some older code that can use 5.6 but I’ve not been able to fully test it on 7. And I want 7. You don’t even know.

    The actual upgrade process is remarkably painless. I had two errors, one of which was my own doing (don’t try to use opcache if you don’t have opcache installed…) and one was math related. The majority of my settings ported over painlessly.

    AH00316: WARNING: MaxRequestWorkers of 40 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 25, for a maximum of 1 servers.

    Obviously the fix there was to change MaxRequestWorkers to 50.

    The interface itself is much nicer. It’s a modern design that is easy to look at with whitespace and tabbing that is natural. The only thing I didn’t like was I couldn’t tell it ‘Install PHP 7 and pick the same options as PHP 5.6 please.’ I ended up copying down what I’d selected for PHP 5.6 and then manually reproducing.

    The provisioning process took a little getting used to, after years of EA 3, but once I had used it a couple times, it felt natural. This can be said of all things. Embrace change, right? It’s also faster, which is very welcome. The longest part is the review process, where it checks for conflicts. This used to happen ‘inline’ with the old deploy, so moving it out just changes the when. I found I preferred it, since I didn’t think “And I’m done!” I knew I couldn’t go forward.

    Initially it installed suphp. I didn’t notice that’s what the default was and found all sorts of errors because of permissions. Errors like this:

    SoftException in Application.cpp:255: File "/home/public_html/index.php" is writeable by group
SoftException in Application.cpp:613: Directory "/home/public_html/gallery" is writeable by group

    I actually knew the fix for this was to run the following in my public_html folder:

    find . -type f -name '*.php' -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

    And yes, that solved everything. I was logged in as Ms. Groves root anyway, so I bounced through my users and ran it.

    But… did I want to stay on suphp? Turns out EA 4 only supports FastCGI with the FastCGI Process Manager (PHP-FPM), and while I’ve been using that for a while (instead of the dread mod_php). The problem there is that suPHP or CGI PHP handlers don’t support opcache. That meant I either had to suck it up and do the manual install for FastCGI or I could wait for v58 of WHM, which will have a UI.

    I opted to wait and stay on suPHP right now. The domains on my site are pretty fast, thanks to the SSD and a well optimized server. Load time did increase, I won’t lie, but it was pretty negligible. I don’t think it’ll really hurt things at this moment. I did some quick tests on GTmetrix and found my load time for sites on PHP 7 actually decreased.

    And that’s why I wanted PHP 7. It’s just faster.