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

2013-11-13 Thread 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


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

2013-11-06 Thread 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.

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: j...@obspm.fr
Heure local/Local time:
mer 6 nov 2013 14:40:26 CET


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

2013-11-06 Thread 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