12-Sep-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.

11-Sep-2016

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:
2016-09-11_21-39-43
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 ….

10-Sep-2016

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.

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 :)

10-Aug-2016

Corfu FINALLY published

It has taken a lot of elapsed time, but the report on our trip to Corfu has finally been published. Not prepared as much as previous reports have been, but clear enough to watch. It not just contains the images, maps and tracks (.GPX only this time) but also the documents used for the trip – including the details of our walk. The only thing still missing are my own remarks on the guide, corrections and additions.

06-Aug-2016

Relay attempts
in general, all is Ok in last monthly maintenance:
PMAS statistics for July
Total messages    :   6052 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :   4173 =  68.9 o/o (Files: 31)
Accepted by PMAS  :   1879 =  31.0 o/o (Files: 31)
  Handled by explicit rule
         Rejected :    854 =  45.4 o/o (processed),  14.1 o/o (all)
         Accepted :    202 =  10.7 o/o (processed),   3.3 o/o (all)
  Handled by content
        Discarded :    264 =  14.0 o/o (processed),   4.3 o/o (all)
     Quarantained :    274 =  14.5 o/o (processed),   4.5 o/o (all)
        Delivered :    285 =  15.1 o/o (processed),   4.7 o/o (all)

but the number of relay attempts is very hihgh. Again, these are mainly of Chinese origin:

  • 111.202.57.39 in two days (adjacent), 878 and 390 attempts
  • 95.208.192.227 with 115 attampts (one day)
  • 157.122.147.2 with 2291 attampts in one day
  • 157.122.148.194 with 413 attampts
  • The latter two are the same network.
    I had to re-configure the router a few weeks ago and didn’t restore the objects – the last one was one of them. Well, they have again been added so the number of relay attemps from these addresses (and spam sent from them) will be blocked. ANY access, in fact.

    12-Jul-2016

    Nightly job…
    The new configuration of the router had some quirks.
    Thinking I had it all set up, it turned out that for some reason, IPTV didn’t pass: the set-up boxes had no connection to the Internet. Resetting them didn’t help – that’s what made this clear.
    Where there is one VLAN for Internet access, this is routed to ports 1, 2 and 3; over LAN1 (connected to WAN1) or LAN2 (connected to WAN2 – the fast port). IPTV is bridged directly to it’s own LAN and port, and that seemed to go wrong. (VOIP works regardless the WAN port used – the lines are both registered at the provider).
    This was in the very early hours of today, and there was no tie to figure it out. So I looked for a backup of the configuration, found a number of older ones, and restored the configuration from the latest of that set, reconnected WAN1 to the internet and set up Port WAN2 as backup. Some things still need to be done, but at the moment, everything is now in working order. So I created a backup of this installation.
    And just then I found the pretty recent backup I was looking for…
    Well, given the time I didn’t restore from that one. There is still some work to be done to swap the two lines. Unless the ISP has another idea to get the connection working at the intended speed of 100Mb – symmetrical.
    Update
    I got an answer on my question to Draytek about this issue: Is it a router setting that causes this? The answer is: No, it’s ‘built-in’.
    AS they put it (in Dutch)

    De WAN 1 is een 10/100 Mb poort. Hiervan is WAN<>LAN doorvoersnelheid ongeveer 50~60 Mb/s. De WAN 2 is een 10/100/1000Mb poort en
    hiervan is de doorvoersnelheid ongeveer 100~110 Mb/s. Onze advies om de WAN 2 te gebruiken.

    Shrt translation : WAN1 is 10/100 Mb, WAN to LAN throughput is about 50-60 Mb/s. WAN2 is a 10/100/1000Mb port where throughput is about 100-110 Mb/s.
    We recommend to use WAN2.

    So in stead of 100 Mb, that WAN1 port is actually a 50Mb port – so 50%. WAN2 is even worse: the speed (given you can run full speed (1Gb/s)) your port is actually 1/10th!
    So if I want to have full advantage, I’ll have to use WAN2. No problem, all is set up to work that way – just have to see if that works for television as well. And the max speed I got when testing it, was only(!) 70 Mb. Faster indeed though not the 90 I would expect, but it might be that router traffic interfered.
    However, if I decide to go any faster (500Mb is possible) I’ll ned to replace the router – and heavily check te actual throughput.

    11-Jul-2016

    Internet access issues
    Since I have a fiber internet connection, and a subscription to a 100 Mb connection (symmetrical, so either way) it wondered me when running a speed test, it would get to just 50 – download a bit less, upload a bit more. On contact with my ISP, I checked using the supplied router (Fritz!box 7390). The laptop directly connected to this router, that one directly connected to the FPU (where fiber meets Ethernet). Here, the speed ran to a speed well over 90 Mb – either way. Connected it like the Draytek router – so with another cable, as this isn’t close to the FPU because of all connections – it still was over 90Mb. Still, the Draytek kept running at “half speed”.
    The fun part is: this is a dual-WAN router. the first WAN port is 100Mb, the second can handle 1Gb. The connection was set up to use the first, so I switched to the second. It does make a difference: Speeds are now increased to about 70. A bit better, but not yet as is has to be. Of course, all other traffic may interfere, but that would have been the case with the Fritz!box as well. So there is one more test to perform: Disconnect the LAN and rerun the tests. If that closes in to 100Mb, it’s obvious that traffic to the server causes the issue. If not, it’s the router that needs another tweak. I asked Draytek what it might be, but I doubt this can be set – I didn’t see any setting that could be – except, perhaps, MTU. Set to 1442 where the max is 1496. But I cannot image that these 40 bytes make such a difference….
    But it might be.
    Server issue
    Yesterday’s issue with the server is confirmed to be a bug, not a real surprise given the massive overhaul of the code. Mark supplied a hotfix that tackles this one and a few others. It will be installed ASAP – it might be tonight but on the other hand, it can wait a few days. It’s not that important.
    Update
    Done – and the configuration has been restored. Now it works again.
    I also updated the email-program, but here I ran into a problem: It seems that the program is unable to open the language file, the server returns a 403-error but there is nothing wrong (it seems) with the file security…Looked into the code and found that the language file used (EN.TXT) seems to contain more, or less messages than is anticipated. Hence: mismatch. I re-installed (= upzipped) the files once more, and even without rebuilding and reinstalling, the site now starts. That is: there is a message popping up because a routine called within the Javscript cannot be found:
    .soymail error
    but that doesn’t stop the music. Nor do the missing header and default footer, but I had URL’s to the spamfilter. So I’d like to have them back.
    Update on these
    I found the reason for the missing header and footer. I forgot the configuration file, didn’t remember name or location (but given the author, it would be ‘soymail.conf’, or so. Checking on the logicals I found it, and adapted the header and footer lines.
    The issue with the script is just a matter of clearing the browser’s log. I could have known that…

    10-Jul-2016

    Server updated
    Updated WASD server. As usual, it’s been a piece of cake, but this time there is a twist.
    In the mapping file, I have a line:

    if (client_connect_gt:10) pass * "503 Exceeding your concurrency limit!"

    to prevent a single accessor to have more than 10 concurrent sessions – at least, this was my interpretation. But now it blocks ALL access, whether the number of sessions is higher than 10 or not, regardless the originating address. (apart from me, there seemed to be one more user, he got this message, but so did I – with ONE session… Since some parts of WASD are rewritten0, this may have slipped attention, so I reported it to Mark.

    Once disabled, the site is accessable again.

    This effects the non-secured sites only because the other ones don’t pass this mapping. However, I notices a weird thing using Firefox: The tile (“~”) used in accessing the user’s mail environment, translates to another character (‘not’ character) and therefore, Mozilla cannot be used to access the webmail-program directly – I have to get to the main page and invoke SoyMail from there.

    03-Jul-2016

    Just the ordinary
    Again, there is nothing special in the system.
    PMAS statistics for June
    Total messages  :  1893 = 100.0 o/o
    DNS Blacklisted  :   0 =  .0 o/o (Files: 0)
    Relay attempts  :  264 = 13.9 o/o (Files: 30)
    Accepted by PMAS :  1629 = 86.0 o/o (Files: 30)
    Handled by explicit rule
    Rejected :  800 = 49.1 o/o (processed), 42.2 o/o (all)
    Accepted :  212 = 13.0 o/o (processed), 11.1 o/o (all)
    Handled by content
    Discarded :  239 = 14.6 o/o (processed), 12.6 o/o (all)
    Quarantained :  195 = 11.9 o/o (processed), 10.3 o/o (all)
    Delivered :  183 = 11.2 o/o (processed),  9.6 o/o (all)

    There were just a few reay attempts causing the logfile to grow over the limit:

    • 5.135.219.26 (38 attempts). The only information I could find on this address is that is seems to be located in France. It tries (bogus) addresses of my domain (the only real one is www.grootersnet.nl) and the attempt was made to connect to a gmail mail server.
    • 208.100.26.230 (16 attemps) but given the sender and addressee used, I think this is a test to see if the mail server is an open array. (It isn’t). The address refers to a hosting company in the USA (Chicago area), and the company that is hosted there, seems to work on QR-codes (ScanMe.org doesn’t own a website, ScanMe.com does)
    • 4.222.41.220 (101 attempts) seems to be a dial-up connection to a server near Wichita (Kansas), so there is no further information.

    Since these are simply ‘just a try’ – the number of attempts is relatively low and do not reoccur – I leave it. For now.

    Funny: On Windows 10, the Edge browser will highlight the first two as links – and offers Chrome to open them :). Show in Internet Explorer shows the data as it is intended.)

    Pending Updates
    I have to update WordPress, but for the lastest version PHP 5.6 (that I downloaded and installed) is recommended, as well as MySQL 5.6 or MariaDB 10.0. It should word with PHP 5.0.4 (I curently run 5.2.13) and MySQL 5.5: that I’m using for several years now,
    For mySQL, I will have to stick to MySQL 5.5 (or MariaDb 5.5) since there is no recent update of MySQL on VMS (HP won’t fund any attempt) nor has Mark Berryman updated his port of mariaDB.
    The previous update (to WordPress 4.3) failed, so I wonder what will happen with this one. I’ll do WP first, than PHP; is has no implications on the blog itself (I hope).

    Another update is the webserver (WASD) to 11.0.1 – and that will be a piece of cake. As usual.

    Router problem?
    The Vigor router has a problem, I think. Although I have disabled any limit (there is no need to limit access), the router complains about exceeding the maximum number of allowed connections. At times not just from the LAN, outside connections get the same error as well. It seems the router doesn’t free disconnected channels, the server has not that much open connectons.. The only solution is a reboot of the router.
    This time, I needed anyway, because I updated the servre firmware. But probably I’ll have to reboot the router regularly; it has a schedule option but I need to dig into the manuals first. If possible, this will of course be scheduled at a quit time.