Partage réseau avec NFS - Page 1

yop,

Je voudrais utiliser NFS pour partager certains dossier sur mon réseau.
Déjà, J'ai un PC en éthernet sur ma box, l'autre en WiFi. Ca ne posera pas de problème, les interfaces de connexion sont transparentes au niveau de NFS ? Je pourrai avoir un réseau normal comme si tout était en éthernet ? [*]

Sur mon PC1, je veux partager des dossiers. J'ai donc utilisé un paquet qui s'appelle kdenetwork-filesharing
Voici comment je l'ai configuré (avec un screen c'est plus simple) : Fichier joint : (screen7.png)
Ca me parait simple à ce niveau. Je vérifie le lancement de nfsd (je boote bien en runlevel 2) :

folco@Weygand:/etc/rc2.d$ ./S20nfs-kernel-server start
./S20nfs-kernel-server: line 42: modprobe: command not found
Exporting directories for NFS kernel daemon...exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/mnt/Data/".
  Assuming default behaviour ('no_subtree_check').
  NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: could not open /var/lib/nfs/etab for locking
exportfs: can't lock /var/lib/nfs/etab for writing
.
Starting NFS kernel daemon: nfsd./S20nfs-kernel-server: line 83: start-stop-daemon: command not found
.

Les erreurs dans les scripts m'étonnent, je n'y ai pas touché. Si vous avez ces fichiers sans trop y avoir touché, ils contiennent ça aussi ?

Erreur de la ligne 42 :

do_modprobe() {
    if [ -x /sbin/modprobe -a -f /proc/modules ]
    then
        modprobe -q "$1" || true
    fi
}

Erreur de la ligne 83 :

		log_daemon_msg "Starting $DESC"
		log_progress_msg "nfsd"
		start-stop-daemon --start --oknodo --quiet \
		    --nicelevel $RPCNFSDPRIORITY \
		    --exec $PREFIX/sbin/rpc.nfsd -- $RPCNFSDCOUNT
		if [ $? != 0 ]; then
			log_end_msg $?
			exit $?
		fi

Bref. Le serveur a tout de même l'air lancé :

folco@Weygand:/etc/rc2.d$ ./S20nfs-kernel-server status
nfsd running

Il me manque quelque chose ?

Sur mon PC connecté en WiFi (PC2), nfs-common est installé.

Dans fstab, j'ai écris ça :
Weygand:/mnt/Data /mnt/Data ext3 defaults 0 0
Quand je fais un "mount -a", il me répond : <Le périphérique spécial Weygand:/mnt/Data n'existe pas>


Ai-je oublié un élément pour faire ce partage ?


[*]
Je viens de vérifier, chaque PC peut pinger l'autre, et reçoit une réponse normale apparemment, donc le réseau local parait correctement consituté :

folco@Weygand:/etc/rc2.d$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=47.2 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=262 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=184 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=102 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=19.7 ms
64 bytes from 192.168.1.11: icmp_seq=6 ttl=64 time=35.3 ms
[...]
^C
--- 192.168.1.11 ping statistics ---
23 packets transmitted, 23 received, 0% packet loss, time 22063ms
rtt min/avg/max/mdev = 10.888/142.134/312.686/92.347 ms

A part que je trouve le ping hallucinant (c'est le second effet WiFi ?), ça m'a l'air tout à fait normal.

Bon, Flanker me fait chercher du côté de mount.nfs -> plantage et hard-reset au premier essai, on continue ça doit être la bonne voie je faisais le test en local, sur la machine serveur elle-même.

PS : comment savoir si PC2 voit PC1 via son hostname ?
Un "ping Weygand" échoue, tandis qu'un "ping 192.168.1.10" réussit... C'est anormal ?

(on aura noté que je n'y connais rien en réseau, je découvre tout à tatons )

Question bête : comment le PC2 pourrait-il faire l'association hostname - IP ? À ma connaissance, Bonjour n'est pas franchement répandu sur Linux...
Du coup, il te faut soit un serveur DNS, soit écrire dans ton fichier /etc/hosts de PC2 :
192.168.1.10 Weygand
(et idem pour PC1)

Pourquoi pas un serveur DNS, mais quel autre avantage pourrais-je en tirer ? Sinon, autant tourner en ip fixe et coder les adresses dans le hosts en effet, non ? Quelle est donc la meilleure solution ?

Dans ton cas, je ne pense pas que ça vaille le coup, mais je développerai davantage quand j'aurais fini mon TP ^^

ok, merci

(vas-y nique-les )

Le plus simple pour partager tes fichiers, c'est d'avoir sshd activé et d'utiliser le kioslave sftp:// ou fuse-ssh.

Et il y a moyen d'utiliser Konqueror (KDE 3.5.10) et Dolphin (KDE 4.4) de manière transparente avec ça ? Faut que ma femme y arrive hein

Tu rentres sftp:// et l'adresse IP dans la barre d'adresses, puis l'utilisateur et le mot de passe dans le dialogue qui va s'ouvrir. Ce qui est cool, c'est que les comptes sont les mêmes qu'en local, pas la peine de configurer quoi que ce soit.

Kevin Kofler (./7) :
Le plus simple pour partager tes fichiers, c'est d'avoir sshd activé et d'utiliser le kioslave sftp:// ou fuse-ssh.

On n'a définitivement pas la même notion de « simple »

Sinon, à propos du DNS :
Le serveur DNS va faire la correspondance entre un nom (www.google.fr, mais aussi weygand, etc.) et l'adresse IP.

DNS :
+ solution flexible : si l'adresse IP change, tu n'as rien à faire sur le client vu que tu utiliseras toujours le même nom
+ tu n'as pas à changer les /etc/hosts : si une nouvelle machine débarque dans ton réseau local (un portable ami), il pourra utiliser directement les noms de machines (à configurer sur le serveur DHCP)
+ si ton portable quitte le réseau local, il n'aura pas de fichier hosts invalide
- chiant à mettre en place
- il faut que les machines reçoivent toujours la même adresse IP (à configurer sur la livebox, il faut mettre en place un serveur DHCP ou configurer les machines en IP fixe)

/etc/hosts :
+ plus simple
- il faut que les machines reçoivent toujours la même IP


À propos du DHCP et du DNS, voici comment ça se passe chez moi. J'ai un serveur DHCP et DNS.
Quand une nouvelle machine débarque sur le réseau, elle demande à la cantonade une adresse IP via un protocole spécifique ; tout le monde recevra la demande qui comporte l'adresse MAC (une adresse unique liée au matériel), mais seul le serveur DHCP va y répondre en lui donnant une adresse IP, une durée du bail, une adresse de serveur DNS et un domaine par défaut.
Pour choisir l'adresse IP, il a deux politiques :
- il connaît l'adresse MAC et il sait quelle adresse IP lui donner
- il donne la première IP libre
Ensuite, la nouvelle machine a directement le serveur DNS à contacter (le même serveur, en l'occurrence), qui connaîtra la correspondance
Du coup, je peux utiliser directement les noms de machines.
Si asterix cherche à contacter teleferic, il va compléter par le domaine par défaut (XXXXXX.net) et va donc demander au DNS l'adresse IP de teleferic.XXXXXX.net, qui sera 192.168.42.23 . Pour l'utilisateur, tout est fait de façon transparente !

L'avantage, c'est quand je quitte le réseau local. Possédant le nom de domaine XXXXXX.net, le DNS chez 1and1 répondra en donnant l'adresse IP de ma freebox quand je ferai une requête sur teleferic.XXXXXX.net, du coup ça marchera toujours aussi bien


Sinon, dans le même genre, tu as le protocole Bonjour, qui fait de la découverte automatique de services disponibles sur le réseau : je peux accéder à asterix.local et teleferic.local sans rien configurer, et asterix sait que teleferic.local partage son imprimante, son scanner, certains dossiers, offre un accès VNC / FTP / Web, etc...
Du coup, dans l'explorateur de fichiers, tu as directement les dossiers accessibles :

Dans iTunes, tu as les bibliothèques musicales partagées, idem dans le carnet d'adresses, iPhoto, etc...
Ça, au moins, c'est simple

NetBios et le partage de fichiers Windows (par Samba) permettent aussi ce genre de trucs sans avoir besoin d'attribuer une IP fixe à un nom, mais je sais pas si Folco voudra installer un truc Windowsien sur sa bécane

Ben mon serveur est sous Debian, après pourquoi pas installer ce qu'il faut pour partager avec un PC sous Windows bien sûr (genre si mon frangin vient ou autre ^^)

Dans ce cas tu peux envisager d'utiliser Samba. Je l'avais fait il y a quelques années sur un petit réseau pour partager les dossiers et l'imprimante d'une machine sous Linux, avec des clients sous Win98, WinXP et Linux. Le tout marchait bien.

Tu veux dire que Samba permet aussi le partage de fichiers entre deux machines Linux ? Remarque j'imagine que oui, ce n'est qu'une interface, peu importe la machine qu'il y a derrière je pense.
Et quel rapport avec l'impression ? Je voudrais que l'imprimante soit accessible depuis les deux PC, il faut bien un serveur d'impression qui n'a rien à voir avec le serveur de fichiers, si ?

Oui, tu peux utiliser Samba pour partager des fichiers entre machines Linux, vu qu'il existe un client et un serveur pour cet OS (mais vu qu'à la base c'est un protocole Windows, on le fait rarement si toutes les machines sont sous Linux).

Le partage de fichier Windows prend aussi en charge le partage des imprimantes, donc si tu installes Samba et que tu le configures comme il faut, tu pourras imprimer depuis une machine Windows sur l'imprimante branchée sur ton serveur sans devoir rien installer en plus. J'imagine qu'il doit y avoir aussi un client Linux pour ça, mais je n'ai jamais essayé.

Ok c'est cool, je vais voir

Je sais pas s'il y a réellement un client linux pour ça, mais de toute façon pour imprimer tu vas a priori avoir un serveur CUPS installé sur la machine à laquelle l'imprimante est connectée (c'est la config standard même pour imprimer en local). Donc ça sert à rien d'avoir autre chose en plus, il suffit d'avoir le client CUPS sur l'autre machine et une ligne dans /etc/cups/client.conf qui indique l'adresse du serveur.

(Par ailleurs il faut que le serveur soit configuré pour écouter le réseau et pas seulement en local. Le tout est expliqué là [edit : attention la page date de 2007, c'est peut-être périmé...] : http://www.debianadmin.com/setup-cups-common-unix-printing-system-server-and-client-in-debian.html )

(le tout étant de configurer Samba comme il faut )

Si tu veux essayer avec sshd (je suis d’avis que ça reste une solution bien simple moi aussi), sache que tu peux, avec dolphin, mémoriser l’url d’accès à la machine en ajoutant un « dossier réseau ». C’est très simple à faire et ensuite tu peux naviguer dedans avec Dolphin. C’est ce que je fais pour accéder à mes données qui sont à la fac.

Merci à tous pour tout. Je vais faire le tri et essayer de tirer parti de tout ça.

Je trouve quand même bizarre de passer par des commandes ftp encapsulées dans du SSH puis dans un wrapper pour faire croire que c'est un FS alors qu'il y a des protocoles qui sont destinés à être des systèmes de fichiers en réseau, justement

Mouais, pas faux

Flanker (./11) :

Kevin Kofler (./7) :
Le plus simple pour partager tes fichiers, c'est d'avoir sshd activé et d'utiliser le kioslave sftp:// ou fuse-ssh.

On n'a définitivement pas la même notion de « simple »

Le grand avantage, c'est qu'il n'y a pratiquement rien à configurer du côté serveur, pas de gestion de comptes (celle du système est utilisée), pas de partages à configurer (on a accès à tout ce à quoi l'utilisateur avec lequel on se loggue a accès, et par défaut on se retrouve dans son HOME) etc.

Zerosquare (./16) :
Le partage de fichier Windows prend aussi en charge le partage des imprimantes, donc si tu installes Samba et que tu le configures comme il faut, tu pourras imprimer depuis une machine Windows sur l'imprimante branchée sur ton serveur sans devoir rien installer en plus.

C'est possible aussi avec CUPS, le protocole IPP utilisé par CUPS est géré depuis au moins XP, peut-être même avant.

Flanker (./22) :
Je trouve quand même bizarre de passer par des commandes ftp encapsulées dans du SSH puis dans un wrapper pour faire croire que c'est un FS alors qu'il y a des protocoles qui sont destinés à être des systèmes de fichiers en réseau, justement

euh sftp n'a rien a voir avec ftp. c'est un protocole qui fait partie de la specification de ssh. et c'est destine (entre autres) a etre un systeme de fichiers en reseau, comme tu dis.

http://en.wikipedia.org/wiki/SSH_file_transfer_protocol

"Compared to the earlier SCP protocol, which allows only file transfers, the SFTP protocol allows for a range of operations on remote files – it is more like a remote file system protocol. An SFTP client's extra capabilities compared to an SCP client include resuming interrupted transfers, directory listings, and remote file removal. [1] For these reasons it is relatively simple to implement a GUI SFTP client compared with a GUI SCP client."

nfs par contre c'est pourri je vois aucune raison d'utiliser ca (mon experience: c'est terriblement lent, chiant a configurer et y a plein de failles de securite).

nfs 3 est pourri, mais ils ont tout refait pour nfs 4

Ah ben tiens, voilà un spammeur original