EasyApache4 Announcement
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:
[LIST]
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.
.vB
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.
.vB
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.
-
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. 0 -
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: [LIST] - 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.
0 -
What's the plan for Tomcat? (Not that I ever understood why it was installed with EasyApache in the first place!)
We will be providing RPMs for mod_jk at some point in the future, currently it is on the bottom of our backlog. 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).
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. What of scripts that currently fire in /scripts/after_apache_make_install or /scripts/posteasyapache (and other similar hook-points)?
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.0 -
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. 0 -
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. 0 -
]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.
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 :) [COLOR="silver">- - - 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?0 -
]This will be an opt-in upgrade at first
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.]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.
At the moment, for me at least, it's just mod_reqtimeout and mod_remoteip from0 -
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 0 -
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? ]We will be providing RPMs for mod_jk at some point in the future, currently it is on the bottom of our backlog.
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.0 -
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 ? 0 -
I agree with eva2000: ] 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
This type of changes we can't apply in productions systems, we need first test it in a clone system.0 -
Many customizations will still be possible, just done differently. In general these are: [list] - 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.
0 -
]We'd like to know which PHP extensions and Apache modules, not already provided via EasyApache 3, do you routinely install.
Apache: mod_cloudflare mod_geoip mod_remoteip mod_reqtimeout PHP (PECL): geoip memcache-beta timezonedb uploadprogress0 -
Off the top of my head, PHP PECL wise [LIST] - 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.
0 -
Thanks for all the responses, these sorts of discussion ]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.
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). [QUOTE=WebJive]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.
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. [QUOTE=KentBrockman]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?
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. [QUOTE=eva2000]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 ?
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.0 -
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. 0 -
]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.
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.0 -
] 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.
Not sure if I understood: [LIST]- 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)
0 -
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. 0 -
]Not sure if I understood: [LIST]
- 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)
It's the latter. Only a single DSO can be in memory at a time (without some trickery). Thus if both PHP 5.3 and 5.4 are installed, you could only select one to run via DSO, the other would use a different handler.0 -
]It's the latter. Only a single DSO can be in memory at a time (without some trickery). Thus if both PHP 5.3 and 5.4 are installed, you could only select one to run via DSO, the other would use a different handler.
Very good. That would require to use DSO and suPHP to save resources... or request a bigger server :) Anyway, good enough to me :D0 -
My 2 cents: Where are the RPMs going to come from? Are they Operating System Level RPMs or cPanel specific RPMs? If they are cPanel specific RPMs, then that means they would still have to pass through cPanel's Quality Assurance? I'm not sure what the gain is from the current system. For example, when a new version of PHP is released, the first people that know about it are the folks over at php.net. If you compile your own PHP, it's a simple process of downloading the new PHP source package, and configure and compile on your server. With the curreny EA3 setup (correct me if I'm wrong) it may take a couple of days for the updated PHP package to make it's way into the EA3 system. Probably doesn't matter a whole lot, but if the new PHP fixes a major security flaw, those couple of days can be a lengthy time. RPMs, even from the OS vendors, can take a while to filter down as well. I would be more interested in an EA4 that controls Apache and JUST Apache. Apache is a fairly mature product, it doesn't change a whole lot. Looking at the past release schedule, Apache 2.4.10 was released on July 19, 2014 and the next release, Apache 2.4.12 was released on January 27, 2014. That's a little over 6 months between releases. PHP on the other hand, has pretty much fallen into a monthly release schedule. PHP 5.4.36 was released on December 18, 2014. PHP 5.4.37 was released on January 22, 2015. PHP upgrades are much more common. I don't think compiling PHP is that much of a hassle. Just save the ./configure line and that pretty much translate straight over from minor version to minor version (5.4.36 to 5.4.37...) Apache modules, probably fall more in line with the Apache schedule. I'm not sure what the release schedule for something like mod_security is, but I don't think its monthly. If you want to release something that allows EA4 to control everything, that's fine. But I would submit that I would rather have more modular control to the system. Being able to install Apache and ONLY Apache, and leaving control of Apache DSO modules to the server admin. If the server admin wants to install mod_security, they can compile it on their own, or if you want to include an RPM for that, that's fine too. If the server admin wants to install mod_cloudflare, they can compile it on their own, or install an included RPM. If the server admin wants to install suphp, they can compile it on their own or install an RPM. If the server admin wants to roll their own PHP, they can do so, or install an RPM. If the server admin wants to install a 3rd party Apache module that isn't listed in EasyApache, they can roll their own and compile it themselves. I understand asking the community for what they "commonly" install, but you can't go around including every tiny module because 1 person wants it. If only 1 person is wanting to install a mod_fakeapachecrash module, then it's a waste of resources (IMHO) for cPanel developers to spend time getting that module included and keeping it maintained in EasyApache. If you have to have specific controls, for example suPHP. The EasyApache system may need to be able to tell cPanel/WHM that suPHP is installed to set the VirtualHost template accordingly (or just allow direct editing of the VirtualHost templates). Then I would submit that having an option of "I will roll my own" as being a configuration option, which will effectively enable it in the EasyApache/cPanel/WHM schematic, but won't actually compile or install it. The admin would be left to install it on their own. i.e.: Do you want to install suPHP? - Yes - No - I will roll my own Which Version of PHP do you want to install? - PHP 5.6.5 - PHP 5.5.21 - PHP 5.4.37 - I will roll my own Configuration Control Would the cPanel/WHM tie into Apache be better served by using an Include for the VirtualHost aspect? I've never really understood the whole distilling system for cPanel's Apache. I come from a background where modifying the configuration files by hand was common. I remember the days when there was no such thing as a Control Panel. If you wanted to increase the Max Clients for Apache, you modified the apache configuration file with a larger Max Clients value. But with cPanel you have to make the change and then distill it, so cPanel can remember that change? Or something like that. It is my understanding that when you create a new account in the WHM or create a new addon or subdomain in the cPanel, that a new VirtualHost is added to the httpd.conf file. So basically, all cPanel/WHM does is add and delete VirtualHosts. Why not just have WHM/cPanel create those VirtualHosts in a secondary file (i.e. /usr/local/apache/conf/includes/virtualhosts.conf) and then in the main httpd.conf file have a line: Include "/usr/local/apache/conf/includes/virtualhosts.conf" This would free up server admins to be able to modify the configuration variables in the httpd.conf file as they see fit. If you want to still have a Tweak Apache place in the WHM, that's fine too, but have those changes saved into a file like /usr/local/apache/conf/includes/whm_apache_tweak.conf) and include it in the httpd.conf file. Basically, cPanel/WHM would never directly touch the httpd.conf file only files that might be included. This way, if someone wants to change a configuration variable that is not settable in the Tweak Apache WHM area, they can do so by directly editing the httpd.conf file or using their own Includes. I get that having Apache controls (and this actually extends into other services, like Exim and PureFTP) within the WHM makes it easier for some people to get a handle of. But it takes control away from server admins that may want a more advanced approach or more control. 0 -
+1 regarding PHP's more frequent releases and need to keep on top of them maybe if you are requiring folks to rebuild rpms for custom or more frequent updates, why not build into whm the tools or scripts to automate the rpm custom build process ? 0 -
what about php 5.2 - I use it on many servers for many clinets, will it be available as custom mod? 0 -
How will the change work vis-a-vis CageFS? For example, if I select user X to have PHP 5.3 in EA4, and that user is in CageFS, will it affect his settings? Will it break them, override them, or not touch them at all because of how CageFS operates? Regarding custom modules, I believe that some of the most common ones are a must. mod_geoip, already mentioned in this thread multiple times, is indispensable, and I'm sure people use many other important ones. In general, I think that it's very important to make the new system as easy as the old one. For example, my company hosts a few dozen VPS customers withough full management but including technical support. So they run cPanel without knowing much about running a server, and very rarely need to talk to us to get support. This is the main strength of cPanel vs. the competition, and in particular the ability to upgrade PHP or install modules for it without knowing anything about packages, is very helpful to many cPanel users. From the screenshots provided it looks like in general, this ability will be preserved for PHP itself, but not necessarily for individual packages. I think this could be a major step backwards if not done correctly. Versatility is important but ease of use is too, hopefully this isn't compromised in EA4. 0 -
I'll answer these questions in line for better readability. ]My 2 cents: Where are the RPMs going to come from? Are they Operating System Level RPMs or cPanel specific RPMs? If they are cPanel specific RPMs, then that means they would still have to pass through cPanel's Quality Assurance? I'm not sure what the gain is from the current system.
RPMs will come from us. They would still be tested via our Quality Assurance as our PHP builds are currently tested.]For example, when a new version of PHP is released, the first people that know about it are the folks over at php.net. If you compile your own PHP, it's a simple process of downloading the new PHP source package, and configure and compile on your server. With the curreny EA3 setup (correct me if I'm wrong) it may take a couple of days for the updated PHP package to make it's way into the EA3 system. Probably doesn't matter a whole lot, but if the new PHP fixes a major security flaw, those couple of days can be a lengthy time. RPMs, even from the OS vendors, can take a while to filter down as well.
Currently, we release new PHP updates within 2 business days of their upstream release. The same will hold true for the new system. RPMs will still be released within that 2 business day cycle.]I would be more interested in an EA4 that controls Apache and JUST Apache. Apache is a fairly mature product, it doesn't change a whole lot. Looking at the past release schedule, Apache 2.4.10 was released on July 19, 2014 and the next release, Apache 2.4.12 was released on January 27, 2014. That's a little over 6 months between releases. PHP on the other hand, has pretty much fallen into a monthly release schedule. PHP 5.4.36 was released on December 18, 2014. PHP 5.4.37 was released on January 22, 2015. PHP upgrades are much more common. I don't think compiling PHP is that much of a hassle. Just save the ./configure line and that pretty much translate straight over from minor version to minor version (5.4.36 to 5.4.37...) Apache modules, probably fall more in line with the Apache schedule. I'm not sure what the release schedule for something like mod_security is, but I don't think its monthly.
Since this system will be yum and RPM based, you will be able to update Apache and PHP separately, together, or however you choose. If you just want to update the Apache RPM, you'll be able to do so without affecting your PHP versions or handlers.]If you want to release something that allows EA4 to control everything, that's fine. But I would submit that I would rather have more modular control to the system. Being able to install Apache and ONLY Apache, and leaving control of Apache DSO modules to the server admin. If the server admin wants to install mod_security, they can compile it on their own, or if you want to include an RPM for that, that's fine too. If the server admin wants to install mod_cloudflare, they can compile it on their own, or install an included RPM. If the server admin wants to install suphp, they can compile it on their own or install an RPM. If the server admin wants to roll their own PHP, they can do so, or install an RPM. If the server admin wants to install a 3rd party Apache module that isn't listed in EasyApache, they can roll their own and compile it themselves. I understand asking the community for what they "commonly" install, but you can't go around including every tiny module because 1 person wants it. If only 1 person is wanting to install a mod_fakeapachecrash module, then it's a waste of resources (IMHO) for cPanel developers to spend time getting that module included and keeping it maintained in EasyApache.
It sounds like the RPM builds will be perfect for you. You'll be able to quickly install what you need, via yum. If you want to install your own RPMs and custom modules, you'll be able to setup a Yum repo and install your modules from there quite easily. If you're not familiar with providing / building RPMs and setting up Yum repositories, we'll be providing documentation for doing that when we release EA4.]If you have to have specific controls, for example suPHP. The EasyApache system may need to be able to tell cPanel/WHM that suPHP is installed to set the VirtualHost template accordingly (or just allow direct editing of the VirtualHost templates). Then I would submit that having an option of "I will roll my own" as being a configuration option, which will effectively enable it in the EasyApache/cPanel/WHM schematic, but won't actually compile or install it. The admin would be left to install it on their own. i.e.: Do you want to install suPHP? - Yes - No - I will roll my own Which Version of PHP do you want to install? - PHP 5.6.5 - PHP 5.5.21 - PHP 5.4.37 - I will roll my own
The RPMs will most likely have post steps that adjust applicable templates to ensure they are available for handler selections. We aren't locking this down at all. You'll have better and more granular control of your Web Stack with EA4.]Configuration Control Would the cPanel/WHM tie into Apache be better served by using an Include for the VirtualHost aspect? I've never really understood the whole distilling system for cPanel's Apache. I come from a background where modifying the configuration files by hand was common. I remember the days when there was no such thing as a Control Panel. If you wanted to increase the Max Clients for Apache, you modified the apache configuration file with a larger Max Clients value. But with cPanel you have to make the change and then distill it, so cPanel can remember that change? Or something like that. It is my understanding that when you create a new account in the WHM or create a new addon or subdomain in the cPanel, that a new VirtualHost is added to the httpd.conf file. So basically, all cPanel/WHM does is add and delete VirtualHosts. Why not just have WHM/cPanel create those VirtualHosts in a secondary file (i.e. /usr/local/apache/conf/includes/virtualhosts.conf) and then in the main httpd.conf file have a line: Include "/usr/local/apache/conf/includes/virtualhosts.conf" This would free up server admins to be able to modify the configuration variables in the httpd.conf file as they see fit. If you want to still have a Tweak Apache place in the WHM, that's fine too, but have those changes saved into a file like /usr/local/apache/conf/includes/whm_apache_tweak.conf) and include it in the httpd.conf file. Basically, cPanel/WHM would never directly touch the httpd.conf file only files that might be included. This way, if someone wants to change a configuration variable that is not settable in the Tweak Apache WHM area, they can do so by directly editing the httpd.conf file or using their own Includes. I get that having Apache controls (and this actually extends into other services, like Exim and PureFTP) within the WHM makes it easier for some people to get a handle of. But it takes control away from server admins that may want a more advanced approach or more control.
We've discussed moving VirtualHosts out of httpd.conf into a conf.d directory and having those slurped in, however we haven't fully made a decision on how these will operate. We have users of cPanel & WHM that put 10k-20k domains on a server, and we want to fully test out the performance aspects of this change before we go any further. All in all, it sounds like you're looking for a very flexible system that will allow you to customize your WebStack to your specifications. I believe EA4 will provide this for you! I look forward to having a proof of concept build out in the next few weeks. If you're not on the Edge mailing list, I'd recommend checking it out. We've been discussing EA4 quite a bit, and once we have our Proof of Concept build out, we'll send it to the Edge list.0 -
]+1 regarding PHP's more frequent releases and need to keep on top of them maybe if you are requiring folks to rebuild rpms for custom or more frequent updates, why not build into whm the tools or scripts to automate the rpm custom build process ?
We'll still be releasing PHP updates within our 2 day SLA. There are no current or future plans to change this release process. We'll absolutely be providing documentation (and possibly small scripts) to assist in building RPMs so you can customize your stack, add patches, etc.]what about php 5.2 - I use it on many servers for many clinets, will it be available as custom mod?
We plan to provide a PHP 5.2 RPM, however it's EOL and currently unsupported by cPanel & WHM.]How will the change work vis-a-vis CageFS? For example, if I select user X to have PHP 5.3 in EA4, and that user is in CageFS, will it affect his settings? Will it break them, override them, or not touch them at all because of how CageFS operates? Regarding custom modules, I believe that some of the most common ones are a must. mod_geoip, already mentioned in this thread multiple times, is indispensable, and I'm sure people use many other important ones. In general, I think that it's very important to make the new system as easy as the old one. For example, my company hosts a few dozen VPS customers withough full management but including technical support. So they run cPanel without knowing much about running a server, and very rarely need to talk to us to get support. This is the main strength of cPanel vs. the competition, and in particular the ability to upgrade PHP or install modules for it without knowing anything about packages, is very helpful to many cPanel users. From the screenshots provided it looks like in general, this ability will be preserved for PHP itself, but not necessarily for individual packages. I think this could be a major step backwards if not done correctly. Versatility is important but ease of use is too, hopefully this isn't compromised in EA4.
We haven't yet discussed CloudLinux vs cPanel Multi-PHP at this time. I don't see both systems being able to be used at once, however I do see cPanel & WHMs Multi-PHP eventually becoming the default. For custom modules, these can easily be installed by running (something like) '# yum install mod_geoip'. Everything will be built from RPMs, and installed as such. We want to make this as flexible and user friendly as possible. I hope this helps answer some of the angles we're moving the EasyApache project into. Thank you all for your great feedback, and I look forward to more!0 -
@sparak-3 ]My 2 cents: Where are the RPMs going to come from? Are they Operating System Level RPMs or cPanel specific RPMs? If they are cPanel specific RPMs, then that means they would still have to pass through cPanel's Quality Assurance? I'm not sure what the gain is from the current system. SNIP.
Please remember a lot of hosting companies don't tweak servers by hand and we're pushing cPanel to automate more so that we can have better clustering with their environment. On the other hand, I understand your point of view as well wanting more granular controls. For most of us, having a clustered predictable environment that matches 75% of the industry makes sense so that it's easy for someone to move their software from another hosting company, to yours. My 2 cents..0 -
]Please remember a lot of hosting companies don't tweak servers by hand and we're pushing cPanel to automate more so that we can have better clustering with their environment.
I do understand that I'm in a very small minority (perhaps a minority of 1?) and as a minority it's hard to make "demands" on how things operate. I would like to have more control of the process, doesn't necessarily mean it will happen, but I thought I would offer my input on the matter. I currently manage a little over 200 servers. Suffice it to say, controlling those servers from the WHM is not very easy for me. The more I can do on the command-line, the better I am. For the most part, command-line system can be put through in an unattended fashion. If I need all servers to match the same basic Apache Configuration, I can simply edit the configuration file and push that configuration file out to all of the other servers. If I need to make a change, I can make that change, and push it out to all of the servers. It is not feasible for me to log into the WHM for each of the 200 servers to make a configuration change. Using the MaxClients configuration parameter as an example. It's easier for me include a set of default values in an Include file that is included in the main httpd.conf file and keep a master copy of that file. If I need to update the MaxClients, update the master file, and push it out to all of the servers. Takes 30 seconds to update 200 servers. If I have to log into each WHM to make the change, it's going to take a lot longer than 30 seconds. I'm probably in a bit of a disconnect with others in that I don't see cPanel as a server management system. To me, cPanel is a server management tool, but it is not (or at least it shouldn't be) a complete server management system. I know that creating VirtualHost, email accounts, database all from inside cPanel/WHM does require some tie in with these services, but I'd prefer that handling to be as minimal as possible (or at least the option to be as minimal as possible). Like the example of cPanel/WHM adding VirtualHosts to the httpd.conf. Is there any other reason any cPanel/WHM process should be touching the httpd.conf file? The tweak Apache settings in the WHM is one area, but this could be made in another Include. But like I said, I know I'm in the minority. Maybe EA4 is going to provide more of this control. It sounds like the developers are at least aware of this.0 -
]I do understand that I'm in a very small minority (perhaps a minority of 1?) and as a minority it's hard to make "demands" on how things operate.
Well put.. :) For me personally, there's not "enough" server management clustering features in WHM, at least not for a viable larger scale hosting operation. While WHM is great for managing our servers (3 and growing) the easy way, when we make a change, we still have to touch all 3, when we should be able to log into a master, make the change and it's propagated to the other servers. Interworx takes a different approach by clustering for balancing. While this may be nice for that market segment, this is expensive operationally for the competitive general hosting environment segment. We'd like to see clustering server management whereby, we control what box a client gets installed to (via WHMCS) but, if we make a configuration change to one server, that config change is rolled to all servers so we don't have to touch every one of them. I see that as the bigger challenge vs clusters for load balancing. There are third party software companies that provide software like this but, they are not targeted for the small hosting companies with less than say 10 servers. They are more geared for hosting companies with 100's or 1000's of boxes like Godaddy, Hostgator and others.0
Please sign in to leave a comment.
Comments
104 comments