EasyApache 4

[mtindor]

Karl,

Thank you for being one of the guinea pigs, and more importantly thank you for actually posting your EA3-->EA4 conversion experience. That sounds hopeful to me. I might actually try it on one of my servers over the weekend.

On all my servers, Im running mod_lsapi serverwide. I dont believe I have any AddHandler lines in customer .htaccess files but certainly am going to check. In my case, Ill have to make sure that the appropriate line in lsapi.conf is uncommented after I switch so that it is using mod_lsapi like I want. When i tested this on a machine in the past month, no matter what profile I chose it would not actually enable mod_lsapi (meaning it would not edit the lsapi.conf file to uncomment the line and make mod_lsapi work serverwide).

Still a lot of things on my checklist, but based upon your experience I think Im ready to try things out. If I do, Ill report my experience as well.

Mike

[clm]

> Thank you. I guess old handler is gone. Not sure what is better - preserve old handler -> but what to point it to, or deal with manual changes.

Can it just point to the default PHP version on that account like it does with EA3 ?

We
e not looking forward to migrating to EA4. The only new feature it brings to cloudlinux is faster install times of the default PHP/Apache version. We run CloudLinux and LiteSpeed and don see the point of migrating until the last moment.

We don want things that worked before to not work. We ourselves sometimes use that line when editing a simple website so we can add php includes inside existing html files.

We will disable as many EA4 features as possible when we have to make the move, and stick to PHP Selector.

[karl]

As an update to my adventures, I did discover some peculiarities with the WHM display of the Home » Security Center »ModSecurity™ Tools » Hits List

Mod sec appears to be working in that:

* I can trigger mod sec events, and they are correctly logged in the Apache error log and in the mod sec audit log
* Triggered mod sec events seem to be correctly redirecting or denying access
* LFD is reading the logs and correctly banning persistent offenders.

What isnt working is the actual display of Home » Security Center »ModSecurity™ Tools » Hits List
The last entry is just before I converted to EA4, and is reflected as the last entry in the database modsec, table hits
I am guessing the Hits List display gathers its data from the modsec database, but it would seem that the data isnt being written to the database any longer.

After doing absolutely everything I could think of to no avail, I resorted to a server reboot. Now there was nothing to indicate that a server reboot would achieve anything, everything seemed to be working except the mod sec display in WHM, I restarted every daemon I could, and cPanel itself, and the /usr/bin/needs-restarting script returned nothing but, nevertheless, the ModSecurity™ Tools » Hits List started working after the reboot.

I really object, on principle, to having to resort to reboots to solve problems, I got rid of winblows on all my servers and desktops some 15 years ago, and even have kernelcare on my servers, so I feel somewhat betrayed by having to resort to a reboot to fix anything.

Nevertheless - it DID fix the issue (mutter, mutter, grumble) - so I guess the moral of this story is:
"When all else fails - reboot and hope for the best"

Now I have to go and worry why I needed to resort to a reboot and couldnt find the solution the penguin way (need emoji for I need a large scotch)

[mtindor]

Ive got a CL6 server running WHM 58 with CageFS/PHP Selector / EA3 / serverwide mod_lsapi. This had lots of production sites on it, all of which I had moved off. So the machine is empty [no customer websites].

I decided to do an EA3-->EA4 conversion. At some point it UNinstalls mod_lsapi (presumably because it is going to install ea-apache24-mod_lsapi).

It got to the point where it installed ea-apache24-mod_lsapi, and appears to have installed it successfully. But near the end of the EA3-->EA4 conversion process I see:

ESC[1;32mhttpd restarted successfully.ESC[0m
/usr/sbin/apachectl is already updated.

!!!! /etc/yum/universal-hooks/posttrans/cp_clear_packman_cache is not executable
^M Verifying : ea-apache24-mod_lsapi-1.0-7.el6.cloudlinux.x86_64 1/1

Installed:
ea-apache24-mod_lsapi.x86_64 0:1.0-7.el6.cloudlinux

Complete!
cat: /usr/local/apache/conf/conf.d/lsapi.conf: No such file or directory/usr/share/lve/modlscapi/user/switch_lsapi: line 253: /usr/local/apache/conf/conf.d/lsapi.conf.tmp: No such file or directory

(I have confirmed that there is no longer a /usr/local/apache/conf/conf.d/lsapi.conf* -- in fact it removed /usr/local/apache/conf/conf.d directory completely at some point during the EA3-->EA4 conversion. So at this time mod_lsapi isnt active in EA)

SUPHP deteceted
patching file /var/cpanel/templates/apache2_4/ssl_vhost.default
Hunk #1 FAILED at 59.
1 out of 1 hunk FAILED -- saving rejects to file /var/cpanel/templates/apache2_4/ssl_vhost.default.rej
patching file /var/cpanel/templates/apache2_4/vhost.default
Built /etc/apache2/conf/httpd.conf OK
Reconfiguration completed
ESC[92mInstruction: ESC[94mhttp://docs.cloudlinux.com/index.html?apache_mod_lsapi.htmlESC[0m

Begin CageFS skeleton updating
command: /usr/sbin/cagefsctl --create-mp ended
command: /usr/sbin/cagefsctl --force-update ended
command: /usr/sbin/cagefsctl --remount-all ended

Check for RUID and install suexec if needed
Loaded plugins: fastestmirror, rhnplugin, security, tsflags, universal-hooks
Setting up Install Process
Loading mirror speeds from cached hostfile
* EA4: 216.14.113.158
* cloudlinux-x86_64-server-6: xmlrpc.cln.cloudlinux.com
Package 1:ea-apache24-mod_suexec-2.4.23-3.el6.cloudlinux.x86_64 already installed and latest version
Nothing to do

Loaded plugins: fastestmirror, rhnplugin, security, tsflags, universal-hooks
Setting up Install Process
Loading mirror speeds from cached hostfile
* EA4: 216.14.113.158
* cloudlinux-x86_64-server-6: xmlrpc.cln.cloudlinux.com
Package 1:ea-apache24-mod_suexec-2.4.23-3.el6.cloudlinux.x86_64 already installed and latest version
Nothing to do

-------------------------------------------
So I tried a yum remove ea-apache24-mod_lsapi and then a yum install ea-apache24-mod_lsapi, and this did not fix the problem. My /conf.d directory is gone, along with /conf.d/lsapi.conf, so apparently it cant enable serverwide mod_lsapi.

If I start up Apache, the default Apache appears to be using mod_lsapi because it shows the mod_lsapi startup info in /usr/local/apache/logs/error_log. But, the website I have on this server for testing is using CGI/FastCGI when I check phpinfo under Server API

Server API CGI/FastCGI

So, to me there is some issue with the mod_lsapi installation. mod_lsapi didnt work on a fresh CL / cPanel box when I chose an Apache profile with mod_lsapi -- I had to go in and manually uncomment a line in the lsapi.conf. On this server, on which I did an EA3-->EA4 conversion, the conf.d directory is totally gone, and thus it doesnt load any lsapi.conf file to enable the serverwide mod_lsapi.

I suspect if I recreate conf.d and grab an lsapi.conf from another server, itll probably work. I shall test that.

Hmm, creating /usr/local/apache/conf/conf.d and adding lsapi.conf to that directory with proper config info, it still does not enable mod_lsapi serverwide after i restart Apache.

In summary:

During an EA3-EA4 conversion:

1. mod_lsapi is not avaialble / being used serverwide like it should be

ea-apache24-mod_lsapi is installed.

2. /usr/local/apache/conf/conf.d directory was deleted

which includes /usr/local/apache/conf/conf.d/lsapi.conf

creating the conf.d directory and adding a proper lsapi.conf file to it and restarting Apache didnt fix it.

3. When I removed ea-apache24-mod_lsapi and reinstalled it, I saw references to:

httpd restarted successfully.
/usr/sbin/apachectl is already updated.
!!!! /etc/yum/universal-hooks/posttrans/cp_clear_packman_cache is not executable
Verifying : ea-apache24-mod_lsapi-1.0-7.el6.cloudlinux.x86_64 1/1

Installed:
ea-apache24-mod_lsapi.x86_64 0:1.0-7.el6.cloudlinux

Complete!

I dont know if the fact that that hook is not executable has anythign to do with it or not.

At any rate, the conversion seemed to have went well [although I had no sites on it when i converted] EXCEPT that mod_lsapi isnt running serverwide. And, of course my totally convoluted custom mod_security setup is totally broken, which the conversion process did inform me that I would have to manually resolve.

Mike

[mtindor]

In followup of my post directly above, it turns out that almost everything I had an issue with was of my own doing.

Remember -- EasyApache4 uses /etc/httpd/conf, not /usr/local/apache/conf (this matters, see below)

As it turns out, the fact that /etc/httpd/conf/conf.d had been removed during the EA3-EA4 conversion process isnt important. The only thing in conf.d was lsapi.conf. And, it was moved to /etc/httpd/conf/conf.d. After Vladislav fr om CL told me this, I did recall reading a long time ago that with EA4 the folder structure was going to change. So the missing /etc/httpd/conf/conf.d/lsapi.conf was a non-issue.

In the end, getting mod_lsapi functioning was simply a matter of going into the MultiPHP Manager and changing the MultiPHP Handler. The available handlers are different based upon what profile you installed. In my case, the MultiPHP handler options were:

CGI
none
SuPHP

Well, my EA3 systems "native PHP" was using SuPHP. So when the EA4 conversion was completed, the MultiPHP Handler was set to SuPHP. I would have thought it wouldnt matter, but apparently it does. mod_lsapi wouldnt activate with the MultiPHP Handler set to SuPHP. As soon as I switched it to CGI, mod_lsapi on my hosting accounts was working immediately.

I dont know if this is by design, or if this is a bug. Im awaiting clarification from CL regarding their thoughts.

In summary:

(pre-conversion machine was a 5-year-old CL6 + WHM 58 + CageFS + PHP Selector + serverwide mod_lsapi box)

1. I didnt get any errors during the EA3-->EA4 conversion

The process seemed to go quite smooth. Aside from the "cat: /usr/local/apache/conf/conf.d/lsapi.conf: No such file or directory/usr/share/lve/modlscapi/user/switch_lsapi: line 253: /usr/local/apache/conf/conf.d/lsapi.conf.tmp: No such file or directory" verbage that the convertor spit out during the conversion process, everything was functional (except mod_lsapi) at the end of the conversion. Had any sites existed on there, they would have been using PHP Selector by default and would have worked just like they did pre-migration. Because suPHP was the handler I had set in EA3, that is the handler that was in use by default in EA4 for the system PHP version (which was PHP 5.6).

2. mod_lsapi not working

As mentioned above, the fix for this was for me to switch the php handler of the system PHP version (PHP 5.6) in MultiPHP Manager from SuPHP. The missing /usr/local/apache/conf/conf.d/lsapi.conf was simply a case wh ere it was moved to /etc/httpd/conf/conf.d. It was all there, and mod_lsapi was enabled [from a configuration standpoint]. I just had to change the MultiPHP Handler to CGI for mod_lsapi to be put in use on the active hosting accounts.

3. My modsecurity installation needs set up again

I use Atomicorp rulesets and have for years. i always installed this manually. So as part of the conversion, it totally ignored my existing modsecurity setup. Modsecurity is running right now, but without a ruleset. So Ill have to go back in and set this up.

Seemed pretty straightforward. Even though I did this on a empty box, I did copy an account over to it for testing and it properly retained its alt-PHP version and settings from the server it was pulled from and functioned fine. I have a feeling that even with a couple hundred accounts on the server, Im not going to run across any major issues. Ill just simply remember to set an appropriate MultiPHP Handler so that mod_lsapi works and then reinstall my modsecurity ruleset.

Next step (probably next weekend) will be for me to do this on a server with a couple hundred accounts. Ill report back findings then.

In the meantime, hopefully the CL crew can clarify for us [on her, in documentation, somewhere] if CGI must always be the MultiPHP Handler if mod_lsapi is to work, or if this is some sort of bug.

Mike

[bogdan.sh]

Hi,

I have personally saw large number of migrations EA3 to EA4, with and without mod_lsapi. Indeed, first conversions were not flawless but from a ~month or so (when we called EA4 stable) they are good. Now, the working directory for apache with EasyApache 4 is /etc/apache2/ : https://documentation.cpanel.net/dis...o+EasyApache+4

or you may get it this way:

# httpd -V | grep HTTPD_ROOT

-D HTTPD_ROOT="/etc/apache2"

And lsapi config file should be existing in /etc/apache2/conf.d/ directory.
As of now please confirm you used followinc command to convert:

sh cloudlinux_ea3_to_ea4 --convert --mod_lsapi --altphp

If --mod_lsapi key was not there then easiest way after migration was - install ea-apache24-mod_lsapi package, and run two commants (setup and enable global):

/usr/bin/switch_mod_lsapi --setup

/usr/bin/switch_mod_lsapi --enable-global

service httpd restart

As of now cpanel do not allow adding 3rd party handlers for MultiPHP , so mod_lsapi should be enabled from command line with above commands (or it will be done automatically if --mod_lsapi key used with conversion script). Changing handlers to CGI is not needed, I suppose it triggered something and restart apache after that. Mod_lsapi works with both handlers in cpanel, suphp and cgi.

The option I need to check is the actual error about reading /usr/local/apache/conf/conf.d/lsapi.conf . Will check it a bit later.

[mtindor]

When I did the conversion, I definitely used

> sh cloudlinux_ea3_to_ea4 --convert --mod_lsapi --altphp

At this time I dont have any issue with the Apache working directory of /etc/apache2. I simply had forgotten that the working directory would change. (and I apologize for erroneously referencing the working directory as /etc/httpd above).

Even though I ran the converter with the options above, it didnt make mod_lsapi function serverwide until I changed the MultiPHP handler from SuPHP to CGI.

After the fact [this morning], I did "manually" attempt to enable mod_lsapi by running:

/usr/bin/switch_mod_lsapi --setup

/usr/bin/switch_mod_lsapi --enable-global

service httpd restart

After I did this, it behaved very differently:

1. mod_lsapi is enabled serverwide
2. Changing MultiPHP handler to/from SuPHP to CGI makes no difference
3. BUT:

Now PHP Selector is not operational and it is using the System PHP version from MultiPHP

(this server has ONE version of PHP installed in MultiPHP, PHP 5.6). PHP 5.6 is set as the System PHP. All domains under the migrated account are set to "inherit"

So, PHP Selector / alt-php should be functioning but are not. Instead the hosting account is using the MultiPHP version. This should not be happening. And this only happeneed after manually running the switch_mod_lsapi commands.

I can tell the language barrier is difficult. The way I explain things is not clear, and I apologize for that. Im doing the best I can.

I have an open ticket with CL, and have provided information to access the server as well as the test hosting account inside that ticket. Id ask that somebody take a further look.

a. bore running switch_mod_lsapi, PHP Selector / alt-php was active for the hosted account and mod_lsapi worked as long as MultiPHP handler was set to CGI

b. After running switch_mod_lsapi, PHP Selector / alt-php is not active for the hosted account and mod_lsapi works serverwide indepedent of the MultiPHP handler setting

c. What should be happening is

* PHP Selector / alt-php should be functioning for the hosted account
* mod_lsapi shoudl work serverwide independent of MultiPHP handler settings

[bogdan.sh]

The above issues are fixed in latest beta package, just released: https://www.cloudlinux.com/cloudlinu...pi-updated-1-9

We will try to move it from beta to stable really fast, however as of now after converting servers to EA4 if mod_lsapi and PHP-Selector used you have to update lsapi to beta also:

yum update liblsapi liblsapi-devel --enablerepo=cloudlinux-updates-testing

yum update ea-apache24-mod_lsapi --enablerepo=cl-ea4-testing

service httpd restart

[accounts]

Hi,

Im pretty certain I have missed something as I cannot find the instructions on how to migrate properly.

- Cloud Linux 6.8
- WHM 60
- EasyApache 3 and 4

WHM has a migration tool EasyApache 4 Migration but my server provider advised against using it.

The warnings that I receive at the start (I havent gone past this section):

Pre-flight check result.

Cpanel Migrate Blocker (Cpanel)

Cpanel evaluates known issues such as network connectivty

- Warning: “Cpanel::Easy::PHP5::MailHeaders” ignored since it does not have an RPM.
- Warning: “Cpanel::Easy::Apache::Fileprotect” ignored since it does not have an RPM.
- Warning: “Cpanel::Easy::Apache::Access” ignored since it does not have an RPM.

Do you have any advice?

[karl]

The instructions I used were from https://<a href="http://docs.cloudli...che_4.html</a>

Specifically,

1. I first ensured that no user was using a
   ative PHP version in LVE Manager, and that indeed, the native option had been disable in the Selector tab
2. I then logged into a root terminal and ran the commandcd ~; wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4; sh cloudlinux_ea3_to_ea4 --convert
3. Follow the instructions

[noyearzero]

Wow it looks like this has been quite a ride getting this all figured out. I appreciate all the work the CL people have put in on this. I know how tough it can be to have to rely on an outside company and deal with all their quirks. Plus needing to know all the millions of ways their customers use and configure their product is no small task. So I can understand why its taken so long to perfect it. Personally, Im glad they didnt rush it out and took the time to get it done as well as possible.

Luckily for me I am able to get this set up right now before we have real accounts on the servers. It seems like most of the bugs have been worked out, so Im pretty confident things will go smoothly. However I do want to clarify a few things regarding alt-php and EA4....

We have 2 servers, 1 that needs to support php 5.3 and that will start out at php 7.0. The guys at our datacenter strongly recommended not going to EA4 a little over a month ago. If I understood right, they made it sound like it was not even possible for our server that needs to support 5.3. But based on what Im reading here, EA4 should work fine with alt-php and that would allow for php 5.3. If Im wrong on that can someone correct me?

Then for our new server, is there any advantage to starting it out with alt-php if it will be all new accounts that are php 7? Both servers are pretty standard CL setups: CL 6.8, cageFS, mod_lsapi.

[clm]

If I were you I would disable EA4 PHP version selector and EA4 PHP.ini editor in the feature manager and disable natve PHP in PHP Selector.

Both alt-php and EA4 and work side by side without issues. However its more complicated for users to have both at the same time.
We currently have EA3 + alt-php on our production servers with the native cPanel PHP version disabled so users can only pick alt-php versions.

We are going to wait until the move to EA4 is obligatory as EA4 doesn improve anything rearly, espacially if you disable all EA4 cPanel front end features so your users only have alt-php.

We will only concider reenableing EA4 features if cPanel and Cloudlinux integrate both products so you can use PHP Selector to configure the PHP modules, and options and EA4 tools to select the PHP version of domains.

[accounts]

Hi Karl,

&#91;quote&#93;I first ensured that no user was using a
ative PHP version in LVE Manager, and that indeed, the native option had been disable in the Selector tab&#91;/quote&#93;

Im in the Selecctor Tab now and the default PHP version is 5.6 (native) at the moment. I can figure out how to check a users PHP version, how/where do I this? There is no Native tick box in my screen.


&#91;QUOTE&#93;I then logged into a root terminal and ran the command&#91;/QUOTE&#93;

Thanks for confirming the command.

[karl]

Hi Fusionhost,

See http://docs.cloudlinux.com/index.html?selectorctl.html for instruction about using selectorctl to check each users eg

/usr/bin/selectorctl --help

Or alternately, go through each users cPanel one by one (yawn), and check them in the "Select PHP Version" pages

[accounts]

Great thank you for your help! I have upgraded &#91;php 7&#93; although I have an issue. The response I receive from one of the accounts is:

> Site error: the file /home/####/public_html/####/####/index.php requires the ionCube PHP Loader ioncube_loader_lin_7.0.so to be installed by the website operator. If you are the website operator please use the ionCube Loader Wizard to assist with installation.

But I can find ionCube 7?
How can I fix this?