Issue Running PHP script as a scheduled task

[weltonw]

Yes

 

[QWeb Ric]

OK, thanks. I'm too tired to dare action this on a production server right now, but this sounds promising! I'll let you know how I get on.

 

[weltonw]

Probably should do this on staging/dev either way. Just sayin'

 

[QWeb Ric]

Unfortunately we don't have a development server that this is an issue on so that's not an option for me...

 

[weltonw]

Yikes. That must be exciting

 

[QWeb Ric]

Thankfully science gave us coffee!

 

[weltonw]

And Beer!

 

[QWeb Ric]

7 months later, I'm finally looking into this again.

Combining John's advice above and How to add programs to a chrooted shell environment template in Plesk , the below code seems to have gotten me half way there.

sudo mkdir /var/www/vhosts/chroot/usr/lib64
sudo cp -a /usr/lib64/mysql /var/www/vhosts/chroot/usr/lib64/
sudo ./update_chroot.sh --add wget
sudo ./update_chroot.sh --add curl
sudo ./update_chroot.sh --add ldconfig
sudo chroot /var/www/vhosts/chroot /bin/sh -c "ldconfig -v"
sudo ./update_chroot.sh --apply all

Now, as long as I use 127.0.0.1 instead of localhost in the mysqli_connect() functions, database scripts are working as chrooted crons. Curl is also no longer erroring.

But although it isn't erroring, it's also not outputting anything at all. No PHP errors, nothing in curl_error(), just an empty result when I fire curl_exec().

I think that both this and the fact I have to use 127.0.0.1 instead of localhost are likely that DNS resolution isn't working within the chrooted environment but I'm struggling to figure out what needs adding to the chroot template to fix that. Any thoughts please?

 

[QWeb Ric]

Ah - http addresses work with Curl, but https addresses do not. Googling is spinning up some references to needing urandom in the chrooted environment but I'm not finding much about how to add that... --add urandom doesn't work.

 

[QWeb Ric]

Not convinced urandom is the problem... If I chroot in and attempt to fire a curl request for a https url, I'm getting "Problem with the SSL" outputs. I've found the CA parts in /etc/ssl/certs but this directory is missing from the chroot template... Am I supposed to just copy the whole directory in like I did with /usr/lib64/mysql or is there a better approach? Seems to me that these files are likely to update often and the chrooted environment would just end up out of date...?

 

[QWeb Ric]

Seems to be an NSS issue:

sudo mkdir /var/www/vhosts/chroot/etc/ssl
sudo cp -a /etc/pki /var/www/vhosts/chroot/etc/
sudo cp -a /etc/ssl/certs /var/www/vhosts/chroot/etc/ssl/

sudo chroot /var/www/vhosts/chroot

curl -v https://www.google.com
* About to connect() to www.google.com port 443 (#0)
*   Trying 2a00:1450:4009:820::2004...
* Connected to www.google.com (2a00:1450:4009:820::2004) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Unable to initialize NSS database
* Initializing NSS with certpath: none
* Unable to initialize NSS
* Closing connection 0

 

[QWeb Ric]

Ahhh! Turns out the lib64 copy John had suggested previously was needed since the NSS libraries are in that tree. I'd tried it when tinkering with the MySQL isses but reverted when I realised only the mysql folder was needed. Seems this does fix the Curl issues though:

sudo cp -a /usr/lib64/*.so* /var/www/vhosts/chroot/usr/lib64/

Now unsure whether the /etc/pki and /etc/ssl trees are actually needed in the chroot after all, but hey ho, Curl with https addresses is working now!

 

[QWeb Ric]

I think I'm done and now all of the domains I'd previously had to keep as /bin/bash shells because of complex cron scripts now seem to be working under "/bin/bash (chrooted)" on CentOS 7. I've collated everything into a new Bash script in the hopes this is useful to others:

Useful-scripts/Bash scripts for Linux/plesk-chroot-template.sh at main · qwebltd/Useful-scripts

Potentially useful scripts by QWeb Ltd. Contribute to qwebltd/Useful-scripts development by creating an account on GitHub.

github.com

 

[QWeb Ric]

It does appear we have one remaining issue, actually. PHPs mail functions aren't working - even if using PHPMailer the cron tasks just throw an "/usr/sbin/sendmail: No such file or directory" error.

Following the various symlinks that /usr/sbin/sendmail passes through, I thought this would work:

sudo mkdir /var/www/vhosts/chroot/usr/lib64/plesk-9.0
sudo mkdir /var/www/vhosts/chroot/usr/sbin
sudo cp -a /etc/alternatives /var/www/vhosts/chroot/etc/
sudo cp -a /usr/lib64/plesk-9.0/postfix-sendmail-wrapper /var/www/vhosts/chroot/usr/lib64/plesk-9.0/
sudo cp -a /usr/sbin/sendmail /var/www/vhosts/chroot/usr/sbin/

But applying the template then just throws the following message and PHP mail functions remain broken:

chrootmng: skipping suid or sgid file "/var/www/vhosts/chroot/usr/lib64/plesk-9.0/postfix-sendmail-wrapper"

Any thoughts please?

 

[weltonw]

So, there isn't really a simple way for a chroot to be truly secure AND to have a sendmail binary.

If you are up for it, there's something like this: Lisa Rushworth Home Page

Otherwise, some implementation use a sort of proxy to mediate communication.

The best option is just have the PHP script connect over submission 587, which works regardless of chroot

 

[QWeb Ric]

Oh wow, that looks like a lot of hackery just to make sendmail work!

PHPMailer in SMTP mode does work, and for in-house scripts that's a totally fine approach. My worry though is that if something like a Magento Cron tries to trigger an email it's entirely possible that this is going to rely on sendmail and just hacking PHPMailer into scripts maintained by other developers to circumvent sendmail reliance isn't an easy task.

I considered setting up a PHP script as a wrapper - something that listens for POST data and uses PHPMailer in SMTP mode to then generate emails, and then stick a custom Bash script where sendmail is supposed to be in the chroot which takes the email and posts it via Curl to this script, but aside from having to then dissect sendmail to figure out how to read the email it's supposed to be receiving, this would create all sorts of mail relay authentication problems that I just don't want to have to think about. I.e. the generated email would always be flagged as originating at my script instead of its true origin. Missing headers, missing DKIM stuff, etc. Not the simple idea it seems.

Thankfully I don't believe we actually have any Cron scripts that ever generate emails on this particular server - I was only testing sendmail for the sake of it.

 

[weltonw]

PHPMailer can use sendmail, but also an external SMTP relay so you can connect to localhost. We do this for our WP installations so email works.

What you mentioned is an option, but carries the downsides you mentioned, which are obviously less than ideal. You can manually pass/rewrite the headers, but that's even complicating jt more