01-Sep-2016

Monthly maintenance
No surprises, except a large number of relay attempts:

PMAS statistics for August
Total messages    :   4188 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :   2549 =  60.8 o/o (Files: 31)
Accepted by PMAS  :   1639 =  39.1 o/o (Files: 31)
  Handled by explicit rule
         Rejected :    678 =  41.3 o/o (processed),  16.1 o/o (all)
         Accepted :    203 =  12.3 o/o (processed),   4.8 o/o (all)
  Handled by content
        Discarded :    325 =  19.8 o/o (processed),   7.7 o/o (all)
     Quarantained :    250 =  15.2 o/o (processed),   5.9 o/o (all)
        Delivered :    183 =  11.1 o/o (processed),   4.3 o/o (all)

Relay attempts were mainly on one day (23-Aug) between 04:16 and 08:28 UTC; all I all 2401 attempts from one address: 157.122.147.4, but this network should not have access: I added a rule to lock tor this network but using the first 16 bits (/16). perhaps there are more masks possible so I’ll have to rule them out one by one.

There have been a few quirks since the last updates, though.
First, it turned out that my throttle-rule on /downloads blocked all access – and what I didn’t see is that there seemed to be eight sessions open, so Google got a 503 error – and signalled a raising number of errors, so I looked at this. The admin page gave one open request on this location, contacted the mailing list and learned there were more: 8 toe be precise, and by that, GoogleBot got this error. That cannot be noticed any more, so I will have to re-enable the line again and monitor what’s going on.

Second, the procedure that should cycle SYSLOGD.LOG – holding log output from the router – every 25000 blocks, didn’t work, where it has in the past. It mayu be caused by the fact that SYSLOGD should close and reopen this file once in a while, so

$ eof=f$file_attributes("sman:[tools.syslogd]syslogd.log;0","EOF")

would set eof to the current size of the file.

However, there must have been an alteration somewhere for some reason. The file isn’t closed so eof remains zero. Given the creation time of the file, this has been the case since 19-Jun-2016, and now the file is more than 600.000 blocks in size.

Or I simply was mistaken; I changed this to

$ eof=f$file_attributes("sman:[tools.syslogd]syslogd.log;0","ALQ")

so eof now holds the number of allocated blocks, no matter whether the file is closed and reopened, or not. If this exceeds the limit, the log file is cycled. This has now happened twice – given the version numbers – and the logs archive.

And today I added (and antidated) a new entry about the publication of our Corfu trip, two years ago.
Bootcamp ahead

Countdown: 19 days to go before flying to Boston 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.