| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
I have a customer who has a worldwide namespace and has MCC management stations
in London and New York. After installing DECmcc the customer ran the command
procedure MCC_DNS_BASIC_SETUP.COM - this procedure creates directories .MCC,
.MCC_UID, .DNA_NODE etc under the root in DNS.
The namespace tree looks similar to this:
Namespace
|
|
|
--------------------------------------------
| | | |
New York MCC MCC_UID ........ London
The Ney York network managers control the root directory and the access control
to all 'top-level' directories. The London manager can make entries to the
London section of the namespace but not to any other sections (i.e. not to the
New York section, the root, .mcc etc).
What the customer would like to do is place the subdirectories .MCC, .MCC_UID
etc under the London directory (and the New York directory) so that network
managers in both New York and London can fully control their EMA entries in the
namespace (but have only read access to others).
An attempt to represent this graphically is show below:
Namespace
|
|
|
-------------------
| |
New York London
| |
----------- -----------
| | | |
.MCC ....MCC_UID .MCC ... .MCC_UID
My questions are:
DNS allows for this configuration in the namespace. What impact would having
the subdirectories .MCC, .MCC_UID etc in both locations have on DECmcc?
Is this the right way to support multiple domains under DECmcc?
Thanks in advance,
Gary.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 673.1 | It is a common problem | TOOK::JESURAJ | Tue Jan 29 1991 12:46 | 9 | |
Most our customers encounter this problem. (Talk to EasyNet folks; they
can tell you a lot about it.) We have plans to look at this issue
in DECmcc V1.2.
There is an interim solution to this problem. Contact Pete Savage
(Keel::savage) or John Egolf (took::egolf) for details.
Jay
| |||||
| 673.2 | DO NOT move backtranslation directories from root | TOOK::STRUTT | Colin Strutt | Tue Jan 29 1991 13:45 | 36 |
I would strongly suggest you do not contact John or Peter - what they
have is NOT intended for customer us, and we will NOT support it in
customer environments.
The answer to the customers perceived solution (sic!) is to step back
and look at the access control aspects of the name space.
Geographic directories (such as NewYork and London) can have access
control entries to allow the appropriately authorised people (let's
call them registrars) to register their own devices. Judicious use of
DNS groups as principals for ACEs is recommended for reasonable sized
customer networks - DNS documentation refers, I believe, to the similar
concept of a DNS group: Name_Czars - you might also have a group called
London_Registrars and New_York_Registrars. These authorised people
might be the only ones who could Register, Deregister and Rename
global entities.
Backtranslation directories (UID is a poor example, but there are
real backtranslation directories), can be protected by having ACEs
mention a DNS group that represents the amalgamation of all the site
groups - for example, All_Registrars, defined as containing
London_Registrars plus New_York_Registrars plus ... Now the
backtranslation directories would only need to allow write access (such
as during Register, Deregister and Rename) to the All_Registrars.
(BTW - the MCC_UID directory will be gone by v1.1, and the MCC
directory will also be removed soon).
Now, let me just mention WHY I suggest that you "change your customer's
perception" - we use backtranslation directories as a way of providing
not only address-to-name translation, but also as a way of ensuring
that each (global) device has a unique network-wide name. By making
backtranslation directories site-specific (or any scheme other than
global) network wide naming will be broken.
Colin
| |||||