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=<filespec>
----------------------------------------------------------------------
Date: Sun, 14 Jan 2007 06:02:31 -0500
From: JF Mezei <jfmezei.spamnot@vaxination.ca>
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 <jfmezei.spamnot@vaxination.ca>
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 <name,ip address, client id> triple :
<shimano,10.0.0.150,01:00:05:9a:20:6e:0e>
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" <colinDOT.butcherAT@xdeltaDOT.coDOT.uk>
Subject: Re: Free cool VMS Email account
Message-ID: <oquqh.30894$k74.23962@text.news.blueyonder.co.uk>
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 <jfmezei.spamnot@vaxination.ca>
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 <value in seconds> 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 <jfmezei.spamnot@vaxination.ca>
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" <sgeorge.ml@gmail.com>
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"
<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?= <arne@vajhoej.dk>
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=<filespec>
Message-ID: <eod315$adc$1@online.de>
In article <45a956de$0$25408$c3e8da3@news.astraweb.com>, JF Mezei
<jfmezei.spamnot@vaxination.ca> 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
************************