Migrer de Windows NT4 à Linux Samba Domain Controller

Site perso Florin Grosu
Migrer de Windows NT4 à Linux Samba Domain Controller
Soumis par Florin Grosu
06-02-2008
Dernière mise à jour : 12-02-2009
Cet article ne m'appartiens pas, il est aujourd'hui disponible sur le site linux-france.org. Je l'ai copié pour ne pas le
perdre, au cas où il ne serait plus disponible. Tous les droits d'auteur restent inchangés. Merci Fabrice Clerc.
 Migrer de Windows à Linux:
Du rêve à la réalité.
Méthode par l'exemple
pour migrer le serveur Microsoft d'une PME
Â
Quel passionné de Linux travaillant sur un système Microsoft n'a pas rêvé de tout "envoyer bouler" pour mettre du
Linux à la place?
Le marché des PME est réputé être le plus difficile à approcher pour les logiciels libres. En province, le problème est
certainement plus criant qu'en région parisienne.
Dans cette jungle où des responsables informatiques préfèrent pouvoir rejeter la faute sur les bugs de Windows, plutôt
que remettre leurs compétences en question, celui de la société GAIA-CONVERTER à Bordeaux a osé: il a remplacé
l'unique serveur NT4 de l'entreprise par un serveur Samba sous Debian Linux.
Ayant eu le privilège de travailler à ses côtés, je vais vous expliquer comment nous avons procédé, en espérant que
cette expérience pourra servir à d'autres.
Que les techniciens "jusqu'au-boutistes" me pardonnent, cet article n'est pas entièrement technique. Que les
débutants me pardonnent aussi, il y a aura peut-être des passages difficiles ; la compréhension sera plus aisée pour
ceux d'entre vous qui ont déjà une expérience de Samba. J'espère que vous en dégagerez les grands axes et les
erreurs à ne pas commettre pour votre propre migration.
Il est tout à fait possible pour de meilleurs techniciens de faire un paramétrage plus fin et plus élégant que celui proposé
au fil du document; de la même manière, certaines bidouilles pouvaient être évitées. Certaines choses sont
documentées, mais nous les avons trouvées trop tard, d'autres n'ont pas fonctionné, et nous avons contourné le
problème...  ...ce document ne peut être dogmatique, je le sais.
Préambule
La situation de départ - Dans le cas qui nous occupe, la société à migrer possède une trentaine de postes sous
Windows 9x, une station Windows 2000 Pro qui sert de banc de test, le contrôleur de domaine sous NT4 serveur
(l'unique serveur NT), et un serveur de base de données Informix. L'architecture réseau est très simple, plusieurs postes
sont sur un réseau 10Mb/s, d'autres en 100Mb/s, mais le serveur lui a une seule carte réseau 10Mb/s.
- Le serveur d'origine comporte 3 disques: 1 pour le système et des dossiers d'installation, et deux pour les fichiers
utilisateurs et les fichiers communs aux différents services, ainsi qu'un lecteur de sauvegarde d'environ 8Go.
- Le serveur de destination est composé de: un processeur Pentium III 1Ghz, 256 Mo de mémoire vive, baie de 3
disques SCSI 10.000trs/mn en RAID 5 d'un volume de 36Go. Les disques ne sont pas en hot-plug. La distribution est
une Debian Woody 3.0, installée avec un noyau 2.4.18 recompilé. Debian a été sélectionné pour des raisons de facil
de mise à jour sur le long terme. Le serveur NT s'appelle SRVNT, et le serveur Linux SRVLINUX.
La situation souhaitée à l'arrivée Le serveur NT doit pouvoir être débranché du réseau et ne servir éventuellement
récupérer des fichiers sur d'anciennes sauvegardes.
Le serveur Linux doit faire office de Contrôleur Principal de Domaine, serveur de fichier, serveur d'impression, serveur
de sauvegardes.
La migration doit impérativement être sans douleur pour les utilisateurs. Il s'agit d'un site industriel. Il suffit d'une panne
de trois heures pour que l'on frôle la catastrophe.
Avantages et problèmes prévisibles - Il faut modifier les logins utilisateurs qui sont en casse mixte, et vérifier qu'aucun
accent ne traîne.
- Un ou deux logiciels fonctionnant avec des bases de données propriétaires et non modifiables se connectent
exclusivement à un nom NetBIOS appelé SRVNT, il faudra donc veiller à ce qu'elles retrouvent leurs petits même après
la déconnexion du serveur NT.
- Les ACLs ne sont pas utilisées au niveau du serveur NT, et ne le seront pas sur le serveur Linux, pas plus que les
quotas de disque.
- Les utilisateurs ont un lecteur réseau pour leur répertoire personnel, et d'autres correspondant à leur service ou aux
ressources communes à l'entreprise.
- Les imprimantes sont compatibles PCL5 ou postscript.
Stratégie adoptée 1) Préparation du serveur hors site (ça m'a permis de le préparer chez moi en dehors de mes
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
heures de travail, au calme).
2) Intégration de Samba au domaine NT grâce à Winbind, et migration des fichiers communs aux différents services.
3) Correction et modification du paramétrage des partages en fonction des problèmes rencontrés.
4) Migration des fichiers utilisateurs, des scripts de connexion, création des comptes en local sur le serveur.
5) Débranchement du serveur NT, et promotion du serveur Linux en contrôleur du domaine, test de connexion des
clients.
Le commencement
La machine
La machine sélectionnée n'a pas besoin d'être terriblement puissante, puisque le gros du travail sera effectué par la
carte RAID. Pas besoin non plus de beaucoup de mémoire. D'ailleurs après un mois d'exploitation, il n'y a toujours pas
un seul octet de swap utilisé, malgré l'utilisation de l'interface X.
L'une des seules grosses difficultés est la mise en place des outils de reporting de la carte RAID. Ils sont développés
pour Red-Hat, et je n'ai pas trouvé de sources compilables pour mettre sur Debian (seul le pilote de reporting s'est
recompilé pour s'adapter à un noyau "maison"). J'adapte les scripts fournis pour Red-Hat. Pour faciliter l'administration
de la machine, je mets une interface X qui permet d'exploiter les outils graphiques de la carte RAID, et d'administrer la
machine avec Webmin; ce n'est pas parce qu'on est sous Linux qu'on doit se priver d'outils faciles d'accès. Bref. Ceci
fait, on installe la dernière version de Samba.
Premiers tests Il ne s'agit pas de mettre le serveur en prod pour s'apercevoir que rien ne tourne. Donc nous testons
Samba tout d'abord en tant que contrôleur de domaine, puis en tant que serveur membre. Cela permet d'affiner le fichier
de paramétrage. On commente et décommente les sections concernées en suivant les fonctionnalités recherchées. J
teste avec un client Windows 2000 et un client Windows XP (ce que j'ai sous la main sur le moment).
La fonction de serveur membre fonctionne immédiatement en suivant à la lettre la procédure du Samba-HOWTOcollection.
En revanche, la fonction de contrôleur du domaine permet de se rendre compte de certains ajustements à faire. Par
exemple, nous n'avons pas réussi à utiliser les homes (net use w: /home) sans utiliser les profils errants. Comme nous ne
voulions absolument pas de ces derniers, nous avons décidé de désactiver les deux. Pour ce faire, il faut modifier le
fichier smb.conf comme ceci:
logon home =
logon path =
Les imprimantes réseau Impossible d'attendre le dernier moment pour migrer les imprimantes réseau. Imaginez qu'une
fois le CPD Windows débranché, on se rende compte qu'il n'est pas possible de faire fonctionner ces imprimantes pour
une raison ou une autre. Les comptes sont déjà migrés, les utilisateurs ont leurs fichiers sur le nouveau serveur, et ils ne
peuvent pas imprimer... Â ...c'est la catastrophe.
Pour cette raison, la première chose que nous décidons de tester juste après Samba, c'est la possibilité de migrer les
imprimantes. CUPS a été installé à l'avance, Samba a été paramétré pour faire tourner CUPS. A notre grande sur
nous ajoutons les imprimantes dans CUPS, et en 5 minutes, tout fonctionne: nous pouvons imprimer depuis le serveur.
Le CD "rescue" Ça n'a pas grand chose à voir avec Samba, mais dans le cahier des charges nous avons défini qu'il
devait être possible d'accéder au serveur depuis un CD "rescue". Bien sûr, nous aurions pu utiliser le CD Debian, ou un
CD Red-Hat ou Mandrake. Nous décidons de faire plus souple. Une fois le serveur complètement fonctionnel, nous
faisons notre propre CD de boot du serveur lui-même. Nous installons le paquetage bootcd, et en moins d'une heure,
nous avons le système installé (et tous les outils dont nous pouvons rêver en cas de problème) sur notre CD. Quand
un volume RAID est grillé ou quand le serveur est volé, on est bien content d'avoir un CD de récupération très complet,
avec les petits outils dont on a l'habitude pour redescendre les bandes de sauvegarde le plus vite possible. Il n'est pas
forcément agréable de se rendre compte qu'on n'a pas l'outil de partitionnement adéquat ou l'éditeur de texte dont on a
l'habitude, dans ces moments où les heures sont vraiment comptées. Le CD nous a d'ailleurs servi une fois alors que le
serveur redémarrait en boucle, à cause d'un démon d'onduleur mal paramétré. Je ne sais pas si Knopix ferait l'affaire...
Debut de la migration
Petite migration entre amis. Ce n'est pas parce qu'on travaille qu'on doit s'ennuyer. Le café et les bières sont là le
samedi après-midi où les choses sérieuses commencent.
Le fichier smb.conf a été conçu hors site de manière à faire tourner la machine comme serveur membre du domaine.
Nous faisons donc la jonction au domaine NT, grâce à la commande smbpasswd -j. Tout se passe bien, et en toute
confiance, on redémarre smbd et nmbd, mais rien à faire, il est impossible d'y accéder depuis le voisinage réseau.
Grommellage et ronchonage sont les deux mamelles de l'informatique, nous râlons donc, et au bout de 10 minutes, ça
fonctionne. Nous avions oublié de démarrer le démon winbindd.
Pour comprendre à quoi sert Winbind, et son rôle dans la fonction de serveur membre d'un domaine NT, je vous invite Ã
lire la petite explication à la fin du document, le Winbind-Howto, ou la partie concernée de l'article sur Samba et les ACLs
dans le Linux Mag 46.
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
Ça imprime!
Comme prévu, nous commençons par tester les imprimantes. Le paramétrage pour Samba n'est pas trop violent:
#gestion des imprimantes
printcap name = CUPS
printing = CUPS
load printers = yes
Et comme le but premier est de permettre l'impression et pas de la restreindre, nous permettons à tout le monde
d'imprimer. Il sera toujours temps plus tard de filtrer les droits. (Je précise que CUPS est déjà paramétré et que nous
avons déjà fait des tests d'impression sous CUPS, mais le paramétrage de CUPS n'est pas l'objet de cet article.)
Nous installons les imprimantes de manière classique: les drivers ne sont pas enregistrés dans le partage [print$],
l'installeur Windows nous avertit que le serveur ne possède pas les pilotes adéquat. Ce n'est pas très grave, puisque
les postes ont déjà les pilotes, il suffit de sélectionner l'imprimante dans la liste des imprimantes disponibles. Ça marche.
Que demande le peuple.
Pour des détails concernant l'impression sous Samba, lire le chapitre 6 du Samba-Howto-Collection concernant le
support des imprimantes.
Ça copie Un partage administratif a été créé qui permet à l'administrateur d'accéder à tous les répertoires, sans a
naviguer dans chacun des partages.
[data]
comment = repertoire de base
path = /home
valid users = @GAIA+"Admins du domaine"
read only = no
admin users = @GAIA+"Admins du domaine"
Â
Pour expliquer rapidement, on n'autorise que le groupe admins du domaine (groupe de sécurité Microsoft dans le
domaine) à entrer dans le partage, et on lui donne le droit d'écrire. De plus, en le déclarant "admin users", les utilisateurs
de ce groupe ont des droits équivalents à ceux de root sur ce partage.
La fonction admin users = a un immense avantage: même si au niveau du système de fichier, les utilisateurs du groupe
admins du domaine n'avaient aucun droit, ce paramètre les placerait tout de même en position de super-utilisateur.
Cela peut paraître absurde à un administrateur Windows, mais dans un système sans ACL, cela améliore grandement
les possibilités d'administration. Pour plus de détails, reportez vous à la page man de smb.conf.
Revenons à nos affaires: le partage data est créé et accessible aux administrateurs, nous nous logeons donc sur le
serveur NT, et copions les deux premiers répertoires. Le transfert se fait sans accroc. Nous éditons smb.conf pour les
partager, décrétons qu'un groupe a le droit de lire et d'écrire, et que les autres ont uniquement le droit de lire. Les
démons sont redémarrés fébrilement, et...  ...impossible d'écrire sur le partage. Nous vérifions bien sûr que le gr
est le bon, qu'il n'y a pas de faute de frappe ; mais rien à faire, ça ne marche pas. En fait, nous avons simplement oublié
une règle de base des partages Samba: une fois que Samba a permis l'accès au système de fichiers par le
truchement des autorisations dans smb.conf, il faut aussi que le système de fichiers permette la même chose! Or nous
constatons très vite que sur le répertoire créé, les droits sont les suivants:
drwxr-xr-x 2 root root
4.0k jan 8 20:46 install
Le propriétaire et le groupe de ce fichier sont le root et le groupe root. Bien évidemment les utilisateurs de notre groupe
(@GAIA+installateurs) n'ont pas le droit d'écrire. Une solution pourrait être de faire un chgrp @GAIA+installateurs install.
On ferait de même pour tous les répertoires partagés par Samba.
La gestion des droits doit rester simple! Je ne sais pas comment vous envisagez les choses, mais pour Jean Bernard
Dubois la chose est tranchée depuis le début: il est absolument hors de question de gérer d'une part les droits sur les
partages avec le fichier smb.conf, et de gérer d'autre part les droits sur le système de fichier. Il applique le principe
suivant à la lettre: "make it simple, stupid". Plus les choses sont complexes, et plus elles sont difficiles à dépanner, surtout
dans l'urgence. Il est donc décidé de mettre tout le monde en lecture, écriture, exécution sur tous les objets partagés pa
Samba, les restrictions d'accès seront uniquement positionnées avec Samba.
Traduction, à l'intérieur du répertoire data retentit un sonore : chmod -R 777 *  .
Les paramètres suivants ont été ajoutés:
create mask = 777
inherit permissions = yes
Je me doute que certains admins doivent se prendre la tête entre les mains à la lecture de cette méthode barbare,
sentant le "newbisme" à plein nez. Je le répète, vous faites ce que vous voulez de votre côté, et personne ne vous
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
encourage (ni ne vous décourage) à faire de même. Compte tenu du contexte "GAIA", nous avons estimé que le risque
était modéré. Ajoutons à cela que les utilisateurs de Samba n'ont pas accès à un shell s'ils tentent de se connecter (le
shell est /bin/false) avec leur login Windows.
D'autre part, si vous vous servez de ce document pour préparer votre propre migration, votre souci premier sera sans
doute d'avoir un système qui fonctionne; un système fonctionnel que vous pourrez sécuriser par la suite. En effet, rien
ne vous empêche de retreindre les droits plus tard.
Note: ne pas oublier de se "déloger".
Nous copions frénétiquement d'autres répertoires, en commençant par les moins sensibles, nous testons au fur et Ã
mesure, et bien évidemment, nous faisons des fautes de frappe dans smb.conf - qui n'en fait pas? Bien sûr après ces
modifications nous retestons, et ça ne marche toujours pas. Ça pourrait durer un bout de temps, parce que bien
souvent Windows met en cache les informations de connexion et ne les réinitialise que lorsqu'on déconnecte la session
: n'oubliez donc pas de vous "déloger" pour vérifier que voter paramétrage est bon.
Modification des scripts de connexion Une fois que les fichiers sont copiés et que leur accès (ou non-accès) est validé
sur différentes machines avec différents logins utilisateurs, nous modifions les scripts de connexion. Il ne s'agit pas, en
effet, que les utilisateurs se connectent sur l'ancien serveur et y modifient les fichiers. Comme nous ne migrons que des
répertoires communs à l'entreprise, la modification est rapide. De toutes manières, les utilisateurs ne se sont rendu
compte de rien.
Déboggage et debriefing Les jours suivants, Jean-Bernard poursuit le déplacement des répertoires des différents
services, sans jamais toucher aux dossiers personnels des utilisateurs.
Il va doucement, mais sûrement, et reste derrière eux prêt à intervenir en cas d'incompréhension ou de petit souci. Il
modifie certains chemins qui pointent vers l'ancien serveur. Il se frotte à des problèmes de noms de fichiers long (nous
résoudrons ce dernier problème in extremis, juste avant la bascule en contrôleur de domaine). L'affaire dure presque
deux mois. Les fichiers communs à plusieurs personnes sont migrés, il va falloir passer aux choses sérieuses: la création
des comptes utilisateurs sur le serveur, et la migration des fichiers personnels. Mais avant, juste deux mots concernant
cette malheureuse affaire de noms de fichiers longs.
Je ne sais trop quelle idée m'est passée par la tête ce jour là , mais je voulais que le serveur utilise la toute dernière
version de Samba: la 2.2.6. Or en Woody, seule la version 2.2.3a était disponible (c'est d'ailleurs toujours le cas). J'ai vu
qu'il y avait un paquet .rpm disponible et précompilé chez Samba, je l'ai donc téléchargé, converti en paquet .deb avec
l'utilitaire alien et installé. Dans ma tête, il suffisait de faire la même chose pour les prochaines versions de Samba. Ami
lecteur, crois moi, l'idée était mauvaise.
Il s'est avéré entre autres dysfonctionnements que lorsque l'on double-cliquait dans l'explorateur Windows sur un fichier
OpenOffice long, il ne s'ouvrait pas, alors que si depuis OpenOffice, on faisait: Fichier, Ouvrir, tout se passait bien. Pour
un utilisateur qui a déjà du mal à faire la différence entre les boutons gauche et droit de la souris, c'est assez déroutant,
et ça met à mal la belle image de Linux que l'on tente de propager. Le problème ne se posait pas du tout avec les
fichiers dont le nom était court et avec d'autres types de fichiers comme les fichiers MS Office.
Nous avons perdu beaucoup de temps pour tenter de résoudre ce problème, et la version 2.2.7 est arrivée là dessus.
Entre temps, j'avais appris à compiler moi-même des paquets .deb à partir des sources de chez Samba, et en plus
Christian Perrier avait mis en ligne ses paquets 2.2.7 précompilés. Nous avons désinstallé la version 2.2.6, et mis à la
place la version 2.2.7 compilée proprement, et tous les problèmes mineurs insolubles ont disparu à cet instant (sauf
pour mon chat qui fait toujours ses griffes sur le canapé), ce qui nous a permis de poursuivre vers l'étape suivante.
Fin de la migration, passage en contrôleur de domaine
Lors du passage en contrôleur de domaine, il y a un écueil à éviter: ne surtout pas laisser ensembles sur le même
réseau IP deux contrôleurs pour un même domaine. Nous l'avons évité, mais on peut difficilement dire que ça a été
avec élégance.
Mais reprenons dans l'ordre :
Créer les utilisateurs sur le serveur Samba Vous vous en doutez, si son compte n'existe pas sur le serveur Samba, il va
être assez difficile à notre charmante comptable d'accéder au fichier de paye, surtout en environnement de domaine.
Il existe deux méthodes.
- La première: utiliser un script fourni avec la documentation de Samba qui permet d'exporter dans un fichier tous les
utilisateurs et tous les groupes du CPD Windows, puis de les importer dans les fichiers passwd et groups. Je vous
conseille très vivement d'utiliser ce type de méthode si vous migrez 200 utilisateurs.
- La deuxième consiste à créer les groupes et les utilisateurs à la mimine avec adduser (quand on en a créé un ou deux
les quarante suivants ne sont pas trop compliqués), puis de créer les utilisateurs dans le fichier smbpasswd grâce Ã
l'utilitaire smbpasswd. C'est la méthode que nous choisissons, officiellement pour maîtriser de bout en bout le
processus de création des comptes.
Vous éviterez d'ébruiter que sur le moment, je ne me souviens plus où j'ai stocké les scripts de conversion, et comme
je n'ai pas envie de perdre une heure à les retrouver...
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
On parle beaucoup de création d'utilisateurs, mais ce à quoi il faut faire le plus attention, finalement, c'est l'appartenance
aux groupes! Il est essentiel d'avoir noté au préalable quel utilisateur relève de quel groupe si vous souhaitez déclarer
un groupe d'administrateurs, ou un groupe de comptables. Je fais remarquer aux étourdis que ce travail là , c'est avant
qu'il faut l'avoir fait, et qu'au moment de les transcrire dans le système Linux, on en a déjà profité pour faire un peu de
ménage. Que celui qui ne s'est jamais retrouvé avec quelques comptes obsolètes, et des appartenances aux groupes
un peu floues m'envoie un mail  ;-)
Nous commençons donc par créer les groupes.
Exemple contraire: en commençant par créer les utilisateurs sans avoir créé un groupe "acteurs", vous risquez de
devoir, par la suite, éditer le fichier passwd pour attribuer à chaque utilisateur le groupe "acteurs", parce que vous aurez
créé l'utilisateur "fernandel" dans le groupe "fernandel", "bourvil" dans le groupe "bourvil", et ainsi de suite. Alors que si
vous commencez par créer le groupe "acteurs", vous allez pouvoir créer tous vos utilisateurs avec ce groupe "acteurs",
puis dans le groupe "comique", vous mettrez "bourvil" et "fernandel" comme utilisateurs supplémentaires, et pour le
groupe "barbant",  vous mettrez "lanvin" et "vandamme" comme utilisateurs supplémentaires. De cette manière sur le
partage "blagues", on pourra poser les autorisations suivantes:
[blagues]
comments = comique troupier
path = /histoires/droles
valid user = @acteurs
write list = @comique
read only = yes.
           ÂÂ
Ainsi, tous les acteurs pourront accéder aux blagues. Les comiques pourront Ã
nouvelles histoires drôles, mais les acteurs barbants ne pourront que les lire.
Modifier le fichier smb.conf Il n'y a pas grand chose à faire puisque tout a été pré-mâché. Il faut bien sûr commenter
tout ce qui correspond à Winbind et aux options de serveur membre, puisque le démon ne va plus servir, et
décommenter toutes les nouvelles options de contrôleur de domaine.
Les options concernées sont les suivantes:
Options commentées
remote browse sync =
password server =
winbind separator =
winbind uid =
winbind gid =
winbind enum users = yes
winbind enum groups = yes
Options modifiées
os level = (passé de 16 à 64)
security = (passé de domain à user)
local master = (passé de "no" à "yes")
Options ajoutées
wins support = yes
domain master = yes
preferred master = yes
domain logons = yes
domain admin group =
Le fichier smb.conf plus bas commente largement ces options.
La grande question est: oui, mais comment les stations vont-elles savoir que c'est SRVLINUX qui est maintenant le
contrôleur de domaine, alors qu'avant, c'était SRVNT? Pour ceux qui se souviennent encore de quelques bribes de
l'article sur NetBIOS (Linux Mag 44) et du seizième caractère (consultable sur http://www.linuxfrance.org/article/serveur/netbios/), le contrôleur de domaine est identifié au milieu des autres machines du réseau,
grâce à son seizième caractère. Bien sûr, l'essentiel est invisible pour les yeux : ce que cherchent les clients c'est une
machine affichant un nom de groupe de travail se finissant par <1C>. En l'occurence, ici: Â GAIAÂ <1C>Â Groupe. Le
problème, c'est que les stations ne feront pas la différence entre le serveur NT et le serveur Linux et risquent de se
connecter indifféremment aux deux serveurs. Il faut donc débrancher le serveur NT du réseau.
Récupérer le jeton de contrôleur de domaine
Être identifié comme contrôleur de domaine au niveau NetBIOS n'est suffisant que pour les clients Windows 9x. Pour
les clients NT et supérieur, il y a un identifiant commun qui leur permet de se reconnaître comme faisant partie du
même domaine: le SID. Ce jeton, c'est le contrôleur du domaine qui l'a, et les clients y ajoutent un petit bout qui signale
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
leur appartenance au domaine tout en les distinguant des autres machines.
Pour que le serveur Samba soit identifié par les machines NT comme LEUR contrôleur de domaine, il faut donc
récupérer ce SID. J'ai beau chercher, je ne trouve pas comment faire. Comme il n'y a qu'une seule machine Windows
2000 sur tout le réseau, je laisse tomber l'affaire.
De fait en ne récupérant pas ce SID, et en redémarrant Samba en tant que contrôleur de domaine, je créé un nouvea
domaine dont le nom est identique au précédent.
C'est quelques jours plus tard en demandant sur la liste de diffusion de Samba que j'apprends la commande à utiliser, et
que je n'ai pas été foutu de trouver dans ma doc: il faut utiliser l'option -S. (extrait de la page man : -S. Avec cette
option, smbpasswd va demander son SID au contrôleur du domaine spécifié dans smb.conf avec le paramètre
workgroup, et l'enregistrer dans son fichier secrets.tdb comme étant son propre SID. Cette option n'est utile que si on
configure un CPD et un CSD Samba, ou si on migre d'un CPD Windows vers un CPD Samba.)
Et c'est parti... On arrête Winbind pour déconnecter le serveur de son contrôleur de domaine, on débranche le serveur
Windows du réseau, et on redémarre les démons smbd et nmbd. On respire, et la première machine fait sa connexion
au domaine, comme si de rien n'était. Vous avez déjà vu un technicien ravi?
C'est le moment de faire la "tournée des popotes" pour vérifier que tous les logins sont exacts, que les scripts montent
correctement tous les lecteurs réseau, et que les droits en lecture et écriture sont bien ceux prévus pour l'utilisateur
(cela permet en outre de vérifier que les utilisateurs sont bien dans les bons groupes). Pour nous tout se passe bien.
Comme nous ne connaissons pas le mot de passe de chacun, nous l'avons attribué identique au nom de l'utilisateur.
Nous vérifions que l'utilisateur peut bien modifier son mot de passe. Ça ne marche pas. Sur la Debian que nous utilisons
l'exemple fourni dans le smb.conf de la documentation Samba ne fonctionne pas. Nous essayons donc le paramétrage
utilisé par Ewen Prigent dans sa documentation illustrée, qui fonctionne à merveille:
passwd chat =*New* %n\n *Re* %n\n *pa*
Il reste une dernière chose à tester avant de quitter l'entreprise avec la certitude sereine du travail accompli (et la
certitude que ce ne sera pas la folie furieuse le lundi matin) : réattribuer les droits sur les partages de certains clients
Windows. Ces partages servent à sauvegarder les bases de la comptabilité tous les soirs, par exemple. Il faut leur
réattribuer les bons droits.  Nous reconnectons aussi la station Windows 2000 au domaine. Cela nous permet de vérifier
que les comptes d'ordinateurs se créent automatiquement dans /etc/passwd. Pour l'ajout de comptes de machines à la
volée, la ligne suivante dans smb.conf suffit:
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
Voilà . C'est terminé en ce qui concerne le contrôleur du domaine. L'ancien serveur NT tourne toujours, il sert à récupére
des fichiers sauvegardés de temps en temps. Le nom du domaine a été changé, et comme SRVLINUX et lui ont des SID
différents, ils sont effectivement sur des domaines différents.
Le lundi matin, aucun utilisateur ne s'est rendu compte du changement de serveur. Mission accomplie.
Fin de l'histoire, début de l'histoire
L'aventure des logiciels libres ne s'arrête pas en si bon chemin, chez GAIA. Bien sûr le serveur tourne comme une
horloge, bien sûr il y a encore de menus soucis à résoudre au quotidien ; même avec Linux, la perfection ne peut être
de ce monde.
Le reste de l'aventure, que je ne détaillerai pas, et dont la migration du serveur n'est qu'une étape, concerne la
bureautique. GAIA Converter utilise la suite OpenOffice.org depuis septembre 2002, environ. Le PDG de GAIA a laissé
carte blanche au niveau de l'informatique : la seule contrainte est que cela doit marcher. Les utilisateurs de GAIA se
servent donc au quotidien d'OpenOffice, et de Mozilla. Bien sûr, il y a encore dans un coin une suite Office qui tourne
pour récupérer les fichiers de certains clients. Bien sûr, il y a toujours des applications Access qui tournent avec des
bases propriétaires, et qu'il sera très long de changer. Bien sûr, certains utilisateurs grognent parfois que ça plante Ã
cause des logiciels libres, mais Jean Bernard n'a pas trop de mal à leur montrer que ce qu'ils n'arrivent pas à faire avec
OpenOffice, par méconnaissance du logiciel, ils ne savaient pas du tout le faire avec MS Office. Les logiciels libres
prennent donc racine tout doucement, et l'objectif, Ã terme, sera de migrer certaines stations Windows sous Linux.
En effet, il est assez difficile de migrer d'un coup le système client, et la bureautique, puis de former 40 personnes. En
revanche, à partir du moment où tout le monde sait se servir de logiciels libres pour la bureautique, et que les échanges
de fichiers dans l'entreprise se font sans contraintes, le passage à un bureau KDE ou GNOME n'est finalement qu'un pas
de plus. Mais pour l'histoire de GAIA, je suis ici un petit peu en avance.
Aller plus loin sans aller trop loin
Pour les grands néophytes qui liront l'article, il me semble important d'expliquer sommairement l'utilité de certaines
fonctions de Samba. Il n'est pas question de refaire en moins bien la documentation de Samba qui est déjà très bien
faite.
SMBD et NMBD Le premier sert à "déclarer" les partages aux clients du réseau, à annoncer les noms NetBIOS de la
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
machine, à accorder les droits d'accès aux objets partagés...  ...retenez que ce démon est très important. Sans lui, le
serveur est muet.
Le deuxième permet à Samba d'accéder aux ressources des autres serveurs SMB du réseau. C'est grâce à lui que des
outils comme LinNeighborhood peuvent afficher le voisinage réseau comme sur une machine Windows, ou que l'on peut
monter des partages Windows dans l'arborescence de fichier Unix. Sans lui, le serveur est sourd.
WINBIND Winbind est un outil capital pour une migration sans douleur. On faisait sans avant, mais ça ne devait pas
être drôle. En fait, Winbind récupère la liste des utilisateurs et des groupes d'un domaine NT, et permet au système
Unix de les réutiliser pour :
- mettre des restrictions d'accès sur des objets du système de fichier ;
- mettre des restrictions d'accès sur des objets partagés par Samba ;
- autoriser un utilisateur du domaine à ouvrir une session sur le serveur, comme s'il s'agissait d'un utilisateur local.
Il évite à la fois d'entrer les utilisateurs dans les fichiers /etc/passwd et /etc/groups, ainsi que dans le fichier smbpasswd.
Il s'appuie sur nsswitch qui va dire dans quel ordre résoudre les noms: commencer par chercher dans /etc/passwd, puis
demander à NIS, puis demander au contrôleur de domaine NT, par exemple. La mise en place de Winbind est
simplissime, pourvu que l'on suive la documentation de Samba.
Deux bases utilisateurs: /etc/passwd et smbpasswd Il me semble utile de rappeler que lorsque Samba est paramétré
pour fonctionner dans le mode user, il faut absolument que les utilisateurs existent à la fois dans le fichier smbpasswd,
qui permet à Samba d'authentifier l'utilisateur au niveau de la machine et du partage, mais aussi dans le fichier
/etc/passwd, qui permet à la machine d'authentifier l'accès aux objets dans le système de fichier!
À cet effet, on commence toujours par créer l'utilisateur dans /etc/passwd (il n'est pas nécessaire de lui donner un
home), puis on l'ajoute au fichier smbpasswd grâce à la commande smbpasswd -a mon_boss (il est d'ailleurs impossible
de faire le contraire).
Il n'est pas du tout nécessaire que le mot de passe smbpasswd soit le même que le mot de passe Unix, car c'est
Samba qui assure l'authentification. Une fois faite, l'utilisateur dispose des droits que lui donne le système sur le fichier.
Tant qu'on en est à parler de base de comptes, il faut noter que la fonction d'expiration des mots de passe utilisateurs
n'est pas encore complètement implantée. Il faudra attendre, ou subventionner le projet Samba.
Et les groupes dans tout ça? C'est pour la prochaine version de Samba, la 3.0. Pour l'heure, on peut utiliser les
groupes entrés dans /etc/groups pour attribuer des droits aux partages du serveur lui-même, mais on ne peut pas
récupérer les groupes pour les réutiliser sur une autre machine du domaine.
Ex.: je définis un partage sur le lecteur CD de "Harry", et je veux donner les droits en lecture au groupe "Potter" sur ce
partage.
"Potter" existe bien dans /etc/groups, mais il n'est pas possible d'utiliser ce groupe au niveau du partage. Il faut ajouter
les utilisateurs un à un.
C'est la raison pour laquelle, sur un site avec beaucoup d'utilisateurs, il vaut mieux que l'authentification soit faite avec
un annuaire de type LDAP (attention, Samba ne sait pas encore lire les annuaires LDAP Microsoft Active Directory).
Conclusion Voilà pour notre histoire,  à vous de construire la vôtre. Ce que Jean Bernard est en train de réaliser dans sa
PME, bien des libristes voudraient avoir la liberté de l'entreprendre, moi inclus.
En terme de stratégie de migration, il me semble important de ne pas se précipiter. Bien sûr, il est tout à fait
envisageable de tout faire en un week-end, mais ma première réaction est de le déconseiller très fortement, sauf si
votre but est d'arriver le lundi matin avec la moitié seulement de vos utilisateurs qui peuvent travailler, et des gens qui
ne peuvent pas accéder à leurs données. La précipitation serait une bonne technique de "BOFH".
Si en revanche, vous ne souhaitez pas travailler avec votre lettre de démission dans la poche, avancer prudemment, et
par paliers me semble une meilleure tactique.
En terme de connaissances, il me semble aussi important d'avoir de bonnes connaissances de Samba et de Linux que
de Windows NT/2000 serveur, car après tout, ce que votre serveur remplace, c'est un contrôleur de domaine Microsoft.
Suivant les fonctionnalités que vous utiliserez, une bonne connaissance des profils utilisateurs, ou de TCP/IP en
environnement Windows vous sera nécessaire.
La pire des choses serait en tous cas de sous-estimer la difficulté. Il y a autant de différence entre une implantation de
Samba sur un réseau domestique et un réseau d'entreprise qu'entre la mise en place de Wind@#!*#...  ...MandrakeLinux sur l'ordinateur de votre petit voisin et son emploi sur un réseau d'entreprise sécurisé et/ou routé.
Documentation-Webographie - Le tout premier site à aller voir, avant quoi que ce soit, est celui de Samba:
http://ftp.easynet.be/samba/samba.html
- Et la toute première doc à lire est la Samba-Howto-Collection:
ftp://ftp.easynet.be/samba/docs/Samba-HOWTO-Collection.pdf
Il est inutile d'aller plus loin ou de se plaindre qu'on y arrive pas tant qu'on n'a pas lu ce Howto du début à la fin. C'est un
véritable manuel de référence. Je n'ose même plus parler de la page man de smb.conf qui pour un projet de ce type doit
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38
Site perso Florin Grosu
devenir votre livre de chevet.
- La deuxième chose à lire, c'est la documentation d'Ewen Prigent chez Linux-France:
http://www.linux-france.org/~eprigent/samba/
Une documentation illustrée, avec des fichiers smb.conf commentés. Une mine!
- J'aurais bien voulu pouvoir vous indiquer l'adresse d'un plan de migration complet détaillant la migration d'un point de
vue technique sous toutes les coutures, mais je n'ai pas su en trouver. Si vous tombez sur l'une d'elles, n'hésitez pas Ã
m'en faire part.
- Je ne conseille pas spécialement la lecture du bouquin O'Reilly sur Samba qui commence à devenir un peu obsolète,
au fur et à mesure que le projet Samba avance (vous avez le droit de ne pas être d'accord avec moi).
- Le "Précis & concis" O'reilly expliquant les paramètres du fichier smb.conf me semble tout à fait incontournable, en
revanche. Il ne devrait jamais être à plus de 30cm de votre console d'administration.
- Paquetages à installer pour CUPS
Sans rentrer dans les détails de l'installation de CUPS, j'ai trouvé quels paquetages installer pour avoir CUPS sur ma
Debian à cette adresse:
http://lists.bxlug.be/pipermail/lxoffice/2002-May/000035.html
- Ma doc précédente sur NetBIOS vous aidera peut-être à mieux comprendre la connexion d'un client au domaine. Elle
est lisible chez linux-france:
http://www.linux-france.org/article/serveur/netbios/ .
- Pour la compréhension du fonctionnement des SID, les bouquins ENI de préparation aux certifications NT Serveur
seront un bon complément au Samba-Howto-Collection.
Pour exemple, voici le fichier smb.conf de GAIA tel qu'il est actuellement. Il est bien évidemment tronqué de tout ce qui
n'est pas directement lié à la compréhension du document.
Remerciements - En tous premier lieu à Jean Bernard Dubois que j'embauche comme directeur informatique dès qu'il
est d'accord.
- A mes chats, ma souris, mes plantes vertes, mon micro pour leur soutien...   ...indéfectible.
- A Alexandra Beaufort et Olivier Parisy, fidèles correcteurs de mes topos.
Pour des précisions, des critiques, des questions, vous pouvez m'écrire:
fclercATlinux-france.org ou f.clercATabul.org
Fabrice Clerc
http://www.grosu.info
_PDF_POWERED
_PDF_GENERATED 8 February, 2017, 11:38