Comment graver sous Linux avec un lecteur IDE ?

graver un cd sous linux

Les programmes de gravure sous Linux ne savent gérer que les périphériques SCSI. Mais rassurez vous. Pour faire fonctionner les graveurs IDE, le noyau linux a recours à une petite astuce : émuler le graveur IDE en graveur SCSI. Il faut d’abord vérifier si les bonnes options sont activées dans le noyau :

SCSI Support -> SCSI support = M
SCSI Support -> SCSI generic support = M
SCSI Support -> SCSI CDROM support = M
ATA/IDE/MFM/RLL support -> IDE, ATA and ATAPI Block devices -> SCSI emulation support = M

Si ces options ne sont pas activées, alors il faut les activer et recompiler le noyau. Normalement sous Mandrake 8.0+ ces options sont activées par défaut et le graveur a de fortes chances d’être préconfiguré.
Ensuite il faut configurer le chargeur de boot pour qu’il dise au noyau quel périphérique émuler en SCSI, pour cela il faut lui passer l’option hdx=ide-scsi , où hdx désigne le lecteur IDE à émuler.

Avec lilo

Il suffit de modifier /etc/lilo.conf et d’ajouter la ligne suivante : append=” hdx=ide-scsi”. Si vous avez déjà append, il suffit de rajouter juste hdx=ide-scsi à la suite.
N’oubliez pas de relancer lilo pour qu’il réenregistre sa configuration en tapant /sbin/lilo.
La ligne append doit être ajoutée dans la section relative de votre noyau par exemple juste après le label.
Cela donne quelquechose de similaire a ceci :

image=/boot/vmlinuz
label=linux
root=/dev/sdb1
append=” hdc=ide-scsi”
read-only

Encore une fois seule la ligne en gras importe. Le reste dépend de votre configuration.

Avec Grub

Il suffit de modifier /boot/grub/menu.lst et de passer en paramètre au noyau en l’ajoutant directement à la ligne kernel l’option : hdx=ide-scsi”
Cela donne par exemple :

kernel (hd2,0) /boot/vmlinuz root=/dev/sdb1  hdc=ide-scsi

Encore une fois seul ce qui est gras importe. Le reste dépend de votre configuration.

Comme je l’ai dit, hdx désigne le lecteur de CDROM IDE que vous voulez émuler en SCSI. Pour information je rapelle la nomenclature des lecteurs IDE sous Linux :
hda = primary master
hdb = primary slave
hdc = secondary master
hdd = secondary slave

Si vous ne le savez vraiment pas (bien qu’il suffit d’ouvrir au pire sa tour), voici une méthode empirique pour le retrouver :

$> grep -r CD /proc/ide/

Et exceptionellement sous Linux, il faut rebooter pour que les changement soient pris en compte.
Ensuite on vérifie si tout est ok :

$> lsmod | grep ide-scsi<- on vérifie si le module d’émulation scsi est bien chargé
$> cdrecord -scanbus<- on vérifie si cdrecord (programme de base de gravure sous Linux) le détecte

Si cdrecord le détecte, alors c’est ok.

Avant de commencer la gravure, il convient de modifier /etc/fstab. En effet, le lecteur étant émuler en SCSI, son nom de device à changer.
Pour nous y retrouver on va créer un répertoire pour monter le graveur, par exemple /mnt/graveur. Puis tester le device.
Le CDROM IDE est émulé en SCSI donc il faut tester les devices SCSI. Les CDROM SCSI sont nommés scdx (Scsi CDrom). Pour cela on met un CD de donnés dans le graveur ou le lecteur IDE qui a été émuler en SCSI et on essaie les commandes suivantes :

$> mount -t iso9660 /dev/scdx /mnt/graveur<-  avec x = 0, 1, 2, 3, ….

Dès que cela marche, vous avez trouvé le graveur. Souvent c’est /dev/scd0.
Ensuite il faut faire votre lien. Faites :

$> ls -l /dev/cdrom*

Prenez le lien qui pointe vers votre ex cdrom IDE et effacer le. Supposons que ce lien est /dev/cdrom, cela donne :

$> rm /dev/cdrom

Ensuite faites le pointer vers le le nouveau lecteur IDE émuler en SCSI :

$> ln -s /dev/scdx /dev/cdrom

Ensuite vous rajouter la ligne suivante dans /etc/fstab :

/dev/cdrom /mnt/cdrom iso9660 ro,nosuid,noauto,exec,user,nodev   0 0

ou

/dev/cdrom /mnt/cdrom auto ro,nosuid,noauto,exec,user,nodev   0 0

Les utilisateurs d’une Mandrake préféront peut être utilisé supermount :

/mnt/cdrom /mnt/cdrom supermount dev=/dev/cdrom,fs=iso9660,ro 0 0

Note : Ce cas ne s’applique bien sûr que lorsque le lien vers le lecteur émulé en SCSI s’apelle /dev/cdrom.

Vous pouvez aussi remplacer /mnt/cdrom qui est le point de montage pour accéder au graveur par le nom que vous voulez : /mnt/cdrom1 , /mnt/graveur , … Bien sûr il ne faut pas oublier de créer le répertoire correspondant.

Ensuite il ne reste plus qu’a configurer les programmes de gravure.
Les plus connus ayant une interface graphique sont : xcdroast, eroaster, k3b, konCD. Vérifier si ces programmes ne sont pas déjà dispobnibles sur les CD de votre distribution.
Une fois le programme de gravure choisi et configurer il ne vous reste plus qu’a graver. Nul besoin de redémarrer à ce stade.

Note : Si voulez faire de la Copie de CD à CD direct, il vous faudra aussi configurer votre lecteur de CD en l’émulant en SCSI pour avoir le graveur et le lecteur en SCSI.

Si vous voulez faire des pochettes de CD sachez qu’il existe des programmes comme cdlabelgen, gtkcdlabel, kcdlabel.
Faites un tour sur http://rpmfind.net pour éventuellement récupérer la version en rpm adaptée à votre distribution.

Comment installer le pilote NForce ?

pilote NForce

Le but de cet HOWTO est d’aider à installer les drivers nforce sous Mandrake 9.x. J’ai essayé de donner la méthode la plus propre qu’il soit pour que cela se passe sans encombres et ce en détaillant le plus possible.
Les commandes doivent être fait en tant que root ( super-utilisateur ).

Information :
Les pilotes nforce disponibles sur le site de nvidia sont nécessaires pour faire marcher l’interface réseau du chipset ( nvnet ). Ils servent aussi pour la carte sons, mais linux peut gérer la carte son du chipset nforce avec le pilote snd-intel8x0 en lieu et place du pilote de nvidia ( nvaudio ).

Préparation

REQUIS :
binutils, gcc, ed, kernel-source, glibc-devel, rpm-build

ed, kernel-source, glibc-devel se trouvent sur les CD de la distribution et peuvent être installé via urpmi/rpmdrake.
Vous devez installer la version de kernel-source qui correspond au noyau que vous utiliser !

$> urpmi binutils ed kernel-source rpm-build<- on install ed, binutils, kernel-source et rpm-build. glibc-devel est installé automatiquement lorsque l’on installe kernel-source
$> rpm -qa | grep kernel-source<- on vérifie la version de kernel-source, par exemple on peut avoir kernel-source-2.4.22-26mdk
$> uname -r<- on vérifie la version du noyau que l’on utilise. Celle-ci doit correspondre. Par exemple cela devrait donner dans mon cas 2.4.22-26mdk

Note :
Si votre noyau est plus ancien que la version des kernel-source que vous avez, cela signifie que vous avez installé la dernière version des kernel-source de votre distribution et qu’un nouveau noyau est disponible. Ceci arrive si vous avez configuré votre système pour récupérer les mises à jour de sécurité et corrections de bogues via internet. Pour récupérer la dernière version du noyau, il vous suffit alors de l’installer via urpmi.
Pour cela vous tapez soit :
$> urpmi -p kernel
qui vous donnera une liste des noyaux disponible, ou alors pour être sûr, vous taper directement le nom entier du noyau que vous voulez :
$> urpmi kernel-2.4.22-26mdk
Pour toujours utiliser la dernière version disponibles des noyaux pour votre système, mettez à jour vos sources updates :
$> urpmi.update -a
Puis récupérez les dernières version de votre noyau et de kernel-source avec urpmi.

1°/ Récupération des drivers :

Télécharger les drivers nvidia sur le site de nvidia. Vous sélectionnez “Linux IA32 Drivers” ( IA32 = Intel Architecture 32 bits, soit les processeurs Intel/AMD/Ciryx/Via 32 bits ). Si vous avez une connexion internet, vous pouvez procéder comme cela en console :

$> urpmi wget<- on install wget qui va nous permettre de télécharger les drivers
$> cd /tmp<- on va télécharger les drivers dans le répertoire /tmp
$> wget http://download.nvidia.com/XFree86/nforce/1.0-0261/NVIDIA_nforce-1.0-0261.src.rpm

2°/ Préparation des sources du noyau :

Vous avez différentes commandes à taper afin de pouvoir préparer les sources du noyau pour une compilation correcte des pilotes nforces. Ces commandes doivent être faites précisément ( respect casse et espces, … ). Si vous le pouvez faites juste un copier/coller.

$> cd /usr/src/linux<- on va dans le répertoire où se trouve les source du noyau. Il est crée lorsque vous installez le package kernel-source
$> make mrproper<- on nettoie les sources
$> cp /boot/config ./.config<- on récupère les options de configuration de l’ancien noyau ( ceux de mdk )
$> make oldconfig<- on compile selon cette version
$> make dep<- on initialise les dépendances entre modules/pilotes du noyau

 

Installation/Compilation

On va lancer la compilation des pilotes. Cela devrait aboutir à la création d’un rpm qu’il ne nous restera plus qu’a installer.

$> rpm –rebuild /tmp/NVIDIA_nforce-1.0-0261.src.rpm

Vous devriez obtenir la ligne suivante tous à la fin si tout s’est bien passé :

Wrote /usr/src/RPM/RPMS/i586/NVIDIA_nforce-1.0-0261.i586.rpm

Ensuite on installe le rpm crée qui contient les pilotes nforce compilé pour notre noyau

$> rpm -Uvh /usr/src/RPM/RPMS/i586/NVIDIA_nforce-1.0-0261.i586.rpm

 

Configuration

Carte son

Normalement la carte son peut être gére par le pilote alsa snd-intel8x0. Pour le vérifier, il suffit de lister les différentes cartes sons configurés et leurs pilotes gràace à la commande :

$> grep sound-slot /etc/modules.conf

Normalement vous devriez avoir ceci :

alias sound-slot-0 snd-intel8x0

Si vous avez plutôt ceci :

alias sound-slot-0 snd-intel8x0
alias sound-slot-1 nvaudio

c’est due au fait que le rpm qui a installé les pilotes nforce a configuré votre modules.conf. Il y a une entrée en trop. Si vous n’avez qu’une seule carte son, alors seul sound-slot-0 doit apparaitre.

Utiliser le pilote ALSA

pour utiliser le pilote ALSA, il faut enlever les références au pilote audio nvidia des nforce ( nvaudio ) et éventuellement à d’autres pilotes audio ( comme i810_audio qui est le pilote OSS ).
Pour cela il faut virer toutes les lignes contenant alias sound-slot-x nomdupilote et ne garder que la ligne contenant alias sound-slot-0 snd-intel8x0. Cette ligne signifie que la 1ère carte son ( sound-slot-0 ) est gérée par le pilote ALSA snd-intel8x0.
A la fin on doit avoir donc une ligne pour le pilote ALSA, et une ligne pour l’émulation OSS, soit :

alias sound-slot-0 snd-intel8x0
above snd-intel8x0 snd-pcm-oss

Note :
Si vous avez des lignes du type “above nompilote snd-pcm-oss” en plus de “above snd-intel8x0 snd-pcm-oss”, vous devez les virer afin d’éviter qu’elles n’entrent en conflit.

Utiliser le pilote nvaudio de NVIDIA

Si vous préférez utiliser le pilote nvaudio de NVIDIA, à ce moment il faut enlever toutes les références à d’autres cartes sons ( lignes commençant par sound-slot-x ou x est un numéro ), ainsi que les ligne du type above nompilote snd-pcm-oss.
Ensuite vous devez juste avoir une ligne disant que la 1ère carte son est gérée par le pilote nvaudio :

alias sound-slot-0 nvaudio

Vérification

On peut charger le pilote sans avoir à redémarrer, mais bon pour faire simple, vous redémarrer l’ordinateur et ensuite vous vérifiez que le pilote est bien chargé en tapant /sbin/lsmod | grep nompilote.
Ainsi pour vérifier si le pilote ALSA est bien utilisé vous faites :

alias sound-slot-0 nvaudio

Chez moi cela donne comme résultat :

[admin@admin3 admin]$ /sbin/lsmod | grep snd-intel8x0 snd-intel8x0     15296 1
snd-ac97-codec       52588 0 [snd-intel8x0]
snd-pcm           79652 0 [snd-pcm-oss snd-intel8x0]
snd-page-alloc     8628 0 [snd-intel8x0 snd-pcm]
snd-mpu401-uart    4704 0 [snd-intel8x0]
gameport          3284 0 [snd-intel8x0]
snd              43972 1 [snd-seq-oss snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-intel8x0 snd-ac97-codec snd-pcm snd-timer snd-mpu401-uart snd-rawmidi snd-seq-device]

Note :
Si vous utilisez le pilote ALSA, n’oubliez d’enlever la propriétés muet pour Vol et PCM dans votre mixeur audio ( unmute ).

Carte Réseau

La chipset nforce sous la Mandrake 9.2 n’est pas géré nativement par le noyau. Dans la mandrake 10.0, le chipset réseau pourra être géré de base par le noyau gràce au pilote forcedeth qui sera intégré dans le noyau 2.4 et 2.6. Donc ce qui suit ne s’applique vraiment qu’à ceux ayant une mandrake dont la version est inférieure à la 10.0.

Tout d’abord vous devez vérifier que dans votre /etc/modules.conf il est spécifié que votre carte réseau doit utiliser le pilote nvnet.
Si vous n’avez q’une carte réseau, alors la 1ère carte réseau ( eth0 ) doit être associée au pilote nvnet, ce qui donne :

alias eth0 nvnet

Ensuite il ne vous reste plus qu’à charger le pilote puis à utiliser les outils de configuration de la mandrake qui désormais verra votre carte réseau.
Pour charger le pilote, il suffit de taper la commande suivante :

$> modprobe nvnet

up

Liens :

Où prendre les drivers :
http://www.nvidia.com/object/linux.html

Comment gérer les services au démarrage ?

centos linux startup

La plupart des démons se trouvent dans le répertoire /etc/rc.d/init.d . C’est là qu’il faut copier le script qui va gérer le démon/service ou l’appli que l’on veut lancer au démarrage.

Pour savoir les démons lancés selon la runlevel, il faut aller dans le sous répertoire correspondant. Ainsi il faut aller dans /etc/rc.d/rcx.d (avec x = numéro de runlevel ).
Après avoir choisi le runlevel dans lequel on veut lancer le démon/service, il suffit de faire un lien vers le script qui se trouve dans /etc/rc.d/init.d . Pour bien faire les choses il convient de respecter certaines conventions.

Conventions :

  • Le nom doit commancer par S (= Start ) suivi d’un numéro d’ordre sur 2 chiffres au minimum. Cela donne un nom du type Sxynom.
  • Si le script doit faire quelquechose de spécial à l’arrêt du système il faut rajouter un lien qui commence par un K (= kill).
  • Il devrait accepter comme arguments start (pour être lancé), stop (pour être arrêter) et accessoirement restart (pour relancer) et status (pour savoir si le script tourne et avoir d’autres infos).
  • Il convient de choisir correctement le numéro d’ordre. Il ne faut pas qu’il soit identique à celui d’un autre démon, et enfin il faut choisir le numéro d’ordre correct.
    En effet imaginons que notre démon utilise la carte réseau et que le script qui configure les cartes réseaux ait un numéro d’ordre de 10. Il faudra que notre démon ait un numéro d’ordre supérieur à 10, sinon comment pourrait il utiliser les cartes réseaux si elles ne sont pas configurées ?

Lancement/arrêt :

Pour lancer/arrêter un service il existe plusieurs possibilités :

Via drakxservices

Vous avez une Mandrake, alors vous pouvez utiliser drakxservices ( Mandrake Control center -> Système -> services ). Avec drakxservices vous pourrez lancer et arrêter chaque services, spécifier si vous voulez qu’ils se lancent au démarrage pour le runlevel courant et aussi avoir une description pour certains.

Manuellement

Vous pouvez le faire à la main en lançant directement le script qui gère le service. Ces scripts sont dans /etc/rc.d/init.d . Cela donne :

 /etc/rc.d/init.d/monservice stop<- Pour arréter le service
/etc/rc.d/init.d/monservice start<- Pour lancer le service
/etc/rc.d/init.d/monservice restart<- Pour relancer le service
/etc/rc.d/init.d/monservice status<- Pour connaitre l’état du service

Via la commande service

Vous pouvez aussi utiliser le programme nommé service. Ce programme est très simple à utiliser. Si vous connaissez le nom du service il suffit de faire :

 service monservice stop<- Pour arréter le service
service monservice start<- Pour lancer le service
service monservice restart<- Pour relancer le service
service monservice status<- Pour connaitre l’état du service
service monservice<- Pour connaitre les autres options que peut accepter ce service

Par exemple pour samba dont le nom de service est smb cela donne :

[root@bastard root]# service smb stop
Arrêt des services SaMBa : [ OK ]
Arrêt du service NMB : [ OK ]

[root@bastard root]# service smb start
Lancement du service SaMBa : [ OK ]
Lancement du service NMB : [ OK ]

[root@bastard root]# service smb restart
Arrêt des services SaMBa : [ OK ]
Arrêt du service NMB : [ OK ]
Lancement du service SaMBa : [ OK ]
Lancement du service NMB : [ OK ]

[root@bastard root]# service smb status
smbd (pid 31865) est en cours d’exécution…
nmbd (pid 31876) est en cours d’exécution…

[root@bastard root]# service smb
I need an action
Utilisation: /etc/init.d/smb {start|stop|restart|status| condrestart}

Administration :

On peut vouloir ensuite spécifier pour quel runlevel on veut que le script se lance automatiquement au démarrage et pour quel autre on ne veut pas. Pour cela il y a plusieurs possibilités.

Via drakxservices

Pour les utilisateurs de la Mandrake, ils pourront utiliser drakxservices (Mandrake Contriol Center -> Système -> Services ) pour définir si ils veulent lancer le service pour le runlevel courant au démarrage ou non. Ils pourront aussi disposer d’une description du service ( si celui-ci le supporte ) ainsi que de son état courrant ( démarré ou à l’arrêt )

Via ntsysv ou tksysv

Les utilisateurs de Red Hat et de Mandrake pourront aussi utiliser ntsysv voire tksysv qui sont des outils en mode console ou avec une interface graphique en tcl/tk pour gérer les services.
Pour le runlevel courant il suffit de lancer ntsysv sans arguments et de cocher les services que l’on veut lancer au démarrage :

$> ntsysv

Pour un autre runlevel il suffit de spécifier la runlevel visé :

$> ntsysv –level 3<- permet de gérer les services de la runlevel 3
$> ntsysv –level 35<- pour gérer plusieurs runlevel en même temps ( ici 3 et 5 )

En utilisant chkconfig

chkconfig est un utilitaire qui permet de gérer les services en ligne de commande. Il se révèle pratique dans le sens qui permet par exemple de gérer des services dans un script. Pour cela il faut que le script du service soit correctement formaté car les informations sur celui-ci ( runlevel par défaut pour lequel le script doit être activé, description ) sont directement intégrées au début de celui-ci.

Obtenir des informations sur un service

$> chkconfig –list<- fournit la liste de tous les services reconnus et précise pour chaque runlevel si ceux-ci sont lancés au démarrage

$> chkconfig –list service <- fourni la configuration actuelle du service nommé service pour tous les runlevel

Actriver/Désactiver un service sur un service

$> chkconfig –level 35 service on <- spécifie que service doit être lancé au démarrage pour les runlevel 3 et 5

$> chkconfig –level 35 service off <- spécifie que service ne doit pas être lancé au démarrage pour les runlevel 3 et 5

$> chkconfig –add service<- ajoute service comme étant un service pouvant être géré par chkconfig ( bien sûr le fichier du script doit être correctement formaté )

$> chkconfig –del service<- supprime le service

$> chkconfig service reset<- remet la configuration à celle par défaut définie dans le script

Exemple :

Je veux lancer le démon diablo dont le script s’apelle diablod. ce script doit être lancé au démarrage des runlevel 3 et 5 et son n° d’ordre est 99 et … qui ne fait rien de spécial

Manuellement

On va procéder manuellement notamment en ce qui concerne la configuration du démarrage du script.

$>  cp diablod /etc/rc.d/init.d/<- je copie le script diablod dans /etc/rc.d/init.d

$>  chmod +x /etc/rc.d/init.d/diablod<- Bien sûr il faut que le script soit exécutable

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc5.d/S99diablod <- Comme je suis toujours en runlevel 5 et que je veux qu’il soit lancé en runlevel 5, je vais mettre le lien  dans /etc/rc.d/rc5.d

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc3.d/S99diablod <- Je vais de temsp en temps en runlevel 3 et je veux qu’il se lance au boot, donc j’ajoute un lien pour la runlevel 3

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc5.d/K99diablod <- Comme il fait un truc spécial à l’arrêt du système je rajoute un script kill

Avec chkconfig

Voici comment il me faudrait gérer le script avec chkconfig. Vous allez voir cela simplifie pas mal de chose car chkconfig s’occupe de tout.

$>  cp diablod /etc/rc.d/init.d/<- Une nécessité : je copie le script diablod dans /etc/rc.d/init.d

$>  chmod +x /etc/rc.d/init.d/diablod<- Bien sûr il faut que le script soit exécutable

$> chkconfig –add diablod<- je demande à chkconfig de prendre en charge mon script

$> chkconfig –level 23 diablod on<- J’active mon script au démarrage pour le runlevel 2 et 3

$> chkconfig diablod reset<- Oups, je me suis trompé, il fallait que ce soit 3 et 5. Comme c’est précisé dans mon script je demande à chkconfig de mettre les valeurs par défaut définies dans le script

Comme je l’ai dit avant, il suffit de regarder dans /etc/inittab pour connaitre la signification de vos runlevel.

contenu d’un script de service type

Voici le squelette de ce à quoi devrait ressembler un script globalement :

#!/bin/bash
#
#  chkconfig: 35 99 9
#  description: démarre et arrête mon service personalisé diablo
#               qui ne fait rien de spécial

# on va tester les arguments donnés au script
case “$1” in
start)
#si on passe comme argument start
echo -n “Lancement de $(basename $0)”
…. ce qu’il faut faire….
;;
stop)
#si on passe comme argument stop
echo -n “Arrêt de $(basename $0)”
…. ce qu’il faut faire….
;;
restart)
#si on passe comme argument restart
echo -n “Redémarrage de $(basename $0)”
…. ce qu’il faut faire….
;;
*)
#Pour tous les autres cas
echo -n “Usage: $(basename $0) start| stop|restart”
#on rappelle la syntaxe du script et on quitte
exit 1
esac

La ligne chkconfig: 35 99 9 signifie que chkconfig doit configurer le service pour qu’il se lance au démarrage des runlevel 3 et 5 avec un n° d’ordre de 99.
la ligne description contient la description du script , telle que par exemple on la verra afficher dans drakxservices.

Comment installer plusieurs distributions

linux distibutions

Il arrive souvent que l’on veuille installer 2 distributions Linux en parallèle et pouvoir booter sur l’un et l’autre.

Plusieurs solutions existent, et parmi ces solutions, il y a le chain-loading.

Le Chain Loading consiste à chaîner les boot loader. Ainsi le chargeur de boot de la première distribution ( li/grub ) chargera le chargeur de boot de la 2ème distribution ( lilo/grub ) lorsque l’on voudra démarrer la deuxième distribution.
Comment procéder ? il faut respecter plusieurs étapes. La 1ère distribution que l’on va installer va devenir la distribution principale. Les autres seront appelées des distribution secondaires.

Note : Toutes les modifications de fichiers système et/ou les commandes devront être lancées en tant qu’administrateur du système ( root ).

Note 2 : On va se baser sur le schéma de partitionnement suivant :
distribution principale : / = /dev/hda2 , /home = /dev/hda5 , swap = /dev/hda7
distribution principale : / = /dev/hda3 , /home = /dev/hda6 , swap = /dev/hda7

Note 3 : Il peut se révéler très intéressant et très pratique d’utiliser la même partition pour le /home de la distribution principale et le /home de la distribution secondaire.

1ère étape : Installer la distribution principale

Tout d’abord on installe la distribution principale. C’est le chargeur de boot de celle-ci qui permettra de lancer les chargeurs de boot des distributions secondaires.
Pour cela, il faut installer le chargeur de boot dans la MBR ( Master Boot Record ) du disque de démarrage. Souvent ce sera pour un système IDE le Primary Master qui s’apelle sous Linux hda.

Lilo

Normalement lors de l’installation de votre distribution vous devriez pouvoir choisir facilement le fait d’installer lilo dans la MBR. Cependant dans le cas où vous voudriez le faire manuellement, il vous suffit d’éditer le fichier /etc/lilo.conf et de modifier l’option boot. Cette option définie l’endroit où lilo doit s’installer. Dans notre cas, nous supposons que hda est notre disque de boot et donc il faudra avoir boot=/dev/hda pour que lilo s’installe dans la MBR. Voici un extrait d’un lilo.conf avec l’option boot correctement positionnée :
boot=/dev/hda
map=/boot/map
prompt
nowarn
timeout=100
keytable=/boot/fr-latin1.klt
message=/boot/message
image=/boot/vmlinuz
label=”linux”
root=/dev/hda2
initrd=/boot/initrd.img
append=”resume=/dev/hda7 hdc=ide-cd splash=silent”
vga=788
read-only

Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

Pour installer GRUB dans la MBR, il suffira de lancer la commande suivante :
grub-install /dev/hda
On peut aussi utiliser la notation native de grub ce qui fait que la commande précédente devient :
grub-install ‘(hd0)’

2ème étape : Installer la ou les distribution(s) secondaire(s)

Après avoir installée notre distribution principale et vérifier qu’elle bootait correctement, nous allons installer la distribution secondaire. En fait là où il faut faire attention, c’est le fait qu’il ne faut pas installer le chargeur de boot de la distribution secondaire dans la MBR !!!. Il faut installer le chargeur de boot dans une partition. Souvent on choisira la partition / ou /boot de la distribution secondaire. Dans notre cas nous choisirons la partition / ( /dev/hda3 ).

Lilo

Lors de l’installation, on peut normalement décider de l’endroit où l’on veut installer lilo. Sinon on peut modifier manuellement le fichier /etc/lilo.conf afin que lilo s’installe sur une partition. L’option boot devra être positionnée correctement, dans notre cas cela donne boot=/dev/hda3. Voici un extrait du lilo.conf de la distribution secondaire :
boot=/dev/hda3
map=/boot/map
prompt
nowarn
timeout=100
keytable=/boot/fr-latin1.klt
message=/boot/message
image=/boot/vmlinuz
label=”linux_sec”
root=/dev/hda3
initrd=/boot/initrd.img
append=”resume=/dev/hda7 hdc=ide-cd splash=silent”
vga=788
read-only

Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

Pour installer GRUB dans la partition / de la distribution secondaire, il suffira de lancer la commande suivante :
grub-install /dev/hda3
On peut aussi utiliser la notation native de grub ce qui fait que la commande précédente devient :
grub-install ‘(hd0,2)’

3ème étape : chainloader les autres chargeur de boot à partir du chargeur de boot de la distribution principale

Après avoir démarrer avec la distribution principale, on va ajouter les entrées nécessaires dans le fichier de configuration des chargeurs de boot afin de chainloader les autres chargeurs de boot.

Lilo

On va donc ajouter une entrée dans /etc/lilo.conf de type other, pointant vers le / de la secondaire ( /dev/hda3 ), qui permettra de charger lorsqu’on la sélectionnera le chargeur de boot de la distribution secondaire. Voic l’entrée que l’on ajoutera :
other=/dev/hda3
label=”distro_2″

Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

De même pour grub, on va modifier le ficher /boot/grub/menu.lst et ajouter l’entrée suivante :
title Distro secondaire           root (hd0,2)
chainloader +1

les changements seront pris automatiquement en compte par GRUB.

Voilà ! Normalement au prochain démarrage, lorsque vous sélectionnerez l’entrée correspondant à la distribution secondaire, vous tomberez sur son chargeur de boot et celui-ci vous permettra de la démarrer.

 

Comment utiliser urpmi –parallel

Ce HOWTO aura pour but de vous montrer comment utiliser la fonction d’installation parallèle d’urpmi.
Nous allons configurer urpmi afin qu?il mette à jour des postes clients depuis un serveur. Les postes clients ont pour nom DNS client1 et client2. Nous allons utiliser SSH pour faire la mise à jour

Configuration des clients

Sur les clients il convient juste de s?assurer qu?un serveur SSH est installé et qu?il autorise les connexions ( notamment de l?utilisateur root ).

Configuration et installation du serveur SSH

urpmi openssh-server

On édite le fichier de configuration du serveur SSH /etc/ssh/sshd_config et on le configure afin qu?il autorise les connexion de l?utilisateur root ( PermitRootLogin yes ) car par défaut ceci est désactivé :

# $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

PermitRootLogin yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don’t read the user’s ~/.rhosts and ~/.shosts file
s #IgnoreRhosts yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

X11Forwarding yes

UsePrivilegeSeparation yes

#Compression yes

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

On relance le service sshd afin que les modifications soient prises en compte :

service sshd restart

il conseillé de tester que l?on peut se connecter sur le serveur depuis l?ordinateur lui-même ou depuis un autre en tapant par exemple la commande suivante dans le cas du poste client1 :

ssh root@assistante2

Configuration des médias sur les clients

Pour ajouter les média sur les postes clients, on peut s?aider du site http://easyurpmi.zarb.org pour configurer les médias. Le Gestionnaire de média de rpmdrake peut aussi le faire de manière automatique. Par exemple pour ajouter de manière automatique les média main, contrib pour une Mandriva 2006 ( le nom des média sera préfixé par 2006_ ) :

urpmi.addmedia --distrib 2006_ ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2006.0/i586

Ensuite on ajoute le média pour les mises à jours de sécurité, normalement on peut le faire de manière graphique et automatique lors du 1er lancement de MandrakeUpdate :

urpmi.addmedia --update 2006_update_secu ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/updates/2006.0/RPMS/ with media_info/hdlist.cz

Si tous se passe bien alors on peut passer à la configuration du serveur.

 

Configuration du serveur

Configuration d’urpmi sur le serveur

Le serveur sera celui qui aura les média pour urpmi configuré et qui enverra les commandes aux postes clients.

  1. Tout d’abord on procède à l’installation du paquetage urpmi-parallel-ssh :
    urpmi urpmi-parallel-ssh
    
  2. On édite le fichier /etc/urpmi/parallel.cfg dans lequel on va définir une ligne du type : nom_du_groupe:protocole_utilisé:client1:client2
    Dans notre cas, nous voulons créer le groupe clients_grp qui regroupera les ordinateurs clients. On utilisera le protocole SSH pour communiquer avec eux. Les postes clients se nomment ( noms DNS ) : client1 et client2. Cela nous donne la ligne suivante :

    clients_grp:ssh:client1:client2
    
  3. on configure les médias sur le serveur, on peut s?aider du site http://easyurpmi.zarb.org pour configurer les médias. Le Gestionnaire de média de rpmdrake peut aussi le faire de manière automatique. Par exemple pour ajouter de manière automatique les média main, contrib pour une Mandriva 2006 ( le nom des média sera préfixé par 2006_ ) :
    urpmi.addmedia --distrib 2006_ ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2006.0/i586
    

    Ensuite on ajoute le média pour les mises à jours de sécurité, normalement on peut le faire de manière graphique et automatique lors du 1er lancement de MandrakeUpdate :

    urpmi.addmedia --update 2006_update_secu ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/updates/2006.0/RPMS/ with media_info/hdlist.cz
    

    Installation et Configuration du client SSH

    On installe le client SSH :

    urpmi openssh-client
    

    On génère la paire de clés privés/publiques SSH pour l?utilisateur root avec la commande ssh-keygen. On utilisera l’encryptage DSA et al clé sera stocké dans /root/.ssh/id_dsa :

    ssh-keygen -t dsa
    

    On copie la clé publique sur les postes clients client1 et client2 :

    ssh-copy-id -i ~/.ssh/id_dsa.pub root@client1
    ssh-copy-id -i ~/.ssh/id_dsa.pub root@client2
    

    Si tout s?est bien déroulée, on devrait pouvoir se connecter sur les postes client1 et client2 en tant que root sans fournir de mot de passe en utilisant par exemple la commande suivante à partir du serveur :

    ssh root@assistante2
    

    Note : On peut envisager de désactiver l?utilisation des mots de passes pour la connexion via SSH, pour cela il suffit de mettre PasswordAuthentication no dans le fichier /etc/ssh/sshd_config des postes clients ( client1 et client2 ).

    Bien que la commande urpmi soit parallélisée, la commande « urpmi.update » qui permet de mettre à jour les média ne l?est pas. Cela pourrait poser problème car les médias des clients et du serveur ne seraient plus synchrones. C?est pourquoi on va faire appel à un programme tierce qui permettra de lancer la mise à jour des média sur les différents postes en même temps. Se programme se basera aussi sur SSH pour fonctionner. Ce programme se nomme fanout et se trouve dans les média contrib. Pour l?installer il suffit de procéder comme suit :

    urpmi fanout
    

    Ensuite on lance la mise à jour des médias sur le serveur ( localhost ) et les 2 postes clients :

    fanout "localhost client1 client2" "urpmi.update -a"
    

    Si cela marche alors on peut faire un essai en lançant une mise à jour sur les postes clients avec urpmi –parallel, il suffit de préciser à la commande le groupe que l?on veut mettre à jour et ensuite de spécifier le paquetage que l?on veut installer. Pour faire une mise à jour de OpenOffice, on fera :

    urpmi --parallel  clients_grp openoffice.org
    

    Pour faire une mise à jour globale des systèmes, on fera :

    urpmi --parallel  clients_grp ?auto-select --auto --keep
    
    En éspérant vous avoir aidé !