Fail over & Cie How you do it

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.

Regards.

JAS

Albert SHIH
DIO b�timent 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
T�l�phone : +33 1 45 07 76 26/+33 6 86 69 95 71
xmpp: jas@obspm.fr
Heure local/Local time:
mer 6 nov 2013 14:40:26 CET

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

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