On 6/20/2013 10:00 PM, Bob Miller wrote: > Hi Ben, > > >>> Maybe using something like set -e to try and get some output from the >>> script? >>> > >> Adding the -e switch doesn't seem to produce any output, either. > > To be clear, I meant putting the line: > > set -e > > near the top of your script. I forget exactly how it functions, but it > makes it so when a script fails it spits out a why on stdout (or maybe > stderr). I believe the -x argument does something useful for > troubleshooting too, but it's been too long. `man bash` knows all...
Oops! Now I understand what you meant. I tried adding "set -e" at the top of my shell script, but it doesn't shed much light on the problem. A quick Google search reveals that "set -e causes the shell to exit if any subcommand or pipeline returns a non-zero status." The result is predictable: the call to "deliver" exits with status 75, so using "set -e" causes the script as a whole to return a non-zero exit status, which in turn causes Dovecot to throw an error in my IMAP client: "[SERVERBUG] failed to send mail". > >> It really boils-down to the fact that I can call the following on the >> command-line and it functions as expected: >> >> su vmail -c '/usr/lib/dovecot/deliver -a "sa-train...@example.com" -d >> "sa-train...@example.com" -m "Training.SPAM" -p >> "/tmp/sendmail-msg-25794.txt"' >> >> Yet, when I attempt to do the exact same thing from within the pipe >> script that Dovecot Antispam calls, I receive exit code 75 from >> deliver/dovecot-lda and absolutely nothing is logged, with exception of >> the information of which I'm already aware (logged to syslog). >> >> I am echo-ing $(whoami) just before calling "deliver" within the pipe >> script and the output is "vmail". So, it's not as though the vmail user >> somehow lacks the permissions required to send via dovecot-lda. > > There are two things that came to mind when I read your mail yesterday. > They are the first things I check for when my commands work and my > scripts don't. > > The first is $PATH, I have found innumerable times when a script > wouldn't run it was because it wasn't running with a fully loaded $PATH > variable, and this is especially true if you are launching your script > from cron. To work around this I either put a PATH= at the top of the > script, or I run the script as an argument to bash instead of using the > executable bit (ie `bash /path/to/script.sh` instead of `./script.sh`) > so the path is retained from the shell. I decided against mentioning > this yesterday because I noted you only used full paths in your script, > which should also work to avoid this problem. All excellent insights. You can see the PATH value in my previous message on this subject (from a few minutes ago); it matches the value that I see as "root" when I print the PATH within the shell. So, that seems okay. Also, I took your good advice and eliminated the potential for the vmail user's shell choice (which happens to be /bin/sh, *not* /bin/bash) to affect the script's behavior. To do this I modified my antispam configuration directives as such: antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/bin/sa-learn-pipe.sh antispam_pipe_program_spam_arg = --spam antispam_pipe_program_notspam_arg = --ham Unfortunately, this change doesn't change the result at all; the call to "deliver" still exits with status code 75. > The other thing I didn't mention was the permissions on the path > to /usr/lib/dovecot/deliver (or any other path, really). Directories > with no world read/execute can prevent scripts from using files beneath > them if they don't have permissions on each directory level in the path. > I didn't mention this yesterday because you said you ran the script as > vmail. However, looking at your "su vmail -c" command, I remember some > times when "su postrgres -c" didn't work when "su - postrgres" then > running the command did. I have tried using "su vmail -c [...]", as well as "su vmail" and then pasting the command into the shell. Both yield the same result. Also, there's no question that the vmail user is able to execute dovecot-adm; if he weren't, then a) pasting the command into the shell wouldn't work (and this does work), and b) I wouldn't be receiving exit status code 75, which is unique to dovecot-adm (I assume that I'd receive a more generic code, like 1, if it was a permissions problem). > Probably neither of these will be useful to you, but I mention them in > hope that they trigger and idea or set you on an investigative path that > proves helpful... Any help at all is useful! I really appreciate the time and thought you put into your posts. I wish I felt closer to a solution... :( Please do reply if you have any additional thoughts. I'm at my wit's end here! Thanks again, -Ben > >> >> What is the explanation for this behavior? It has to be something to do >> with how the plug-in calls the script. Does the plug-in call the script >> in some other context, like chroot? >> >> As a final point of note, is it just me, or is the "90-plugin.conf" >> snippet incorrect at the bottom of >> http://wiki2.dovecot.org/Plugins/Antispam ? Those values appear to be >> for the analogous Dovecot 1 plug-in, e.g., "antispam_mail_sendmail" is >> used, when the equivalent directive is called "antispam_pipe_program" in >> versions >= 2.0. >> >> -Ben >
