On 09/26/2011 07:19 PM, Casey wrote:
Thanks Jake. I'm hoping to make this process as automated as possible...
What I'm wondering, is does the database need to be converted somehow
to work properly on the new server since the old server is running
mysql 4 and the new one is mysql 5? Also, in theory, if I recompiled
vpopmail to include the same features as the old server is running,
and then modified the sql dump file to replace the domain paths from
the old server with the correct ones on the new server
(/home/vpopmail/domains), and then rsync'd the mail over and kept it
in the same type of structure as it was on the old server...shouldn't
that work?
When I first tried doing that, I had copied over all of the config
files, hadn't copied all of the data from the domain folders, and
hadn't done any compiling beyond enabling many domains. Like I
mentioned before, I was able to get vuserinfo to recognize the
accounts with the quotas, username, password, encrypted password,
etc...but the major problem was that vqadmin would show the domain,
but wouldn't recognize that there were accounts associated with it.
Sure, you can do it this way, but you'll be doing the work twice. Once
to modify the stock packages now to ease the migration, and then again
to standardize your environment to this project. IMHO it would be time
best spent to do standardize it now, and forget worrying about
standardizing it later.
I guess I can kind of break this project up into to parts...my main
concern is getting everything moved to the new server, and then once
thats done I'd like to standardize things so that in the future if I
want to migrate I can just use the backup/restore scripts. I'm not
sure if this is better to try to tackle all at once, or two break up
into multiple tasks. It just seems like theres gotta be a way that
this can be done without a ton of scripting and manual entry -
especially considering i have everything in the database, I just need
to make sure that the domains/accounts are mapped to the correct
location in the file system.
So if you wrote a script on the source box to do something like "for
each vuserinfo" and walk the directory containing the users to get a
text output of the username (email address) and password, the ran a
script to "vadduser" each line in that text output you would have all of
the users recreated on the destination server. Then rsync each user's
dir to the new location (ie: rsync -avz --progress -e ssh /u/domain.com/
user@destination:/home/vpopmail/domain/) and you would have the user on
the new machine, and a copy of their mailstore on the destination server
as well. Maybe keep a looped script running to rsync the mailstore using
the "--delete" option to keep a sync'ed copy of the mailstore on the
destination until you have had a chance to test it out and feel
comfortable changing DNS over.
Then you don't have to futz with DB structures, translations, changes,
etc. And you have the added benefit of moving 1 domain at a time if you
want, so you can make the transition in a staged method.
Another question...theres been alot of talk on here about enabling
"many domains" vs. disabling it. As far as I know, in the current
version it is disabled, so when you create a new domain it creates a
table for that domain, opposed to putting them all under the vpopmail
table. Any idea how this will be setup in the future? Our existing
system has it enabled, and we have 300+ domains with alot of users, so
naturally it seems easier to try to keep things the same on our
migration, but that also means recompiling vpopmail every time we want
to update, so are we better off trying to convert our "many domains"
database to the current format?
So I have not seen any performance gain either way. The only benefit
thus far has been to ease writing of programs in using one table vs
many. I personally have a machine that has 450 domains, 4200 users, and
processes somewhere in the ballpark of 2 million emails a month (inbound
and outbound). This is on a P4 3Ghz with 2G of RAM. Most are POP3, and
I've had to tweak that to keep from hitting the maximum number of
connections, plus a few other tweaks, but nothing MAJOR.
If we do make a DB change in the future (and we probably will, since a
lot of people ask for it and there is no negative impact of changing) it
will be for a different version of QMT. If, and this is probably not
very likely, we change the DB format for the 1.3 branch, we will have
conversion scripts in place to assist with migrating beforehand.
