| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 465.1 | while we are looking for the bug in getprpwent | SMURF::BAT | Segui la tua beatitudine | Fri Mar 28 1997 14:56 | 5 |
| Are they running yppasswdd
Are they running ypbind -S
Is this only happening on a client? or yp slaver server? or yp master?
|
| 465.2 | more questions if you can get the answers | SMURF::BAT | Segui la tua beatitudine | Fri Mar 28 1997 16:54 | 38 |
|
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 ...
|
| 465.3 | update | RHETT::MOORE | | Tue Apr 01 1997 16:05 | 17 |
| 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
|
| 465.4 | | COMICS::CORNEJ | What's an Architect? | Wed Apr 02 1997 04:26 | 5 |
| We saw similar problems on DOVER - it was one of the reasons for moving
away from NIS to a bespoke solution.
Jc
|
| 465.5 | update | RHETT::MOORE | | Wed Apr 09 1997 14:05 | 6 |
| 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
|
| 465.6 | brane dammage | SMURF::BAT | Segui la tua beatitudine | Wed Apr 09 1997 21:21 | 30 |
| 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...
|