I hope next Cyberpanel version will also support AlmaLinux 9
I had assumed that the best Linux distributions for use as a server were Red Hat and derivatives, for their greater reliability, robustness, security and performance in its functions as a server.
Almalinux 9
Will share some update soon about the support of cyberpanel like with ubuntu and all
@usmannasir any prevision?
has the topic changed? when can we expect updates and support for AlmaLinux 9 ?
I am looking forward to supporting this system
still waiting for a response from @usmannasir
has anyone tried to install?
Please give us some time.

@usmannasir Any updates on AL9.2 Support? We been holding the migration for quite sometimes now. Let’s know if we could help. Any ATA is much appreciated.

Almalinux 8 loses active support in about 7-8 months from now.

Hi, any news or ETA ?
Thanks in advance for the support.

@usmannasir We will have Cyberpanel for Almalinux 9, any predictions?
When is Alma Linux 9 Support coming? If you’re reading this comment Please VOTE at the top!
I managed to properly install it on my Almalinux 9 by experimenting with the script and occasionally intervening during the installation process. After that, I compare it to a fresh Debian installation with a cyberpanel on AWS. I can attest that everything was properly configured, to the extent where I saw one issue on a clean Debian install with PHP8.2 not working, but it works fine on my Almalinux 9. Almalinux 9 refers to the right Alma/Remi 9 and other repositories.
I can share OVA or VMA if anyone wants it.
CyberPanel is supported on Ubuntu 18.04, Ubuntu 20.04 Ubuntu 22.04, AlmaLinux 8 and CloudLinux 7.x…
No Almalinux 9.
Yes, it is currently unsupported, but I am a bit stubborn to install it on Alma9
Could you post your install process?
Php 8.2 shouldn’t be an issue anymore with 2.3.5 and forward.
As long as the new PHP versions are added to litespeed’s repo for php.
@usmannasir will we have the fantastic cyberpanel in almalinux 9?
During the installation process, there are numerous untidy procedures that require intervention, such as manually modifying the repository sources or copying the backup of the correct AlmaLinux 9 sources after the script overrides them to maintain the sources’ integrity.
In addition, I can provide the image to you in your preferred OVA or VMA format, as I said in my initial response.
No news about Almalinux 9 support?
V3.0.0 should support Almalinux 9 later.
What is the expected release date for Cyberpanel 3.0?
I do not know when 3.0.0 will be released, but 2.3.5 was just released, so it might take some time.
@usmannasir, AlmaLinux 8 has lost extended support which may be an issue depending on requirements of the user. We have been abundantly patient and I even in good faith paid in the last year to support the project. This is now high priority!
Coming v soon
How long from now would you wager? I’m in the process of changing VPS hosts (from Contabo to Oplink) and if it were in the next couple weeks, I’d be down to help test things!
By end of next week consider it done, will give full dedication to this.
I’ve added initial support for Almalinux 9, install and basic features are working.
Will test more during next week.
@usmannasir Just as a quick note, I just did an install on Alma9.4, wen tthrough ok, I suppose, I noticed it did not install lsphp83 as I saw some references to it not installed towards the end of the install.
Did not have a thorough look through but installed lsphp83 (it confirmed it was not installed yet) and so far, nothing further to report, except one minor bug bear, that is it skipped through the choosing the password for the admin account, and set a default one.
So all up, 2 issues observed from a quick test install.
Din anyone tried the migration from AlmaLinux 8 to 9?
Hello,
I tried to install cyberpanel on alma9, but still I got this error:
Traceback (most recent call last):
File “/root/cyberpanel/install/install.py”, line 2626, in
main()
File “/root/cyberpanel/install/install.py”, line 2506, in main
installCyberPanel.Main(cwd, mysql, distro, ent, None, port, args.ftp, args.powerdns, args.publicip, remotemysql,
File “/root/cyberpanel/install/installCyberPanel.py”, line 808, in Main
installer.installMySQL(mysql)
File “/root/cyberpanel/install/installCyberPanel.py”, line 371, in installMySQL
type = clAPVersion.split(‘-’)[0]
AttributeError: ‘NoneType’ object has no attribute ‘split’
Oops, something went wrong…
That’s the same issue as I had triying to run the install.sh-script using SERVER_OS=“CentOS8”.
In the new version of the install script SERVER_OS is still set to CentOS8 for detected Alma9 as OS?
Is this correct?
I tried CentOS 7 to Almalinux 9 on a virtual machine and after a lot of work, I got it working.
Will be redoing it again and then running on production.
I will post a complete walkthrough after.
What I have noticed so far is:
-
I had to package and port some symlinks from a working machine running Almalinux 9 and Cyberpanel for ease of update since Almalinux 9 uses python 3.9 and Almalinux 8 uses python 3.6.
-
After elevating, mariadb is uninstalled
-
Each system will vary with and the guide will provide a walkthrough based on what Cyberpanel installs, you will have to go through and fix/remove some packages on your own.
Hello sajetek_developer,
thank you for your message.
The python-issue is just what I thought.
But a self-made walkthrough is not a good option in my opinion.
Alma9 is officially supported for cyberpanel, so cyberpanel has to test dependencies and standard packages of the OS for their software-package (in my opinion).
As a potential customer for the enterprise-version, I expect the package to run on a virgin Alma9 without spending hours for troubleshooting and fixing dependencies on a “supported OS”.
After updating the OS, nobody could guaranty the functionality of cyberpanel, so you have to fix
dependencies again.
Not really an enterprise-like solution
It’s not a one size fits all walkthrough as each system has separate packages installed.
What is consistent here, are the packages for CyberPanel and the packages of the OS version.
Leap is not a one size fits all tutorial but they do compile packages that cause issues for you to remove.
CyberPanel installs packages based on the OS version so once migrated over to Almalinux 9, the repos will be consistent with what CyberPanel uses. The only issue there is that CyberPanel links to python3.6 and the upgrade script does not remove the links and recreatee it to point to python3.9.
This is a constant so we can provide a walkthrough based on that and provide the symlinks to python 3.9 which fixes the issue.
After that you can update cyberpanel as normal which will install all it’s dependencies.
Specific to your issue: I have installed Cyberpanel with no errors on a virgin Almalinux 9. (This is how I was able to find the python differences)
Your issue is specific to you so you will have to troubleshoot.
Try removing install.sh and /root/cyberpanel
Run this command to fix the mariadb repo.
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
dnf clean all
remove and reinstall mariadb packages, then install/upgrade CyberPanel
Hello sajetek_developer,
Thank you for your answer. The error mentioned above was on a virgin alma9, but I did not change anything with python before.
Could you please tell me, what exactly to change on virgin alma9 to get the installer run correctly and getting things started?
Kind regards.
I can’t remember.
I will mount up another VM and test it again and provide feedback.
Run this command to fix the mariadb repo.
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
dnf clean all
The issue is with accessing the mariadb repo.
Then run the installer for CyberPanel and it will install fine.
It’s running on Almalinux 9, can I update?
Almalinux 9.4 is supported in CyberPanel.
But so far I’ve not had any good luck getting docker to work on 9.4
So i would not recommend updating from 8.10 to 9.4 yet.
I’ve’ elevated all my CentOS 7 machines to Almalinux 8 and then to Almalinux 9.4 and I do have docker running without issues.
The issue with docker was resolved last month or so Here on Github.
I will be posting a walkthrough soon for the elevation from CentOS 7 with Cyberpanel to Almalinux 9.
So far I’ve had no issues since after the fix for Docker and FTP.
How do you fix the docker issue?
Because i have an Almalinux 9.4 install, i can’t seem to create the docker container at all.
And the image is on the server.
Not Found

Login via SSH and uninstall everything related to docker.
Then run the Cyberpanel upgrade script.
Then go to Docker Manager and let them handle the installation.
Most likely you are running podman-docker which is the wrong package.
I initially had that issue as well.
These are my installed packages.
If the repo is missing, install it first.
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
Here’s before uninstalling:
I ran these commands:
# Remove unused data
docker system prune --all --volumes
# Remove all services
docker service rm $(docker service ls -q)
# Remove all containers
docker rm -f $(docker ps -aq)
# Remove all images
docker rmi -f $(docker images -aq)
# Remove all volumes
docker volume rm $(docker volume ls -q)
systemctl stop docker
dnf list installed|grep docker
sudo yum remove docker-compose-plugin
sudo yum remove containerd.io.x86_64
sudo yum remove docker-buildx-plugin.x86_64
sudo yum remove docker-ce.x86_64
sudo yum remove docker-ce-cli.x86_64
sudo yum remove docker-ce-rootless-extras.x86_64
Then i ran:
sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh)
Choose the current version today 18.08.24 which is 2.3.6
Here’s after:
-
Going to install Docker.
-
Add the image (feelingsurf/viewer)
-
Create container
-
How the container looks when i click create:
-

dnf list installed|grep docker
Enable debugging temporarily in: /usr/local/CyberCP/CyberCP/settings.py by setting DEBUG to True
check /usr/local/CyberCP/dockerManager/urls.py and make sure you have the line below, it should be the only line that matches “images”:
url(r’^images’, views.images, name=‘containerImage’),
Run the following, this will cleanup your pycache and restart lscpd and lsphp:
find /usr/local/CyberCP/ -type d -name pycache -exec rm -r {} +; service lscpd restart && service lsws restart; killall lsphp
Retry the creation of the image, you should get some debug output.
When you are done reset Debug and run the code to clear pycache and restart lscpd.
The urls.py has more than one line that matches “images”
urls.py
from django.urls import path, re_path
from . import views
from websiteFunctions.views import Dockersitehome
urlpatterns = [
re_path(r'^$', views.loadDockerHome, name='dockerHome'),
# re_path(r'^images$', views.loadImages, name='loadImages'),
re_path(r'^getTags$', views.getTags, name='getTags'),
re_path(r'^runContainer$', views.runContainer, name='runContainer'),
re_path(r'^submitContainerCreation$', views.submitContainerCreation, name='submitContainerCreation'),
re_path(r'^listContainers$', views.listContainers, name='listContainers'),
re_path(r'^getContainerList$', views.getContainerList, name='getContainerList'),
re_path(r'^getContainerLogs$', views.getContainerLogs, name='getContainerLogs'),
re_path(r'^installImage$', views.installImage, name='installImage'),
re_path(r'^delContainer$', views.delContainer, name='delContainer'),
re_path(r'^doContainerAction$', views.doContainerAction, name='doContainerAction'),
re_path(r'^getContainerStatus$', views.getContainerStatus, name='getContainerStatus'),
re_path(r'^exportContainer$', views.exportContainer, name='exportContainer'),
re_path(r'^saveContainerSettings$', views.saveContainerSettings, name='saveContainerSettings'),
re_path(r'^getContainerTop$', views.getContainerTop, name='getContainerTop'),
re_path(r'^assignContainer$', views.assignContainer, name='assignContainer'),
re_path(r'^searchImage$', views.searchImage, name='searchImage'),
re_path(r'^manageImages$', views.manageImages, name='manageImages'),
re_path(r'^getImageHistory$', views.getImageHistory, name='getImageHistory'),
re_path(r'^removeImage$', views.removeImage, name='removeImage'),
re_path(r'^recreateContainer$', views.recreateContainer, name='recreateContainer'),
re_path(r'^installDocker$', views.installDocker, name='installDocker'),
re_path(r'^images$', views.images, name='containerImage'),
re_path(r'^view/(?P<name>.+)$', views.viewContainer, name='viewContainer'),
path('manage/<int:dockerapp>/app', Dockersitehome, name='Dockersitehome'),
path('getDockersiteList', views.getDockersiteList, name='getDockersiteList'),
path('getContainerAppinfo', views.getContainerAppinfo, name='getContainerAppinfo'),
path('getContainerApplog', views.getContainerApplog, name='getContainerApplog'),
path('recreateappcontainer', views.recreateappcontainer, name='recreateappcontainer'),
path('RestartContainerAPP', views.RestartContainerAPP, name='RestartContainerAPP'),
path('StopContainerAPP', views.StopContainerAPP, name='StopContainerAPP'),
]
Here’s the output it gave:
Output
# Page not found (404)
|Request Method:|GET|
| --- | --- |
|Request URL:|https://IP:PORT/docker/runContainer/?image=feelingsurf/viewer&tag=stable|
Using the URLconf defined in `CyberCP.urls`, Django tried these URL patterns, in this order:
1. base/
2. [name='adminLogin']
3. verifyLogin [name='verifyLogin']
4. logout [name='logout']
5. packages/
6. websites/
7. tuning/
8. ftp/
9. serverstatus/
10. dns/
11. users/
12. dataBases/
13. email/
14. serverlogs/
15. firewall/
16. backup/
17. managephp/
18. manageSSL/
19. api/
20. filemanager/
21. emailPremium/
22. manageservices/
23. plugins/
24. emailMarketing/
25. cloudAPI/
26. docker/ ^$ [name='dockerHome']
27. docker/ ^getTags$ [name='getTags']
28. docker/ ^runContainer$ [name='runContainer']
29. docker/ ^submitContainerCreation$ [name='submitContainerCreation']
30. docker/ ^listContainers$ [name='listContainers']
31. docker/ ^getContainerList$ [name='getContainerList']
32. docker/ ^getContainerLogs$ [name='getContainerLogs']
33. docker/ ^installImage$ [name='installImage']
34. docker/ ^delContainer$ [name='delContainer']
35. docker/ ^doContainerAction$ [name='doContainerAction']
36. docker/ ^getContainerStatus$ [name='getContainerStatus']
37. docker/ ^exportContainer$ [name='exportContainer']
38. docker/ ^saveContainerSettings$ [name='saveContainerSettings']
39. docker/ ^getContainerTop$ [name='getContainerTop']
40. docker/ ^assignContainer$ [name='assignContainer']
41. docker/ ^searchImage$ [name='searchImage']
42. docker/ ^manageImages$ [name='manageImages']
43. docker/ ^getImageHistory$ [name='getImageHistory']
44. docker/ ^removeImage$ [name='removeImage']
45. docker/ ^recreateContainer$ [name='recreateContainer']
46. docker/ ^installDocker$ [name='installDocker']
47. docker/ ^images$ [name='containerImage']
48. docker/ ^view/(?P<name>.+)$ [name='viewContainer']
49. docker/ manage/<int:dockerapp>/app [name='Dockersitehome']
50. docker/ getDockersiteList [name='getDockersiteList']
51. docker/ getContainerAppinfo [name='getContainerAppinfo']
52. docker/ getContainerApplog [name='getContainerApplog']
53. docker/ recreateappcontainer [name='recreateappcontainer']
54. docker/ RestartContainerAPP [name='RestartContainerAPP']
55. docker/ StopContainerAPP [name='StopContainerAPP']
56. container/
57. CloudLinux/
58. IncrementalBackups/
The current path, `docker/runContainer/`, didn’t match any of these.
I thought you were on the “Create New Container” page but I now understand where you are.
I was able to replicate your issue using your urls.py file.
Mine is a bit different and i’m not sure if it’s because of the elevation but this should fix your problem.
urls.py
from django.conf.urls import url
from django.urls import path
from . import views
from websiteFunctions.views import Dockersitehome
urlpatterns = [
url(r'^$', views.loadDockerHome, name='dockerHome'),
# url(r'^images', views.loadImages, name='loadImages'),
url(r'^getTags', views.getTags, name='getTags'),
url(r'^runContainer', views.runContainer, name='runContainer'),
url(r'^submitContainerCreation', views.submitContainerCreation, name='submitContainerCreation'),
url(r'^listContainers', views.listContainers, name='listContainers'),
url(r'^getContainerList', views.getContainerList, name='getContainerList'),
url(r'^getContainerLogs', views.getContainerLogs, name='getContainerLogs'),
url(r'^installImage', views.installImage, name='installImage'),
url(r'^delContainer', views.delContainer, name='delContainer'),
url(r'^doContainerAction', views.doContainerAction, name='doContainerAction'),
url(r'^getContainerStatus', views.getContainerStatus, name='getContainerStatus'),
url(r'^exportContainer', views.exportContainer, name='exportContainer'),
url(r'^saveContainerSettings', views.saveContainerSettings, name='saveContainerSettings'),
url(r'^getContainerTop', views.getContainerTop, name='getContainerTop'),
url(r'^assignContainer', views.assignContainer, name='assignContainer'),
url(r'^searchImage', views.searchImage, name='searchImage'),
url(r'^manageImages', views.manageImages, name='manageImages'),
url(r'^getImageHistory', views.getImageHistory, name='getImageHistory'),
url(r'^removeImage', views.removeImage, name='removeImage'),
url(r'^recreateContainer', views.recreateContainer, name='recreateContainer'),
url(r'^installDocker', views.installDocker, name='installDocker'),
url(r'^images', views.images, name='containerImage'),
url(r'^view/(?P<name>(.*))$', views.viewContainer, name='viewContainer'),
path('manage/<int:dockerapp>/app', Dockersitehome, name='Dockersitehome'),
path('getDockersiteList', views.getDockersiteList, name='getDockersiteList'),
path('getContainerAppinfo', views.getContainerAppinfo, name='getContainerAppinfo'),
path('getContainerApplog', views.getContainerApplog, name='getContainerApplog'),
path('recreateappcontainer', views.recreateappcontainer, name='recreateappcontainer'),
path('RestartContainerAPP', views.RestartContainerAPP, name='RestartContainerAPP'),
path('StopContainerAPP', views.StopContainerAPP, name='StopContainerAPP'),
]
Remember to disable debugging and clear pycache.
Try upgrading to the branch 2.3.5-a9
I’m seeing that this branch has the same structure as my install.
I haven’t upgraded to 2.3.6 as yet
When i tried 2.3.5-a9 i got a strange upgrade error.
Errors
[08.19.2024_18-16-50] #########################################################################
[08.19.2024_18-16-50] verify certificate successful.
[08.19.2024_18-16-50] #########################################################################
Traceback (most recent call last):
File "/root/cyberpanel_upgrade_tmp/upgrade.py", line 3464, in <module>
main()
File "/root/cyberpanel_upgrade_tmp/upgrade.py", line 3460, in main
Upgrade.upgrade(args.branch)
File "/root/cyberpanel_upgrade_tmp/upgrade.py", line 3362, in upgrade
Upgrade.UpdateConfigOfCustomACL()
File "/root/cyberpanel_upgrade_tmp/upgrade.py", line 2996, in UpdateConfigOfCustomACL
django.setup()
File "/usr/local/lib/python3.9/site-packages/django/__init__.py", line 16, in setup
from django.urls import set_script_prefix
File "/usr/local/lib/python3.9/site-packages/django/urls/__init__.py", line 1, in <module>
from .base import (
File "/usr/local/lib/python3.9/site-packages/django/urls/base.py", line 9, in <module>
from .exceptions import NoReverseMatch, Resolver404
File "/usr/local/lib/python3.9/site-packages/django/urls/exceptions.py", line 1, in <module>
from django.http import Http404
File "/usr/local/lib/python3.9/site-packages/django/http/__init__.py", line 5, in <module>
from django.http.response import (
File "/usr/local/lib/python3.9/site-packages/django/http/response.py", line 15, in <module>
from django.core.serializers.json import DjangoJSONEncoder
File "/usr/local/lib/python3.9/site-packages/django/core/serializers/__init__.py", line 23, in <module>
from django.core.serializers.base import SerializerDoesNotExist
File "/usr/local/lib/python3.9/site-packages/django/core/serializers/base.py", line 7, in <module>
from django.db import models
File "/usr/local/lib/python3.9/site-packages/django/db/models/__init__.py", line 20, in <module>
from django.db.models.fields.files import FileField, ImageField
File "/usr/local/lib/python3.9/site-packages/django/db/models/fields/files.py", line 8, in <module>
from django.core.files.storage import Storage, default_storage
File "/usr/local/lib/python3.9/site-packages/django/core/files/storage/__init__.py", line 3, in <module>
from django.conf import DEFAULT_STORAGE_ALIAS, settings
ImportError: cannot import name 'DEFAULT_STORAGE_ALIAS' from 'django.conf' (/usr/local/lib/python3.9/site-packages/django/conf/__init__.py)
above command failed...
I’ve just checked on a VM that I have with native Almalinux 9 and Docker Manager is working perfect.
My urls.py file also reflects the same as my elevated machine.
It’s not yet on the latest commit of 2.3.5.
I also tried upgrading this machine to 2.3.5 and got the same error as you
So I’ve recognized the issue.
I was able to update to the latest commit of 2.3.5 which gave me the same urls.py file as you and I got the same error.
There is a bug in the urls.py file that limits it to urls matching regex “runContainer$”
Remove the $ from the below line:
re_path(r'^runContainer$', views.runContainer, name='runContainer'),
So that it looks like this:
re_path(r'^runContainer', views.runContainer, name='runContainer'),
then run:
find /usr/local/CyberCP/ -type d -name __pycache__ -exec rm -r {} \+; service lscpd restart && service lsws restart; killall lsphp
You should be up and running again.
I haven’t tested everything for docker to see if the issue also occurs on other urls so it’s possible that the issue may reoccur on other urls.
I will open a Bug report on github to have this resolved.
I had to re-install 2.3.6 on almalinux 9.4, then, this is the solution.
But 8.4 - 8.10 uses the $ sign it seems.
I did a clean install on Almalinux 9 and everything works perfectly, except MailScanner which reproduces this message
CyberPanel is supported on x86_64 based Ubuntu 18.04, Ubuntu 20.04, Ubuntu 20.10, Ubuntu 22.04, CentOS 7, CentOS 8, AlmaLinux 8, RockyLinux 8, CloudLinux 7, CloudLinux 8, openEuler 20.03, openEuler 22.03…
Is there any way to get around this?
a clean install cyberpanel on Almalinux 9.5 ,and the 7080 Port is open to public by default. another issue is that, on the cyberpanel menu :security>>firewall can’t see the option about 7080 port.
This is a security issue, Please fix it ASAP.
Not sure why you posted it here.
But i have now added a patch on the port 7080 not showing in the firewall.
It won’t be in older versions of CyberPanel, but it might get pushed into 2.5.5-dev atm.







