Month: January 2018

New development environment
having worked with a graphical IDE for the last 4 years (using Delphi on Windows in my daily job) I think it’s time to install something similar on de VMS boxes. I have used the HP(E) supplied NetBeans solution on my PWS – which is way too small to run such a heavy Java application in it’s 256 Mb memory. But it’s free…
Nevertheless, it hasn’t been updated for years and there is a newer kid on the block – Eclipse based, with a Java component on the VMS side. Since the basis is Unix/Linux based, you’ll also need GNV – GNU for VMS: Nxtware-remote, by eCube. I had it all on Diana but it has been years ago that I had it installed – so I re-installed Java and GNV – the latter has been quite a challenge, since though it looked as if the installation succeeded, it didn’t. Even manually removing the whole installation by hand failed.
As it turned out, it might have been that, due to getting the whole thing on the system, there was a link set up that needed to be removed – using GNV programs. That I just deleted….Luckily I had the whole lot on Dahpne, being a cluster member I could copy what I needed: mnt.exe and umnt.exe. Setting up foreign commands to use them:
$ mnt := PSXROOT:[bin]mnt.exe
$ umnt := PSXROOT:[bin]umnt.exe

I could figure out what to do:
$ mnt
DISK$AXP084:[000000]PSX$ROOT.DIR;1 on /DISK$AXP084/VMS$COMMON/GNV
shows mounted file systems and mount points, so
$ umnt /DISK$AXP084/VMS$COMMON/GNV
get rid of the link – and now re-installation completed..

After that, I could install Nxtware-Remote, and start $ @NXTware-Remote_Configure to set it all up. Now it proved needed to changes a number of SYSGEN parameters (and a number of process quota). Done so, and so I needed a reboot.
Because I had done some cleanup since last boot, a few things didn’t go as planned: MaraiDB didn’t start, not did the webserver. This was caused by specifying a logical that I removed (since it was completely obsolete – a residue from an older instance – and disk. After I updated the startup files for the webserver, it did start, but the database still failed. Since this is done on batch, where SUBMIT has /NOLOG parameter, you’re in the dark. After adding a logfile to the SUBMIT command, I found out the reason: Since the server runs under user MYSQL051_SVR, this needs to login – but it has a captive commandfile:

Username: MYSQL051_SRV Owner:
Account: MYSQL051 UIC: [37775,1] ([MYSQL051,MYSQL051_SRV])
CLI: DCL Tables: DCLTABLES
Default: MYSQL051_ROOT:[MYSQL_SERVER]
LGICMD: MYSQL051_ROOT:[VMS.MYSQL]LOGIN_SERVER.COM
Flags: DisCtlY DefCLI LockPwd Restricted DisWelcome DisNewMail DisMail
DisReport DisReconnect

and logical MYSQL051_ROOT has also been removed…After I added the definition to the command file starting the database server, it started.

A hard test of the startup procedures, but now these are corrected, next startup should go fine.

Now it’s waiting for the licences

WordPress update
Starting the blog to create this post, I was notified a new version of WordPress was available (4.9.2) – so I downloaded it (and Aksimet 4.0.2, thatmatches this version) and installed them.

Next advantage of restart of the webserver: Since some process workingset quota have been enlarged, it seems the blog is faster …
Perhaps I can now run a higher PHP version as well.

More on certificate renewal
Comparing genealogy (wichh got the certificate a few days ago) and both webmail and homedesk made it clear that the mapping for the certificates is fine:


[[(service):80]]
map /.well-known/acme-challenge/* \
/wcme/.well-known/acme-challenge/* map=once
script /wcme* /cgi-bin/wcme*
pass * 403

[[(service):443]]
##[[192.168.0.2:443]]
# ...


but authorization wasn’t:

[[service]]
#[NONE]
#/.well-known/* read

[Auth=VMS]
/* read+write


so nothing could be done on port 80…Obvious, since access to both webmail and homedesk require authentication. For genealogy, unauthorized access is an option, so here it states

[NONE]
/* read
/public/* read

and so I changed the settings for webmail and homedesk accordingly, and now the certificates were created and stored in place.
But the browsers still complained about the invalidity of the certificates, even after clearing the bowser and server caches. The only way to get around it was to restart the server (from the web-admin page, or by
$ httpd/do=restart from the commandline – the same thing.

Now wait until April, for the next renewal…

I wrote a small report on all issues on the WASD mailing list.

Cleaning up 2017
The new years starts with some house-keeping of last year. No surprises, mail is still mostly rubbish:

PMAS statistics for December
Total messages    :   3082 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    405 =  13.1 o/o (Files: 31)
Accepted by PMAS  :   2677 =  86.8 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1836 =  68.5 o/o (processed),  59.5 o/o (all)
         Accepted :    171 =   6.3 o/o (processed),   5.5 o/o (all)
  Handled by content
        Discarded :    445 =  16.6 o/o (processed),  14.4 o/o (all)
     Quarantained :    204 =   7.6 o/o (processed),   6.6 o/o (all)
        Delivered :     21 =    .7 o/o (processed),    .6 o/o (all)


Just two days show a larger amount of relay attempts:

14-DEC-2017 03:26:10.51 to 03:29:14.29 (190) (23.254.204.176)

22-DEC-2017 04:20:08.50 to 04:24:03.01 (184) (104.168.134.210)

trying to send a mail from a (bogus user)@grootersnet.nl to 1029mandaditos@gmail.com, both addresses are owned by Hostwinds.com. Quite possible that the router should have blocked them, since I’ve blocked addresses from Hostswinds.com there, but it is possible that these addresses are not properly set (both are /17 addresses according analysis, and since the sender address is forged, so could be the sender address…)
Anyway, I notified hostwinds.com of these attempts – there have been similar attempts in November).

BTW: A (real user)@grootersnet.nl to any other outside address will fail as well, since PMAS has a rule to reject any grootersnet.nl sender from outside the local domain…

Next is a manual job: Moving all 2017 data into one location. That’s the next job tonight.

Failed certification renewal
There were a few things to do here.
First, I needed to update WCME, I was still running the first version (1.0.0) and a new one (1.2.0) was already downloaded but never moved to VMS and installed there. So that was the first activity to do. Next, it failed – again – even after replacing the INSTALLed executable. As it turned out, it was a matter of directory access protection. After that, genealogy.grootersnet.nl got a new one, but webmail and homedesk failed again – due too many failed renewals. So I have to wait some time and retry. But since genealogy.grootersnet.nl does have the new certificate, I guess these two will be renewed as well soon.