Roxanne Sandesara wrote:
> Currently, on my qmail-toaster box, I have a single set of users set up
> as a single domain, with multiple aliased domains so that mail to
> <any_user>@<any_of_our_domains> will reach that user. However, the
> default domain that all of this is tied to needs to change from what it
> is current set to be, to that of one of the aliased domains. (In Other
> Words: everything is set up on <domain1.com>; I need <domain1.com> to
> become an alias, while <domain8.com> from the list of aliased domains
> will become the default and primary domain identity.)
>
> Thus far, in my search, I have found the table in the vpopmail database
> whose name will need to be changed; in addition, the path for each user
> will need to change, both in the database table and in the filesystem,
> to use the new default domain name. Looks like there's an entry in
> dir_control that will need to be changed; the values in the 'domain'
> column in lastauth; the values in the 'domain' column in valias, and the
> @<domain> part of each valias_line value. Obviously, I will need to
> rename the server within Linux to properly identify itself as
> mail.<domain8.com> rather than mail.<domain1.com>. I've also found the
> following files in /var/qmail/control that I believe will need to be
> changed:
>
> defaultdomain
> defaulthost
> me
> plusdomain
> rcpthosts
> smtpgreeting
> virtualdomains
>
> Now, having given this rundown, here comes my questions:
> 1) Does anyone know of anything I've missed, in the above, that I need
> to make sure to catch for this to go semi-smoothly.
You'll also need to take care of the contents of /var/qmail/users/. While
you can manually edit the assign file, re-creating the cdb is a bit tricky.
If I remember correctly, you might need to add and remove a dummy domain to
get this cdb rebuilt.
> 2) Is there an easier way of doing this that I am missing?
I'd consider removing the alias domain and adding it back in normally (using
vpopmail/bin commands). Then add users in the normal (qmail-admin) fashion.
That might not be feasible if you have 100's of users though.
This would be a lot safer than modifying the sql database manually. That
thing scares me a bit. There are bitmapped flags contained in one the fields
(gid, I think) that aren't readily apparent. In addition, the tables are all
ISAM, so be sure to have mysql backups (like from the qtp-backup script)
before you change anything there.
> 3) Is this likely enough to hose my server that I should build it up
> from scratch (after a proper backup, naturally)?
I don't think you need to go that far (unless you really hose things).
> 4) Am I correct that I should also get my reverse DNS records changed so
> that the IP for the server comes back with the new domain name?
I believe so, but I'm not certain of this.
> 5) Will this mess up the SSL key, requiring me to buy another one? (I
> don't really mind doing so, but I want to make sure of all my steps and
> preparations before I do this, as this is a live server in production,
> and I really can't afford for it to be down for untold hours.)
I believe so, but I'm not certain of this.
> I really want to make sure I have this planned out and prepped ahead of
> time. As stated, this is my live server in production. I don't have
> another box that I can bring up, configure from scratch, and just slip
> into place, so I need to get this right the first time.
>
> Roxanne
>
Sounds like you have a good start.
You might want to let the list know when you intend to do the cutover, so
help can be ready. Also, remember the #QmailToaster IRC channel. ;)
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
