Month: September 2016

Mail problems
After PMAS was updated, it struck me that there were no quarantained of discarded messages. As it turned out, no valid ones either: no wonder: the PMAS worker processes kept stopping:

%%%%%%%%%%% OPCOM 10-SEP-2016 18:36:29.70 %%%%%%%%%%%
Message from user INTERnet on DIANA
INTERnet ACP SMTP Accept Request from Host: 192.168.0.2 Port: 62502

%%%%%%%%%%% OPCOM 10-SEP-2016 18:42:57.12 %%%%%%%%%%%
Message from user INTERnet on DIANA
INTERnet ACP SMTP Accept Request from Host: 192.168.0.2 Port: 62504

%%%%%%%%%%% OPCOM 10-SEP-2016 18:55:18.14 %%%%%%%%%%%
Message from user SYSTEM on DIANA
%PTSMTP-I-CTRLEXIT, PTSMTP exiting
-PTSMTP-I-EXITREQUESTED, exit requested by operator

%%%%%%%%%%% OPCOM 10-SEP-2016 18:55:18.14 %%%%%%%%%%%
Message from user SYSTEM on DIANA
%PTSMTP-I-DBSTATUS, status for configuration PMAS_ROOT:[DATA]PTSMTP.CONF:
Total of 4763 connections accepted; 2 workers currently active
Pid Process Name State Connections Serviced
20244067 PTSMTP 0001 exiting 3711
20245D68 PTSMTP 0002 exiting 343


Here, I’ve done the update – without any configuration changes. Then started PMAS again

%%%%%%%%%%% OPCOM 10-SEP-2016 19:04:21.24 %%%%%%%%%%%
Message from user WILLEM on DIANA
%PTSMTP-I-STARTING, PTSMTP for OpenVMS 1.0-1 starting

%%%%%%%%%%% OPCOM 10-SEP-2016 19:04:21.29 %%%%%%%%%%%
Message from user WILLEM on DIANA
%PTSMTP-I-STARTDB, starting configuration for file PMAS_ROOT:[DATA]PTSMTP.CONF:
-PTSMTP-I-LISTENON, listening for connections on 0.0.0.0,2525
-PTSMTP-I-RUNWITH, running with from 2 to 10 workers

%%%%%%%%%%% OPCOM 10-SEP-2016 19:04:23.05 %%%%%%%%%%%
Message from user WILLEM on DIANA
%PTSMTP-E-WORKERDIED, worker PTSMTP 0002 (20249025) terminated unexpectedly
-PTSMTP-I-WORKEREXIT, worker exiting
-PTSMTP-E-TLSCONFIGERR, TLS/SSL configuration error; check configuration

%%%%%%%%%%% OPCOM 10-SEP-2016 19:04:23.05 %%%%%%%%%%%
Message from user WILLEM on DIANA
%PTSMTP-E-WORKERDIED, worker PTSMTP 0001 (20248824) terminated unexpectedly
-PTSMTP-I-WORKEREXIT, worker exiting
-PTSMTP-E-TLSCONFIGERR, TLS/SSL configuration error; check configuration

and this goes on, and on, and on…. all day long on Sunday.
Today, I noted this because operator.log of Sunday was 10 times as big as usual, and not any message had arrived from the ouside world.
So I sent a mail to process.com, and Hunter suggested I should disable TLS again – I enabled it on Saturday because of the error. It’s one of these internal updates that should go unnoticed:

PMAS V3.2-7 upgrades the OpenSSL component to 1.0.2g. I’ve not heard of anyone else having any issues, but I’d suggest you make sure the files pointed to by your configuration are OK. Also, check the PMAS_DATA:PTSMTP_TLS.CONF file and make sure it’s still accurate.

But I didn’t do ANY change at all! 3.2-5 works fine….

But I took a closer look.
Checkecd the file hunter pointed to, but that states:


#This file intentionally empty


and the certifcate files menstioned in the configuration screen: server-pub.pem and server-priv.pem, don’t exist. Should not make a difference if TLS is not enabled, but the worker logs show these will be loaded – TLS or not:
failed to load certificate file server-pub.pem; exiting

So I’ll reverse this update – until a solution is found (I have this version still available).

Update
Hunter ran into the same behaviour, and on my way home from the office, he found the reason: comment two lines in PTSMTP.CONF:

Please edit PMAS_DATA:PTSMTP.CONF and search for the section labeled “[tls]”. Comment out that line, then also comment out the tls_protocols line under it.

Once you do that, PMAS should start OK.

Looks like I inadvertently left the [tls] section in that file, when it should be coming from ptsmtp_tls.conf instead.
Please edit PMAS_DATA:PTSMTP.CONF and search for the section labeled “[tls]”. Comment out that line, then also comment out the tls_protocols line under it.

Once you do that, PMAS should start OK.

Looks like I inadvertently left the [tls] section in that file, when it should be coming from ptsmtp_tls.conf instead.

Sorry about that.

Done this, and now mail is coming in again.

WordPress update
Setting up WP461 as a new blog – using the same set up as always – had a twist. I specified that database wp42 should be used; this one existsand an upgrade would be required – but for some reason wp-config.php isn’t exactly loading the file containg the database access parameters, and creates a new database WP with record prefix WP_. The upgrade script syas no update is required, and hitting the continue button breaks the session.
However, using this new dataabse has no problems at first glance.

Bootcamp
8 days to go (actually, 7 1/2) to setup the laptop….But the main server seems to be in good condition now.

Yesterday’s Mondesi issue solved
Dug into the issue.
The old version did show a page, no error (nor data but that is another story), on the mapping:

0212 redirect /cgi-bin/mondesi* ///cgiplus-bin/mondesi*
0213 pass /mondesi/-/* /wasd_root/src/mondesi/*
0214 exec+ /cgiplus-bin/* /cgi-bin/*

and the new one:
0212 redirect /cgi-bin/mondesi* ///cgiplus-bin/mondesi*
0213 pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*
0214 exec+ /cgiplus-bin/* /cgi-bin/*

But WATCHing the mapping procedure on the server, it seems that is still using the old value – it maps /mondesi/-/acme.js to /wasd_root/src/mondesi/acme.js:

0174 /mondesi/-/acme.js .. SET /wasd_root/* stmLF
0175 /mondesi/-/acme.js .. SET /web/* stmLF
0176 /mondesi/-/acme.js .. SET /wasd_root/doc/* map=ELLIPSIS
0177 /mondesi/-/acme.js .. SET /wasd_root/src/* NOcache map=ELLIPSIS
0178 /mondesi/-/acme.js Y- PASS /mondesi/-/* /wasd_root/src/mondesi/*

and since this file doesn’t live there, it won’t find this file. hence the error.
I didn’t understand so I asked for help on teh WASD-INFO list.
But after that, scrutinizing the output, it turned out the problem did not occcur in homedesk.conf itself, but in one of the included files: Basic.conf. In that file, there was another location of this wrong mapping. And since WASD runs the mappings from top to bottom, it will use the first match – in this case, the wrong one. So I commented it out – and ran into the same error but to another location, because a bit further on there is one line that now causes havoc:

pass /*/-/* /wasd_root/runtime/*/* cache=perm

So now the acme.js files is searched for in the general WASD runtime environment, where it doesn’t exist either.
Therefore the commented line would need to be changed to the right value:

pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*

like the comment added a long time ago, states:

# Mondesi, Must be defined here otherwise overruled by
# runtime setting

And behold:

So I have to answer my own request to the WASD list….

WordPress 4.6.1
This is the latest version of WordPress.
A few weeks ago I got a mail from the WordPress team urging me to update. Easy – if you’re on Windows or Linux, but for VMS, the automated update won’t work as in these systems, since quite a lot of files contain dots as part of the filename, which is not normal for VMS. So it’s likely that when these files are stored on VMS, the dots will be replaced by underscores and therefore kill the blog. Moreover, I don’t want a standard installation (I do not have a [wordpress] directory 🙂 ) so it won’t work for that reason alone.
Of course I could set the system to allow dots in a filename (there is a setting to do that) but that may interfere with other programs. so I take the slow route: Upload the .ZIP file, unpack it, rename the newly created wordpress directory to WP with the version added, and create a system logical with that same name, referring to that directory as root of the given WordPress environment:
So on my (windows) workstation, download the nzipfile from wordpress,org and pass it to VMS

FTP wordpress-4.6.1.zip to the standard location on VMS (sman:[install.wp] - this will create wordpress-4^.6^.1.zip.

on VMS:

$ set def sman:[install.wp]
$ unzip wordpress-4^.6^.1.zip -d web_disk2:[private].
$! this creates web_disk2:[private.wordpress] directory tree
$ ren web_disk2:[private]wordpress.dir web_disk2:[private]wp461.dir
$ def/sys WP461 web_disk2:[private.wp461.]/trans=conc

The next thing is to ‘reverse’ the translations of dots in a filename (except the last one, being the divider between file name and extension/file type) into underscore. In the past, this was straight on: any dos – except the last one – should be replaced by a dot. This was possible because in the past, wordpress didn’t use underscores in their filenames, but hyphens. But since version 3.something, some files have underscores…
So the script I created to do this tedious job (named wp2vms.com), had to be altered, and 4.3.1 – the current version – was made running using that script. But in 4.4 there were even more of these files, so I didn’t get it running.
Now I have investigated what files should NOT be renamed and happily enough, the filter of files to bypass this action, could be found in two places: If the full name contains string “RANDOM_COMPAT” or “IMAGES”, the files do not need to be renamed. Running that procedure reversed the translation except these, and one that was false-positive and needed to be renamed.
(to find it: run wp2vms another time. Since the output is now limited, any file that should be renamed now stands out clearly).
So now WP461 can be put to the test.
The only thing to be done is to edit WP-CONFIG.PHP to refer to the include file containing the security definitions (which is inaccessible via the internet, of course) and add a mapping for the server. Non-public, by the way.
If it works, the blogs will be updated.

Bootcamp preparations
Nine days left to prepare a system for bootcamp ….

Updates installed
Today I installed a number of updates.

First, the latest version of PMAS (Precise Mail Anti Spam) has been installed: 3.2.7 – I was still running 3.2.5; it does it’s job (silently but well) but it may include some (internal) enhancements. One thing for sure: if messages are released from the user quarantine or discard pages, the page is reloaded – and the released messages won’t show up anymore.
Second, I updated the WASD web server to the latest version (11.0.2) which meant the sites have been off line for s short time.One small glitch here: Following the manual, the update procedure couldn’t locate the INSTALL procedure so I had to make a small change. But once the update had run and the server is started, all seems well. I just have to disable a number of obsolete configuration items, and look for the new HTTP2 possibilities; I haven’t enabled them yet.
Next, I updated a few packages from the sane forge: DCLInABox (terminal emulator over HTTP), AlaMode (real-time server monitor), and Mondesi (6.0.1) – which requires more configuration on the server (obviously). But for some reason, this still refers to the very old version (2.0.0) which didn’t work anyway, even when the actual image is uninstalled and deleted. So for this, I need to do some (WATCH) analysis.
So apart from Mondesi, all went smoothly. As you would expect.

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 🙂