• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question CentOS2Alma conversion: Your expectations and experience?

Thanks but did not work.
Does not show any php handler error and the script still says php70 is detected.

Comes to my attention that 7.0 is STILL shown in the panel's PHP config. in off position but the switch allows to be turned on.
This shouldn't be happening, right?

Any other idea?

Thanks again,

Regards
 
Thanks but did not work.
Does not show any php handler error and the script still says php70 is detected.

Comes to my attention that 7.0 is STILL shown in the panel's PHP config. in off position but the switch allows to be turned on.
This shouldn't be happening, right?

Any other idea?

Thanks again,

Regards

BTW, in the graphic Plesk installer, PHP 7.0 is not even show to install or remove BUT as said above, it shows in the server's php interpreter activation.

Totally lost here....
 
BTW, in the graphic Plesk installer, PHP 7.0 is not even show to install or remove BUT as said above, it shows in the server's php interpreter activation.

Totally lost here....
I remember that I had to remove it twice. Once regularly, then refresh the PHP versions page in the backend, then remove it again (on the command line). Only after the second removal it was really gone.
 
I couldn't use the conversion tool as it kept failing. Instead, I set up a new instance of Plesk on Alma Linux and migrated 100 sites over to the new server with the Plesk migration tool. I worked like a dream and I have said goodbye to Centos 7, it will be missed.
 
I couldn't use the conversion tool as it kept failing. Instead, I set up a new instance of Plesk on Alma Linux and migrated 100 sites over to the new server with the Plesk migration tool. I worked like a dream and I have said goodbye to Centos 7, it will be missed.
Im glad you managed to migrate the sites over, this is my plan also but i am having issues connecting the migration tool. I used the migration tool perfectly 5 years ago but I cant seem to connect now on port 22. The error i am getting is below;

Failed to check SSH connection to the source server 'source' (x.x.x.x): Unable to connect to 'x.x.x.x' by SSH: Bad authentication type; allowed types: [u'publickey', u'gssapi-keyex', u'gssapi-with-mic'].
Ensure that the server is up and there are no firewall rules that may block SSH connections to the server,

then restart migration.

I have port 22 open as i can SSH onto the server using Putty. I am hosting both servers on the same AWS VPC and i have tried allowing all incoming traffic for testing, nothing is blocked on there.

I am using password authentication as i have always done. The error above suggests that password authentication is not enabled so i have tried to set PasswordAuthentication yes on both "/etc/ssh/ssh_config" & "/etc/ssh/sshd_config" to no avail.

This is absolutely driving me nuts, are you using PasswordAuthentication?
 
Im glad you managed to migrate the sites over, this is my plan also but i am having issues connecting the migration tool. I used the migration tool perfectly 5 years ago but I cant seem to connect now on port 22. The error i am getting is below;

Failed to check SSH connection to the source server 'source' (x.x.x.x): Unable to connect to 'x.x.x.x' by SSH: Bad authentication type; allowed types: [u'publickey', u'gssapi-keyex', u'gssapi-with-mic'].
Ensure that the server is up and there are no firewall rules that may block SSH connections to the server,

then restart migration.

I have port 22 open as i can SSH onto the server using Putty. I am hosting both servers on the same AWS VPC and i have tried allowing all incoming traffic for testing, nothing is blocked on there.

I am using password authentication as i have always done. The error above suggests that password authentication is not enabled so i have tried to set PasswordAuthentication yes on both "/etc/ssh/ssh_config" & "/etc/ssh/sshd_config" to no avail.

This is absolutely driving me nuts, are you using PasswordAuthentication?
Just to give an update for this, i managed to get the connection wokring. I was testing this to and from Alma Linux 9
 
I couldn't use the conversion tool as it kept failing. Instead, I set up a new instance of Plesk on Alma Linux and migrated 100 sites over to the new server with the Plesk migration tool. I worked like a dream and I have said goodbye to Centos 7, it will be missed.
I have managed to connect the Plesk Migrator from centos to alma 9 without any issues. Can I ask another question regarding the migration and best practices. After you migrated the sites from Centos to Alma 9, did you simply assign you original IP to the new server and did everything work straight away? Is this what you did and did you experience any issues?
 
Conversion tool works with problems in our environment.

Problem 1: before upgrade -> export LEAPP_OVL_SIZE=4096
Problem 2: after conversion httpd not start -> watchdog module not enable
Problem 3: selinux blocked httpd (if nginx proxy enabled: 502 bad gateway) -> reinstall plesk policy
 
I was unable to get apache to restart after the conversion. I get these error messages from the Diagnose & Repair:
errorThere is a disabled required Apache module: mpm_event
errorThere is a disabled required Apache module: mpm_prefork
errorThere is a disabled required Apache module: proxy
errorThere is a disabled required Apache module: proxy_fcgi
error3 service plans with unregistered PHP handlers were found.
 
I was unable to get apache to restart after the conversion. I get these error messages from the Diagnose & Repair:
errorThere is a disabled required Apache module: mpm_event
errorThere is a disabled required Apache module: mpm_prefork
errorThere is a disabled required Apache module: proxy
errorThere is a disabled required Apache module: proxy_fcgi
error3 service plans with unregistered PHP handlers were found.
I found that modsec was running a custom configuration. I was able to get Apache to start after switching it to a standard configuration. I am going to go through the whole process again on Monday on the test server.
 
Hi,

I had issues updating using v1.3.2 due to PHP 7 handlers.

Last night downloaded the latest script at: https://github.com/plesk/centos2alma/releases/download/v1.3.3/centos2alma-1.3.3.zip

Ran it and 30 minutes later the server updated without a glitch!
Total time, including the self-reboot was around 40 minutes.

Maria DB had already been updated before to v 10.11.8, no postgres installed and SELlinux is disabled.

Thanks a lot to Peter, Kaspar and everyone else involved.
 
Uh, oh. On a test server, before going to production, I was able to get it to work a few days ago. But in another test run, I got this error:

2024-08-08 15:22:17,030 - INFO - Installing: python2-leapp-0.16.0-2.el7.noarch (elevate)
2024-08-08 15:22:17,030 - INFO - python2-leapp = 0.16.0-2.el7
2024-08-08 15:22:17,030 - INFO - You could try using --skip-broken to work around the problem
2024-08-08 15:22:17,582 - INFO - You could try running: rpm -Va --nofiles --nodigest
2024-08-08 15:22:17,649 - ERROR - Command ['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7'] failed with return code 1
2024-08-08 15:22:17,649 - ERROR - Failed: installing leapp. The reason: Command '['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7']' returned non-zero exit status 1.
 
we migrated from centos 7 to alma 9 the only issue we had was with cresources (think it was called) was enabled and had to disable that in order to stop getting errors on cpu :)
 
Good to know. Indeed, Almalinux measures and displays the CPU load differently from CentOS. The same load on Alma 8 for the "last minute" drives the number up by factors compared to what CentOS measures or displays. This can have an extreme impact on tools that monitor server performance or react on increased load. As we are measuring load at least every 10 seconds we had to adapt the scripts to that new situation, as otherwise scripts might think something is awfully wrong while short peaks on cpu load happened before, but did not become visible the same as they show in Alma 8 or 9.
 
Uh, oh. On a test server, before going to production, I was able to get it to work a few days ago. But in another test run, I got this error:

2024-08-08 15:22:17,030 - INFO - Installing: python2-leapp-0.16.0-2.el7.noarch (elevate)
2024-08-08 15:22:17,030 - INFO - python2-leapp = 0.16.0-2.el7
2024-08-08 15:22:17,030 - INFO - You could try using --skip-broken to work around the problem
2024-08-08 15:22:17,582 - INFO - You could try running: rpm -Va --nofiles --nodigest
2024-08-08 15:22:17,649 - ERROR - Command ['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7'] failed with return code 1
2024-08-08 15:22:17,649 - ERROR - Failed: installing leapp. The reason: Command '['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7']' returned non-zero exit status 1.
Someone is looking at this and responded to a GitHub issue I created on this: "It seems we are using new packages from the elevate repositories that are not compatible with leapp 0.14, which we have pinned. I will fix this and recreate the latest release wit the fix."
 
Someone is looking at this and responded to a GitHub issue I created on this: "It seems we are using new packages from the elevate repositories that are not compatible with leapp 0.14, which we have pinned. I will fix this and recreate the latest release wit the fix."
Thank you for reporting this issue on our Github page Paul. I see that developers are working on resolving this issue. However there is no ETA yet on when a fix will be released.
 
Uh, oh. On a test server, before going to production, I was able to get it to work a few days ago. But in another test run, I got this error:

2024-08-08 15:22:17,030 - INFO - Installing: python2-leapp-0.16.0-2.el7.noarch (elevate)
2024-08-08 15:22:17,030 - INFO - python2-leapp = 0.16.0-2.el7
2024-08-08 15:22:17,030 - INFO - You could try using --skip-broken to work around the problem
2024-08-08 15:22:17,582 - INFO - You could try running: rpm -Va --nofiles --nodigest
2024-08-08 15:22:17,649 - ERROR - Command ['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7'] failed with return code 1
2024-08-08 15:22:17,649 - ERROR - Failed: installing leapp. The reason: Command '['/usr/bin/yum', 'install', '-y', 'leapp-0.14.0-1.el7', 'python2-leapp-0.14.0-1.el7', 'leapp-data-almalinux-0.1-6.el7']' returned non-zero exit status 1.

Hello, using new version "centos2alma-1.3.3.zip" (https://github.com/plesk/centos2alma/releases/download/v1.3.3/centos2alma-1.3.3.zip) I get the same error trying to convert a Plesk Obsidian v18.0.63_build1800240802.12 os_CentOS 7 (CentOS Linux 7.9.2009 (Core)) server to AlmaLinux.
 
Back
Top