| Title: | DCE Product Information |
| Notice: | Kit Info - See 2.*-4.* |
| Moderator: | TUXEDO::MAZZAFERRO |
| Created: | Fri Jun 26 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2269 |
| Total number of notes: | 10003 |
Hi friends
I've got a couple of customer questions. Maybe somebody
saw smiliar "problems" or issues:
Thanks for any comment !!
Marco
I would like to ask a couple of questions, concerning DCE, which I think, can
not be answered by reading the product dokumentation:
1) In the logfiles of the security master and replica daemon of my cell, I quite
freqently find the error messages:
DCE$SPECIFIC:[VAR.SECURITY]DCE$SECD.OUT
(RPC_CN_AUTH_VFY_CLIENT_REQ) on server failed status = 14129020
and
(RPC_CN_AUTH_VFY_CLIENT_REQ) on server failed status = 14129025
what do they mean ? Why is there neither time stamp nor the client
principal name displayed ?
2) What is the meaning of those error counts:
cdscp> show server
SHOW
SERVER
AT 1997-03-14-15:16:03
Creation Time = 1997-03-14-02:05:28.054
Future Skew Time = 300
Read Operations = 8613
Write Operations = 109
Skulks Initiated = 45
Skulks Completed = 45
Times Lookup Paths Broken = 2 <----
Crucial Replicas = 0
Child Update Failures = 2 <----
Security Failures = 0
Known Clearinghouses = /.../gdcw4g_cell/gdcw4g_ch
cdscp>
Are the serious ? They happen, whenever I do a remote configuration of a
Windows NT 4.0 DCE 1.1c Client.
3) When I enter the command UCX SHOW COMM/MEM there a no WAITS and DROPS
displayed. But there are WAITS and DROPS displayed when I monitor single
devices allocated by DCE daemon processes. For example a device allocated by
the security master server:
UCX> show dev BG1393: /full
Device_socket: bg1393 Type: STREAM LOCAL REMOTE
Port: 1121 1234
Host: LOCALHOST LOCALHOST
Service: cdsLib
RECEIVE SEND
Queued I/O 0 0
Q0LEN 0 Socket buffer bytes 0 0
QLEN 0 Socket buffer quota 32768 32768
QLIMIT 0 Total buffer alloc 0 0
TIMEO 0 Total buffer limit 131072 131072
ERROR 0 Buffer or I/O waits 105 0
OOBMARK 0 Buffer or I/O drops 0 0
I/O completed 227 103
Bytes transferred 13021 25705
Options: None
State: ISCONNECTED PRIV
RCV Buff: WAIT
SND Buff: None
UCX> exit
is this serious ?
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2190.1 | answer to #2 | TUXEDO::ZEE | There you go. | Tue Mar 18 1997 11:56 | 41 |
>2) What is the meaning of those error counts: > > cdscp> show server > SHOW > SERVER > AT 1997-03-14-15:16:03 > Creation Time = 1997-03-14-02:05:28.054 > Future Skew Time = 300 > Read Operations = 8613 > Write Operations = 109 > Skulks Initiated = 45 > Skulks Completed = 45 > Times Lookup Paths Broken = 2 <---- > Crucial Replicas = 0 > Child Update Failures = 2 <---- > Security Failures = 0 > Known Clearinghouses = /.../gdcw4g_cell/gdcw4g_ch > cdscp> > > Are the serious ? They happen, whenever I do a remote configuration of a > Windows NT 4.0 DCE 1.1c Client. The two counters are related and are worth investigating. The seriousness depends on what directories are involved. Basically, a directory and its related child pointer entry (which is in its parent directory) are out of synch. Perhaps there is a missing child pointer entry or a dangling child pointer entry (points to non-existing directory). Check the cdsd.log file for any potential messages specifying what directory is in question. Otherwise, you should do recursive "cdscp list dir /.:/*" and compare to "cdscp list child /.:/*" and somewhere along the way, the two outputs will not match. If you are missing a child pointer entry, become cell_admin and create it via "cdscp create child". The server code will synchronize the attributes within a day and you should be all set. If you have a child pointer entry with no corresponding directory (and you know the directory should not exist), then you have a dangling child pointer, and you should just delete it via "cdscp delete child". --Roger | |||||
| 2190.2 | server failed status value meanings.... | STAR::SWEENEY | Thu Mar 27 1997 15:41 | 27 | |
On issue 1) What do they mean? > (RPC_CN_AUTH_VFY_CLIENT_REQ) on server failed status = 14129020 This status means the client request verification failed because the client's ticket has expired. > (RPC_CN_AUTH_VFY_CLIENT_REQ) on server failed status = 14129025 This status means the client request verification failed because there is too much of a skew between the client request time and the time on the security server. >Why is there neither time stamp nor the client principal name displayed ? The only answer I have is that it's not coded to display that information, I do not know why, possibly too much overhead to obtain the information. Issue 3) may be better addressed in the UCX notes conference, LASSIE::UCX. Dave | |||||