05-Apr-2018

Maintenance
Monthly maintenance on April 2st shows no surprises, except the low number of relay attempts:
PMAS statistics for March
Total messages    :   2696 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    218 =   8.0 o/o (Files: 31)
Accepted by PMAS  :   2478 =  91.9 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1741 =  70.2 o/o (processed),  64.5 o/o (all)
         Accepted :    173 =   6.9 o/o (processed),   6.4 o/o (all)
  Handled by content
        Discarded :    422 =  17.0 o/o (processed),  15.6 o/o (all)
     Quarantained :    126 =   5.0 o/o (processed),   4.6 o/o (all)
        Delivered :     16 =    .6 o/o (processed),    .5 o/o (all)

There was just one log of relay attempts significantly larger than the rest: Most were either empty or just 4 blocks in size (the minimum , could take just a few lines). This one was 56 blocks (28 KB) holing 190 records, sent from
21:10:43.65 to 21:14:46.53, sent from address 104.168.140.209, sender “{fake, of course)@grootersnet.nl” trying to reach locotrones1029@gmail.com. Again, the address seems to belong to HostsWinds.com.

Software updates
Triggered by the fact that the secured sites had access issues yesterday (invalid certificate date) and messages on the WASD mailing list concerning issues with WCME (entry 32 and up) I knew I had to update WCME to renew the certificates. Mark had also posted a mail on a new WASD version (and therefore, ALAMODE, the real-time monitor); Checking the site I found that there was also a newer release of MonDesi (the real-time web-based system monitor) so I decided to get WCME directly and install and run it.
Checking the system however, there was no WCME-program running – and there should be one: WCME-overseer. The last log file it would create as from January this year, and I restarted the system in February So the process hadn’t run for two months. No problem, since all it does is check the date of the certificates and if these are about to expire, run the WCME-program to create new ones.
And that hadn’t been done, obviously.
To find out why, I executed the line in the server-startup procedure to get it running. But time after time it failed; No logfile, though I requested one. Next step is to analyze the audit log – and behold:
Security alarm (SECURITY) and security audit (SECURITY) on DIANA, system id: 21505
Auditable event:          Detached process login failure
Event time:                4-APR-2018 19:51:24.72
PID:                      2020FDA4
Process name:             WCME-startup
Username:                 HTTP$NOBODY
Process owner:            [HTTP$NOBODY]
Image name:               $116$DKA100:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Posix UID:                -2
Posix GID:                -2 (%XFFFFFFFE)
Status:                   %RMS-E-PRV, insufficient privilege or file protection violation

I changed the command line to use SYSTEM – and that caused WCME-overseer to run. Auto-renewal should now happen – overnight. This morning, I indeed got the message that certificate renewal had been successful – but the sites still had problems. Reason: The new certificates were not copied to the right spot, I have a procedure to take care of that, it may have run but was looking to the wrong location. Changed that, and the certificates are now on the right spot. But I needed to restart the server to accept the new licences: Only after an update of the server, this could be done without restarting the server….Anyway, after that the sites were accessible as they should be.

So now came the update of WASD, OPENMSSL and ALAMODE – which went flawlessly as before – only that $ httpd/do=exit didn’t work as expected, as I found out after I started the new version: Still got the old server, when accessing the admin pages….Killed it using stop/id, the new server (running but in ‘starting’ mode) got on directly and was running fine. Alamode worked fine as well, once it was properly installed.

The next to be updated was the system monitor MonDeSi – np problems here either, except that, for some reason, a $ httpd/do-restart was required to get the new version running. Probably an issue with caching …

The next update is WordPress – version 4.9.5 – which should cause no problems.

Update
Wordpress has been updated to 4.9.5 – as well as Akismet (4.0.3)

Leave a Reply

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