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.


Reply via email to