INFO-VAX Sun, 14 Jan 2007 Volume 2007 : Issue 28 Contents: Re: BIND Server config issue DHCP Server question/problem Re: Free cool VMS Email account Re: Moving from Bind 8 to Bind 9 Re: Moving from Bind 8 to Bind 9 Re: OpenVMS Licence for people in Asia Re: RUN SYS$SYSTEM:DCL on Itanium VMS 8.2-1 Re: Suggestion: SET FILE/SHADOW= ---------------------------------------------------------------------- Date: Sun, 14 Jan 2007 06:02:31 -0500 From: JF Mezei Subject: Re: BIND Server config issue Message-ID: <45aa0dad$0$368$c3e8da3@news.astraweb.com> Another impact when trying to use a common directory (which used to work) The Bind 9.3 server (on Alpha) , when getting dynamic updates on a zone file will insist on writing teh new version of that zone file in the SYS$SPECIFIC:[TCPIP$BIND] directory even though the zone file resides in SYS$SYSDEVICE:[TCPIP$BIND_COMMON] directory. As a result, you end up with 2 copies of the file. If you update the one in the common directory, those updates will not be read by the software because it will file a similar filename in the specific directory. If common configurations are no longer supported, perhaps they should have excluded the TCPIP$BIND_COMMON_SETUP.COM file that is deposited in SYS$MANAGER. I guess one possible solution would be to play with SET FILE/ENTER to use the same directory for each instance. Is it possible to find out if the removal of working common bind directories is a "feature" that is to be fixed, or whether it was intentional and will not come back ? ------------------------------ Date: Sun, 14 Jan 2007 11:00:28 -0500 From: JF Mezei Subject: DHCP Server question/problem Message-ID: <45aa536f$0$32593$c3e8da3@news.astraweb.com> Issue: DCHP server responds to a request from a mac, gives it its IP address and subnet mask, but does not provide any additional parameters. (This seemed to work fine when I was on VAX at 5.3) In the DHCP configuration, I have setup : (questions below the --------) The NETS. file: 10.0.0.0 10.0.0.11 10.0.0.150-10.0.0.255 The NETMASK. file # Network netmask 10.0.0.0 255.255.0.0 one group in DHCPCAP. subnet1:\ :dn=vaxination.ca:\ :nw=10.0.0.0:\ :sm=255.255.0.0:\ :ba=10.0.255.255:\ :gw=10.0.0.1:\ :ds=10.0.0.11 65.39.192.130:\ :t2=75598:\ :t1=43198:\ :sp=smtp.vaxination.ca:\ :po=pop.vaxination.ca:\ :to=18000:\ :tu=1500:\ :rd:\ :sl:\ :lt=86400:\ :at=900:\ :xf=10.0.0.10:\ :ww=www.vaxination.ca:\ :sg=smtp.vaxination.ca:\ :lg=10.0.0.9:\ :ms: --------------------------------------------- Questions: The DHCP server offers the correct IP from the NETS. file. It also offers the right subnet mask. Whether this was taken from the NETMASKS. file or from the actual DHCP optiosn defined in subnet1, I do not know. But no other "subnet1" option is included in the offer or in any packets (I have debug level up to 6). It seems to parse the config file properly. QUESTION: How does the DHCP server choose which subnet/group to pick the data from and include it in the response ? Do it look at the network "name" (10.0.0.0 in my case) in the NETS. file, and matches it againsts a nw= entry in the DHCPCAP. file ? If not, how does it do it ? ------------------- Also: found in provisional list. f=665970 DHCPREQUEST(selecting) from HW 00:05:9a:20:6e:0e for IP 10.0.0.150: new lease assign_name(Shimano,10.0.0.150,01:00:05:9a:20:6e:0e) binding triple : DNS binding shimano.vaxination.ca to 10.0.0.150 DDNS failed to create 10.0.0.150 PTR shimano.vaxination.ca : It succesfully creates shimano.vaxination.ca pointing to 10.0.0.150 in the dynamic DNS updates, but fails in creating the reverse translation. In the bind server log, I find: > Sun 14 10:46:41 INFORMATIONAL: client 10.0.0.11#49415: updating zone 'VAXINATION.CA/IN': deleting rrset at 'shimano.vaxination.ca' A > Sun 14 10:46:41 INFORMATIONAL: client 10.0.0.11#49415: updating zone 'VAXINATION.CA/IN': adding an RR at 'shimano.vaxination.ca' A > Sun 14 10:46:41 INFORMATIONAL: client 10.0.0.11#49415: updating zone '10.IN-ADDR.ARPA/IN': update failed: not authoritative for update zone (NOTAUTH) Basically, it is saying that tyhe server is not authoritative to make updates for the reverse DNS ! But the zone is declared as type=master, and the zone file has SOA and NS records that point to this host as the server. Anyone else experienced this ? I have tried a gazillion things. Is there a way to artificially try to insert a record in a zone file from DCL ? (this DHCP thing is very tedious since one needs to reset the DHCP status on the client so it can make a new request to test). I thought migrating from VAX to Alpha would be a cinch. Turns out it might have taken just as long to learn Linux and do as Hoff now recomments. This is all stuff that had been working fine on VAX with 5.3 of TCPIP Services. (DHCP serving my MAC as well as the dynamic updates to DNS for both the forward and reverse translations. ------------------------------ Date: Sun, 14 Jan 2007 18:14:44 GMT From: "Colin Butcher" Subject: Re: Free cool VMS Email account Message-ID: You can also get a free e-mail account at https://trysecureserver.com/ - which is running on a VMS platform. Cheers, Colin. ------------------------------ Date: Sun, 14 Jan 2007 05:30:30 -0500 From: JF Mezei Subject: Re: Moving from Bind 8 to Bind 9 Message-ID: <45aa067e$0$8793$c3e8da3@news.astraweb.com> My old 8.* TCPIP$BIND.CONF on VAX generated a few errors (notably a statement about forward first without a list of forwarders, whereas the 8.* software didn't complain about it). Also, in each zone file, one must add a TTL. This can be done by adding a $TTL statement before the SOA statement which is then applied to every record in the zone file. Also, in the .CONF file, if you have an allow-updates { 10.0.0.10 ; } ; for instance, the 9.0 server will complain about it being insecure because hosts are specified by IP address. creating and ACL and specifying the ACL name seems to please the server even if in the end, it is the same specification. Also, it appears that you need to allow updates from 127.0.0.1 since the DHCP server now uses that interface to talk to the bind server. So i guess the restriction that the DHCP server must run on the same node as the Bind server is still in effect. ------------------------------ Date: Sun, 14 Jan 2007 06:54:46 -0500 From: JF Mezei Subject: Re: Moving from Bind 8 to Bind 9 Message-ID: <45aa199e$0$14715$c3e8da3@news.astraweb.com> JF Mezei wrote: > creating and ACL and specifying the ACL name seems to please the server > even if in the end, it is the same specification. Found out later this is not the case. And even an ACl generates the message: ## Sun 14 04:29:36 WARNING: zone 'SKONOSKI.COM' allows updates by IP address, which is insecure # This appears to be standard on all the new Bind implementations, even on Hoff's recommended Linux platform. Seems that since an IP can be spoofed, they consider IP address based ACLs to be insecure. Interestingly, the TCPIP SET NAME/INIT (which sends a message to the bind server to reload the zone files) has been changed to use some secure method to talk to the bind server (which required I run some utility to generate some keys in TCPIP$ETC). However, the DHCP software seems to talk to bind in normal ways. ------------------------------ Date: 14 Jan 2007 08:40:35 -0800 From: "siju" Subject: Re: OpenVMS Licence for people in Asia Message-ID: <1168792835.128640.125490@11g2000cwr.googlegroups.com> On Jan 13, 9:15 am, "johnhreinha...@yahoo.com" wrote: > >Siju Siju, > > You pick the VAX Base License and the Layered Products set. The > first gets you the license to run the basic OpenVMS operating system, > the second gets you the license keys for everything else - TCP/IP, > DECnet, C, BASIC, FORTAN, etc. The reason they are separate is that > the Base license is specific to your CPU/system but the Layered > Product keys work on any VAX or Alpha. > > I believe that for a license for SimH you put "SIMH" for the CPU > serial # > Thankyou so much John :-) it worked Now :-) Kind Regards Siju ------------------------------ Date: Sun, 14 Jan 2007 12:23:40 -0500 From: =?ISO-8859-15?Q?Arne_Vajh=F8j?= Subject: Re: RUN SYS$SYSTEM:DCL on Itanium VMS 8.2-1 Message-ID: <45aa671a$0$49197$14726298@news.sunsite.dk> Marc Van Dyck wrote: > And by the way, what the heck is "DEC/Shell" ? I believe it was a Unix shell for VMS systems offered by DEC back in the 80's (before POSIX). Arne ------------------------------ Date: Sun, 14 Jan 2007 11:09:25 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Suggestion: SET FILE/SHADOW= Message-ID: In article <45a956de$0$25408$c3e8da3@news.astraweb.com>, JF Mezei writes: > Phillip Helbig---remove CLOTHES to reply wrote: > > $ @ DISK:[DIR]FILE.COM > > > > in the above files, and have DISK be a non-system disk accessible by all > > nodes in the cluster. Before you issue the above command, you can check > > if the file exists and take appropriate action. > > That is the problem. In a low end cluster, your disks are inside the > systems. So there are no disks that are directly accessible to all systems. My hobbyist cluster is rather low-end. Most of the hardware I got for free and dates from the late 80s/early 90s. All your disks should be shadow sets based on host-based volume-shadowing. If the disk is relevant for only one node (e.g. the system disk), have all members on that node, otherwise distribute them across nodes. Such virtual disks are accessible by all systems as long as at least one node hosting a member of the shadow set is up. With a three-node cluster, I have two members in such a shadow set. I don't need to deal with the possibility that the only member which is up doesn't host a member, since in that case I don't have quorum and if the machine is booting at all, it would be for maintenance etc in which case I don't need a full-scale startup. (To be sure, the startup sequence executed in such a case might be the same on all nodes, but it is relatively static so it is less trouble to set it up once on all nodes by hand and leave it at that.) If you want to have more than three nodes in your cluster, you could have three members in your shadow set. ------------------------------ End of INFO-VAX 2007.028 ************************