This may be related to bug 10931. when sending a test e-mail from mail.cgi, screen blanks and no mail is sent. /var/log/http/error_log says: can't exec : No such file or directory, referer: https://router:444/cgi-bin/mail.cgi error closing : (exit 512), referer: https://router:444/cgi-bin/mail.cgi (I removed the date/[error] and client IP address_ The configuration screen has TLS turned on and port 587. This is a commercial mail server and I have verified connectivity from the router to the mail server (via telnet). firewall/router has been in use for a while, and has gone through at a few updates already. The following log entries may or may not be related. I believe they are the result of my hitting the refresh button? mail.cgi: Use of uninitialized value in string eq at /srv/web/ipfire/cgi-bin/mail.cgi line 83. mail.cgi: Use of uninitialized value in string eq at /srv/web/ipfire/cgi-bin/mail.cgi line 140. mail.cgi: Use of uninitialized value $cgiparams{"update"} in string eq at /srv/web/ipfire/cgi-bin/mail.cgi line 152. mail.cgi: can't exec : No such file or directory, referer: https://router:444/cgi-bin/mail.cgi target mail server log on target shows nothing in the mail log. Steps to reproduce: Services | Mail Service Enter all information, setting mailserver port to 587 and Use TLS to enabled. Using Authenticated SMTP, fill in Username and Password. Click Send testmail (before clicking Save button) Blank screen appears with no error message Refresh screen and configuration page appears Click Save Click Send testmail Blank screen appears Tested with chromium Version 37.0.2062.120 Built on Debian 7.6, running on Debian 7.8 (281580) (64-bit) Firefox 37.0.2 Debian Linux "Wheezy" using xfce4 desktop
I am sorry but i am not able to comprehend this issue. As stated, the system runs some time already and got several updates. The DMA part is actually not a final release, it is in the testing tree. Depending on the time, when the update from the next tree was installed, it is possible that an unstable version was updated which leads to the error. It is not possible to click on "send testmail" before the settings are saved. As a shoot in the sky i would recommend to check the filepermissions on the file /var/ipfire/dma/mail.conf this should be owned by nobody. I recommend to clean that file (empty), give it nobody.nobody permissions and retry the whole procedure again.
I cleaned out the configuration and redid it as suggested. The same problem occurred. I looked at your code a little, and noticed you are using send_by_sendmail from the MIME::Lite module. That uses sendmail, so I went looking for it and found it in /usr/sbin/sendmail. That is a symbolic link to /etc/alternatives/sendmail. /etc/alternatives does not exist on my system, so the symbolic link points to a null location. This is consistent with the error message from /var/log/error_log stating can't exec : No such file or directory, I found /usr/share/logwatch/scripts/services/sendmail which appears to be a Perl script that replicates sendmail. I tried pointing to that and again had no results. Then, I discovered the link sendmail.dma -> dma so I pointed sendmail to that. At that point, it worked (I received an e-mail at the target host). It appears that, on my system, sendmail is a null link (to /etc/alternatives/sendmail, and /etc/alternatives does not exist). However, once I changed the link to point to /sbin/dma, it worked. Let me know what I can do to make sure no one else has to go through this. This is a truly excellent function.
Hi! It seems that you updated from a very early development state. But you found nearly the right solution. sendmail.dma should be linked to /usr/bin/sendmail which is created from update-alternatives. In a early development state this has not worked as i remember. In the actual core 94 this should work fine though. The files are created correctly if you install one of the nightly builds. If i have some time i will test the update process from core 93 to 94 myself. But i think the error does not remain anymore. But before closing this Bug i try to test it to be safe. Thank you for the feedback.
After upgrade to Core95 the error appears again.
I believe, in my case, the error occurs because Daniel and I are both beta testers. We upgraded to 94, found a bug, then it was fixed in the release, but I, definitely, did not fix it correctly (ie, did not back off, then upgrade again). I built a new machine using 94 (fresh install) and it worked correctly. I then upgraded to 95 and again, it worked correctly. I seriously thing this is not a bug on release, but a bug that was caused by the testing. However, if you want to validate that future upgrades are taken care of, you could simply include a check for the error condition as follows: if [ ! -d /etc/alternatives ] then mkdir /etc/alternatives && chmod 755 /etc/alternatives ln -s /usr/sbin/sendmail.dma /etc/alternatives/sendmail fi However, I think this is limited to Daniel and I, from what I've seen so far. Rod
Hi Rod Rodolico, Well nearly exactly these lines where added to core 94, after the BUG was reported... It seems you managed to get somehow around the fix due to changing from testing to production or other way round. I think we can close this one. It is not a Bug anymore.