Controler la vitesse des ventilateurs d’une carte mère

Sur les dernières cartes mère, il est possible de contrôler via soft la vitesse des ventilateurs (fan-control). Cette fonctionnalité permer de jouer sensiblement sur le bruit de la machine.

Sur les carte MSI KT8 (utilisant un chip NForce 3 équipée d’un chip w83627thf) il est possible de controler la vitesse des ventilateurs au travers du périphérique associé dans /sys (pour peu que vous soyez bien en noyau 2.6)

La commande suivante permet celà :
echo $valeur > /sys/bus/i2c/devices/2-0290/pwm1
$valeur est un nombre entre 0 et 240. 0 étant l’arret complet du ventilateur. pwm1 correpond au premier ventilateur. La carte peut en gérer 3 qui seront alors pwm1, pwm2 et pwm3.

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

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.