Tâche #13977
Scénario #11962: Les inclusions statiques Era doivent être exécuté à chaque lancement de bastion
Création d'un cache des inclusions statiques + lancement du cache au démarrage de bastion
Description
Gwenael Remond a écrit :
[...] Il faudrait :
1) séparer les inclusions statiques du lance.firewall et les mettre dans un fichier (ailleurs ou bien dans
/sbin/
) il faut générer un fichier avec le contenu des inclusions statiques
2) exécuter ce fichier a chaque reload (service bastion restart
)
Associated revisions
les inclusions statiques doivent être réexécuté à chaque démarrage de bastion (ref #13977 @2h)
les inclusions statiques doivent être réexécuté à chaque démarrage de bastion (ref #13977)
bastion : cache inclusions statiques restauré après iptables-restore
bastion/bastion : on restaure le cache des inclusions statiques après la
restauration globale du modèle pour éviter que ces règles soient
flushées.
ref #13977 @1h
bastion : le test du code retour concerne iptables-restore
bastion/bastion : la variable RETVAL était induement affectée du code retour du
test de présence du fichier des inclusions statiques. Il fallait lui
affecter le code retour de la commande iptables-restore
ref #13977 @15m
History
#1 Updated by Joël Cuissinat over 7 years ago
- Description updated (diff)
- Estimated time changed from 2.00 h to 4.00 h
- Remaining (hours) changed from 2.0 to 4.0
#2 Updated by Scrum Master over 7 years ago
- Status changed from Nouveau to En cours
#3 Updated by Scrum Master over 7 years ago
- Description updated (diff)
- Assigned To set to Emmanuel GARETTE
#4 Updated by Emmanuel GARETTE over 7 years ago
- % Done changed from 0 to 100
- Remaining (hours) changed from 4.0 to 0.25
#5 Updated by Scrum Master over 7 years ago
- Status changed from En cours to Résolu
#6 Updated by Fabrice Barconnière over 7 years ago
- Status changed from Résolu to En cours
- % Done changed from 100 to 80
Le fichier cache est généré et est bien exécuté dans /etc/init.d/bastion restart.
Les inclusions statiques sont mises en place temporairement puis elles sautent avant la fin de l'exécution du restart.
En fait la commande iptables-restore fait un flush des règles. L'option -n permet d'éviter le flush mais on se retrouve avec des règles en double si fait un restart car . /usr/share/eole/firewall.start met déjà en place des règles. Il faudrait faire en flush après . /usr/share/eole/firewall.start dans le restart (et peut-être ailleurs, bref à étudier).
#7 Updated by Fabrice Barconnière over 7 years ago
- Remaining (hours) changed from 0.25 to 1.0
#8 Updated by Fabrice Barconnière over 7 years ago
- % Done changed from 80 to 100
- Remaining (hours) changed from 1.0 to 0.25
#9 Updated by Scrum Master over 7 years ago
- Status changed from En cours to Résolu
#10 Updated by Fabrice Barconnière over 7 years ago
- Status changed from Résolu to En cours
#11 Updated by Fabrice Barconnière over 7 years ago
- % Done changed from 100 to 90
inclusion déplacée au mauvais endroit. On ne s'en rend pas compte sur un serveur avec ERA.
Sur un serveur sans ERA, il n'y a pas d'inclusion statique donc pas de fichier. Le code retour juste après le test de présence du fichier était pour iptables-restore.
#12 Updated by Fabrice Barconnière over 7 years ago
- % Done changed from 90 to 100
#13 Updated by Scrum Master over 7 years ago
- Status changed from En cours to Résolu
#14 Updated by Joël Cuissinat over 7 years ago
- Status changed from Résolu to Fermé
- Remaining (hours) changed from 0.25 to 0.0
OK