Almalinux 9 CyberPanel Error code '' **ERROR** Could not compile PHP ''
- Thread starter dangerover
- Start date
I think CyberPanel, unless installed using a partnered hosting script (and maybe not even then) has become a little too problematic. The install script that is. I want to talk with Usman about a couple ideas of moving it forward. The installer is honestly spread across multiple files that are very exact in their operations and are not resilient to any system that isn't freshly installed, which can cause problems during updates (twice I had it break and fubar the install when running an update because one of the update scripts errors out with EL9).
I gave up on using cyber panel in its current state, and it's not for the feint of heart to install from the cli. I did make a PR to bandaid fix the fatal python failure during the 'pip install -r requirments.txt' part. Some changes to python intentionally broke older versions of the 'packaging' package in pip (it's fixed with packaging>=22). Alma uses python3-packaging as a dependency unnecessarily, and that means being unable to update packaging to the proper version. In my testing, packaging 24 (current) doesn't cause any breakage, so my dirty patch was basically 'pip install -U --root-user-action=ignore --force-reinstall --break-system-packages packaging>=22' and then the script works.
The change by the python group to the packaging package was to mitigate some older broken requirements.txt files that explicitly defined incompatible dependencies.
Hopefully rhel will use the newer python3-packaging in 9.6, but who knows. The more correct patch I suppose would be to create the venv and then patch the packaging package in the venv, then do the requirments.txt file, but it's a guaranteed show stopper on current EL9 (at least alma) systems.
That said ..
I compiled lsmcd the other night and ran into an issue, so I made a ticket on the repo. While gcc recognizes register pointers as warnings, clang throws errors on them. Anyway, got it sorted, but the dev (Bob) that responded to my ticket said that they really don't recommend using memcached unless for whatever reason you need to for a reason you know that you need to, or because it's already set up and you don't wanna break something that works. And I agree.
Unless you absolutely insist on using memcached, I would recommend going the redis route. Redis is superior to memcached. Only potential issues could be that youre on shared hosting and can't run a redis server. But redis can be configured to not bind to an IP address or tcp port, usinga unix socket instead. It's a simple config file edit in redis.conf. redis also doesn't need to run as root (in fact it runs as redis:redis by default) and you can place the .sock file and .pid file in a localized directory under your /usr/local/lsws, such as .../lsws/run or .../lsws/var. Or even .../lsws/redis/run for your .pid and .sock files and .../lsws/redis/redis for your data directory (normally this is /var/lib/redis). Again, it's a permission thing.
CyberPanel does offer both memcached and redis during the install, and you can only set one or the other for your lscache WordPress plugin.
TL;DR: I would recommend using redis in place of memcached unless you really need to. That said, the packages 'compat-openssl11' and 'compat-openssl11-devel' should hopefully resolve your compile issue, though you may have to use compile line variables like OPENSSL_LIBS="-L/path/to/openssl-compat -lssl -lcrypto -lz" and OPENSSL_CFLAGS="-I/path/to/openssl-compat/include" on your './configure' command line. but you'll want to be sure that you also set the flag '--with-openssl=static' on that command line too. The compat packages are in the OS AppStream repo.
NOTE: alternatively, you could try these variables prepended to your './configure' command line:
CFLAGS=$(pkg-config --cflags compat-openssl11) LDFLAGS=$(pkg-config --libs compat-openssl11)
NOTE2: you may not need the extra variables of what you're trying to build specifically calls the /usr/lib64/libssl.so.1.1 file directly instead of expecting /usr/lib64/libssl.so to be a symbolic link to it.
Hope this helps.
I gave up on using cyber panel in its current state, and it's not for the feint of heart to install from the cli. I did make a PR to bandaid fix the fatal python failure during the 'pip install -r requirments.txt' part. Some changes to python intentionally broke older versions of the 'packaging' package in pip (it's fixed with packaging>=22). Alma uses python3-packaging as a dependency unnecessarily, and that means being unable to update packaging to the proper version. In my testing, packaging 24 (current) doesn't cause any breakage, so my dirty patch was basically 'pip install -U --root-user-action=ignore --force-reinstall --break-system-packages packaging>=22' and then the script works.
The change by the python group to the packaging package was to mitigate some older broken requirements.txt files that explicitly defined incompatible dependencies.
Hopefully rhel will use the newer python3-packaging in 9.6, but who knows. The more correct patch I suppose would be to create the venv and then patch the packaging package in the venv, then do the requirments.txt file, but it's a guaranteed show stopper on current EL9 (at least alma) systems.
That said ..
I compiled lsmcd the other night and ran into an issue, so I made a ticket on the repo. While gcc recognizes register pointers as warnings, clang throws errors on them. Anyway, got it sorted, but the dev (Bob) that responded to my ticket said that they really don't recommend using memcached unless for whatever reason you need to for a reason you know that you need to, or because it's already set up and you don't wanna break something that works. And I agree.
Unless you absolutely insist on using memcached, I would recommend going the redis route. Redis is superior to memcached. Only potential issues could be that youre on shared hosting and can't run a redis server. But redis can be configured to not bind to an IP address or tcp port, usinga unix socket instead. It's a simple config file edit in redis.conf. redis also doesn't need to run as root (in fact it runs as redis:redis by default) and you can place the .sock file and .pid file in a localized directory under your /usr/local/lsws, such as .../lsws/run or .../lsws/var. Or even .../lsws/redis/run for your .pid and .sock files and .../lsws/redis/redis for your data directory (normally this is /var/lib/redis). Again, it's a permission thing.
CyberPanel does offer both memcached and redis during the install, and you can only set one or the other for your lscache WordPress plugin.
TL;DR: I would recommend using redis in place of memcached unless you really need to. That said, the packages 'compat-openssl11' and 'compat-openssl11-devel' should hopefully resolve your compile issue, though you may have to use compile line variables like OPENSSL_LIBS="-L/path/to/openssl-compat -lssl -lcrypto -lz" and OPENSSL_CFLAGS="-I/path/to/openssl-compat/include" on your './configure' command line. but you'll want to be sure that you also set the flag '--with-openssl=static' on that command line too. The compat packages are in the OS AppStream repo.
NOTE: alternatively, you could try these variables prepended to your './configure' command line:
CFLAGS=$(pkg-config --cflags compat-openssl11) LDFLAGS=$(pkg-config --libs compat-openssl11)
NOTE2: you may not need the extra variables of what you're trying to build specifically calls the /usr/lib64/libssl.so.1.1 file directly instead of expecting /usr/lib64/libssl.so to be a symbolic link to it.
Hope this helps.
Last edited: