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