On Tuesday, October 22, 2002, at 07:49 AM, Matt Simerson wrote:
If you read through user.c, you'll find a subroutine "modusergo". In there, is the guts of what happens when you click on "modify user" and then "submit". Reading through that, it appears that if we get a new password, we make a call to vpasswd. This function, I would guess is against libvpopmail.a and connects to the MySQL update server and updates the password, in addition to running crypt() against the supplied password. At this point, all is well.What if you just moved the vpasswd call (to change the password) AFTER the other changes you make via vauth_getpw? You still have the problem of a user not seeing their changes propagate immediately (if they go to edit their page again, it might still show the old values).
However, in the very next function, the problem becomes manifest. We check for the value of gecos and if it exists (which it always does because it's value is in the HTML form) then it first makes a call to vauth_getpw. Testing has revealed that as expected, it does the database read from the MySQL read server on localhost. Unfortunately, it's making the query a tiny fraction of a second after writing the new password into MySQL update server. I'm sure Bill and Ken both know the problem now.
I can only think of one guaranteed way to fix it. That is to make sure that when qmailadmin does it's vauth_getpw call, it reads from the MySQL master. This is the only guaranteed way to assure that a successful database update written a fraction of a second before gets read back.I don't know enough about the vpopmail structures, but you would probably need to add a flag to vauth_getpw indicating whether it was allowed to read from the local (replicated) server, or if it should read from the master.
Qmailadmin should make all of its calls from the master, so it's always reporting the actual/current settings.
--
Tom Collins
[EMAIL PROTECTED]
