Version 1

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 facilité 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 qu'à 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 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. Je 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-HOWTO-collection.
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 surprise, 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.

Ç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 avoir à 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 groupe 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 par 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 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é fait 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...

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 écrire de 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.linux-france.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 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 nouveau 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érer 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 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@#!*#...  ...Mandrake-Linux 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 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