Projet

Général

Profil

Tâche #17579

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

Redémarrage des tunnels si bastion est trop lent

Ajouté par Karim Ayari il y a plus de 7 ans. Mis à jour il y a plus de 7 ans.

Statut:
Fermé
Priorité:
Normal
Début:
17/10/2016
Echéance:
% réalisé:

100%

Temps estimé:
10.00 h
Temps passé:
Restant à faire (heures):
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 ?

Révisions associées

Révision c4e9d7c3 (diff)
Ajouté par Fabrice Barconnière il y a plus de 7 ans

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

ref #17579 @1h

Historique

#1 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

<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 Mis à jour par Emmanuel GARETTE il y a plus de 7 ans

  • Tracker changé de Demande à Tâche
  • Sujet changé de Message d'erreur xtables lock à Redémarrage des tunnels si bastion est trop lent
  • Temps estimé mis à 10.00 h
  • Tâche parente mis à #17455
  • Restant à faire (heures) mis à 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 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Scrum Master il y a plus de 7 ans

  • Statut changé de Nouveau à En cours

#8 Mis à jour par Scrum Master il y a plus de 7 ans

  • Assigné à mis à Fabrice Barconnière

#9 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • % réalisé changé de 0 à 100
  • Restant à faire (heures) changé de 10.0 à 1.0

#10 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Statut changé de En cours à Résolu

#11 Mis à jour par Karim Ayari il y a plus de 7 ans

je teste cela rapidement, merci.

#12 Mis à jour par Karim Ayari il y a plus de 7 ans

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

#13 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Restant à faire (heures) changé de 1.0 à 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 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Statut changé de Résolu à Fermé

Formats disponibles : Atom PDF