EasyApache4 Announcement

[cPanelKenneth]

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)

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.

 

[Kent Brockman]

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 :D

 

[sparek-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.

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.

 

[eva2000]

+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 ?

 

[nospa]

what about php 5.2 - I use it on many servers for many clinets, will it be available as custom mod?

 

[HostCenter IL]

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.

 

[JacobPerkins]

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.

 

[JacobPerkins]

+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!

 

[WebJIVE]

@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..

 

[sparek-3]

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.

 

[WebJIVE]

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.

 

[sparek-3]

I'm also probably one of those old crabby men that doesn't take well to change. The idea of having a clustering system, might work. But I also kind of developed my own system that I've been using for years that's tailored specifically to me, so I like it better. The 200 or so servers I manage, there's probably 4 or 5 different subsets, so they're not all identical. But my system allows me to manage these accordingly.

I think you did key in on a part. It seems like cPanel/WHM is being geared more towards smaller hosting companies, companies that don't have a lot of servers. Again, to use my MaxClients example, modifying the MaxClients on 3 servers through the WHM wouldn't be a huge issue. Probably would take you longer than 30 seconds, but maybe 5 minutes total? And that's fine for that amount of servers. But when you scale this to larger numbers, it just doesn't work. That's why I like being able to do as much as possible from the command line. I realize I'm in a minority there, but when you deal with a lot of servers, you learn to use the command line a lot more.

 

[WebJIVE]

I think you did key in on a part. It seems like cPanel/WHM is being geared more towards smaller hosting companies, companies that don't have a lot of servers.

Not sure this is so true. GoDaddy and Hostgator both use cPanel exclusively now. GoDaddy is sundowning their home-grown system in favor of cPanel. If you sign up for a new hosting account with them, it's a cPanel system.

 

[sparek-3]

Oh, I'm sure large companies use cPanel.

It just seems to me like cPanel is developing new tools and applications that are more geared towards web hosting companies that have 2 or 3 servers instead of 100s or 1000s. cPanel's leaving the command-line structure behind, gearing more towards the WHM for control. Meaning you have to log into the WHM to configure something. I'm not really in favor of this (but again, I am in a minority).

GoDaddy probably has a few people that are like me that can function on the command-line and operate. But I would also venture a guess that GoDaddy has more than one server admin managing all of their servers. 200 servers with 50 server admins, that's 4 servers apiece that has to log in and make a MaxClients change. That's doable.

 

[WebJIVE]

It just seems to me like cPanel is developing new tools and applications that are more geared towards web hosting companies that have 2 or 3 servers instead of 100s or 1000s.

Not sure I agree with that one. For instance, GoDaddy is slightly behind Yahoo in server count and Yahoo has 100,000 servers so, automation is paramount and you can't have admins logging into that many servers to performa cmd line functions. Microsoft is at 1m servers with all their offerings.

 

[sparek-3]

Well, I really don't think you can bring Yahoo, GoDaddy, Google, Microsoft into this conversation. That's an apples and oranges comparision.

Sure those companies may be using cPanel, they may be using a ton of other tools, but look at the capital they are bringing in. When you're calculating your gross income in the millions if not billions of dollars, that's a far, far, far cry from web hosting companies that, if lucky, bring in 100K-300K dollars a year. Those companies can afford to hire the personnel needed to manage. They may have a team (not just a single person) that deals only with EasyApache and it's configuration, that is the only thing they deal with. They don't answer support questions, they don't deal with other aspects, just Apache or what EasyApache offers.

I'm sure they have people there that are a lot smarter than I am, and have built distribution systems for deploying changes, a lot better than I have.

cPanel (this is just my opinion) seems to have geared their new applications towards the mom and pop web hosting companies that sprout up every year that may run all of their hosting accounts on a single server or a handful of servers. There's nothing stopping large corporations like GoDaddy or Yahoo from using cPanel, but they have unimaginable resources where they can customize the deployment for themselves. It's that middling area, that's where I would put myself and the company I work for, that's kind of left in the dust. Too big to be a mom and pop web hosting company, but not big enough to be a GoDaddy or Yahoo.

 

[kevinlevin]

It is absolutely critical a proven and heavily tested working migration EA3 (Apache 2.2)-->EA4 (Apache 2.4) tool (or a migration description) to be provided since the following scenario is absolutely possible:

A working EA3 Apache 2.2 environment will immediately stop working after EA4 Apache 2.4 migration.
The majority of the providers are not yet fully migrated to Apache 2.4 for various of reasons.
The only available alternative would be to stay with EA3 Apache 2.2 but not updating it since it will become depricated sooner or later.

Theoretically, it should be easier if first the following migration can be made automatic:

EA3 (Apache 2.2) --> EA3 (Apache 2.4)

After that:

EA3(Apache 2.4) ---> EA4 (Apache 2.4)

A very important thing here is the PHP handler - Cpanel should officially choose the most stable and recommended php handler for the new setup --> EA4.

Why is important?

Because of the different ways the PHP handlers works - including but not limited to: .htaccess directives, custom php.ini files, directory and file permissions etc.

What we have at the moment:

suPHP ---> slow, almost depricated and not updated, not working with opcache accelerators,
DSO --> not suitable for security reasons (not working with Cloudlinux as well),
mod_ruid2 --> far from stable, most annoying issue is with the mod_security (yes, not fixed yet, I have tested it myself a week ago)
fcgid --> most suitable option - compatible with Cloudlinux.

 

[cPanelKenneth]

Theoretically, it should be easier if first the following migration can be made automatic:

EA3 (Apache 2.2) --> EA3 (Apache 2.4)

EasyApache 3 will already convert from Apache 2.2 to Apache 2.4. If you encounter problems with the conversion, we'd love to know about them, so we can fix them. Please file those in a new thread, so we can keep this one focused on EasyApache 4.

Thank you.

 

[cPanelKenneth]

Oh, I'm sure large companies use cPanel.

It just seems to me like cPanel is developing new tools and applications that are more geared towards web hosting companies that have 2 or 3 servers instead of 100s or 1000s. cPanel's leaving the command-line structure behind, gearing more towards the WHM for control. Meaning you have to log into the WHM to configure something. I'm not really in favor of this (but again, I am in a minority).

GoDaddy probably has a few people that are like me that can function on the command-line and operate. But I would also venture a guess that GoDaddy has more than one server admin managing all of their servers. 200 servers with 50 server admins, that's 4 servers apiece that has to log in and make a MaxClients change. That's doable.

We tend to favor making changes either in the GUI, or via the API.

The command line, in recent years, has been neglected by a number of features and enhancements. While having API calls for the new functionality helps, it's not exactly a replacement for command line utilities. To improve this part of our software, we've begun requiring new features and enhancements make it easier for large scale automation. Command line utilities, documentation on configuration files, documentation on templates, and similar things are what you should start seeing soon to help here.

 

[sparek-3]

[Probably getting a bit off-topic for this thread...]

This has kind of been my observation as well. Granted, you may have more stuff in the API now, I never delved too deeply into that. But CLI utilities have been sorely lacking in cPanel for quite a few years now.

I suppose having a more robust API might help. But in order to use the API, something has to be written and then made available to perform that function from the API. With CLI, if the scripts and commands are available, a shell script can be made to perform that action (such as parking a domain name from the command line by running /usr/local/cpanel/whostmgr/bin/whostmgr directly). By forcing a GUI interface or API, you (cPanel developers) can certainly control more of the behavior, but it takes flexibility away from server admins.

Forcing WHM or other GUIs for certain tasks can work for small scale hosts. But large scale hosts, even with 10 or 20 servers, it's not that feasible to log into that many WHM or GUIs to make changes. I suppose the API could be used and that may be the way you decide to go with this. But I would like to see greater attention paid to being able to automate or perform tasks in an "unattended" (server admin doesn't have to be there clicking on something) capacity.