Scott Silva a écrit : > on 10/3/2007 3:25 PM Bazy spake the following: >> Ed W wrote: >>>> How to disable pop3 and imap access during the data migration process >>>> (duration 5 minutes to 10 minutes). Can i send a custom error >>>> message to >>>> our users ? >>>> >>> >>> I don't recall the exact details, but I think both options are possible >>> if you check the dovecot wiki. There is a good study regarding the >>> proxy stuff, and some notes on sending custom errors back (along with a >>> note that it's not supported on many clients) >>> >>> If you use SQL then you could simply change the query temporarily >>> >>> Also when I do my migration I change the permissions on the home >>> folders >>> first (root:root say) - this way if I muck something up they don't get >>> logged into the old mailbox. Then I reset the permissions back on the >>> new server and update the proxy settings. This also gives a random >>> error back to the client in the meantime if they try and log in. >>> >>> I should think that the above could even be scripted and run per >>> mailbox >>> for a very subtle downtime period... I use rsync once while the mailbox >>> is online, then change perms so that the user can't login, then do a >>> final rsync to get any changes across. I didn't check whether there is >>> a problem with an existing connection still accessing the data after >>> the >>> perms were changed though... >>> >>> Good luck >>> >>> Ed W >> >> I'm not an perl expert, but... you could create a script that listens on >> port 143, and one for 110, that acts as a server. So right after ".login >> <username> <password>" the perl script will print an error, telling the >> client that the server is down for maintenance or something like that. >> >> Like when you get the 550 error in smtp and it says "die spammer" :). >> >> I think you can use IO::Socket::Telnet. >> Take a look over these scripts: >> http://www-user.tu-chemnitz.de/~uro/perlgoodies/server/ >> >> It's just an idea... >> > Or just stop the dovecot running on the proxy and the connections will > just die. > Thanks for your answer, finaly the best solution is a simple chmod 0 on the /var/mail/domain.com ... migration, chmod 700 on the new disk, update the DB ... and wait about the cache TTL of the dovecot deliver ;-)
One bash script and 80% of my 10'000 domains can be migrated to the new disk in less than 5 minutes. Thanks you Dom
