| You can run the DNS setup before or after the installation.
The basic setup sets up directories needed by MCC itself (if you
run this one before installation the IVP test against the
DNS directory .MCC will succeed.
The DNS setup file sets up the DNS directories needed to store
node information (DNA_NODE, DNA_BACKTRANSLATION & children, & DNS_SYNONYM) and
the MCC context for the IDP (Initial Domain Part -- a number like
a telephone number which distinguishes your network from any
other) -- you can use the default of 49 or I can send you a document
that describes more details, or you can ask the GE folks what they
registered (you may get HUH as a reply). Also see MCC_DNS_SETUP_IDP.COM.
Once all the DNS_* directories and MCC* directories are created in
DNS you have the ability to register node4 and nodes. You may also
want to create additional directories for bridges, etc. rather
that cluttering up the DNS root directory with object names.
And don't forget to copy you DNS directories to a redundant DNS server.
Hope this helps. /Claudia
|
| A correction to .-1
The DNS_* referances should be DNA_*.
Also, I would STRONGLY reccomend that you create appropriate child
directories somewhere below the root to store any other entities you
will register (eg; Bridges, Stations, Domains). Don't under any
circumstances put the entities in the ROOT. DNS preformance is
directly affected by the number of things in the root and it doesn't
take many to make a difference.
Also, don't forget that if you are using Bridges and Stations, you WILL
need (required by MCC - see release notes) child directories for name
translation for them - :.MCC_BRIDGE_BACKTRANSLATION and
:.MCC_STATION_BACKTRANSLATION
s/rob
|
| In reponse to .-2:
> Also, I would STRONGLY reccomend that you create appropriate child
> directories somewhere below the root to store any other entities you
> will register (eg; Bridges, Stations, Domains). Don't under any
> circumstances put the entities in the ROOT. DNS preformance is
> directly affected by the number of things in the root and it doesn't
> take many to make a difference.
>
> Also, don't forget that if you are using Bridges and Stations, you WILL
> need (required by MCC - see release notes) child directories for name
> translation for them - :.MCC_BRIDGE_BACKTRANSLATION and
> :.MCC_STATION_BACKTRANSLATION
Before I installed DECmcc BMS V1.0, I executed
@MCC_DNS_BASIC_SETUP.COM which automatically creates both the
.MCC_BRIDGE_BACKTRANSLATION and .MCC_STATION_BACKTRANSLATION DNS
directories. Next, I performed the following command:
MCC> register bridge lan150 address=08-00-2B-3F-2E-78
registration successful
Then, I executed the following command:
DNSCP> show dir . object *
and the lan150 NAME appeared. Therefore, I assume that to get the lan150
name OUT of the DNS namespace root, I need ONLY perform the following
steps:
DNSCP> create dir .mcc_bridge
MCC> register bridge .mcc_bridge.lan150 address=08-00-2B-3f-2E-78
1) Are .MCC_BRIDGE and .MCC_BRIDGE_BACKTRANSLATION in the proper
parent-child relationship by merely creating the .MCC_BRIDGE DNS
directory?
2) Are the above steps necessary and sufficient? If so, then why do I NOT
see the DNS command, CREATE DIR .MCC_BRIDGE, in the
MCC_DNS_BASIC_SETUP.COM file by default?
3) Is there any SYNONYM convention for bridges so that the user doesn't
have to specify MCC> SHOW BRIDGE .MCC_BRIDGE.LAN150 ALL CHAR
but rather
MCC> SHOW BRIDGE LAN150 ALL CHAR,
even though DNS-wise, LAN150 resides in .MCC_BRIDGE.LAN150?
Please advise.
\Thanks in Advance!
|
| To move it you must first DEREGISTER the Bridge to remove it from the
root and then the Register command will work. Note that from the
viewpoint of MCC this is a new bridge so if the bridge were included
in domains or there was historical data collected, it will only be
for the first registration in this case (since the UID for the bridge
will change when it is registered the second time).
There is no required relationship between .MCC_BRIDGE_BACKTRANSLATION
and any other child directory that you may create to store bridge info.
You can create a directory of any not reserved name for your bridges
etc. For example I could put all my MCC bridges, stations and domains
in one directory named .ROBS_MCC_STUFF and that would be fine. I think
your naming convention is good though for a single instance of MCC in a
network. If there will be many instanced of MCC in a network like if
it will be used by a central network ops group, and several local
groups at various sites you might want a directory structure that alows
the info to be appropriatly spread around the net. For example; if
you have 3 sites (FOO, SAM, BAR) you would want to install 2
nameservers at each site (for performance in general - not MCC
specific) and set up some directories like .FOO.MCC_BRIDGES ,
.SAM.MCC_BRIDGES and .BAR.MCC_BRIDGES . Create these so the master
replica of each is at the appropriate site (.BAR.MCC_BRIDGES would have
it's master replica on a server at site BAR with a copy on the second
server and perhaps a read-only copy at one other site). This is similar
to what the EASYnet is doing in the DEC: namespace. This way most
access to the nameserver can be satisfied at the local server.
I think I also answered your question #2. If not, ask some more.
For your #3, the answer at this time is NO. I believe that the
development group must provide this (and if they only used DNS with
things in child directories I think they would do it sooner) but I do
not know what comittment has been made to this.
Even though it is painful as far as typing long names right now, I
think it is best to bite the bullit and do it anyway. It will be very
painful to change the namespace later and this gets ready for when MCC
does provide some namespace path defaults.
s/rob
|