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