Unfortunately, this didn't work for me, and I'm stuck at the "Which PHP version on the target..." question. Nothing I've answered works. For background -- I built a new base system to host ISPConfig (3.1.15p3). It's based on CentOS 8.1, and I installed PHP 7.4 as part of building the system. I also installed PHP 5.6 on the system. I did not build the PHP installations from scratch. I simply did "dnf install php" using the Remi repository. Likewise, I installed PHP 5.6 by saying "dnf install php56". On the system, if I execute "php --version", I get: PHP 7.4.6 (cli) (built: May 12 2020 08:09:15) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.6, Copyright (c), by Zend Technologiesand if I execute "php56 --version", I get: PHP 5.6.40 (cli) (built: May 13 2020 09:37:13) Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies My source ISPConfig server is based on CentOS 6, and has PHP 5.6 installed as the only version. My first migration attempt was made before I had installed PHP 5.6 on the target. When the "Which PHP version..." question came up, I responded "Default" and the migration continued to run, but it ultimately failed with various errors, including complaints about lines containing "php_admin_value" in a section labelled "mod_php enabled". After that, my next attempt started by installing PHP 5.6 on the target server, as described above. My idea was to allow sites to be migrated by using PHP 5.6 on the target server, and then I would see if I could update them to use PHP 7.4 on a case-by-case basis. However, when the "Which PHP version..." question comes up, I can't see anyway to answer the question, other than by typing "Default", which will simply cause the migration to fail. So, after a lot of preamble, we finally get to the crux of the issue -- am I going to have to rip out all of PHP 7.4 from the target, make sure that PHP 5.6 is the only installed version, make sure it is designated as "Default", do the migration, and then add in PHP 7.4? AND, am I going to have to go through the entire custom build approach for both PHP versions in order to get everything to work? And what about the "php_admin_command" entries in the Apache configuration files? They seem to upset Apache, so is the issue a mod_php or php-FPM problem, or are we looking at a "new version of Apache doesn't like such things" problem? Any and all advice appreciated. Cheers Norm
My understanding is ISPConfig is not yet supported officially on CentOS 8. That may be the reason for some of your problems, I guess Migration Toolkit also does not support CentOS 8 yet. When you installed additional PHP versions on the target system, did you configure those in ISPConfig? I have done that on Debian GNU/Linux, and there it is crucial to do the configurations and most importantly to make sure that in the Operating System the default PHP version remains the original, otherwise ISPConfig stops working.
Well, ISPConfig installed without error and seems to be running fine, at least as far as every aspect of the administration web pages. I haven't actually created new clients or sites on the new server, mainly since they would only end up getting overwritten by the migrated data. I can easily try that and see what happens. The default version of PHP in CentOS 8 is PHP 7.2.11. I decided to install 7.4.6 since it was the "latest and greatest", and I didn't think it was worthwhile installing something that was only a point release or two older. I'm beginning to think I may need to do that. I really hate the thought that I might need to rebuild this whole server from scratch, just to get older software installed into a default configuration, especially considering that I still plan to make sure that everything finally ends up as "the latest and greatest". Any other thoughts from anyone?
Wait for Centos 8 to be officially supported by ISPConfig. I believe it is already being tested as we speak. Unless there are very serious problems which put ISPConfig development on hold, I think the next version 3.1.16 should be supporting Centos 8 and Ubuntu 20.04.
The default PHP version of a given OS version should not be changed and ISPConfig does not support that you change it. Always keep the default PHP version. You can use newer and older PHP versions as additional PHP versions in ISPConfig for the websites, but do not change the default PHP version. Besides that, CentOS 8 is not supported yet as mentioned above, so it is not recommended to use it in a production server. Regarding the original problem with selecting the PHP version, using the word 'Default' should work. If it does not work on your server, contact Migration Tool support here: https://www.ispconfig.org/get-support/?type=migration
I understand your comments about not changing the default version of PHP, but there is the fact that CentOS 8 comes with PHP 7.2.11 as its default, and that version is already marked as "end of life, not supported". CentOS 8 itself was released in September 2019, and its parent was released a year ago. While I could easily have accepted only the default versions for everything, that would have potentially left me in almost the same boat that I found my previous server -- having a system that needs several of its components updated before I even get it into full use. I am not trying to suggest that ISPConfig should have supported CentOS 8 within a week of the O/S release. I've been a developer for over 4 decades so I know that things aren't always as easy as one thinks they should be. However, being told "wait for CentOS 8 to be supported" doesn't tell me how long that will be. Will I see CentOS 8 support about the time that CentOS 9 is released? It also kind of begs the question as to what aspects of CentOS 8 aren't currently supported? As I mentioned, once I had managed to install all of the prerequisites, ISPConfig installed with only two minor errors, and seems to be running quite well. My latest round of problems seem to be with the Migration Tool, and not necessarily with CentOS or ISPConfig itself. And just for info, the "two minor problems" were: ISPConfig sets the value "UseFtpUsers" at line 247 of /etc/pure-ftpd/pure-ftpd.conf. However, pure-ftpd claims that the name of that variable is unrecognized. As a result, the daemon won't start. Commenting out the line seems to solve the problem. And two, the installation of clamd and amavisd sets the service as "[email protected]", however the installer for ISPConfig attempts to start the service as "clamd.amavisd.service". Again, an easy fix.
No offense means I think. We just explained that the ISPConfig works best that way (supported distro and software versions). You can surely use the latest version of any distros of softwares if that is what you really want but please do not expect any official supports from here. I did that myself some times. There is a thread where people discuss on using the not-yet-supported-Centos 8 which you might want to join and ask for help instead of hijacking this thread with your problems due to your own choice. So please, be reasonable.
I had no intention of "hijacking" this thread. I had searched around for discussions on dealing with the PHP specification issue in the Migration Tool, and this was the only thread I found where that problem had been discussed. Yes, I could have started a new thread but that would have likely been dismissed as duplicating an existing discussion. And while there are various pieces of documentation that describe "The Perfect Server with (some form of Linux)", I have never seen any document that says "ISPConfig only works with, and is only supported on, these Linux distributions". Since there are various pieces of documentation for various Linux versions, it seems only reasonable to assume that the difference between version 7.6 and 8.1 of the same operating system should be relatively minor. For the most part, it was. Using "The Perfect Server...CentOS 7.6" as the basis didn't present a lot of problems, and I documented what occurred to assist anyone trying to do the same thing. The biggest problem I ran into was when I tried to migrate from my older server to my new one. When I came here to ask for assistance, the main response I seem to be getting is "you shouldn't have done that". Quite frankly, that really isn't much help. I have used ISPConfig for years, and it is the primary manner in which I support web sites based on various technologies. My current server is running WordPress (various versions), Joomla, Redmine (on Ruby), phpBB, Elgg, plain old HTML, and various other bits and pieces. It has been rock-solid stable for years, and I wouldn't have bothered trying to update it except for warnings about out-of-date PHP support. I guess I'll have to look elsewhere to try to get better answers.
Probably you never visited the ISPConfig website then, as this exact info can be found there. I'll cite it for you: Plus we repeat this on and on here in the forum regularly. So you expect that we don't tell you the truth when you did something that must result in an unstable and not fully working setup? We actually know that it does not fully work yet and that's why it is NOT supported yet and we will label it as supported as soon as it's stable enough to be used in production environments. The problem with CentOS is that it does not contain all required packages in a central repository, you have to get them from third-party repos and the maintainer of these repos needed more than half a year to provide the missing packages, so we just could start testing just recently due to the inability of CentOS to provide a bigger range of software. That's why it is recommended to use Debian and Ubuntu for ISPConfig, which have all required packages in their base repo. There was no need to upgrade your current server as ISPConfig supports additional PHP versions. So you can easily run all PHP versions from 5.6 to 7.4 on your CentOS 7 system simultaneously and easily select per site which PHP version is shall use from within ISPConfig. That's also the reason why the update of PHP 7.2 to 7.4 on centOS 8 did not made much sense, CentOS patches PHP with security patches without changing the major version number. The simple answer is: Is the new system a test system without live sites or you don't care about stability, then keep your current CentOS 8 system and wait until we release an ISPConfig version which fixes all issues of a CentOS 8 setup. The system is meant to run as production system with live sites, then keep using your CentOS 7 system as that#s the CentOS version that shall be used at the moment for running ISPConfig live systems. The PHP problem you mentioned is no problem at all, simply install as many additional PHP versions as you need, this way you can even keep older PHP versions for sites that do not support PHP 7.4 yet.
Btw. ISPConfig 3.1.16, which will support CentOS 8, will get released in June, so you can also just wait for the release together with full installation instructions.
I have been to the ISPConfig site any number of times, and I'll grant you that the supported list is there, but it doesn't say "You should not use anything not on our list". I'll admit that's splitting hairs, and maybe the real fault lies with the developers of CentOS, but I've used CentOS on various other servers and liked the way it worked. I never found any real problems with it until now. I guess in future I'll take the supported list more to heart. I'm sorry for the slight flame. As far as installing newer versions of PHP on my existing server, I looked into that as the first approach. Obviously, I would have avoided building a whole new server if I could. It takes a lot of work to provision an ISPConfig server, and I didn't feel like going through it all. However, every source I found for installing PHP 7.x on to a CentOS 6 server basically said "if you do this you could kill your server. It's not supported and not recommended". That's why I built a CentOS 8 server -- installing PHP 7.x was supported, and the installation was dead easy. I guess now I'll have to go back and try doing it manually and hope I don't kill my server. All of my existing sites run very nicely with PHP 5.6, but I keep seeing warnings about it's security problems, and some software (like Joomla) no longer supports it. I have a requirement to put up a newer Joomla, so I need the PHP 7.x support. Back to salt mines, I guess.
CentOS 6 is really old and should be replaced indeed, but it's not wise to use CentOS 8 before it's supported, especially as there is CentOS 7. But as you installed CentOS 8 now, I recommend that you keep it if the issues you have are not critical for you and in a few weeks, there will be an ISPConfig version that completely works on your system, you might just reconfigure some services as we might change the base setup to Rspamd and remove amavis. and regarding of what you read about PHP versions, you seem to mix up the base system PHP, which you should not replace, with additional PHP versions. Additional PHP versions get installed in a different path, so they do not interfere with your system PHP at all and run just side by side with the system PHP.
Are you sure that's 'php_admin_command'? There are two similar directives (php_admin_value and php_admin_flag) supported by mod_php (see https://www.php.net/manual/en/configuration.changes.php), but I don't find anything for php_admin_command. If perchance the _value or _flag directives are in use for sites, they are probably set to use mod_php (or possibly apache on your old server just ignores those directives). You should be able to wrap them in '<IfModule mod_php5.c>' and '</IfModule>' and they won't cause a problem once migrated (or just delete them, which is effectively the same), though you may need to carry those same values into the php config on your new server. For your overall migration situation, another idea to consider is install a temporary Centos 7 system, and migrate to it to work through your apache/php issues. Once Centos 8 is fully supported, install ISPConfig 3.1.16, run through the centos 8 perfect server guide (if it exists at the time), and migrate again to the server you're working on now. A bit more work, but fully supported, and not just waiting for centos 8 support...
When I started building the CentOS 8 server, I looked at the available versions of PHP. Simply executing "dnf install php" would have given me PHP 7.2, but it was very easy to install PHP 7.4, so I did that, making it the base version for the system, and avoiding a release that was already marked as end-of-life. That meant that I wouldn't have to have two very close versions needing to be installed. Since we were talking about "point" releases, rather than full versions, I didn't feel there would be any problem. And I will await with bated breath the release of ISPConfig 3.1p16 and updates to the "Perfect Server" document.
They really are "php_admin_command" statements. At a guess they seem to be something that was removed from support for newer versions of PHP, or something that only works with mod_PHP or PHP-FPM (or vice versa) For the moment, I'm not horrendously worried about them, as they actually applied to a site on the server that has been largely decommissioned. I'll worry about getting its content at a later time. In effect, that's what I've done. I just finished building a CentOS 7.6 system with all the bits and pieces, and installed ISPConfig on it. I'm running tests on it, and then will likely try a migration from my CentOS 6 system, likely followed by moving all the crap to a CentOS 8 system once that is supported. So many servers, so little time.
