Sorry, didn't mean to take this off-list... On Tuesday, October 22, 2002, at 09:08 AM, Matt Simerson wrote:
I think that having qmailadmin always read from the master is the best solution. Unfortunately, it would require updating the vpopmail API to add an argument specifying whether to use a read server or not. Unless someone knows a way around it.On Tuesday, October 22, 2002, at 11:27 AM, Bill Shupp wrote:After only getting the first half of the story yesterday, I duplicated your process to see if I could figure it out. The strange thing to me was that there are I think 3 select queries and 2 update queries that occur before modusergo is finished. This seems excessive. There really should just be one select, and one update.
I tend to agree.All the error checking and modifications to the vpw structure should happen in qmailadmin, with a single update at the end.The only problem with that is the vpopmail call vauth_setpw function doesn't handle crypting of the password. That needs to be done via a vpopmail call in case the sysadmin has set up crypt to use something other than the systems default crypt(). Of course, that could be as easy as adding a vcrypt routine to vpopmail if it doesn't already exist. Then you'd have the crypted password.
I think that refining this will be the best solution to the problem. However, the following select during moduser (called by the result page after modifying the user) might still get old data. I'm not sure how long replication takes.In theory, it's instant but on really busy systems, it can take up to a second or two. If replication breaks for any reason, it could be minutes or hours. You can't count on
No, specifically because I wrote a script that allows me to watch the replication among all four of my slaves at the same time. It often takes a few seconds for the slave to catch up. I picked 5 because it *should* succeed nearly every time.Did you experiment with sleeps less than 5 seconds?
I vaguely recall someone else having to put a sleep in either qmailadmin or vqadmin for this same reason.
But a sleep is a bandaid, it's not a solution.Maybe another solution would be to refresh back to the main menu, or user list after modifying. That would force a delay before moduser() does the next select for the result page.I think the ideal solution would be, as you stated, a one select, and one update function. At the very beginning of the modusergo subroutine, do your vauth_getpw so that you have all the values. Then, if there is a password update, then run the vcrypt function which will return the crypted password. Populate your vpw hash with the crypted password, any other changes as already configured and then at the end of the routine, update the master server.
My only beef with that is I that I think it should do the vauth_getpw from the MySQL master. That way you'll never end up overwriting newer data on the master from an out of date slave. That functionality will only affect people using MySQL replication and I think it's a safeguard that should be in place.
Short of that, one solution would be to merge the call to vpasswd into vauth_setpw, but as you pointed out above, the mkpasswd call from vpasswd, along with some other checking from that function, would need to added to modusergo. And to make sure that the next read doesn't get old information, you could go back to the main menu, or show_users instead of moduser. I could easily implement this solution this morning, if that's what people want to do.
Thoughts? What do you think Ken?
Cheers,
Bill Shupp
