Bonjour tout le monde

J'éspère que je vais trouver quelqu'un ici en plein été...

Je dois déménager mon serveur (de Bezon vers Roubaix).

Hormis la fastidieuse mailing à préparer à cause du changement d'IP (désolé
d'avance), je me questionne au sujet du spool. En fait j'aimerai que ça
soit totalement transparent pour les utilisateurs. Je voudrais surtout
éviter une renumérotation des articles.
Le serveur d'origine a une partition reiserfs, donc je 'crois' que je ne
serais pas ennuyé par les inodes et cie.
Je pense carrément couper le serveur A, configurer le B (transfert du spool
que j'aurais compressé), attendre la propagation DNS et enfin activer le B.
Cela provoquera une coupure totale de 1 ou 2 jours.
Est-ce correct, que dois-je prévoir d'autre ? Tous conseils sont bienvenus.

Merci
Romain

Bonsoir Romain,

> En fait j'aimerai que ça
> soit totalement transparent pour les utilisateurs. Je voudrais surtout
> éviter une renumérotation des articles.

C'est effectivement préférable.


> Je pense carrément couper le serveur A, configurer le B (transfert du spool
> que j'aurais compressé), attendre la propagation DNS et enfin activer le B.
> Cela provoquera une coupure totale de 1 ou 2 jours.
> Est-ce correct, que dois-je prévoir d'autre ? Tous conseils sont bienvenus.

Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
la suite et il arrive qu'on ne s'en sorte pas, même à coup de makehistory.
La solution la plus propre et avec une plus faible interruption de service
est détaillée ici :

http://www.eyrie.org/~eagle/faqs/inn.html#S6.4

Tu mets le serveur B en esclave du A et transfères l'intégralité du spool.
Pendant le temps du transfert, ton serveur A reçoit toujours les articles
de l'extérieur (et les retransmet au B).

Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
les DNS et signale à tes pairs le changement d'IP.

--
Julien ÉLIE

« Un clavier azerty en vaut deux. »

Bonsoir Romain,

> En fait j'aimerai que ça
> soit totalement transparent pour les utilisateurs. Je voudrais surtout
> éviter une renumérotation des articles.

C'est effectivement préférable.


> Je pense carrément couper le serveur A, configurer le B (transfert du spool
> que j'aurais compressé), attendre la propagation DNS et enfin activer le B.
> Cela provoquera une coupure totale de 1 ou 2 jours.
> Est-ce correct, que dois-je prévoir d'autre ? Tous conseils sont bienvenus.

Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
la suite et il arrive qu'on ne s'en sorte pas, même à coup de makehistory.
La solution la plus propre et avec une plus faible interruption de service
est détaillée ici :

http://www.eyrie.org/~eagle/faqs/inn.html#S6.4

Tu mets le serveur B en esclave du A et transfères l'intégralité du spool.
Pendant le temps du transfert, ton serveur A reçoit toujours les articles
de l'extérieur (et les retransmet au B).

Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
les DNS et signale à tes pairs le changement d'IP.

--
Julien ÉLIE

« Un clavier azerty en vaut deux. »

Julien ÉLIE écrivit :

> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Ne pas oublier de baisser les TTL fortement plusieurs jours avant.

--
Michel

Julien ÉLIE écrivit :

> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Ne pas oublier de baisser les TTL fortement plusieurs jours avant.

--
Michel

Julien ÉLIE a écrit :
> Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
> la suite

Humm oui, j'ai déja testé (inter-archi, et entre deux machines de la
même archi) et ça a été à chaque fois un gros "oh merde!.." après des
jours de calculs de makehistory qui segfaulte, un tdx-util qui fume, ou
bien encore un historique délirant à la fin, etc. Grosso-modo, les
structures C sont sérialisées "tel quel" sur disque, avec numéro
d'inode, et donc il faut être assez chanceux pour s'en tirer.

<http://groups.google.com/group/news....ol+compatibili
ty%22&rnum=1&hl=fr#f4a6b05f11e92119>
(attention lien très long)

> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4

Seul truc bizarre: sur de très gros spool, j'ai plein d'articles rejetés
qui s'accumulent, pour une raison inconnue.

> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Accessoirement réfléchir à deux fois pour reiserfs. Ca ma pété à la
gueule trois fois un gros spool après la perte d'un secteur (eh oui les
disques consumer end pour un serveur de cuisine, c'est vraiment pas ça)

Depuis, je garde mon ext3 qui résiste tant bien que mal aux petites
péripéties.

Julien ÉLIE a écrit :
> Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
> la suite

Humm oui, j'ai déja testé (inter-archi, et entre deux machines de la
même archi) et ça a été à chaque fois un gros "oh merde!.." après des
jours de calculs de makehistory qui segfaulte, un tdx-util qui fume, ou
bien encore un historique délirant à la fin, etc. Grosso-modo, les
structures C sont sérialisées "tel quel" sur disque, avec numéro
d'inode, et donc il faut être assez chanceux pour s'en tirer.

<http://groups.google.com/group/news....ol+compatibili
ty%22&rnum=1&hl=fr#f4a6b05f11e92119>
(attention lien très long)

> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4

Seul truc bizarre: sur de très gros spool, j'ai plein d'articles rejetés
qui s'accumulent, pour une raison inconnue.

> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Accessoirement réfléchir à deux fois pour reiserfs. Ca ma pété à la
gueule trois fois un gros spool après la perte d'un secteur (eh oui les
disques consumer end pour un serveur de cuisine, c'est vraiment pas ça)

Depuis, je garde mon ext3 qui résiste tant bien que mal aux petites
péripéties.

Bonsoir Xavier,

>> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4
>
> Seul truc bizarre: sur de très gros spool, j'ai plein d'articles rejetés qui s'accumulent, pour une raison inconnue.

Il n'y a pas de message explicite mentionné à côté du rejet ?

Cela me fait d'ailleurs penser qu'en plus du

ctlinnd param c 0

il faudrait aussi préciser

ctlinnd perl n
ctlinnd python n

car sinon, il va y avoir plein de rejets pour cause d'EMP.

Mais je présume que le problème que tu as rencontré est différent.


P.-S. : Tu donneras le bonjour à Adrien au travail :-)

--
Julien ÉLIE

« Il ne faut jamais gifler un sourd : il perd la moitié du plaisir.
Il sent la gifle mais il ne l'entend pas. » (Georges Courteline)

Bonsoir Xavier,

>> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4
>
> Seul truc bizarre: sur de très gros spool, j'ai plein d'articles rejetés qui s'accumulent, pour une raison inconnue.

Il n'y a pas de message explicite mentionné à côté du rejet ?

Cela me fait d'ailleurs penser qu'en plus du

ctlinnd param c 0

il faudrait aussi préciser

ctlinnd perl n
ctlinnd python n

car sinon, il va y avoir plein de rejets pour cause d'EMP.

Mais je présume que le problème que tu as rencontré est différent.


P.-S. : Tu donneras le bonjour à Adrien au travail :-)

--
Julien ÉLIE

« Il ne faut jamais gifler un sourd : il perd la moitié du plaisir.
Il sent la gifle mais il ne l'entend pas. » (Georges Courteline)

Julien ÉLIE a écrit :
> Mais je présume que le problème que tu as rencontré est différent.

Oui, car j'imagine que les messages n'auraient pas été stockés. Faudra
que je jette un oeil sur le phénomène..

> P.-S. : Tu donneras le bonjour à Adrien au travail :-)

Arf :p

Julien ÉLIE a écrit :
> Mais je présume que le problème que tu as rencontré est différent.

Oui, car j'imagine que les messages n'auraient pas été stockés. Faudra
que je jette un oeil sur le phénomène..

> P.-S. : Tu donneras le bonjour à Adrien au travail :-)

Arf :p

Julien ÉLIE wrote:

> Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
> la suite et il arrive qu'on ne s'en sorte pas, même à coup de makehistory.
> La solution la plus propre et avec une plus faible interruption de service
> est détaillée ici :
>
> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4
>
> Tu mets le serveur B en esclave du A et transfères l'intégralité du spool.
> Pendant le temps du transfert, ton serveur A reçoit toujours les articles
> de l'extérieur (et les retransmet au B).
>
> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Petite question : on peut garder le même path sur les deux serveurs ?
C'est pas super clair pour moi...

J'ai déménagé mon trad spool à la main et ça a bien marché ceci dit,
mais on m'a souflé que c'est MAL en plus d'être très long en effet.

Julien ÉLIE wrote:

> Bof pour le transfert de spool compressé. Ça peut poser des problèmes par
> la suite et il arrive qu'on ne s'en sorte pas, même à coup de makehistory.
> La solution la plus propre et avec une plus faible interruption de service
> est détaillée ici :
>
> http://www.eyrie.org/~eagle/faqs/inn.html#S6.4
>
> Tu mets le serveur B en esclave du A et transfères l'intégralité du spool.
> Pendant le temps du transfert, ton serveur A reçoit toujours les articles
> de l'extérieur (et les retransmet au B).
>
> Une fois que tout est bon, tu coupes le A et mets le B en maître. Modifie
> les DNS et signale à tes pairs le changement d'IP.

Petite question : on peut garder le même path sur les deux serveurs ?
C'est pas super clair pour moi...

J'ai déménagé mon trad spool à la main et ça a bien marché ceci dit,
mais on m'a souflé que c'est MAL en plus d'être très long en effet.

Bonsoir Patrick,

> Petite question : on peut garder le même path sur les deux serveurs ?
> C'est pas super clair pour moi...

Je ne vois pas d'inconvénient à ce que tu gardes le même path.
Il sert surtout à newsfeeds pour ne pas proposer un article à un pair
quand il est manifeste qu'il le possède déjà (car son path est dans
l'en-tête Path: de l'article en question).


news.serveur.fr/path1,path2:...suite-de-ta-ligne-dans-newsfeeds

Si Path: contient "news.serveur.fr", "path1" ou "path2", alors l'article
n'est pas envoyé à ce pair.


> J'ai déménagé mon trad spool à la main et ça a bien marché ceci dit,
> mais on m'a souflé que c'est MAL en plus d'être très long en effet.



--
Julien ÉLIE

« La raison du plus fou est toujours la meilleure. » (Raymond Devos)

Bonsoir Patrick,

> Petite question : on peut garder le même path sur les deux serveurs ?
> C'est pas super clair pour moi...

Je ne vois pas d'inconvénient à ce que tu gardes le même path.
Il sert surtout à newsfeeds pour ne pas proposer un article à un pair
quand il est manifeste qu'il le possède déjà (car son path est dans
l'en-tête Path: de l'article en question).


news.serveur.fr/path1,path2:...suite-de-ta-ligne-dans-newsfeeds

Si Path: contient "news.serveur.fr", "path1" ou "path2", alors l'article
n'est pas envoyé à ce pair.


> J'ai déménagé mon trad spool à la main et ça a bien marché ceci dit,
> mais on m'a souflé que c'est MAL en plus d'être très long en effet.



--
Julien ÉLIE

« La raison du plus fou est toujours la meilleure. » (Raymond Devos)

Julien ÉLIE wrote:

> Bonsoir Patrick,

Bonsoir,

>> Petite question : on peut garder le même path sur les deux serveurs ?
>> C'est pas super clair pour moi...
>
> Je ne vois pas d'inconvénient à ce que tu gardes le même path.
> Il sert surtout à newsfeeds pour ne pas proposer un article à un pair
> quand il est manifeste qu'il le possède déjà (car son path est dans
> l'en-tête Path: de l'article en question).
>
>
> news.serveur.fr/path1,path2:...suite-de-ta-ligne-dans-newsfeeds
>
> Si Path: contient "news.serveur.fr", "path1" ou "path2", alors l'article
> n'est pas envoyé à ce pair.

Je pensais que INN en tenait compte en entrée. Par exemple si je reçois
un article avec mon path dedans, on peut supposer qu'il y a une boucle
quelque part. J'essaierais ça lors du prochain déménagement.

Tant que j'y suis, un autre truc un peu pénible lorsqu'on déménage de
serveur c'est le changement d'IP. Il faut que chaque peer change sa
configuration, je me demande s'il n'y aurait pas de solution à ça.

Merci.

Julien ÉLIE wrote:

> Bonsoir Patrick,

Bonsoir,

>> Petite question : on peut garder le même path sur les deux serveurs ?
>> C'est pas super clair pour moi...
>
> Je ne vois pas d'inconvénient à ce que tu gardes le même path.
> Il sert surtout à newsfeeds pour ne pas proposer un article à un pair
> quand il est manifeste qu'il le possède déjà (car son path est dans
> l'en-tête Path: de l'article en question).
>
>
> news.serveur.fr/path1,path2:...suite-de-ta-ligne-dans-newsfeeds
>
> Si Path: contient "news.serveur.fr", "path1" ou "path2", alors l'article
> n'est pas envoyé à ce pair.

Je pensais que INN en tenait compte en entrée. Par exemple si je reçois
un article avec mon path dedans, on peut supposer qu'il y a une boucle
quelque part. J'essaierais ça lors du prochain déménagement.

Tant que j'y suis, un autre truc un peu pénible lorsqu'on déménage de
serveur c'est le changement d'IP. Il faut que chaque peer change sa
configuration, je me demande s'il n'y aurait pas de solution à ça.

Merci.

Bonsoir,

> Je pensais que INN en tenait compte en entrée. Par exemple si je reçois
> un article avec mon path dedans, on peut supposer qu'il y a une boucle
> quelque part. J'essaierais ça lors du prochain déménagement.

Non il n'en tient pas compte.
Je viens de tester les deux choses suivantes :

**
Serveur 1 avec pathhost:host
Serveur 2 avec pathhost:host

Envoi d'un message 1 -> 2.
Sur 1 : Path: host!not-for-mail
Sur 2 : Path: host!not-for-mail


**
Serveur 1 avec pathhost:host, pathalias:alias et pathcluster:cluster
Serveur 2 avec pathhost:host

Envoi d'un message 1 -> 2.
Sur 1 : Path: cluster!host!alias!not-for-mail
Sur 2 : Path: host!cluster!host!alias!not-for-mail



Il n'y a pas de filtrage fait par INN sur le pathhost. En revanche,
comme tu peux le voir, il n'est pas doublé si le dernier "hop" est
exactement ton pathhost.

En ce qui concerne la boucle, c'est de toute façon vite vu avec le
Message-ID de l'article en question. Si INN l'a, il te le dira
aussitôt, avant même de connaître l'en-tête Path: de ton article.



> Tant que j'y suis, un autre truc un peu pénible lorsqu'on déménage de
> serveur c'est le changement d'IP. Il faut que chaque peer change sa
> configuration, je me demande s'il n'y aurait pas de solution à ça.

Les DNS servent à cela...
Je les flushe pour ma part toutes les nuits donc si un de mes pairs
change d'adresse IP, la communication reprendra automatiquement
le lendemain.

Après, s'il y a en plus des iptables ou des paramètres réseau
plus avancés directement dans les routeurs, avec des IP, cela
demande une intervention manuelle de la part de tes pairs.

--0
Julien ÉLIE

« La raison du plus fou est toujours la meilleure. » (Raymond Devos)

Bonsoir,

> Je pensais que INN en tenait compte en entrée. Par exemple si je reçois
> un article avec mon path dedans, on peut supposer qu'il y a une boucle
> quelque part. J'essaierais ça lors du prochain déménagement.

Non il n'en tient pas compte.
Je viens de tester les deux choses suivantes :

**
Serveur 1 avec pathhost:host
Serveur 2 avec pathhost:host

Envoi d'un message 1 -> 2.
Sur 1 : Path: host!not-for-mail
Sur 2 : Path: host!not-for-mail


**
Serveur 1 avec pathhost:host, pathalias:alias et pathcluster:cluster
Serveur 2 avec pathhost:host

Envoi d'un message 1 -> 2.
Sur 1 : Path: cluster!host!alias!not-for-mail
Sur 2 : Path: host!cluster!host!alias!not-for-mail



Il n'y a pas de filtrage fait par INN sur le pathhost. En revanche,
comme tu peux le voir, il n'est pas doublé si le dernier "hop" est
exactement ton pathhost.

En ce qui concerne la boucle, c'est de toute façon vite vu avec le
Message-ID de l'article en question. Si INN l'a, il te le dira
aussitôt, avant même de connaître l'en-tête Path: de ton article.



> Tant que j'y suis, un autre truc un peu pénible lorsqu'on déménage de
> serveur c'est le changement d'IP. Il faut que chaque peer change sa
> configuration, je me demande s'il n'y aurait pas de solution à ça.

Les DNS servent à cela...
Je les flushe pour ma part toutes les nuits donc si un de mes pairs
change d'adresse IP, la communication reprendra automatiquement
le lendemain.

Après, s'il y a en plus des iptables ou des paramètres réseau
plus avancés directement dans les routeurs, avec des IP, cela
demande une intervention manuelle de la part de tes pairs.

--0
Julien ÉLIE

« La raison du plus fou est toujours la meilleure. » (Raymond Devos)