L’objet de cet article est de décrire l’installation d’un petit linux sur une machine sans disque dur (network boot). Pour l’occasion, j’ai a ma diposition un monstre de puissance (sic) a savoir une Dell PIII550. Marchine au demerrant très silencieuse … impec !
Cette machine permet le boot PXE. Ce systeme permet de faire booter une machine sur le réseau sans avoir a programmer le prom sur la carte reseau. Un peu comme le DHCP permet d’obtenir une adresse IP.

Pour commencer j’installe sur le serveur (celui qui contient le HD) (une suse 10.0) le serveur atftp qui est recommandé plutot que le classique tftpd proposé par Yast. Sa configuration se fait en modifiant le fichier /etc/sysconfig/atftpdavec les options suivantes ;

ATFTPD_OPTIONS="--daemon --user tftp -v"
ATFTPD_USE_INETD="no"
ATFTPD_DIRECTORY="/srv/tftp"

Avant de lancer le demon, il sera nécessaire de créer un utilisateur tftp sur le systeme. Le demon se lance ensuite par la commande /etc/rc.d/atftpd restart

Le package syslinux fournit une image bootable. Il faut alors la copier de /usr/share/syslinux/pxelinux.0 vers le répertoire tftpboot choisi lors de l’installation du serveur. TFTP est un protocole réseau de transfert de fichier (Trivial File Transfert Protocol) ; ce protocole est suffisemment simple pour qu’un périférique comme une carte réseau puisse l’utiliser sans qu’un OS ne soit démarré.

Il faut ensuite créer un petit fichier de configuration pour indiquer sur quel noyau booter. Les noyaux sont disponible sur suse dans le repetoire d’installation /boot/loader/. Il faudra donc copier initrd et linux dans le répertoire tftpboot puis créer un fichier tftpboot/pxelinux.cfg/default contenant les informations ci-dessous :

default linux

 # Install Linux
 label linux
   kernel linux
   append initrd=initrd splash=silent showopts

 prompt   1
 timeout  10

A noter qu’au lieu de s’appeler default, il est possible de donner comme nom l’adresse MAC du client sous la forme ee-ff-gg-aa-bb-cc-dd ce qui permet d’avoir des configurations différentes par client.

Il est ensuite nécessaire de configurer le serveur DHCPD. Ce qui se fait avec Yast sans problème. Il faut ensuite ajouter une entrée spécifique pour cet hote dans le fichier /etc/dhcpd.confqui aura la forme suivante :

host target_host {
     hardware ethernet xx:xx:xx:yy:yy:yy;
     fixed-address 10.0.0.???;
     server-name "10.0.0.???";
     filename "/tftpboot/pxelinux.0";
}

Le champ hardware ethernet correspond à l’adresse MAC du client. qu’il faudra que vous trouviez (ifconfig permet de l’avoir par exemple). Le champ fixed-addrress correspond à une adresse IP que l’on affecte au client. server-name correspond à l’adresse IP du serveur tftpd et filename au fichier que nous avons précédemment copié et qui sera utilisé pour le démarrage du client.

Il ne reste plus qu’à booter le client et comme par magie (héhé) il va démarrer sur l’image mise à sa disposition depuis le serveur !
Cette image telle que décrit permet de démarrer l’installation de la suse …

Tout cela est bien joli, mais ce n’est aps exactement ce que je cherchais… Mon objectif booter un linux dejà installé ! Donc pour ca il me faut installer une linux dans un répertoire … et celà se fait simplement avec Yast. Ensuite, il faut modifier le fichier tftpboot/pxelinux.cfg/default pour le faire pointer vers le noyau créé par Yast lors de l’install précédente … Sauf que bien sure ce n’est pas si simple puisque le noyau par defaut n’a pas de resau et qu’il faudra donc s’en compiler un avec les modules réseaux nécessaires.

Il faut donc compiler un noyau avec les options suivantes :

• Le driver de la carte réseau doit être compilé dans le noyau et non en module
• Le noyau doit être capable de configurer son réseau durant le boot en demandant une ip au serveur DHCP. Ceci est activé dans le menu Networking-TCP/IP – networking par l’option Kernel level autoconfiguration
• Le noyau doit être capable de monté son FS racine depuis un lien NFS. Cette option se configure dans File systems-Nework File Systems-NFS-Root file system on NFS.

Une fois compilé avec ces options (make bzImage) le nouveau noyau disponible dans arch/i386/boot/bzImage peut être copié en temps que vmlinuz dans l’arborescence vu tftpboot.

Il faut enfin modifier le fichier tftpboot/pxelinux.cfg/default comme suit :

default linux
label linux
  kernel vmlinuz
  append root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=IP_du_seveur_nfs:rep_nfs_partage initrd=initrd
prompt   1
timeout  10

Comme il arrive que l’impression par défaut configurée par Mozilla déconne un peu, il est possible d’utiliser l’impression KDE.
Pour ce faire, afficher l’écran de propriété de l’imprimante sous Mozilla (après avoir obtenu la fenetre d’envoie d’un impression) puis remplacer la ligne lpr ${MOZ_PRINTER_NAME … par kprinter –stdin

Petit problème que j’ai pu rencontrer lors d’une utilisation de dual-screen : KDM demarre sur le premier écran qui n’est pas toujours celui que l’on souhaite utilisé par défaut.
Pour modifier celà il existe une option qui peut être ajoutée dans le fichier kdmrc (/etc/opt/kde3/share/config/kdm/kdmrc sur suse) :
Dans la section [X-*-Greeter], ajouter la ligne GreeterScreen=1 par exemple pour que celui-ci soit affiché sur l’ecran n°1 …

En avant propos, je tiens à dire que je suis un utilisateur convaincu et ravi de Suse depuis 4 ans environ et de puis la Suse 8. Je ne suis pas un fan de la dernière option de la dernière version du dernier soft qui vient de sortir, mais je demande plutot à mes systèmes d’être stable, de tourner 24/24 et de me fournir les outils nécessaire à mon utilisation : development web/java/vhdl/c/c++, bureautique de base et internet. Voila pour le cadre de façon général. Coté existant en place j’ai actuellement 2 serveurs en suse 9.0 + 1 serveur et 1 poste de travail en suse 9.2. A l’occasion d’un crash, dont vert de honte, je vous tairai la cause, je suis passé en Suse 10 ; j’en profite pour livrer mes premières impressions :

Comme a l’habitude, je n’aime pas bien utiliser les distributions sur CD :

• Parce que changer les cd c’est chiant
• Parce que ca coute
• Parce que donner 1.5 euro aux auteurs compositeurs pour graver une distribution Linux me désole
• Parce que de toute façon les cd ne servent qu’une dizaine de fois grand max, avant d’etre obsoletes

Bref, je décide d’installer une version en réseau et fais donc comme d’habitude un mirroir de l’instal live en local pour une installation future. Là, je dois dire que j’ai rencontré ma première déception, lorsque je me suis rendu compte que je venais de télépcharger 30Go incluant les version 32bits, 64 bits, ppc … + les sources. Suse m’a habitué à mieux organiser ses répertoire pour eviter celà ! La synchronisation, une fois ménage fait avec le mirroir n’est donc pas vraiment évidente avec une ligne d’exclusion dans le wget plutot gigantesque. Mais finalement s’est fait. Je grave le cd de boot et démarre l’install.

Installation réseau de le suse 10.0

Tout commence bien, jusqu’à ce que … l’installation propose un partitionnement par défaut assez interressant puisqu’il a m’a directement proposé de formater l’espace disque contenant la source de donnée … original ! Ceci étant dit, la proposition par défaut n’etant que rarement interressant, c’est juste une bonne blague qui m’aura fait sourir. Là ou j’ai moins rigolé c’est lorsque l’install a planté à cause de paramètres incohérents dans mon partitionnement, relatif à l’usage de Raid1. Car, bien sure, je venait de passer 30 minutes à faire ma sélection de packages. J’ai ensuite beaucoup moins rigolé lorsque ce même temps passé a de nouveau été perdu alors qu’en plein milieu de l’installation le disque contenant les données s’est auto-démonté … opération mystérieuse et désastreuse.

Installation CD de la Suse 10.0

Après avoir passé pas mal de temps sur de nouveau essais, j’ai dû me résoudre a passer sur une install CD. J’ai donc téléchargé et gravé les 3 premiers espérant que cela suffise. j’ai ensuite choisi une installation par défaut et j’ai une nouvelle fois été trés déçu de constater qu’il me fallait graver le cd4 pour 50 Mo et le CD 5 pour 2Mo … n’aurait-il pas été possible de mettre ces 52 Mo sur le CD 2 ou 3 alors que ceux-ci ne sont pas par défaut utilisés à 100% pour une install standard ?!?
Bref, l’installation se passe bien, mon système boote, je suis heureux .. mais jusqu’à ce que …

Les moins de la suse 10.0

Outre l’installation désastreuse, je ne suis pas satisfait par certains points :
Le dual head d’abord : avec les Suse 9.0 et 9.2, l’installation s’est passée sans problème, mes deux écrans etaient configurés de façon indépendante et leur résolution différait sans problème. Lors de l’installation, la configuration proposée par défaut n’a tout d’abord pas permie de démarrer X-Windows. Une fois reconfigurée, je suis maintenant contraint d’avoir un écran dans sa résolution normale : 1280×1024 et un second écran en virtual screen 1024×1024 car ne supportant pas de fréquence plus élevée. La configuration de Xorg ne me permettant pas de modifier cela. Outre ce problème, l’ecran primaire n’est pas mon écran principal … du coup il a été nécessaire de modifié les paramètres de kdm (GreeterScreen) pour ne pas être obligé d’alumer les deux écrans pour se logguer. Je vous ennuie avec mes cas particuliers perso mais ce que je trouve domage c’est qu’il s’agisse d’une forte régression par rapport à ce qu’apportait la version 9.2.

Second point négatif : les outils Java ne sont pas distribués dans la version de base, il est necessaire de les télépcharger à part, l’opération n’est pas très compliquée mais elle n’est pas non plus facile pour tout le monde et de fait, il n’y a pas de JRE de base ; domage pour la consultation sur Internet.

Ensuite, la Suse 10 n’est pas non plus livrée avec les outils nécessaire à la lecture de MP3 (ni de divx mais là je suis habitué). La raison est totalement louable, distribuer un player de MP3 sous GPL revient à violer un breuvet logiciel (ce qui met bien en évidence le risque pour l’open source à la généralisation des breuvet logiciel) toutefois, en Europe ces breuvet ne sont heureusement pas applicable et une version Europe avec MP3 aurait évité une fastidieuse étape de recompilation des outils livrés. La version 9.2 (et 9.0) intégrait sans aucun scrupule les librairies adéquates.

Pour l’instant j’en suis là, et j’espere que ce sera tout

Les plus de la suse 10.0

Bien sure il n’y a pas que du moins et pour preuve la distrib est toujours installé sur mon poste. Le mieux se résume tout simplement à des nouvelles versions des logiciels habituels, OpenOffice 2, noyau 2.6.13, Kde 3.4… Ca a l’air stable et les performances sont correctes mais ceci est subjectif.

En Bref

Suse m’a habitué a des version xx.0 toujours un peu moins bonnes que les xx.1, xx.2 ou xx.3. mon conseil est donc plutot d’attendre la version suivante pour une migration plannifiée mais si c’est forcé, la 10.0 fera l’affaire ; plutot à partir de cd a moins que vous ayez plus de chance que moi. Attention aux utilisateurs de dual-screen et mp3. Mais en tout cas, je reste fidèle (pour cette fois).

Pour mettre a jour votre suse avec les package (non officiel) répondant à vos besoins multimédia, voir le lien “Custom” ci-contre …

MRTG, le célèbre outil de monitoring réseau peut être utilisé pour suivre n’importe quel indicateur système pour peu qu’on lui fournisse les bonnes données… voici un exemple avec un monitoring de la mémoire utilisée :

Tout d’abord pour trouver la mémoire totale et la mémoire utilisée, il nous faut écrire un petit script basé sur la commande free -m. Ce script extrait la mémoire totale et la mémoire utilisée, soit la mémoire totale – mémoire libre – mémoire cache :

#!/bin/bash
MemTotal=`free -m | head -2 | tail -1 | tr -s ” ” | cut -d ” ” -f 2`
MemUse=`free -m | head -3 | tail -1 | tr -s ” ” | cut -d “:” -f 2 | cut -d ” ” -f 2`
echo $MemUse
echo $MemTotal
echo “0 day(s)”

Il se termine par l’affichage des deux valeurs sur la sortie standard suivi d’un temps d’uptime de 0 jour par défaut. Ce format de sortie est celui attendu par MRTG.
La première ligne indique la valeur à utiliser pour la ligne de graphique bleue ; la seconde est utilisée pour tracée l’air de graphique verte.

Pour terminer, il faut paramétrer MRTG et donc modifier mrtg.conf en ajoutant une entrée comme suit :

Target[linux_mem]: `../bin/memory`
Title[linux_mem]: MEMORY LOAD
PageTop[linux_mem]: Memory LOAD Mo
WithPeak[linux_mem]: dwmy
Unscaled[linux_mem]: ymwd
ShortLegend[linux_mem]: Mo
MaxBytes[linux_mem]: 1024
YLegend[linux_mem]: Stat Memoire
LegendI[linux_mem]: Memoire utilisee:
LegendO[linux_mem]: Memoire totale:
Legend1[linux_mem]: Memoire utilises en Ko
Legend2[linux_mem]: Memoire total en Ko
Legend3[linux_mem]: Pic de mémoire utilisée
Legend4[linux_mem]: Pic de mémoire totale
Options[linux_mem]: growright, integer, nopercent, gauge

La première ligne contient le chemin absolue vers la commande à lancer pour obtenir les données du graphique.

La synchro entre le palm et le PC sous win XP au travers de l’infrarouge n’est malheureusement pas toujours surper aisée à mettre en oeuvre… pour ma part j’ai du chercher un moment avant de trouver la bonne solution.
Une fois l’IR installé sur le portable et HotSync configuré pour accepter la synchro IR, il faut encore vérifier quelques points dans la config de la “liaison sans fil” avant de faire fonctionner la synchro… Dans le panneau de configuration, dans le gestionnaire des Liaison sans fil, il faut vérifier que :

1- Le Transfert d’image ne soit pas activé
2- Dans les propriété du Matériel, puis dans Avancé le paramètre Speed Limit soit bien à 57.6kbps

Une fois celà vérifié, la synchronisation devrait bien se passer et le message “port utilisé par une autre application” devrait disparaitre..

Vous souhaitez transférer de façon automatique une fichier via scp au travers d’un script sans que celui ne vous demande de saisir un mot de passe …
Ceci est tout à fait possible en utilisant le mode Batch de scp avec une authentification par partage de clef publique. Le système est simple à mettre en oeuvre :

Sur la machine depuis laquelle on souhaite se connecter :
Pour commencer il faut créer pour l’utilisateur qui va executer le script un couple de clefs publiques/privées. Pour ce, lancez pour cet utilisateur la commande ssh-keygen -t dsa en repondant par Entrée à chaque question. Cette commande va créer deux fichiers dans le répertoire ~/.ssh : id_dsa et id_dsa.pub.

Sur la machine sur laquelle l’on souhaite se connecter :
Copiez ensuite le contenu du fichier id_dsa.pub dans le fichier ~userCible/.ssh/authorized_keys. userCible étant l’utisitateur sous lequel vous allez vous connecter lors du transfert sur la machine distante.
Enfin, vérifier les doits d’accès qui doivent être 700 pour le répertoire .ssh et 644 pour le fichier authorized_keys.

Tester

Maintenant l’accès à la machine cible se fait simplement par la commande suivante : scp -B -i ~/.ssh/id_dsa userCible@destination:~/