All as usual
Back from the OpenVMS Bootcamp, found everything in working order – except for the front page that looked weird. But in general all is well. Apart from the usual stuff:

PMAS statistics for September
Total messages    :   9390 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :   7221 =  76.9 o/o (Files: 28)
Accepted by PMAS  :   2169 =  23.0 o/o (Files: 29)
  Handled by explicit rule
         Rejected :   1220 =  56.2 o/o (processed),  12.9 o/o (all)
         Accepted :    203 =   9.3 o/o (processed),   2.1 o/o (all)
  Handled by content
        Discarded :    351 =  16.1 o/o (processed),   3.7 o/o (all)
     Quarantained :    244 =  11.2 o/o (processed),   2.5 o/o (all)
        Delivered :    151 =   6.9 o/o (processed),   1.6 o/o (all)

there has been some attempts to relay, using a forged grootersnet.nl account, to one (!) address: xiaonanzi11165@vip.163.com, which is a Chinese address, renowned for it’s bad behaviour. This time on three days, on two addresses (both Chinese as well):

  • 07-sep-2016  05:42:31.68 – 09:57:18.53 (2400)
  • 09-sep-2016  07:01:50.77 – 11:19:44.45 (2400)
  • 30-Sep-2016  18:12:17.81 – 22:07:42.44 (2300)
  • every sixth minute in these time frames. They were not yet included in the new list of networks to be blocked, so I added them, so I should no longer see them.

    During the bootcamp, I also took a look to the new WordPress version (4.6.1) that I already had installed and accessible, and it seemed all well working, so there is no real issue updating the blogs – that will be done later tonight.
    There is one minor issue: the stats plugin – very out-of-date but still present. Removal via Plugin pages failed (obviously: the site is read-only) so I have to remove it myself – from the database…

    Some other issue handled during the bootcamp: I had a problem with PMAS: normally, I would get a mail back from the [INFO-WASD] mailing list when I sent a message but this didn’t happen anymore after I added a rule to block any incoming mail that has the grootersnet.nl domain in the “From:” header line. Since there is ONE source where mail from this domain can come from, which is MY server, these are all forged; I had tons of them so I blocked it. But as it turned out, this list is setup by another fine Process.com package: PMDF, which takes the incoming message, adds “[INFO-WASD]” in front of the subject (if it isn’t there already) and sends them to all subscribers, with “From:” unchanged. The maintainer of the list (Jeremy Begg), was also on the bootcamp and we tried to figure out what may have caused it. Contacted Hunter Goatley of Process also for help, and he gave me a method to check how the scan can be observed: Set debug to a high level, have the file at hand like it arrives, and run pmas.exe interactively.
    I had a message from Mark Daniel at hand, could now observe how the rule scan went as it was acceptyed; then changed the “From:” line as if I sent the message, and bingo: the mail got rejected – because I set it to reject regardless any other rule (‘megareject’). Changed the rule to ‘reject’ and now the message was accepted due to another rule, based of the “received:” header line, containing a value that is acceptable.
    So: problem solved.

    Tested it against the test address that Jeremy had set up, and I got the reply as expected.

    Then there was the issue with the home page: The text wasn’t displayed as it should. Turned out to be a number of typos in the text; corrected them today and now all show now as it was intended. At least: This bit.

    Last but not least: Since I’m back home, the laptop sitting in front of the servers as a console system can be removed. It’s no big deal to start the systems after a power outage in the evening following the issue, but it is a bit cumbersome to do so when you’re in the US…

    What’s next
    I learned a few things on bootcamp, and one is worth some experimentation, so I’ll pick that one up. I will give my remarks in this blog as well – since my aim is to do some changes in signalling.

    To be continued


    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: Port: 62502

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

    %%%%%%%%%%% OPCOM 10-SEP-2016 18:55:18.14 %%%%%%%%%%%
    Message from user SYSTEM on DIANA
    -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,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).

    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.

    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:, 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 🙂


    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.


    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:

  • in two days (adjacent), 878 and 390 attempts
  • with 115 attampts (one day)
  • with 2291 attampts in one day
  • 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.


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


    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.
    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…


    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.