After OS update, daily digest Emails stopped

P

phantomflash

I used freebsd-update to update from 8.2-RELEASE to 8.4-RELEASE. Then I noticed the daily and weekly digest Emails I used to get, giving system and security information, were no longer coming to me. How do I turn them back on?
 
Check /var/log/cron and see if the scripts are actually being executed. Then have a look in /var/log/maillog to see if the emails are perhaps stuck and not being sent to the correct user.

I've noticed after some upgrades you need to run newaliases(1) or things will stop working.
 
All I can say is that I have one machine with the same problem:
Code: 
root@kg-vm2# mailq
     /var/spool/mqueue (4 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
s9H56qlX035068  1979 Fri Oct 17 07:06 MAILER-DAEMON
  (Deferred: Connection refused by kg-vm2.kg4.no.)
            <root@kg-vm2.kg4.no>
s9H56qlY035068  4339 Fri Oct 17 07:06 MAILER-DAEMON
  (Deferred: Connection refused by kg-vm2.kg4.no.)
            <root@kg-vm2.kg4.no>
s9H114OY034602  290 Fri Oct 17 03:01 <root@kg-vm2.kg4.no>
  (Deferred: Connection refused by kg-vm2.kg4.no.)
            <root@kg-vm2.kg4.no>
s9H114lW034637  2653 Fri Oct 17 03:01 <root@kg-vm2.kg4.no>
  (Deferred: Connection refused by kg-vm2.kg4.no.)
            <root@kg-vm2.kg4.no>
     Total requests: 4
it was upgraded to FreeBSD 8.4-STABLE:
Code: 
root@kg-vm2# uname -a
FreeBSD kg-vm2.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r270837: Sat Aug 30 13:25:23 CEST 2014
  root@kg-vm2:/usr/obj/usr/src/sys/GENERIC  amd64
and newaliases has been run:
Code: 
root@kg-vm2# ls -l /etc/mail/ali*
-rw-r--r--  1 root  wheel  1688 Aug 30 17:22 /etc/mail/aliases
-rw-r-----  1 root  wheel  65536 Sep  2 10:03 /etc/mail/aliases.db
All the relevant configuration files look ok to me, and sendmail is running:
Code: 
root@kg-vm2# pgrep -lf sendm
517 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue
514 sendmail: accepting connections
but still it doesn't work.
 
SirDice said:
Check /var/log/cron and see if the scripts are actually being executed. Then have a look in /var/log/maillog to see if the emails are perhaps stuck and not being sent to the correct user.

I've noticed after some upgrades you need to run newaliases(1) or things will stop working.
Click to expand...

Thanks for your suggestions. I have determined that the mails are stuck. I did run newaliases as you suggested but it didn't help. The mail log contains many entries of the form

Code: 
Oct 17 15:11:06 secure sm-mta[10313]: s9D818ZK062306: to=myname@mydomain.com, ctladdr=<root@secure.mydomain.com> (0/0), delay=4+12:09:58, xdelay=00:00:00, mailer=esmtp, pri=20372552, relay=mailgateway.mydomain.com., dsn=4.0.0, stat=Deferred: Name server: mailgateway.mydomain.com.: host name lookup failure

secure is the server trying to send. mailgateway is the correct mail server. I can telnet to it on port 25 (using its name) and send mail. But sendmail can't.

I have looked at many different web pages having suggestions about the "host name lookup failure" message. I've rechecked everything from the IP address, the subnet mask, default gateway, etc. I've done digs to check the MX record in DNS and it looks OK. (We have a separate DNS server on the network.) I've checked everything suggested here: http://www.onlamp.com/pub/a/BSD/2004/05/13/freebsd_basics.html I've also gone further and put the mail server in the hosts file, and put an entry in mailertable and I still get the same error message in the mail log.

What could be going on? Remember this worked fine before the version update, and has never worked since -- so it seems impossible to be caused by any external changes.

Looking at the log message, I see it seems to be saying it thinks the name server is mailgateway.mydomain.com. It's not. The name server is dc.mydomain.com. So I have two questions about this:
  1. Is that really what this log syntax means? Or does mean something else (such as it is getting the name mailgateway.mydomain.com from the name server's MX record)?
  2. Is it important that there is a period after this name in the log?
 
For some reason, sendmail on your machine seems to think that mailgateway... is a name server. You should figure out why.
 
With regards to my machine with the same problem, I forgot to show that I can easily flush the mail queue with sendmail:
Code: 
root@kg-vm2# sendmail -q -v
Running /var/spool/mqueue/s9J56qDc040763 (sequence 1 of 4)
<root@kg-vm2.kg4.no>... Connecting to local...
220 kg-vm2.kg4.no LMTP ready
>>> LHLO kg-vm2.kg4.no
250-kg-vm2.kg4.no
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
>>> MAIL From:<>
250 2.5.0 Ok
>>> RCPT To:<root>
>>> DATA
250 2.1.5 Ok
354 Go ahead
>>> .
250 2.1.5 root Ok
<root@kg-vm2.kg4.no>... Sent

Running /var/spool/mqueue/s9J56qDd040763 (sequence 2 of 4)
>>> RSET
250 2.0.0 Ok
<root@kg-vm2.kg4.no>... Using cached LMTP connection for local...
>>> MAIL From:<>
250 2.5.0 Ok
>>> RCPT To:<root>
>>> DATA
250 2.1.5 Ok
354 Go ahead
>>> .
250 2.1.5 root Ok
<root@kg-vm2.kg4.no>... Sent

Running /var/spool/mqueue/s9J114Oq040297 (sequence 3 of 4)
>>> RSET
250 2.0.0 Ok
<root@kg-vm2.kg4.no>... Using cached LMTP connection for local...
>>> MAIL From:<root@kg-vm2.kg4.no>
250 2.5.0 Ok
>>> RCPT To:<root>
>>> DATA
250 2.1.5 Ok
354 Go ahead
>>> .
250 2.1.5 root Ok
<root@kg-vm2.kg4.no>... Sent

Running /var/spool/mqueue/s9J114Db040332 (sequence 4 of 4)
>>> RSET
250 2.0.0 Ok
<root@kg-vm2.kg4.no>... Using cached LMTP connection for local...
>>> MAIL From:<root@kg-vm2.kg4.no>
250 2.5.0 Ok
>>> RCPT To:<root>
>>> DATA
250 2.1.5 Ok
354 Go ahead
>>> .
250 2.1.5 root Ok
<root@kg-vm2.kg4.no>... Sent
Closing connection to local
>>> QUIT
221 2.0.0 Bye
you have mail
So I really don't understand why it is complaining.
 
tingo said:
For some reason, sendmail on your machine seems to think that mailgateway... is a name server. You should figure out why.
Click to expand...

So are you answering "yes" to question 1 (does the log really mean what it seems to be saying) and "no" to question 2 (is the period after the name important)?

Assuming that's the case, well, yeah, that's exactly what I've been trying to figure out for a couple of days. I'm not a sendmail expert, but I have done a grep to find all occurences of "mailgateway" or "nameserver" in all config files in /etc and all subdirectories, and there is none at all in any sendmail config file. In fact the only occurrences of "mailgateway" are those I've added while trying to troubleshoot and fix the problem.

How would sendmail possibly think it's a name server, different from what everything else on the system thinks? Remember I can do a dig and it uses the correct nameserver (which happens to be at 192.168.14.4). Here is the contents of the resolv.conf and nsswitch.conf files, which according to what I've read, are supposed to control nameservers for the entire system:

Code: 
secure# cat resolv.conf
domain  mydomain.com
nameserver  192.168.14.4
nameserver  127.0.0.1
secure#
secure#
secure# cat nsswitch.conf
#
# nsswitch.conf(5) - name service switch configuration file
# $FreeBSD: release/8.4.0/etc/nsswitch.conf 158266 2006-05-03 15:14:47Z ume $
#
group: compat
group_compat: nis
hosts: files dns
networks: files
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
secure#

(I added the second nameserver line 127.0.0.1 to resolv.conf myself as a test of this problem.)

And moreover, remember it has to be something that was changed by the OS version update process.
 
That is a yes to question 1; yes. :)
What happens if you do nslookup mailgateway on the machine (the machine where the problematic sendmail is running)? And do a nslookup dc as well.
 
tingo said:
That is a yes to question 1; yes. :)
What happens if you do nslookup mailgateway on the machine (the machine where the problematic sendmail is running)? And do a nslookup dc as well.
Click to expand...

Code: 
secure# nslookup mailgateway
Server:  192.168.14.4
Address:  192.168.14.4#53
Name:  mailgateway.mydomain.com
Address: 192.168.14.70
 
secure#
 
 
 
secure# nslookup dc
Server:  192.168.14.4
Address:  192.168.14.4#53
Name:  dc.mydomain.com
Address: 192.168.14.4
 
secure#

See why I'm mystified?

Since my last post I have determined that I can send mail to other domains, not just our own domain. This means sendmail really is finding the name server and using it. It just can't seem to find what the name server's MX record points to. But the data is right there:

Code: 
secure# nslookup -query=mx mydomain.com
Server:  192.168.14.4
Address:  192.168.14.4#53
mydomain.com  mail exchanger = 10 mailgateway.mydomain.com.
 
secure#

Once again however I should ask about that period after the name. Is it supposed to be there or not?


[After posting the above, I tried another nslookup of mailgateway.mydomain.com with the period after the name, and it got the same results as without the period. In addition, when I look up the MX records of other domains (successfully Emailed to), they also come back with trailing periods.]
 
Here is an update -- I have now found a workaround.

As I mentioned, after much testing, I eventually discovered sendmail could send to other domains but not to ours. After a while I realized this means it could work with other domains’ DNS servers but not our DNS server.

I thought maybe the difference was using the outward-facing IP address instead of the internal one, but that wasn’t it. Even when I set our internal DNS to tell it to use the external mail server IP, it didn’t work. However using an external DNS, to tell it to use the external mail IP, does work.

So I edited resolv.conf to tell the server to use our ISP's name servers instead of ours, and then I started getting mail from it (the latest log messages, plus hundreds of backlogged ones).

The downside is that the server now doesn’t know how to talk to the other computers on our LAN, since it can’t get their internal IP addresses from our DNS. But we can work around that by editing the hosts file to define any addresses we may need from time to time. (Editing the hosts file didn’t help the sendmail problem.) And if we ever figure out what’s causing our DNS to be distasteful to sendmail, we can change it back.

If this gives anybody any clues to a permanent fix, feel free to let me know. No other machine has a problem with our DNS, and 8.2 didn't have a problem either -- only when we went to 8.4.
 
You must log in or register to reply here.
Back
Top