Réseau
local Ethernet
Depuis plus d'un an maintenant que je connais linux, je
n'ai jamais mis le nez dans la partie qui concerne les réseaux. Je sais
qu'un réseau est constitué de plusieurs machines connectées entre elles,
chacune étant identifiable grâce à son adresse
IP (Internet Protocol). Celle-ci peut être fixe, ou alors attribuée
dynamiquement (comme le fait votre fournisseur d'accès internet par exemple).
Depuis quelques semaines, je m'y intéresse, car je voudrais connecter
mon Pentium III 500 Mhz et mon TBird 1000 Mhz dans un réseau local. En
fait, je souhaiterais répartir les charges de calcul de mes rendus Blender.
C'est ce que l'on appelle un cluster (grappe)
: une machine virtuelle très puissante constituée de plusieurs calculateurs
mis en parallèle. C'est la NASA qui a implémenté en premier ce type de
système que l'on appelle cluster BEOWULF.
Mais avant d'en arriver là, il faut commencer par voir
les bases de la technologie réseau. Il faut avant tout bien savoir ce
que l'on veut faire, car tout est possible sous linux : monter un serveur
Web pour héberger votre propre site, un serveur d'application, partager
une imprimante, utiliser une machine comme passerelle internet, ou comme
noeud de calcul dans un cluster. En ce qui me concerne, je dois juste
configurer un réseau local de type ETHERNET (en utilisant le protocole
TCP/IP (Transmission Control Protocol/Internet Protocol)), constitué de
deux machines, leur faire partager une imprimante, et par la suite, installer
et utiliser un programme de calcul parallèle nommé PVM
(Parallel Virtual Machine). Je ne rentrerai donc pas dans les détails
des bases de la technologie réseau, car vous trouverez une documentation
de qualité et très fournie sur le Web : les différents protocoles,
notions de classe de réseau, de serveurs de nom de domaine, d'adresse
de diffusion, etc... Je m'attacherai, comme à l'accoutumée, à décrire
mon expérience de linux en réseau. De plus, si vous avez une Mandrake
8.1, il y a de fortes chances que votre matériel soit directement reconnu,
et que les diverses options par défaut soit suffisantes pour démarrer,
notamment au niveau du noyau, pour lequel je n'ai rien eu à régler.
Avant de connecter physiquement les machines, il faut
récupérer un peu de matériel : une carte réseau type Ethernet par ordinateur,
ainsi qu'un câble croisé à la norme RJ45.
Pour connecter plus de deux ordinateurs, on aura en plus besoin de hubs
ou de switches, ainsi que du câble RJ45 non
croisé. Personnellement, j'ai juste acheté 2 petites cartes réseau
à 104 Frs pièce, très bien adaptées à linux puisqu'elles possèdent le
chipset RealTek 8139, et un câble RJ45 croisé à 30 Frs.
Installation et configuration
Tout le matériel est très bien reconnu par la dernière
Mandrake 8.1. En effet, le chipset 8139 utilise le
module 8139too, fournit avec la distribution.
Le fichier /etc/modules.conf indique bien une ligne : alias
eth0 8139too, et la commande : lsmod
me montre que ce module est bien chargé au démarrage. Pour vérifier, on
peut encore taper : dmesg | grep eth0 qui
nous confirmera la présence d'une interface réseau sur la machine. Si
aucune ligne n'est renvoyée, on saisi alors la commande : ifconfig.
ifconfig est l'un des nombreux programmes présents avec le package
des nettols (ifconfig, netconf, netstat, ping...) ; il sert à configurer
et à activer les cartes réseau. La sortie de cette commande devrait afficher
des informations concernant les interfaces réseau.
Tout d'abord on doit obligatoirement constater la présence
d'un périphérique virtuel loopback, noté
lo, et qui correspond à "l'autotest"
du système. Il permet en effet à l'ordinateur de communiquer avec lui-même.
Son adresse IP est toujours la même : 127.0.0.1.
D'autre part, si une carte réseau est présente et bien reconnue sur votre
ordinateur, il devrait aussi y avoir une ligne débutant par eth0,
qui correspond à la première carte réseau du système (eth1, eth2...pour
les autres). Là, si aucune ligne comportant des adresses IP n'apparaît,
comme pour le périphérique loopback ("inet adr :
127.0.0.1 etc..."), c'est qu'aucune addresse IP n'a été attribuée
à votre carte réseau. Pour la configurer, soit on utilise l'interface
graphique netconf ou le programme
ifconfig.
ifconfig eth0 192.168.0.1 netmask 255.255.255.0
assigne l'addresse IP 192.168.0.1 à la première carte réseau, avec un
netmask de 255.255.255.0. Avec :
192.168.0.1 adresse de l'hôte (la carte réseau)
192.168.0 adresse du réseau (partie commune à toutes
les machines du même réseau)
255.255.255.0 masque de réseau
Si l'on veut se simplifier la vie, on peut utiliser netconf,
qui fonctionne très bien. Il suffit juste de remplir les champs HOSTNAME,
IP adress et Kernel module, sans trop se préoccuper du reste, les options
par défaut étant largement suffisantes pour débuter. Perso, j'ai paramétré
comme suit :
HostName+DomainName : TBIRD.localdomain et PIII500.localdomain
(mes deux machines...)
Alias (très utile) : TBIRD et PIII500 (on on peut prendre
un autre nom que celui utilisé pour le HostName, c'est juste un alias
quoi...)
Adresse IP : 192.168.0.1 et 192.168.0.2
Netmask : 255.255.255.0
Ce sont des valeurs très couramment utilisées pour les
petits réseaux locaux privés. Elles sont enregistrées dans un fichier
ifcfg-eth0, situé dans /etc/sysconfig/network-script,
avec un autre, ifcfg-lo
pour le périphérique loopback).
Leur présence à cet emplacement est requis pour une configuration
dès le démarrage de la machine. Pour que les adresses IP
soient activées dès le démarrage, il faut activer
l'option Manual dans netconf, car
DHCP et BOOTP sont réservés pour l'attribution dynamique
des IP (pas d'adresse IP fixe).
De plus, avec netconf, dans la partie "Misc/Info
about other hosts" (infos sur les autres ordos du réseau), on voit
bien que notre localhost.localdomain correspond à l'adresse 127.0.0.1,
pour l'auto-communication comme décrit plus haut. D'ailleurs, nous allons
réaliser notre premier test de communication avec le programme ping.
Communication
ping 127.0.0.1
teste la communication de la machine avec elle-même. Normalement, on doit
voir défiler indéfiniment une suite de lignes nous décrivant la transmission
de paquets d'information. On interrompt le processus en faisant Ctrl+C,
et on regarde les dernières lignes. Elles nous donnent le nombre de paquets
transmis, de paquets reçus et le pourcentage de paquets perdus, ainsi
que des statistiques de vitesse de communication. Si tout a bien fonctionné,
vous le saurez immédiatement... Le programme ping fonctionne en
boucle sans fin, mais il est possible de lui passer une option pour lui
indiquer le nombre de paquets à transmettre :
ping -cN 127.0.0.1
pour le faire "pinger" N fois. Quand les
deux machines sont configurées, on peut passer à la communication d'ordinateur
à ordinateur. Pour cela on va encore pinger. Depuis mon poste "Tbird",
je tape dans une console : ping -c5 192.168.0.2,
et je devrais voir défiler cinq lignes, tout comme lors de l'autotest,
avec une ligne finale récapitulative. Je peux aussi taper simplement :
ping -c5 PIII500, et j'obtiens le même résultat,
signe que la communication est établie entre les deux ordinateurs.
Depuis l'autre poste (PIII500), si je fais : ping
tbird, j'obtiens le même résultat. Si ça ne marche pas, il faut
vérifier le fichier /etc/hosts (sur
chaque machine...), qui doit contenir l'ensemble des adresses
IP des postes du réseau. Si vous avez opéré avec le programme netconf,
et bien renseigné les différents champs indiqués plus haut, ça
devrait être bon. Mais le cas échéant, il faudra remplir ce fichier "à
la main".
Si vous avez installé les packages
telnet-client et telnet-server sur
chacune des machines, vous aurez la possibilité
de réaliser des connexions distantes. Par exemple, un :
telnet PIII tapé dans un terminal depuis mon poste TBIRD,
me permet de me logger sous un nom d'utilisateur de la machine PIII, puis
je fais un su - pour passer en root. En fait,
on ne peut pas se connecter directement en root, donc il faut faire
ce petit changement. L'invite de mon terminal n'indique plus alors "root@TBIRD:#"
mais" root@PIII:#", qui prouve bien que je contrôle l'autre
bécane. On peut aussi se servir du soft G-Telnet,
qui propose une petite console graphique pour établir ce type de
connexion.
Attention toutefois, ces connexions ne sont pas très
sécurisées, aussi est-il conseillé d'utiliser
OpenSSH, qui permet l'utilisation
de canaux de communication cryptés. De même que pour telnet,
on tape :
ssh tbird pour
se connecter à une machine distante. Il faut bien sûr posséder
un compte sur cette bécane. L'avantage par rapport à telnet,
c'est que l'on peut se logger directement en root, et que les connexions
sont sécurisées, et même cryptées grâce
au fameux code RSA. OpenSSh possède de nombreuses options,
que l'on peut consulter dans les pages man avec : man
ssh.
[ Pour convertir cette page man en
format PS (PostScript), puis PDF imprimable, on fait :
groff -man -Tps /usr/share/cheminverspageman
puis un coup de ps2pdf pour
passer du format ps à pdf, que l'on peut imprimer. Je décris
la manip' car j'ai tourné l'autre jour pour imprimer cette page...
groff est un prog'qui permet d'éditer et de créer des documents
au format des pages man, et il est capable de convertir celles-ci grâce
aux options apppropriées... (Encore plus rapide : man
-t bash > bash.ps, puis ps2pdf bash.ps)
]
Autre manip' intéressante et
utile, le lancement de programmes à distance. Imaginons que je
veuille me faire une petite partie de LBreakout2, depuis mon ordos PIII
(sur lequel ce jeu n'est pas installé), en exportant l'affichage
de l'ordos TBIRD, qui lui, a LBreakout2 installé sur son disque
dur. Ceci est possible car XWindow est un SERVEUR
GRAPHIQUE, qui possède donc des fonctionnalités réseaux
avancées...
Je me connecte donc sur TBIRD depuis
PIII : telnet tbird, ou mieux, ssh
tbird
Puis je tape :
export DISPLAY=192.168.0.1:0.0 avec 192.168.0.1, adresse
IP de PIII (sur lequel je veux jouer au jeu) et 0.0
correspondant au serveur.écran de
TBIRD. La commande indique d'exporter l'affichage de TBIRD (0.0) sur PIII.
Ainsi, si je lance (toujours connecté à TBIRD avec telnet
ou ssh) LBreakout2, j'aurai l'affichage du jeu sur l'écran de l'ordos
PIII.
Partage de fichiers
On dispose de plusieurs possibilités pour avoir
accès aux données d'une bécane distante située
sur un réseau. L'une d'entre elles est SAMBA, qui permet de partager
des fichiers et des imprimantes entre des machines Win et des Linuxbox.
Elle ne sera pas décrite ici (en tout cas pas pour l'instant),
car j'ai expérimenté le système NFS (Network File
System) en premier. Celui-ci permet de visualiser le contenu d'une machine
comme si les données étaient présentes sur votre
propre système. En effet, j'ai 2 bécanes sur mon mini-réseau
local, mais la seconde machine ne dispose ni de lecteur de disquette,
ni de lecteur CDROM. Ce n'est pas grave car NFS est justement là
pour m'aider.
Pour disposer de ces fonctionnalités NFS, il
faut avoir les options nfs activées dans la configuration
du noyau, ce qui est le cas avec les distrib's récentes, et avoir
installé les packages nfs et nfs-utils, présents
par défaut sur la Mandrake 8.1. Ils sont même installés
par défaut, et pour vérifier leur présence, on fait
un : service nfs status dans une console,
qui renvoie une réponse explicite du genre : nfs est en cours
d'exécution... Si nfs n'est pas lancé, il faut le faire
à la main : service nfs start. Pour
qu'il soit lancé dès le démarrage de la bécane,
on peut utiliser ksysv, le programme
permettant d'ajouter/enlever des services au démarrage. Il suffit
de faire glisser le programme nfs de la fenêtre de gauche,
jusque dans l'un des niveaux d'exécution (ici le runlevel 5 pour
le démarrage en mode graphique).
Le fichier important pour cette manip'
est /etc/exports. Il définit en effet
les dossiers qui seront accessibles aux hôtes d'un réseau
donné. Dans mon exemple de réseau local, si je veux accéder
aux répertoire /home de ma machine TBIRD (serveur),
depuis PIII500 (client), je dois configurer
/etc/exports sur TBIRD, ainsi que /etc/fstab sur PIII500. Cela me donne
les lignes suivantes à ajouter dans /etc/exports, sur TBIRD :
/home (rw) *.localdomain
/mnt/cdrom (rw) *.localdomain
qui donne l'accès à toute
machine du réseau localdomain, en mode lecture-écriture
(ro pour lecture seule).
Il faut alors relancer nfs avec
: service nfs restart
et les lignes dans /etc/fsatb sur PIII500
:
tbird:/home /mnt/nfs nfs 0 0
tbird:/mnt/cdrom /mnt/nfs nfs 0 0
avec bien sûr, le dossier /mnt/nfs
à créer dans le répertoire /mnt (sur PIII500)...
Depuis PIII500,
je tape dans une console : mount tbird:/home /mnt/nfs
(il n'est pas nécessaire de mettre l'option
-t nfs de mount, et l'on peut mettre les adresses
IP à la place des alias PIII ou TBIRD), et
magie de linux en réseau, je peux consulter mon dossier /home situé
sur TBIRD. Je peut lire/écrire dans ce dossier, et en guise de
test, je réalise un premier transfert de données d'une bécane
à l'autre, par un simple glisser-déposer entre 2 fenêtres
(l'une me montrant le contenu d'un dossier de "destination"quelconque
sur PIII500, l'autre le contenu de /mnt/nfs/ de
PIII500, qui contient donc l'arborescence de mon /home chez TBIRD
(faut suivre...;-)..!). Encore mieux, je peux visualiser l'activité
réseau grâce à net_monitor, lancé dans
une console. Les pics du graphique m'indiquent qu'il y a bien transfert
de fichiers de TBIRD à PIII500. Enfin je peux constater la présence
de fichiers provenant de TBIRD, dans mon dossier de destination sur PIII500.
Cerise sur le gâteau, on peut
placer des icônes sur KDE pour accéder à des dossiers
distants : il suffit de créer des raccourcis type "CDROM"
pointant sur tbird:/home, avec comme point de montage /mnt/nfs, et le
tour est joué. Je n'ai pas testé avec Supermount,
mais ça devrait fonctionner, en prenant toutefois en compte les
incompatibilités entre Supermount et le noyau 2.4.x...
Rendu parallèle
Comme je l'ai dit plus haut, je souhaite
utiliser la puissance de mes deux machines associées pour mes calculs
de rendu Blender. En effet, ceux-ci sollicitent beaucoup le système,
à cause des différents effets d'animation (ondes, ombres,
mouvements de particules, etc...), et j'ai la possibilité de répartir
la charge de calcul sur les bécanes d'un réseau. Par contre,
je n'utilise pas PVM (Parallel Virtual Machine), comme dit en intro de
cet article, car malgré sa simplicité d'installation, ce
prog nécessite une configuration "manuelle" que je ne
suis pas en mesure de réaliser pour l'instant. De plus, sur le
site de Blender, j'ai trouvé une solution de rendu parallèle
à télécharger. C'est donc cette solution que j'ai
choisi de tester en premier lieu.
Pour cela, il faut les packages de binaires
précompilés NSPR
(librairies Netscape Portable Runtime) ainsi que le prog RENDERD.
La mise en oeuvre est relativement
aisée, même pour un débutant je dirais ( il y a aussi
la possibilité de télécharger les sources à
compiler soit-même, pour ceux qui souhaitent adapter/modifier le
prog'...). Pas besoin de NFS ou autre, juste 2 bécanes minimum,
reliées en réseau.
Il suffit d'extraire l'archive NSPR
en premier. Le dossier d'installation n'a pas grande importance. Un tar
xzvf nspr.tar.gz bien placé, et le tour est joué...
Par contre, l'archive RENDERD doit
être décompactée dans /usr/local. Il y aura
copie des prog's renderd et broker
dans /usr/local/bin. Il faut absolument
que l'éxecutable blender se trouve aussi dans ce répertoire,
au côté de renderd et broker. On le copie donc,
ou bien on fait pointer une variable d'environnement BLENDER vers lui.
On créé alors un nouveau
dossier nommé brokertasks dans /usr/local/bin,
près de nos prog's renderd et broker. Voilà,
c'est quasi-fini. Il faut évidemment faire de même sur toutes
nos machines du réseau.
Pour tester tout ça, on copie
un/des fichier(s) d'animation *.blend dans le dossier /usr/local/bin/brokertasks/.
On ouvre une console, on va dans /usr/local/bin, et on lance le broker
(intermédiaire) sur une seule machine
(ici TBIRD), avec la commande : ./broker
Ensuite, dans une autre console, depuis
/usr/local/bin toujours, on lance : ./renderd sur
toutes les machines ! L'intermédiaire broker gère
les fichiers à traiter en les prenant un par un (par ordre alphabétique)
dans brokertasks, et quelques secondes après, il répartit
la charge de calcul sur tous les ordos du réseau fonctionnant,
avec le renderd lancé.
On peut alors suivre l'évolution
des opérations, avec la sortie des terminaux, qui nous indiquent
que le fichier *.blend a été trouvé, qu'il est accepté,
et que le calcul est lancé. Dans le terminal du second ordinateur,
on voit défiler la liste des images calculées : c'est vraiment
génial ! L'ordos TBIRD calcule les images 1,3,4,5,7,9, pendant
que PIII traite les images 2,6, etc... puis les renvoie dans /render sur
TBIRD, grâce à la connexion réseau. La répartition
du calcul a belle et bien lieu, et je peux vérifier l'activité
réseau avec le prog' net_monitor, qui me montre bien
les transferts de données entre les 2 bécanes. Cette répartition
"réseau" permet un sacré gain de temps : en faisant
calculer une grosse scène lourde en effets d'animation à
TBIRD seul, le résultat met une vingtaine de minutes à sortir.
En utilisant ce procédé, je gagne une dizaine de minutes
facile, ce qui est loin d'être négligeable.
Attention
: le résultat sort dans le dossier /render/ sur TBIRD (le seul
qui ait le broker en action) sous la forme d'une suite d'images au format
désiré (jpeg, targa). Il faut donc
que le fichier *.blend soit configuré pour être rendu dans
ce type de format : si on met un format
de sortie avi.jpg (NB un seul fichier vidéo au format AVI), ça
ne fonctionnera pas, le renderd renverra un message d'erreur. Une
fois un calcul terminé, les prog's restent en attente (daemons),
et dès qu'un nouveau fichier *.blend est copié dans brokertasks,
ils se lancent automatiquement. Une fois le travail effectué, on
retrouve nos fichiers *.blend dans un dossier brokerdone (toujours dans
/usr/local/bin/), qui est créé automatiquement.
On peut alors encoder cette suite d'images
dans le banc de montage de Blender, et sortir l'anim' en avi.raw, avi.jpg,
ou encore utiliser mpeg_encode pour l'avoir en *.mpeg... Je sais
plus où j'ai lu ça : "Linux c'est top, mais Linux en
réseau c'est trop puissant", et bien je vous le promets, c'est
bel et bien vrai !
VNC
Pour le contrôle à distance,
on a vu telnet et ssh, pour se logger en mode console. Il
existe cependant une solution orientée graphique, nommée
VNC, pour Virtual Network Computing. Ce prog' est constitué des
packages vncviewer et vncserver sous Linux. Il permet de
connecter plusieurs types de plateformes entre elles (Win98 et GNU/Linux
pour notre cas), par le biais d'un simple réseau Ethernet (supposé
correctement configuré et fonctionnel bien entendu...).
Entre deux machines linux
:
Installer les packages vncviewer
(pour le client, ici TBIRD) et vncserver (pour le serveur, ici
PIII), livrés avec la Manadrake 8.2. Lancer le serveur sur PIII
avec : vncserver tout simplement.
On doit avoir un message de sortie avec une ligne du type : "New
X Desktop is PIII:3" : notez bien ce
PIII:3, c'est l'identificateur du serveur graphique de PIII qui sera "exporté"
vers TBIRD.
Depuis le client TBIRD on tape alors
la commande : vncviewer PIII:3
et il nous demande le mot de passe de l'utilisateur pour se connecter.
On a alors le serveur X de l'ordos distant (ici PIII) qui s'affiche sur
le client TBIRD. On peut lancer des progs', en fonctions des droits d'utilisateur
dont on dispose, on peut surveiller les machines d'un réseau sans
bouger de place (très pratique pour l'Education Nationale), réaliser
des opérations de maintenance à distance, ou contrôler
des machines via l'Internet, pour les personnes mal intentionnées.
Entre une machine linux et une
Win98 :
Perso, je me suis intéressé
à VNC à cause de mon scanner. En effet, CANON ne participant
pas au développement de pilotes pour mon scanner parallèle,
je me suis dit qu'en le connectant sur ma babasse PIII sous Win98, je
pourrais piloter le tout depuis TBIRD tournant sous Linux... pas con le
gars ;-)) L'expérience a fonctionné à l'école
où je bosse, alors y'a pas de raisons... Et bien, pour y parvenir,
il a d'abord fallu que je résinstalle Win98 sur les 2 machines,
pour remettre à plat le réseau Win98, très lunatique
dans son installation et son fonctionnement, mais j'y suis parvenu.
Sur TBIRD/Linux, je vais encore utiliser
vncviewer, donc rien à toucher.
Sur PIII/Win98, j'installe le prog'
VNC, qui fournit le viewer et le server. Il faut ensuite intégrer
les infos dans la base de registre en allant cliquer sur MenuDémarrer/Programmes/VNC/Install
Registry-truc-machin. Vous pouvez pas vous planter, c'est l'icône
en RUBI-CUBE turquoise, symbole de la base de registre... Vous confirmez
les dialogues-box qui s'ouvrent alors, puis vous lancer VNC en mode "APPL
MODE" en cliquant sur Run WinVNC (Appl Mode). Il est alors demandé
de rentrer un mot de passe pour que les clients puissent se connecter.
Il suffit d'en saisir un et de s'en souvenir...
On retourne sur TBIRD/Linux, et on tape
la commande : vncviewer : il demande
alors le nom d'hôte ou l'adresse IP du serveur PIII ou tape directement
vncviewer piii ou vncviewer
192.168.0.4. Puis on donne le mot de passe,
et il se connecte. Magnifique ! On a le bureau de Win98 dans une fenêtre,
et je peux lancer des scans d'images ou d'autres progs' Win98 tout en
restant sous mon OS adoré. Celui-ci étant vraiment mutli-tâches
et très stable, je peux faire d'autres choses, ce qui n'est malheureusement
pas possible avec ce foutu Windaube... De plus, si je fais l'inverse,
à savoir, lancer le viewer depuis PIII/Win98 et le server sur TBIRD/Linux
(attention, comme dit plus haut, notez bien le New
X Desktop TBIRD:2, par exemple, pour lancer le viewer Win98 avec TBIRD:2
!), j'ai le bureau Linux KDE2 sous mes yeux ébahis. Enfin,
c'est pas l'usage que j'en fais, si je veux du Linux, je connecte directement
en Linux. Ce
qui est vraiment génial dans ce cas, c'est que je n'ai pas à
investir dans un autre scanner, puisque celui-ci fonctionnant en mode
ECP sur le port parallèle de PIII, il tourne assez vite (le mode
ECP sur la carte mère de TBIRD n'est pas supporté).
Mais
comment récupérer mes images me direz-vous, entre Linux
et Win98 ? C'est la suite avec la mise en oeuvre de SAMBA.
SAMBA
Ca fait un moment que je voulais le tester le SAMBA,
mais pas d'occas' alors... Maintenant que je scanne mes images à
distance via le réseau Ethernet, il serait bien de penser à
les rapatrier sous Linux. Et sachant
que VNC ne permet pas la manipulation graphique
de fichiers, par glisser-déposer par exemple, il faut utiliser
un voisinage réseau "mixte" Linux/Win98 comme le prog'
LinNeighbourhood, qui fonctionne sur
la base de SAMBA. Bien sûr, je peux redémarrer
l'un des 2 ordos pour communiquer en Win98/Win98 ou linux/linux, mais
rebooter à chaque fois, c'est pas très pratique, et SAMBA
est relativement simple à mettre en oeuvre.
Ce prog', qui est un soft phare de GNU/Linux, permet
de partager des dossiers entre Linux et Win98, ainsi que des imprimantes,
ce qui se révèle être très utile pour les réseaux
mixtes, et surtout pour leurs administrateurs.
Avec la dernière Mandrake 8.2, Samba est
installé et configuré par défaut. Pour vérifier
qu'il est bien présent et qu'il tourne on tape :
service smb status
qui doit renvoyer deux lignes : smbd in execution... et nmbd
in execution..., preuve que les démons tournent.
Dans le cas contraire il faudra installer le package
samba à la main ou en RPM. Pour tester la config'de SAMBA, il existe
le petit prog' testparm qui renvoie
des infos utiles pour connaître l'état du fichier de configuration.
Le seul truc à régler, c'est le fichier
/etc/samba/smb.conf sous LM8.2
On édite ce fichier et modifie/ajoute les lignes
suivantes :
[global]
workgroup = nom_domaine_Win98
! attention mettre le nom de domaine du réseau
Win98 !
netbios name = TBIRD
netbios : nom hôte en majuscule
interfaces = 192.168.0.5 pour
assurer la détection de la carte Ethernet
security = SHARE
pour le partage sans mot de passe :
ATTENTION si vous êtes connecté à
l'extérieur comme sur le Net, cette option peut permettre à
n'importe qui d'avoir accès à vos dossiers !!
Pour voir les dossiers Linux depuis
Win98, on ajoute une section :
[partages]
path = /home
guest ok = yes
ATTENTION, option dangereuse
read only = yes
ATTENTION, option dangereuse
si elle est mise à "no", car elle permet l'écriture
dans les dossiers concernés
[cdrom]
path = /mnt/cdrom
guest ok = yes
read only = yes
locking = no
Pour la prise en compte de ces changements,
on redémarre SAMBA avec :
service smb restart
Si, depuis Win98, je double-clique
sur mon icône Voisinage Réseau, je dois voir apparaître
les 2 machines PIII, et TBIRD, et dans TBIRD, je dois avoir un dossier
nommé partage, un cdrom, et éventuellement une imprimante.
Pour cette dernière, les options par défaut du fichier smb.cong
sont suffisantes, et permettent de lancer des impressions depuis win98
en passant par la machine linux, c'est vraiment génial, je sais
que je me répète, mais c'est la vérité...!
Enfin pour pouvoir profiter d'un voisinage
réseau analogue à celui de Win98, il suffit d'installer
le soft LinNeighbourhood, qui
permet de monter des dossiers Win98 dans un dossier /mnt/samba par exemple...
Vraiment génial...
Je peux maintenant scanner mes images
depuis Linux, grâce à VNC, puis les copier sans redémarrer,
de mon ordos PIII sous Win98, à TBIRD sous GNU/Linux. Je peux utiliser
mon réseau dans tous les sens, et piloter des progs' à distance,
utiliser NFS pour les partage des fichiers sous Linux, Samba pour les
échanges mixtes.
|