SOLVED Jailed shell issues with email piping

[jndawson]

Hello,

As of roughly about the time our auto cPanel updates completed (now on v.58.0.7), our piped email to our whmcs system (latest v.6.3.1) started failing.

[ [email protected] ~># grep 1bQGs2-0002l7-QL /var/log/exim_mainlog
2016-07-21 09:30:47 1bQGs2-0002l7-QL <= [email protected] H=c-customer-network ([10.0.0.3]) [123.45.678.90]:16679 P=esmtpsa X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_plain:[email protected] S=4406 [email protected] T="testing" for [email protected]
2016-07-21 09:30:47 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1bQGs2-0002l7-QL
2016-07-21 09:30:47 1bQGs2-0002l7-QL => support <[email protected]> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <[email protected]> wcF+BLf4kFdsKQAAjl7P1g Saved"
2016-07-21 09:30:52 1bQGs2-0002l7-QL ** |/home/us/whmcs_crons/pipe.php ([email protected]) <[email protected]> R=virtual_aliases_nostar T=jailed_virtual_address_pipe: Child process of jailed_virtual_address_pipe transport returned 1 from command: /usr/local/cpanel/bin/jailexec
2016-07-21 09:30:52 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1bQGs2-0002l7-QL
2016-07-21 09:30:52 1bQGs8-0002lM-8A <= <> R=1bQGs2-0002l7-QL U=mailnull P=local S=5907 T="Mail delivery failed: returning message to sender" for [email protected]
2016-07-21 09:30:52 1bQGs2-0002l7-QL Completed

here's the forwarder in cPanel:

[email protected] |/home/us/whmcs_crons/pipe.php

Note the missing 'php -q'. Re-adding it does nothing; it disappears.

We ran the script (actually the 'cron' script, since that didn't run either) at cli and it ran properly.

Did the cPanel update change something that is now horribly broken?

thanks,
Jim Dawson

 

[cPanelMichael]

Note the missing 'php -q'. Re-adding it does nothing; it disappears.

Hello,

The following information found under the email piping option explains the omission of /usr/bin/perl or /usr/bin/php portion is by design. It relies on the target at the top of the script:

When piping to a program, you should enter a path relative to your home directory. If the script requires an interpreter such as Perl or PHP, you should omit the /usr/bin/perl or /usr/bin/php portion. Make sure that your script is executable and has the appropriate target at the top of the script. If you do not know how to add the hashbang, just make sure to name your script file with the correct extension and you will be prompted to have the hashbang added automatically.

As far as the error message itself, please let us know if the following WHMCS document is helpful:

http://docs.whmcs.com/Email_Piping#Email_Forwarder_Method

Please post the output from the following commands if the issue persists after reviewing the steps listed in that document:

cat /etc/redhat-release
arch
uname -a
/usr/local/cpanel/bin/envtype

I've seen limited reports of this issue with CentOS 7.2 on Virtuozzo and OpenVZ systems, however it's not yet reproducible.

Thank you.

 

[jndawson]

Permissions changed to 644 (which we didn't catch); changing to 755 worked.

Keep in mind we were not trying to do something different. These are pipes that were running just fine for months with no attention needed.

For reference, here is the info you requested:

[ [email protected] ~># cat /etc/redhat-release
CentOS release 6.8 (Final)
[ Thu Jul 21 13:18:52 ]
[ [email protected] ~># arch
x86_64
[ Thu Jul 21 13:18:52 ]
[ [email protected] ~># uname -a
Linux cp1.ourcompany.tld 2.6.32-642.1.1.el6.x86_64 #1 SMP Tue May 31 21:57:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[ Thu Jul 21 13:18:52 ]
[ [email protected] ~># /usr/local/cpanel/bin/envtype
vmware

 

[cPanelMichael]

Permissions changed to 644 (which we didn't catch); changing to 755 worked.

Keep in mind we were not trying to do something different. These are pipes that were running just fine for months with no attention needed.

Hello,

I've not seen a recent change in the executable requirement for email piping scripts. Were you able to track down when and why the file permissions changed?

Thank you.

 

[jndawson]

I've not seen a recent change in the executable requirement for email piping scripts.

Neither have I.

Were you able to track down when and why the file permissions changed?

Everything was working just fine, including piping email to our ticketing system on July 20. Last imported ticket was roughly about the time the nightly cPanel update, which installed 58.0.5/.6/& .7, was completed morning of the 21st.

 

[twhiting9275]

Piping will always require 7xx permissions when done through cPanel, because cPanel seems to want to (incorrectly) remove the PHP argument from the forwarder, so, your script has to be treated as an executable script. It's been this way for years now.

 

[jndawson]

Piping will always require 7xx permissions when done through cPanel, because cPanel seems to want to (incorrectly) remove the PHP argument from the forwarder, so, your script has to be treated as an executable script. It's been this way for years now.

I don't know about 'years', but we presently have 2 whmcs installations on different cPanel servers (both at v.58.0.7) and the one running whmcs v.5.8.14 has perms 0644 & the PHP argument 'php -q' must be there or the pipe doesn't work. We double checked that while troubleshooting the newly upgraded v.6.3.1 server that had the piping issues.

 

[twhiting9275]

These were probably setup before the cron changes were made. I really can't recall exactly how long it's been, but it's been quite a while since that change

 

[cPanelMichael]

Hello,

The following document was recently changed to reflect updated information about email piping:

Forwarders - Documentation - cPanel Documentation

However, we do have a case open regarding the following text under the piping option in "cPanel > Forwarders":

When piping to a program, you should enter a path relative to your home directory. If the script requires an interpreter such as Perl or PHP, you should omit the /usr/bin/perl or /usr/bin/php portion. Make sure that your script is executable and has the appropriate target at the top of the script. If you do not know how to add the hashbang, just make sure to name your script file with the correct extension and you will be prompted to have the hashbang added automatically.

This suggests that if no hashbang is present in the provided program, a prompt will be displayed to add the hashbang automatically. This prompt is never provided, nor is the proper hashbang added to the program. Case CPANEL-7562 is open to ensure the prompt is displayed as suggested by the cPanel interface output, or to remove that statement and require that the user add it manually. I'll update this thread with more information on the status of the case as it becomes available.

Thank you.

 

[jndawson]

These were probably setup before the cron changes were made.

Actually, no. I set them up in May when I installed a new copy of WHMCS on a cpanel server that previously had no WHMCS installation. They worked fine.

 

[twhiting9275]

huh, ok. I've seen this as behavior in cPanel for years now.

 

[jndawson]

Update to close the loop on this:

The incoming email from our vendor had a message boundary error (Content-Type: application/application/json) which they corrected (Content-Type: application/json). Apparently the import script doesn't do error checking. Attachments from them are now being properly imported.

Thanks for the assistance.

 

[cPanelMichael]

I'm happy to see the issue is now resolved. Thank you for updating us with the outcome.

 

[swbrains]

I have come across this issue recently as well. I have a Perl script on my dedicated server under a specific account that I use to process incoming mail to a specific forwarder address. The account has jailed shell (and has as long as I can remember). The script was set as the pipe target for a forwarder and had worked for quite a while. I deleted and recreated the forwarder yesterday and now email sent to that script does not get processed. The Track Delivery app in cPanel shows this error for messages sent to that forwarder:

"Child process of jailed_virtual_address_pipe transport returned 2 from command: /usr/local/cpanel/bin/jailexec"

After a number of tests including removing all code except for a few lines from the script, I narrowed down the problem a bit. I created a new test script that does nothing but this:

#!/usr/bin/perl

require "myincludefile.pl";

open (DEBUGLOG, ">/home/myaccount/public_html/cgi-bin/pipemailtest.log");
print DEBUGLOG "script has run";
close DEBUGLOG;

exit;

The script is located in the cgi-bin directory for this account -- the same location as the "myincludefile.pl". In this state, sending mail to the forwarded address with the pipe causes the jailexec error above.
If I change the require statement to include the full path, such as:

require "/home/myaccount/public_html/cgi-bin/myincludefile.pl";

then it works fine when I send an email to the forwarded address and the debug log file is created. All of the other scripts I use under this account do *not* need to specify the full path for a "required" include file if it's in the same path as the parent script (which this one is). This only seems to be a problem with a script executed as a pipe target in a mail forwarder. If I execute the same script directly from the browser, it will work properly even *without* the full path specified in the require field.

The forwarder is set up like this in cPanel:

[email protected] |/home/myaccount/public_html/cgi-bin/pipemailtest.pl

The test script (and the required "myincludefile.pl" file) have 755 permissions and work fine if the full "require" path is specified, so I don't think this is a file permission issue.

Also, switching "myaccount" to Normal shell in WHM doesn't resolve the issue when it is has the non-working require statement (no path specified).

Any ideas would be greatly appreciated!
Thanks!

 

[cPanelMichael]

"Child process of jailed_virtual_address_pipe transport returned 2 from command: /usr/local/cpanel/bin/jailexec"

Hello @swbrains,

Could you open a support ticket using the link in my signature so we can take a closer look and see why this is happening? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[swbrains]

Support Ticket 8040939 opened. Please note that I am not able to grant access to the server to cPanel technicians. I understand if that precludes your staff from investigating further.

 

[swbrains]

Unfortunately, support replied that they would require access to the server to investigate further, which we are unable to provide. I'm assuming that also means this is not a known issue and that it can't be replicated in-house given the information provided in my initial response here. I will move forward using the workaround mentioned -- specifying the full paths to include files in scripts used for piping emails.