Project

General

Profile

Tâche #17579

Distribution EOLE - Scénario #17455: Traitement express MEN (42-44)

Redémarrage des tunnels si bastion est trop lent

Added by Karim Ayari over 6 years ago. Updated over 6 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Fabrice Barconnière
Target version:
Distribution EOLE - sprint 2016 42-44 - Équipe MENSR
Start date:
10/17/2016
Due date:
% Done:

100%

Estimated time:
10.00 h
Spent time:
1.10 h
Remaining (hours):
0.0

Description

Nous avons un gros problème qui semble survenir de manière assez aléatoire : le matin sur nos Amon des règles de pare-feu sont manquantes
aprés avoir remonté toute le cheminement des différents scripts appelés je me suis aperçu que toutes les règles sont bien présentes dans le scripts lance.firewall
mais c'est ce dernier qui ne parvient pas à générer certaines règles (je l'ai pris en flagrant délit) car il rencontre ce message d'erreur :

+ /sbin/iptables -t filter -N wco-mg2
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

j'ai déposé ici pour 1 semaine la trace d'exécution de lance.firewall
https://cadol.es/paste/?ddf1e8fda5df0846#glAuB2EEFucMMKneKQBKbrZd9ulMdeprm+VBu4v9b7Y=

le problème ne se pose pas tout le temps mais seulement sur nos Amon avec modèle vlan (~ 12 et ~ 4000 règles).

une idée sur ce qui pourrait causer cette erreur ?

Associated revisions

Revision c4e9d7c3 (diff)
Added by Fabrice Barconnière over 6 years ago

Ne pas relancer rvp sur Amon si bastion est arrêté

ref #17579 @1h

History

#1 Updated by Karim Ayari over 6 years ago

rebelote ce matin :( il va falloir m'aider sur ce coup :(

je lance /sbin/lance.firewall à la main une 1ère fois : même message
je lance /sbin/lance.firewall une seconde fois à la main : tout est ok.

EOLE est une distribution libre dérivée de la distribution Ubuntu.
Veuillez consulter les licences de chacun des produits dans
root@bcharvet:~# iptables-save |grep "FORWARD \-i" |grep -v mac |wc -l
325
root@bcharvet:~# /sbin/lance.firewall 
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
root@bcharvet:~# /sbin/lance.firewall 
root@bcharvet:~# iptables-save |grep "FORWARD \-i" |grep -v mac |wc -l
361
root@bcharvet:~#

#2 Updated by Karim Ayari over 6 years ago

je pense avoir trouvé la source du problème qui expliquerait que ce soit aussi aléatoire
en regardant les logs de l'agent zéphir je me suis aperçu que l'agent rvp relance les tunnels systématiquement aux alentours de l'heure du logrotate

2016-10-20T06:28:35.515835+02:00 bcharvet.0420049a.local zephiragents: [-] agent rvp : service rvp relancé

et sur les serveurs qui m'ont renvoyé le message d'erreur au moment d'un service bastion restart fait manuellement, un tunnel était en erreur :

2016-10-21T07:50:36.187316+02:00 plainedelain.0011194t.local zephiragents: [-] tunnel 10.1.60.0/24 vers 192.168.0.0/16 -- 192.168.10.43 injoignable en erreur
2016-10-21T07:50:45.268920+02:00 plainedelain.0011194t.local zephiragents: [-] agent rvp : service rvp relancé
2016-10-21T07:53:36.207317+02:00 plainedelain.0011194t.local zephiragents: [-] tunnel 10.1.60.0/24 vers 192.168.0.0/16 -- 192.168.10.43 injoignable en erreur
2016-10-21T07:53:45.289366+02:00 plainedelain.0011194t.local zephiragents: [-] agent rvp : service rvp relancé
2016-10-21T07:56:36.211356+02:00 plainedelain.0011194t.local zephiragents: [-] tunnel 10.1.60.0/24 vers 192.168.0.0/16 -- 192.168.10.43 injoignable en erreur
2016-10-21T07:56:44.689142+02:00 plainedelain.0011194t.local zephiragents: [-] agent rvp : service rvp relancé
2016-10-21T07:59:36.236008+02:00 plainedelain.0011194t.local zephiragents: [-] tunnel 10.1.60.0/24 vers 192.168.0.0/16 -- 192.168.10.43 injoignable en erreur
2016-10-21T07:59:44.827971+02:00 plainedelain.0011194t.local zephiragents: [-] agent rvp : erreur lors de la relance du service rvp

#3 Updated by Karim Ayari over 6 years ago

<gnunux> karim[ac-lyon], rah purée oui possible
<gnunux> le tunnel remet des règles iptables !
<karim[ac-lyon]> c'est cadeau
<gnunux> et les règles iptables bloque l'accès au tunnel
<karim[ac-lyon]> en fait j'ai recoupé avec le log iptables
<gnunux> bien vu !
<gnunux> l'agent devrait regarder s'il y a un lock ...

#4 Updated by Emmanuel GARETTE over 6 years ago

  • Tracker changed from Demande to Tâche
  • Subject changed from Message d'erreur xtables lock to Redémarrage des tunnels si bastion est trop lent
  • Estimated time set to 10.00 h
  • Parent task set to #17455
  • Remaining (hours) set to 10.0

Si Bastion est long a redémarrer, les tunnels sont redémarrés (puisque plus accessible).

Comme le redémarrage des tunnels provoquent, sauf erreur de ma part, la mise en place de règle iptables, des erreurs apparaissent.

A mon avis il faudrait faire un lock lors de la mise en place des règles iptables et supprimer le lock quand l'action est finie.
L'agent Zéphir ne devrait vérifier l'état des tunnnels lorsque les locks sont placés.

#5 Updated by Karim Ayari over 6 years ago

en attendant on peut éviter ce problème en ajoutant l'option -w lors de la génération des régles iptables dans le script iptwriter.py
la régle attend de pouvoir être ajoutée et du coup ne termine pas sur une erreur
je fournirai un diff dans la demande.

#6 Updated by Karim Ayari over 6 years ago

j'ai ajouté l'option -w sur les scripts suivants :

/usr/share/era/backend/iptwriter.py
/usr/share/era/backend/horaires_firewall #certains utilisent les restrictions horaires dans l'EAD

et dans les inclusions statiques de notre modèle.

reste peut-être à modifier le ou les scripts qui générent les script end/middle/static_rules.sh

#7 Updated by Scrum Master over 6 years ago

  • Status changed from Nouveau to En cours

#8 Updated by Scrum Master over 6 years ago

  • Assigned To set to Fabrice Barconnière

#9 Updated by Fabrice Barconnière over 6 years ago

  • % Done changed from 0 to 100
  • Remaining (hours) changed from 10.0 to 1.0

#10 Updated by Fabrice Barconnière over 6 years ago

  • Status changed from En cours to Résolu

#11 Updated by Karim Ayari over 6 years ago

je teste cela rapidement, merci.

#12 Updated by Karim Ayari over 6 years ago

j'ai modifié un serveur j'attends demain pour voir ce que cela donne.

#13 Updated by Fabrice Barconnière over 6 years ago

  • Remaining (hours) changed from 1.0 to 0.0
karim[ac-lyon]> merciiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
<barco> salut karim[ac-lyon] : de rien. Tu veux parler des règles iptables ?
<karim[ac-lyon]> ouaaai pour le correctif

#14 Updated by Fabrice Barconnière over 6 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF