| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4237.1 | See Topic 3862 | TRM::KWAK | | Fri Dec 11 1992 13:19 | 7 |
| RE:.0
Please look at topic 3862.1-3862.4.
The topic describes a similar problem and its fix.
William
|
| 4237.2 | More questions ... | UTRTSC::VELZEN | Pim van Velzen, CS/SSO Holland | Fri Dec 11 1992 13:56 | 31 |
|
Re: .1
Thanks for your fast response.
I did read this topic a number of times, but didn't had the feeling that
this explained the cause of this problem.
First of all, I am confused about the binary attribute sets which are
supposed to be there on the MCC objects.
I don't see them in the namespace of my customers system or on the MCC-
station of my colleague. Not on the 'good' objects and not on the 'bad'
objects ? Do you mean that they MUST be there ?
The suggested fix/workaround is to deregister the domain-member and
register it again.
We have done this on the customers system, i.e. deregister the culprit
member and show the domain again. The result was that the display was
much longer, but we got another NOATTRIB ten members further ...
As there are a lot of domains with a lot of members, this is almost
the same as starting all over again.
My idea was to use the backup of the customers system, and try to analyze
what is wrong with respect to MCC+DNS and, more important, to find out
what could have caused this, to prevent this in the future.
Still hope you can help me with this ...
/\Pim.
|
| 4237.3 | Some explanation on the cause of problem | TRM::KWAK | | Fri Dec 11 1992 15:52 | 42 |
|
Re: .2
> First of all, I am confused about the binary attribute sets which are
> supposed to be there on the MCC objects.
>
> I don't see them in the namespace of my customers system or on the MCC-
> station of my colleague. Not on the 'good' objects and not on the 'bad'
> objects ? Do you mean that they MUST be there ?
The Binary attributes cannot be seen using V1.1 DNS$Control.
The attributes can be seen using V2.0 DNS$Control (or dnscp on Ultrix),
but the attributes are ILV-encoded.
I have a utility program took::user$920:[kwak.public]read_attr2.exe
which prints out all attributes of a MCC-DNS object in readable format
(i.e. binary attributes are ILV-decoded and displayed).
> The suggested fix/workaround is to deregister the domain-member and
> register it again.
>
> We have done this on the customers system, i.e. deregister the culprit
> member and show the domain again. The result was that the display was
> much longer, but we got another NOATTRIB ten members further ...
> As there are a lot of domains with a lot of members, this is almost
> the same as starting all over again.
>
> My idea was to use the backup of the customers system, and try to analyze
> what is wrong with respect to MCC+DNS and, more important, to find out
> what could have caused this, to prevent this in the future.
The possible cause of the problem:
1. One could have used DNS$Control program to delete MCC-DNS
objects or objects attributes, or
2. One might have tried to replicated DNS directories using
V1.1 DNS$Control - I remember that coping a DNS directory does
copy binary attributes of objects in the directory.
William
|
| 4237.4 | Other possibilities ? | UTRTSC::VELZEN | Pim van Velzen, CS/SSO Holland | Fri Dec 11 1992 17:18 | 37 |
|
Re: .3
> I have a utility program took::user$920:[kwak.public]read_attr2.exe
> which prints out all attributes of a MCC-DNS object in readable format
> (i.e. binary attributes are ILV-decoded and displayed).
Ok thanks, I will use that to find out about the (missing) attributes.
> The possible cause of the problem:
> 1. One could have used DNS$Control program to delete MCC-DNS
> objects or objects attributes, or
This seems very unlikely to me, as the customer is using DNS($Control)
V1.1, is unable to display the binary attributes and is totally unaware
of the existance of these attributes.
> 2. One might have tried to replicated DNS directories using
> V1.1 DNS$Control - I remember that coping a DNS directory does
> copy binary attributes of objects in the directory.
I assume that you mean 'does NOT copy' ?
On the customers MCC-station a Digital colleague installed the DNS-server
with one clearinghouse containing the master-copy of all the DNS directories.
Later on he installed a second DNS-server and copied the directories to this
one as read-only copies.
In the current situation, the second (read-only) server is stopped and the
directories have been rebuild to the master-copy only.
As far as I have understood from various note-entries, the problem where
attributes are not copied correctly by a 'DNS> copy directory' only shows
with MCC if the read-operations come out on the replica-objects.
So my thought was/is, that this does not apply to the customers situation.
/\Pim.
|
| 4237.5 | NO binary attributes ... proven! | UTRTSC::VELZEN | Pim van Velzen, CS/SSO Holland | Fri Dec 11 1992 18:09 | 19 |
|
Re: .3/4
>> I have a utility program took::user$920:[kwak.public]read_attr2.exe
>> which prints out all attributes of a MCC-DNS object in readable format
>> (i.e. binary attributes are ILV-decoded and displayed).
>
>Ok thanks, I will use that to find out about the (missing) attribu
I have used the program to display the (hidden) binary attributes
on some good and some corrupted domain members/DNS objects.
This clearly shows that the 'bad' ones don't have the binary attributes
on them. This, at least, gives me the feeling that I know what the error-
messages means, i.e. where it comes from.
But, still looking for clues ...
/\Pim.
|
| 4237.6 | V1.1 of DNS will display the binary attributes... | FARMS::LYONS | Ahh, but fortunately, I have the key to escape reality. | Fri Dec 11 1992 18:33 | 13 |
| If and only if you get a copy of the "Special" DNS$CONTOL.BIN
that drives the internals of DNS and allows it to display them.
The problem stems from the fact that DNS was set up to display
attributes that start with " " (a space) or anything that is later
in the ASCII sequence. Attributes that start with hex 00 - hex 19
were skipped over.
I think that Rob Spence may have a copy of it. If so, please ask him
(or if you are reading this, Rob) to place it in the survival kit
and make it available to everyone.
DRL
|
| 4237.7 | | TRM::KWAK | | Tue Dec 15 1992 10:35 | 11 |
| RE: .4 & .5
From what I read from the replies, I think that your customer has
lost Binary attribute information by replicating a Read-only replica
of a directory and re-building the Master replica ("DNS> copy
directory" operation might have NOT copied the binary attributes.
Please try NOTED::DNS notes coference in order to get more info on
proper directory copy operations.
William
|