Conference smurf::dec_mls_plus

    Are they running yppasswdd
    
    Are they running ypbind -S
    
    Is this only happening on a client? or yp slaver server? or yp master?

    
    1.  Does it clear itself out?
    
    Also, does this "clear itself out", i.e., on a second (or third)
    attempt to login does it succeed or is this a hard failure, i.e., the
    ppde record has indeed vanished?  That is, the command:
    
    	ls /tcb/files/auth/{U}/{USERNAME}
    
    returns no file, authck fails, etc.
    
    
    2.  What is the exact sequence of events?
    
    Can you get a little more info on the login sequence too?
    Does this only happen if they attempt to login, but misstype their
    username or password, which then fails for that reason, then they
    try it again and they get the 
    "Protected Password information suddenly vanished"
    message?
    
    3.  Does the audit log report a failed update?
    
    Also, in the audit log, is there a record preceding the
    
    	"protected password entry vanished after write"
    
    record which reads:
    
    	"can't rewrite updated protected password entry"
    
    
    Sorry to annoy you with this detail, but there are four places
    in the login_sec code which reports this as the error.  I know,
    I know, every error code in the system should be unique, but hey...
    Well, now, I just realized I could send you a version of login_sec.o
    that would have unique error strings ...
    

    update that I got from a Digital rep down there...
    
    1. The problem does clear itself out and affects only one user at a
    time.  There was one time that it affected multiple users and didn't
    clear up by itself, but she thinks that this was caused by the customer
    trying to fix the situation manually and making it worse.
    
    2. This only happens from NIS clients.  They *think* it happens when
    their are multiple accesses going on to the password database at the
    same time, such as when multiple people are updating passwords, or
    several people are trying to login at the same time someone is updating
    their password.
    
    3. Don't know about the other audit entry you wanted to look for.  They
    will have to go back and look.
    
    Martin

    We saw similar problems on DOVER - it was one of the reasons for moving
    away from NIS to a bespoke solution.
    
    Jc
    

    update from the customer -- he removed the NIS slave server and
    cautioned the users to wait some time between password updates.
    They still get the message occasionally, but the password updates
    do seem to be occurring and they haven't had any accounts disappear.
    
    martin

    Hmm, Martin, I guess I'm still confused.  Let me know what I should do
    about this...  should I just test it on V4 and see if we get the same
    problem?  I'm not exactly sure what I should do here in order to
    reproduce this problem.
    
    By "removed the NIS slave server", did the customer mean that, on the
    yp client that are only clients, in the line that sets up ypbind,
    "ypbind -S domain,server1,server2,...,serverN" 
    they are no longer mentioning any slave servers, i.e., it only contains
    the master server?  Or do they now just have a domain consisting of a
    master server and N clients?
    
    Or if it is on a YP client that is also a slave server, does it just
    reference other slave (and master) servers and not itself? 
    
    And I didn't know any "accounts" were actually disappearing... you mean
    that "ypcat {passwd || prpasswd} | grep accountname" returns nothing?  
    
    
    So, should I try this only on yp client that is neither also a slave or
    master server?  Should I try it on a yp client that is also a slave
    server and has itself listed (first) in the ypbind?  Do I just start
    changing the password over and over until it fails?  I tried the latter
    on a yp client that was also a slave server (and checked to be sure
    that it was forcing an update of the master server, which then starting
    propagating the maps), but I have only a lightly loaded pair of
    systems, and I may not have been fast enough logging in again....
    
    Chatter chatter, this probably isn't helping to make it clear what
    isn't clear to me...