| Summary: | Core 94. Test e-mail returns error. | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Rod Rodolico <rodo> |
| Component: | --- | Assignee: | Alexander Marx <alexander.marx> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | - Unknown - | CC: | daniel.weismueller, michael.tremer |
| Version: | 2 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
|
Description
Rod Rodolico
2015-10-01 00:08:24 UTC
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. |