Hello tout le monde,
À la demande générale de JoelTheLion, et comme ça peut servir à d'autres, je me propose dans ce journal de décrire la mise en place de répertoires partagés sur un serveur « à la Windows » mais en mieux.
J'utilise SSH comme protocole de transfert de fichier, Avahi pour déclarer les partages et Nautilus ou Dolphin pour y accéder sans taper au clavier.
Pourquoi c'est mieux :
- parce que c'est libre et ne met en œuvre que des technologies ouvertes,
- parce que c'est du pur Unix & KISS,
- parce que c'est sécurisé,
- parce que c'est fiable, même entre distributions très différentes (essayez de partager un dossier entre Seven et Vista, vous aurez envie de vous pendre avec le câble réseau...),
- parce que c'est ergonomique côté client (deux ou trois clics sous GNOME et KDE).
Dans l'ensemble il n'y a rien ni compliqué ni de nouveau, mais ça permet de compiler toutes les commandes et remarques intéressantes en une page, comme ça pas besoin de chercher. Et puis ça peut donner des idées à d'autres.
Bien sûr, Avahi doit être installé et fonctionnel sur les serveurs et clients (un simple « ping server.local » suffit à valider ce point). KDE a besoin de kde-zeroconf, et GNOME utilise GVFS qui prend ça en charge (bien qu'il vaille mieux avoir gvfs-fuse).
Tout d'abord, rien à faire sur le client si ce n'est créer le couple de clef SSH. Il suffira de lancer avec l'utilisateur à autoriser un bête :
$ ssh-keygen -t dsa
La clef publique à récupérer par la suite est ~/.ssh/id_dsa.pub.
Côté serveur, les manipulations sont plus nombreuses.
On créé le répertoire à partager, ainsi qu'un utilisateur qui en sera propriétaire :
# mkdir /srv/share
# useradd -m -c "Share user" user
# chown -R user /srv/share
Pas besoin de mot de passe puisqu'on va utiliser des clefs.
Personnellement, j'utilise scponly qui n'autorise que les connexions SSH via SCP mais pas l'ouverture de shell, sinon il faut utiliser un shell standard, ce qui laisse un risque potentiel. De plus, utiliser /bin/false ou /sbin/nologin empêchent les transferts SFTP.
Pour ce faire :
# chsh -s /usr/bin/scponly user
On autorise les clefs publiques en ajoutant le contenu des ~/.ssh/id_dsa.pub des clients dans le fichier ~/.ssh/authorized_keys sur le serveur.
Ici, on peut déjà vérifier que ça se monte sur les clients, même si ça n'est pas automatique. Sous GNOME, on peut lancer :
$ gvfs-mount sftp://user@server.local
$ gvfs-mount -l
Mount(0): sftp en tant que user sur server.local -> sftp://user@server.local/
Type: GDaemonMount
Si c'est bon, on peut démonter :
$ gvfs-mount -u sftp://user@server.local
(je préfère GNOME entre autres parce qu'on ne peut pas vraiment scripter des trucs comme ça sous KDE, encore que ça doit pouvoir se faire avec Dbus mais ça me semble beaucoup moins évident)
La dernière étape, la déclaration réseau, se fait en créant un fichier .service dans le répertoire /etc/avahi/services, par exemple share.service.
Normalement c'est en XML mais je n'ai pas trouvé comment l'insérer, donc ici c'est avec des crochets :-).
De toute manière il y a des exemples dans /usr/share/doc/avahi-daemon :
[?xml version="1.0" standalone='no'?][!--*-nxml-*--]
[!DOCTYPE service-group SYSTEM "avahi-service.dtd"]
[service-group]
[name replace-wildcards="yes"]Nom du partage sur %h[/name]
[service]
[type]_sftp-ssh._tcp[/type]
[port]22[/port]
[txt-record]path=/srv/share[/txt-record]
[txt-record]u=user[/txt-record]
[/service]
[/service-group]
On y précise donc juste le répertoire et l'utilisateur avec lequel se connecter.
Pas besoin de relancer Avahi, c'est pris en compte immédiatement.
On vérifie que ça se déclare bien sur le client en lançant :
$ avahi-browse -tr _sftp-ssh._tcp
= eth0 IPv4 Partage sur server.local SFTP File Transfer local
hostname = [server.local]
address = [x.x.x.x]
port = [22]
txt = ["u=user" "path=/srv/share/"]
Avec ça, a-priori tout est bon.
On vérifie avec Nautilus ou Dolphin en ouvrant l'URI network:/ .
Sous Nautilus, le partage doit apparaître directement à la racine et en l'ouvrant, il est monté dans ~/.gvfs si on a gvfs-fuse.
Avec Dolphin, il faut descendre dans « Network Services » puis « Remote disk (sftp) » et on doit voir le partage.
Voilà, j'espère avoir clair et utile. En tout cas, chez moi ça marche tout seul : j'utilise ce système quotidiennement et je n'ai plus les problèmes que j'avais avec le couple NFS/Automount (qui notamment ne supportait pas les coupures réseau). Bon c'est plus lent mais ça reste utilisable.
Quelques remarques :
- pour un réseau domestique c'est super (deux ou trois utilisateurs), pour une entreprise il y a certainement des choses à adapter, toutefois ça ne me paraît pas irréaliste,
- pour plus de sécurité, je désactive les connexions SSH par mot de passe, avec
PasswordAuthentication=no
dans /etc/ssh/sshd_config, - comme c'est basé sur SSH et Avahi, il y a de grandes chances que ça fonctionne aussi sous Mac OSX; si quelqu'un peut nous faire un retour, nous en saurions plus,
- en cas de problème au montage, vérifier la configuration SSH et en particulier les permissions de ~/.ssh et de ses fichiers. SSH est très tatillon sur ce point.
# OpenSSH intègre déjà de quoi limiter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
http://formation-debian.via.ecp.fr/ftp.html#id575203
# Merci!
Posté par JoeltheLion (site web personnel) . Évalué à 3.
# Comme c'est complique...
Posté par pasBill pasGates . Évalué à 1.
net share monpartage=c:\repertoire
Ah ouais, ouhlala c'etait super-complique...
[^] # Re: Comme c'est complique...
Posté par DLFP est mort . Évalué à 9.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Comme c'est complique...
Posté par llaxe . Évalué à -2.
[^] # Re: Comme c'est complique...
Posté par zebra3 . Évalué à 3.
J'ai découvert que Seven avait implémenté une nouvelle notion qui est le « réseau résidentiel » qui donne un mot de passe commun à tout le réseau et permet de faciliter les accès aux partages. Une bonne idée, sauf que c'est actif par défaut et que ça empêche les machines hors-Seven d'accèder aux partages. Dans un monde où XP est encore la norme, c'est un peu bloquant...
J'ai fini par trouver une option à décocher pour permettre cet accès, dommage que je ne l'ai pas notée (en même temps, je ne pense pas avoir à le refaire).
Bref aujourd'hui, à moins d'être administrateur Windows ou très bidouilleur, c'est un peu la galère. Qui a dit que Windows était adapté au grand public ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Comme c'est complique...
Posté par yellowiscool . Évalué à -7.
Envoyé depuis mon lapin.
[^] # Re: Comme c'est complique...
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Comme c'est complique...
Posté par yellowiscool . Évalué à -7.
Ah d'accord…
Envoyé depuis mon lapin.
[^] # Re: Comme c'est complique...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Mais heureusement, personne ne le ferait.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Txt record
Posté par anakin . Évalué à 2.
[^] # Re: Txt record
Posté par KiKouN . Évalué à 2.
# Super
Posté par KiKouN . Évalué à 5.
Toutefois, ce serveur ne sera pas allumé en permanence (suspend to ram). Il faudra le réveiller d'abord. La mise en veille sera assuré par un petit service qui regarde s'il y a des connexion ssh active et s'il n'y a pas de jeton à durée limitée d'actif.
Il me reste la partie client à faire. Je ne sais pas trop quelle techniques je vais employer pour cela ou si la technique sera la même entre les machines fixes et les portables.
Je posterai sùrement un journal une fois la plateforme prête.
[^] # Re: Super
Posté par benoar . Évalué à 3.
[^] # Re: Super
Posté par KiKouN . Évalué à 4.
La carte intégrée ne supporte que le mode WOL MagicPacket et ne marche pas en suspend to RAM. Pas bien grave car je comptais utiliser une carte 1Gbit.
Ma carte 1Gbit ne supporte que les modes WOL MagicPacket et activité physique. C'est une carte premier prix. Malheureusement, je suis chez neuf et la box TV envoie des packets en broadcast ce qui réveille de suite le serveur en mode activité physique.
Par contre, je viens de vois que les cartes utilisant le driver 8139too (carte très courante) peuvent supporter plus de modes WOL. Je m'en vais en essayer quelques-unes.
Tant pis pour le 1Gbit. Je pourrais toujours racheter une carte 1Gbit plus tard.Le serveur est pour l'instant de la pure récup.
[^] # Re: Super
Posté par KiKouN . Évalué à 3.
Le problème, pour réveiller le serveur depuis internet, il faut faire les mêmes modifications sur le routeur. Heureusement (dans notre cas), je suis chez SFR mais neufbox en prêt. Je ferai ces modifications si je trouve une neufbox4 d'occassion.
[^] # Re: Super
Posté par KiKouN . Évalué à 2.
La carte intégrée ne supporte que le mode WOL MagicPacket et ne marche pas en suspend to RAM. Pas bien grave car je comptais utiliser une carte 1Gbit.
Ma carte 1Gbit ne supporte que les modes WOL MagicPacket et activité physique. C'est une carte premier prix. Malheureusement, je suis chez neuf et la box TV envoie des packets en broadcast ce qui réveille de suite le serveur en mode activité physique.
Par contre, je viens de vois que les cartes utilisant le driver 8139too (carte très courante) peuvent supporter plus de modes WOL. Je m'en vais en essayer quelques-unes.
Tant pis pour le 1Gbit. Je pourrais toujours racheter une carte 1Gbit plus tard.Le serveur est pour l'instant de la pure récup.
# mDNS et DNS-SD
Posté par Alexis de Lattre (site web personnel) . Évalué à 3.
Sinon, il doit être possible de faire du DNS-SD, ce qui supprime la limitation au sous-réseau. Dans ce cas, la config se fait dans le serveur DNS du domaine, plus besoin d'Avahi.
[^] # Re: mDNS et DNS-SD
Posté par benoar . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.