home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / kerberos / 866 < prev    next >
Encoding:
Text File  |  1992-11-13  |  1.7 KB  |  39 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!tytso
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: The incredible missing Principle trick
  5. Message-ID: <9211130336.AA02678@tsx-11.MIT.EDU>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. References: <1992Nov12.205140.24257@tc.cornell.edu>
  9. Date: Fri, 13 Nov 1992 03:36:24 GMT
  10. Lines: 27
  11.  
  12.    Date: Thu, 12 Nov 1992 20:51:40 GMT
  13.    From: Mike Hojnowski <mqh@theory.tc.cornell.edu>
  14.  
  15.    We're running Kerberos V4 here with about 6000 principles.  The server is 
  16.    running on an RS/6000 (AIX 3.2.0).  Somehow, for reasons unknown, 8 of our
  17.    principles disappeared over the weekend.  They appear in a "kdb_util dump"
  18.    on Sunday, and are gone on Tuesday.  The server was not interrupted at all
  19.    during that interval.
  20.  
  21.    Anyone seen anything like this before?
  22.  
  23. One possible reason is that you got unlucky with a hash collision which
  24. caused the DBM file to grow bigger than the max. allowable filesize on
  25. your system, and you have a badly implemented DBM library that doesn't
  26. deal well with that situation (i.e., fails silently) --- but that's only
  27. a guess.  At MIT, we haven't had that problem happen with our Kerberos
  28. database, which has almost 20,000 entries in it.  However, we have had
  29. this sort of problem with our /usr/lib/aliases file on our mailhub,
  30. when the length of the /usr/lib/aliases.pag gets bigger than 2
  31. gigabytes.
  32.  
  33. I'm not sure I believe this is what's really happening, though, since
  34. 6,000 principals isn't all that many.  We haven't seen your problem at
  35. MIT, although we're not running our server on a RS/6000.
  36.  
  37.                             - Ted
  38.  
  39.