Re: [rt-users] Fail over Cie How you do it

[Kevin Falcone]

On Wed, Nov 06, 2013 at 02:59:05PM +0100, Albert Shih wrote:
 If I take the « mail » example, it's « easy » to make a upgrade/maintenance
 of mai-server because we don't loose any mail. If the smtp server is down, 
 all 
 MTA known to keep mails in the queue. 
 
 If RT is down, all request go to a blackhole. Until now what I'm doing is
 to change the aliases tables before update
 
 request -- RT
 
 to
 
 request -- somebody@
 
 and when RT come back, I push the ticket manually. But that's is possible
 because I don't have so much ticket. 

A properly configured mail delivery to RT will hold mail in the mail
queue until RT is back up.  If you're losing mail when apache is down,
you've done something very very wrong.  rt-mailgate will always return
either Success or Temporary Failure.

If we're worried about a particularly long maintenance window, we'll
use postfix's hold queue to stick mail aside and not have postfix
retry submissions.  In general though, upgrades from 4.0.17 to 4.0.18
are simple make upgrade, make upgrade-datbase, clear mason cache and
restart apache operations for us.

If we're concerned about larger upgrades, we make a clone VM and test
there.

-kevin


pgpBm6_UJ5TZt.pgp
Description: PGP signature

Re: [rt-users] Fail over Cie How you do it

[Thomas Bätzler]

Salut,

Am 06.11.2013 14:59, schrieb Albert Shih:
 Hi,

 For one time not exactly a technical question.

 Long time ago when first time I install a RT it's for my own use. After
 that the « virus » spread to my team. 

 Now all IT team use RT. 

 They are some project to extend RT to other services. 

 That's mean progressively RT become a very important software.

 But in that case how you manage to do some upgrade, maintenance, etc..

 If I take the « mail » example, it's « easy » to make a upgrade/maintenance
 of mai-server because we don't loose any mail. If the smtp server is down, 
 all 
 MTA known to keep mails in the queue. 

 If RT is down, all request go to a blackhole. Until now what I'm doing is
 to change the aliases tables before update

 request -- RT

 to

 request -- somebody@

 and when RT come back, I push the ticket manually. But that's is possible
 because I don't have so much ticket. 

 So my question is when you RT is very important how you do the
 failover/upgrade/maintenance.

We're running RT on a dedicated machine, so the local mail server on
that box is only responsible for handing off mails to rt-mailgate. When
we're doing upgrades, we're using iptables firewall rules to block
incoming external smtp connections - we can still send test mails to see
wether ticket creation works locally, but mail from other systems will
not be delivered until we remove the blocking rules. If you want to be
100% sure of not losing any mail, just set up another mail system to act
as a secondary MX for your RT mail domains - that way you can be sure
the mails are held as long as needed.

As for upgrading - best practise is probably to set up a staging system
that's mostly identical to the production system, then try out the
upgrade on the staging system before you do it on the production system.
Always make a backup of your database, RT installation and site_lib Perl
tree before doing RT upgrades.

HTH,
Thomas