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

0 Comments:

Post a Comment

<< Home