I had the cron job for my Nextcloud instance set up to call php8.1. Code: /usr/bin/php8.1 -f [web_root]/cron.php I changed it to call php8.2 instead: Code: /usr/bin/php8.2 -f [web_root]/cron.php However, with that one change I now see errors in cron_error.log: Code: /bin/bash: /usr/bin/php8.2: No such file or directory This seems very strange to me because both /usr/bin/php8.1 and /usr/bin/php8.2 have the exact same permissions: Code: -rwxr-xr-x 1 root root 5577224 Oct 6 11:46 /usr/bin/php8.1 -rwxr-xr-x 1 root root 5696296 Oct 6 11:46 /usr/bin/php8.2 What am I missing here?
Thanks for the hint, Taleman, that sounds familiar. I do remember setting this up when I first configured ISPConfig. Is that in Server Config / Jailkit? If so, I remain a bit puzzled, because for "Jailkit cron chrooted applications" I see only "/usr/bin/php /usr/lib/php/ /usr/share/php/ /usr/share/zoneinfo/ /usr/bin/perl /usr/share/perl/". Nothing about php8.1 which used to work. I guess I must be looking in the wrong place?
Also, I already see php8.2 in /etc/jailkit/jk_init.ini. The configuration for it looks exactly the same as for php8.1 (except for the version number, of course).
Now I've tried reverting to php8.1 and I still see the cron failures! That's bizarre. The only other change was enabling redis, but is it possible that would affect it?
Okay, I admit I'm stumped. I'll just ask it simply: how do I ensure php8.1 and php8.2 are in the jail for cron? I did pay for the ISPConfig guide PDF, but I can't see where in there this is described. Even a page reference would help. (In the meantime I've switched to a webcron call, but would like to switch back once I'm educated on this anew.)
Add "php8_2" to System > server config > jailkit > Jailkit chroot app sections. New jails will then have PHP 8.2 and existing jails will get it then until tomorrow during nightly jail update run.
Thanks, till, will do. That still is a little puzzling, though. Back when I was running PHP 8.1, the Jailkit chroot app sections was: Code: coreutils basicshell editors extendedshell netutils ssh sftp scp jk_lsh mysql-client git I did, yesterday, add 'php' to that list, after finding mention of that elsewhere, though that by itself fixed nothing. Without any php at all in that section, how was cron able to call PHP in the jail?
The section php is not a specific PHP version, it's the system PHP. If you want to have a specific PHP version, then you must specify that by selecting the matching app section. Because there is always a PHP in the jail as specified in Jailkit cron chrooted applications field.
Is that the case even if 'php' isn't actually visibly present in the "Jailkit cron chrooted applications" field? (This was the case for me.)
Any new installed ISPConfig system contains this in the "Jailkit cron chrooted applications" field: Code: /usr/bin/php /usr/lib/php/ /usr/share/php/ /usr/share/zoneinfo/ /usr/bin/perl /usr/share/perl/ as you can see, the PHP binary is listed there as well as the folders /usr/lib/php/ and /usr/share/php/.
Yes, I had/have that as well. I was referring to the "Jailkit chroot app sections" you mentioned. I had no 'php' in there at all until now. Just to be sure, here's what I have now. The 'php php8_1 php8_2' has subsequently been added to "Jailkit chroot app sections" by me.
Applications in jailkit can be added by either specifying an app section or by including its binary and folders individually.
Thanks. I think I know what happened now. I added the binary path /usr/bin/php8.2 to the "Jailkit cron chrooted applications" field but, if I understand correctly, that runs only once per day (a "nightly jailkit run" as you referred to it), which I didn't realize. Thus it didn't work instantly, which I incorrectly expected. Now I have the "Jailkit cron chrooted applications" field back to the default, and I have added 'php php8_1 php8_2" to the "Jailkit chroot app sections" field, and will wait until tomorrow to try the direct cron call again.
That does suggest that /usr/bin/php (that is, the default 7.4 in my case) will run in the jail, but doesn't explain why usr/bin/php8.1, which was not in "Jailkit cron chrooted applications", was able to run.
Unfortunately this morning trying the /usr/bin/php8.2 call in the cron job, with "php8_2" now included in the "Jailkit chroot app sections" field and "/usr/bin/php8.2" in the "Jailkit cron chrooted applications" field, still won't run, showing the same error, "/bin/bash: /usr/bin/php8.2: No such file or directory".
Do I have Jailkit configured correctly? Code: Jailkit chroot home: /home/[username] Jailkit chroot app sections: coreutils basicshell editors extendedshell netutils ssh sftp scp jk_lsh mysql-client git php php8_1 php8_2 Jailkit chrooted applications: /usr/bin/groups /usr/bin/id /usr/bin/dircolors /usr/bin/lesspipe /usr/bin/basename /usr/bin/dirname /usr/bin/nano /usr/bin/pico /usr/bin/mysql /usr/bin/mysqldump /usr/bin/git /usr/bin/git-receive-pack /usr/bin/git-upload-pack /usr/bin/unzip /usr/bin/zip /bin/tar /bin/rm /usr/bin/patch /etc/localtime Jailkit cron chrooted applications: /usr/bin/php /usr/lib/php /usr/share/php /usr/share/zoneinfo /usr/bin/perl /usr/share/perl/ /usr/bin/php8.1 /usr/bin/php8.2 Jailkit authorized_keys template: /root/.ssh/authorized_keys Hardlinks within Jailkit chroot: Allow hardlinks within the jail
When you change the configuration for Jailkit, this is not reflected immediatelly for all jails. If you want to add it immediately: Code: jk_init -j /var/www/clients/clientX/webX/ php8_2 Replace clientX and webX with the correct values.
The results of that: Code: root@foo:/var/www/clients/client1# jk_init -j /var/www/clients/client1/web1/ php8_2 usr/bin/var/www/clients/client1/web1/bin ERROR: /var/www/clients/client1 is not owned by root:root! ERROR: jail directory php8_2 is not safe Which is true. /var/clients/client1 is owned by some numeric group and user, 10XX, rather than root:root. Is that a problem?
Yes, it is. You can not have a jail where any directory in the tree is owned by a non-root user. You must have changed the directory ownership manually as ISPConfig sets them correctly to root:root.