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. Si NFSv4 arrive à maturité et est déjà plus stable, fiable, sûr et rapide que NFSv3 sur LAN, certaines fonctions sont toujours en cours de développement :
- 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.
Aller plus loin
- Le projet de référence pour linux (57 clics)
- Fiabilisation du projet (12 clics)
- Guide de migration NFSv3 vers NFSv4 (151 clics)
- Suivi développements client NFS (22 clics)
- Suivi développements serveur NFS (21 clics)
# j'comprends pas...
Posté par Christophe Merlet (site web personnel) . Évalué à 6.
[^] # Re: j'comprends pas...
Posté par Victor . Évalué à 4.
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 (site web personnel) . Évalué à -10.
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 . Évalué à 10.
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 (site web personnel) . Évalué à -2.
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 (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: j'comprends pas...
Posté par Amand Tihon (site web personnel) . Évalué à 4.
Et je le fais tant sous KDE qu'en console avec Midnight Commander.
[^] # Re: j'comprends pas...
Posté par yoho (site web personnel) . Évalué à 10.
[^] # Re: j'comprends pas...
Posté par Christophe Merlet (site web personnel) . Évalué à -3.
[^] # Re: j'comprends pas...
Posté par Amand Tihon (site web personnel) . Évalué à 6.
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 . Évalué à 10.
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 (site web personnel) . Évalué à 10.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: j'comprends pas...
Posté par Sylvain Briole (site web personnel) . Évalué à 6.
[^] # Re: j'comprends pas...
Posté par CS . Évalué à 5.
[^] # Re: j'comprends pas...
Posté par Tzacos . Évalué à 4.
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 B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: j'comprends pas...
Posté par X345 . Évalué à -2.
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 Tzacos . Évalué à 1.
[^] # Re: j'comprends pas...
Posté par X345 . Évalué à -5.
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 (site web personnel) . Évalué à 1.
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...
Posté par Erwann . Évalué à 3.
[^] # Re: j'comprends pas...
Posté par Sami Dalouche . Évalué à 1.
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 (site web personnel) . Évalué à 9.
Mais non, l'informatique, ce n'est pas plein de jargon... :)
[^] # Re: j'comprends pas...
Posté par case42 (site web personnel) . Évalué à 10.
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 . Évalué à -4.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 10.
-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 (site web personnel) . Évalué à -1.
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 GNUtoo . Évalué à -1.
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 lolop (site web personnel) . Évalué à 3.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Numéro d'utiisateur
Posté par Rémi baudruche . Évalué à 9.
Ce sera pareil avec la version 4 ?
[^] # Re: Numéro d'utiisateur
Posté par Victor . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Numéro d'utiisateur
Posté par yoho (site web personnel) . Évalué à 3.
[^] # Re: Numéro d'utiisateur
Posté par Rémi baudruche . Évalué à 1.
[^] # Re: Numéro d'utiisateur
Posté par v_atekor . Évalué à 9.
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 (site web personnel) . Évalué à 4.
- 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 GNUtoo . Évalué à 4.
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 M . Évalué à 2.
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 baudruche . Évalué à 3.
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 . Évalué à 8.
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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 4.
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
Posté par v_atekor . Évalué à 2.
(En réalité les 3 protocoles de sécurité proposés)
[^] # Re: Numéro d'utiisateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 1.
[^] # Re: Numéro d'utiisateur
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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 . Évalué à 1.
[^] # Re: Numéro d'utiisateur
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 0.
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 (site web personnel) . Évalué à 2.
[^] # Re: Numéro d'utiisateur
Posté par Tobu . Évalué à 4.
En fait on peut utiliser Kerberos pour à peu près toutes les taches d'authentification maintenant: se loguer en SSH, se loguer en shell avec PAM, utiliser un proxy socks v5...
# Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonjour sur LAN
Posté par briaeros007 . Évalué à 6.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonjour sur LAN
Posté par Drolez Ludovic . Évalué à 4.
Donc oui, mDNS + NFSv4 est AMHA, une combinaison bien supérieure à Netbios+CIFS.
[^] # Re: Bonjour sur LAN
Posté par Tobu . Évalué à 3.
[^] # Re: Bonjour sur LAN
Posté par gc (site web personnel) . Évalué à 1.
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
Posté par kadreg . Évalué à 5.
[^] # Re: Tiens c'est fiabilisé en france à grenoble
Posté par Anonyme . Évalué à 0.
[^] # Re: Tiens c'est fiabilisé en france à grenoble
Posté par v_atekor . Évalué à 3.
# des infos ?!
Posté par poil oq . Évalué à 2.
si quelqu'un connaît un moyen libre d'accéder à des montages nfs depuis windows xp...
[^] # Re: des infos ?!
Posté par FRLinux (site web personnel) . Évalué à 3.
Steph
[^] # Re: des infos ?!
Posté par poil oq . Évalué à 1.
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
Posté par blackshack . Évalué à 1.
[^] # Re: une question non sur NFS mais en rapport un peu avec le sujet
Posté par v_atekor . Évalué à 1.
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 . Évalué à 1.
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
Posté par korm . Évalué à 3.
[^] # Re: Intégré au noyau
Posté par v_atekor . Évalué à 4.
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 (site web personnel) . Évalué à 2.
- 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
Posté par v_atekor . Évalué à 1.
- Les ACL POSIX
- Les ACL NFSv4 (Compatibles Windows)
La question de l'automonter devrait également être résolue.
[^] # Re: Intégré au noyau
Posté par TRex . Évalué à 6.
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
Posté par Dup (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.