Vous n'êtes pas identifié(e).
La mise à jour s'effectue correctement.
Par contre avec le script :
Et la mise en place du service avec le runlevel 2 :
Au redémarrage du système, je n'ai pas de mise à jour de l'IP sur le site noip
Par contre, le processus a bien été lancé, car si j'effectue la commande :
Donc ma question : qui empêche le script de fonctionner lors de l'init du système (réseau non opérationnel?, autre?)
Dernière modification par galactic (27-03-2018 15:01:17)
Hors ligne
Dans /etc/rc.local on exécute la commande avec un délai :
Le script /etc/rc.local est exécuté par /etc/init.d/rc.local :
Cependant toujours pas compris pourquoi la commande qui doit faire un accès réseau ne s'éxécute pas correctement quand on la met dans un script rc2.d
Dernière modification par galactic (27-03-2018 14:20:49)
Hors ligne
Problème résolu
Pas vraiment. C'est un contournement, pas une résolution.
Cependant toujours pas compris pourquoi la commande qui doit faire un accès réseau ne s'éxécute pas correctement quand on la met dans un script rc2.d
C'est le déplacement dans rc.local ou l'ajout de la temporisation qui a contourné le problème ?
Il vaut mieux montrer que raconter.
Hors ligne
C'est le déplacement dans rc.local ou l'ajout de la temporisation qui a contourné le problème ?
Vraisemblablement, c'est la temporisation. Je vais faire quelques tests pour cerner la chose plus précisément; j'aimerais revenir à un fonctionnement standard en utilisant rc2.d.
Dernière modification par galactic (28-03-2018 15:29:09)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Après quelques essais sans rc.local dont report du delai (15s) dans le scipt /etc/init.d/noip le fonctionnement est correct.
Donc il doit y avoir un service qui n'est pas disponible lors de l'éxécution du script au démarrage; alors à quoi sert # Required-Start: $all
Dernière modification par galactic (28-03-2018 16:31:00)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Le problème apparait lors du passage à une IP statique. Le DHCP étant désactivé au niveau de la box.
Avec cette config, malgré l'indication du gateway (qui devrait suffire pour relayer la requête) la résolution de nom est longue (quand elle se fait - et à l'init elle ne se fait pas) : la box ne semble pas traiter correctement une demande d'un client DNS qui provient d'un équipement situé sur le même réseau. Dans ce cas la box ne connait pas l'adresse MAC de l'équipement.
Au final, le problème semble résolu en enlevant le délai dans le script /etc/init.d/noip et en ajoutant la box comme serveur DNS :
Merci pour les éclaircissements apportés et les idées émises pour la résolution du problème.
Dernière modification par galactic (31-03-2018 20:46:19)
Hors ligne
une attribution d'adresse statique par dhcp
Ceci ne veut rien dire, c'est un oxymore. Le D de DHCP signifie "dynamique". Par définition une configuration par DHCP n'est pas statique et vice versa.
Les options "address", "netmask", "gateway" ne sont prises en compte que par la méthode "static" et ignorées par la méthode "dhcp". Par contre l'option dns-nameservers est prise en compte quelle que soit la méthode (si le paquet resolvconf est installé), et peut entrer en conflit avec l'option domain-name-servers reçues du serveur DHCP avec la méthode "dhcp".
A quoi correspond l'adresse de DNS 172.16.0.23 qui est hors du sous-réseau configuré sur l'interface ?
la box ne semble pas traiter correctement une demande d'un client DNS qui provient d'un équipement situé sur le même réseau. Dans ce cas la box ne connait pas l'adresse MAC de l'équipement.
Qu'est-ce qui te fait dire cela ? La suite semble prouver le contraire, car il n'y a aucun lien entre résolution DNS et adresse MAC.
J'ai plutôt l'impression que l'adresse de DNS 172.16.0.23 n'est pas valide et que la bonne solution aurait été de la supprimer.
Il vaut mieux montrer que raconter.
Hors ligne