Ticket #661 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Zone jamais mise à jour

Reported by: pierre-gilles Assigned to: anonymous
Priority: high Milestone: alternc-0.9.6
Component: BIND Version: alternc-0.9.5
Severity: block Keywords:
Cc:

Description

Si on crée un domaine genre alternc.org: que l'on veut rediriger http://alternc.org vers une IP l'interface prends les changements en compte mais dans le fichier de la zone de bind d'alternc l'enregistrement @ n'est pas modifié.

J'imagine que /usr/lib/alternc/update_domains.sh est en cause ...

Change History

05/12/06 15:15:43 changed by anonymous

vu hier aussi =)

05/12/06 19:44:07 changed by pierre-gilles

le bug est ligne 238 de update_domain.sh .... J'ai un fixe qui marche sur un de mes serveurs mais comme je ne comprends les implications de :

fqdn="$domain"

je n'ose pas trop le produire... Le test me semble superfetoire...

05/18/06 10:34:10 changed by anonymous

Bonjour,

montre le fixe pierre-gilles

++

06/11/06 12:36:16 changed by valentin

la condition de ce bug que j'ai pu reperer;

si un domaine est crée et configuré sans 'héberger les dns sur le serveur' puis que l'on coche 'héberger les dns' dans un second temps, alors la configuration (A et MX records) n'est pas propagé au fichier de zone

pour que la propagation se fasse il faut modifier ou recréer chaque ligne de la config après avoir coché 'héberger les dns'.

06/11/06 23:43:18 changed by valentin

pas sur que les bug 661, 711, et 517 aient la même cause, mais en tout cas vala une cause identifiée et un proposition de solution;

quand un domaine est crée sans 'héberger les dns', on peux rajouter des sous domaines, rien ne fera l'objet d'un fichier de zone, c'est normal.

par contre, si plus tard on va sur la gestion du domaine et que la seule modif consiste à valider 'héberger les dns', la fonction edit_domain() est bien appellée pour créer l'enregistrement dans la table domaines_standby mais c'est tout.

la zone résultante pour bind est donc vierge de toute déclaration de sous-domaine, comme si le domaine venait tout frais d'un add_domain(), sans tenir compte de ses sous domaines.

pour que ça fonctionne comme attendu, edit_domain() devrait dans ce cas appeller set_sub_domain() pour chaque sous domaine déclaré (quand 'dns' passe de 0 à 1).

une autre solution peut-être plus simplificatrice serait d'abandonner la table sub_domaines_standby et de considerer que toute modification de domaine ou de sous domaine conduit update_domain.sh à réecrire intégralement la zone à partir de la table sql, ce qui permettrait de garantir la synchro. mais ça a peut-être des incidences malheureuses ailleurs.

06/13/06 02:16:44 changed by anarcat

Salut valentin,

Je crois que la solution que tu proposes s'applique plus au bug #517 qu'à celui-ci, que je n'ai d'ailleurs pas encore essayé de reproduire.

Pour ce qui est de ré-écrire complètement les zones, j'aime bien le fait qu'update_domaines fonctionne par substitution. Ça me permet de garder des entrées spéciales (e.g. des CNAME, PTR, etc) dans mes fichiers de zone. Ça serait dommage de changer ce comportement...

Quand au #711, j'ai l'impression que c'est un problème d'upgrade...

06/23/06 06:05:42 changed by anarcat

  • status changed from new to closed.
  • resolution set to fixed.

(In [1672]) change proper ip even if modifying TLD, closes: #661