Il y a des logiciels simples à démarrer mais compliqués à peaufiner. À l'inverse, certains logiciels sont difficiles à démarrer mais leur configuration devient, ensuite, aisée. Samba relève un peu des deux. En mode Groupe de travail, il se démarre facilement. Pour en tirer le maximum, il faudra se livrer à une étude minutieuse de ses caractéristiques et comprendre, en finesse, son fonctionnement. En mode Serveur de Domaine, c'est plutôt le démarrage qui est difficile ; ce qui peu surprendre...
Samba est un logiciel libre, largement documenté. J'ai consulté de nombreux tutoriels et "how-to" expliquant comment configurer un serveur Samba. Pourtant, j'ai eu un mal fou à démarrer mon premier serveur de Domaine sous Samba. Les raisons ? La première est que, ne connaissant rien aux réseaux Window$, il ne me servait à rien de savoir comment régler tel ou tel paramètre, n'ayant pas la moindre idée de ce que cela signifiait. La seconde est qu'il existe une foule de détails, insuffisamment documentés ou soulignés, pouvant bloquer le serveur.
Je ne reprendrai donc pas, ici, les explications existant déjà ailleurs. Je commencerai par pointer les "détails" bloquants et renverrait le lecteur à une seconde partie pour l'explication des notions de réseau Window$.
Démarrer un serveur Samba, en mode Groupe de Travail (Workgroup) est relativement simple. Même si on n'arrive pas facilement à obtenir de ce serveur ce que l'on en attend, on arrivera facilement à créer un dossier partagé pour tout le monde, en lecture seule.
Démarrer un serveur Samba en mode Serveur de Domaine est bien plus compliqué. Il arrivera souvent que l'on soit tout proche du but, alors que rien ne marche. On tourne alors en rond, se posant mille questions, rarement les bonnes. Je propose, ici, de commenter les points sur lesquels j'ai le plus bloqué. Il sembleront peut-être secondaires, périphériques, c'est pourtant ceux-là qui m'ont fait perdre le plus temps. C'est souvent le cas... Les choses compliquées sont bien expliquées dans les manuels et on y est attentives. Mais il y a quelques présupposés, des "détails", que l'auteur omet de préciser ou de souligner, nous empêchant ainsi de faire fructifier notre compréhension des choses compliquées.
L'utilisatrice root doit impérativement être l'un des utilisatrices référencées de Samba. Si tel n'est pas le cas, il sera impossible de connecter un ordinateur, un client, au serveur. On se retrouvera dans le situation ubuesque où le serveur Samba est parfaitement fonctionnel, mais aucun ordinateur ne peut s'y connecter.
L'enregistrement de root en tant qu'utilisatrice Samba se fait simplement, avec la commande suivante :
root@linux-box> smbpasswd -a root
Il s'en suit un dialogue permettant de choisir quel sera le mot de passe de root, en tant qu'utilisatrice Samba.
Dans un réseau Window$, un ordinateur client doit être déclaré auprès d'un serveur de domaine, avant de pouvoir utiliser les services qu'il propose. Cette déclaration est une opération implicite, effectué par le client, lorsqu'on le rattache à un domaine.
Au cours du dialogue de rattachement, on va nous demander sous quelle identité on souhaite faire ce rattachement. Cette identité est forcément une identité connue de Samba. S'agissant d'une tâche d'administration (déclaration de machine cliente), elle ne peut être réalisée que par une administratrice Samba. D'où l'importance d'avoir déclaré root comme utilisatrice de Samba.
Cela ne suffit pas... Pour traiter la demande d'enregistrement, Samba va devoir fabriquer une utilisatrice fictive et l'enregistrer dans le fichier Linux des utilisatrices (/etc/passwd). Or, Samba ne peut réaliser cet enregistrement que si on lui a dit comment le faire. C'est le rôle dévolu au paramètre "add machine script" du fichier de configuration de Samba. Ce paramètre ne prenant pas de valeur par défaut, le serveur ne pourra accepter aucune connexion tant qu'on n'aura pas fixé une bonne valeur à ce paramètre ! Voici, à titre d'exemple, une valeur de paramètre ayant fonctionné, pour Samba 3, sur une Ubuntu 6.10 et sur une Mandriva 2006.0 :
add machine script = /usr/sbin/useradd -s /bin/false -d /var/lib/nobody %u
On y déclare simplement que la machine sera enregistrée comme une utilisatrice fictive, c'est-à-dire dépourvue de répertoire personnel et de shell.
Ce paramètre n'est pas une option mais une obligation. Tant qu'il n'est pas renseigné, toute tentative de déclaration d'un client auprès du serveur Samba renverra le message idiot "utilisateur inconnu" qui nous fera croire que les login et mot de passe utilisés pour effectué cette déclaration sont inconnus du serveur ; même si l'on a fait cette demande au nom de root et qu'on a pris soin de déclarer root à Samba !
Par défaut, Samba suppose que les utilisatrices Linux correspondant aux utilisatrices ordinaires de Samba font partie du groupe Linux users. Il conviendra de s'assurer que c'est bien le cas. Certaines distribution Linux ajoutent automatiquement toute nouvelle utilisatrice à ce groupe, d'autres non.
Si cette condition n'est pas vérifiée, il en résultera des dysfonctionnement sur les droits des utilisatrices dont on serait tentée de chercher l'origine dans le fichier de configuration de Samba, alors qu'il n'y est pour rien.
Avant de lancer Samba en tant que Serveur de Domaine, il est souvent conseillé de commencer par le tester en tant que membre d'un Groupe de Travail. Le passage en mode Serveur de Domaine n'étant alors qu'une formalité : le changement de quelques paramètres de la section global du fichier de configuration... Erreur !
Le fonctionnement de Samba en mode Serveur de Domaine suppose la déclaration de deux partages spéciaux : profile et netlogon. On ne peut donc faire l'économie des sections correspondantes, dans le fichier de configuration. À la limite, on pourrait supprimer printers et homes pour ne conserver que global, profile et netlogon. Inutile de vouloir faire fonctionner Samba en mode Serveur de Domaine tant qu'on a pas correctement configuré ces deux sections (se reporter à son manuel préféré).
Tout ça c'est bien gentil, mais où faut-il créer ces répertoires ? Quels sont les fichiers concernés par Samba ? Où serait-il judicieux de les placer ? Y a-t-il une logique particulière qui prime ?
C'est un problème classique auquel il n'existe pas solution générale. Pour faire ses premiers pas en Samba Serveur de Domaine, je suggère l'organisation suivante :
contient les fichiers de configuration du serveurs
contient les fichiers de configuration des utilisatrices et donc les partages spéciaux profile et netlogon
je suggère d'assimiler les utilisatrices Samba, à des utilisatrices Linux ordinaires. Leur home Samba sera donc leur home Linux
les partages ordinaires (dossiers partagés) se trouvent là où ils se trouvent ;-)
Toute personne souhaitant utiliser un ordi sous Window$, doit travailler dans une session. Si l'utilisatrice démarre l'ordi ou si l'utilisatrice précédente à fermé sa session, toute nouvelle arrivante doit ouvrir une session. Pour ce faire, elle doit s'authentifier en déclinant un login et un mot de passe reconnus par le système. Ces deux informations doivent donc avoir été préalablement déclarées au système, lors de la création d'une utilisatrice.
Si on n'éteint jamais l'ordi partagé et si on ne ferme jamais sa session, nulle n'a besoin d'ouvrir une session, puisque tout le monde travaille dans la même session.
Si, lorsqu'on démarre l'ordi, il finit par afficher le bureau sans que l'on ait besoin d'ouvrir une session, cela signifie simplement qu'il ouvre la session d'une utilisatrice prédéfinie.
Je n'ai pas trouvé d'explication satisfaisante de ce que sont, respectivement, un groupe de travail et un domaine.
En revanche, j'ai compris que, dans un groupe de travail, la déclaration et l'authentification des utilisatrices se fait ordi par ordi. Une utilisatrice ne peut ouvrir une session sur un ordi, que si elle a été déclarée sur cet ordi. De plus, n'importe quel ordi relié au réseau peut se déclarer membre d'un groupe de travail. Bien entendu, seul une utilisatrice ayant les privilèges d'administration de cet ordi pourra effectuer l'opération.
Dans un domaine, toute personne déclarée auprès du domaine, pourra ouvrir une session depuis n'importe quel ordi membre du domaine. Mais l'ordi doit, au préalable, avoir été déclaré membre du domaine. Cette déclaration ne peut être faite que par une utilisatrice ayant les privilèges d'administration du domaine. Une simple administratrice de l'ordi se déclarrant n'aura pas ce pouvoir. Une administratice de domaine n'a nul besoin d'être administratrice de l'ordi depuis lequel elle ouvre une session.
Un ordi peut être membre d'un groupe de travail ou d'un domaine, mais pas les deux à la fois.
Si un ordi appartient à domaine, les utilisatrices locales peuvent toujours ouvrir des sessions "locales" tout en accédant à des ressources partagées par d'autres ordis, y compris celles que propose le serveur Samba. L'utilisatrice (locale) devra alors s'authentifier auprès des ordis distants qu'elle contacte.
Le plus souvent, un serveur de domaine Samba joue deux rôles totalement différents. D'un côté il propose au partage des imprimantes et des répertoires. De l'autre, il authentifie les utilisatrices.
Pour bien comprendre cette différence, imaginons un cas extrême, celui d'un serveur Samba où tous[1] les partages (répertoires et imprimantes) seraient librement accessibles à toutes. N'importe quelle utilisatrice ouvrant une session depuis n'importe quel ordi du réseau, membre ou non du domaine, pourrait y accéder. Son ordi n'aurait nul besoin d'être déclaré au serveur de domaine. Elle n'aurait, elle-même, nul besoin d'être connue de ce serveur.
Imaginons, maintenant, que tous les partages soient ouverts aux utilisatrices du domaine et à elles seules. Notre utilisatrice locale pourra toujours accéder à ces partages, à la condition qu'elle connaisse l'identité d'une utilisatrice du domaine et qu'elle se déclare comme telle, pour chaque partage qu'elle souhaite utiliser. En revanche, une utilisatrice du domaine ouvrant une session en tant que telle, aurait automatiquement accès à tous les partages, quel que soit l'ordi depuis lequel elle ouvrirait sa session.
Les utilisatrices peuvent être décrites sur deux plans, totalement différents : leur existence, leurs privilèges.
Sur un ordi Window$ il existe des utilisatrices locales, distantes et déterritorialisées.
Les utilisatrices locales sont celles que l'on a créé à travers le panneau de contrôle de création des utilisatrices. Une session locale, s'ouvre sous l'identité d'une utilisatrice locale.
Si un ordi distant n'offre l'accès à ses ressources qu'à certaines de ses utilisatrices, tout personne souhaitant accéder à ces ressources devra s'identifier, au préalable. De ce fait, chloe sur l'ordi a, pourra accéder aux données de sandra sur l'ordi b, en se déclarant en tant que sandra, lorsquelle accédera aux ressources proposées par b. Dans le cas particulier où deux utilisatrices sont déclarées sur deux ordis, avec les mêmes login et mot de passe, elles seront automatiquement identifiées (sans dialogue) lorsqu'elles voudront accéder aux ressources partagées par l'autre ordi.
Les ressources mises en partage pour tout le monde, ne demanderont pas d'identification. Dans tous les cas, les accès aux ressources distantes sont lancés depuis un ordi où les utilisatrices sont identifiées comme locales.
Au sein d'un Domaine, les utilisatrices ne sont plus locales à un ordi, mais déclarées auprès du Domaine. Elles peuvent donc ouvrir une session depuis tout ordi faisant partie de ce Domaine, sans jamais avoir été déclarées sur cet ordi. Elles accèdent alors aux ressources de l'ordi local, en tant qu'utilisatrices déterritorialisées.
Que se passe-t-il si chloe est déclarée (avec le même mot de passe) en tant qu'utilisatrice locale d'un ordi a et en tant qu'utilisatrice du Domaine DOMSMB, auquel appartient a ? Pour Window$, ces deux utilisatrices sont différentes.
J'imagine qu'il doit être difficile de concevoir un outil de configuration qui satisfasse aussi bien l'utilisatrice occasionnelle que l'administratrice professionnelle... C'est sans doute pour cela que je n'ai pas trouvé d'outil adapté à une novice en Samba. Pour faire simple, il existe deux types d'outils agissant sur la configuration de Samba.
Les premiers, destinés aux utilisatrices Linux finales, manipulent Samba sans le dire. Ainsi, une utilisatrice du bureau Gnome d'Ubuntu se verra proposer la possibilité de partager un dossier quelconque, entre utilisatrices Linux, MacO$ X, Window$ d'un même réseau. Sans le savoir, elle utilisera Samba et n'a pas à se préoccuper de la configuration du serveur. Elle ne sait même pas que son ordi est un serveur Samba...
Les seconds sont des outils d'administration. SWAT et Webmin sont des services accessibles, en réseau, via une interface Web. Il sont donc facilement pilotables depuis un ordi Window$ client qui nous sevirait à tester le fonctionnement du serveur Samba.
SWAT (Samba Web Administration Tool) est un générateur de fichier de configuration de Samba. Il ne traite que de Samba et pas de l'interface avec le système d'exploitation, ni des autres fichiers de configurations (smbusers, etc...).
Lorsqu'on démarre de zéro, SWAT permet de générer un fichier de configuration contenant les principales rubriques que nous aurons à compléter, en fonction du type d'utilisation que nous voulons faire de Samba. Par la suite, SWAT permet d'intervenir sur des sections spécifiques du fichier de configuration. Il peut également tester la conformité de ce fichier, en donner une vue simplifiée et une vue exhaustive (où figurent toutes les valeurs par défaut).
Malgré la simplification apportée, SWAT reste un peu effrayant, lorsqu'on fait ses premiers pas en Samba. Même la vue "simplifiée" affiche de nombreux paramètres dont on ne sait que faire alors qu'il n'y a souvent rien à faire (mais on ne le sait pas)...
Si votre distribution Linux vous propose une paquetage SWAT[2], je recommande la démarche suivante. Utiliser le Wizard pour générer le canevas du fichier de configuration, puis utiliser un autre outil jusqu'au premier test concluant de connexion. Par la suite, on réutilisera SWAT pour adapter et peaufiner un fichier dont est certaines qu'il fonctionne. Plus d'angoisse sur les paramètres "vides" affichés par l'interface SWAT, puisqu'on sait qu'ils ne sont pas vitaux...
L'intérêt du Wizard est qu'il est sensé proposer des valeurs adaptées à votre distribution (emplacement des fichiers et répertoires standards, commandes et backends, etc.).
À vérifier mais il se peut que même un SWAT générique soit susceptible de fournir les bonnes valeurs, par reconnaissance du type de distribution.
Si votre distribution ne propose pas de paquetage SWAT, il est préférable de ne pas ajouter les problèmes d'installation et de configuration d'un SWAT générique à ceux de Samba.
Webmin propose un module pour Samba[3]. Moins pratique que SWAT pour intervenir sur le fichier de configuration principal de Samba, ce module permet néanmoins de toucher à des fichiers connexes (utilisateurs, alias...). On peut aussi, d'un simple clic, arrêter ou redémarrer le serveur Samba.
Dans certaines versions, un sous-module d'édition de texte permet d'intervenir directement sur le fichier de configuration.
Parfois, SWAT apparaît comme un sous-module fictif du module Samba de Webmin. Webmin devient alors un outil complet et souple de configuration de Samba. Si cette option n'apparaît pas dans Webmin alors que SWAT est installé sur votre système, il suffit probablement de configurer le module Samba de Webmin pour lui indiquer où se trouve l'exécutable SWAT.
Enfin, on ne négligera pas la possibilité d'intervention directe, avec un éditeur de texte, sur le fichier de configuration de Samba. Lorsqu'on fait les premiers tests de démarrage du serveur, ce fichier est sensé être aussi dépouillé que possible et donc facile à manipuler.
Dans ce cas, la configuration à distance, depuis le poste Window$ de test, sera plus délicate qu'avec les outils graphiques précédents, pour qui n'est pas familière avec vi ou emacs (à travers un client ssh).
Ne pas manipuler les fichiers de configuration de Samba avec des éditeurs de texte Window$.
Le but de cette section est juste de pointer l'existence de quelques commandes utiles et de suggérer une démarche de test, allant la conformité syntaxique du fichier de configuration au test depuis un client Window$.
Cette commande permet d'effectuer un contrôle du fichier de configuration principal de Samba. De plus elle affiche le contenu de ce fichier, dépouillé de tous ses commentaires.
Cette commande peut devenir centrale si l'on décide d'éditer un fichier "master", abondamment commenté. Le fichier de configuration réel est alors produit grâce à testparm.
On ne retiendra de cette commande très complète que la forme permettant de tester, depuis l'ordi serveur, avec l'application client Samba, les fonctionnalités du serveur Samba, en ignorant d'éventuels problèmes de réseau. On voit ce que verrait un client Samba (ou Window$), s'il était correctement raccordé au réseau local du serveur.
"smbclient -U% -L localhost" affiche les fonctionnalités déclarées publiquement par le serveur.
"nmblookup" est la principale commande permettant de visualiser la présence des ordis et services sur le réseau.
"nmblookup -S <ordi>" affiche l'ensemble des déclarations netbios de l'ordi mentionné. Les services étant identifés par des codes numériques (héxadécimaux), on se reportera à un tableau explicitant la signification des principaux codes. "man nmblookup" vous expliquera tout ce qu'on peut faire de cette commande.
Les commandes suivantes sont à taper dans une fenêtre de terminal (invite de commande) du poste Window$.
Cette commande permet d'afficher les ressources disponibles sur le réseau. Elle permet de vérifier que le serveur Samba est, au minimum, vu comme un système Window$.
Sans paramètres ("NET VIEW"), cette commande affiche les listes des ordis reconnus.
En précisant l'ordi ("NET VIEW \\<ordi>"), elle affiche les partages proposés par cet ordi.
Cette commande affiche en détail les déclarations d'identité et de services des ordis du réseau.
"NBTSTAT -n" affiche les caractéristiques de l'ordi sur lequel elle est tapée.
"NBTSTAT -a <ordi>" affiche les caractéristiques de l'ordi mentionné.
"NBTSTAT" seul affiche les paramètres possibles à cette commande.
Un serveur Samba assurant la fonction de gestionnaire de domaine doit apparaître affublé de la valeur hexadécimale 1C (logon server). On se reportera à un tableau explicitant les codes des principaux services.
Il existe des manuels très sophistiqués et très détaillés qui sont probablement utiles aux administratrices de systèmes professionnels. Tous ceux que j'ai eu en main pèchent par la connaissance des réseaux Window$ qu'ils présupposent et un mode d'exposition où les principes ne sont jamais vraiment expliqués.
Pourtant, un manuel se détache du lot : Samba, installation, mise en oeuvre et administration, de Michel Dutreix, publié chez ENI éditions, dans la collection Ressources Informatiques. Il est moche, il fait "amateur" en comparaison des pavés indigestes qui semblent faire autorité, mais il ne faut pas s'arrêter à ça. L'essentiel y est expliqué et présenté avec pédagogie, sobriété, précision, en français, aussi bien dans la langue que dans le mode d'exposition.
Pour les informations hyper-détaillées, on pourra toujours se reporter avantageusement au how-to officiel.
Comme pour les manuels, le Web regorge d'exemples plus ou moins commentés. Ceux que j'ai consultés présentent, à mes yeux, le défaut de s'éparpiller : exemples incomplets et/ou trop touffus, qui interdisent de saisir l'essentiel.
J'ai néanmoins trouvé un exemple particulièrement réussi. Le fichier de configuration de Samba y est ultra-léger, les interventions sur le système Linux ne sont pas éludées (création de répertoire, droits, etc.) et les explications sont claires et succinctes.
Cet exemple, plus verbeux, présente l'avantage d'être en français.
Si le serveur est protégé par un firewall[4], il faut savoir quels ports ouvrir. Cette section de la documentation française d'Ubuntu les indique et fournit les commandes iptables correspondantes.
Complet mais en anglais, The Unofficial Samba HOWTO, rédigé en 2002, offre une alternative à la documentation officielle. Cela reste un vrai "howto" alors que le howto officiel est aussi indigeste qu'un manuel de référence truffé d'exemples et de commentaires.
Dans le même registre et en anglais, le livre Using Samba est, comme l'indique son titre, organisé autour de problématiques utilisatrice. Chez le même éditeur la deuxième édition de 2003 est plus à jour, mais on regrette un format de mise en ligne moins pratique pour la navigation. Il faut bien vendre les éditions papier... D'ailleurs la troisième édition (2007) n'est pas en ligne ;-)
Si vous ne connaissez rien aux réseaux Window$ et que NetBios vous semble (à juste titre) assez incohérent, je vous recommande la lecture d'un article très instructif et édifiant : Understanding the Network Neighborhood. Je suis archi-nulle en réseaux Window$ et je me rends compte que cela nuit considérablement à l'utilisation que je pourrais être amenée à faire d'un serveur Samba comme serveur principal sur un tel réseau (pas comme un moyen simple de partager quelques ressources dans un réseau hétérogène).
Le site officiel de Samba propose quand même autre chose que le howto qui n'en est pas un et recense et met à jour d'autres ressources.
[1] À l'exception des partages spéciaux netlogon et profile.
[2] Certains distribution le proposent comme un paquetage à part, d'autres l'incluent dans le paquetage Samba.
[3] Selon les distributions, ce module peut être inclus dans le paquetage Webmin ou faire l'objet d'un paquetage spécifique.
[4] Vivement recommandé pour un serveur et impératif sur un portable susceptible d'être raccordé à un réseau local inconnu pour obtenir un accès à internet.