Articles précédents : Internet
- [5] JRES 2005
- [79] Le Wikiquote francophone risque de fermer sans réaction de sa communauté
- [100] Enfin un FAI ADSL associatif !
- [33] Torrentule : à la recherche des torrents librement téléchargeables
- [17] Derrière vos distributions et logiciels favoris... le retour.
- [22] Derrière vos distributions et logiciels favoris...
- [17] Politique sécurité de Cisco
- [58] Les navigateurs Web, Firefox et les parts de marchés en Europe
- [62] SeaMonkey : C'est parti !
- [95] La FreeBox devient un media center grâce à VLC
Liens connexes
- Le projet de référence pour linux (1759 hits)
- Fiabilisation du projet (568 hits)
- Guide de migration NFSv3 vers NFSv4 (1280 hits)
- Suivi développements client NFS (635 hits)
- Suivi développements serveur NFS (497 hits)
Dépêche modérée par
Dépêche éditée par
Initié en 2001 par l'Université du Michigan, développé et fiabilisé par NetApp et Bull, en version 4, ce protocole de partage de données a été entièrement repensé et ré-écrit pour le partage au travers d'Internet.
NFSv4 est également conçu pour pallier les lacunes des versions précédentes et se pose en successeur et en concurrent de Samba, NFSv3 ou de AFS dont il s'inspire.
Par rapport à ses prédécesseurs, NFSv4 embarque de nombreuses avancées telles que :
- une technologie de cache agressive (délégation)
- Le regroupement des requêtes réseau (Compound request)
- La sécurisation négociée et le chiffrement des données : Kerberos 5, Certificats (SPKM), Clefs publiques/privées (LIPKEY)
- La capacité pour les clients de maintenir des sessions ou de les récupérer malgré un crash serveur ou une panne du réseau
- La possibilité (à terme) de rediriger la charge de serveurs saturés vers un autre serveur, de manière transparente pour les clients
- Le support d'attributs fichier nommés par l'utilisateur (ex. un attribut 'photos')
Disponible pour la plupart des Unix (dont Linux), mais également pour MS-Windows, ce nouveau système de fichier réseau a une vocation industrielle. Il pourrait facilement être utilisé par des particuliers : des versions gratuites et simples à employer existent pour Linux et BSD et la sécurisation forte des échanges mise en oeuvre par NFSv4 protégera efficacement leurs échanges sur le réseau.
![[en]](../../../images/en.png)
Le projet de référence pour linux (1759 hits)-
Fiabilisation du projet (568 hits)
-
Guide de migration NFSv3 vers NFSv4 (1280 hits)
-
Suivi développements client NFS (635 hits)
-
Suivi développements serveur NFS (497 hits)
> Lire la suite (80 commentaires, moyenne: 3,2). [dépêche : 401 caractères]
- Le support des certificats et de Lipkey
- Les attributs nommés.
Si vous voulez suivre les développements, il est recommandé d'utiliser des noyaux à jour pour bénéficier des dernières modifications du module noyau NFS.
j'comprends pas...
C'est quoi le rapport entre NFSv4 et "l'heure des débats" ?
-
[^]Re: j'comprends pas...
Posté par kaouete (page perso, ) le 14/01/2006 à 13:58. (lien). Évalué à 4.Peut-etre simplement parce que NFSv4 est optimisé pour aussi marché à travers le net ?
Je pense que
ce protocole de partage de données a été entièrement repensé et ré-écrit pour le partage au travers d'Internet.
laisse comprendre ca.-
[+] [^]Re: j'comprends pas...
Posté par Christophe Merlet (page perso, ) le 14/01/2006 à 14:03. (lien). Évalué à -10.> Peut-etre simplement parce que NFSv4 est optimisé pour aussi marché à travers le net ?
Ha heuuuu, ben au meme titre que NFSv3, SMB/CIFS, HTTP/WebDAV, FTP, etc.
Rien de révolutionnaire donc...
> ce protocole de partage de données a été entièrement repensé et ré-écrit pour le partage au travers d'Internet.
J'espére qu'ils ont fait autre chose que de réinventer la roue !
Ou alors c'est la news qui cherche une accroche pour appater le lecteur moyen de linuxfr...-
[^]Re: j'comprends pas...
Posté par Damien Metzler () le 14/01/2006 à 14:23. (lien). Évalué à 10.Ben NFSv3 est quand même pas génial sur une connexion WAN. Il fait des requêtes RPC de partout et t'a intérêt à avoir tes DNS bien configurés pour que ça fonctionne correctement et que ça tombe pas en timeout au bout de 3 mount parce que la requête reverse DNS marche pas côté serveur....
SMB/CIFS est assez pourri et notamment pour passer à travers les switch, les résolutions de nom WINS ne passent pas
HTTP/WebDAV pas de réel client qui prenne en compte toutes les spécificités du protocole
FTP : pourquoi pas proposer rcp comme système de fichier tant que t'y est...
Je ne connais pas la v4 mais si les nouveautés dont parle l'auteur dans la news sont vraies, c'est une vraie évolution de NFS.-
[+] [^]Re: j'comprends pas...
Posté par Christophe Merlet (page perso, ) le 14/01/2006 à 14:36. (lien). Évalué à -2.Le seul défaut que tu trouve a NFSv3 est sa dépendances aux serveurs DNS ? Je vais te décevoir, pour TOUS les protocoles internets sont dépendants du bon fonctionnement des DNS, y compris NFSv4 !
Cela dit, il existe une solution, tu peux toujours utiliser les adresses IP directement, ça marche pour tous les protocoles !
Ha tiens c'est nouveaux ça, SMB qui ne passe pas a travers les switchs. Tant que t'y ai, dis qu'il faut secouer les cables réseaux pour aider les gros paquets SMB a passer !
De plus WINS n'est plus utilisé depuis bien longtemps, et quand bien meme, WINS est conçu pour fonctionner a travers l'internet.
Pour WebDAV, je suis curieux de savoir qu'elles sont les spécificités du protocole que tu ne retrouve pas dans les clients et qui t'empeche de partager les fichiers.
Concernant FTP, ça fait 30 ans qu'il partage des fichiers et qu'il le fait bien. Je n'ai rien a lui reprocher.-
[^]Re: j'comprends pas...
Posté par Laurent J (page perso, ) le 15/01/2006 à 00:03. (lien). Évalué à 4.Bien sûr... utiliser ftp pour travailler en direct sur un disque distant, et de façon transparente... Et la marmotte...
-
[^]Re: j'comprends pas...
Posté par Amand Tihon (page perso, ) le 15/01/2006 à 03:23. (lien). Évalué à 4.Ça m'arrive très souvent, même si je préfère le faire en sftp ou en fish.
Et je le fais tant sous KDE qu'en console avec Midnight Commander.-
[^]Re: j'comprends pas...
Posté par yoho (page perso, ) le 15/01/2006 à 04:35. (lien). Évalué à 10.Non, ce que tu fais, c'est certainement du transfert de fichier... Essayes de monter un répertoire personnel en FTP et tu verras le problème tout de suite. Mieux, essayes de monter /usr en FTP... bah ça NFS est fait pour ça : ça roxe côté rapidité de transfert, y compris pour les accès en lecture/écriture avec beaucoup de fichiers, ce que ne fait pas FTP (c'est plutôt pour une quantité raisonable de gros fichiers FTP).
-
[+] [^]Re: j'comprends pas...
Posté par Christophe Merlet (page perso, ) le 15/01/2006 à 08:38. (lien). Évalué à -3.Je ne vois toujours pas le rapport avec le débat sur le téléchargement de fichiers... tu peux m'éclairer ?
-
[^]Re: j'comprends pas...
Posté par Amand Tihon (page perso, ) le 15/01/2006 à 08:42. (lien). Évalué à 6.Alors c'est sûr et certain, la finalité de FTP n'est pas la même que celle de NFS. Effectivement, FTP ne permet pas tout ce qu'offre NFS.
Par contre, je maintiens, persiste et signe, j'ouvre sans problème dans mon éditeur de texte des fichiers présents sur un serveur FTP. Simplement, c'est fait au niveau applicatif par les kioslaves, et pas par le système. C'est ça que je voulais dire quand je parlais d'utiliser le FTP de manière transparente : je me fiche de savoir si ça se passe en local, FTP, sftp, NFS ou Samba, mes applications ne broncheront pas et j'éditerai sagement mon fichier. Je le fais rarement en FTP, mais je le fais tous les jours en fish://-
[^]Re: j'comprends pas...
Posté par v_atekor () le 15/01/2006 à 10:17. (lien). Évalué à 10.La différence avec ftp et les autres est très simple :
NFSv4 est un système de fichier, qui permet (par rapport à FTP)
-un mapping d'uid,
-un accés tranparent au système distant pour les programmes au niveau du système d'exploitation (Et non au travers d'une couche d'abstraction elle que KDE/KIO)
-Une gestion concurente des programmes (Ouverture en lecture simultanée à une ouverture en écriture par différents clients... )
-Une gestion des locks (verrous sur le fichier, sur des sections de fichiers)
En bref: NFSv4 est très proche de la norme POSIX (sections systèmes de fichiers) ce qui est a des années lumières de ftp ou http qui ont leuur propre standard.
Un programme quelconque prévu pour fonctionner en local (sans couche d'abstraction de type KIO...) pourra exploiter des ressources NFSv4, et non des ressources ftp ou http.
-
[^]Re: j'comprends pas...
Posté par Jean Parpaillon (Jabber id, page perso, ) le 16/01/2006 à 08:38. (lien). Évalué à 10.Et voilà ce qui arrive quand on a des applications trop intelligentes... Les gens sont même plus foutus de faire la différence entre un système de fichier et un protocole réseau, entre un réseau local et réseau global.
-
[^]Re: j'comprends pas...
Posté par Sylvain Briole (page perso, ) le 16/01/2006 à 12:20. (lien). Évalué à 6.Ce sera encore pire lorsque le Hurd règnera en maître sur le monde : avec ses "translators", ftp, smb, http ou autre, tout sera fichier et système de fichiers! ;-)
-
[^]Re: j'comprends pas...
-
-
[^]Re: j'comprends pas...
Posté par Tzacos () le 17/01/2006 à 11:23. (lien). Évalué à 4.la différence est simple:
NFS est un système de fichier, c'est à dire qu'il sert sur une partition montée (distante ou locale)
FTP est un protocole de transfert de fichier, il ne fait quer TRANSFERER les ficheirs et rien d'autre (en simplifiant)
-
-
-
-
-
[^]Re: j'comprends pas...
Posté par Farvardin (page perso, ) le 15/01/2006 à 17:02. (lien). Évalué à 10.après les vieux trolls Atari / Amiga, Mac / Pc, Kde / Gnome, Linux / Windows, on assiste sous nos yeux ébahis à un troll d'un nouveau genre : NFS / FTP (alors que l'on s'attendait plutôt à qque chose comme NFS / SMB ...)
--
You can't grep dead trees...
-
[+] [^]Re: j'comprends pas...
Posté par Xion345 (Jabber id, ) le 15/01/2006 à 19:17. (lien). Évalué à -2.A ma connaissance, tous les paquets TCP ont la même taille !
Inutile donc de secouer les cables pour faire passer les gros paquets :-)
Par contre, secouer les cables peut être utile pour éviter les embouteillages, d'ailleurs il existe un proverbe bien connu : "Secouer ou embouteiller, il faut choisir"-
[^]Re: j'comprends pas...
-
-
[+] [^]Re: j'comprends pas...
Posté par Xion345 (Jabber id, ) le 15/01/2006 à 19:47. (lien). Évalué à -5.A ma connaissance, tous les paquets TCP ont la même taille !
Inutile donc de secouer les cables pour faire passer les gros paquets :-)
Par contre, secouer les cables peut être utile pour éviter les embouteillages, d'ailleurs il existe un proverbe bien connu : "Secouer ou embouteiller, il faut choisir"-
[^]Re: j'comprends pas...
Posté par FReEDoM (page perso, ) le 16/01/2006 à 12:50. (lien). Évalué à 1.1) Quand on parle de TCP, on parle de trame (paquet IP oui OK)
2) Ces dernières sont de taille variable gérée tout seul par le protocol TCP (voir congestion taille de fenêtre)-
[^]Re: j'comprends pas...
-
-
-
-
[^]Re: j'comprends pas...
Posté par Sami Dalouche (page perso, ) le 16/01/2006 à 09:59. (lien). Évalué à 1.Tu as quand même oublié ssh (sur FUSE, ou GNOME-VFS, et je suppose que KDE a son équivalent aussi). Ca fonctionne pas trop mal, mais il est vrai que ca manque de clients du côté de Windows...
A part les bugs Nautilus, WebDAV est pas trop mal non plus.. Dommage qu'il n'existe pas de resume en upload / download. Quelqu'un sait si c'est prévu dans le futur ?
Longue vie à NFSv4, qui espérons, ne sera pas un désastre comme NFSv3...
-
[^]Re: j'comprends pas...
Posté par Gnurou (page perso, ) le 16/01/2006 à 13:03. (lien). Évalué à 9.Ben NFSv3 est quand même pas génial sur une connexion WAN. Il fait des requêtes RPC de partout et t'a intérêt à avoir tes DNS bien configurés pour que ça fonctionne correctement et que ça tombe pas en timeout au bout de 3 mount parce que la requête reverse DNS marche pas côté serveur....
Mais non, l'informatique, ce n'est pas plein de jargon... :)
-
-
[^]Re: j'comprends pas...
Posté par case42 (page perso, ) le 14/01/2006 à 14:24. (lien). Évalué à 10.Il me semble qu'NFSv3 se comporte plutot mal quand la connectivite avec le serveur est mauvaise (entre autre si le serveur ne repond pas, ca hang vilainement).
A mon avis le cote "optimise pour aussi marcher a travers le net" est a raproche du "systeme de cache agressive", qui je pense devrais permetre a un client de continuer a fonctionner sans trop de soucis meme si le serveur est provisoirement inaccessible.
Donc oui, effectivement, NFS peut deja fonctionner a travers le Net, mais il n'est pas optimise pour.-
[+] [^]Re: j'comprends pas...
Posté par gniiiiiiiiii () le 14/01/2006 à 22:19. (lien). Évalué à -4.Il me semble qu'NFSv3 se comporte plutot mal (...)
Il ne vous est pas venu à l'idée que c'était peut-être le support linux de NFS qui était quelque part pourri ! Sur BSD ça marche plutôt mieux... :-)-
[^]Re: j'comprends pas...
Posté par case42 (page perso, ) le 15/01/2006 à 10:29. (lien). Évalué à 5.Je peux temoigner d'experience que sur NetBSD ca ne se passe pas bien non plus.
Je voulais rajouter aussi que l'usage d'NFS sur le net ne peux s'envisager serainement de nos jours qu'a travers un VPN ou autre tunnel chiffre. Integrer la possibilite de chiffrer dans NFS simplifiera bien la vie (oui je sais, d'autres le font deja...)
-
-
[^]Re: j'comprends pas...
Posté par v_atekor () le 15/01/2006 à 10:34. (lien). Évalué à 10.NFS (v3) peut aller sur internet, mais...
-Si le réseau fonctionne _toujours_ bien (pas de déconnections intempestives, sous peine de perte de session
-Le port NFS est choisi aléatoirement ce qui ne simplifie pas la gestion des firewall
-la quantité d'information liée au protocole transmise par NFSv3 est beaucoup plus importante qu'en v4, et ralentit considérablement les échanges.
- la gestion du cache est limitée
NFSv4 répond à tout ça :
- Le port de connection est unique (2049)
- Les pannes réseaux (fréquentes sur internet) ne gènent pas le fonctionnement)
- les requètes sont regroupées pour éviter des allées et venues entre client et serveur
- le cache est beaucoup plus efficace
Enfin, utiliser NFSv3 sur internet est suicidaire du point de vue sécurité.-
[+] [^]Re: j'comprends pas...
Posté par FRLinux (page perso, ) le 15/01/2006 à 18:39. (lien). Évalué à -1.> Enfin, utiliser NFSv3 sur internet est suicidaire du point de vue sécurité.
Je vois pas du tout ce qui te fait dire çà :)
(pardon, j'ai pas pu m'empecher ... bougez pas, je suis deja dehors :)
-
-
[+] [^]Re: j'comprends pas...
Posté par tuks () le 15/01/2006 à 21:24. (lien). Évalué à -1."Il me semble qu'NFSv3 se comporte plutot mal quand la connectivite avec le serveur est mauvaise (entre autre si le serveur ne repond pas, ca hang vilainement)."
efectivement...ca pose enormement de problemes quand c'est mal configure...
j'ai essaye nfs v3 avec:
ordi windows(sfu) qui plante <----->ordi linux kde
ca posait enormement de problemes a xine et kde...
car d'abitude j'uttilisait un reseau "reliable" entre linux et linux...j'avais donc pas configure nfs pour ce genre de "hang"
-
[^]Re: j'comprends pas...
Posté par Laurent Pointal (page perso, ) le 16/01/2006 à 12:06. (lien). Évalué à 3.(entre autre si le serveur ne repond pas, ca hang vilainement).
Ouaip, j'ai eu des blocages méchants sur un serveur à cause de montages NFS d'un autre serveur qui de temps en temps n'allaient pas bien (et de FAM qui zieutait tout ça).
Résolus en montant les volumes avec les options soft,bg.
-
-
-
Numéro d'utiisateur
Si je me trompe pas, NFS, on peut pas mêtre d'identifiant, il faut avoir le même numéro d'utilisateur. Ce qui me semble pas pratique pour un partage simple des fichiers.
Ce sera pareil avec la version 4 ?
-
[^]Re: Numéro d'utiisateur
Posté par kaouete (page perso, ) le 14/01/2006 à 15:35. (lien). Évalué à 2.oui c'etait le cas.
Et je crois bien que ce sera possible de faire les choses differement avec cette nouvelle version, d'apres ce que j'en avais lu (et d'apres ma memoire :)
-
[^]Re: Numéro d'utiisateur
Posté par Gilles Mocellin () le 14/01/2006 à 15:42. (lien). Évalué à 2.C'est la question que je me pose aussi. Si on a pas la possibilité de gérer des utilisateurs en dehors de ceux du système, ou au moins de faire un mapping entre les utilisateurs coté client et ceux coté serveur, samba/cifs sera toujours mieux...
Il serait bien aussi qu'un simple utilisateur puisse monter ou utiliser un espace distant sans être obliger d'être root. Un login/mot de passe/certificat/jeton Kerberos pour se faire reconnaître du serveur devrait suffire.
-
[^]Re: Numéro d'utiisateur
Posté par Gilles Mocellin () le 14/01/2006 à 15:56. (lien). Évalué à 1.En regardant le tutorial, ça marche comme en V3. Il faut une base d'utilisateur commune au serveur et au client, NIS ou LDAP...
-
[^]Re: Numéro d'utiisateur
Posté par yoho (page perso, ) le 15/01/2006 à 04:39. (lien). Évalué à 3.Tu peux aussi indiquer au serveur NFS un mapping entre telle UID et telle autre UID, où donner à tous les utilisateurs un même UID (un peu comme un mode anonyme en FTP finalement).
-
[^]Re: Numéro d'utiisateur
Posté par Rémi Delepoulle () le 15/01/2006 à 06:56. (lien). Évalué à 1.ça a l'air compliqué, je me dis, autant utiliser samba, quand on comprend pas tout ça ....
-
[^]Re: Numéro d'utiisateur
Posté par v_atekor () le 15/01/2006 à 10:27. (lien). Évalué à 9.NFSv4 est prévu pour internet, et évidement sur internet il difficile de prévoir quel UID sera utilisé par un client sur une machine de l'autre côté de la planète...
Donc, nfsv4 prévoit un ID mapper qui permet de faire des correspondances entre les uid/gid des clients et ceux du serveur...
Pour ceux qui ont un LAN avec quelques machines et pour qui ce mécanisme est inutile, NFSv4 supporte (évidemment) et dans la configuration par défaut la correspondance : uid client = uid serveur... sauf pour l'utilisateur root pour des raisons évidentes de sécurité (root client = nobody serveur, par défaut).
En bref, la configuration par défaut offre un fonctionnement proche de SAMBA, avec des performances et une sécurisation plus efficace; et tout est prévu pour aller plus loin, beaucoup plus loin.
C'est une avancée importante de pouvoir gérer correctement les uid/gid sur NFsv4 par rapport à NFSv3.
L'idmapper s'interface avec LDAP et NIS et permet des déploiements plus complexes (dans le style active directory, par exemple)-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 15/01/2006 à 20:36. (lien). Évalué à 4.Il y a des trucs super avec Samba. Par exemple ;
- le root d'une machine n'est pas capable de réellement prendre l'identité d'une autre personne. Faire sous root "su - toto" permettra d'avoir un shell sous toto mais aucunement d'avoir accès aux données de toto. Avec NFS, si ! Or comment voulez faire confiance a une tentacule de PC distribué sur le net dont vous ne seriez pas sur des root...
- j'adore la possibilité de pouvoir lancer des scripts via les hooks "root pre exec...". Je trouve cela super souple. Je crée ainsi pas mal de script .bat à chaud en fonction de la personne mais aussi de la machine. OK, on doit pouvoir faire cela avec apache2 et j'envisage de transférer une partie de mes scripts utilisant un transport CIF vers du transport http, mais bon, c'est pratique ces hooks.
OK, samba a aussi plein de défauts. Pas de point de montage partagé entre utlisateurs, un protocole qui fait tout et n'importe quoi (partage de fichier, impression...). Ce serait bien de pouvoir avoir un paquet samba qui n'ai pas le code concernant l'impression par exemple.-
[^]Re: Numéro d'utiisateur
Posté par tuks () le 15/01/2006 à 21:32. (lien). Évalué à 4."le root d'une machine n'est pas capable de réellement prendre l'identité d'une autre personne."(sous samba) "Avec NFS, si !"
j'ai gentoo...ca resemble a bsd donc je sait pas pour les autres distribs
dans /etc/exports qui est le fichier de configuration ou tout est stoque pour le serveur nfs...(repertoire,ip,options) ba dans les options de configuration t'as des option pouvant empecher ca
man exports pour plus d'info-
[^]Re: Numéro d'utiisateur
Posté par Matthieu C () le 15/01/2006 à 22:01. (lien). Évalué à 2.C'est surout un pb de mapping : vu qu'il y a pas d'authentification NFS n'a pas moyen de savoir si tu dis vraiement qui t'es.
avec /etc/exportso n peut mapper le root en anonymous, mais j'ai pas souvenir qu'on puisse faire plus complexe...-
[^]Re: Numéro d'utiisateur
Posté par Rémi Delepoulle () le 16/01/2006 à 00:43. (lien). Évalué à 3.J'ai l'impression que NFS, c'est probablement une bonne chose pour des gros server qui se font confiance entre eux, mais en aucun cas pour des particuliers.
Moi je me sert de samba, alors que je sait même pas mon uid ni mon gid, ni ce que c'est un mapping de uid/gid
c'est ça qui est bien avec samba. c'est a peut près aussi facile d'emploit qu'un ftp avec des aventages en plus.-
[^]Re: Numéro d'utiisateur
Posté par CS () le 16/01/2006 à 19:58. (lien). Évalué à 8.C'est tout à fait la philosophie des auteurs du protocole Smb : faire un truc simple, ou y a qu'a cliquer pour le configurer et ou faut surtout pas comprendre comment ça marche. Et tant pis si c'est tout pourris, ça fait ramer les réseau etc.
Non pas que je pense que des logiciels simples à utiliser soient néfastes, au contraire. Simplement, ce type de discours ("je me fous de comment ça marche du moment qua j'arrive à le faire marcher en 5 minutes") était exclusivement tenu par des Windowsiens, auxquels ont répondait qu'un newbie qui comprend rien à ce qu'il fait est dangereux et que sous Linux on est obligé de comprendre un minumum avant de faire n'importe quoi.
De fait, les légendaires problèmes de sécurité de Windows furent longtemps majoritairement des problèmes d'administrateurs amateurs qui faisaient n'importe quoi (pourvu que ça marche).
En prendrait-on la direction sous *nix ?-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 20:56. (lien). Évalué à 5.Il suffit de voir cette daube de gconf qui ne sers à rien ...
On peux cependant reprendre dans SMB ce qui est bien. Par exemple, l'authentification des utilisateurs et virer ce qui est pourris (le partage par n'importe qui n'importe comment, le partage d'impression, les élections pour être master du voisinage réseau, le mélange avec les RPC...)
-
-
-
-
-
[^]Re: Numéro d'utiisateur
Posté par yoho (page perso, ) le 16/01/2006 à 02:29. (lien). Évalué à 3.Je comprend pas le premier point... tu fais forcément confiance au root où se trouve tes données, puisque tu mets tes données sur son PC/serveur... J'arrive pas à me représenter un cas concret illustrant ce que tu dis. Je suis toto sur la machine A, j'accède à mes données en tant que toto sur la machine B, donc, oui, root de la machine B peut accéder à mes données, mais c'est tout, aucun autre root ne le peux.
Ce qui est un peu plus dangereux, c'est NIS : NIS peut dire "si tu es root sur A, c'est comme si tu étais root sur B" (mais les machines A et B doivent faire partie du réseau NIS). C'est pourquoi root est généralement une exception dans la base NIS : c'est le seul utilisateur qui n'est pas dedans (si l'admin a bien configuré son truc).
En plus, tu sembles dire que samba a des avantages sur NFS, mais je me représente encore moins lesquels (à part le multi-plate-forme évidemment). Samba est hyper lent pour le transfert de fichiers.-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 08:32. (lien). Évalué à 4.Je connais un peu NFS et Samba ainsi que NIS. Je les utilise tous les trois tous les jours ;-)
Les fichiers de toto sont une la machine A, tu te logues sur la machine B, tu passes en root et tu fais su - toto. Tu as alors acces a tous les fichiers de toto sur la machine A alors que tu es sur la machine B !
Avec Samba, cela ne marche pas car même si tu devient toto sur la machine B, cela ne te donne pas le droit de lire les fichiers sur la machine A. C'est tout.
Au niveau performance, je suis d'accord et j'utilise nfs en local entre mes machines UNIX dont je controle le root !
C'est pour cela qu'avoir un NFS qui tient sur internet me parait à la fois mieux (car ca ira aussi mieux en local) mais je ne vois pas bien comment je pourrais avoir confiance en des machines distribués sur le net et dont je ne maitrise pas le root.
Au niveau NIS, tu gères qui est dans la base NIS et il n'y a pas que le root qui est exclus ! En pratique, tu ne met que la plage des uid de tes utilisateurs. NIS n'est pas super sécurisé mais combien de personne tourne avec un ldap sans ssl ! D'un point de vue sécurité, ldap sans ssl n'est pas franchement mieux que nis. Il suffit de mettre un poste client de l'annuaire et de faire un "getent password" pour s'en rendre compte. La aussi, il faut maitriser les root locaux que le ldap soit avec ssl ou sans ssl.
Question : comment maitrises tu le root des portables qui passe leur temps a voyager ?
J'espère avoir été plus clair ;-)-
[^]Re: Numéro d'utiisateur
-
[^]Re: Numéro d'utiisateur
Posté par Benoît Sibaud (Jabber id, page perso, ) le 16/01/2006 à 09:35. (lien). Évalué à 3.> Les fichiers de toto sont une la machine A, tu te logues sur la machine B, tu passes en root et tu fais su - toto. Tu as alors acces a tous les fichiers de toto sur la machine A alors que tu es sur la machine B !
Il faut que A partage ses fichiers à B pour ça, donc que le root@A fasse confiance au root@B (au moins partiellement, genre partage en lecture seule).-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 14:11. (lien). Évalué à 2.C'est justement le problème !
La machine A doit rendre accessible des fichiers pour toto qui travaille sur la machine B en lecture ecriture.
A partir de ce moment là, il faut avoir le controle du root de la machine B ce qui est difficile pour un protocole qui irait sur internet parce que les machines pourraient etre distantes de pas mal de bornes.
Avec un partage de type samba, il n'y a pas ce problème... Mais cela a aussi des inconvénients. Par exemple avec NFS, tu te logues et avec l'automounteur, tu as toutes tes données en lecture écriture (enfin, avec le module pam pmount, on peux faire a peu près pareil avec samba). L'autre avantage est de pouvoir mutualiser les points de montages et les requètes sur le serveur nfs entre les utilisateurs.
Dans les laboratoires de recherche, on a de plus en plus affaire a du nomadisme. NFSv4 ne semble pas pouvoir répondre à cette problématique.-
[^]Re: Numéro d'utiisateur
Posté par v_atekor () le 16/01/2006 à 15:09. (lien). Évalué à 2.Si, il y répond complètement et a été conçu dans cette optique. NFSv4 se veut un concurent de SAMBA (entre autre) et donc permet _au minimum_ d'imiter le fonctionnement de SAMBA.
NFSv4 peut être associé à :
IDMapper ou/et LDAP ou/et Kerberos.
L'utilisation de Kerberos délivre un jeton de manière indépendante de l'UID utilisé, et permet le montage avec les droits correspondant.
Donc, à la base peux avoir un montage indépendament de la machine utilisée avec des droits corrects.
Ajoute LDAP et tu n'as même pas besoin de spécifier quel répertoire tu dois monter pour obtenir tes données.
Je ne comprends pas où tu vois un problème?-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 15:42. (lien). Évalué à 2.Je précise que je n'ai jamais utilisé NFSv4. Donc je navigue a vue. Je ne suis pas là pour descendre NFS que j'utilise tous les jours et que je trouve parfois bien plus pratique que Samba.
Pour moi, d'après ce que j'ai compris, NFS identifie les machines et non les personnes. Dans la version 4, c'est nettement supérieur à ce qui se faisait dans la version 3 (en gros, les netgroup).
Le problème d'après moi est que si tu authorises une personne a accéder à un serveur NFS(v4) sur sa machine avec son compte, alors si elle a le mot de passe root, elle peux accéder aux données concernant les autres personnes qui aurait accès à cette même machine. Chose non possible avec Samba.-
[^]Re: Numéro d'utiisateur
Posté par v_atekor () le 16/01/2006 à 15:51. (lien). Évalué à 1."Le problème d'après moi est que si tu authorises une personne a accéder à un serveur NFS(v4) sur sa machine avec son compte, alors si elle a le mot de passe root, elle peux accéder aux données concernant les autres personnes qui aurait accès à cette même machine. Chose non possible avec Samba."
Ce n'est pas le cas. Ce n'est d'ailleurs pas le cas non plus avec NFSv3 si tu utilises l'option root_squash (Option passée dans la configuration par défaut)
Dans la version 4, c'est le rôle de l'IDMapper de faire correspondres les identifiants entre client et serveurs, et les droits correspondants sont appliqués par NFS.
Si tu utilises un protocole de sécurité tel que Kerberos lié à LDAP, alors le risque est nul, même si tu te loggue sur une machine qui n'est pas la tienne, et que tu réalise un montage.
Tu as un message privé...-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 18:08. (lien). Évalué à 3.> Tu as un message privé...
OK, je te repond la dessus tout a l'heure.
Sinon, root_squash ou pas, ca ne change pas grand chose.
Je suis root sur une machine, je fais su - toto et je prends l'identité de toto et peux alors lire les fichiers de toto sur le serveur.
Le problème est que sur un portable qui se balade, la personne a le mot de passe root DONC peut prendre l'identité de n'importe quel compte accessible sur cette machine. Dès que les machines se font confiances, cette personne a donc accès a tous les fichiers exportés sur des partages NFS, quel que soit les droits posés dessus... CQFD.-
[^]Re: Numéro d'utiisateur
Posté par Benoît Sibaud (Jabber id, page perso, ) le 16/01/2006 à 20:30. (lien). Évalué à 1.En même temps, le mot de passe root donne accès à tous les mots des utilisateurs (par cassage ou par écoute clavier...), que l'on utilise du NFS, du SMB, du FTP ou du SSH...
-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 16/01/2006 à 20:52. (lien). Évalué à 3.Je suis d'accord, mais je pense par exemple à un portable en libre service utilisé par pleins de personnes mais pas en même temps.
Il est clair que sur une machine réellement multi-utilisateurs, le mot de passe root ne doit pas être diffuser. C'est rarement le cas des portables or ce sont les portables qui posent des problèmes d'administration aujourd'hui.-
[^]Re: Numéro d'utiisateur
Posté par gpe () le 17/01/2006 à 10:57. (lien). Évalué à 1.Euh? Pourquoi les utilisateurs d'un portable en libre service devraient avoir le mot de passe root?
-
[^]Re: Numéro d'utiisateur
Posté par Sytoka Modon (page perso, ) le 17/01/2006 à 12:58. (lien). Évalué à 3.Si le portable voyage beaucoup, il y a des cas où on est obligé de le donner a distance...
Sinon, a moins de verouiller complètement dès le BIOS, on sais ca que vaut réellement un mot de passe root ! C'est très facile a casser sur une machine.
Et même en verouillant le BIOS, il suffit de demonter le disque dur et de le monter sur une autre machine pour le changer. C'est vachement dur (en général une vis a déviser).
Bref, personnellement, je n'ai pas confiance dans les portables qui voyagent...
Mais depuis que je sais que NFSv4 authentifie les personnes et pas seulement les machines comme sous NFSv3, le problème du root est bien moins crucial.
-
[^]Re: Numéro d'utiisateur
Posté par boklm (page perso, ) le 17/01/2006 à 14:04. (lien). Évalué à 0.Et pourquoi pas ?
C'est le meme problème avec un portable personnel. C'est pratique de pouvoir donner le pass root à l'utilisateur du portable (de toute facon, il n'aura pas trop de mal à le récuperer lui meme avec un accès physique à la machine). Le problème avec NFSv3, c'est qu'en autorisant sa machine à se connecter au serveur NFS, on lui autorise l'accès à tous les fichiers des autres utilisateurs en meme temps, car la verification des permissions sur les fichiers est effectuée par la machine cliente (sur laquelle l'utilateur est root), et non pas sur le serveur NFS. Il lui suffit donc d'un 'su - ptramo' pour acceder aux fichiers de Pierre Tramo (le très celebre J2EE Lead Architect).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Numéro d'utiisateur
Posté par yoho (page perso, ) le 15/01/2006 à 19:52. (lien). Évalué à 2.Avec samba aussi il faut faire un maping d'UID...
-
-
-
[^]Re: Numéro d'utiisateur
-
-
Bonjour sur LAN
Salut,
Est-ce qu'il y a un moyen de détecter des partages NFS sur un réseau local avec un truc comme Bonjour/RendezVous/Avahi ?
Amha, C'est la fonctionnalité qui manque pour remplacer Samba dans les foyers (outre la compatibilité Windows®).
E Ultreïa !
-
[^]Re: Bonjour sur LAN
Posté par briaeros007 () le 14/01/2006 à 18:34. (lien). Évalué à 6.quand je faisais mumuse avec nfs(v3) , on pouvais déja facilement détecter les serveurs présents sur le réseau . Je vois pas pouquoi ca changerais maintenant .
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Bonjour sur LAN
Posté par Étienne Bersac (Jabber id, page perso, ) le 14/01/2006 à 19:49. (lien). Évalué à 4.Salut,
Oui en fait, ma question n'a pas de rapport avec NFS. La vrai question est quand les Envirronements de Bureau gèreront-il la détection de partages NFS ? Il semble qu'avahi viennent combler cela. Et pour de nombreux service en plus.--
E Ultreïa !
-
-
[^]Re: Bonjour sur LAN
Posté par Drolez Ludovic (page perso, ) le 15/01/2006 à 11:27. (lien). Évalué à 4.Oui, NFS quel que soit sa version, propose un service pour lister les partages disponibles sur le serveur (utilisé par exemple par autofs ou am-utils, commande showmount --exports srv). Ce qui manque sous Linux, c'est quelque chose pour découvrir les stations, et de ce coté le DNS multicast (Bonjour) fonctionne bien et me séduit beaucoup.
Donc oui, mDNS + NFSv4 est AMHA, une combinaison bien supérieure à Netbios+CIFS.-
[^]Re: Bonjour sur LAN
Posté par Tobu () le 15/01/2006 à 14:36. (lien). Évalué à 3.Le client zeroconf de konqueror (adresse zeroconf:/ ) détecte les partages nfs d'après http://dot.kde.org/1114696139/ , mais je ne sais pas trop quel serveur nfs l'annonce. J'imagine que celui d'OSX le fait. Sinon on peut imaginer un démon à part qui se charge de voir si un nfs tourne en local et de l'annoncer.
-
-
[^]Re: Bonjour sur LAN
Posté par gc (page perso, ) le 15/01/2006 à 20:58. (lien). Évalué à 1.Ca ne manque pas vu que ca existe déjà.
rpcinfo -b mountd 2
rpcinfo -b mountd 3
C'est utilisé par exemple par l'assistant de partage de connexion de Mandriva : l'assistant propose la liste des partages NFS et SMB détectés.
Tiens c'est fiabilisé en france à grenoble
Je suis sur que les développeurs de cet outils lisent ce site, et je les félicite de leur travaille au nom de toute la communauté.
-
[^]Re: Tiens c'est fiabilisé en france à grenoble
Posté par Pierre Tramo () le 15/01/2006 à 10:35. (lien). Évalué à 0.C'est gentil de ta part, je suis sûr que ça va leur faire plaisir.
-
[^]Re: Tiens c'est fiabilisé en france à grenoble
des infos ?!
"Disponible pour la plupart des Unix (dont Linux), mais également pour MS-Windows"
si quelqu'un connaît un moyen libre d'accéder à des montages nfs depuis windows xp...
-
[^]Re: des infos ?!
Posté par FRLinux (page perso, ) le 15/01/2006 à 12:18. (lien). Évalué à 3.Une petite recherche me ramène directement sur la page du coté obscur : http://support.microsoft.com/?kbid=324055
Steph-
[^]Re: des infos ?!
Posté par poil oq () le 15/01/2006 à 20:23. (lien). Évalué à 1.bon forcément c'est pas plus libre que l'OS, par contre il faut s'enregistrer sur "passport", je trouve ça moyen...
en plus les critiques sur internet ne disent pas du bien du support NFS via SFU (pauvre en performance surtout) je vais me lancer dans des tests quand même...
-
une question non sur NFS mais en rapport un peu avec le sujet
Est-ce que Coda (autre système de fichier distribué) permet un partage par le biais d'internet et pas seulement du réseau local, et cela de façon sécurisé??
-
[^]Re: une question non sur NFS mais en rapport un peu avec le sujet
Posté par v_atekor () le 16/01/2006 à 12:51. (lien). Évalué à 1.Oui.
Coda est le successeur de AFS qui permet déjà ça.
http://www.coda.cs.cmu.edu/-
[^]Re: une question non sur NFS mais en rapport un peu avec le sujet
Posté par NebuchadnezzaR () le 16/01/2006 à 13:53. (lien). Évalué à 1.Coda ! c'est pas un peu mort ? Je crois que son remplaçant devait être intermezzo qui en fait en mort et remplacé par LustreFS.
D'ailleurs la politique de la société clusterFS sur la release GPL de lustreFS a changé, avant il fallait 1 an après la sortie de la version commercialle, aujurd'hui elle sort directement.
http://www.lustre.org
http://www.clusterfs.com/pr/2005-11-16.html
-
Intégré au noyau
Quelqu'un sait combien de temps il faudra attendre pour voir nfs4 sans le mode experimental intégré au kernel vanilla?
-
[^]Re: Intégré au noyau
Posté par v_atekor () le 15/01/2006 à 15:17. (lien). Évalué à 4.L'objectif est que NFSv4 passe en version 'non expérimentale' dans les version vanilla lorsquelle sera prête pour l'entreprise, c'est à dire lorsque toutes les fonctions NFSv4 de la RFC seront disponibles ET validées, probablement entre mi-juillet 2006 et fin 2006.
Cependant, NFSv4 est d'ores et déjà prête (et utilisée) pour un remplacement de NFSv3, au niveau fonctionnel de NFSv3, (plus exactement : NFSv3, + kerberos, + locking, + delegation, + crash/session recovery).
Au cours de cette année, les principaux distributeurs Linux devraient proposer NFSv4 comme service NFS par défaut. (A confirmer)-
[^]Re: Intégré au noyau
Posté par Sytoka Modon (page perso, ) le 15/01/2006 à 20:49. (lien). Évalué à 2.Il y a à l'heure atuelle (NFSv3) deux trucs "chiants" qui ne marchent pas, à ma connaisssance, sous debian/sarge :
- pas de gestion des acl
- pas de gestion de l'option -ghost par l'automounteur.
Cette dernière option permet de voir les dossiers qui pourrait être automounté dans un repertoire via la commande ls ou via un explorateur de fichier. Pour les débutants qui cliquent dans un explorateur, la non prise en charge de cette option est fatale.-
[^]Re: Intégré au noyau
-
-
-
[^]Re: Intégré au noyau
Posté par TRex () le 16/01/2006 à 10:42. (lien). Évalué à 6.Suse semble avoir commencé à tester NFSv4 pour le livrer dans sa prochaine version de Linux industriel. RedHat devrait bientôt suivre.
Il est à supposer qu'ils vont virer le mot "experimental". Probablement si leurs tests sont positifs.
En tout cas, dès maintenant, il vaut mieux utiliser NFSv4 plutôt que NFSv3 si l'on recherche plus de fiabilité sous stress. De nouveaux tests ont été développés (ACL, Locks) et mis à la disposition des Distributions par l'entre-mise du LTP. Des tests de fiabilité, de stress et d'interopérabilité avec des UNIX (IOZone, FStress, FFSB, Connectathon) sont exécutés sur chaque nouvelle livraison du CITI. Le mode WAN est testé entre Bull et le CITI, et on peut le simuler très facilement en local avec l'outil NetEM, qui est inclus dans les noyaux récents.
Bull a ajouté IPv6 dans le client.
Par contre, NFSv4 n'intègre pas encore toutes les nouvelles fonctionnalités du RFC. La délégation au client est implémentée. Viendront ensuite migration et réplication ... Voir les liens donnés dans l'article.
NFSv4 a aussi été testé sur ia32, x86_64 et PPC, afin de trouver les problèmes liés au 32->64bits et les problèmes Little-Big Endian. De tels portages sont indispensables pour secouer le code source et faire apparaître des problèmes cachés. Des tests d'intéropérabilité sont également exécutés entre ces différentes architectures.
Il y a également une initiative pour que les développeurs et les testeurs de NFSv4 publient dans des conférences importantes en 2006, comme l'OLS'06. En 2005, il n'y avait eu qu'un BOF (réunion rassemblant les personnes réalisant et les personnes intéressées pour utiliser).
De nombreux "Early Adopters" contribuent à tester NFSv4.
En bref, le fond de NFSv4 est bon. Bien mieux que NFSv3. Il reste maintenant à régler tous les petits détails que l'on rencontre quand un produit est utilisé en réel et que les tests automatisés ne peuvent pas faire apparaître.
meme clubic a un article dans son wiki
Cette page a été générée par Templeet en 0.2537s (dont 0.0416 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.