EasyApache 4
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Karl Fleming
  2. Tuesday, 13 January 2015
  3.  Subscribe via email
Upcomming EasyApache 4 Announcement
Rate this post:
  1. 06.10.2016 13:10:20
  2. # 81
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
Hi Igor,

We found a number of websites that used embedded php in html and had added
AddHandler application/x-httpd-php5 .html .htm

into their htaccess files

After the conversion to EA4, most of these sites just attempted a file download in a browser, or at best, were missing the php controlled items like menus

We changed the code in the htaccess files to
AddHandler application/x-httpd-ea-php56 .html .htm

which seemed to fix everything, but maybe there is a better way (we were most concerned at getting sites back on line with minimum down-time)
  1. 06.10.2016 13:10:51
  2. # 82
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
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.
  1. 06.10.2016 14:10:11
  2. # 83
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
From the time I spent in the development of a well known php program, anything that is 'left over' in an attempt to fix a legacy compatibility, gets forgotten and comes back to bite you at some later stage.

Personally, and I do understand that I don't have to deal with possibly thousands of broken sites, unless one can have a clear road-map of temporary fixs that will be positively removed in a pre-defined future  release - I would rather that nothing of the 'old' is preserved and one has a clean fresh platform.

I hate change - it makes me worry and ruins my appetite, but nevertheless, we need to progress forward (so we are told) and embrace new things !!

I do wonder if much of what we are seeing is change for changes sake, followed by clever marketing to convince us that we now can't live without a new  "whatever" that we didn't even know existed, or that we desperately needed it. Life used to be much simpler before the internet :D
  1. 07.10.2016 13:10:37
  2. # 84
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
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, I'm running mod_lsapi serverwide.     I don't believe I have any AddHandler lines in customer .htaccess files but certainly am going to check.   In my case, I'll 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 I'm ready to try things out.   If I do, I'll report my experience as well.

Mike
  1. 07.10.2016 13:10:29
  2. # 85
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
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\'t it just point to the default PHP version on that account like it does with EA3 ?

We\'re 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\'t see the point of migrating until the last moment.

We don\'t 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.
  1. 07.10.2016 13:10:55
  2. # 86
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
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 isn't 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 it's data from the modsec database, but it would seem that the data isn't 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 couldn't find the solution the penguin way :( (need emoji for 'I need a large scotch')
  1. 09.10.2016 11:10:01
  2. # 87
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
I've 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 isn't 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 can't 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 didn't 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 doesn't 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, it'll 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 didn't 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 don't 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 isn't 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
  1. 10.10.2016 01:10:26
  2. # 88
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
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 isn't 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 system's "native PHP" was using SuPHP.   So when the EA4 conversion was completed, the MultiPHP Handler was set to SuPHP.    I would have thought it wouldn't matter, but apparently it does.   mod_lsapi wouldn't 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 don't know if this is by design, or if this is a bug.   I'm 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 didn't 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 I'll 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, I'm not going to run across any major issues.   I'll 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.    I'll 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
  1. 10.10.2016 07:10:16
  2. # 89
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
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/display/EA4/Introduction+to+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.
  1. 10.10.2016 09:10:50
  2. # 90
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
When I did the conversion, I definitely used

sh cloudlinux_ea3_to_ea4 --convert --mod_lsapi --altphp

At this time I don't 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 didn't 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.   I'm 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.  I'd 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
  1. 12.10.2016 04:10:45
  2. # 91
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
The above issues are fixed in latest beta package, just released: https://www.cloudlinux.com/cloudlinux-os-blog/entry/beta-mod-lsapi-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
  1. 27.10.2016 10:10:55
  2. # 92
Jon Accepted Answer
Posts: 3
Joined: 27.10.2016
0
Votes
Undo
Hi,

I'm 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 haven't 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?
  1. 27.10.2016 12:10:02
  2. # 93
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
The instructions I used were from [url]http://docs.cloudlinux.com/index.html?cpanel_easyapache_4.html[/url]

Specifically,

  • I first ensured that no user was using a \'native\' PHP version in LVE Manager, and that indeed, the native option had been disable in the Selector tab
  • I then logged into a root terminal and ran the command
    cd ~; wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4; sh cloudlinux_ea3_to_ea4 --convert
  • Follow the instructions :D
  1. 27.10.2016 13:10:07
  2. # 94
Ryan Accepted Answer
Posts: 22
Joined: 18.10.2016
0
Votes
Undo
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 it's taken so long to perfect it.  Personally, I'm glad they didn't 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 I'm 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 I'm reading here, EA4 should work fine with alt-php and that would allow for php 5.3.  If I'm 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.
  1. 27.10.2016 13:10:53
  2. # 95
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
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 it\'s 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\'t 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.
  1. 27.10.2016 13:10:39
  2. # 96
Jon Accepted Answer
Posts: 3
Joined: 27.10.2016
0
Votes
Undo
Hi Karl,


[quote]I first ensured that no user was using a \'native\' PHP version in LVE Manager, and that indeed, the native option had been disable in the Selector tab[/quote]

[color=#666666]I\'m in the \'Selecctor Tab\' now and the default PHP version is 5.6 (native) at the moment. I can\'t figure out how to check a users PHP version, how/where do I this? There is no \'Native\' tick box in my screen.
[/color]


[QUOTE]I then logged into a root terminal and ran the command[/QUOTE]


Thanks for confirming the command.
  1. 27.10.2016 14:10:43
  2. # 97
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
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
  1. 27.10.2016 15:10:47
  2. # 98
Jon Accepted Answer
Posts: 3
Joined: 27.10.2016
0
Votes
Undo
Great thank you for your help! I have upgraded [php 7] 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\'t find ionCube 7?
How can I fix this?
  1. 29.10.2016 09:10:03
  2. # 99
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
If you are using CloudLinux alt-php, log into the cPanel for that user, go to the Select PHP Version tools and check the ioncube_loader extension, and save the extension set.

If you do not see the ioncube_loader extension, log into a root terminal and run
yum groupinstall alt-php
and that should install all the missing extensions.

If you are using the cPanel PHP Selector ...... I have no idea !! :(
  1. 10.12.2016 17:12:50
  2. # 100
John Accepted Answer
Posts: 1
Joined: 10.12.2016
0
Votes
Undo
How long does the conversion from ea3 to ea4 take?

Will apache be down during the conversion?

thx


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.