SYSMGR

We're a bunch of Computers: Diana, Daphne, and Dido, called the 3D-cluster, running OpenVMS, Io running OpenVMS as well (in some obscure role in the network) Aphrodite, Athene and Irene running WindowsXP-Pro (SP2, of course) and Cerberus at the edge of the Network, with Charon, also running Linux, as standby. SYSMGR takes care of us.

Monday, August 28

28-Aug-2006

Still DNS trouble
This morning, at the customer's premises, I found that none of the webs could be accessed. Even logging in using SSH failed. So last night's excersise wasn't the solution.
One possible cause, I thought, was the second NIC in the system: It's not connected at all, originally it was defined in DECNet but I removed the divice completely - first from TCPIP and than from DECNet - because there is no other DECNet system - yet - to communicate with, it's logging "pollutes" the operator log by a message every 3 seconds or so.

Thought THAT might be the problem.

So I re-did the DECNet configuration, and had to reboot to get it available to confirure TCPIP onnthat interface. restart of TCPIP went fast - no more wait on configuring devices! BIOND came up right as well, but was slow in giving answers. But that was caused by specifying the router as DNS server and that will not respond directly (and call out). After removal of that errenous entry in the name service definition, all was well.
Logicals
But reboot revealed another problem: Though the webserver comes up properly, it is found that some webs (webmail, for instance) won't work because logicals aren't defined correctly. I ran down all startup files but I couldn't find a reason why, for instance, "USER" was defined as it should be: USERDISK:[USER.]/trans=(concealed,terminal) but just as [USER] - without a disk.
(actually: though "USERDISK" is a label of a disk, and it's mentioned in it's MOUNT command, "USERDISK:[USER.]" is wrong as well, it won't work with "/terminal" attribute. It has been defined as $ ud = 'f$trnlnm('USERDISK") and "$ define user 'ud':[USER.]/trans=(c,t)" and that is Ok). This is still a matter of investigation.
Logs
The logs arn't yet copied properly - that is: the default protection is still wrong for accessing them through the web (W: no access, where is should be W:RE). So I added a default protection on all web-accesable directories that would allow this:
$ set security/acl=(default_protection, access=(S:RWEDC,O:RWEDC,G:RWE,W:RE)
and added on top of the scan-log procedure:
$ set protection/default=(s:rwed,o:rwed,g:rwe,w:re)
but that will be in effect tomorrow

Sunday, August 27

27-Aug-2006

DNS trouble
I installed the latest patches on VMS, and rebooted. That caused severe problems with DNS, just the local data was accessable with TCPIP SHOW HOSTS - nothing that is stored in the BIND files:

$ tcpip sho host

LOCAL database

Host address Host name

192.168.0.200 3D_GROOTERS, CL_GROOTERS
192.168.0.33 CERBEROS
192.168.0.4 DAPHNE.INTRA.GROOTERSNET.NL, DAPHNE
192.168.0.2 DIANA.INTRA.GROOTERSNET.NL, DIANA, diana,
WWW.INTRA.GROOTERSNET.NL
192.168.0.251 LJ2100TN
127.0.0.1 LOCALHOST
193.172.141.34 MAIL.VXCOMPANY.COM
65.125.246.7 VMSPR2.PARSEC.COM
192.168.0.31 WIRELESS
192.168.0.30 charon.intra.grootersnet.nl
10.0.0.1 cl_diana, CL_DIANA
$

and that's it. Beacuse of that, the webserver was started on the only web available: the administration entry on the local IP address on port 82 (actually, that's what triggered the idea something was wrong). and indeed: this was the logfile:

$ type TCPIP$BIND_RUN.LOG
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
Sun 27 22:08:02 NOTICE: starting BIND 9.2.1
Sun 27 22:08:02 INFORMATIONAL: using 1 CPU
Sun 27 22:08:02 INFORMATIONAL: loading configuration from 'SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND.CONF'
Sun 27 22:08:02 INFORMATIONAL: no IPv6 interfaces found
Sun 27 22:08:02 INFORMATIONAL: listening on IPv4 interface *, 0.0.0.0#53
Sun 27 22:08:02 INFORMATIONAL: listening on IPv4 interface LO0, 127.0.0.1#53
Sun 27 22:08:02 INFORMATIONAL: listening on IPv4 interface WE0, 192.168.0.2#53
Sun 27 22:08:02 INFORMATIONAL: listening on IPv4 interface WE0, 192.168.0.200#53
Sun 27 22:08:02 WARNING: zone INTRA.GROOTERSNET.NL' allows updates by IP address, which is insecure
Sun 27 22:08:02 WARNING: zone '0.168.192.IN-ADDR.ARPA' allows updates by IP address, which is insecure
Sun 27 22:08:02 ERROR: none:0: open: TCPIP$ETC:RNDC.KEY: file not found
Sun 27 22:08:02 NOTICE: couldn't add command channel 127.0.0.1#953: file not found
Sun 27 22:08:02 INFORMATIONAL: zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 42
Sun 27 22:08:02 INFORMATIONAL: zone 0.168.192.IN-ADDR.ARPA/IN: loaded serial 2006082701
Sun 27 22:08:02 INFORMATIONAL: zone LOCALHOST/IN: loaded serial 42
Sun 27 22:08:02
INFORMATIONAL: zone INTRA.GROOTERSNET.NL/IN: loaded serial 2006082701
Sun 27 22:08:02 INFORMATIONAL: running
Sun 27 22:08:02 INFORMATIONAL: zone 0.168.192.IN-ADDR.ARPA/IN: sending notifies(serial 2006082701)


Looking into the configuration, it shows that DNS was not running:

$ tcpip sho name

BIND Resolver Parameters

Local domain: INTRA.GROOTERSNET.NL

System

State: Started, Disabled

Transport: UDP
Domain:
Retry: Not defined
Timeout: Not defined
Servers: No values defined
Path: No values defined

Process

State: Disabled

Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
$


but in the permanent configuration, it is defined:

$ tcpip sho config name

BIND Resolver Configuration

Transport: UDP
Domain: INTRA.GROOTERSNET.NL
Retry: 4
Timeout: 4
Servers: 127.0.0.1
Path: No values defined


Address 127.0.0.1 wasn't possible according the log, so I added a second one that IS valid: The machine's own address:

$ tcpip sho config name

BIND Resolver Configuration

Transport: UDP
Domain: INTRA.GROOTERSNET.NL
Retry: 4
Timeout: 4
Servers: 127.0.0.1, 192.168.0.200
Path: No values defined


but that didn't help either. Nor did re-configuring of DNS; that was suggested on the ITRC request (http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1054911), although I found, in starting TPCIP, that it took ages to define the interfaces.
A bright idea, given on the output as shown above, had me decide to re-enable it accoring the permanent configuration:

$ TCPIP SET NAME -
/DOMAIN= INTRA.GROOTERSNET.NL/SERVER=127.0.0.1/RETRY=4/TIMEOUT=4
$ TCPIP SET NAME/DOMAIN= INTRA.GROOTERSNET.NL/SERVER=127.0.0.1 -
/RETRY=4/TIMEOUT=4/SYSTEM/ENABLE



That gave back the DNS data. It looked right since on the PC, I could access the internal and external webs.

Monday, August 21

21-Aug-2006

WAS'D-DAY
I took the jump this night and activated WASD as my webserver. That meant a few little changes to my configuration files (use the webname in stead of the address, and, for some, taking out a few mistakes in the specification). It also required removal of all APACHE logicals, and re-setting some others (for instance the SoyMail logicals that were referring the wrong way now). But within 30 minutes, WASD was up and runing all websites.
A few hicks - mainly file protection and ownership. These will gradually be corrected, when I get into them.

Of course it means the procedure cycling the logfiles needs an adjustment (no more cycling of logfiles, nor copying them from APACHE$ROOT:[LOGS]) and having WASD automatically cycle them every week - preferrably ginving them a fixed name. But that should not be the biggest problem - only time to find out and implement.

Now I can think of the content management....

Sunday, August 20

20-Aug-2006

WASD
is getting along. All webs are running - on port 82, so just locally - and the only thing needed was to copy files under APACHE$COMMON:[cgi-bin] to HT_ROOT:[cgi-bin] to get them working: because /cgi-bin/ refers to HT_ROOT:[cgi-bin], HT_ROOT:{axp-bin] - a searchlist in which there is no space for APACHE$COMMON:[cgi-bin]. Of course I could have added that in startup, but it's just a few so it really didn't matter.
(Searchlists? Yeah, that works under WASD!)
Another thing to be done other than I wanted was SOYMAIL - id did work but the "internals" didn't work as expected. Well, I wanted to install the latest version anyway - so I did so on WASD only. With some puzzling where to place mappings, it now works.
That all was easily found after I learned how to use th WATCH facility: real-time logging what the server is doing in processing the request - mapping, authorization, CGI and DCL execution, network actiovity - you name it: it can all be logged: in real time. That alone makes WASD worthwhile!
One more thing to do, and test it for a while, but I'm pretty sure WASD will be up and running in production shortly. But first find a way of handling the logfiles...
UPDATE
The one nasty oustanding issue has been solved - again, with some help by Mark Daniel and his great WATCH facility he built into WASD! One more thing to do: make everyting requiering authentication unless explicity supressed. But that's a matter of somewaht lower priority.
Abuse
Nothing weird but the usual SPAM and phishing attempts. No time to dig into them, alas.
CMS
I think I'll write my own CMS - using WASD's facilities. PHP packages would be possible but ig I can fgo for the fast, most efficient way, I don't think that's the route to take.
Multiple servers
I'm setting up a VMS box that will run all free webservers on VMS: OSU, SWS and WASD. All of them are running - and running fine, the only problem I faces now is that the CGI-program that delivers dynamic pages, produces no output on WASD...It works, but output is limited to 24 timnes 2 spaces. It must be someting in the Dibol program: using SMG for creen handling, perhaps? Something to dig into!
If time permist, there might be an article on this issue and all problems encountered, inclusing the trouble I had moving from SWS to WASD.