On Tue, Jul 27, 2010 at 3:08 PM, Alex Moura <[email protected]> wrote: > As Dominic and Kenneth pointed out, the planning should be simple but > carefully crafted. > Basically, having a new RT server installation, configured, tested and > running and a DB dump / restore will do the trick. > I only missed tips regarding special attention to the DNS / MX part of the > solution. > As you will be changing RT servers, it is important to include the MX > changes in the appropriate steps of the plan, both for testing and also for > entering in production. You may receive mail that can open new tickets > during testing, and you will have extra work to fix the mess or else opt - > if you can - to loose/ignore those tickets.
with qmail we have it setup like this #cat ~alias/.qmail-help |/opt/rt3/bin/rt-mailgate --queue help --action correspond --url https://rt.example.net 2>/dev/null || exit 111 so its a temporary failure signal to the sender's relay/smtp server. that means the mail won't be lost, it will re-attempt at a later time automatically this will allow you to keep the RT down for long time. > []'s, > Alex > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
