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 |