email piping works, but generates error via return email

mmanna

Hello,

I am having a somewhat perplexing problem that I seem to be stuck on. I'm new to osticket and just set up the latest version of it on Saturday on my shared linux hosting plan.

When a user sends an email to my piped email address, it generates the ticket, notifies me, and sends them a confirmation, all as expected. However, it also sends an email back to the user with the following error:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its

recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/myusername/public_html/tms/api/pipe.php

generated by help@mydomain.com

The following text was generated during the delivery attempt:

------ pipe to |/home/myusername/public_html/tms/api/pipe.php

generated by help@mydomain.com ------

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/php_xslt.dll' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/php_xslt.dll: cannot open shared object file: No such file or directory in Unknown on line 0

I've tried searching and browsing the forum extensively - I found a few threads describing similar problems, but none had the same error I'm getting. The ones I found were also somewhat old and were likely prior to the 1.6 RC4 version which I am using.

I sent an email to my hosting provider, and they replied as follows:

Marc,

This is one or multiple issues with your program:

1. The permisions are setup wrong

2. The script is configured incorrectly

3. The script has a bug

They also offered to try and fix it for me, for a fee. I'd like to try and resolve it myself first (with your help!).

If anyone can offer any advice or suggestions, I would be most appreciative!

I am running the following:

CPanel 11.18.3-RELEASE build 21703, Theme X3

Apache 1.3.39 (Unix)

PHP 5.2.4

MySQL 5.0.45-community

I've already verified that my pipe.php is chmod' 764

The first 2 lines of pipe.php are:

#!/usr/bin/php -q

<?php

Thanks,

Marc

mmanna

Anybody? Any ideas or suggestions? Please?

Marc

mmanna

After some persistence, I was able to get the following info back from my hosting company ... but I still don't know what to do about it. It sounds like they are implying that php_xlst.dll is the old way of doing things and osticket should be re-coded to use XSL instead? Any thoughts or suggestions would be appreciated. I'm really hitting the end of the road here and out of options.

Please note if your program is dependent on php_xslt that is only supported in php 4. PHP5 supports XSL. Level 3 has certified xsl is working.

djtremors

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/php_xslt.dll' -

Firslty check if you have multiple PHP CLI bin file copies running.

then in your pipe use the /usr/bin/php in front of the script so it uses PHP for sure to run it and not what is possibly in the script.

I saw that error before when bash was trying to open the file and gave warnings.etc.

you can check from command line the pipe your about to run works without warnings or errors and see if it just sits and wait for input which means it's working.. any warning or errors is a no no...

mmanna

Thanks for the suggestions. Unfortunately, I'm on a shared hosting plan so I don't think I have access to do most of what you were suggesting.

As far as your comment about /usr/bin/php ... the first line of my pipe.php is:

#!/usr/bin/php -q

Is that what you are talking about? Do I need to change it?

Thanks

Marc

djtremors

No, i'm refering to the pipe command itself.

Instead of invoking the script directly, call the CLI php command and pass the script name.. ie

"| /usr/bin/php /var/www/website/osticket/api/pipe.php"

so basically add the path to PHP command line.

if you have shell access just run : which php

tulsabobt

piping errors in Cpanel

In Cpanel 11 you cannot specify the interpreter, which is what is causing the problem. You advise to point to PHP, BUT see below:

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 Hashbang 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.

So, how do I work around this so the error messages are nto sent out?

Bob

JonnyClean

I think I've got this one...

After reading this thread and a few others I think I have a solution that will work for you guys, I had the exact problem described.

Unfortunately you will need root access to do this.

in /etc/exim.conf

search for return_output

You'll find a comment that looks something like:

# This transport is used for handling pipe deliveries generated by alias

# or .forward files. If the pipe generates any standard output, it is returned

# to the sender of the message as a delivery error. Set return_fail_output

# instead of return_output if you want this to happen only when the pipe fails

# to complete normally. You can set different transports for aliases and

# forwards if you want to - see the references to address_pipe in the directors

# section below.

Below that you'll see some options. Among them there are two mentions of "return_output"

change both to "return_fail_output" (no quotes)

When you are done it will look something like this:

address_pipe:

driver = pipe

return_fail_output

virtual_address_pipe:

driver = pipe

group = nobody

return_fail_output

user = "${lookup{$domain}lsearch* {/etc/virtual/domainowners}{$value}}"

---------------

This worked for me! Hope it helps you too!

---------------

email piping works succeeds creates ticket created

mail delivery error fails failed

btssn

need help when sending reply to tickets email piping not working instead i am getting this error although email does come through

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/btssn/public_html/ticket/api/pipe.php
generated by tickets@btssn.co.uk
local delivery failed

The following text was generated during the delivery attempt:

------ pipe to |/home/btssn/public_html/ticket/api/pipe.php
generated by tickets@btssn.co.uk ------

Failed loading /opt/ioncube/ioncube_loader_lin_5.6.so: /opt/ioncube/ioncube_loader_lin_5.6.so: undefined symbol: zend_execute_ex
Failed loading /opt/php56/lib/php/extensions/no-debug-non-zts-20131226/ZendGuardLoader.so: /opt/php56/lib/php/extensions/no-debug-non-zts-20131226/ZendGuardLoader.so: undefined symbol: zend_execute_ex

Reporting-MTA: dns; merkur.websitewelcome.com

Action: failed
Final-Recipient: rfc822;|/home/btssn/public_html/ticket/api/pipe.php
Status: 5.0.0

ForwardedMessage.eml
Subject:
Re: [#0503] test email piping
From:
Saj Btssn <saj@btssn.co.uk>
Date:
21/01/2020, 12:01
To:
Support <tickets@btssn.co.uk>

test reply
On 21/01/2020 12:01, Support wrote:

saj,

A customer support staff member has replied to your support request, #0503 with the following response:

test

We hope this response has sufficiently answered your questions. If not, reply to this email or login to your account for a complete archive of all your support requests and responses.

http://www.btssn.co.uk/ticket/view.php?auth=o1xyyaaaagmaiaaaNlvV%2FVrsLX81Tg%3D%3D

ntozier

This thread is 9 years old. Please do not be a necromancer.

Please start your thread after you read the posting guidelines located in this thread: Please read before requesting assistance. The more information you give us the better we will be able to assist you. Thank you.

Your PHP is failing at loading shared objects (most likely php extensions under linux). This is not an osTicket issue, its a hosting issue for command line PHP on the server.

Killing zombie thread with a head shot.