Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pas étonnant que les logs ne soient pas accessibles :
Cette version date de juillet 2011.
Essaie d'ajouter des règles pour le port 53 en TCP aussi.
L'ajout de règles autorisant le protocole TCP sur le port 53/domain n'a pas d'incidence.
Par ailleurs je doute de la "stabilité" d'iptables :
La distribution est un portage sur architecture ARM, et d'origine iptables n'était pas présent : donc apt-get install.
1) Les règles isolées du contexte du jeu de règle complet ne veulent rien dire.
Je ne préjuge pas à qui je m'adresse : il y en a qui zappent au-delà de 5 lignes de code.
2) Tu es sûr du port ?
smtp/465 : c'est le port utilisé par Free; et celà fonctionne si je n'utilise pas iptables.
3) La première règle est une faille de sécurité béante. Pour les paquets retour le port source ne suffit pas, on doit utiliser l'état de suivi de connexion
J'écris d'abord les règles d'une façon basique, et quand celà fonctionnera, je passerai à une écriture plus élaborée.
J'ai élargi en mettant une plage de ports large, des fois qu'un autre port puisse être impliqué dans l'échange: même problème.
Je ne pense pas que celà soit une question de port, mais je ne vois pas ce qui manque dans ces règles.
Des idées ?
Et un fichier ipaddress qui contient la dernière adresse IP valide :
Et le script d'envoi de mail si l'adresse IP courante est différente de la précédente :
Grace à un script qui s'éxécute toute les heures, je récupère un fichier ou j'ai 2 adresses IP, l'ancienne et la nouvelle, fichier de la forme :
adresses
Dans une commande awk je regarde ces 2 adresses, si différentes je dois envoyer un mail, et dans tous les cas je supprime la première adresse :
Mon problème est de savoir comment procéder : pas de possibilité de commande system et pas de variable de retour avec awk.
Si j'applique les 2 règles sed séparémént avec un fichier intermédiaire, celà fonctionne; mais si j'utilise un pipe j'ai le message :sed: no input files
La commande :
La 1ère commande fait une extraction dans un fichier, alors que la 2ème fait une modification de fichier : donc sans doute une mauvaise utilisation du pipe.
Ensuite je dois comparer l'adresse IP avec une autre adresse contenue dans un fichier ipadresse et faire un traitement si elles sont différentes.
Je m'aperçois que dhclient sature /var/log/syslog : en effet, n'obtenant pas d'adresse IP par un serveur dhcp, il réitère la demande toutes les 20 secondes; donc, tel quel çà ne va pas le faire. Il faut en revenir au fait qu'il faut "killer" le process dhclient.
Donc le petit script pour effectuer la tache :
Et il faut bien le mettre quelque part ce script, normalement on va faire en sorte qu'il soit éxécuté à la fin du process init donc sa place est dans /etc/rc.local
Et en parcourant les lignes commentées et non commentées de rc.local, je tombe sur :
Eurêka et fin des problèmes sur les 2 IP.
La suggestion de raleur (pstree) concernant le process (init) qui lance dhclient aurait du me mettre sur la voie.
une commande plus d' actualité avec systemd
Effectivement c'est la commande service que j'utilise pour manager Tomcat. Mais à force de commuter entre divers Linux, je ne suis pas certain d'employer la bonne commande.
Pour revenir à mon problème, j'ai une solution qui n'est pas très élégante (c'est un détournement de déclaration), mais faute de mieux ...
Dans le fichier /etc/dhcp/dhclient.conf, il suffit de refuser un serveur dhcp donné :
Dans le man de dhclient.conf
reject ip-address;
La déclaration reject oblige le client DHCP à rejeter les offres des serveurs qui utilisent une adresse spécifique en tant qu'identifiant serveur. Ceci peut être utilisé pour éviter d'être configuré par un imposteur ou des serveurs dhcp mal configurés, toutefois ceci ne devrait être utilisé qu'en dernier ressort - il vaut mieux essayer de trouver les mauvais serveurs DHCP et les corriger.
Donc "meaculpa", NetworkManager n'était pas en cause 
)il doit y avoir un processus client DHCP qui tourne
dhclient est lancé par le processus init et il génère le fichier :
Et pour les logs (grep sur dhclient):
(grep sur eth0)
Si j'effectue la commande :
Je n'ai plus que l'IP statique, l'IP dynamique a disparu.
J'ai trouvé cette solution (ou plutôt rustine) sur le net :
ifdown eth0
kill du process dhclient
suppression du fichier /var/lib/dhcp/dhclient.leases
ifup eth0
Et dans ce cas on n'a plus que l'IP statique.
Mais celà ne résout pas mon problème car sur l'équipement il y a un watchdog susceptible d'effectuer un reboot automatique : et dans ce cas je me retrouve avec dhclient démarré et une IP dynamique.
tu utilise un rpi avec raspbian
Perdu
C'est un pcDuino V3B (=Raspberry++) avec Ubuntu et LXDE comme bureau léger.
J'ai vu quelque part un portage personnel de Debian sur ce matériel, mais vu les problèmes potentiels, je préfère en rester à la distribution fournie par le fabricant de la carte.
monter un serveur avec le bureau Gnome c'est pas l'idéal , il est plein de truc pas forcément utile pour un serveur
Tout à fait mais :
- il s'agit d'un système mono-carte (processeur ARM) avec Linux pré-installé
- le bureau, c'est LXDE avec des paquets Gnome comme NetworkManager
- le bureau, je ne l'utilise pas : je fais tout par SSH : installs java/tomcat/applis et configurations.
La suppression de NetworkManager :
Je ne cherche pas à ergoter, je veux que les choses soient claires
Désolé, mais j'avais mis un smiley.
il y a le dhclient.conf dans /etc/dhcp/dhclient.conf
Justement avant de voir vos réponses je suis tombé sur quelque chose qui ressemble à mon problème :
https://askubuntu.com/questions/914700/ … ip-address
Et là après quelques modifs : toujours les 2 adresses IP; puis décommenter une ligne dans dhclient.conf et reboot -> plus aucune IP.
Donc fin du SSH, il me faut remettre le matériel en ordre avec un clavier/souris/écran, et en plus c'est de la connectique particulière.
D'ou nécessité de passer provisoirement en mode Pause.
Là, c'est bon je n'ai plus qu'une seule adresse; mais si je reboot la machine, je me retrouve avec les 2 adresses.
Quel module ?
NetworkManager
Comment ça, "vu" ?
Quand à partir d'une machine connectée au réseau local, je peux accéder en SSH à un équipement du réseau en fournissant une adresse IP, je considère que cet équipement est vu sur le réseau avec l'adresse IP fournie pour la connexion SSH.
Si on veut ergoter sur les mots, il faut postuler à l'Académie Française 
Considérant la configuration de l'équipement en IP statique :
Connecté sur l'équipement, la commande ip addr donne :
On a 2 adresses IP affectées au même équipement (.254 -statique- et .156 -dynamique-).
Et celà quelque soit la valeur managed=true/false affectée dans le fichier /etc/NetworkManager/NetworkManager.conf
De même si on ajoute l'adresse MAC de la machine dans ce fichier :
On a toujours 2 adresses IP affectées à l'équipement.
D'ou la question comment éviter l'affectation d'une IP dynamique?
Et pour le NetworkManager
Sur le réseau local, le serveur est vu avec l'adresse dynamique 192.168.1.156
Si on remplace managed=false par managed=true : ce qui devrait donner la gestion de l'IP à ifupdown
Le réseau local permet l'accès au serveur avec 2 adresses IP 192.168.1.156 (dynamique) et 192.168.1.254 (statique).
Donc malgré la configuration statique, NetworkManager effectue une requête DHCP pour obtenir une IP (dynamique).
Je voudrais savoir comment mettre réellement NetworkManager hors service concernant la gestion de l'adresse IP.
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.
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
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.
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
Le script est éxécuté (j'ai un PID), mais l'action sur le serveur n'est pas effectuée. J'ai eu le même problème (non résolu à ce jour) ily a quelque temps sur un script qui effectuait une mise à l'heure en fin d'init par une requête sur un serveur de temps.
Je ne comprends pas ce qui bloque dans le processus de démarrage. Dois-je mettre le script dans rc.local au lieu de rc2.d.
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?)