elekaj34 wrote:
> J'aimerais mettre en place un MX secondaire pour mon domaine.
> Par contre, j'aimerais savoir si mes utilisateurs pourront lire leur
> mail stockés sur le MX secondaire (en cas de panne du MX primaire) ?

Euh, il y a deux choses qui n'ont rien à voir:
- les MX, qui reçoivent les mails, qui peuvent être redondants (MX
secondaires, multiples..) via des enregistrements multiples dans le DNS,
avec une priorité pour chacun.
- les accès type POP, IMAP, etc. qui eux aussi *peuvent* être redondants

En général, quand un MX tombe, le 2e "prend le relais" (en fait il ne
prend rien du tout, c'est juste que les serveurs l'utilisent comme
serveur de secours), et est configuré pour tout relayer directement vers
le MX primaire. Evidemment le secondaire a une queue de réception, et
attend gentiment que le MX primaire soit de nouveau disponible.

elekaj34 wrote:
> J'aimerais mettre en place un MX secondaire pour mon domaine.
> Par contre, j'aimerais savoir si mes utilisateurs pourront lire leur
> mail stockés sur le MX secondaire (en cas de panne du MX primaire) ?

Euh, il y a deux choses qui n'ont rien à voir:
- les MX, qui reçoivent les mails, qui peuvent être redondants (MX
secondaires, multiples..) via des enregistrements multiples dans le DNS,
avec une priorité pour chacun.
- les accès type POP, IMAP, etc. qui eux aussi *peuvent* être redondants

En général, quand un MX tombe, le 2e "prend le relais" (en fait il ne
prend rien du tout, c'est juste que les serveurs l'utilisent comme
serveur de secours), et est configuré pour tout relayer directement vers
le MX primaire. Evidemment le secondaire a une queue de réception, et
attend gentiment que le MX primaire soit de nouveau disponible.

Xavier Roche a écrit :
> elekaj34 wrote:
>
>> J'aimerais mettre en place un MX secondaire pour mon domaine.
>> Par contre, j'aimerais savoir si mes utilisateurs pourront lire leur
>> mail stockés sur le MX secondaire (en cas de panne du MX primaire) ?
>
>
> Euh, il y a deux choses qui n'ont rien à voir:
> - les MX, qui reçoivent les mails, qui peuvent être redondants (MX
> secondaires, multiples..) via des enregistrements multiples dans le DNS,
> avec une priorité pour chacun.
> - les accès type POP, IMAP, etc. qui eux aussi *peuvent* être redondants
>
> En général, quand un MX tombe, le 2e "prend le relais" (en fait il ne
> prend rien du tout, c'est juste que les serveurs l'utilisent comme
> serveur de secours), et est configuré pour tout relayer directement vers
> le MX primaire. Evidemment le secondaire a une queue de réception, et
> attend gentiment que le MX primaire soit de nouveau disponible.
>
>

Donc si j'ai bien compris, pour avoir un secour total (SMTP + IMAP), il
faut un DNS configuré comme suit :

MX 10 mx1.mondomaine.net
MX 20 mx2.mondomaine.net

imap-1 A 1.2.3.4
imap-2 A 4.5.6.7
smtp-1 A 1.2.3.4
smtp-2 A 4.5.6.7

Avec machine A en IP 1.2.3.4 et une machine B en IP 4.5.6.7.
La machine A est le serveur primaire (SMTP + IMAP) et la machine 2, le
serveur de secours.

En cas de panne du serveur primaire, les mails arriveront sur le MX
secondaire, et les utilisateurs pourront donc dans ce cas envoyer et
recevoir leurs mails en utilisant la machine B. C'est bien cela ?

Il restera donc a syncroniser les comptes IMAP de chaque utilisateurs a
intervalles réguliers.

Est ce la bonne méthodologie ?

Cordialement

Elekaj

Xavier Roche a écrit :
> elekaj34 wrote:
>
>> J'aimerais mettre en place un MX secondaire pour mon domaine.
>> Par contre, j'aimerais savoir si mes utilisateurs pourront lire leur
>> mail stockés sur le MX secondaire (en cas de panne du MX primaire) ?
>
>
> Euh, il y a deux choses qui n'ont rien à voir:
> - les MX, qui reçoivent les mails, qui peuvent être redondants (MX
> secondaires, multiples..) via des enregistrements multiples dans le DNS,
> avec une priorité pour chacun.
> - les accès type POP, IMAP, etc. qui eux aussi *peuvent* être redondants
>
> En général, quand un MX tombe, le 2e "prend le relais" (en fait il ne
> prend rien du tout, c'est juste que les serveurs l'utilisent comme
> serveur de secours), et est configuré pour tout relayer directement vers
> le MX primaire. Evidemment le secondaire a une queue de réception, et
> attend gentiment que le MX primaire soit de nouveau disponible.
>
>

Donc si j'ai bien compris, pour avoir un secour total (SMTP + IMAP), il
faut un DNS configuré comme suit :

MX 10 mx1.mondomaine.net
MX 20 mx2.mondomaine.net

imap-1 A 1.2.3.4
imap-2 A 4.5.6.7
smtp-1 A 1.2.3.4
smtp-2 A 4.5.6.7

Avec machine A en IP 1.2.3.4 et une machine B en IP 4.5.6.7.
La machine A est le serveur primaire (SMTP + IMAP) et la machine 2, le
serveur de secours.

En cas de panne du serveur primaire, les mails arriveront sur le MX
secondaire, et les utilisateurs pourront donc dans ce cas envoyer et
recevoir leurs mails en utilisant la machine B. C'est bien cela ?

Il restera donc a syncroniser les comptes IMAP de chaque utilisateurs a
intervalles réguliers.

Est ce la bonne méthodologie ?

Cordialement

Elekaj

elekaj34 wrote:
> smtp-1 A 1.2.3.4
> smtp-2 A 4.5.6.7

imap IN CNAME imap-1
imap IN CNAME imap-2
smtp IN CNAME smtp-1
smtp IN CNAME smtp-2

Le problème c'est que le resolver va renvoyer dans un ordre aléatoire
les CNAME pour imap et smtp (pas de vrai "failover" comme pour les
enregistrements MX)

> Il restera donc a syncroniser les comptes IMAP de chaque utilisateurs a
> intervalles réguliers.

Ouais.. pas totalement trivial à faire.

elekaj34 wrote:
> smtp-1 A 1.2.3.4
> smtp-2 A 4.5.6.7

imap IN CNAME imap-1
imap IN CNAME imap-2
smtp IN CNAME smtp-1
smtp IN CNAME smtp-2

Le problème c'est que le resolver va renvoyer dans un ordre aléatoire
les CNAME pour imap et smtp (pas de vrai "failover" comme pour les
enregistrements MX)

> Il restera donc a syncroniser les comptes IMAP de chaque utilisateurs a
> intervalles réguliers.

Ouais.. pas totalement trivial à faire.

Le Tue, 27 Sep 2005 11:22:15 +0200, Xavier Roche écrivit:
> > Il restera donc a syncroniser les comptes IMAP de chaque
> > utilisateurs a intervalles réguliers.
> Ouais.. pas totalement trivial à faire.

Mouais. Faudrait regarder du côté de Cyrus-Murder, avec peut-être
un backend fichier commun...

Arnaud.
--
Perso: http://launay.org/blog/
Consulting: http://www.cusae.com/
Hébergement: http://www.nocworld.com/

Xavier Roche a écrit :
> elekaj34 wrote:
>
>> smtp-1 A 1.2.3.4
>> smtp-2 A 4.5.6.7
>
>
> imap IN CNAME imap-1
> imap IN CNAME imap-2
> smtp IN CNAME smtp-1
> smtp IN CNAME smtp-2
>
> Le problème c'est que le resolver va renvoyer dans un ordre aléatoire
> les CNAME pour imap et smtp (pas de vrai "failover" comme pour les
> enregistrements MX)
>
>> Il restera donc a syncroniser les comptes IMAP de chaque utilisateurs
>> a intervalles réguliers.
>
>
> Ouais.. pas totalement trivial à faire.

Hi,

En fait l'ordre n'est pas forcement aléatoire,
en général il alterne, c'est ce qu'on appel du "round robin" DNS.
C'est un peu la haute disponibilité du pauvre ...
Le problème se pose lorsqu'un des serveurs IMAP ou SMTP
sera défaillant ... ton client de messagerie rencontrera une erreur
une fois sur deux.

Si tu veux un vrai failover il faut gérer un peu plus de chose,
- une base d'info commune ou synchronisé (RSYNC) mail + comptes
utilsateurs ...
- une supervision des services (MON)
- un module de haute dispo (Linux-HA)
etc ...

Bon ca peut rapidement devenir complexe mais c'était juste un exemple.

Cordialement,

Régis

Regis TOUVRON wrote:
> En fait l'ordre n'est pas forcement aléatoire,
> en général il alterne, c'est ce qu'on appel du "round robin" DNS.

Sauf que, de mémoire, la couche du resolver mélange les réponses du
serveur DNS pour forcer le caractère aléatoire.

Regis TOUVRON wrote:
> En fait l'ordre n'est pas forcement aléatoire,
> en général il alterne, c'est ce qu'on appel du "round robin" DNS.

Sauf que, de mémoire, la couche du resolver mélange les réponses du
serveur DNS pour forcer le caractère aléatoire.

Xavier Roche wrote:
> elekaj34 wrote:
>
>> J'aimerais mettre en place un MX secondaire pour mon domaine.
>> Par contre, j'aimerais savoir si mes utilisateurs pourront lire leur
>> mail stockés sur le MX secondaire (en cas de panne du MX primaire) ?
>
>
> Euh, il y a deux choses qui n'ont rien à voir:
> - les MX, qui reçoivent les mails, qui peuvent être redondants (MX
> secondaires, multiples..) via des enregistrements multiples dans le DNS,
> avec une priorité pour chacun.
> - les accès type POP, IMAP, etc. qui eux aussi *peuvent* être redondants

Est-il possible de définir 2 MX avec un niveau de priorité égal pour
faire une sorte de répartition de charge ou de redondance mais explicite
ou vaut-il mieux déplacer le mécanisme au niveau du
firewall/routeur/boiboite ?

Du genre :

MX 10 smtp0.mondomaine.net
MX 10 smtp1.mondomaine.net
MX 20 mx0.foo.bar
MX 20 mx1.foo.baz

Merci.

Manu <nobody@guzu.net> écrivait:

> Est-il possible de définir 2 MX avec un niveau de priorité égal pour
> faire une sorte de répartition de charge ou de redondance mais explicite
> ou vaut-il mieux déplacer le mécanisme au niveau du
> firewall/routeur/boiboite ?
>
> Du genre :
>
> MX 10 smtp0.mondomaine.net
> MX 10 smtp1.mondomaine.net
> MX 20 mx0.foo.bar
> MX 20 mx1.foo.baz

Oui, on peut.

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf

Le 4 octobre 2005 à 07:44, Manu a écrit :

> Est-il possible de définir 2 MX avec un niveau de priorité égal pour
> faire une sorte de répartition de charge ou de redondance mais explicite
> ou vaut-il mieux déplacer le mécanisme au niveau du
> firewall/routeur/boiboite ?

9:32 fred@balvenie:~> host -t mx microsoft.com
microsoft.com mail is handled by 10 maila.microsoft.com.
microsoft.com mail is handled by 10 mailb.microsoft.com.
microsoft.com mail is handled by 10 mailc.microsoft.com.

Ca répond à la question ?

Au fait, là où ça devient rigolo, c'est ça :

9:32 fred@balvenie:~> host maila.microsoft.com
maila.microsoft.com has address 131.107.3.125
maila.microsoft.com has address 131.107.3.124
9:33 fred@balvenie:~> host mailb.microsoft.com
mailb.microsoft.com has address 207.46.121.51
mailb.microsoft.com has address 131.107.3.123

.... !

Fred
--
Oh I try to find her Oh I try to answer I touch her hand And death
smiles She really want to take me I've seen the door And the walls
cry (So) let it drain (Your) static blood And kiss the fallen angel
Down in the heart of hell (Noir Désir, Lola)

F. Senault wrote:
> Au fait, là où ça devient rigolo, c'est ça :
> 9:32 fred@balvenie:~> host maila.microsoft.com
> maila.microsoft.com has address 131.107.3.125
> maila.microsoft.com has address 131.107.3.124

En théorie, et sous réserve que je dise pas de conneries, il y a deux
niveaux:

1- les MX, avec les priorités qui vont bien - le client/serveur va
essayer d'envoyer le mail en choisissant un serveur (avec la priorité la
plus basse en premier). en cas d'échec, il regarde si un MX existe avec
une priorité égale ou plus élevée, et rebelotte. ça, c'est la
redondance/failover côté MX.

2- les entrées A du DNS qui corresponsent à un nom - le client qui fait
le gethostbyname()/connect() [ou le getipnodebyname() désormais :p],
est supposé essayer de se connecter à la première IP qui est donnée, et
en cas d'échec la suivante, etc.. (en gros, tenter l'ensemble des
adresses données dans le addr_list du hostent). ça c'est le failover du
pauvre, côté TCP.

Exemple:

$ telnet mx.free.fr
Trying 212.27.42.19...
telnet: connect to address 212.27.42.19: Connection refused
telnet: connect to address 212.27.42.22: Connection refused
telnet: connect to address 212.27.42.18: Connection refused
telnet: connect to address 212.27.42.23: Connection refused
telnet: connect to address 212.27.42.21: Connection refused
telnet: Unable to connect to remote host: Connection refused

Autant le 1 est réservé aux MX (avec une priorité, ce qui permet d'avoir
un failover un peu plus intelligent), autant le 2 est valable partout.

Sauf que beaucoup d'applications gèrent correctement le 1, mais avec un
délais de re-tentative de l'ordre de quelques minutes à quelques heures,
et ignorent le 2 (en prenant la première adresse, h_addr, qui correspond
à h_addr_list[0] - vous connaissez beaucoup de développeurs qui se
souciens de savoir si une autre IP répond en cas d'échec d'un connect()
? :p) ; qui est néanmoins "balancée" car la couche de résolution DNS
renvoie les adresses dans le désordre.

Donc dans les faits,
1 est utile pour la redondance/failover
2 est utile pour le load banlancing

F. Senault wrote:
> Au fait, là où ça devient rigolo, c'est ça :
> 9:32 fred@balvenie:~> host maila.microsoft.com
> maila.microsoft.com has address 131.107.3.125
> maila.microsoft.com has address 131.107.3.124

En théorie, et sous réserve que je dise pas de conneries, il y a deux
niveaux:

1- les MX, avec les priorités qui vont bien - le client/serveur va
essayer d'envoyer le mail en choisissant un serveur (avec la priorité la
plus basse en premier). en cas d'échec, il regarde si un MX existe avec
une priorité égale ou plus élevée, et rebelotte. ça, c'est la
redondance/failover côté MX.

2- les entrées A du DNS qui corresponsent à un nom - le client qui fait
le gethostbyname()/connect() [ou le getipnodebyname() désormais :p],
est supposé essayer de se connecter à la première IP qui est donnée, et
en cas d'échec la suivante, etc.. (en gros, tenter l'ensemble des
adresses données dans le addr_list du hostent). ça c'est le failover du
pauvre, côté TCP.

Exemple:

$ telnet mx.free.fr
Trying 212.27.42.19...
telnet: connect to address 212.27.42.19: Connection refused
telnet: connect to address 212.27.42.22: Connection refused
telnet: connect to address 212.27.42.18: Connection refused
telnet: connect to address 212.27.42.23: Connection refused
telnet: connect to address 212.27.42.21: Connection refused
telnet: Unable to connect to remote host: Connection refused

Autant le 1 est réservé aux MX (avec une priorité, ce qui permet d'avoir
un failover un peu plus intelligent), autant le 2 est valable partout.

Sauf que beaucoup d'applications gèrent correctement le 1, mais avec un
délais de re-tentative de l'ordre de quelques minutes à quelques heures,
et ignorent le 2 (en prenant la première adresse, h_addr, qui correspond
à h_addr_list[0] - vous connaissez beaucoup de développeurs qui se
souciens de savoir si une autre IP répond en cas d'échec d'un connect()
? :p) ; qui est néanmoins "balancée" car la couche de résolution DNS
renvoie les adresses dans le désordre.

Donc dans les faits,
1 est utile pour la redondance/failover
2 est utile pour le load banlancing

Xavier Roche a écrit :
> F. Senault wrote:
>
>> Au fait, là où ça devient rigolo, c'est ça :
>> 9:32 fred@balvenie:~> host maila.microsoft.com
>> maila.microsoft.com has address 131.107.3.125
>> maila.microsoft.com has address 131.107.3.124
>
>
> En théorie, et sous réserve que je dise pas de conneries, il y a deux
> niveaux:
>
> 1- les MX, avec les priorités qui vont bien - le client/serveur va
> essayer d'envoyer le mail en choisissant un serveur (avec la priorité la
> plus basse en premier). en cas d'échec, il regarde si un MX existe avec
> une priorité égale ou plus élevée, et rebelotte. ça, c'est la
> redondance/failover côté MX.
>
> 2- les entrées A du DNS qui corresponsent à un nom - le client qui fait
> le gethostbyname()/connect() [ou le getipnodebyname() désormais :p], est
> supposé essayer de se connecter à la première IP qui est donnée, et en
> cas d'échec la suivante, etc.. (en gros, tenter l'ensemble des adresses
> données dans le addr_list du hostent). ça c'est le failover du pauvre,
> côté TCP.
>
> Exemple:
>
> $ telnet mx.free.fr
> Trying 212.27.42.19...
> telnet: connect to address 212.27.42.19: Connection refused
> telnet: connect to address 212.27.42.22: Connection refused
> telnet: connect to address 212.27.42.18: Connection refused
> telnet: connect to address 212.27.42.23: Connection refused
> telnet: connect to address 212.27.42.21: Connection refused
> telnet: Unable to connect to remote host: Connection refused
>

ça marche mieux avec le port:

telnet mx.free.fr 25
Trying 212.27.42.19...
Connected to mrelay3-2.free.fr.
Escape character is '^]'.
220 mrelay3-2.free.fr ESMTP

Xavier Roche a écrit :
> F. Senault wrote:
>
>> Au fait, là où ça devient rigolo, c'est ça :
>> 9:32 fred@balvenie:~> host maila.microsoft.com
>> maila.microsoft.com has address 131.107.3.125
>> maila.microsoft.com has address 131.107.3.124
>
>
> En théorie, et sous réserve que je dise pas de conneries, il y a deux
> niveaux:
>
> 1- les MX, avec les priorités qui vont bien - le client/serveur va
> essayer d'envoyer le mail en choisissant un serveur (avec la priorité la
> plus basse en premier). en cas d'échec, il regarde si un MX existe avec
> une priorité égale ou plus élevée, et rebelotte. ça, c'est la
> redondance/failover côté MX.
>
> 2- les entrées A du DNS qui corresponsent à un nom - le client qui fait
> le gethostbyname()/connect() [ou le getipnodebyname() désormais :p], est
> supposé essayer de se connecter à la première IP qui est donnée, et en
> cas d'échec la suivante, etc.. (en gros, tenter l'ensemble des adresses
> données dans le addr_list du hostent). ça c'est le failover du pauvre,
> côté TCP.
>
> Exemple:
>
> $ telnet mx.free.fr
> Trying 212.27.42.19...
> telnet: connect to address 212.27.42.19: Connection refused
> telnet: connect to address 212.27.42.22: Connection refused
> telnet: connect to address 212.27.42.18: Connection refused
> telnet: connect to address 212.27.42.23: Connection refused
> telnet: connect to address 212.27.42.21: Connection refused
> telnet: Unable to connect to remote host: Connection refused
>

ça marche mieux avec le port:

telnet mx.free.fr 25
Trying 212.27.42.19...
Connected to mrelay3-2.free.fr.
Escape character is '^]'.
220 mrelay3-2.free.fr ESMTP

Philippe P. wrote:
> ça marche mieux avec le port:

Non sans blague ? :p

L'exemple était là pour démontrer l'utilisation des adresses données par
le resolver en cas d'échec sur la connexion de la première adresse.

(Ps: <http://www.giromini.org/usenet-fr/repondre.html>)

Philippe P. wrote:
> ça marche mieux avec le port:

Non sans blague ? :p

L'exemple était là pour démontrer l'utilisation des adresses données par
le resolver en cas d'échec sur la connexion de la première adresse.

(Ps: <http://www.giromini.org/usenet-fr/repondre.html>)

Xavier Roche a écrit :
> Philippe P. wrote:
>
>> ça marche mieux avec le port:
>
>
> Non sans blague ? :p
>
> L'exemple était là pour démontrer l'utilisation des adresses données par
> le resolver en cas d'échec sur la connexion de la première adresse.
>
> (Ps: <http://www.giromini.org/usenet-fr/repondre.html>)
>

autant pour moi, je n'avais pas bien compris.Apres avoir relu ton post,
ça va mieux.désolé pour le dérangement et merci pour l'info

Xavier Roche a écrit :
> Philippe P. wrote:
>
>> ça marche mieux avec le port:
>
>
> Non sans blague ? :p
>
> L'exemple était là pour démontrer l'utilisation des adresses données par
> le resolver en cas d'échec sur la connexion de la première adresse.
>
> (Ps: <http://www.giromini.org/usenet-fr/repondre.html>)
>

autant pour moi, je n'avais pas bien compris.Apres avoir relu ton post,
ça va mieux.désolé pour le dérangement et merci pour l'info