SSHFS - le fork de SSHFS actuellement maintenu

 (github.com/deadbeefsociety)
3 points par GN⁺ 2023-09-06 | 1 commentaires | Partager sur WhatsApp
  • SSHFS permet de monter un système de fichiers distant via SFTP, et comme la plupart des serveurs SSH prennent en charge et activent par défaut l’accès SFTP, il peut être utilisé sans intervention côté serveur
  • Le fork de maintenance deadbeefsociety/sshfs a été archivé, car SSHFS n’est plus abandonné ; la version à utiliser est libfuse/sshfs
  • SSHFS est inclus dans les principales distributions Linux et a un long historique d’utilisation en production sur divers systèmes, mais il n’existe actuellement aucun contributeur actif de façon régulière, et les problèmes connus sont listés dans le bugtracker
  • Le mainteneur actuel continue d’intégrer les pull requests et de publier régulièrement des releases, mais n’a pas la capacité de développement nécessaire en dehors du traitement des problèmes à fort impact ; les signalements de bugs sans pull request ou les problèmes non critiques ont donc de fortes chances de ne pas recevoir de réponse
  • La forme d’exécution de base est sshfs [user@]hostname:[directory] mountpoint, et il est recommandé de l’exécuter en tant qu’utilisateur normal ; le mountpoint doit appartenir à cet utilisateur
    • Si le nom d’utilisateur est omis, le nom d’utilisateur local est utilisé
    • Si le répertoire est omis, le répertoire personnel distant est monté
    • Si un mot de passe est requis, ssh lancé par sshfs demandera ce mot de passe
  • Il est possible de spécifier diverses options SSH, dont -oport=PORT, et pour démonter, utilisez fusermount -u mountpoint sous Linux, et umount mountpoint sous BSD et macOS
  • La compilation nécessite libfuse 3.1.0 ou plus, ou une interface compatible libfuse3, Glib avec les en-têtes de développement, Meson 0.38 ou plus et Ninja ; l’exécution des tests requiert le module Python py.test

À lire aussi

1 commentaires

 
GN⁺ 2023-09-06
Avis de Hacker News

  • Si vous voulez quelque chose qui fonctionne en espace utilisateur et que Emacs vous convient, il y a TRAMP, « Transparent Remote (file) Access, Multiple Protocol » : https://www.gnu.org/software/tramp/
    Je l’utilise souvent pour accéder à des fichiers sur des serveurs depuis mon MacBook Pro.

    • Ce que je préfère avec TRAMP, c’est qu’après avoir fait cd dans un répertoire d’un système distant, on peut faire un cp de fichiers depuis le répertoire de travail courant vers la machine locale ou vers une autre machine distante, et inversement copier depuis le local vers le répertoire de travail distant courant.
      Avant d’utiliser TRAMP, je me connectais en SSH à la machine distante, j’utilisais cd et ls pour trouver l’emplacement où copier, je fermais la session SSH, puis je transférais les fichiers avec scp ou rsync, et la plupart du temps je devais ensuite me reconnecter en SSH.
    • À noter que bon nombre de fonctionnalités d’Emacs, peut-être la plupart voire toutes, fonctionnent de manière transparente avec Tramp. Cela inclut dired, eshell et magit.

  • Intéressant. J’ai toujours pensé que sshfs faisait partie d’OpenSSH, on en apprend tous les jours.
    Le sshfs utilisé dans Slackware semble lui aussi abandonné : https://github.com/libfuse/sshfs
    En lisant la citation du lien, je me demande si ce projet deviendra le « successeur ».

    If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact Nikolaus@rath.org and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
    Je me demande aussi si l’abandon vient de la réorganisation de RHEL, comme ce qui s’est passé avec Bluetooth.

    • Cela semble assez naturel que les mainteneurs d’OpenSSH s’en chargent. Moi aussi, je pensais que c’était un élément central de l’infrastructure SSH sous Linux.

  • Pour info, après avoir utilisé macFUSE + sshfs pendant des années sur Mac, je n’installe désormais plus que l’excellent outil Mountain Duck. Il permet d’accéder à des endpoints SFTP dans le Finder et via des points de montage.
    C’est un très bon logiciel et il m’est indispensable.

    • Je suis redevenu récemment client de rsync.net et, en parcourant la documentation, j’ai été un peu surpris de voir que Fuse/sshfs figure encore parmi les options recommandées pour l’intégration Mac : https://www.rsync.net/resources/howto/mac_sshfs.html
      Il y a quelques mois, cela m’avait poussé à essayer ExpanDrive/StrongSync, et c’est la première fois que j’entends parler de Mountain Duck. J’aime bien Cyberduck. Je compte l’essayer maintenant ; si cela fonctionne bien, ce serait bien de mettre cette page à jour pour les autres. À part ça, je suis un client satisfait.
    • Pour mémoire, macOS dispose désormais de https://www.fuse-t.org/. Cela fonctionne sans extension noyau, en lançant en arrière-plan un serveur NFS local auquel macOS se connecte.
      Une implémentation de sshfs est aussi disponible sur https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste...
    • Moi aussi, j’utilise principalement Mountain Duck. Cela dit, dans VSCode, l’extension Remote SSH de Microsoft aide beaucoup pour travailler sur des dépôts situés dans une VM ou sur une autre machine distante.
      Sur macOS, Libfuse/SSHFS est devenu assez pénible à utiliser depuis quelques années, ce qui m’a aussi poussé vers Mountain Duck.

  • C’est dommage que sshfs ne soit plus maintenu. À l’école, je m’en servais pour éditer du code avec mes nombreux plugins Vim sur des serveurs de calcul distants, sans avoir à y installer tous mes plugins Vim.
    J’ai été surpris de voir à quel point le système fonctionnait de façon fluide.

  • Je pense que SFTP est un bon protocole, mais sous-estimé. Dans certains cas, la mise en miroir bidirectionnelle a plus de sens que la réplication d’une arborescence de fichiers d’un côté vers l’autre.
    Après avoir forké et examiné le code de SSHFS, j’ai rassemblé et maintiens des ressources et réflexions personnelles sur https://hackmd.io/@q/sftp-over-ws

    • SFTP est une nette amélioration par rapport à FTP, mais il reste beaucoup de potentiel inexploité côté serveur, et cela ne se résoudra pas simplement en créant de meilleurs clients.
      Les serveurs OpenSSH et GNU lsh ne proposent tous deux que d’anciennes versions du protocole. Probablement la v2. Ce caractère ancien est un choix délibéré : https://marc.info/?l=openssh-unix-dev&m=168488976013498&w=2

  • La combinaison technique est un peu différente, mais j’utilise depuis un moment NFS sur WireGuard avec pas mal de satisfaction.

    • Quand le canal TCP est réinitialisé, NFS gère la reconnexion plus élégamment, ce qui est un gros avantage.
      Davantage de fonctionnalités de système de fichiers sont également implémentées, si bien que les rapports df reflètent correctement l’utilisation du système de fichiers distant.
      En plus, NFSv4 fournit des « delegations », qui permettent de donner au client le contrôle complet d’un fichier sous forme de bail expirant. Les clients NFS récents disposent aussi de « polite delegations », qui prolongent implicitement la durée du bail.
      SSHFS reste très pratique pour monter quelque chose « vite fait » avec une configuration minimale.
    • Je suis allé dans la direction opposée. L’infrastructure VPN est très stable, mais je suis passé à une approche stockage.
      Après avoir synchronisé mes fichiers avec un utilitaire de stockage DVFS tout simple, je ne suis jamais revenu en arrière. J’aime avoir plusieurs copies un peu partout.
    • Il y a quelques années, je suis passé de sshfs à NFSv4 + WireGuard, et cela fonctionne très bien.

  • Aujourd’hui, quand j’ai besoin des fonctionnalités de sshfs, j’utilise surtout rclone mount. Les performances, la stabilité et les options de cache sont meilleures.

    • Cela dit, rclone ne peut pas écrire au milieu d’un fichier sans transférer le fichier entier. C’est son plus gros problème.
      sshfs peut aussi avoir la même limitation.

  • Malheureusement, ce fork n’a pas l’air très actif. Le dernier commit date de mars, et il n’y a presque aucune activité sur les PR et les issues.
    Je ne miserais pas dessus.

    • Si c’est un projet stable, quel niveau d’activité est-on censé attendre ?
    • Dans la définition « à la JavaScript » de l’« activité », cela consiste à toucher à quelque chose qui fonctionne bien et à le casser.

  • Nautilus, c’est-à-dire l’explorateur de fichiers d’Ubuntu, prend en charge le montage de dossiers SFTP. En interne, il semble utiliser gvfs.
    Comme SFTP utilise une connexion SSH pour le transfert de fichiers, je n’ai pas vu de différence d’interface par rapport à SSHFS.

    • On peut parcourir un endpoint SFTP dans l’interface graphique de Nautilus, mais crée-t-il aussi en même temps un point de montage de système de fichiers utilisable depuis le terminal ?
      Je ne m’en souviens pas bien.

  • Quelqu’un a déjà utilisé rclone ou sshfs avec macFUSE/osxfuse sur Mac OS X ?

    • J’utilise Macfuse pour monter tous mes serveurs comme des dossiers locaux. Ça fonctionne bien.
      J’ai un petit script pour chaque serveur. Par exemple mount_fooserver.sh :
      umount -f ~/mounts/fooserver
      sshfs -o kill_on_unmount,reconnect,allow_other,defer_permissions,direct_io username@server:/ ~/mounts/fooserver -ovolname=foo
    • Sur M1, j’utilise macFUSE et sshfs pour monter le disque d’une machine Linux au bureau. Dans l’ensemble ça va, même s’il y a quelques grincements typiques.
      La configuration a été une vraie aventure, et plusieurs fois je me suis demandé si c’était bien la bonne méthode, mais en persévérant ça a fini par bien marcher.
    • Voir mon commentaire de premier niveau plus haut. La réponse, c’est « Mountain Duck ».
    • Sur Monterey, M1, sshfs fonctionne, mais il est plutôt lent.