Prochaines etapes : montage sur le client d'un volume NFS du serveur (donc installation du serveur ad hoc), puis mise en place d'un bridge entre le serveur et le client pour qu'ils dialoguent enfin a 1GBit, sans passer par le routeur...
A tres bientot sans aucun doute, dans un sujet approprie ! :)
Ne sachant pas ce qu'était le gateway, je l'avais commenté dans /etc/resolv.conf
Rajouter l'adresse de mon routeur a de nouveau permis l'accès à l'extérieur pour mon serveur. apt-get est actuellement en train de faire des mises à jour :)
Cela explique pourquoi je pouvais pinger seulement les machines du réseau local.
Il ne s'est pas révélé nécessaire d'utiliser la commande route.
Un grand merci à tous pour votre patience avec un newbie complet des réseaux !
Ok, ce n'est pas super lisible, mais l'absence d'une ligne "default" dans la table de mon serveur pourrait-elle expliquer pourquoi j'obtiens des "Network unreachable" avec ping, apt-get, etc. ?
Si oui, comment rajouter cette ligne (route add qqchose, j'imagine) ?
Mon réseau est assez simple. Un modem/routeur Linksys qui entretient la connection internet, et auquel sont connectés :
1/ Plusieurs portables, en Wi-Fi, obtenant leur IP par le DHCP du routeur
2/ Un serveur (FTP, Samba et SSH), dans un placard, connecté en Ethernet, pour lequel je souhaite une IP fixe, afin de pouvoir accéder à mes docs en FTP depuis l'extérieur, sans avoir à reconfigurer régulièrement la table de routage du routeur au fur et à mesure que les baux DHCP expirent.
Voilà pour les forces en présence.
Maintenant, je pense que la situation est en réalité assez simple, et le /etc/resolv.conf suivant devrait suffire, au moins en théorie (seules les dernières lignes sont utiles):
Mon erreur aura été de laisser "search" au départ, puis de retirer cette option ET d'insérer l'adresse de mon routeur 192.168.1.1, ce qui a peut-êtrecourt-circuité l'usage des DNS de mon FAI, et rendu l'IP lookup du serveur plus lente lors des requêtes SSH et FTP, car je doute que le routeur fasse serveur DNS. En changeant 192.168.1.1 en 192.168.1.0 j'ai p-e indiqué une adresse inexistante, ce qui a amené le serveur à utiliser le DNS du FAI (?).
Ne conserver que les deux dernières lignes résoud le problème de réactivité (ou les deux du milieu qui, malgré les apparences, sont bien différentes;-] ).
J'ai certainement complexifié un peu la situation au départ (mais bon, je débute et je tatonne), comme bien souvent sous Linux, la configuration est bien plus simple que ce à quoi on est habitué sous d'autres systèmes, une ligne dans un fichier au bon endroit suffit...
Maintenant que mon serveur fait appel à des serveurs DNS valides, il devrait être content.
Je pense avoir résolu le problème de manque de réactivité du serveur, probablemennt dû à la résolution inverse de l'IP cliente. Bravo à Raphael Surcouf et Symoon qui ont bien eu le nez creux, merci aux autres également.
Pour retrouver un password prompt SSH qui ne prend plus 15 secondes avant de pointer son nez, j'ai modifier mon /etc/resolv.conf comme suit :
L'astuce consiste à mettre comme premier nameserver non pas l'IP de mon routeur 192.168.1.1 mais l'adresse qui correspond à la Destination LAN IP de l'interface "LAN & Wireless" de la table de routage du Linksys (Setup>Advanced Routing>Show Routing Table), càd 192.168.1.0
On retrouve alors également un temps d'établissement de la connection FTP réduit, une navigation dans l'arborescence FTP plus fluide et des transferts qui ne mettent plus une plombe à démarrer.
Olivier, merci pour ton astuce :
J'ai aussi configuré le serveur DHCP de mon modem/routeur pour qu'il m'attribue toujours la même IP
C'est une idée, mais malheureusement, plusieurs portables se connectent, car je vis en colloc, et les potes de passage sont également friands de la connection internet...
C'est donc un progrès. Reste néanmoins un problème, de taille:
apt-get ne parvient toujours pas à établir de connection vers les miroirs Debian, pas plus que ping ne peut "pinger".
L'adressage DHCP/statique n'a rien à voir avec le medium filaire ou pas.
Non, en effet, mais c'était juste pour dire que je ne peux pas mettre l'IP de mon portable dans /etc/hosts, sauf à devoir la tenir à jour très régulièrement. Et pour les connexions depuis Internet, le problème reste entier.
Regarde quel serveur DNS te renvoie le serveur DHCP, a priori 192.168.1.1
Euh... volontiers, mais je vois ça comment ?
Voici mon /etc/resolv.conf en l'état (en 2e et 3e DNS, j'ai inséré ceux donnés par mon FAI sur leur courrier papier, dont un qui est différent de ceux, commentés, utilisés par mon routeur)
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Je n'ai donc pas inséré l'adresse de mon portable, puisqu'en DHCP.
En revanche, y aurait-il qqchose à gagner à mettre l'adresse de mon routeur ? Je dois m'absenter, mais je tenterai ce soir.
(Bon, je n'ai pas trouvé comment modifier ma réponse précédente, d'où celle-ci)
Pour le coup, c'est encore un problème de DNS, mais côté serveur cette fois-ci. En effet, celui-ci essaie d'effectuer la résolution inverse de ton ip
Symoon, ton explication pourrait en effet expliquer le temps de latence du serveur, mais :
1/Pourquoi la connection finit-elle par s'établir ? Cela signifie-t-il que le serveur, après avoir tenté d'obtenir le nom du client pour mettre dans ses logs, accepte en définitive la connection (dans ce cas, le log n'a qu'une utilité relative, d'un point de vue sécurité...) ?
2/ Mon portable est connecté sans fil, d'où l'usage du DHCP, alors que mon serveur est en Ethernet. Comment rendre possible la résolution du nom du client (mon portable), sinon en mettant à jour /etc/hosts chaque fois que le bail DHCP du portable change ? En effet, si le serveur DHCP (mon routeur) gère toutes les résolutions de noms, alors cela pourrait expliquer pourquoi la connection est plus réactive quand les deux ordinateurs (serveur et client) sont en DHCP.
Sinon, mes recherches continuent, et je suis en train de lire des trucs sur le paquet resolvconf, qui n'est pas installé sur mon serveur. Est-il nécessaire que je l'installe ?
Je comprends un peu mieux l'importance de resolv.conf maintenant que j'ai passé mon serveur en IP statique. En revanche, je ne saisis pas quel nom de domaine renseigner en face de "search".
J'ai tenté le coup avec les domaines suivants, sans résultat :
domain_not_set.invalid (sans surprise...)
192.168.1.1 (mon routeur)
pipex.net (mon FAI...)
pipex.com (...qui utilise ces deux noms de domaine)
localhost.local
domain.tld (des fois que ça soit aussi simple que ça...)
81.***.***.*** (mon IP fixe extérieure, fournie par mon FAI)
Ce que je ne saisis pas, quand je lis que je dois mettre "mon" domaine, c'est que je n'en possède pas.
Il s'agit d'un simple réseau local, avec une connexion ADSL/IP fixe, et je n'héberge ni ne maintiens aucun site web. Je souhaite juste pouvoir accéder à mes fichiers par FTP en local en donnant le nom de mon serveur, et depuis l'extérieur en tapant l'IP que m'a fourni mon FAI.
Merci de votre aide, j'ai rarement obtenu autant de réponses pertinentes et utiles sur un forum en aussi peu de temps,
En effet, mon /etc/resolv.conf n'est pas configuré. Comme il s'agit d'un serveur de fichiers sans GUI, caché dans un placard sans écran ni clavier, géré uniquement en SSH, j'étais sur le point de dire que cela n'a pas d'importance... sauf qu'apt-get fait la tronche, maintenant, pour se connecter sur ftp.fr.debian.org...
Il semble que les DNS de mon FAI ont été copiés automatiquement. En revanche, apt-get ne se déride pas, quel "search domain" dois-je mettre ?
De plus, cela peut-il réellement expliquer les temps de latence lors d'une connection SSH ou FTP depuis mon ordinateur portable ? En effet, si j'ai bien compris ce qu'est un DNS, il n'est pas utilisé lors de la commande...
ssh 192.168.1.10
...puisque je renseigne directement l'adresse IP locale de mon serveur.
Pourtant, la connection demande de la patience avant de s'établir...
J'ai en effet essayé de redémarrer après avoir débranché les deux nouveaux disques, sans succès (toujours ce prompt single user demandant d'effectuer un fsck à la main, et toujours le pc freezé). Mais il est têtard, je n'ai pas pensé à effectuer cette même opération pour le les deux disques composant le volume de stockage installé dès l'origine (/dev/md2)
Je vais essayé de suite, et commenter les lignes de la fstab concernant /dev/md2 et /dev/md3. Je les monterai à la main tant qu'ils ne m'auront pas clairement signifé qui est qui (non mais des fois!). Jouer à la cachette, ce n'est plus de mon âge.
Ma question concernant les "deux versions" de /dev/fstab visait plutot à essayer de saisir les conséquences de la modification en parallèle des volumes composant un RAID1. Mon système n'a bien entendu qu'une seule /dev/fstab :D
Enfin, merci pour les options de mount, je n'avais pas pris conscience du fait qu'il est possible de court-circuiter les autorisations aussi directement.
[^] # Re: Résolu !
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Prochaines etapes : montage sur le client d'un volume NFS du serveur (donc installation du serveur ad hoc), puis mise en place d'un bridge entre le serveur et le client pour qu'ils dialoguent enfin a 1GBit, sans passer par le routeur...
A tres bientot sans aucun doute, dans un sujet approprie ! :)
[^] # Résolu !
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Ne sachant pas ce qu'était le gateway, je l'avais commenté dans /etc/resolv.conf
Rajouter l'adresse de mon routeur a de nouveau permis l'accès à l'extérieur pour mon serveur. apt-get est actuellement en train de faire des mises à jour :)
Cela explique pourquoi je pouvais pinger seulement les machines du réseau local.
Il ne s'est pas révélé nécessaire d'utiliser la commande route.
Un grand merci à tous pour votre patience avec un newbie complet des réseaux !
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Tout semble-t-il normal ? Je me pose cette question car la même commande depuis mon portable en DHCP retourne :
Ok, ce n'est pas super lisible, mais l'absence d'une ligne "default" dans la table de mon serveur pourrait-elle expliquer pourquoi j'obtiens des "Network unreachable" avec ping, apt-get, etc. ?
Si oui, comment rajouter cette ligne (route add qqchose, j'imagine) ?
Merci,
[^] # Re: On avance, on avance...
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Mon réseau est assez simple. Un modem/routeur Linksys qui entretient la connection internet, et auquel sont connectés :
1/ Plusieurs portables, en Wi-Fi, obtenant leur IP par le DHCP du routeur
2/ Un serveur (FTP, Samba et SSH), dans un placard, connecté en Ethernet, pour lequel je souhaite une IP fixe, afin de pouvoir accéder à mes docs en FTP depuis l'extérieur, sans avoir à reconfigurer régulièrement la table de routage du routeur au fur et à mesure que les baux DHCP expirent.
Voilà pour les forces en présence.
Maintenant, je pense que la situation est en réalité assez simple, et le /etc/resolv.conf suivant devrait suffire, au moins en théorie (seules les dernières lignes sont utiles):
Mon erreur aura été de laisser "search" au départ, puis de retirer cette option ET d'insérer l'adresse de mon routeur 192.168.1.1, ce qui a peut-êtrecourt-circuité l'usage des DNS de mon FAI, et rendu l'IP lookup du serveur plus lente lors des requêtes SSH et FTP, car je doute que le routeur fasse serveur DNS. En changeant 192.168.1.1 en 192.168.1.0 j'ai p-e indiqué une adresse inexistante, ce qui a amené le serveur à utiliser le DNS du FAI (?).
Ne conserver que les deux dernières lignes résoud le problème de réactivité (ou les deux du milieu qui, malgré les apparences, sont bien différentes;-] ).
J'ai certainement complexifié un peu la situation au départ (mais bon, je débute et je tatonne), comme bien souvent sous Linux, la configuration est bien plus simple que ce à quoi on est habitué sous d'autres systèmes, une ligne dans un fichier au bon endroit suffit...
Maintenant que mon serveur fait appel à des serveurs DNS valides, il devrait être content.
Et pourtant...
ping ne ping pas
apt-get update me gratifie du message suivant :
Une idée sur ce que j'ai encore pu faire de travers ?
Merci pour votre aide,
[^] # On avance, on avance...
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Pour retrouver un password prompt SSH qui ne prend plus 15 secondes avant de pointer son nez, j'ai modifier mon /etc/resolv.conf comme suit :
L'astuce consiste à mettre comme premier nameserver non pas l'IP de mon routeur 192.168.1.1 mais l'adresse qui correspond à la Destination LAN IP de l'interface "LAN & Wireless" de la table de routage du Linksys (Setup>Advanced Routing>Show Routing Table), càd 192.168.1.0
On retrouve alors également un temps d'établissement de la connection FTP réduit, une navigation dans l'arborescence FTP plus fluide et des transferts qui ne mettent plus une plombe à démarrer.
Olivier, merci pour ton astuce :C'est une idée, mais malheureusement, plusieurs portables se connectent, car je vis en colloc, et les potes de passage sont également friands de la connection internet...
C'est donc un progrès. Reste néanmoins un problème, de taille:
apt-get ne parvient toujours pas à établir de connection vers les miroirs Debian, pas plus que ping ne peut "pinger".
Encore du boulot donc... mais pas pour ce soir.
Bonne nuit à tous,
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Euh... volontiers, mais je vois ça comment ?
Voici mon /etc/resolv.conf en l'état (en 2e et 3e DNS, j'ai inséré ceux donnés par mon FAI sur leur courrier papier, dont un qui est différent de ceux, commentés, utilisés par mon routeur)
Et mon /etc/hosts :
Je n'ai donc pas inséré l'adresse de mon portable, puisqu'en DHCP.
En revanche, y aurait-il qqchose à gagner à mettre l'adresse de mon routeur ? Je dois m'absenter, mais je tenterai ce soir.
Erwann
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Malheureusement non, mon ancien routeur SMC permettait cette configuration, mais sur ce Linksys, les baux DHCP durent au maximum un jour.
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Symoon, ton explication pourrait en effet expliquer le temps de latence du serveur, mais :
1/Pourquoi la connection finit-elle par s'établir ? Cela signifie-t-il que le serveur, après avoir tenté d'obtenir le nom du client pour mettre dans ses logs, accepte en définitive la connection (dans ce cas, le log n'a qu'une utilité relative, d'un point de vue sécurité...) ?
2/ Mon portable est connecté sans fil, d'où l'usage du DHCP, alors que mon serveur est en Ethernet. Comment rendre possible la résolution du nom du client (mon portable), sinon en mettant à jour /etc/hosts chaque fois que le bail DHCP du portable change ? En effet, si le serveur DHCP (mon routeur) gère toutes les résolutions de noms, alors cela pourrait expliquer pourquoi la connection est plus réactive quand les deux ordinateurs (serveur et client) sont en DHCP.
Sinon, mes recherches continuent, et je suis en train de lire des trucs sur le paquet resolvconf, qui n'est pas installé sur mon serveur. Est-il nécessaire que je l'installe ?
Merci,
Erwann
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
Je comprends un peu mieux l'importance de resolv.conf maintenant que j'ai passé mon serveur en IP statique. En revanche, je ne saisis pas quel nom de domaine renseigner en face de "search".
J'ai tenté le coup avec les domaines suivants, sans résultat :
Ce que je ne saisis pas, quand je lis que je dois mettre "mon" domaine, c'est que je n'en possède pas.
Il s'agit d'un simple réseau local, avec une connexion ADSL/IP fixe, et je n'héberge ni ne maintiens aucun site web. Je souhaite juste pouvoir accéder à mes fichiers par FTP en local en donnant le nom de mon serveur, et depuis l'extérieur en tapant l'IP que m'a fourni mon FAI.
Merci de votre aide, j'ai rarement obtenu autant de réponses pertinentes et utiles sur un forum en aussi peu de temps,
Erwann
[^] # Re: Résolutions DNS
Posté par error404 . En réponse au message Serveur Debian moins réactif en IP statique qu'en DHCP. Évalué à 1.
En effet, mon /etc/resolv.conf n'est pas configuré. Comme il s'agit d'un serveur de fichiers sans GUI, caché dans un placard sans écran ni clavier, géré uniquement en SSH, j'étais sur le point de dire que cela n'a pas d'importance... sauf qu'apt-get fait la tronche, maintenant, pour se connecter sur ftp.fr.debian.org...
Il semble que les DNS de mon FAI ont été copiés automatiquement. En revanche, apt-get ne se déride pas, quel "search domain" dois-je mettre ?
De plus, cela peut-il réellement expliquer les temps de latence lors d'une connection SSH ou FTP depuis mon ordinateur portable ? En effet, si j'ai bien compris ce qu'est un DNS, il n'est pas utilisé lors de la commande...
...puisque je renseigne directement l'adresse IP locale de mon serveur.
Pourtant, la connection demande de la patience avant de s'établir...
[^] # On persévère.
Posté par error404 . En réponse au message Réparer une fstab sur RAID1, depuis une Knoppix. Évalué à 1.
J'ai en effet essayé de redémarrer après avoir débranché les deux nouveaux disques, sans succès (toujours ce prompt single user demandant d'effectuer un fsck à la main, et toujours le pc freezé). Mais il est têtard, je n'ai pas pensé à effectuer cette même opération pour le les deux disques composant le volume de stockage installé dès l'origine (/dev/md2)
Je vais essayé de suite, et commenter les lignes de la fstab concernant /dev/md2 et /dev/md3. Je les monterai à la main tant qu'ils ne m'auront pas clairement signifé qui est qui (non mais des fois!). Jouer à la cachette, ce n'est plus de mon âge.
Ma question concernant les "deux versions" de /dev/fstab visait plutot à essayer de saisir les conséquences de la modification en parallèle des volumes composant un RAID1. Mon système n'a bien entendu qu'une seule /dev/fstab :D
Enfin, merci pour les options de mount, je n'avais pas pris conscience du fait qu'il est possible de court-circuiter les autorisations aussi directement.