Tracking Center: "No Data in Database"

[thedab101]

Hi all,
I've discovered something strange: the tracking center shows "No Data in Database". This started two days ago, and the only change that was made recently was securing Exchange's web properties with Duo 2FA. I'm not sure if this is causing the tracking centre to return no data. I've done some preliminary research and a year ago, it looked like cycling the logs and restarting the logging service would fix the problem. I did that (and kicked the server) and that hasn't resolved the issue.

Running v7.3.8, and fully up to date on the non-prod repo. (I ran an update on the test repo in case there was some sort of update but there wasn't).

Is anyone else experiencing this issue? It looked like it was resolved last year with a service pack, but I'm not sure what (other than Duo - which shouldn't be interfering with the traffic between Exchange and PMG) would cause it today.

Any help is greatly appreciated.
Thanks.

 

[Stoiko Ivanov]

the data for the Tracking Center is read from /var/log/syslog (and rotated variants) - what's in those files? - when does /var/log/syslog start?
How does your /etc/rsyslog/rsyslog.conf look like, how does your logrotate config look like?

 

[thedab101]

The syslog contains (outside of a warning about ClamAV being outdated, and a message that usually gets stuck in queue from a particular valid sender - a non issue right now) actual entries of junk messages and legitimate messages, as did the previous logs. I purged the log yesterday, so it starts from the 12th around 8pm when I purged it, but I compared it to the previous logs and at the first few glances and reading, they both appear to report email messages the same.

Here's the rsyslog.conf, which looks like the default:
# /etc/rsyslog.conf configuration file for rsyslog # # For more information install rsyslog-doc and see # /usr/share/doc/rsyslog-doc/html/configuration/index.html ################# #### MODULES #### ################# module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support #module(load="immark") # provides --MARK-- message capability # provides UDP syslog reception #module(load="imudp") #input(type="imudp" port="514") # provides TCP syslog reception #module(load="imtcp") #input(type="imtcp" port="514") ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Where to place spool and state files # $WorkDirectory /var/spool/rsyslog # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg :omusrmsg:*

And log rotate config looks like the default (neither of these files have been changed):

/var/log/syslog /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }

 

[Stoiko Ivanov]

On a quick look - the configs indeed look right - could you please share some of the lines from /var/log/syslog (anonymize addresses if you want, but leave the rest as intact as possible)

 

[thedab101]

I've attached the log to this message. Once you've reviewed them please let me know so I can delete them from this message.
I've included the current log and backed up log.

 

[Stoiko Ivanov]

I deleted the logs for you - and took a look

The looks look ok as well on first sight - but there are really very few mails going through the PMG - and those that do get through seem to not be able to get delivered (connection timeouts when reaching the outbound server - or temporary reject, and permanent rejects due to a wrong realying configuration)..

So - make sure you search in a long-enough time-frame last mail I found in syslog entered here:

Sep 13 04:04:31 pmg postfix/smtpd[3673]:

and it had an empty sender - so make sure to search at least from 12.09.2023 and to check 'include empty senders'

 

[thedab101]

I deleted the logs for you - and took a look

The looks look ok as well on first sight - but there are really very few mails going through the PMG - and those that do get through seem to not be able to get delivered (connection timeouts when reaching the outbound server - or temporary reject, and permanent rejects due to a wrong realying configuration)..

So - make sure you search in a long-enough time-frame last mail I found in syslog entered here:

Sep 13 04:04:31 pmg postfix/smtpd[3673]:

and it had an empty sender - so make sure to search at least from 12.09.2023 and to check 'include empty senders'

Thanks for deleting the logs.
There were not a ton of mail the last few days - but I did send a few test messages. (The relaying errors you're referring to I'm aware of, I haven't prioritized fixing that yet - I use Exchange/PMG primarily for home and some business use).
I did check the "include empty senders" which shows results, but it's stopped showing anything with an email address in the "from" column in the last two days. And I don't see the test messages I sent from gmail. I search far back enough (beyond two days ago) and see a normal display in the tracking viewer (a from address, a to address, time and status).

 

[Stoiko Ivanov]

I did check the "include empty senders" which shows results, but it's stopped showing anything with an email address in the "from" column in the last two days. And I don't see the test messages I sent from gmail. I search far back enough (beyond two days ago) and see a normal display in the tracking viewer (a from address, a to address, time and status).

the 3 messages to gmail-addresses in syslog and syslog.1, which you attached were all from <> (meaning had an empty sender)

 

[thedab101]

I'm seeing the same behaviour now, now that the day has started: valid email messages have an empty sender. What could be causing this behaviour?

 

[thedab101]

The reason for this concern is that this is normally expected when I visit the tracking centre: I see no data whatsoever, when I normally did (without the checkbox selected to show empty senders). It's an important at-a-glance tool, so I'd like to know if I've done something wrong.

 

[Stoiko Ivanov]

I'm seeing the same behaviour now, now that the day has started: valid email messages have an empty sender. What could be causing this behaviour?

The mails arrive with an empty sender from T05.yourdomain.ca - so probably a configuration on that system
(see the line in your syslog that starts with `Sep 13 01:02:32 pmg postfix/smtpd[2287]:`)