[695] in Moira
Moira & afs.incr
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed Dec 22 07:09:08 1993
Date: Wed, 22 Dec 1993 07:08:29 -0500
To: tytso@MIT.EDU, bug-moira@MIT.EDU
From: "Richard Basch" <basch@MIT.EDU>
Dec 14 12:22:01 <8031> Couldn't add rbosco to system:rbosco: User or group doesn't exist
Dec 14 15:34:27 <8511> Couldn't add gossard to system:gossard: User or group doesn't exist
Dec 16 16:05:58 <12160> Couldn't add alcohen to system:alcohen: User or group doesn't exist
Dec 20 12:18:40 <16737> Couldn't add cefola to system:cefola: User or group doesn't exist
These are all the result of a "register_user" query.
Suspiscion:
- It is being passed to the incremental as first reactivating the user,
which will then try to lookup up his grouplist and then try to add him
to all of those groups, and then the reactivation of his group.
Because the reactivation of the user has to do a callback to the server,
it discovers that the group is active, and is therefore correct in
reporting that there is an inconsistency between the server and the
prdb. The afs.incr program doesn't know that it will shortly be passed
a group reactivation, which will then correct the problem.
Unfortunately, either reactivation while the database is already
complete will generate this error. I may simply change the error text
to simply mention that this is an error due to reactivation. The
afs.incr program already knows that it is a reactivation since there are
both "before" and "after" values.
What I will probably do is setup the following additional tags to be
printed along with the existing text:
"user modify: "
"user add: "
"user delete: "
"list modify: "
"list add: "
"list delete: "
"member add: "
"member delete: "
or some take on that (perhaps in more verbose readable English).
I left off the "filesys" versions since they simply execute another
script and all output from that script is considered to be error text.
(Also, there is no "member modify".)
-Richard
