Depuis plusieurs mois, nous avons quelques postes de travail sous Linux dans l'entreprise où je travail. Je dois avouer que ça fonctionne plutôt bien après quelques temps d'adaptation et que je suis bien satisfait du résultat de notre déploiement Linux.
La distribution utilisée est Ubuntu en version 7.10 et 8.04 (au départ on a commencé avec la version 7.04). Je parle de plusieurs mois, mais en fait, ça fait pratiquement un an que le premier poste Linux a fait son entrée dans le parc informatique! Avec le temps, quelques autres se sont rajoutés.
Le bogue récurant qu'il restait depuis tout ce temps était l'accès aux partages Samba de différents serveurs de fichiers de l'entreprise. L'environnement de bureau est GNOME et l'accès aux partages réseau se fait donc normalement à l'aide de GnomeVFS ou GVFS, dépendant de la version d'Ubuntu. Autant un que l'autre, c'est instable et pas fiable au pas possible.
Avec GnomeVFS et GVFS, on a souvent le droit au message "Impossible d'afficher le contenu complet de ce répertoire". Un ou quelques rafraîchissements plus tard, le contenu du répertoire s'affiche enfin. Pas bloquant, mais très dérangeant pour l'utilisateur. Un autre problème, l'usager ouvre un fichier (par exemple dans OpenOffice), fait des modifications et tente d'enregistrer. Bang! Fichier non accessible... rien à faire à part un copier/coller dans un autre document pour ne pas perdre les modifications...
GVFS est encore pire. GVFS est tout simplement pas prêt à être intégré dans une distribution "stable". Bien souvent, il refuse tout simplement de monter les partages demandés.
La solution jusqu'à tout récemment était de monter les partages réseau avec des bêtes scripts en utilisant l'utilitaire mount et le module cifs du kernel (paquet smbfs). Bien que fonctionnel sans aucun bogue, c'est pas très pratique étant donné que je dois paramétrer d'avance les partages dont aura besoin l'utilisateur. C'est aussi pas bien adapté à une machine multi-utilisateurs où chaque utilisateur a son propre code d'accès.
Il y a quelques semaines, j'ai donc développé une application bien simple : un frontend graphique à l'utilitaire mount. Avec cette application, j'obtiens donc les avantages de *VFS (accès simple et rapide, sans configuration préalable par un technicien) sans ses bugs.
Mon employeur m'a permis de distribuer cette application sous licence GPLv3 afin d'en faire profiter d'autres à l'extérieur de l'entreprise. Donc, si vous aussi vous avez des problèmes avec l'accès aux partages de fichiers, cette application peut vous être utile !
Plus d'infos et téléchargement : http://www.ti-quebec.com/linux-unix/monter-un-partage-samba-(...)
Journal Monter un partage Samba sous Linux sans utiliser *VFS
14
juin
2008
# Autres solutions
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
http://linuxappfinder.com/package/fusesmb (jamais testé)
Parce que gksudo sur mount, ça revient à leur donner les droits root...
[^] # Re: Autres solutions
Posté par ohmer . Évalué à 2.
Pour le gksudo, les utilisateurs sont déjà membres du groupe admin et ont donc déjà les droits root.
[^] # Re: Autres solutions
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 8.
Si, c'est tout l'intérêt d'utiliser fuse pour monter un kio.
Pour le gksudo, les utilisateurs sont déjà membres du groupe admin et ont donc déjà les droits root.
Arg.
# Pas de VFS
Posté par Guillaume Knispel . Évalué à 7.
Plus sérieusement j'ai toujours detesté les VFS de Gnome / KDE / whatever - j'en ai déjà un dans mon système et j'ai surtout pas envie d'en avoir 50. Vu que ton journal m'apprend que en pratique, le code est tout pourri et ne fonctionne, ça me fait une raison de plus pour les détester.
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 3.
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 2.
[^] # Re: Pas de VFS
Posté par CrEv (site web personnel) . Évalué à 1.
les systèmes de fichiers basés sur fuse s'exécutent justement en espace utilisateur.
Il y a une parti de fuse dans le noyau + une lib en userspace et les systèmes virtuels se basant sur la lib sont donc en userspace (c'est un peu l'avantage principal de fuse).
Au contraire, kio, gvfs, ... sont moins facilement portable puisque dépendent de beaucoup plu de lib.
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 4.
Il y a quelques vagues "portages" (mais il n'y a par exemple rien pour OpenBSD), qui doivent se synchroniser avec l'upstream FUSE à chaque fois.
De plus, FUSE doit obligatoirement être chargé par le noyau. Si l'administrateur n'en veut pas, tu ne pourras rien faire. Si c'est uniquement en espace utilisateur, l'administrateur aura beaucoup plus de mal à t'empêcher. D'ailleurs il y verra peut-être moins d'inconvénients si ça ne touche pas au noyau. (Sans parler d'éventuels problèmes de sécurité)
> Au contraire, kio, gvfs, ... sont moins facilement portable puisque dépendent de beaucoup plu de lib.
Et bien, si ces libs sont bien écrites, elles sont portables sans de grosses difficultés, car elles n'utilisent que des choses standard, donc plutôt portables.
[^] # Re: Pas de VFS
Posté par M . Évalué à 2.
Moais tout les os le suive pas les standard (genre windows).
Et puis le pb avec kio, gvfs, ... c'est que tu ne peut utiliser que des applis specifiques.
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 2.
L'éventuelle couche d'abstraction, doit à mon avis être bien plus fine et moins dérangeante que la totale non-portabilité du code de modules noyaux.
> Et puis le pb avec kio, gvfs, ... c'est que tu ne peut utiliser que des applis specifiques.
Effectivement, il est difficile de faire mieux (à part avec des détournements d'appels systèmes, style LD_PRELOAD) en restant uniquement en espace utilisateur. C'est donc un échange, espace noyau et plus de support des programmes contre espace utilisateur et plus de portabilité. Mais je ne crois pas qu'on débattait de ça.
[^] # Re: Pas de VFS
Posté par M . Évalué à 2.
L'éventuelle couche d'abstraction, doit à mon avis être bien plus fine et moins dérangeante que la totale non-portabilité du code de modules noyaux.
On ne parle pas de porter tous les modules noyaux dans notre cas, mais seulement fuse. Donc si fuse a été écrit de manière portable la couche d'abstraction doit pouvoir etre du même ordre que celle pour abstraire les sockets & co.
D'ailleurs comme dit plus bas, il me semble que fuse a été porté sur d'autre OS.
Effectivement, il est difficile de faire mieux (à part avec des détournements d'appels systèmes, style LD_PRELOAD) en restant uniquement en espace utilisateur.
Ha, et les détournements d'appels systèmes c'est portable ? On fait comment sous windows ?
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 2.
Comme j'ai dit précédemment, le code qui se trouve dans le noyau n'est à mon avis pas souvent portable. Le VFS des *BSD doit être bien différent de celui de Linux ou de celui de Windows. Peut-être même que la différence avec les VFS des micro-noyaux comme Hurd est encore plus grande.
> D'ailleurs comme dit plus bas, il me semble que fuse a été porté sur d'autre OS.
Je l'ai moi-même dit. Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?
> Ha, et les détournements d'appels systèmes c'est portable ?
Je voulais dire que les KIO/etc. sont portables, je ne parlais pas des détournements puisque j'ai dit "moins de support des applications" (implicitement). (Cela dit, c'est possible sous windows avec des "hooks" je crois (mais je n'ai jamais fait))
[^] # Re: Pas de VFS
Posté par liberforce (site web personnel) . Évalué à 2.
Je crois que gvfs passe par FUSE pour permettre cela, mais je vous dis ça de mémoire, je connais très mal les VFS. Voir la conf d'Alex Larson, le principal dev de gvfs lors du GUADEC 2007 (et particulièrement page 28 pour la rétro compatibilité avec le parc d'applis):
http://www.gnome.org/~alexl/presentations/guadec2007-gvfs.pd(...)
[^] # Re: Pas de VFS
Posté par CrEv (site web personnel) . Évalué à 2.
oui il y a une partie dans le noyau (en _standard_ et intégré depuis la version 2.6.14 et on peut le faire marcher sur des 2.4 à partir du 2.4.21).
Il est également disponible sur :
- freebsd
- netbsd
- darwin (macosx)
- windows (en tout cas une partie)
- open solaris
- hurd
Franchement on a vu mieux comme soft peu portable...
pourquoi quelques "vagues" portages ?
Si je ne me trompe, le port pour mac a été réalisé par google. Il y a pire comme vague "portage"...
s'il le manque pour openbsd, tu peu toujours le faire.
Pour ce qui est de se synchroniser avec l'upstream, c'est pas un peu le principe d'un portage ?
> Et bien, si ces libs sont bien écrites, elles sont portables sans de grosses difficultés
oui et _si fuse est bien écrit_ il est portable sans de grosses difficultés
où est la différence ?
Le problème c'est que kio ou autre ne permettent pas à une application de le voir de manière transparente. Donc même si c'est portable ça ne fait pas tout, il faut que les applications comportent de quoi le lire.
Au contraire, avec fuse c'est des systèmes de fichiers, et n'importe quelle application peut l'utiliser.
Si je veux utiliser firefox pour lire un fichier sur un sshfs je peux. Si je veux le faire avec kio/gvfs je ne peux pas (et le coup de ~/.gvfs c'est pas vraiment portable non plus...)
> n'utilisent que des choses standard
fuse n'utilise que des choses standard, le noyau...
[^] # Re: Pas de VFS
Posté par Octabrain . Évalué à 3.
Je répète ce que j'ai répondu plus haut :
Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?
J'ai regardé le code de la partie noyau de FUSE disponible sur SourceForge, et il n'y a pas une ligne de support pour d'autres OS que Linux, que des "linux.h", des appels spécifiques à Linux, etc. Ce n'est absolument pas portable.
Les "portages" en question ont donc dû être réécrits à partir de rien (pour la partie noyau).
Le problème c'est que kio ou autre ne permettent pas à une application de le voir de manière transparente. Donc même si c'est portable ça ne fait pas tout, il faut que les applications comportent de quoi le lire.
J'ai également déjà répondu plus haut : soit on choisit d'écrire un(des) module(s) noyau, qui ne peut pas être écrit de façon portable, mais on supporte toutes les applications, soit on écrit une bibliothèque en espace utilisateur (style KIO), qui ne supporte pas toutes les applications (mais déjà pas mal pour un utilisateur lambda qui se restreindrait à son environnement KDE/GNOME), mais qui peut être largement plus portable qu'un module noyau.
[^] # Re: Pas de VFS
Posté par CrEv (site web personnel) . Évalué à 3.
Mais dans ce cas, pourquoi ne pas prendre fuse par le côté libfuse ?
libfuse est une lib permettant d'écrire des systèmes de fichiers (quand on écrit un système pour fuse on ne touche qu'à libfuse).
libfuse est à mon avis écrite justement pour être portable, pour fonctionner sur pas mal de systèmes.
Après, il faut évidemment sur chaque système écrire le bon backend à libfuse (fuse sous linux, macfuse sous mac, ...) permettant de l'exécuter, mais pourquoi pas avoir un backend kio, un gvfs, ...
Donc oui, finalement je te rejoins sur le fait que fuse (le module) n'est pas fait pour être portable mais libfuse par contre l'est.
Evidemment ça n'en fait pas un système uniquement en espace utilisateur, mais permet tout de même d'avoir des systèmes de fichiers "réels" car je trouve vraiment domage de ne pas l'utiliser pour toutes les applis.
Par exemple, récemment j'ai écris un petit système de fichier virtuel pour digikam : justement pour pouvoir l'utiliser de n'importe où. Ca permet de voir les photos de digikam selon leur arborescence de tag, de faire des recherches ... depuis n'importe quelle appli, que ce soit mon client mail, un navigateur de fichier, un browser, ssh, un montage nfs, .... chose que j'aurais jamais pu faire si j'avais voulu l'écrire avec kio ou gvfs.
Alors oui, ça demande d'avoir libfuse (et donc le module noyau) mais c'est vraiment beaucoup plus puissant !
[^] # Re: Pas de VFS
Posté par windu.2b . Évalué à 3.
Kio étant un sous-projet de KDE, qui se veut justement portable, on peut penser que la portabilité est un point pris en compte lors du développement...
Ce que je dis n'est pas une certitude absolue, car on peut faire du code non-portable en se basant sur du code portable, bien évidemment !
[^] # Re: Pas de VFS
Posté par ckyl . Évalué à 0.
Par ce que si tu ne fais pas que du linux tu l'as dans l'os ? Typiquement fuse et un de ses modules répondaient fonctionellement à nos besoins mais on devait supporter des machines linux et windows.
Du coup on à un beau NFS sur un NAS qui va ramer du cul au lieu d'un joli système de fichier distribué pour les données temporaires plus un SAN pour le stockage permanent.
[^] # Re: Pas de VFS
Posté par 태 (site web personnel) . Évalué à 4.
Menfin, "supporter" les partages windows sous windows, ça ne doit pas être si compliqué que ça, si ? Et fuse a des portages sur autre chose que linux (macosx, freebsd, netbsd).
[^] # Re: Pas de VFS
Posté par ckyl . Évalué à 1.
Typiquement si tu me donnes la possibilité de monter un glusterfs et/ou un hadoop DFS sous linux/mac/windows je serais très content ! J'ai pas suffisamment de temps pour faire le portage windows.
[^] # Re: Pas de VFS
Posté par Nicolas Noirbent . Évalué à 1.
http://en.wikipedia.org/wiki/OpenAFS
http://www.openafs.org/
Distribué, avec un client disponible pour UNIX, Windows et Mac OS X. Après c'est pas forcément évident à mettre en place, mais ça pourrait correspondre à tes besoins.
[^] # Re: Pas de VFS
Posté par ckyl . Évalué à 1.
# nfs
Posté par B16F4RV4RD1N . Évalué à 6.
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: nfs
Posté par ohmer . Évalué à 2.
[^] # Re: nfs
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: nfs
Posté par Psychofox (Mastodon) . Évalué à 5.
cygwin les fournit aussi d'ailleurs...
[^] # Re: nfs
Posté par M . Évalué à 4.
C'est peut etre corrigé avec la derniere version (4).
# pam
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
# smb4k
Posté par Samuel Verschelde (site web personnel) . Évalué à 4.
Si l'application a évolué favorablement, c'est une manière intéressante de s'en sortir à mon avis.
[^] # Re: smb4k
Posté par WH (site web personnel) . Évalué à 1.
# fusesmb
Posté par nookie (site web personnel) . Évalué à 7.
Son utilisation est plus que simple, allez osons le mot simplissime.
fusesmb point/de/montage/
Le point de montage contiendra alors tous les workgroups accessibles, sous forme de dossier. Dans chacun de ses dossiers, un repertoire par machine. Et Pour chaque machine, ses partages. En gros, une exploration du réseau par smb sous forme de système de fichier. La lib FUSE permet de faire tout ça en tant qu'utilisateur. Je trouve ça assez magique, et vous?
Tu pourrais du coup faire des liens symboliques vers des partages assez naturellement pour les organiser comme tu le sens. Il me semble que c'est optimal par rapport à ces machins graphiques lourds, attachés à un bureau, non standards, instables et qui cachent l'arborescence de leur exploration.
J'utilise smbfs et n'ai pas encore eu de problème.
L'idéal selon moi serait tout de même qu'une implémentation d' NFS sorte sur les OS sales... Au dela des arguments tournants autour d'une espèce de liberté à laquelle certains gens bizarres s'attachent tant (sont fous ces gens, y veulent être libres. meua chui libre de choisir entre les softs que me file mon OS sale que je sais pas trop skils y font dedans :) \o/ lol ) , NFS est plus fournit en configuration et plus rapide (subjectivité activée).
Allez un peu de hors sujet à bon entendeur : connaissez vous les autres tours de magie faits grâce à la lib FUSE?
- SSHFS pour monter N'IMPORTE QUEL répertoire d'une machine accessible en ssh.
- ENCFS pour creer des repertoires cryptés et les monter comme des partitions
- PEERFUSE : projet en cours. système de fichier distribué pour faire un système de peer to peer accessible dans un point de montage
</HorsSujet milles_excuses="true">
[^] # Re: fusesmb
Posté par Samuel Verschelde (site web personnel) . Évalué à 1.
$ fusesmb test
fuse: failed to open /dev/fuse: Permission non accordée
[^] # Re: fusesmb
Posté par Samuel Verschelde (site web personnel) . Évalué à 1.
Autre chose : comment ça fonctionne pour les partages non publics ou ceux qui sont protégés par mot de passe ?
[^] # Re: fusesmb
Posté par CrEv (site web personnel) . Évalué à 4.
C'est souvent la politique de base des distribs.
On peut aussi donner les droits à tout le monde comme ceci :
- modifier le fichier udev gérant fuse
avant :
# cat /etc/udev/rules.d/99-fuse.rulesKERNEL=="fuse", NAME="%k",MODE="0660",OWNER="root",GROUP="fuse"
après :
# cat /etc/udev/rules.d/99-fuse.rules
KERNEL=="fuse", NAME="%k", MODE="0666"
- changer les droits sur fusermount
# chmod 4755 /usr/bin/fusermount[^] # Re: fusesmb
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
http://doc.ubuntu-fr.org/fusesmb
# Partage CIFS à mon boulot
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
J'ai gardé Nautilus comme gestionnaire de fichier et c'est par ce dernier que j'accède à differents partages CIFS. Le problème est que depuis le passage à Ubuntu 8.04, en dehors de GNOME, je ne peux accéder à aucune ressource réseau (par SSH, CIFS ou autre) via Nautilus ! Pour contourner ce problème, j'ai écrit deux scripts pour monter et démonter respectivement un partage CIFS. Son utilisation avec Nautilus est simple :
- je clique avec le bouton droit sur le dossier dont le nom est celui du partage et qui se trouve dans le répertoire dont le nom est celui de la machine sur laquelle se trouve la partage,
- je choisis 'ouvrir avec un autre application', puis je précise une application personnalisée qui se trouve être le script de montage. Une fois ceci fait, il apparaîtra toujours parmi les programmes disponibles dans le menu contextuel,
- une fois monté, j'accède au partage.
Je fais de même pour démonter le partage.
Note : tous mes accès distants sont dans un répertoire Media/ dans mon home.
# fstab ?
Posté par benoar . Évalué à 3.
Pour les montages "à la demande", tu peux mettre des options dans le fstab pour que les user puissent le monter.
Et pour les répertoires dépendant des utilisateurs, il y a peut-être moyen de faire ça avec PAM, comme indiqué plus haut.
[^] # Re: fstab ?
Posté par benoar . Évalué à 3.
Avec tous ces nouveaux systèmes (que ce soit samba et ses bizarreries, G(nome)VFS, ...) on en vient à oublier les bons vieux outils qui marchent bien, et on se met à réinventer la roue ! C'est dommage, parce que même si ces outils apportent certaines choses intéressantes, ils en font aussi partir d'autres qui sont bien pratiques.
(Bon, dans notre cas ce serait NFS mais c'est un mauvais exemple, j'ai toujours eu plein de merdes avec, et apparemment pas mal d'autres gens .... ya qu'en entreprise/université avec des vieux gurus barbus que j'ai vu que ça marchait ...)
[^] # Re: fstab ?
Posté par Stéphane Davy . Évalué à 1.
Comme dit plus haut, pam_mount est impeccable pour ça.
[^] # Re: fstab ?
Posté par benoar . Évalué à 2.
[^] # Re: fstab ?
Posté par ohmer . Évalué à 1.
[^] # Re: fstab ?
Posté par benoar . Évalué à 3.
[^] # Re: fstab ?
Posté par ohmer . Évalué à 2.
Le problème est pour les montages ponctuels non définis dans le fstab ou pour se connecter sous un nom d'usager différent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.