[PHP] PHPMailer kan sendmail niet vinden op Debian

[Kajel]

Hallo allemaal!

Ik zit met een ontzettend frustrerend probleem, waar ik nou al ruim 5 uur mijn hoofd op aan het breken ben Ik heb sinds een tijdje een VPS waar ik een aantal websites op draai. Voornamelijk wat "uitprobeer" sites, maar ook 1 productiesite. De VPS draait Debian 6.

Nou kwam ik er vandaag achter dat er geen mailtjes meer verzonden worden vanuit de productiesite sinds de verhuizing naar de VPS. Hierdoor kunnen gebruikers zich niet meer registreren op de betreffende website. De website maakt gebruik van de PHPMailer class.
De error log gaf het volgende aan:

Sending mail failed: Language string failed to load: execute/usr/sbin/sendmail

Googlen levert op dat sendmail de Mail Transfer Agent is. Sendmail schijnt moeilijk te configureren te zijn en op een aantal plekken werd postfix als alternatief aangewezen. Dat zou volgens een aantal bronnen de fout op moeten lossen. Een

Bash:

apt-get remove --purge sendmail

en een

Bash:

apt-get install postfix

later was ik nog geen stap verder in het probleem. Postfix levert, net als de meeste andere MTA's een sendmail-wrapper, zodat sendmail gebruikt kan worden om postfix aan te roepen, zoals PHPMailer verwacht. Maar de fout bestaat nog steeds.

Er zat niks anders op dan goed debuggen. Dus als test-case heb ik even een aparte website opgezet die alleen maar een mailtje probeert te versturen en eventuele fouten rapporteert.

Gebruikte code is als volgt:

PHP:

<?php

  require_once('PHPMailer/class.phpmailer.php');

  $mail = new PHPMailer();
  $mail->IsSendmail();
  $to = '[e-mail]';
  $subject = 'the subject';
  $message = '<h1>hello</h1>';
  $from = '[e-mail]';
  $replyto = '[e-mail]';

  $mail->AddReplyTo($replyto);
  $mail->SetFrom($from);
  $mail->AddAddress($to);
  $mail->Subject = $subject;
  $mail->MsgHTML($message);
  if (!$mail->Send()) {
    echo "Mailer Error: " . $mail->ErrorInfo;
  } else {
    echo "Message sent!";
  }
?>

Dit levert de volgende foutmelding op:

Mailer Error: Could not execute: /usr/sbin/sendmail

Postfix er maar afgegooid, en exim4 geprobeerd. Deze schijnt goed icm Debian te werken. Nog steeds dezelfde foutmelding echter Ik vermoed dat het iets met permissions te maken heeft, maar /usr/sbin/sendmail (de wrapper voor exim4) heeft voor world executable, read en write rechten, en /usr/sbin dir heeft voor world read en executable rechten.
Heeft iemand meer ervaring met dit soort dingen en suggesties? De PHP mail() functie werkt, maar is minder betrouwbaar volgens zowel de makers van PHPMailer als bijv. de makers van Swiftmailer (andere PHP mail class). Bovendien zou mailen via sendmail (in dit geval exim4) toch moeten werken?
Mailen via de command line werkt overigens ook. Zowel als normale user en als root.

edit: Omdat een collega er naar vroeg, zet ik het ook even hier: exim4 heeft logbestanden, maar die leveren in dit geval niks op, omdat de binary uberhaupt niet aangeroepen kan worden, laat staan de machtiging krijgen om te loggen

[ Voor 3% gewijzigd door Kajel op 01-08-2011 10:02 ]

[Verwijderd]

Heeft PHPMailer een debug modus, die mischien meer info kan geven over wat er nu precies fout gaat?

En ik neem aan dat PHPMailer de sendmail binary probeert uit te voeren? Staat de PHP configuratie wel zo ingesteld dat dit toegelaten word?

[Kajel]

PHPMailer debuggen is niet echt nodig lijkt me, want ik weet al dat de fout niet daar ligt, maar bij het aanroepen van sendmail. Aangezien sendmail en de map /usr/sbin world read en execute rechten hebben, lijkt het me dat www-data (de apache2 gebruiker) de binary moet kunnen uitvoeren. Of heeft PHP een andere gebruiker onder Debian dan Apache2?

[MueR]

Dit lijkt er op. Mag de user waar apache threads onder draaien wel bij die file komen?

[RobIII]

Als (tijdelijke?) oplossing kun je natuurlijk ook rechtstreeks mailen door IsSMTP() te callen (oid; is even uit m'n blote bol). Dan heb je helemaal geen senmail/exim/postfix nodig.

[ Voor 4% gewijzigd door RobIII op 01-08-2011 10:26 ]

[Kajel]

MueR schreef op maandag 01 augustus 2011 @ 10:17:
Dit lijkt er op. Mag de user waar apache threads onder draaien wel bij die file komen?

Ik gebruik de PHPMailer en niet de ingebouwde mail() functie van PHP. Jouw link heeft me echter wel op het idee gebracht om het script dat PHPMailer aanroept even via de cli te runnen, en dan doet ie t wel!
De aangedragen oplossingen in die thread gaan echter over Fedora, dus weet nog niet helemaal hoe ik dat naar Debian moet vertalen

RobIII schreef op maandag 01 augustus 2011 @ 10:26:
Als (tijdelijke?) oplossing kun je natuurlijk ook rechtstreeks mailen door IsSMTP() te callen (oid; is even uit m'n blote bol). Dan heb je helemaal geen senmail/exim/postfix nodig.

Maar moet ik als ik IsSMTP() wil gebruiken, niet ook een SMPT server meegegeven plus de juiste credentials?

[RobIII]

Kajel schreef op maandag 01 augustus 2011 @ 11:18:


Maar moet ik als ik IsSMTP() wil gebruiken, niet ook een SMPT server meegegeven plus de juiste credentials?

Juiste SMTP server uiteraard; maar dat kan die van je hoster/provider zijn. Credentials wrsch. ook maar dat is afhankelijk van de hoster/provider die je gebruikt.

[MueR]

Kajel schreef op maandag 01 augustus 2011 @ 11:18:
[...]

Ik gebruik de PHPMailer en niet de ingebouwde mail() functie van PHP. Jouw link heeft me echter wel op het idee gebracht om het script dat PHPMailer aanroept even via de cli te runnen, en dan doet ie t wel!
De aangedragen oplossingen in die thread gaan echter over Fedora, dus weet nog niet helemaal hoe ik dat naar Debian moet vertalen

Welk naampje er op het beestje hangt maakt weinig uit, het blijft een linux bak. Ergens op die sendmail staat een access mask die voorkomt dat apache's user (ik gok even op "nobody") dat ding mag aanspreken. Dus je hoster zal even moeten kijken hoe en wat.

[Kajel]

RobIII schreef op maandag 01 augustus 2011 @ 11:48:
[...]

Juiste SMTP server uiteraard; maar dat kan die van je hoster/provider zijn. Credentials wrsch. ook maar dat is afhankelijk van de hoster/provider die je gebruikt.

Niet van mijn provider in ieder geval, omdat ik het niet zelf thuis host. In de OP zei ik al dat het om een VPS gaat. Dan is er neem ik aan geen SMTP van de hoster waar ik aanspraak op kan maken?

MueR schreef op maandag 01 augustus 2011 @ 12:17:
[...]

Welk naampje er op het beestje hangt maakt weinig uit, het blijft een linux bak. Ergens op die sendmail staat een access mask die voorkomt dat apache's user (ik gok even op "nobody") dat ding mag aanspreken. Dus je hoster zal even moeten kijken hoe en wat.

apache's user op Debian heet www-data. Sendmail heeft de volgende permissions:

lrwxrwxrwx 1 root root 5 Jul 31 23:30 sendmail -> exim4

(Het is een symlink naar exim4 zoals je kunt zien)
Als ik het goed begrijp kan iedereen ernaar schrijven, lezen en het executen. Of bedoel je met access mask iets anders?

[MueR]

Nee, ik bedoelde inderdaad de chmod. Die lijkt in ieder geval niet het probleem. Staat er iets in je apache danwel exim error logs toevallig? Het is momenteel een beetje koffiedik kijken

[Kajel]

Exim log geeft niks aan. Is ook logisch want het script kan volgens de foutmelding sendmail (en dus exim) niet uitvoeren, laat staan dat die laatste dan foutmeldingen kan loggen. Apache log levert ook niks op.

Toch heeft jouw suggestie me wellicht op het goede pad gebracht. De php-fpm error log laat namelijk het volgende zien:

Mon Aug 01 13:24:47 2011] [error] [client 78.40.193.155] FastCGI: server "/srv/www/fcgi-bin.d/php5-fpm" stderr: PHP Warning: escapeshellarg() has been disabled for security reasons in /srv/www/bla.nl/publlic_html/PHPMailer/class.phpmailer.php

Ik ben er niet kapot van dat PHPMailer escapeshellarg() (en trouwens ook escapeshellcmd()) nodig heeft om te mailen. Ik ga eerst eens kijken wat de concurrent (Swiftmailer) doet als ik via sendmail een mail wil verzenden. Ik zou (aangezien t om een VPS gaat) de restricties op kunnen heffen, maar ik weet niet hoe, en vraag me vooral af hoe verstandig dat is.

[MueR]

Ik zou niet weten hoe een script via sendmail zou moeten mailen zonder daarvoor de sendmail binary op de server aan te spreken. Dat ze die escape functies gebruiken is juist goed, unescaped parameters in je shell commands kan best wel fout gaan. Waarom run je PHP trouwens als FastCGI ipv als normale apache module?

[Kajel]

Ik draai PHP niet als normale FastCGI, maar als PHP-FPM, wat niet hetzelfde is. De reden dat ik PHP als PHP-FPM draai, is omdat het een stuk sneller werkt dan mod_php onder Apache2, zeker bij een beetje "beefy" site met substantiele traffic.

mod_php spawnt voor elke request naar een PHP file, een nieuw parent proces, wat niet bepaald efficient is.
FastCGI daarentegen draait PHP als permanente daemon, waar de PHP requests naartoe gedelegeerd worden.
PHP-FPM doet daarbij ook nog eens aan goede load balancing en scaling door bij een bepaald aantal concurrent requests een nieuw proces te starten. Zo hoef je niet langs een zooi interne ports te gaan round robin'en in Apache om PHP te load balancen.

[MueR]

Dan gok ik dat het toch ergens in de configuratie van die specifieke manier van php aanspreken. Ik heb geen ervaring met die manier, dus veel zinnigs kan ik er niet over zeggen. Het lijkt ook een community driven engine? Misschien dat er op hun mailinglist wat te vinden is?

[Olaf van der Spek]

MueR schreef op maandag 01 augustus 2011 @ 16:03:
Dan gok ik dat het toch ergens in de configuratie van die specifieke manier van php aanspreken. Ik heb geen ervaring met die manier, dus veel zinnigs kan ik er niet over zeggen. Het lijkt ook een community driven engine? Misschien dat er op hun mailinglist wat te vinden is?

FPM is nu first-party: http://php.net/manual/de/install.fpm.php

[Kajel]

Olaf van der Spek schreef op maandag 01 augustus 2011 @ 16:09:
[...]

FPM is nu first-party: http://php.net/manual/de/install.fpm.php

Ik had het al gelezen ja! Jammer overigens (en offtopic) dat je het bij Debian dan nog steeds uit de unstable repo moet halen

[Olaf van der Spek]

Kajel schreef op maandag 01 augustus 2011 @ 00:04:
Sending mail failed: Language string failed to load: execute/usr/sbin/sendmail

Dit is een nogal onduidelijk foutmelding. Ook wordt er niet aangegeven wat de foutcode nou is.
Je kan dit proberen:

code:

sudo -s
su - www-data
/usr/sbin/sendmail

Maar als sendmail in sbin staat, betekent dat al dat een gewone gebruiker het (eigenlijk) niet kan aanroepen.

Kajel schreef op maandag 01 augustus 2011 @ 16:11:
[...]

Ik had het al gelezen ja! Jammer overigens (en offtopic) dat je het bij Debian dan nog steeds uit de unstable repo moet halen

Daar kan Debian toch weinig aan doen? FPM was gewoon niet op tijd beschikbaar voor de huidige stable release.

[ Voor 27% gewijzigd door Olaf van der Spek op 01-08-2011 16:14 ]

[Kajel]

Opgelost!!
Zie hieronder voor uitleg.

Olaf van der Spek schreef op maandag 01 augustus 2011 @ 16:14:
[...]

Dit is een nogal onduidelijk foutmelding. Ook wordt er niet aangegeven wat de foutcode nou is.
Je kan dit proberen:

code:

sudo -s
su - www-data
/usr/sbin/sendmail

Maar als sendmail in sbin staat, betekent dat al dat een gewone gebruiker het (eigenlijk) niet kan aanroepen.

Die foutmelding kwam uit een door de applicatie gegenereerde error log. De error die mijn testscript kreeg van PHPMailer was al een stuk duidelijker:

Mailer Error: Could not execute: /usr/sbin/sendmail

De doorslag kwam van de error.log van PHP zelf:

Mon Aug 01 13:24:47 2011] [error] [client 78.40.193.155] FastCGI: server "/srv/www/fcgi-bin.d/php5-fpm" stderr: PHP Warning: escapeshellarg() has been disabled for security reasons in /srv/www/bla.nl/publlic_html/PHPMailer/class.phpmailer.php

Ik heb uiteindelijk de restricted commando's gevonden in php.ini bij de setting

disable_functions

en deze daar weggehaald. Dit was de oplossing!

Ik ga vanavond wel even kijken of SwiftMailer het allemaal wat netter doet, want PHPMailer gebruikt ook nog de popen functie die direct het proces aanspreekt, en popen staat bij standaard ook in de disable_functions in de php.ini. Daar zal vast een goede reden voor zijn

[...]

Daar kan Debian toch weinig aan doen? FPM was gewoon niet op tijd beschikbaar voor de huidige stable release.

Klopt, hoewel ze wel wat traag zijn in het accepteren van dingen die al lang stabiel zijn. Zoals recente versies van GD2 lib van de makers zelf.