First off, kudos to the creators of ISPProtect; it sounds like a great addition to run on ISPConfig. Unfortunately I'm having a bit of trouble running the trial on a fresh OracleCloud Ampere A1 ARM64 platform. Initially I got the following error: Code: Downloading ionCube Loader for your system. /tmp/ioncube.tar.gz 100%[===========================================>] 11.95M 16.3MB/s in 0.7s ionCube Check succeeded. Failed loading /tmp/ioncube/ioncube_loader_lin_7.4.so: /tmp/ioncube/ioncube_loader_lin_7.4.so: wrong ELF class: ELFCLASS32 So I proceeded to visit get-loader.ioncube.com for install assistance and followed their manual directions for installation; I was able to download the correct binary for my platform (which is running Ubuntu 20.04 ARM64 edition); and placed the .so file in the appropriate libs folder. I then added the zend_extension ini snippet to mods-available and symlink'd them to their respect /etc/php/7.4/cli/conf.d and /etc/php/7.4/fpm/conf.d. Both my phpinfo in my web browser and php -i on the command line show ionCube ini parsed and loaded with the paragraph indicating "ionCube - Loader version 11.0.1". Now running ispp_scan results in no auto installation; but still errors out with: Code: ionCube Check succeeded. Failed loading /tmp/ioncube/ioncube_loader_lin_7.4.so: /tmp/ioncube/ioncube_loader_lin_7.4.so: wrong ELF class: ELFCLASS32 Warning: _il_exec((????): failed to open stream: No such file or directory in /tmp/v71/ispp_scan.php on line 2 Any ideas what's needed to run ISPProtect on ARM64 platforms? Does "ELFCLASS32" indicate a 32-bit binary that should be 64-bit? If that's the case, the suggested platform from ionCube maybe at fault. The uname -m for my platform definitely says "aarch64". Any clues would be appreciated!
Could be but why don't you simply try the 64-bit package since it is the 32-bit package shows you that error.
Sorry, I didn't clarify. I did try the 64bit installer directly from ionCube. That is why... However, I did note that next to ./ispp_scan is an iconCube folder with suspect libraries in it; removal of the folder causes issn_scan to re-download what maybe the wrong libraries. Shouldn't the loaded 64-bit libraries in my php.ini take priority?
Please try the following: Open the ispp_scan bash script and search for the line Code: echo "disable_functions=" >> ${DIR}/ispp_php.ini Then add your loader line from global php ini to it like: Code: echo "zend_extension=/path/to/yours" >> ${DIR}/ispp_php.ini The global php ini is mostly ignored due to issues with custom settings on many systems.
Okay, I found the problem; there is a bug in ./ispp_scan. Even with ionCube ARM64-bit ioncube_loader_lin_7.4.so loaded into php.ini; ./ispp_scan fails to detect it and persists with downloading 32-bit drivers to the tmp folder and uses them. I can "fool" ISPProtect by copying over the file. This means I simply copy the installed, working, 64-bit ARM compatible file at /usr/lib/php/20190902/ioncube_loader_lin_7.4.so to the automated download ispp_scan uses at /tmp/ioncube//ioncube_loader_lin_7.4.so. I've already reported and linked to this thread on ISPProtect.com via the their contact page. I'll examine the scripts they are using to bootstrap; but I don't think there is a repo for pull requests.
