Contenu | Rechercher | Menus

Annonce

DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 13/08/2020, à 07:28

Qid

NFS vs SSHFS besoin d'explications

Bonjour tout le monde

Prélude :
Mes questionnements du jour sur :
- la différence entre SSHFS et NFS
- le fonctionnement de l'un et de l'autre
viennent d'une discussion amorcée en début d'année dans un autre fil de discussion

J'explique la situation actuelle :
En fait j'utilisais SSHFS pour un partage croisé dans un parc informatique et depuis la réinstallation de ce parc en 20.04 j'ai voulu remettre en place le partage mais cette fois en NFS plutôt qu'en SSHFS car j'ai cru comprendre que le premier était plus adapté...
Du coups je vous expose le plan simplifié du parc :
Ordi A utilisateur principal AUa (administrateur uid=1001)
Ordi B utilisateur principal BUu (simple utilisateur non administrateur uid=1002) et BUa (administrateur uid=1001)

Mon besoin final :
AUa doit pouvoir accéder et modifier le home de BUu
Pendant que BUu doit pouvoir accéder et modifier uniquement un dossier bien précis (DP) dans le home De AUa

Informations complémentaires :
Ua est strictement identique sur les 2 postes : même nom même uid

Mon problème dû à mes incompréhensions de fonctionnement de NFS par rapport à SSHFS :
A l'époque du précédent SSHFS je n'avais qu'un seul et unique utilisateur administrateur sur chaque machine donc pas de soucis mais maintenant ? Pour moi le but du jeu est donc d'avoir accès localement au dossier distant comme si j'étais en local...

Donc dites moi si je me trompe dans l'idée où je reviendrais sur mes pas et ferais ça en sshfs : le fstab de A ferait un sshfs#Uu@B:/home/BUu pendant que celui de B ferait un sshfs#Ua@A:/home/AUa/DP/ sauf que ceci doit se faire automatiquement sans demande de mot de passe (c'est là qu'interviendrait la clef ssh si ma mémoire est bonne)

Parce-que avec NFS après avoir joué avec exports dans la machine distante d'un côté et le fstab local de l'autre j'en suis à cette situation que je ne comprends pas : AUa a bien le droit d'accès au home de BUu et peut écrire dedans sans aucune difficulté et donc sans demande de mot de passe par contre BUu lui ne peut pas écrire... Il ne sait que lire..

Désolé pour le roman mais je me devais d'expliquer tout l'historique de la situation pour que vous puissiez bien comprendre où j'en suis

J'espère que vous pourrez m'aider à tout comprendre
Et à ce sujet je suis même preneur d'une explication sur la viabilité des solutions chmod 777 et/ou chown BUu/1002 (sur la machine A)


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#2 Le 14/08/2020, à 07:01

J5012

Re : NFS vs SSHFS besoin d'explications

nfs : doit être configurée côté serveur (quels disques sont partagés) , et côté client (fstab monte les disques)
sshfs : pas de configuration côté serveur , et côté client pas de montage prealable par fstab

droits d'acces et permissions d'ecriture sont configurables dans les deux contextes (tu avais l'habitude de ssh en root mais tu peux aussi ssh avec des droits limités ...

le gros avantage de sshfs c'est pas de reglages supplementaires autre que l'installation du paquet !

le gros avantage de nfs c'est sa souplesse dans un contexte multi-utilisateurs, multi-ordinateurs etc ... (de grands reseaux *nix et gnulinux l'utilisent)

pour que BUu puisse acceder au home de AUa, il suffit que AUa definisse un utilisateur BUu avec des permissions d'écriture dans un sous-dossier (ca se fait côté serveur nfs)

Hors ligne

#3 Le 14/08/2020, à 07:13

Zakhar

Re : NFS vs SSHFS besoin d'explications

D'un point de vue "technique", NFS est géré côté kernel, c'est LE partage natif Linux.
sshfs est un driver fuse. Donc tout tourne en "userspace", et ça utilise la couche SSH pour simuler l'arborescence de fichiers et les lectures/écritures.

En corollaire, NFS est largement plus performant, d'autant qu'il ne chiffre pas, ce qui n'est pas forcément totalement nécessaire sur un réseau local. Or le simple fait de chiffrer peut casser totalement la performance sur des machines un peu anciennes (comme le PC portable depuis lequel j'écris).

Aussi, NFS en tant que système "kernel" a été pensé à la base pour du "réseau local". Rien n'empêche bien sûr de s'en servir via un tunnel VPN (je le pratique de temps en temps), mais ce n'était pas le "use case" standard.

sshfs tournant en userspace au dessus de SSH n'en a pas grand chose à faire que le ssh soit en réseau local ou à 1000km. La seule différence potentielle sera la performance de transfert.

Côté inconvénients découlant de ces approches différentes, NFS est plus "sensible" pour le reste de la machine. Essayez la chose suivante : montage NFS depuis un client, éteindre le serveur qui partage les fichiers, essayer d'éteindre le client. Eh bien vous allez avoir des time-out trèèèèès long (voire infinis) si aucune précaution n'a été prise, car le shutdown va essayer de démonter le partage NFS, et ne pouvant communiquer avec la serveur (qui a été coupé) va provoquer de longs time-out.

Avec sshfs, comme c'est du "userspace", du moment que la session utilisateur a été coupée, il n'y a plus de problème au shutdown car ça n'a pas d'incidence "kernel".

Dernière modification par Zakhar (Le 14/08/2020, à 07:17)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#4 Le 14/08/2020, à 08:12

Qid

Re : NFS vs SSHFS besoin d'explications

J5012 a écrit :

sshfs : pas de configuration côté serveur , et côté client pas de montage prealable par fstab

[•••]

pour que BUu puisse acceder au home de AUa, il suffit que AUa definisse un utilisateur BUu avec des permissions d'écriture dans un sous-dossier (ca se fait côté serveur nfs)

Un montage SSHFS peut tout-à-fait être renseigné dans le fstab... C'était la config que j'avais...

Et donc j'en déduis avec la seconde partie cité de ton message que NFS manque de souplesse car comme c'est effectivement dit partout je ne peux l'utiliser comme il faut que si mes droits uuid sont strictement identique sur chaque machine... Ce qui n'est pas le cas... Finalement le problème que je rencontre avec NFS c'est que je n'arrive pas à forcer le montage avec le bon user pour avoir les bons droits sur le dossier d'arrivée

@Zakhar : l'argument du shutdown ne devrait pas se poser dans mon cas mais c'est un élément qui crains vraiment je trouve...

La discussion reste ouverte mais je pense que je vais vraiment démonté ce qu'on a déjà fait en NFS pour revenir à SSHFS qui me semble beaucoup plus souple


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#5 Le 14/08/2020, à 08:31

J5012

Re : NFS vs SSHFS besoin d'explications

oui mais non pour nfs : souplesse dans un contexte multi utilisateurs, mais si voux n'etes que deux clients, c'est certain c'est lourd !

le serveur nfs doit connaître à l'avance les utilisateurs autorisés sur les disques partagés, et le montage fstab côté client se réalise non pas directement dans le dossier auquel accede l'utilisateur autorisé, mais depuis un dossier general à partir duquel l'utilisateur autorisé trouvera son chemin vers son espace personnel....

dans le contexte de sshfs, utiliser fstab perd tout l'intérêt d'avoir un acces en espace utilisateur (le FS de sshfs, c'est fuse via le protocole vfs, systeme de fichiers virtuel de gnulinux) comme quand tu piques une clé usb et que tu y accedes de suite sans la faire prealablement fstaber !... (une vrai galere ca ... y a eu une epoque où c'etait le chaos)

Hors ligne

#6 Le 14/08/2020, à 09:29

Zakhar

Re : NFS vs SSHFS besoin d'explications

Comme NFS est "kernel" la gestion des droits est effectivement indispensable... et souvent une vraie galère. Il existe certes des possibilités de "mapping", mais ça reste "pieds au mur".

sshfs, comme tout module "fuse" travaille avec les droits de l'utilisateur qui a fait le montage... sauf si tu le lances en root ce que je déconseille largement (je suis aussi l'auteur de plusieurs drivers fuse !)
La "bonne façon" de monter automatiquement un partage via sshfs est de le mettre dans le "démarrage de session". Ainsi le montage est fait avec les droits de l'utilisateur.
Dans le /etc/fstab, la seule façon "propre" pour éviter le montage en root, est de préciser noauto,user dans les options.
Mais dans ce cas là, le montage n'est pas actif tout de suite au démarrage.
L'utilisateur qui veut se servir du partage doit "faire un clic" (nautilus ou autre) qui déclenchera automatiquement le montage. Selon les cas d'usage la solution /etc/fstab avec noauto,user ou le démarrage en session sont à privilégier.

Après, franchement, le seul avantage (potentiellement) décisif que je voie à NFS est ce que j'ai cité plus haut : la performance.

Je suis actuellement sur un PC portable qui tourne avec un core i7... d'une des premières générations !.. Cela veut dire une machine d'une bonne douzaine d'année puisque ses premières versions Ubuntu étaient la 8.04
Malgré le corei7, sur mes partages fuse (1fichierfs - ma propre création fuse), je plafonne à 50Mo/s en lecture à cause du chiffrement TLS.
Sur mon PC de bureau plus récent, je sature largement la fibre et l'ethernet 1Gbps en tournant à des pointes de 110Mo/s... ce qui m'a d'ailleurs permis de faire corriger un grave bug à Free (version de firmware 4.2.1, je vous la conseille si vous ne l'avez pas encore).

Même quand on tourne au maximum de la vitesse, un montage fuse reste moins efficace que NFS car on passe pas mal de temps à faire des copies kernel/userspace, malgré sans doute les optimisations "splicing" qu'a dû faire sshfs (ça reste à faire dans mes drivers).
Donc même si tu ne vois pas de différence de performance parce que la machine est "assez rapide", tu as des différences d'efficacité, c'est à dire consommation de plus de ressources pour la même tâche de copie réseau.

Outre la plus grande consommation électrique, cette moindre efficacité peut se manifester lorsque la machine devient très chargée par d'autres tâches.

Mais à mon sens c'est vraiment le seul avantage qui mérite de se pencher sur NFS.

En conclusion, si
- les machines client sont "assez rapides" (pour que le goulot d'étranglement ne soit pas le chiffrement)
- le serveur est "assez rapide" (pour chiffrer pour le compte de tous les clients)
- les clients et le serveur sont très rarement en "surcharge CPU"

... reste en sshfs.

Dans le cas contraire NFS peut se justifier.

... par contre évite vraiment le montage en root dans le /etc/fstab, je t'ai donné les alternatives "bonnes pratiques" ci-dessus selon ton cas d'usage.

Dernière modification par Zakhar (Le 14/08/2020, à 09:33)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#7 Le 14/08/2020, à 10:18

Qid

Re : NFS vs SSHFS besoin d'explications

J5012 a écrit :

oui mais non pour nfs : souplesse dans un contexte multi utilisateurs, mais si voux n'etes que deux clients, c'est certain c'est lourd !

le serveur nfs doit connaître à l'avance les utilisateurs autorisés sur les disques partagés, et le montage fstab côté client se réalise non pas directement dans le dossier auquel accede l'utilisateur autorisé, mais depuis un dossier general à partir duquel l'utilisateur autorisé trouvera son chemin vers son espace personnel....

dans le contexte de sshfs, utiliser fstab perd tout l'intérêt d'avoir un acces en espace utilisateur (le FS de sshfs, c'est fuse via le protocole vfs, systeme de fichiers virtuel de gnulinux) comme quand tu piques une clé usb et que tu y accedes de suite sans la faire prealablement fstaber !... (une vrai galere ca ... y a eu une epoque où c'etait le chaos)

En fait pour répondre à ton premier paragraphe dans mon plan tout le monde est client et serveur car on parle d'un accès croisé... En réalité la config complète c'est :
- 2 machines simple utilisateur B1 et B2 qui n'accèdent qu'à un dossier bien précis du home de A1Ua
- 2 machines administratrices du parc A1 et A2 qui elles doivent avoir accès au home de chacune des autres machines
Le but étant que tous les fichiers soient bien stocké sur A1 et non ailleurs avec la possibilité pour les 2A de faire le rangement à distance...

Par contre il me vient une idée qui simplifierait peut-être les choses grâce à NFS : est-ce que A1 ne pourrait pas stocker la totalité de tous les home de chaque machines ?

Je n'ai pas bien compris ton second paragraphe

Quant au 3ieme je suis d'accord avec toi mais en fait l'un n'empêche pas l'autre...

@Zakhar : j'aime bien ton idée de montage via le profil user et non via le fstab... Je ne savais pas que c'était possible... Ça résoudrait mes problèmes de montage non désiré dans une autre machine multi-usages/multi-compte dont je n'ai pas encore parlé pour l'instant... Mais pour ces 4 là je ne vois pas l'intérêt car il n'y a réellement qu'une session qui sert physiquement : BUa n'existe en réalité que pour faciliter l'administration à distance via ssh

J'avoue ne pas avoir encore lu le reste du message car trop long sur mobile... Je verrai ça plus tard de mon ordi


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#8 Le 14/08/2020, à 10:32

Zakhar

Re : NFS vs SSHFS besoin d'explications

Qid a écrit :

@Zakhar : j'aime bien ton idée de montage via le profil user et non via le fstab... Je ne savais pas que c'était possible... Ça résoudrait mes problèmes de montage non désiré dans une autre machine multi-usages/multi-compte dont je n'ai pas encore parlé pour l'instant... Mais pour ces 4 là je ne vois pas l'intérêt car il n'y a réellement qu'une session qui sert physiquement : BUa n'existe en réalité que pour faciliter l'administration à distance via ssh

J'avoue ne pas avoir encore lu le reste du message car trop long sur mobile... Je verrai ça plus tard de mon ordi

Pourquoi évite-t-on les montages fuse en root : question de sécurité !

Par construction, fuse ouvre une plus grande "surface d'attaque", mais tant qu'on se limite à faire le montage "user" (et qu'on n'a pas autorisé dans la configuration globale de fuse les root et other) les dégâts supplémentaires potentiels sont limités aux fichiers auquel l'utilisateur peut accéder.

Montage fuse en root = pwned (potentiellement bien sûr)

Ce n'est effectivement "pas plus compliqué" de mettre ça dans le démarrage de session. D'autant plus si, comme tu le dis, il n'y a qu'un utilisateur par machine, les deux choses sont en fait équivalentes en terme de complexité.
Le "démarrage en session" est en fait même bien plus souple, car tu peux par exemple démarrer un script qui fera le montage, et peut donc aussi faire tout ce qu'un script peut faire.

Je procède ainsi sur cette machine :
Démarrage de session :

Nom : Montage 1fichier et Secure
Commande : /bin/sh /mnt/Data/Scripts/1fichier_secure.sh
Commentaire : Montage pour user 1000 du cloud storage.
$ cat ~/Scripts/1fichier_secure.sh 
#! /bin/sh
if ! mount | grep -q 1fichierfs; then
	mount  /home/zakhar/1fichier
fi
if ! mount | grep -q encfs; then
	ENCFS6_CONFIG=/home/zakhar/.config/.1fichier_encfs6.xml  encfs /home/zakhar/1fichier/.crypt/ /home/zakhar/Secure/ --extpass="/usr/bin/secret-tool lookup encfs passwd"
fi

Donc comme tu le vois, le démarrage de session en l'occurrence fait 2 montages fuse de mon "cloud storage".
-1) il monte le cloud storage lui-même (1fichierfs)
-2) Il monte par dessus la partie chiffrée de ce cloud storage

Le montage est réalisé conditionnellement s'il n'est pas déjà actif (ce qui permet de relancer le script en cours de session si un des deux montages a planté).

Comme tu le constates, le script ci-dessus monte le "cloud storage" en invoquant juste mount.
En réalité j'ai combiné les deux approches, le /etc/fstab contient pour ce montage :

$ grep 1fichier /etc/fstab
1fichierfs /home/zakhar/1fichier fuse ipv4,api-key=@/home/zakhar/.1fichier.key,refresh-file=\!000_refresh.txt,stat-file=.stats,cacert=/home/zakhar/1fichier_ca.pem,no-ssl=/.crypt/,uid=1000,gid=1000,log-level=7,log-file=/tmp/debug.txt,ftp-user=1fichierfs-zakhar-laptop,user,noauto 0 0

Il faut surtout noter que la ligne dans le /etc/fstab se termine par : user,noauto

Si le montage ne s'est pas fait au démarrage de session (par exemple machine démarrée sans réseau : c'est un portable, donc ça arrive !), on pourra alors le faire "par clic" via Nautilus une fois un réseau connecté.
Outre cette fonctionnalité supplémentaire, cela simplifie la commande de montage dans le script/démarrage de session à un simple mount.

Dernière modification par Zakhar (Le 14/08/2020, à 10:39)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#9 Le 14/08/2020, à 11:09

Qid

Re : NFS vs SSHFS besoin d'explications

heu... ça y est vous m'avez perdu...
déjà je reviens là-dessus :

Zakhar a écrit :

évite vraiment le montage en root dans le /etc/fstab

même avec ton dernier post je ne comprend pas cette remarque : dans mon fstab soit :
- en sshfs : sshfs#user@ip:/home/user/dossier
- en nfs (dixit la doc nfs) : 192.168.0.10:/<Dossier_à_partager>/ /media/NFS nfs defaults,user,auto,noatime,bg 0 0
par contre en recopiant cette dernière ligne je me demande si j'ai pas merdé à ce niveau : en plus de l'ip il faut que je précise l'user il me semble !?


je crois bien que mon problème de fond c'est que je commence à voir les limites de ma compréhension et de l'utilisation des droits système sous linux... parce que au final moi il y a un truc qui me perturbe : c'est de savoir comment plusieurs utilisateurs peuvent écrire dans un dossier sans fiche le bazar (j'entend par là que je ne veux pas me retrouver avec un dossier dans lequel des fichiers appartiennent pour certains à un user et pour d'autres à d'autres... en fait c'est ça mon problème de fond et c'est bien pour ça que j'essaye d'arriver de ma machine avec compte utilisateur non administrateur de sa machine sur l'autre machine pour écrire mais ceci bien avec le compte de l'utilisateur local et non avec l'utilisateur distant... d'ailleurs dans l'autre sens ça a bien marché et c'est pour ça que je ne comprend plus rien : pourquoi en nfs AUa arrive à écrire chez BUu et pourquoi BUu lui avec les même règles croisée d'export et de montage ne pourrait pas y arriver ?


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#10 Le 14/08/2020, à 23:15

Zakhar

Re : NFS vs SSHFS besoin d'explications

Oui, il va falloir que tu regardes un peu comment se comporte un montage fuse !

Il faut savoir que ce tu vois au travers d'un driver fuse est une arborescence de fichiers qui peut être totalement simulée. L'exemple pour apprendre fuse, le fameux "hello" est un driver qui présente une arborescence contenant un seul fichier (hello) lequel contient le texte "Hello World!". C'est donc totalement virtuel !

Quant aux droits que tu observes, un driver fuse est totalement différent de l'habituel POSIX.
Seul l'utilisateur qui fait le montage a le droit de lire/écrire les fichiers dans le montage fuse (même pas root !... sauf option explicite de montage)
Les droits que tu vois s'afficher via un driver fuse sont totalement simulés par le driver qui fait absolument comme ça lui chante... bien qu'en général on essaye d'être logique quand on écrit un driver fuse !..
En théorie, même quand le driver fuse expose que l'utilisateur n'a pas le droit de lire ou écrire un fichier, rien n'empêche que l'utilisateur puisse néanmoins le faire !.. Cependant un driver qui serait codé ainsi apporterait un brin de confusion.

Ca redevient un peu plus "normal" si tu fais le montage fuse avec l'option -o default_permissions. Dans ce cas le kernel va regarder les permissions exposées et si l'accès demandé est interdit, c'est lui qui répond sans même appeler le driver.

Comme en dehors de l'option "-o default_permissions" un driver fuse peut faire à peut près n'importe quoi malgré les droits affichés, la limitation au seul user qui a fait le montage est intentionnelle pour "limiter les dégâts".

Le problème est donc, si tu fais le montage sans noauto,use dans /etc/fstab, celui qui fait le montage est root.
Par conséquent, à cause de la règle de fuse, seul root va pouvoir utiliser le montage... ce qui n'est sans doute pas ce que tu veux pour tes utilisateurs.
Donc très probablement, pour que tes utilisateurs puissent utiliser le montage qui a été lancé dans le /etc/fstab, tu as dû mettre l'option -o allow_other

Et là avec ça le problème est que n'importe qui peut faire n'importe quoi sur le montage. Comme en plus tu vas écrire sur une autre machine, si un de tes PC est compromis, même avec un user limité du genre www-data (si tu as un serveur web), c'est le régal !..

C'est bien la raison pour laquelle on préfère monter avec le user, pour éviter ce genre de compromission qui pourrait se répandre à ce que permet ton driver fuse.

A la limite tu peux monter avec le user en précisant -o allow_root si tu en as besoin (par exemple faire d'autres montages root par dessus le sshfs). Ca c'est moins grave, parce que si de toute façon c'est root qui est compromis, c'est game over...

Comme je n'ai jamais utilisé sshfs, je ne sais pas ce qu'il expose comme droit et comment il gère les choses. A toi de fouiller la chose !


Avec NFS la gestion des droits est toute autre, c'est du POSIX strict puisque géré par le kernel. La grosse difficulté est la correspondance des UID !
En principe c'est plus facile avec NFS 4 qui peut passer les noms d'utilisateur sous forme de chaîne de caractère et faire le bon mapping.

Donc si tu as
- Machine Bob : User Bob = 1000 (par défaut sur Ubuntu) + User Alice = 1001
- Machine Alice : User Alice = 1000 (par défaut sur Ubuntu) + User Bob = 1001

En NFS 3, sans options spécial Alice va lire/écrire sur la machine Bob en tant que 1000, et donc avec l'identité de Bob... pas cool !

En NFS 4 et en activant les bons services, pour peu que les users existent sur chaque machine, les fichiers seront créés avec le bon user.


Après ce n'est peut-être pas ce que tu veux effectivement... tu veux plutôt faire comme le NFS 3, c'est à dire que tout le monde écrive chez tout le monde en user 1000 (puisque tu dis qu'il n'y qu'un user par machine).
Si c'est bien ça que tu veux faire... tu forces en NFS 3 et ça devrait être automatique, et sans complexité de mapping aucune si chacun utiliser le user 1000 !.. (en fait même 1000/1000, valeurs par défaut Debian/Ubuntu).

Dernière modification par Zakhar (Le 14/08/2020, à 23:19)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#11 Le 15/08/2020, à 08:27

Qid

Re : NFS vs SSHFS besoin d'explications

Le montage SSHFS se fait comme on fait une connexion ssh... C'est pour ça que je suis bien plus certain de mon coup en matière de gestion de droit... Et aussi parce-que j'appelle bien un user de la machine serveur...

Avec NFS j'ai plutôt l'impression que ce sont les utilisateurs locaux qui doivent se faire une place pour accéder au serveur... Et c'est bien ça qui me pose souci : je ne veux/peux pas avoir la même structure d'user sur toutes mes machines... Ou plus exactement je n'en vois pas l'intérêt autre que pour ce satané montage...


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#12 Le 16/08/2020, à 19:18

Zakhar

Re : NFS vs SSHFS besoin d'explications

Comme je te le dis, si tu ne fais que du "User 1000", c'est à dire 1 seul user par machine, en fait NFS 3 fera juste ça, et ça a l'avantage de la performance.

Avec sshfs, le serveur écrit sans doute (forcément !) avec le user avec lequel tu t'es connecté, donc tout est cohérent par construction quel que soit les users... du moment qu'ils sont sur les deux machines.
J'espère quand même tu ne fais pas du SSH en root, parce que là niveau sécurité c'est mort ! tongue

Ce serait plutôt alors l'équivalent de NFS 4 qui passe les chaînes de caractère des users plutôt que les identifiants numériques, ce qui rend le "mapping" plus logique. Avec NFS 4 (correctement paramétré !) si Alice écrit sur la machine de Bob, elle écrira avec le user Alice (à supposer qu'il existe).


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#13 Le 17/08/2020, à 00:51

Qid

Re : NFS vs SSHFS besoin d'explications

Pour rappel et c'est aussi un peu pour ça que je ne comprends rien à tes remarques sur Root mais par défaut ce dernier n'existe pas en temps que user sur Ubuntu... Enfin bref...

En tous cas je me demande si je n'ai pas un souci dans les besoins d'interprétation des uuid par les systèmes justement... Oui j'aurais bien aimé pouvoir garder NFS mais j'ai le pressentiment que je n'arrive pas à lui faire comprendre mes besoins de jonglage d'user... Au moin avec SSHFS c'est clair...


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#14 Le 17/08/2020, à 09:06

Zakhar

Re : NFS vs SSHFS besoin d'explications

Qid a écrit :

Pour rappel et c'est aussi un peu pour ça que je ne comprends rien à tes remarques sur Root mais par défaut ce dernier n'existe pas en temps que user sur Ubuntu... Enfin bref...

Oui, je vois ce que tu ne comprends pas !..

Ce qui est formellement NON recommandé est

sudo sshfs toto@192.168.0.100 /montage

Là tu fais un montage en root sur le client et tu utilises un "compte normal" sur le serveur : sur le serveur ce n'est pas root qui lit et écrit.

Effectivement, tu as raison, root existe bien sur Ubuntu mais n'a juste pas de mot de passe. Donc si tu essayais

sshfs root@192.168.0.100 /montage

Tu aurais un problème pour entrer le mot de passe... puisqu'il n'y en a pas.

Je parle donc bien du montage sshfs en root côté client (en fait en sudo), c'est ça qui est "moche" car pour l'utiliser tu es obligé de changer la configuration fuse pour autoriser cela, et de mettre allow_other en option, sinon seul root peut accéder au montage côté client, ce qui n'est probablement pas ce que tu souhaites.

A noter que si tu fais le montage dans /etc/fstab, cela revient bien à un "sudo sshfs" car au moment où les montages /etc/fstab sont exécutés, c'est bien root qui est aux commandes.

Par contre, si tu fais comme je le suggère, le montage au "démarrage de session", là le montage est fait avec l'UID/GID de l'utilisateur, et tu n'as plus besoin d'ouvrir la configuration de fuse ou de allow_other.

Dernière modification par Zakhar (Le 17/08/2020, à 09:08)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#15 Le 17/08/2020, à 09:32

Qid

Re : NFS vs SSHFS besoin d'explications

Je ne suis pas sûr d'avoir bien saisi ce que tu dis ou plutôt je me demande si tu ne causes pas plus ou moins dans le vide avec tes recommandations qui sont très certainement déjà appliquées mais j'avoue que ça me perturbe... D'autant que tant qu'on est en manuel on a le choix par contre une fois dans le fstab... Là c'est forcément Root

Zakhar a écrit :

Par contre, si tu fais comme je le suggère, le montage au "démarrage de session", là le montage est fait avec l'UID/GID de l'utilisateur, et tu n'as plus besoin d'ouvrir la configuration de fuse ou de allow_other.

J'aimerais bien que tu m'en dises plus là dessus du coup...

Enfin tout ça ne répond pas à mon questionnement de base... D'autant que là tu me parles de SSHFS alors que tu m'as quand-même recommandé de rester avec NFS...


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#16 Le 17/08/2020, à 17:39

Zakhar

Re : NFS vs SSHFS besoin d'explications

Pour ne pas tourner en rond, il faudrait que tu nous mettes la commande exacte que tu utilises pour ton montage sshfs, ou ce que tu as mis dans le /etc/fstab. Sinon effectivement on mouline dans le vide ! big_smile


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#17 Le 17/08/2020, à 17:51

Qid

Re : NFS vs SSHFS besoin d'explications

Zakhar a écrit :

Pour ne pas tourner en rond, il faudrait que tu nous mettes la commande exacte que tu utilises pour ton montage sshfs, ou ce que tu as mis dans le /etc/fstab. Sinon effectivement on mouline dans le vide ! big_smile

bah... pour le sshfs je dois pouvoir vous retrouver ça sur l'ancienne version 16.04 du poste principal qui est resté sur l'ancien disque car la 20.04 a été installée sur un ssd neuf
quant au nfs je vous donnerais l'export d'un poste et le fstab correspondant
et quant à faire je vous donnerais les 2 sens : celui qui marche et celui qui ne marche pas

mais bon ce que j'aurais aimé c'est avoir une explication générale du truc
j'ai eu des bribes mais est-ce que ça me suffit à comprendre... pas sûr...

bon normalement j'aurais de nouveau le parc entre les mains certainement mercredi ou demains
donc je vous donnerais tout ça à ce moment là... ce qui ne nous empêche pas de continuer la discussion pour me préparer avant wink


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#18 Le 17/08/2020, à 19:23

kholo

Re : NFS vs SSHFS besoin d'explications

salut,
d'abord désolé mais je ne me lancerai pas dans qq recherche que ce soit ni pour NFS, ni SSHFS...
ceci simplement parce que j'ai cherché un truc simple pour faire du réseau...
parce que ça me prend la tête et que je suis peut être trop fainéant...
j'ai choisi sftp... ça marche... " et pis c'est tout..."
je n'avais qu'un seul soucis c'était l'accès un peu trop ouvert à la racine du serveur...
il aura fallut que j'attende ces derniers jours pour avoir une astuce donnée par Adrien D de Linuxtricks : chroot
donc je partage l'info et le lien...
vidéo avec explication et démonstration
PS : j'en fini par penser moi même que je fais du prosélytisme avec sftp alors je vais arrêter... je me fatigue moi même
je mettrai à jour mes fils qui en parlent et ça ira bien...
et je plussoie l'idée que tout est mieux que SAMBA !!

Hors ligne

#19 Le 17/08/2020, à 20:21

Qid

Re : NFS vs SSHFS besoin d'explications

Ouais je suis preneur d'autres idées aussi pourquoi pas... Mais de là à passer par du FTP... Pour moi ce protocole était plutôt fait pour du transfert distant de fichiers... Dans un réseau local ça ne me semble pas vraiment adapté... Et puis un peu lourd à mettre en place aussi non ? Moi aussi je suis Adrien sur youtube mais je ne me souviens pas avoir vu passer cette vidéo... Je regarderai ça


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#20 Le 18/08/2020, à 10:31

kholo

Re : NFS vs SSHFS besoin d'explications

alors ftp est installé par défaut sur presque toutes les distributions...
là c'est du ftp dans un tunnel ssh donc SFTP...
j'aime pour plusieurs raisons :
c'est simple, portable, reconnu de partout et ça se monte comme une unité (MS traine un peu mais filezilla fait le job)
on peut se connecter sur un serveur pour mettre à jour un site internet également (je m'en sert aussi comme ça !)

pour Ubuntu et bien d'autres distributions, une ligne me suffit :

sudo apt install openssh-server

ensuite pour se connecter avec un gestionnaire de fichiers (ctrl + L pour faire afficher la barre du chemin):

sftp://utilisateur@IPSERVEUR/point/de/montage

on peut mettre ça aussi depuis "connexion à un serveur"
par exemple :

sftp://toto@192.168.1.10/home/toto

ensuite je garde dans les favoris de nautilus avec ctrl + D !!!
je ne parle pas des petits trucs et astuces que je détaille de partout sur ce forum exemple ici... 2013 c'est pas d'hier !!!

Adrien ajoute des subtilités pour la sécurité mais qui sont optionnelles sur un réseau local peu ouvert... (enfin... pour le moment...)

Hors ligne

#21 Le 18/08/2020, à 11:26

Qid

Re : NFS vs SSHFS besoin d'explications

Ouais... Ok je vois le genre... Mais du coups c'est quoi la différence entre sftp et sshfs ?


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#22 Le 19/08/2020, à 14:33

J5012

Re : NFS vs SSHFS besoin d'explications

ce sont les protocoles : protocole ssh, protocole ftp+ssl/tls voir leurs docs respectives ....

et nfs a aussi un protocole : protocole nfs , (comme smb est celui de cifs/samba)
nfs n'est pas assez souple pour ton utilisation actuelle, à savoir tous tes ordi sont serveurs et clients en meme temp...

nfs suppose (dans une configuration normale) :
- un gros serveur faisant office de serveur de comptes utilisateurs (bien que cette fonction est deportée en general quand il y a plus de 100 utilisateurs) et d'espace d'hebergement (l'espace de stockage des donnees utilisateurs)
- plusieurs clients desktop, workstation, ou meme clients legers, cas pratique d'à peu près toutes les universités
- un ou plusieurs administrateurs ne gerant que le serveur nfs
- le partage public d'un espace déja monté coté serveur, avec differents sous-dossiers correspondant soit à une activité publique par exemple "jeux", à une activité reglementée comme "comptabilité", soit à des comptes utilisateurs.
- quand un client se connecte sur le reseau du serveur nfs, ce qu'il voit dans son espace de fichiers est directement le partage déja monté du serveur nfs, mais le client le voit via son propre protocole Fuse (dans ubuntu il s'agira de gnome-vfs), un cache des ces fichiers est créé dans le sous-dossier ".gvfs" du home du client.
- grâce aux droits d'acces et permissions du compte utilisateur, le client n'accedera qu'à son dossier : dans nautilus il verra toute l'arborescence du serveur nfs (l'espace déja monté), il clique sur son dossier, il verra une demande "nom d'utilisateur" , "mot de passe" , le serveur nfs ne suppose jamais qu'il connaît l'utilisateur distant à l'avance (comme dans une configuration poste à poste microsoft) ... la documentation nfs est vraiment à lire (on sait tous que c nul mais tres utile)

ca peut t'aider de jouer à nfs avec l'application webmin (prend en compte ssh)

Dernière modification par J5012 (Le 19/08/2020, à 14:36)

Hors ligne

#23 Le 19/08/2020, à 14:37

Qid

Re : NFS vs SSHFS besoin d'explications

Qid a écrit :
Zakhar a écrit :

Pour ne pas tourner en rond, il faudrait que tu nous mettes la commande exacte que tu utilises pour ton montage sshfs, ou ce que tu as mis dans le /etc/fstab. Sinon effectivement on mouline dans le vide ! big_smile

bah... pour le sshfs je dois pouvoir vous retrouver ça sur l'ancienne version 16.04 du poste principal qui est resté sur l'ancien disque car la 20.04 a été installée sur un ssd neuf
quant au nfs je vous donnerais l'export d'un poste et le fstab correspondant
et quant à faire je vous donnerais les 2 sens : celui qui marche et celui qui ne marche pas

bon...
sshfs qui fonctionnait entre les deux postes administrateur en monosession sur une 16.04 à l'époque :

sshfs#animateur@192.168.0.101:/home/animateur   /media/PARCINFO/ANIMATEUR-2     fuse    port=22,user,noatime,allow_other,_netdev        0 0

et nfs sur fstab du même poste en 20.04 vers un poste public (situation opérationnelle à priori)...

192.168.0.102:/home/adherent /mnt/ADHERENT1 nfs defaults,user,auto,noatime,bg 0 0

sachant que l'export de l'autre côté est :

/home/adherent 192.168.0.0/24(rw,all_squash,anonuid=1002,anongid=1002,sync)

sachant que 1002=adherent


et donc en sens inverse (qui ne marche pas car je n'ai pas les droits en écriture) :
le fstab du post 102

192.168.0.100:/home/animateur/DOCUMENTS\040ADHERENTS /mnt/DOCADHERENT nfs defaults,user,auto,noatime,bg 0 0

avec l'export :

/home/animateur/DOCUMENTS\040ADHERENTS 192.168.0.0/24(rw,all_squash,anonuid=1002,anongid=1002,sync)

sachant que 1002=aucun utilisateur connu sur la machine
je rectifie donc en 1001=animateur


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#24 Le 19/08/2020, à 14:46

Qid

Re : NFS vs SSHFS besoin d'explications

J5012 a écrit :

nfs n'est pas assez souple pour ton utilisation actuelle, à savoir tous tes ordi sont serveurs et clients en meme temp...

je veux bien le croire...

J5012 a écrit :

nfs suppose (dans une configuration normale) :
- un gros serveur faisant office de serveur de comptes utilisateurs (bien que cette fonction est deportée en general quand il y a plus de 100 utilisateurs) et d'espace d'hebergement (l'espace de stockage des donnees utilisateurs)
- plusieurs clients desktop, workstation, ou meme clients legers, cas pratique d'à peu près toutes les universités
- un ou plusieurs administrateurs ne gerant que le serveur nfs

c'est sûr ce dernier point qu'il y a un défaut effectivement car même si j'aimerais que tout le monde soit responsabilisé et ne stock pas sur les client je veux quand-même que les animateurs puisse aller vérifier que justement il n'y a pas de bourde de stockage de faite
mais d'où mon autre idée d'organisation de tout ça qui serait de stocker tous les /home de tous les postes sur une seule machine... ce ne serait pas plus facile à gérer ? par contre en toute logique j'entends bien la dépendance aux aléas du réseau local mais bon... je m’interroge quand même


"GNU/Linux c'est que du bon mais M$ Windows ce n'est pas si mal"
Référent technique d'un Groupe d'Utilisateur du Libre
plus d'info sur mon profil

Hors ligne

#25 Le 19/08/2020, à 15:08

J5012

Re : NFS vs SSHFS besoin d'explications

@qid : je te lis et je comprend que tu n'as pas eu d'experiences multi-utilisateurs multi-administrateurs :

- dans un reseau nfs, tous les administrateurs ne sont pas "root", il y a ce qu'on appelle des responsabilités graduelles et partagés ...

- Si on prend ton exemple de prof pouvant verifier etc ..., il suffit de leur donner davantage de droits d'acces ou et de creer des groupes (et en general le groupe utilisateur n'est pas le seul groupe utilisateurs, ubuntu cree ton compte utilisateur dans le groupe du meme nom, mais il aurait pu creer ton compte dans le groupe "users" ...

- Par exemple, tu crées le groupe "profs" avec des droits d'acces sur les groupes "lyceens" et "collegiens" , tous les utilisateurs des groupes "lyceens" et "collegiens" pourront être lus par les utilisateurs du groupe "profs" mais aussi par les utilisateurs du groupe "admin" ainsi que par root ou tout utilisateur ayant les droits pour sudo (là aussi tu peux affiner les droits d'acces et d'execution)...

Hors ligne