Fichiers et services de partage

Ce module couvre SAMBA et NFS. Les objectifs portent sur quelques implémentations spécifiques tels que les serveurs de fichiers et les partages d'imprimante.

État :

Retour au document principal

Pré-requis

• Niveau LPIC 1

1. Les outils client de Samba

nmblookup trainer-1
querying trainer-1 on 192.168.3.255
192.168.3.101 trainer-1<00>

Samba version 2.2.7a-security-rollup-fix
Service uid gid pid machine
----------------------------------------------
dean      dean dean 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:34:54 2003
IPC$      nobody nogroup 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:34:45 2003
IPC$      nobody nogroup 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:34:53 2003
dean      dean dean 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:35:14 2003
netlogon  dean dean 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:34:54 2003
public    nobody nogroup 3145 drakelap (192.168.3.100) Mon Nov 26 13:35:34 2003
IPC$      nobody nogroup 3106 trainer-1 (192.168.3.101) Mon Nov 26 13:34:54 2003

2. Configurer un serveur SAMBA

Le fichier de configuration de samba est smb.conf souvent présent dans /etc/samba. Dans lequel l'option [global] est présente, avec comme paramètres qui peut être défini tels que WORKGROUP=.

Le serveur SAMBA utilise deux démons appelés nmbd et smbd implémentant respectivement les services NMB et SMB. Les deux démons sont démarrés avec le script rc :

/etc/rc.d/init.d/smb start

Le manager de réseau, le fichier hôtes '''lmhosts'''

Ce fichier est généralement dans le même répertoire que le fichier smb.conf et est lu par nmbd pour résoudre les noms d'hôte NetBIOS. Le contenu du fichier est similaire au fichier /etc/hosts:

10.0.0.20 accounts

Répertoires partagés

Nous allons définir un partage appelé readshare lequel est lisible et un autre appelé rw-share lequel a des permissions en lecture / écriture mais seulement accessible pour l'utilisateur tux:

[readshare]
comment = Read-only Directory
path = /usr/local/news/
guest only = yes
browseable = yes # C'est optionnel


[rw-share]
comment = Read-write Share for tux
path = /usr/local/documents
browseable = yes
guest ok = yes
writeable = yes
valid users = tux

Partage d'imprimantes

Nous avons choisi d'exporter toutes les imprimantes définies avec CUPS sur le serveur Linux. Ce qui suit est la configuration qui permettra ceci:

[global]
printcap name = cups
load printers = yes
printing = cups


# Imprimante sans filtre
[printers]
comment = All Printers defined using CUPS
path = /var/spool/samba
browseable = no
guest ok = yes     # autorise les utilisateurs anonyme 
writable = no
printable = yes
create mode = 0700
#Les pilotes d'imprimantes doivent être présent coté client
print command = lpr-cups -P %p -o raw %s -r

Implémenter WINS avec Samba ?

Sur un réseaux de machine NetBios les noms sont résolus par l'utilisation du service d'information réseau Windows ou WINS.

Les clients peuvent utiliser soit des requêtes d'émissions de noms d'hôte ou être configuré pour utiliser un serveur WINS. Ce serveur permet de réduire la quantité de trafic sur le réseau suite aux émissions.

SAMBA comme serveur WINS

Pour activer WINS dans SAMBA l'option suivante doit être renseigné dans /etc/smb.conf

wins support = yes

Les clients Windows peuvent alors être configurés pour utiliser le serveur SAMBA en tant que serveur WINS.

Serveur WINS secondaire

Un réseau NetBIOS possède généralement un seul serveur WINS. Si un second serveur est configuré alors les serveurs doivent être en mesure de synchroniser leurs informations sur l'hôte. On peut configurer SAMBA pour s'enregistrer sur un réseau existant comme serveur WINS secondaire en lui donnant l'adresse du serveur primaire avec l'option:

wins server = <serveur wins existant>

Serveur SAMBA comme contrôleur de domaine

security = users
domain master = yes
local master
preferred master = yes
domain logon = yes

[netlogon]
path=/var/lib/samba/netlogon
writable = no
public = no

• Informations

  Vous n'avez pas besoin d'avoir un script d'ouverture de session. Ce partage netlogon est quelque chose que le client Windows doit se connecter même si il est vide.

3.Configurer un serveur NFS

Le protocole NFS est conçu pour être portable sur différentes machines, systèmes d'exploitation, les architectures de réseau et les protocoles de transport. Cette portabilité est assurée par l'utilisation de Remote Procedure Call (RPC) primitives construit au sommet d'une représentation externe de données (XDR) (RFC1094 NFS v2)

NFS (Network File System) version 4 est un protocole de système de fichiers distribués qui est le descendant des versions du protocole NFS 2 [RFC1094] et 3 [RFC1813]. Contrairement aux versions antérieures, le protocole NFS version 4 prend en charge l'accès aux fichiers traditionnels tout en intégrant le support de verrouillage de fichier et le protocole de montage

[...]

La version 4 du protocole NFS [...] retient les caractéristiques essentielles des versions précédentes: la conception pour la récupération facile, indépendant des protocoles de transport, systèmes d'exploitation et les systèmes de fichiers, la simplicité, et de bonnes performances "(RFC3010).

Le serveur NFS lance les démons suivant :

rpc.nfsd
rpc.mountd

Ces services sont démarrés avec le service nfs:

/etc/init.d/nfs start/stop/status/restart/reload

En outre rpc.statd est utilisé pour avertir le client lorsque le service NFS est interrompu de façon inattendue , et permet aux clients rpc.lockd de verrouiller des fichiers accessibles sur le serveur.

Ces services sont lancés avec le service nfslock:

/etc/init.d/nfslock start/stop/status/restart

Les programmes utilisant les appels de procédure distante (RPC) utilises des numéros de programme spécifique figurant dans /etc/rpc. Quand un service RPC est lancé, il va préciser à portmap quel numéro de port il utilise ainsi que son numéro de programme.

Les clients RPC se connecte au service portmap, même si il est possible de contourner portmap si le numéro de programme RPC est connu.

Le fichier /etc/exports

Syntaxe :

• Répertoire <Hôte>(<option1,option2,...>) <Hôte>(<option1,...>)

Options commune de /etc/exports :

Mappages utilisateur

Une fois qu' un répertoire distant est monté sur le client en local on pourrait s'attendre que les utilisateurs locaux puisse accéder à leurs fichiers comme si le répertoire aurait été monté localement. Toutefois, ce ne sera que le cas si les UID sur les systèmes locaux et distants correspondent.

NFS est généralement utilisé dans un environnement où les UID sont communs entre le serveur et les clients.

Anonuid et Anongid

Il est possible, en utilisant les options anonuid et anongid d'attribuer un UID unique et anonyme, ou un GID par répertoire exporté. Les utilisateurs montant le partage auront le droits de ce ID anonyme sur le serveur. Par exemple, tout le monde aura accès au partage ci-dessous et héritent du droit de l'utilisateur distant avec l' UID = 150 et GID = 100.

/share      *(rw,anonuid=150,anongid=100)

Root Squashing

Par défaut, l'utilisateur root sur le système client sera mappé à l'utilisateur nobody sur le serveur. Cette option est désactivée dans /etc/exports avec l'option no_root_squash

Enfin, il est possible de cartographier tous les utilisateurs de n'importe quel client avec l'utilisateur nobody avec l'option all_squash.

TCPwrappers

L'outil portmap a été compilé avec libwrap nous donnant la possibilité de contrôle d'accès dans /etc/hosts.allow et /etc/hosts.deny.

strings `which portmap ` |grep hosts.allow

Utilisation de exportfs et nfsstat

La commande exportfs sans argument va afficher tous les repertoires exportés.

L'affichage des statistiques de nfsstat est faite pour le serveur NFS et l'activité client. Les informations sont luent a partir de 2 fichiers :

/proc/net/rpc/nfs Contient les informations au sujet de l'activité client

/proc/net/rpc/nfsd Contient les informations au sujet du serveur NFS

4.Mise en place d'un client NFS

L'outil showmount permet de voire les partages sur un hôte distant, les principales options sont :