The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

EasyApache4: Definitely Worth It

Discussion in 'EasyApache' started by linux4me2, Aug 5, 2016.

Tags:
  1. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    79
    Likes Received:
    13
    Trophy Points:
    8
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    I upgraded to v. 58 and then did the migration to EasyApache4 (EA4) a couple of days ago. It wasn't an easy transition. It took me about 15 hours of work, some of which involved getting help from my web host (managed VPS) and even a cPanel support ticket.

    My migration to EA4 was not straightforward, so the fact that I had issues doesn't mean you will. I am running WHM/cPanel on a VPS, I'm running Litespeed instead of Apache, I have a lot of sites using custom PHP scripts, I was using ModSecurity with the Comodo WAF Plugin instead of just the OWASP vendor rules, etc.

    One problem I had was with ModSecurity, which appeared not to be working, and the Comodo WAF Plugin, which gave me a 500 error after the migration to EA4. Even after removing and reinstalling the Comodo WAF Plugin, which fixed the 500 error, the Hits List was empty. It turned out ModSecurity was working, but the ModSecurity Hits List was not updating because of an issue with tailwatch. The bright side was that the problems with the Comodo WAF plugin motivated me to switch to running the Comodo rules as a vendor with my custom rules in the ModSecurity Tools -> Edit Rules UI, and I don't need to worry about the Plugin anymore.

    The other major problem was with the new include_path for PHP, which broke a number of those sites with custom scripts that were using "require_once" scripts that used to live in the include_path for PHP. In that case, the templates for each vhost on my VPS were interfering with php.ini settings for open_basedir, so even when I moved the scripts to the new include_path, they were not accessible.

    The last issue was with WHMCS, which was giving me the white screen of death. That turned out to be because the EA4 migration script didn't bring along the memory_limit setting from EasyApache3, and for some reason was using only 30M for memory_limit. Setting memory_limit to the default 128M solved that problem. None of the WordPress sites I have were adversely affected, and did fine throughout the process.

    Once those things were resolved, it has been smooth sailing, and despite the struggle it took me to get to this point, I think it was well worth it. No more re-compiling every time there's a new version of PHP. The MulitPHP capability has made it easy to start testing PHP 7 on a couple of sites, and I am very impressed with the speed boost it gave the test sites. Next, I'm going to give the AutoSSL a try.

    I really want to thank the folks at cPanel. EA4 is well worth the time it takes to make the migration even if you have some issues with it like I have.
     
    eva2000, cPanelMichael and Infopro like this.
  2. WhiteDog

    WhiteDog Well-Known Member

    Joined:
    Feb 19, 2008
    Messages:
    118
    Likes Received:
    0
    Trophy Points:
    16
    I would not consider spending 15 hours on this "worth it" ... my customers are not going to wait this long.
    cPanel should start putting together a list of common issues with EA4 and how to resolve them.
     
  3. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    79
    Likes Received:
    13
    Trophy Points:
    8
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    I would much rather have had a seamless upgrade, but I have been waiting a long time for PHP 7 and AutoSSL, so spending a day getting EA4 working was worth it for me. What I was trying to say was that even though it did take a day for me to get things working, now that it is, I'm glad I went through it. I think most people won't have the issues I did, and now there are plenty of posts about issues and workarounds that didn't exist when I did the migration.

    The known bugs/workarounds post is an excellent idea.
     
  4. rpvw

    rpvw Well-Known Member

    Joined:
    Jul 18, 2013
    Messages:
    118
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Spain
    cPanel Access Level:
    Root Administrator
    Wanted to add my .2c to this. As a former supplier of software, I am particularly sensitive to how anything new is received by the public.

    So lets define a few things - the public I refer to here are the server owners/admins/operators, and they have their clients to look after.

    Starting from the premise that nobody actually likes change, and we all prefer to sit in our comfortable state of existence surrounded by predictable and familiar parameters - the sudden threat of something NEW will inevitably cause consternation and revolt (yes, yes, we know all server admins are revolting - cPanel staff can stop falling about laughing now :( ). Having said that, the initiative and road-map to drag EasyApache into the 21st century and ultimately make it easier to maintain and deploy is worthy of the highest praise and respect.

    The area that does worry me, however. is the fact that it appears to be far from ready as a main stream release. Admins spending 15 hours to get it working has the potential to destroy a one/two man hosting company after their clients become thoughtfully fed up and jump ship. I am sure the huge hosting companies with almost endless human resources of techs and support personnel will welcome their new clients with glee - but cPanel may have lost another licensee in the process.

    The bottom line is that any software has got to work out of the box (unless you want to follow in the steps of our friends from Redmond), for every eventuality and configuration, and having to wade through endless forum suggestions and issues and work-rounds to bugs that should shouldn't be there in the first place of a production ready release is just not acceptable.

    There seems to be a disturbing trend in software development these days that pushes the basic de-bugging and quality control onto the end user. Personally I abhor these tactics as shabby and underhanded. It has all the feel of the bean counters cutting the R&D budgets by chopping off the testing and evaluation stage of the release - let the users do it - it will save us a fortune and we can get on with other half baked project in the time we save.

    Come on guys, we expect cPanel to be better than that! And if the intention was to rush a new feature to production from pure altruism, it may well backfire on you as those revolting admins refuse to see your vision and magnanimity, and kick and scream and throw their toys out of the cot.

    Maybe my thoughts and words are a bit harsh, and if they are out-of-order or truly unjustified; my apologies - but realistically, from what we are being fed, I am finding it difficult to see this situation in any other way.
     
    Archmactrix likes this.
  5. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    79
    Likes Received:
    13
    Trophy Points:
    8
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    You've got me wishing I never posted. My intention was to say that even though it took me a long time to get EA4 working, it was worth it. I like EA4 that much better than EA3. The other thing I think I did a poor job of explaining was that my problems were due to third-party plugins, custom code, and probably my own ineptitude when it came to troubleshooting some of the issues. I tried to point out that only the sites with custom code were affected. The sites using mainstream software, like WordPress, were fine, so I'm sure I haven't lost any clients.

    If you don't like change, you can use only the "stable" versions of WHM/cPanel. By the time things hit the stable tier, most issues are resolved. There's nothing wrong with that, but that's not what I did. I wanted to try WHM v. 58, so I upgraded the day it hit the "release" tier. Not only that, but I ran the migration from EA3 to EA4 the same day. I've been doing this long enough to know that any time the word "migration" is used, I need to set aside some extra time to resolve any issues that come up. A more prudent person would have waited until v. 58 had been out in the release tier for a while and continued using EA3. I wanted to try the new features in EA4, so I took the plunge.

    I think the only way to make software work out-of-the-box is to make the environment so restrictive that no user can make alterations, add third-party software, or change the product in a way that hasn't been explicitly tested prior to release. Personally, I don't like that kind of software.

    Now, I've got a couple of sites running PHP 7 while the rest of them are running PHP 5.6, and I've used AutoSSL to test installing an SSL certificate on a site that's using a shared IP address. It took about two minutes to install the SSL certificate using AutoSSL, and it's working flawlessly. When I roll PHP 7 and AutoSSL out for my customers, they're going to be kissing my feet, not looking for a new host.
     
  6. sehh

    sehh Well-Known Member

    Joined:
    Feb 11, 2006
    Messages:
    579
    Likes Received:
    5
    Trophy Points:
    18
    Location:
    Europe
    I also migrated to EA4 and each server took 40 minutes. No need for support, no need to open tickets and everything worked great.

    *edit*

    I forgot to mention two things, in case they are of any help to others:

    1) If you used the AddHandler in your .htaccess to add more extensions, you need to change the mime type
    from: AddHandler application/x-httpd-php5 .html
    to:AddHandler application/x-httpd-ea-php56 .html

    2) The EA3 to EA4 migration does not properly migrate the php.ini file. I had to manually compare my old ini file (/usr/local/lib/php.ini) with the new ini file (/opt/cpanel/ea-php56/root/etc/php.d/local.ini) and made changes to new file accordingly.
     
    #6 sehh, Aug 7, 2016
    Last edited: Aug 7, 2016
  7. Erel

    Erel Member

    Joined:
    Jul 23, 2007
    Messages:
    11
    Likes Received:
    0
    Trophy Points:
    1
    I will add my feedback. I'm using cPanel for about 10 years now. I'm not a server or Linux expert.
    The VPS is used to run a single, busy, site.

    The migration from EA3 to EA4 was fine. However it disabled the PHP opcache feature which caused the whole site to be slow.
    I decided to upgrade to PHP 7 with opcache.

    My expectation was that if I choose an option named PHP + OPCACHE then it will install PHP + OPCACHE with all the settings required.
    However this is not the case.
    For the sake of others I will point to several steps that are required and can easily be missed:
    1. You need to choose: ea-apache24-mod_mpm_prefork
    2. Select ea-php70-php
    3. Select ea-php70-php-opcache

    Each one of these options is in a different page and can be easily missed.
    The next step is to select DSO in the PHP handlers page.

    I always thought that the worst that can happen is that the site will be offline. I learned that it can be much worse. The server returned the PHP files as text downloads. This means that any visitor now downloaded a script that may include the database password and all kinds of other sensitive stuff. This should never happen. No one in the world will ever want to deliver php files as raw text files.

    I'm still not sure why it happened. I changed it back to suPHP and then the site was offline. Only after deleting the php.ini that was located in the home folder, the site started working.

    I turned DSO again and again it started delivering the PHP scripts instead of running them on the server. I restarted the apache server and it started working properly.

    This is the first time that I encounter such issues when working with cPanel.
     
    #7 Erel, Aug 7, 2016
    Last edited: Aug 7, 2016
  8. sehh

    sehh Well-Known Member

    Joined:
    Feb 11, 2006
    Messages:
    579
    Likes Received:
    5
    Trophy Points:
    18
    Location:
    Europe
    Based on PHP7 docs for cPanel, if a user-defined php.ini exists, then that takes precedence, thus the system php.ini is not read. This means that your user-defined php.ini must be A COMPLETE php.ini, anything missing will break php execution. I'm guessing this is what caused your problem and why it was fixed once you deleted it.

    Take a look here for more details:
    cPanel's PHPRC PHP Patch for EasyApache 4 - EasyApache 4 - cPanel Documentation
     
  9. sawbuck

    sawbuck Well-Known Member

    Joined:
    Jan 18, 2004
    Messages:
    1,367
    Likes Received:
    5
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    @sehh - Important distinction - thanks for posting.
     
  10. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    648
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    Thank you to everyone for providing us with feedback on EasyApache 4. I'd like to add that anyone experiencing a problem with the conversion to EasyApache 4 is welcome to create a thread on our forums, or open a support ticket, so we can help troubleshoot any problems and ensure the conversion completes successfully.

    Thank you.
     
  11. Cantalupo

    Cantalupo Registered

    Joined:
    Aug 8, 2016
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Brazil
    cPanel Access Level:
    Root Administrator
    Same problem with me, white screen!
    This occurred after the EasyApache 4
    I tried to install ioncube there.
     
  12. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    I have upgraded a few servers to EA4 and I haven't had any problems. I'm also switching over to PHP-FPM from suPHP during this process and I haven't noticed any problems and haven't gotten any wind of any issues from my clients. Granted, I'm not really into what I'd consider my heavy usage servers yet, but some of the servers (albeit low usage) have been upgraded for a month or better, and I haven't encountered any end-user problems that I am aware of.

    I like the way EA4 is going. Or, I suppose a better way of putting this is that I think I will like the way EA4 goes. I like the modularization of EA4 over EA3. With EA3 if you had to upgrade ModSecurity, you had to recompile Apache. If you suddenly decided that you wanted mod_deflate or any other Apache module, you had to recompile Apache. If you wanted mod_cloudflare with Apache, you had to download an addon to EasyApache and recompile Apache. I quit using EasyApache3 a long time ago because of this. If I wanted mod_deflate, I just compiled the mod_deflate DSO module from Apache's source directory and included it in Apache. If I wanted ModSecurity or wanted to run an updated version of ModSecurity (how did you know when an updated ModSecurity was available?), I recompiled ModSecurity as a DSO module. Mod_cloudflare? Compile from source. It made no sense at all to have to run EasyApache3 everytime you wanted to update or add something to Apache.

    With EasyApache4 if you need to update ModSecurity, you just yum update ea-apache24-mod_security2 (of course, this assumes that cPanel releases updates in a timely manner, I'm still crossing my fingers on that). If you want mod_deflate, yum install ea-apache24-mod_deflate and it's installed. This is essentially what I was doing before, outside of EasyApache3, except I was compiling from source and EA4 provides RPMs for the addons.

    One thing EasyApache4 doesn't provide is mod_cloudflare and perhaps it would be nice if they provided an RPM for it, but honestly installing mod_cloudflare from source isn't that difficult.

    Code:
    wget https://www.cloudflare.com/static/misc/mod_cloudflare/mod_cloudflare.c
    /usr/bin/apxs -i -c -Wl,lz mod_cloudflare.c
    echo "LoadModule cloudflare_module modules/mod_cloudflare.so" >/etc/apache2/conf.modules.d/90-cloudflare.conf
    /usr/sbin/apachectl -k graceful
    It takes maybe 10 seconds. And since Apache doesn't really update that often, you should be good until a new version of Apache is released. Although, this could potentially be a pain if you have automatic updates enabled (I don't, but I monitor for updates).

    I suppose there may be other popular Apache modules that users use that might benefit from being included with cPanel, but I also wonder how many of those modules can be easily compiled as DSO modules. And Apache really doesn't change that often.

    This modularization also benefits PHP. Instead of having to rerun EasyApache3 to compile PHP when a new PHP version is released (which happens approximately every month) you just install an updated RPM. I had been compiling PHP outside of EasyApache3 because of this. One downside to this is that there is a delay between when a new version of PHP is released and when it gets added to the EA4 repositories - about a week. Not a huge issue, but I wish this was a bit quicker because a lot of the new releases fix security issues (although most are minor) meaning that about a week passes where a security issue is publicly exposed and cPanel's PHP is left unpatched. However, this is really no different than EasyApache3's dependence on PHP, there was a delay between PHP's release of an update and cPanel inclusion of that PHP update in EasyApache3.

    I also wish cPanel's PHP would install an updated version of cURL library. This might necessitate cPanel installing their own cURL and keeping it updated to be used alongside their PHP. There may be other common libraries that need to be updated in PHP, but cURL is the one that sticks out to me. They could install an always up-to-date version of cURL in /opt/cpanel/curl and compile ea-phpXX-php-curl against that version of cURL (call it ea-curl and require it alongside ea-phpXX-php-curl).

    But overall, I like EasyApache4. I like the direction they are going with making this RPM based and just the modularization of it. Does it need some tweaks? Sure. But it's a step in the right direction if you ask me.
     
    eva2000 and Infopro like this.
Loading...

Share This Page