Well...I was able to get the migrate-domain script i found working,
turns out the reason it wouldn't run, was because the Solaris server was
setup with tcsh as the default shell, instead of bash. I know...simple,
right?
Everything works pretty well so far. I run the script on each domain, it
creates a tarball of each mailbox, and generates a script that creates
the domain, each user, sets the password, quota, etc. It also recreates
the mailing lists. I had a few issues, because of the different paths
being used between the servers, but I wrote a simple script that
re-created the symlinks for each mailing list, and modified each file to
include the correct domain path for the mailing list.
Here is the next thing I'm not sure about...what is the best way for me
to re-create all of the user aliases? Looks like they are all stored in
the database on the old server, but is there an easy way that I can
"import" them?
Another issue I noticed, is that when I run vdominfo, the total user
count is only shown for the first domain I added - the other domains
simple say "0". However, vqadmin and vuserinfo both show all of the
domains, users, and appear to be working fine.
Thanks,
Casey
Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>
On 9/26/11 5:21 PM, Jake vickers wrote:
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.
