Linux en boot PXE

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

Opensuse 10.2, le test

Comme d’habitude, je mirror les installs sur mon réseau local ce qui me permet d’être pénard pour les install suivantes; rien de nouveau là dessus sauf qu’une nouvelle fois il faut faire le tri pour le pas récupérer 30Go incluant des versions ppc qui ne me sont pas utile. Tout va bien si ce n’est la ligne wget un peu longue mais bon on aime ou on aime pas ;o).
Ensuite, je suis fdonc parti sur une install NFS et pour info, comme je ne souhaite pas trop m’embéter je réalise l’install dans une machine virtuelle VMWare, le tout tournant sous une Linux Suse 10.0. Au passage vive VMWare.. magnifique outil !

Gravage du CD de boot (70 Mo) ; config réseau détectée tout seul, config de l’install via NFS… tout va bien ! un sacré + puisqu’en 10.0 je n’ai jamais rèussi à installer en NFS et j’avais été contraint de graver les 7 cd !!!
Coté installeur YAST, rien de très nouveau, c’est propre et toujours assez simple. J’ai choisi une install par défaut KDE pour ne pas trop me compliquer la vie dans mes tests. Je ne comprends pas trop pourquoi le swap est installé sur la première partition, mais à part ce point ca va ; l’install KDE par défaut fait environ 2Go et YAST s’occupe de tout.

Comme d’habitude il ne faudra pas s’attendre à trouver les packages bien utiles comme java, acrobat reader les codec mp3 et autre … La distribution est 100% GPL et ne viole pas de breuvet logiciel. Dans les liens associés à cet article vous trouverez donc deux repository contenant les packages nécessaire pour tout cela. Le principal problème que je trouve à ca est que la mise à jour des patch de sécurité pour ces élément externes ajoutés n’est pas garantie. PackMap fait des efforts pour les mise à jour mais Suse Watcher ne les prend pas en compte et il n’y a aucun angagement. Bref mieux vaut ne pas les utiliser quand on peut éviter.

Après un peu plus d’utilisation et de déploiement sur differentes machines, j’ai trouvé à cette distribution pas mal de plus et un peu de contre. Coté plus, il y a la touche graphique, toujours mieux, la convivialité elle aussi toujours en progrès. Ce sont de très bonne choses. J’ai pu expérimenté Xen et quelques machines virtuelles. Super ! Bon, bien sure quelques deconvenues, surtout liées au noyau, peut etre opensuse a-t-elle voulue se doter d’un noyau trop récent ?!? n’empeche que le driver de ma ralink n’est pas supporté alors qu’en 10.0 il fonctionnait à merveille et que mes tentative pour utiliser un driver construit par mes soin et malgrès de nombreux post à ce sujet sur le net, n’ont abouti à rien.

J’ai rencontré pas mal de déconvenues avec mon portable (Del L400) :

  • Support de l’APM très moyen, les ventillos ne se declenchent pas et le cpu à finit en coupure thermique… assez desagreable
  • Détection anormal de sélection du bouton “sleep” (il n’y en a pas” qui conduit le système à rebooter sans-cesse en se mettant en “suspend-on-disk”). Ce qui se corrige simplement en modifiant l’evenement associé dans le fichier /etc/sysconfig/powersave/event
  • Pas de support de l’intel speedstep, ni des sensors

A part ca, une fois bien paramétré, le suspend-on-disk c’est du bonheur ! malgrès tout, j’ai fini par reinstallé une version 10 sur le portable pour eviter les déconvenues thermiques…
Coté installation serveur de developpement, tomcat, apache, eclipse sont bien packagés, je ne comprend pas trop la nouvelle organisation des répertoires pour ses applications, la version précédente avec tout dans le /opt me semblait plus simple même si il est vrai qu’elle etait peut etre moins standard.

A part ca je n’ai pas réussi à percer tous les mystères de la wallet à mot de passe utilisée pour le wlan et me demandant de saisir un mot de passe pour me connecter au réseau… alors qu’avec un init-level 3 ca se connecte tout seul… etrange ; comme la grande question subsidiaire ?!? comment change-t-on le mot de passe de sa wallet ?!? à creuser pour ma part.
Bref, quand j’aurai réussi à comprendre comment faire la mise à jour des packages (oui ca aussi ca a changé mais c’est pas clair non plus), je pourrai voir s’il y a eu des correctifs de faits par rapport aux problèmes évoqués plus haut et peut-être y reviendrai-je sur mon portable.

Vivement la 10.2… mais en tout cas, tout ca devient vraiment beau ;o)

Appeler la messagerie d’un destinataire

Ce message n’a pas grand chose à faire là et c’est un peu un inclassable mais bon … Petite note pour rappel sur comment obtenir directement la messagerie d’un correspondant plutot que de faire sonner son GSM. Pour France télécom, il faut composer le 06 80 80 ab cd avec abcd tel que le numéro du destinataire est 06 ab cd ?? ??. Pour SFR, il faut appeler le 06 12 00 12 12
Ensuite, se laisser guider par le système vocal.

Paramétrage mémoire d’une JVM

Plusieurs paramètres permettent de configurer la JVM et entre autre sa gestion de la mémoire. Tout d’abord les paramètres -Xms et -Xmx qui indiquent respectivement la taille mémoire initiale et la taille mémoire maximum. Ces limites sont fixées en ajoutant après le parametre la quantité de mémoire et son unité, ce qui donne par exemple -Xms256M -Xmx512M pour une initialisation à 256Mo pouvant être étendue à 512Mo. En général il est recommendé d’utiliser les même valeurs pour l’un et l’autre des paramètres, ceci dit je ne suis pas totalement d’accord avec cette configuration qui revient à bloquer de la mémoire pour rien.

Ce premier paramétrage est le plus simple il est toutefois primordial car la JVM carsh assez violement lorsqu’il n’y a plus de mémoire.
Vient ensuite la gestion du garbage collector, définie par le paramètre -Xmn. Il existe deux type de garbage : le premier est une libération rapide de la mémoire la seconde une libération plus fouillée ; cette dernière ralenti par contre les performance du système.
Pour comprendre l’utilisation de ce paramètre, il faut comprendre la gestion de la mémoire Java. En deux mots, Java alloue les objet dans un espace appelé Eden, lorsque cet espace est plein (quand il passe le seuil fixé par -Xmn) le GC vide au mieux cet espace. Les éléments qui ne peuvent être libérés car toujours utilisés sont migrés vers un autre espace (old space). Une libération plus complète sera effectué lorsque l’on va attendre la limite de Xmx (max) – Xmn. Le paramètre est important car il joue directement sur les perf de la machine : S’il est trop petit, des objets de l’eden même récents vont être transférés vers l’espace mémoire des ancien : la mémoire va être consommé plus vite et il y aura plus régulièrement de gros ralentissements liés au passage du garbage collector.

LANG (charset) par défaut d’une JVM

Par defaut, la variable $LANG permet de choisir l’encoding par defaut de la JVM. Cette variable est dans /etc/sysconfig/i18n

Pour forcer un notre encodage, il est possible de passer l’option -Dfile.encoding=ISO-8859-1″ comme paramètre de la JVM ; ceci permettra de considére ce charset pour les fichiers lus par la JVM. Pour que tomcat serve des pages dans cet encoding il faudra ajouter :-Djavax.servlet.request.encoding=ISO-8859-1
Dans les dernieres version d’openSuse le fichier i18n n’existe plus, il faut alors ajouter ce parametres aux parametres de le JVM dans le fichier j2ee puis relancer tomcat. Il est aussi possible de passer par /etc/sysconfig/langage pour changer la variable $LANG

Cette solution permet de fixer le charset par defaut dans le mode souhaité qui doit etre le même que celui d’apache quand on utilise l’ajp13 ; à UTF-8 ou WEBISO-8859-1 … ou autre

Etat de la JVM d’un serveur d’application

Pour connaitre l’etat de la JVM d’un serveur d’application, du moins la mémoire qui lui reste et celle qu’il utilise, il faut accéder aux fonction de la classe Runtime ce la-dite JVM.

La jsp suivante affiche les principales informations :
<HTML>
<HEAD></HEAD>
<BODY>

<%java.lang.Runtime.getRuntime().gc();%>
— JVM MEMORY AVANT GARBAGE —<BR>
Total Memory : <%=java.lang.Runtime.getRuntime().totalMemory()/(1024*1024)%>Mo<BR>
Free Memory : <%=java.lang.Runtime.getRuntime().freeMemory()/(1024*1024)%>Mo<BR>
Max Memory : <%=java.lang.Runtime.getRuntime().maxMemory()/(1024*1024)%>Mo<BR>
<BR>

<%java.lang.Runtime.getRuntime().gc();%>

— JVM MEMORY APRES GARBAGE —<BR>
Total Memory : <%=java.lang.Runtime.getRuntime().totalMemory()/(1024*1024)%>Mo<BR>
Free Memory : <%=java.lang.Runtime.getRuntime().freeMemory()/(1024*1024)%>Mo<BR>
Max Memory : <%=java.lang.Runtime.getRuntime().maxMemory()/(1024*1024)%>Mo<BR>
<BR>
Proc Dispo : <%=java.lang.Runtime.getRuntime().availableProcessors()%><BR>
</BODY>
</HTML>

Gestion des Cookies dans un ensemble de pages JSP avec @include

J’ai rencontré pas mal de problèmes avec les JSP est les cookies, ces derniers sont assez utile pour laisser quelques traces et configuration sur le client de l’internaute qui peuvent être utiles pour l’optimisation de la navigation sur un site ou pour la suivi des statistiques.
Lors de l’intégration dans un contexte JSP utilisant des includes, il y a pas mal de petites règles à respecter pour que cela fonctionne sans quoi il y a moyen de s’arracher les cheveux !

Ce qu’il faut avoir : les Cookies doivent être envoyé dans l’entête de la réponse. Lorsque les pages générées sont de taille importante, le seveur d’application peut envoyer la page par morceaux dès qu’il y a suffisemment de données pretes. Du coup, si l’ajout du cookie est fait après le premier flush, il ne sera pas pris en compte. Il est donc important que les Cookie soient placés suffisemment tot dans la page pour éviter le flush.
Dans un contexte d’utilisation avec des include de JSP, il faut savoir en plus que le tag jsp:include a tendance à déclencher des flush (ce qui me semble étange puisque le fulsh peut être passé en option et que par défaut il ne l’est pas). Du coup, si le cookie est enregistré par une sous JSP, il ne sera pas pris en compte par le navigateur ; arrivant trop tard. La solution dans ce cas est d’utiliser un tage @include à la place du jsp:include, mais attention son utilisation est très différente puisque dans ce cas il s’agit de l’import du source importé avant la compilaton de la JSP et non de l’appèle à une autre JSP. Ce qui peut poser des problème si la modification est faite à postérieuri.

Bref, ma solution dans ce cas, réunir dans un fichier d’entête toutes les opération intervenant sur les Cookies et intégrer cette page au travers d’un @include dans toutes les pages du site en entête. L’utilisation généralisée du @include etant à proscrire à mon avis.

Modification du timeout des sessions avec tomcat

Pour modifier le timeout des sessions d’une webapp sous tomcat, il suffit d’ajouter les lignes suivantes dans le fichier web.xml :

<session-config>
<session-timeout>30</session-timeout>
</session-config>