with the Jura pictures, Rita’s quilt, and the pictures taken last year in the Meie Gardens (better late than never…). The greek pictures and an update on our scultering is still to be done.
Of course, looked at the system and did some housekeeping.
to be updated: This year’s holidays: One to France (Jura) and one to Greece – a hiking trip of two weeks. That content includes maps – to be scanned and scaled. A daunting task that will take time.
Tracks of what has been walked and cycled will be included
Bind is Ok
it seems, since there were no reports of Internet connectivity not working. Si I guess it was just a glitch in the interaction between Diana and the router. No problems aftre yesterday (excpet that at some point, the PHP process ran out of file quota, butÂ whether these were VMS of PHP-internal could not beÂ found.
OneÂ more (minor) issue with PHP – and I found this before:
%HTTPD-W-NOTICED, 23-NOV-2006 22:13:17, CGI:1969, not a strict CGI response
-NOTICED-I-URI, GET (18 bytes) /sysblog/index.php
-NOTICED-I-SCRIPT, /sysblog/index.php sysblog:index.php (cgi_exe:phpwasd.exe) SYSBLOG:index.php
-NOTICED-I-CGI, 254445425547424F4F542D572D43484E2C2061737369676E (62 bytes) %DEBUGBOOT-W-CHN, assign channel system service request failed
-NOTICED-I-RXTX, err:0/0 raw:495/0 net:495/0
It’s this message that triggers the “Not a strict CGI response” situation. Something within PHP fails to (re)connect to a channel. It’s a sprurious error and mostly nothing is wrong, just once in a while this happens. Stopping the sub-process heals – but it shouldÂ not happen….
(I guess the previous trouble posting had the same cause)
Still problems with BINDThe problems yesterday did indeed cause a problem with mail. Since checking domains failed, delivery of mail was rejected as well. Therefore, I had to resent mail pushed out yesterday. I did that at 7:00 am – about that time.
But at 9, Kim called that there was again no connectivityÂ to theÂ Internet, and Kasper did as well around 11. Mail sent to grootersnet.nl failed again!
So The first thing to do was having a look once more. But $ TCPIP SHO HOST showed all I would expect. I looked in Operartor.logÂ and teh BIND logs but there is no clue whatsoever why it suddenly fails to translate external addresses! After stopping and starting BIND, and waiting a few minutes, there was no more problem!
It will be one of the first things to check tomorrow.
Aphrodite has some problem once in a while. It will get all configuration data form Diana (set up to be configured by DHCP – as all Windows boxes) but connection for telnet and POP (for mail) will fail; Starting a DOS box and give the command ipconfig /renew solves the problem. In the BIND log, Aphrodite is often mentioned trying toÂ make adjustments to the BIND database – which is, for good reasons, not allowed.
Yesterday I had to repair a light switch, and so power had to be taken off – and I expected that the datacentre would powered: the guide sheetÂ stated “First floor” and did not mention the attic where the datacenter is. Alas – that’s correct where lightÂ is concerned but major power is wired to the first floor – so DOWN all went.
Nasty thing is I just found out today. That is: KimÂ complained that Internet connectivity didn’t work. But the local network seemed Ok. It was impossible to access the system directly (I was on another location) so I got into the issue tonight – and found out what happened.
On Irene – the Windows machine for ‘normal use’Â – nslookup of an external site failed, but internal all was well. So I took a look to DIana’s TCPIP$BIND process – which was running fine but $ TCPIP SHOW HOST just showed the local database, not what is stored in DNS! So I restarted BIND (that is: $ @SYS$STARTUP:TCPIP$BIND_SHUTDOWN followed by $ @SYS$STARTUP:TCPIP$BIND_STARTUP) and next the data did properly show up. Next I had to renew Irene’s DHCP data, before nslookup did work.
But to find out WHY this happened: $ SHOW SYSTEM/NOPROC showed an uptime of only almost 24 hours, and yesterday’s Operator.log ended when I switched off power: at 19:15, and a second log started when power was restored (at 19:45). That’s a way to find out what miistake I made last night!
(If I could have checked the logfiles from my job location, something I usually do at another site, I would have noticed before)
Everthing worked fine after that, except for this blog. Simple reason: the logical where this log resides wasn’t properly defined. Just had to change that (manually, to be done in the startup files as well). Now all runs fine, only it seems mail is not delivered. I sent something this afternoon, there was nothing wong with it, it didn;t bounce but I have not got it here. It might come later…