Running ISPconfig on ARM64: Bullseye with Linux 5.10.110-rockchip-rk3588: uninitialized value $apache_proc_php in concatenation (.) or string at - line 2524 (#1)

Hi MikaelWinther1,

ISPconfig

Just to set your expectations, support for this is unlikely to be added, unless someone like yourself, who has exposure to ISPConfig and has some perl skills, and is willing to contribute to the project, is able to fork itand make a pull request.

Support for Plesk, cPanel and Virtualmin were all added back in a time when I had a web hosting job where knowing that kind of information was useful to me and the team that had regular exposure to Plesk servers and cPanel Servers. Ive changed jobs twice since then and I simply dont have exposure to ISPConfig nor the will to maintain this project for much longer.

Regarding support for ISP Config, you can either fork a copy of apache2buddy and modify and use it as you want to and run your own custom version, or you can contribute to this project, it's entirely up to you. However to be honest Im unlikely to run into ISP Config and hence it will not be on the roadmap.

Event Mode

If you look through previous closed issues, event and worker modes came up quite a lot. apache2buddy simply wasnt written to sove this kind of problems, because apachebuddy (on which apache2buddy was built upon) was designed to calculate maxclients for prefork only, because of its inclusion of mod-php.

Calculating memory usage in apache becomes irrelevant because the php bit (which was the bulk of the memory use) is offloaded to something like php-fpm - since neither event not worker modes support mod-php.

One of my colleagues wrote a script called PHP-FPMPAL to solve that issue, however that project has been abandoned for several years.

The Error:

Without access to yor system to troubleshoot further, I would take the educated guess that your php executable is not in /usr/bin/php as hardcoded in this subroutune:

sub detect_php_memory_limit {
    if ( ! $NOINFO) {
        our $apache_proc_php = get_php_setting('/usr/bin/php', 'memory_limit');
        show_info_box(); print "Your PHP Memory Limit (Per-Process) is ${CYAN}".$apache_proc_php."${ENDC}.\n";
        if ($apache_proc_php eq "-1") {
            show_advisory_box(); print "You should set a PHP Memory Limit (-1 is ${CYAN}UNLIMITED${ENDC}) which is not recommended.\n";
        }
    }
}

Hardcoded php path is definitely wrong

Though I will take on the chin that it should not have been hardcoded as /usr/bin/php but rather it should have had a variable like our $php_exe = 'which php;`, to save a large rewrite of apache2buddy, if you try and symlink /usr/bin/php to your php executable path, it should make that error go away.

I've generated a new issue to take a look at that here: https://github.com/richardforth/apache2buddy/issues/409

As there are statements that check for the precence of PHP using "which php"further up - but nothing that sets the variable that we can substitute for an executable. This has been in the code for over 10 years! However it should be corrected. The question is when.

End of Maintenance Looms

As I said I dont get a lot of time to devote to apache2buddy.pl like I used to, so its likely that at some point in the future this project will stop being actively maintained.

I'm hoping some kind soul will create a pull request, I can then run the Jenkins pipeline to test it doesnt break anything and merge it in, Failing that, if I get some annual leave and some free time I'll take a look at the issues in due course.

I hope that at least answers some of your questions. Since ISPConfig and Event mode are off the table for the reasons given, Im closing this issue, but refer you to issue #409

richardforth / apache2buddy