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 Announcement

Discussion in 'cPanel Announcements' started by MattDees, Jan 13, 2015.

  1. MattDees

    MattDees cPanel Product Owner
    Staff Member

    Joined:
    Apr 29, 2005
    Messages:
    417
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    Over the past several months, we have been working on the next generation of EasyApache. In EasyApache 4, we will make quite a few major changes to the way cPanel & WHM utilizes Apache HTTPd & PHP. This will initially be an opt-in update so that users can choose when to move to the new ecosystem, but at some point, this will be a required change. The major changes that we plan to introduce are:

    • Improved Operating System Integration and migrating to OS standard paths for services
    • EasyApache will use the system package manager
    • Full binary distribution of Apache HTTPd and PHP via RPM & yum
    • Use of Modern Apache releases (2.4)
    • Automatic updates of Apache HTTPd & PHP
    • Ability to set different PHP versions on a per-vhost basis


    As you can tell, there are many changes compared to what EA3 has delivered over the years. The purpose of this article is to solicit feedback about what is being planned for EasyApache 4 delivery. We absolutely want to know what our customers think of this plan! Please use this thread for posting comments.

    Improved Operating System Distribution Integration
    In order to align cPanel & WHM better with the operating system that the server runs, we will move the various Apache assets to match the file system paths that CentOS and RHEL provide. This will allow better customizations to Apache and make the deployment of new Apache modules a rapid process. Symlinks will be left behind in /usr/local/apache to help old scripts work with the new paths.

    With these changes, porting most Apache modules that already have an RPM built for CentOS/RHEL should be relatively easy: tweak the spec file, ensure proper dependencies are provided, and recompile the RPM. Alternatively, it means that the existing resources for building RPMs for Apache modules will remain relevant and follow the process used by RHEL Administrators.

    EasyApache Interface to move to Package Manager
    With the initial release of EasyApache 4, we will move the EasyApache interface to the Package Manager, which will provide an interface for yum. cPanel will create yum repositories that hold the EasyApache4 RPMs, which includes Apache, PHP, and friends. Using yum will also allow your own customized repositories.

    To shorten processing time and provide better quality control over the packages, EasyApache will begin utilizing RPMs. This will meet one of our project goals of cPanel & WHM becoming a better member of the Operating System’s ecosystem.

    Package Manager Screenshot 2.png

    The purpose of this UI is to provide a general-purpose interface into the packages and repositories available on a system.

    Multi-PHP Domain Support
    The release of EasyApache 4 will include Multi-PHP support at the VirtualHost level. We will utilize Red Hat’s Software Collections to allow the installation of multiple PHP versions simultaneously. WHM and cPanel Interfaces will allow users and administrators to select system level and per-domain default PHP versions. This will be achieved by using AddHandler entries in .htaccess files.

    Screen Shot 2015-01-08 at 5.50.59 PM.png

    Modern Apache only (2.4)
    EasyApache 4 will only provide RPMs for Apache 2.4. This allows us to provide better support for Apache and simplifies the process of rolling out customizations.

    Automatic Updates
    We plan to automatically update Apache & PHP by default. This will be an opt-out process so that hosts can easily put updates of Apache & PHP under their control.

    Feedback
    We absolutely want to hear what you think of our plans for EasyApache4! Please comment below.
     
    #1 MattDees, Jan 13, 2015
    Last edited: Jan 13, 2015
    velnix likes this.
  2. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,557
    Likes Received:
    7
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    Modern software releases that stay up-to-date via RPMs and YUM is my favorite aspect. I would expect an option to allow automated updates to include major new versions and not just minor versions, though understandably not by default and just as a preference for people wishing to be on the latest releases, such as on a system used for web site development or where compatibility with out-of-date web applications is not a concern.
     
    #2 cPanelDon, Jan 13, 2015
    Last edited: Jan 13, 2015
    Kent Brockman likes this.
  3. JamesOakley

    JamesOakley Well-Known Member

    Joined:
    Apr 15, 2011
    Messages:
    83
    Likes Received:
    2
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    A few questions come instantly to mind - I'm sure more will become clear as you start to release docs to show it will all work. But:
    • What's the plan for Tomcat? (Not that I ever understood why it was installed with EasyApache in the first place!)
    • What of the custom modules that currently go in /var/cpanel/easy/apache/custom_opt_mods? (I'm sure there's a plan, but I'm trying to picture how things will work).
    • What of scripts that currently fire in /scripts/after_apache_make_install or /scripts/posteasyapache (and other similar hook-points)?

    I can see this will need a lot of time on a test server before I can be sure everything I currently include in an Apache / PHP recompile will all work, but those are the few theoretical questions that come to mind on first reading this.
     
  4. MattDees

    MattDees cPanel Product Owner
    Staff Member

    Joined:
    Apr 29, 2005
    Messages:
    417
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    We will be providing RPMs for mod_jk at some point in the future, currently it is on the bottom of our backlog.

    This will be an opt-in upgrade at first and we will be trying to provide a migration path for any commonly used modules. If your host has a module that they use, you may need to write an RPM for it that builds against ours. We will be providing documents, tutorials & resources on how to do this.

    We haven't explored this yet, however we can provide hooks from within the RPM installation itself using the Standard Hooks system or one can integrate into this using more distro-standard methods.
     
  5. Tcalp

    Tcalp Active Member

    Joined:
    Mar 16, 2013
    Messages:
    25
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Ottawa, ON, Canada
    cPanel Access Level:
    DataCenter Provider
    I assume you guys are slowly gearing this more and more towards 'domain level settings' instead of cPanel account level settings (based upon the PHP version enhancement listed above). I think in a general basis it's certainly moving in the direction that it should, hopefully that will bring forward other enhancements such as per-service SSL support and domain level IP control / multi-ip per account.
     
  6. WebJIVE

    WebJIVE Well-Known Member

    Joined:
    Sep 30, 2007
    Messages:
    53
    Likes Received:
    3
    Trophy Points:
    8
    Question, what about any existing .htaccess files pointing to previous PHP versions we already have compiled and installed?

    Also, will Apache 2.4 break compatibly with any existing sites after the migration? We tried migrating to Apache 2.4 at one time and a lot of sites started getting 500 errors.
     
  7. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,130
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    Yes, I guess the htaccess files may contain commands that have been deprecated on 2.4. What course of action will be taken in such scenarios is an interesting question.

    I bet the most problematic cases will be those with very old websites with custom programming, which is, in my case, nearly the 30% of our customer base :)

    - - - Updated - - -

    Another question I can recall is: when multiple PHP versions are allowed to coexist, how will the system deal with PHP DSO or cgi's, where there are a daemon always up and listening? Will then consume more RAM?
     
  8. JamesOakley

    JamesOakley Well-Known Member

    Joined:
    Apr 15, 2011
    Messages:
    83
    Likes Received:
    2
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    I think the point is that this would need to remain opt-in for quite some time. There will be a lot of edge-cases, uncommon uses, and so on that may prove knotty for server administrators to find the best implementation for in EA4. Forcing them to move over too fast could cause chaos, as things don't work, previously installed Apache modules have to be left out for the time being, etc. There will also be third-parties to work with, making sure that people like Cloud Linux, CloudFlare and others have all been able to migrate and test the code they had that integrated into the EA3 processes.

    At the moment, for me at least, it's just mod_reqtimeout and mod_remoteip from https://documentation.cpanel.net/display/EA/Custom+Modules, although I'm sure others will have more unusual modules to move across.
     
  9. eva2000

    eva2000 Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    322
    Likes Received:
    10
    Trophy Points:
    18
    Location:
    Brisbane, Australia
    cPanel Access Level:
    Root Administrator
    Twitter:
    Interesting.. I get that RPM/YUM is easier but you might loose some flexibility that source installs provide ?

    My main concern would be with PHP and custom compiled options via /var/cpanel/easy/apache/rawopts/all_php5 etc. How is that going to be dealt with when PHP becomes a RPM only maintained system ? One of the items I add is a PHP configscan .ini directory for custom php.ini options. I guess with PHP as RPM package, does that mean you're follow OS standard paths and also include a configscan .ini directory by default ?

    Another one that's related to PHP would be how LiteSpeed Enterprise Cpanel plugin will handle building matching PHP versions once Apache and PHP move to RPM based and how that relates to multiple PHP versions feature in EasyApache4 under LiteSpeed Enterprise (for compatibility).

    I guess with major changes like this, it would be great with WHM/Cpanel licensing would make allowances for a secondary developer/staging license option - so folks could clone or replicate production systems on a staging environment and test out the EasyApache4 migration without messing up live production systems. This way you'd more likely get more early adopters and feedback from folks testing EasyApache4 migration ;) :) :D
     
  10. JamesOakley

    JamesOakley Well-Known Member

    Joined:
    Apr 15, 2011
    Messages:
    83
    Likes Received:
    2
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    EasyApache is a collection of scripts / hooks / add-on modules to make installing Apache and PHP from source easy.

    Although this change is being called EasyApache 4, it seems to me to be better described as "we're moving away from EasyApache as the supported method to install Apache and PHP, and adopting an RPM and package-based mechanism instead".

    If that's the scope of the change, that doesn't automatically make it good or bad - but it would be helpful to talk about it as what it is. If I've misunderstood, and this truly will be a new version of EasyApache, still recognisably the same family of tools, then please can someone from cPanel spell out what I've missed.

    We can all see some big advantages to an RPM-based installation, but also some major things get lost; as @eva2000 just pointed out, there is (on the face of it) much less scope to customize.

    Surely these systems have to run in parallel until everyone has found ways to do all that they used to do with the new system?

    Sorry, Matt - I never came back to you on this. I wasn't referring so much to mod_jk as the installation of the TomCat system itself, complete with its own separate-port webserver.
     
  11. eva2000

    eva2000 Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    322
    Likes Received:
    10
    Trophy Points:
    18
    Location:
    Brisbane, Australia
    cPanel Access Level:
    Root Administrator
    Twitter:
    Another question is with EA4 being opt-in. Can it be rolled back to EA3 system if there's issues ? Or does that involve a whole WHM/Cpanel reinstall ?
     
  12. diracuser

    diracuser Member

    Joined:
    Oct 22, 2014
    Messages:
    11
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    I agree with eva2000:

    This type of changes we can't apply in productions systems, we need first test it in a clone system.
     
  13. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,461
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Many customizations will still be possible, just done differently. In general these are:

    • If you require compile-time customizations (e.g. different flags for gcc) you'll need to build your own RPMs.
    • If you require a custom PHP extension, or Apache module, that we don't provide. You'll need to build your own RPM (or use apxs to install it)

    We'd like to know which PHP extensions and Apache modules, not already provided via EasyApache 3, do you routinely install. Once we know about those we can give thought to providing those with EasyApache 4.

    We also realize that some of the customizations people do are to work around what we provide with EasyApache 3. For example people commonly use something like all_php5 to install php-fpm. With EasyApache 4, we'll provide php-fpm.

    We still want an interface that is focused exclusively on making it easy to install Apache and PHP. What you're seeing in the screen shots is the more general purpose package management interface.
     
    inetbizo likes this.
  14. JamesOakley

    JamesOakley Well-Known Member

    Joined:
    Apr 15, 2011
    Messages:
    83
    Likes Received:
    2
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    Apache:
    mod_cloudflare
    mod_geoip
    mod_remoteip
    mod_reqtimeout

    PHP (PECL):
    geoip
    memcache-beta
    timezonedb
    uploadprogress
     
  15. eva2000

    eva2000 Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    322
    Likes Received:
    10
    Trophy Points:
    18
    Location:
    Brisbane, Australia
    cPanel Access Level:
    Root Administrator
    Twitter:
    Off the top of my head, PHP PECL wise

    • geoip 1.1.0+
    • igbinary 1.2.1
    • memcached 2.2.0 with libmemcached 1.0.18 using igbinary serializer
    • memcache 3.0.8
    • pcntl
    • apc cache 3.1.15-dev for PHP 5.5+
    • imagick 3.1.2 or 3.2.x latest RC

    general config wise I also add in

    --with-config-file-scan-dir=

    so my customisations can each have their own *.ini file as well as move all php.ini optimisations to their own .ini that survive updates or php.ini changes.
     
  16. MattDees

    MattDees cPanel Product Owner
    Staff Member

    Joined:
    Apr 29, 2005
    Messages:
    417
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    Thanks for all the responses, these sorts of discussion

    I'll be clear, this is not the same family tools in the sense that the codebases are related, it provides a similar feature set in the sense that it makes for easy selection of apache & php packages and providing for the ability to do the sort of customizations that were allowed in EA3 via standard tools (RPM, yum, mock, etc)

    Providing manual changes will still be possible by forking our spec files and compiling your own RPMs and placing them into your own yum repo. We will document this process - it's not terribly difficult and much easier than EA3 optmods (especially since the toolchain is extensively documented).


    There is always the potential for breakage when performing this type of migration - also why this will be an opt-in process at first so we can start the process. If you have any idea of the sort of issues you encountered in migration, I'd like to hear about them so that we can prepare accordingly. Sometimes these issues are as simple as using an extra module in apache (mod_access_compat, for example) however it's hard for me to comment on this without specifics.

    There will be a single PHP DSO per version, this is a limitation of PHP and the zend framework itself. Other than that, you can expect higher ram usage due to more binaries being in memory.

    While the ability to switch back and forth will certainly exist we haven't decided if we are going to build the ability to move back to EA3 into the UI migration tools. The main concern here is about when people move to EA4, make changes and then move back and the expectation that their changes will persist. Ensuring that end-users vhosts are in place between versions isn't an issue (as that is just a matter of running /scripts/rebuildhttpdconf) however providing a seemless switch between the two is a point of concern.

    We'll certainly provide information on how to do these steps manually at the very minimum.
     
  17. briansol

    briansol Active Member

    Joined:
    Oct 31, 2007
    Messages:
    35
    Likes Received:
    1
    Trophy Points:
    6
    Location:
    ct
    How would things like xcache that require php.ini changes be effected? I have struggled with upgrading php version through EA in the past because it would immediately make my xcache build mis-matched.
     
  18. cPJacob

    cPJacob cPanel Product Owner
    Staff Member

    Joined:
    May 2, 2014
    Messages:
    510
    Likes Received:
    66
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    Items like this that require adjustment of files after the installation of the RPM would likely be handled by pre and post scripts within the RPM itself. However, this hasn't been fully defined yet, so this might change.
     
  19. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,130
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    Not sure if I understood:
    • Only one of the installed PHP versions will be able to run as DSO?
    • Or if you install, by example, PHP 5.3 and 5.4 you can set 5.3 to be DSO and 5.4 to use fastcgi? (beisdes that, I know it could use tons of RAM, and the UI should warn about that)
     
  20. myusername

    myusername Well-Known Member
    PartnerNOC

    Joined:
    Mar 6, 2003
    Messages:
    691
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    chown -R us.*yourbase*
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    I'd like to request support for different versions of PHP 'per directory' in each account, because that's going to be the next thing people ask for. Since you are in the same area working on code for different PHP versions per account, maybe now would be a good time to just tackle both issues.

    The reason for this request is of course that some people might have one section of their site that requires an old PHP while the rest of the site would be fine running the latest.

    I would imagine a UI in cPanel similar to the way that the password protection thing works, where a list of dirs is presented on screen and the user can click on those to set an override PHP version from the account's default.
     
Loading...

Share This Page