06-Jan-2019

Update to WASD
Checking the WASD server log las week, I noted that WASD had silently crashed and restarted several times since last update:
%HTTPD-F-SOFTWAREID, HTTPd-WASD/11.3.0 OpenVMS/AXP SSL
-HTTPD-F-WHEN, 12-DEC-2018 19:32:30.98
-HTTPD-F-WHERE, module:VM line:939
-HTTPD-F-WHAT, lib$get_vm()
%HTTPD-F-EXIT, 12-DEC-2018 19:32:31, WASD:80 %X10158264
-HTTPD-F-TRACE, FFFFFFFF800880D8
-HTTPD-F-TRACE, 0000000000239F74
-HTTPD-F-TRACE, 0000000000388658
-HTTPD-F-TRACE, 00000000001B8398
-HTTPD-F-TRACE, 00000000001A1CDC
-HTTPD-F-TRACE, FFFFFFFF80189210
-HTTPD-F-TRACE, FFFFFFFF801635E4
-HTTPD-F-TRACE, 0000000000264784
-HTTPD-F-TRACE, 0000000000262F74
-HTTPD-F-TRACE, FFFFFFFF80E77718
-HTTPD-F-TRACE, FFFFFFFF80E50444
(all requests that were loaded at that time, or last 100?)
-HTTPD-F-ADIEU, ...
$ httpd /priority=4 /SYSUAF=RELAXED
%HTTPD-I-SOFTWAREID, HTTPd-WASD/11.3.0 OpenVMS/AXP SSL
WASD VMS Web Services, Copyright (C) 1996-2018 Mark G.Daniel.
This package (all associated programs), comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version.
http://www.gnu.org/licenses/gpl.txt
%HTTPD-I-IMAGE, HTTPD_SSL 11.3.0 09-DEC-2018 19:04:04.31 $116$DKA100:[WEB.WASD_ROOT.][AXP]HTTPD_SSL.EXE
%HTTPD-I-STARTUP, 12-DEC-2018 19:32:47
%HTTPD-I-ALIGN, start collecting alignment faults (64kB,128,0xFFFFFFF0)
%HTTPD-I-WASD_ROOT, $116$DKA100:[WEB.WASD_ROOT]
%HTTPD-I-ENVIRONMENT, 1
%HTTPD-I-SYSTEM, AlphaServer DS10 617 MHz VMS V8.4
%HTTPD-I-TCPIP, HP TCPIP$IPC_SHR V5.7-ECO5 (08-NOV-2014 13:06:10.02)
%HTTPD-I-MODE, OTHER
%HTTPD-I-ODS5, supported by Alpha VMS V8.4
%HTTPD-I-ODS, directory parser enabled
%HTTPD-I-GMT, +00:00
%HTTPD-I-INSTANCE, supervisor
%HTTPD-I-GZIP, using LIBZ_SHR32 V1.2.3
%HTTPD-I-GBLSEC, existing global section of 32 page(let)s
...

Noted Mark Daniels, he supplied a set of sources that have been updated due to other and this issue, got these, installed them, recompiled the server and installed it (version 11.3.0a).

See if the issue is solved, during the next weeks.

01-Jan-2019

New Year cleanup
2018’s last mail statistics:

PMAS statistics for December
Total messages  :  2269 = 100.0 o/o
DNS Blacklisted  :   0 =  .0 o/o (Files: 0)
Relay attempts  :  270 = 11.8 o/o (Files: 31)
Accepted by PMAS :  1999 = 88.1 o/o (Files: 31)
 Handled by explicit rule
     Rejected :  1374 = 68.7 o/o (processed), 60.5 o/o (all)
     Accepted :  142 =  7.1 o/o (processed),  6.2 o/o (all)
 Handled by content
    Discarded :  289 = 14.4 o/o (processed), 12.7 o/o (all)
   Quarantained :  169 =  8.4 o/o (processed),  7.4 o/o (all)
    Delivered :   25 =  1.2 o/o (processed),  1.1 o/o (all)

Just one day with a larger amount of relay attempts – as usual, it seems, using bogus grootersnet.nl senders from Hostwinds.com, trying to reach that single gmail address:

14-DEC-2018 01:03:27.69 - 01:07:32.90 (242 entries) from 108.174.197.195

All files that were created in 2018 have now been moved to their archive directory, ready to be stored offline.

Blocked sites
The last few weeks there is a new spammer on the block, sending via, or from, Amazon AWS servers. Also, some AWS connections were trying to access the webserver with over 50 connections, port by port. What I found out in the logfiles, have now been blocked in the router, in order to block that type of applications altogether, when arriving via Amazon.

This has been done with quite a number of sites last year, causing a significant drop in spam messages, but the router could be quite busy when these sites try to get in continuously. The plan is to notify these (otherwise well-behaving) providers that their systems are used by ill-behaving clients, but whether that will prevent problems remains to be seen.

DHCP trouble
Last week, I tried to cleanup DHCP a bit, because there should be one address for most services: the cluster alias. But where this works fine, it made the DHCP server non-responsive. No errors, no logging, it just didn’t react on requests. So I revered one or two settings to be Diana, and now it does work again… In retrospect, I may have known: the default location of the protocol-environment is SYS$SYSDEVICE:[TCPIP$DHCP] where other services reside on SYS$SPECIFIC:.