7

Déc

by Maniack Crudelis

Lorsqu’on se lance dans l’aventure du home server, on se retrouve bien vite confronté au problème de l’IP changeant régulièrement. Le première réponse à ça fut bien vite le service Dyndns.

Avec  l’arrivée d’un nom de domaine, je voulais quelque chose de plus « propre », me voila donc parti pour le service DynHost de chez OVH.

La documentation concernant DynHost sur le site OVH est assez incomplète, mais on y trouve tout de même un script intéressant, la partie concernant Ipcheck.py.

Dans cette version du script, fourni par OVH, la ligne Updatehost à déjà été modifiée.
Mais le problème se situe dans le script sh dynhost. En effet, il va chercher l’adresse locale de la machine et non l’adresse publique.

IP=`/sbin/ifconfig $IFACE | fgrep "inet ad" | cut -f2 -d":" | cut -f1 -d" "`

En ce qui me concerne, je me trouve derrière une neufbox, la solution la plus répandue est d’interroger un site du style checkip.dyndns.org pour en extraire l’adresse IP publique.
Afin de ne pas faire appel inutilement à un serveur distant pour une info que j’ai déjà chez moi, j’ai choisi d’interroger directement la neufbox à ce sujet.

IP=`wget http://192.168.1.1/0_0 && cat 0_0 | grep ".[0-9]{1,3}" | cut -d '<' -f 2 | cut -d ' ' -f 2 && rm -f 0_0`

Pour expliquer un peu cette commande, on télécharge la page d’accueil de la neufbox, qui affiche notre adresse IP publique.

wget http://192.168.1.1/0_0

On recherche la ligne concernant l’affichage de l’IP.

grep ".[0-9]{1,3}"

On utilise ensuite la commande cut pour couper la chaine de caractère et garder uniquement l’adresse IP.

cut -d '<' -f 2 | cut -d ' ' -f 2

Cette méthode devrait pouvoir être appliquée à toutes les box du marché.

Le script ainsi modifié va cherché l’adresse IP publique et met à jour votre champ dynhost avec cette adresse, seulement si elle a changé.

Le second problème que m’a posé ce script est qu’il utilise, par défaut, des chemins relatifs. Après avoir placé le script dans un dossier, histoire de faire les choses proprement, le script n’exécutait plus ipcheck.py, car il ne le trouvait tout simplement pas.
Il est donc plus prudent d’indiquer les chemins absolus dans le script.

Le script complet, modifié par mes soins:

#! /bin/sh

# OVH - DynHost
#
# Permet de 
mettre à jour le champ DYNHOST
# pour votre nom de domaine.

# La mise à jour ne se fait que si l adresse IP
# a effectivement changé.
# Fichier de log: dynhost.log

# Mod par Maniack Crudelis

HOST='nom_domaine'
LOGIN='login'
PASSWORD='password'
OPTIONS="-l -v" #-l = log; -v = verbose
LOCALPATH=.../DynHost

# Obtention de l adresse IP actuelle et celle enregistrée lors du dernier changement
	IP=`wget http://192.168.1.1/0_0 && cat 0_0 | grep ".[0-9]{1,3}" | cut -d ' $LOCALPATH/last_dynhost.log
			echo `date` >> $LOCALPATH/last_dynhost.log
			echo Démarrage de DynHost >> $LOCALPATH/last_dynhost.log
			echo -n "Ancienne IP: " >> $LOCALPATH/last_dynhost.log
                	echo $OLDIP >> $LOCALPATH/last_dynhost.log
               		echo -n "Nouvelle IP: " >> $LOCALPATH/last_dynhost.log
              		echo $IP >> $LOCALPATH/last_dynhost.log
			echo "Mise à jour!" >> $LOCALPATH/last_dynhost.log
			echo "Lancement de 
ipcheck.py" >> $LOCALPATH/last_dynhost.log
			cd $LOCALPATH && python ipcheck.py $OPTIONS -a $IP $LOGIN $PASSWORD $HOST >> $LOCALPATH/last_dynhost.log
			cat $LOCALPATH/last_dynhost.log >> $LOCALPATH/dynhost.log
         	else
               		echo IP Identique!
#Pour ne pas surcharger le log, si l ip ne change pas, log de la dernière execution seulement
                echo `date` > $LOCALPATH/last_dynhost.log
                echo Démarrage de DynHost >> ~$LOCALPATH/last_dynhost.log
		echo IP identique, pas de changement. Pas d appel à ipcheck. >> $LOCALPATH/last_dynhost.log
         	fi
         else
		echo ---------------------------------- > $LOCALPATH/last_dynhost.log
		echo `date` >> $LOCALPATH/last_dynhost.log
		echo Démarrage de DynHost >> $LOCALPATH/last_dynhost.log
	 	echo Panique à bord: Aucune IP Disponible!! >> $LOCALPATHt/last_dynhost.log
		cat $LOCALPATH/last_dynhost.log >> $LOCALPATH/dynhost.log
         fi

Le script doit maintenant être exécuté régulièrement, pour cela on ajoute une tâche au crontab.

crontab -e
*/5 * * * * 'chemin de dynhost'/DynHost/dynhost > /dev/null

Le script sera ainsi exécuté toutes les 5 minutes, en cas de changement de l’adresse publique du serveur, le champ dns sera immédiatement mis à jour.

Comments

  1. Maniack Crudelis on 02.26.2011

    Arg désolé pour le commentaire qui avait été posté! Des soucis avec le wordpress du site qui m’ont obligé à jongler avec les bases de données, et une fausse manip plus tard, un commentaire est passé à la trappe.

    Je vais quand même y répondre, la question était de savoir si Dynhost renseignait un champ A ou un CNAME. D’après OVH, le champ DynHOST est un champ A avec une IP dynamique.

    Dans la pratique, c’est un champ A pour lequel on donne une IP, mais nécessitant un couple login/mdp pour être mis à jour depuis un client distant.

    Ensuite c’est surtout ipcheck qui fais le travail, je sais notamment qu’il peut renseigner un champ MX, il faut fouiller l’aide du script et le code pour en savoir plus.

  2. Etienne on 02.27.2011

    Super,
    merci pour la réponse !

    Oui y’avait eu un petit souci quand j’ai poste le commentaire, et quand j’ai voulu le reposter WP me disait que j’avais déjà poste ce même commentaire…

    Enfin bref, merci, je peux donc transférer mon domaine chez Gandi.

    Je modifierais ton script pour y ajouter l’envoi d’un mail au moment de la mise a jour, et je te le reposterais.

  3. Yann on 05.25.2011

    Bonjour!

    Je me heurte actuellement à des problèmes de DynHost avec OVH et j’essaie justement d’utiliser ce script.
    Voici l’erreur retournée par le script dans dyndns.log:

    ipcheck.py: opt_address set to xx.xx.xx.xx
    ipcheck.py: opt_username = ruincorp.com-rsi
    ipcheck.py: opt_password = *******
    ipcheck.py: opt_hostnames = rsi.ruincorp.com
    ipcheck.py: manually setting localip
    ipcheck.py: Good, no ipcheck.err file.
    ipcheck.py: Good, no ipcheck.wait file.
    ipcheck.py: Checking hosts in file vs command
    line.
    ipcheck.py: rsi.ruincorp.com needs updating
    ipcheck.py: Prefix = /nic/update?system=dyndns&hostname=
    ipcheck.py: Hosts = rsi.ruincorp.com
    ipcheck.py: Suffix = &myip=xx.xx.xx.xx&wildcard=OFF&backmx=NO
    ipcheck.py: http code = 500
    ipcheck.py: http msg = Internal Server Error
    ipcheck.py: ipcheck.html file created
    ipcheck.py: Dyndns 999 result. Dyndns emergency shutdown.
    ipcheck.py: ipcheck.err file created.

    Savez-vous d’où ça peut venir??

    Merci d’avance 🙂

    Yann

  4. Maniack Crudelis on 05.26.2011

    L’erreur 500 provient en principe du serveur OVH, non du script.
    A la ligne 43 du script ipcheck.py, vérifie le nom du serveur, chez moi ça donne ça:
    Dyndnshost = « www.ovh.com »

    Pour forcer une mise à jour par le script, modifie le fichier ipcheck.dat et change l’IP, cela le forcera à mettre à jour sur le serveur OVH.
    Pour ma part, après un essai, le
    serveur OVH répond correctement.
    A suivre…

  5. yann on 04.22.2012

    Merci pour l’info ! Ca marche pour moi également 😉

  6. camel on 06.03.2012

    Ca n’a pas marché correctement chez moi :-(. J’ai du modifier la regexp pour recuperer l’ip.

    « : [[:digit:]]{1,3}.[[:digit:]]{1,3}.[[:digit:]]{1,3} »

    Aussi, j’utilise la commande egrep.

    IP=`wget http://192.168.1.1/0_0 && cat 0_0 | egrep « : [[:digit:]]{1,3}.[[:digit:]]{1,3}.[[:digit:]]{1,3} » | cut -d ‘<' -f 2 | cut -d ' ' -f 2 && rm -f 0_0`

  7. Faizan on 01.08.2013

    solo> Pour ce qui est de la gestion de plusieurs nom de domaines sur un seul hébergement, en effet seuls les hébergements « évolués » d’OVH le permettent mais il en est de même chez Celeonet. Quant aux sous-domaines, j’ai eu besoin d’en créer récemment. Cela se fait en quelques clics et ils sont disponibles sous quelques minutes. A vrai dire j’ai été surpris de la facilité avec laquelle je les ai mis en place. Il faut préciser qu’il s’agissait de sous-domaines pointant vers des virtuals hosts distant et non
    vers des répertoires de l’hébergements. Cela doit contribuer à simplifier la chose.

Leave a Reply