Maintenance
Most of the standard work (collecting and saving logfiles) is now carried out by a DCL procedure. One of the things it does is getting the mail statistics of last month:
PMAS statistics for July
Total messages : 8495 = 100.0 o/o
DNS Blacklisted : 1807 = 21.2 o/o (Files: 31)
Relay attempts : 5557 = 65.4 o/o (Files: 31)
Processed by PMAS : 1131 = 13.3 o/o (Files: 30)
Discarded : 148 = 13.0 o/o (processed), 1.7 o/o (all)
Quarantained : 344 = 30.4 o/o (processed), 4.0 o/o (all)
Delivered : 639 = 56.4 o/o (processed), 7.5 o/o (all)
The number of blocks in the anti-relay logs show there have been many attempts, it will (for now) signal all files that are 4 blocks, or more, in size. For July, the result is:
PTSMTP_ANTIRELAY.LOG-2010-07-02 is 4 blocks: check file ANTIRELAY.-2010-07-02
PTSMTP_ANTIRELAY.LOG-2010-07-03 is 513 blocks: check file ANTIRELAY.-2010-07-03
PTSMTP_ANTIRELAY.LOG-2010-07-05 is 172 blocks: check file ANTIRELAY.-2010-07-05
PTSMTP_ANTIRELAY.LOG-2010-07-06 is 190 blocks: check file ANTIRELAY.-2010-07-06
PTSMTP_ANTIRELAY.LOG-2010-07-08 is 176 blocks: check file ANTIRELAY.-2010-07-08
PTSMTP_ANTIRELAY.LOG-2010-07-09 is 4 blocks: check file ANTIRELAY.-2010-07-09
PTSMTP_ANTIRELAY.LOG-2010-07-14 is 90 blocks: check file ANTIRELAY.-2010-07-14
PTSMTP_ANTIRELAY.LOG-2010-07-19 is 196 blocks: check file ANTIRELAY.-2010-07-19
PTSMTP_ANTIRELAY.LOG-2010-07-23 is 5 blocks: check file ANTIRELAY.-2010-07-23
That will be done with another script, one day. But I’ve already analyzed the bigger ones before.
The PMAS logs however were not archived – not in the right location. Checking the command procedure, this is obvious: the line would never execute…
The operator logs have been archived – except for the last one, but that might have been in process at the time, soi the expected file didn’t yet exist (operator.log is renamed when processed). Since it’s hard to predict, the job will now start 30 minutes after midnight (I could of course synchronize with the log scanner – but that requires a lot of extra work – where this works as fine)
Saving the WASD logfiles processed the wrong files: the ones of June are archived in the July archive.
Corrected the scripts and re-run it, just a few other ones to take care about, but now it does the job.
Cleanup afterwards now works as well.
Wait for the next run to complete: on 01-Sep-2010.
Syslogd not started
Because I needed to find something out, I screened the current SYSLOGD log file – and found the latet entry has been just before reboot on 17-Jul-2010. Watching the system, there wasn’t a syslod process running, and the service was disabled. So I added the line to start the service to the startup script, started the service and sent a message using Logger. Now the daemon runs.
New licenses loaded
Latest licenses – valid through March 2011 – have been loaded. Next, get a new PMAS license befeore the current one expires: 02-Sep-2010.