Le Monde, toujours sans pub pour moi

Rédigé par jdrien - - aucun commentaire

Ce matin, sur le site lemonde.fr, une nouvelle page d'accueil :

lemonde.fr antipub

Pour la rédaction du journal : le modèle économique basé sur la publicité ne fonctionne pas. Je n'en veux pas. Le modèle sur abonnement ? J'ai déjà quantité d'abonnements à des journaux et ou magazines. Proposez-moi autre chose, mais en tout cas la culpabilisation ne fonctionnera pas. Si la rédaction du journal n'a toujours pas compris cela, désolé pour eux. Dernière chose : je n'autorise pas le journal à savoir si j'utilise ou non un bloqueur de publicité. Je n'autorise pas non plus ce journal à savoir comment je lis leur contenu. Le site Internet du journal est publiquement accessible et j'utilise les outils que je veux.

 

Donc le monde tournera sans moi. Tant mieux pour eux sans doute.

 

1984, ironie du destin

Rédigé par jdrien - - aucun commentaire

En regardant 99 Francs l'autre soir, j'ai vu un court extrait d'une ancienne publicité pour Apple. Intitulée 1984, cette publicité est incroyable avec le recul que l'on a maintenant. Quelle ironie !

L'article sur wikipedia est assez bien fait (même très bien !).

automysqlbackup ou l'art de ne pas réinventer la roue

Rédigé par jdrien - - aucun commentaire
On trouve très souvent des personnes qui publient sur leur blog des scripts qui leur permettent de sauvegarder leurs bases de données avec MySQL. Ces scripts faits maison sont nombreux et tentent de répondre précisément aux besoins des rédacteurs.

En fait, la sauvegarde à chaud des bases de données simples est tellement évidente sous MySQL (un bête mysqldump suffit a priori) que l'on est vite tenté de réinventer la roue et de repartir de zéro. On arrivera certainement à un résultat satisfaisant, mais on sera sans doute passé à côté de fonctionnalités ou de problèmes importants (externalisation des sauvegardes, nettoyage, sécurité etc).

C'est suite à la publication sur le Planet Debian d'un énième script de ce type que j'ai appris qu'un outil intégré dans les dépôts de Debian existait : automysqlbackup.

Sous Debian donc, un simple sudo apt-get install automysqlbackup suffit à mettre en place une solution rapide de sauvegarde des bases sous MySQL.

D'origine, on arrive à un résultat très satisfaisant :
 - toutes les bases sont sauvegardées dans des répertoires bien ordonnés ;
 - les sauvegardes sont quotidiennes, hebdomadaires et mensuelles ;
 - les sauvegardes sont gérées par cron ;
 - pas d'utilisateur à renseigner : on utilise le mécanisme interne de debian (utilisateur MySQL debian-sys-maint) ;
 - les sauvegardes sont compressées ;
 - les sauvegardes sont nettoyées au fur et à mesure selon la durée de rétention définie.
 
Avec un peu de configuration on peut (fichier /etc/default/automysqlbackup) :
 - compresser les données avec bzip2 au lieu de gzip ;
 - exclure certaines bases ;
 - transmettre les logs de la sauvegarde par mail ;
 - effectuer des pre-traitements ainsi que des post-traitements : ainsi on peut facilement faire un rsync vers un autre serveur.

Bref, rien ne sert de réinventer la roue ! Et comme l'écrit Thomas Goirand, mainteneur du paquet pour Debian dans son commentaire à propos d'un script de sauvegarde :
Hi,
I'm the maintainer of automysqlbackup. Actually, you should really have a look into automysqlbackup. You thought about few of the problems you may have when doing backups, like the umask, and some others, but you forgot lots of them, and your script is missing many features of automysqlbackup (like daily, weekly, and monthly backups, which covers absolutely all needs). The nice part of automysqlbackup is also that it lived inside Debian for a large amount of time, and gathered feedback from users, which means that many, many, many small problems have been fixed in it. Over the years, I can even say that it's now a fork from the original code (it's unfortunate, and happened because of many things that I added in the package, plus upstream not adding them and releasing a new version which was really different and impossible to merge back).

I would strongly suggest to not work on your own, that's always less good than working as a team. If there's something that is missing in automysqlbackup (actually, I don't think there is), then it can be added, and I would welcome you to contribute patches.
PS : bien sûr, l'expérience de l'écriture de sa propre solution de sauvegarde peut être bénéfique sur le plan des connaissances. On comprend alors vraiment les choses. Et quand on voit des outils comme automysqlbackup on comprend justement qu'il est illusoire de croire que l'on peut penser à tout tout seul...

Rions un peu ou le ridicule ne tue pas (pas assez)

Rédigé par jdrien - - aucun commentaire
Rions un peu dans ce monde de brutes. A propos du documentaire "Une contre histoire de l'Internet", on s'amusera de la critique de telecablesat.fr :
Un embrouillaminis de jargon geek et de propos railleurs visant à défendre un Internet débridé sans la moindre régulation.

[telecablesat.fr, critique du 14/05/2013 du documentaire "Une contre histoire de l'Internet" - Lien]

Juste énorme.

Et pour ceux qui voudraient voir de quoi il retourne :
magnet:?xt=urn:btih:9aee1cbd18e735a3915da6011d0cfe7a4c700f59&dn=%5B+ARTE+%5D+Une+contre-histoire+de+l%27Internet+-+x264+720p+A3C&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Fopen.demonii.com%3A1337

(via http://thepiratebay.tn/torrent/8466371/%5B_ARTE_%5D_Une_contre-histoire_de_l_Internet_-_x264_720p_A3C)

Profitons que Internet soit débridé alors !

Quelques aventures avec ntp

Rédigé par jdrien - - aucun commentaire
Ce billet va présenter deux problèmes liés aux décalages avec les serveurs de référence de temps que j'ai rencontré il y a quelque temps sur les serveurs que j'administre.

Autant sur un PC bureautique il n'est pas nécessaire de se préoccuper de la finesse de la synchronisation avec les serveurs de temps (une simple mise à l'heure par ntpdate @server_de_temps au boot devrait suffire), autant le problème de la gestion de l'horloge est primordiale dans un contexte de serveur. En effet, outre le fait que le serveur ne sera que rarement rebooté et donc que la solution du ntpdate au boot est alors inadaptée, il est nécessaire que l'horloge interne du serveur soit correctement gérée à la fois pour les échanges avec les autres serveurs et pour les applications hébergées sur ledit serveur. De nombreuses applications nécessitent une gestion du temps monotone et ne supporte pas les remises à l'heure violentes.

Nous avions régulièrement des serveurs qui avaient un décalage trop important avec leurs serveurs de référence. Normalement, si le décalage est acceptable alors le démon ntpd va progressivement rattraper la dérive, petit à petit. Mais si le décalage est trop important, alors la synchronisation sera forcée. Et ce n'est pas bien !

On voit apparaître les messages suivants dans la log du démon ntpd :
time reset -0.291613 s

Ces time reset sont assez violents ; ils interviennent si le décalage n'est pas compris entre -0.128s et 0.128s. On peut obtenir facilement le décalage actuel par la commande suivante :
# /usr/sbin/ntpdate -q @IP_serveur_de_temps
server @IP_serveur_de_temps, stratum 6, offset -0.013661, delay 0.02574
 1 Aug 14:09:07 ntpdate[9017]: adjust time server @IP_serveur_de_temps offset -0.136612 sec

 
Ici le décalage est -0.136 seconde, donc trop important.

Nous avons pu voir deux cas différents :
 - le décalage est dû à un bug dans le firmware du serveur ;
 - le décalage est dû à un mauvais choix dans la source de temps choisi par le système.

Suite à une mise système sur des serveurs (passage en noyau 2.6.18), nous avons pu observer des décalages fréquents et des resynchronisations plusieurs fois par jour.
 
Premier cas : quand un bug de firmware entraîne des décalages de temps...
Il faut savoir que le noyau 2.6.18 utilise comme source de temps hpet (High Precision Event Timer) et non plus tsc (Time Stamp Counter) comme avant (pour plus d'information sur les sources de temps disponibles on peut lire le document http://www.makelinux.net/books/ulk3/understandlk-CHP-6-SECT-1).

 - pour vérifier la source de temps utilisée :
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

 - pour visualiser les sources disponibles :
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies hpet tsc


- il est fortement conseillé d'utiliser hpet qui doit être le plus précis normalement. J'ai effectué un test en changeant hpet par acpi_pm et la dérive était toujours importante :
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

Le problème est que sur les serveurs que nous utilisions, des IBM x3850, un bug dans le firmware génère une dérive système importante. La version du firmware a donc un impact sur la gestion système du temps. Pour être honnête nous n'avions jamais pensé à regarder du côté des composants matériels pour contrôler cette gestion du temps !

Extrait du changelog du bios en v1.05 :
    *  IBM BIOS Flash Update System x3800/x3850/x3950/x3950E
          - Version 1.05, ZSE122A    (Suggested)
          > Problem(s) Fixed:
              - Fix operating system time drift, while using HPET.

              
Bien sûr nous utilisions une version plus ancienne (v1.04) qui était atteinte de ce fameux bug !

Nous avons pu procéder à la mise à jour du firmware, et depuis plus de soucis. La précision est au rendez-vous. J'ai effectué quelques mesures pendant deux jours avant la mise à jour du firmware : avec une prise de mesure par minute, la dérive moyenne constatée est de -0.224423 seconde. Cette dérive moyenne obligeait le démon ntpd à forcer la synchrnonisation environ 6 fois par jour. Après la mise à jour du firmware, nous avons constaté une dérive moyenne de 0.000773 seconde et plus aucune synchronisation forcée.

Second cas :
Si on peut mettre à jour un composant de type hpet pour améliorer la fiabilité, tant mieux. Mais si on ne dispose de ces composants ? C'est ce qui s'est passé sur un autre serveur, encore plus antique que les IBM x3850 du point précédent.

Dans le fichier de log de ntpd j'ai pu remarqué que les synchronisations forcées sont nombreuses (plus de 4 par jour parfois) :
     7 Aug 01:06:03 ntpd[17849]: time reset -0.167096 s
 
La dérive est donc importante et les écarts fluctuent.
Sur ces vieux serveurs, nous n'avons pas la chance d'avoir un composant type HPET et nous ne pouvions certainement pas chercher du côté des mises à jour de firmware.

Nous allons donc tenter de trouver une meilleure horloge.
 
Liste des sources de temps disponibles :
    [root] # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    acpi_pm jiffies tsc pit


Ces sources sont présentées dans l'ordre de préférence.
 
La source utilisée :
    [root] # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    tsc


Avec cette source (TSC : Time Stamp Counter) la moyenne du décalage est de 0.013591 seconde.
 
J'ai changé la source pour utiliser acpi_pm :
    echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

J'ai supprimé le fichier drift et j'ai relancé ntpd.
 
Depuis la modification la moyenne du décalage est de -0.003481 seconde. Pour que cette modification soit prise en compte lors du prochain reboot, il faut ajouter l'option clocksource=acpi_pm au noyau dans le fichier /boot/grub/grub.conf.
 
Pour plus d'information sur les horloges, voir la page http://www.makelinux.net/books/ulk3/understandlk-CHP-6-SECT-1.

Conclusion : si un décalage se produit, il faut toujours faire à la qualité de la source de temps interne au serveur.

Bilan : habituellement en cas de problème NTP (dérive, resynchronisation etc.) on aura tendance à chercher du côté de la configuration du démon ntpd, d'un bug dans ledit démon ou bien encore on aura tendance à chercher du côté des serveurs de référence. Bref, on restera à un niveau applicatif pour ce module système et on ne cherchera pas nécessairement au niveau système pur (gestion des firmwares, configuration des paramètres du noyau).

Epic Hack, Episode IV

Rédigé par jdrien - - aucun commentaire
$ traceroute -m 100 216.81.59.173
traceroute to 216.81.59.173 (216.81.59.173), 100 hops max, 60 byte packets
 1  livebox (192.168.1.1)  7.247 ms  7.327 ms  8.081 ms
 2  80.10.127.12 (80.10.127.12)  41.506 ms  41.503 ms  43.345 ms
 3  10.125.230.202 (10.125.230.202)  43.344 ms  43.445 ms  44.700 ms
 4  ae45-0.nista202.Paris.francetelecom.net (193.252.99.242)  47.170 ms  47.171 ms  64.202 ms
 5  81.253.184.90 (81.253.184.90)  66.739 ms  71.804 ms *
 6  * xe-0-1-0-0.auvtr3.Aubervilliers.opentransit.net (193.251.132.242)  60.580 ms  61.833 ms
 7  tiscali-2.GW.opentransit.net (193.251.254.70)  63.739 ms  54.566 ms  56.011 ms
 8  xe-5-0-0.atl11.ip4.tinet.net (89.149.180.206)  167.807 ms xe-7-0-0.atl11.ip4.tinet.net (141.136.108.138)  168.096 ms xe-3-2-0.atl11.ip4.tinet.net (89.149.182.217)  169.351 ms
 9  epik-networks-gw.ip4.tinet.net (77.67.69.158)  175.603 ms  176.230 ms  177.781 ms
10  po0-3.dsr2.atl.epikip.net (216.81.59.2)  175.751 ms  175.577 ms  176.204 ms
11  * * *
12  Episode.IV (206.214.251.1)  211.211 ms  213.140 ms  181.086 ms
13  A.NEW.HOPE (206.214.251.6)  235.821 ms  236.381 ms  233.823 ms
14  It.is.a.period.of.civil.war (206.214.251.9)  192.529 ms  192.397 ms  192.179 ms
15  Rebel.spaceships (206.214.251.14)  224.575 ms  223.187 ms  190.889 ms
16  striking.from.a.hidden.base (206.214.251.17)  183.387 ms  169.991 ms  173.318 ms
17  have.won.their.first.victory (206.214.251.22)  173.311 ms  173.069 ms  177.750 ms
18  against.the.evil.Galactic.Empire (206.214.251.25)  171.612 ms  173.425 ms  172.213 ms
19  During.the.battle (206.214.251.30)  172.189 ms  170.375 ms  174.484 ms
20  Rebel.spies.managed (206.214.251.33)  187.452 ms  184.106 ms  184.094 ms
21  to.steal.secret.plans (206.214.251.38)  176.400 ms  164.441 ms  175.482 ms
22  * to.the.Empires.ultimate.weapon (206.214.251.41)  202.710 ms  202.982 ms
23  the.DEATH.STAR (206.214.251.46)  203.309 ms  200.630 ms  200.464 ms
24  an.armored.space.station (206.214.251.49)  188.640 ms  183.616 ms  183.708 ms
25  with.enough.power.to (206.214.251.54)  172.240 ms  175.834 ms  178.392 ms
26  destroy.an.entire.planet (206.214.251.57)  181.522 ms  181.295 ms  181.055 ms
27  Pursued.by.the.Empires (206.214.251.62)  171.199 ms  183.643 ms  183.964 ms
28  sinister.agents (206.214.251.65)  183.887 ms  183.807 ms  169.184 ms
29  Princess.Leia.races.home (206.214.251.70)  186.956 ms  184.360 ms  188.026 ms
30  aboard.her.starship (206.214.251.73)  176.836 ms  177.043 ms  205.558 ms
31  custodian.of.the.stolen.plans (206.214.251.78)  210.521 ms  210.363 ms  210.481 ms
32  that.can.save.her (206.214.251.81)  223.368 ms  186.277 ms  189.641 ms
33  people.and.restore (206.214.251.86)  173.534 ms  177.743 ms  165.354 ms
34  freedom.to.the.galaxy (206.214.251.89)  188.511 ms  180.887 ms  180.871 ms
35  0-------------------0 (206.214.251.94)  180.750 ms  166.291 ms  167.833 ms
36  0------------------0 (206.214.251.97)  163.865 ms  177.261 ms  277.070 ms
37  0-----------------0 (206.214.251.102)  188.823 ms  185.405 ms  185.394 ms
38  0----------------0 (206.214.251.105)  185.428 ms  185.447 ms  186.785 ms
39  0---------------0 (206.214.251.110)  183.584 ms  179.677 ms  202.641 ms
40  0--------------0 (206.214.251.113)  186.701 ms  186.703 ms  195.416 ms
41  0-------------0 (206.214.251.118)  209.908 ms  218.616 ms  210.229 ms
42  0------------0 (206.214.251.121)  210.202 ms  218.689 ms  217.341 ms
43  0-----------0 (206.214.251.126)  205.596 ms  190.934 ms  190.928 ms
44  0----------0 (206.214.251.129)  174.850 ms  199.928 ms  188.765 ms
45  0---------0 (206.214.251.134)  197.882 ms  196.898 ms  196.771 ms
46  0--------0 (206.214.251.137)  209.894 ms  200.154 ms  194.528 ms
47  0-------0 (206.214.251.142)  194.500 ms  194.444 ms  180.015 ms
48  0------0 (206.214.251.145)  186.537 ms  189.326 ms  209.464 ms
49  0-----0 (206.214.251.150)  197.258 ms *  190.432 ms
50  0----0 (206.214.251.153)  169.133 ms  171.446 ms  163.703 ms
51  0---0 (206.214.251.158)  177.543 ms  199.581 ms  195.352 ms
52  0--0 (206.214.251.161)  181.527 ms  170.271 ms  179.748 ms
53  0-0 (206.214.251.166)  225.716 ms  226.931 ms  182.487 ms
54  00 (206.214.251.169)  160.609 ms  168.630 ms *
55  I (206.214.251.174)  173.263 ms  179.645 ms  210.331 ms
56  By.Ryan.Werber (206.214.251.177)  165.142 ms  165.358 ms  166.772 ms
57  When.CCIEs.Get.Bored (206.214.251.182)  182.696 ms  188.539 ms  201.360 ms
58  CCIE.38168 (206.214.251.185)  177.905 ms  168.995 ms  174.893 ms
59  FIN (206.214.251.190)  175.547 ms * *

via @AlecMuffett

2001, odyssée de l'uptime

Rédigé par jdrien - - aucun commentaire


Plus de 2 000 jours d'uptime pour un serveur, c'est pas mal. Et c'est suffisamment rare pour que celui puisse être noté. Typiquement le type de machine qui prend la poussière dans un coin et que l'on oublie... Il est vrai aussi qu'elle ne fait pas grand chose (juste un serveur de rebond pour administrer d'autres composants de temps en temps).

Pour les curieux : il s'agit d'un serveur IBM x336 (type 8837), mono-alimenté de surcroît. Jamais eu un seul problème avec cette machine.

Pour les grincheux : oui, je sais... Un uptime de 2001 jours c'est pas top au niveau des mises à jour des composants. On se traîne des vieilleries à tous les étages : firmwares bogués, outils systèmes inexistants, obsolètes ou bogués. Et pas de mise à jour de sécurité, en tout cas pour le noyau.

Mais la performance matérielle est tout de même belle !

OVH-HUBIC VS. Apple, encore un exemple de l'importance de ne pas brader nos libertés

Rédigé par jdrien - - aucun commentaire
Bonjour,
Depuis environ 3 mois, on n'arrive plus à valider la nouvelle Apps Hubic au près d'Apple. Cette  nouvelle Apps comporte les bugs fixes et les nouvelles fonctionnalités (sync).

Le problème qu'Apple évoque est que comme hubiC est une offre stockage Cloud et qu'on commerciale les offres payantes, ces offres payantes doivent obligatoirement être proposées via iTunes !!  C'est extrement surprenant puisqu'aucun de nos concurrents autre que Apple n'est pas obligé de le faire. Visiblement Apple cherche à vendre leur iCloud ou sinon avoir 30%" de chiffre d'affaire de tous les autres stockage dans le Cloud qui ne sont pas amercains !

En plus, Apple essaie de nous obliger d'abandonner notre système de login et mot de passe et utiliser les login et les mots de passe d'iTunes !! Ce qui est inacceptable pour nous. Vous faites confiance à Ovh et nous pouvons vous garantir la confidentialité de vos données que si vous utilisez notre système de login/mot de passe. Si vous utilisez le système d'Apple et étant donné qu'Apple est soumis à Patriot Act, vos données sont sous le Patriot Act ! Et donc on ne peut plus rien vous garantir. En même temps on voit mal comment Apple peut obliger Google ou Microsoft à utiliser leur login/mot de passe .. Et pourquoi les obliger à utiliser les login d'iTunes puisque Google, Dropbox ou Microsoft est déjà sousmis à Patrio Act ?

En bref, il y a quelque chose qui est en train de se jouer entre Apple et Ovh. Nous ne sommes pas soumis à Patriot Act et on voit qu'il y a une difference de traitement vis à vis de nos concurrents américains qui eux sont soumis à Patriot Act. On n'arrive pas à s'empecher de penser que Quelqu'un n'est pas content qu'il existe un système de stockage Cloud qui échappe aux regards indiscret et qu'il est impossible de savoir ce  qu'il s'y passe. Combien de clients ? Qui sont nos clients ? Qu'est ce qu'ils stockent sur hubiC ? Oui, hubiC est sous le radar de Patriot Act et ça fait le désordre ..

On ne lâchera pas. hubiC restera sous ce radar là.

Amicalement
Octave
Je pense que le message (reçu ce jour à 13h12 dans la mailing-list de OVH) de Octave Klaba (fondateur de OVH) est très clair. Il est absolument anormal que Apple, simple distributeur de l'application de OVH, puisse prendre autant de libertés avec nos libertés. Je ne veux pas que OVH (entreprise de droit français) sous soumise au droit américain (attention, uniquement la partie la plus vile, le Patriot Act). Non je ne comprends pas pourquoi Apple devrait toucher 30% des revenus de OVH liés à Hubic.
Dropbox, Google Drive ou encore SugarSync [...] ne court-circuitent en aucun cas les règles d'Apple, aussi arbitraires soient-elles.
En lisant cela dans l'article de Clubic consacré au sujet, on comprend que c'est foutu. Le problème n'est pas ce que Apple reproche à OVH mais pourquoi OVH devrait se conformer aux règles d'Apple pour que son application soit disponible pour les utilisateurs du matériel d'Apple. Vous ne comprenez pas ? Dans ma 308, vous croyez vraiment que Peugeot peut me dire quelle station de radio j'ai le droit d'écouter ? Quelles routes je peux prendre ?

Apple est complètement moisi. Totalement. Et quand je peux voir des articles de ce genre sur des sites dits spécialisés, on se pose la question de la compétence des dits sites. Clubic était pitoyable depuis longtemps ; là c'est pire que tout. Sonnez l'hallali mes braves, on ne peut plus rien faire pour eux.

Alors on me dira que Apple fait ce qu'il veut sur ses téléphones, dans son App Store etc. Il faut être bien naïf dans ce cas pour pouvoir prendre la défense d'Apple et ne pas comprendre que ce qui se joue derrière tout ça s'appelle simplement la liberté.

Oui la liberté, rien de moins : Apple ou qui que ce soit n'a pas à décider de ce que je fais de mon équipement électronique. Mon téléphone m'appartient ; mon matériel m'appartient. J'ai le droit d'installer ce que je veux sur mon matériel : je suis libre. Je suis libre de ne pas choisir le cloud à la sauce Apple (je vais vomir) ; je suis libre de ne pas subir le Patriot Act (je suis français, on croit rêver).

C'est que les personnes qui vivent comme Apple l'entend n'ont pas compris : vous avez signé un pacte avec le Diable. Vous avez bradé votre liberté pour quelques beaux écrans, quelques petits appareils blancs qui n'ont rien de transcendants. Vous n'êtes que les serviles pantins de votre enchaînement. Bashing Apple ? Oui, je veux. Et puis quoi ? J'ai encore le droit non ?

Comment modifier les informations produits d'une lame IBM BladeCenter HS22

Rédigé par jdrien - - aucun commentaire
Il m'est arrivé de voir que certains serveurs IBM BladeCenter HS 22 perdaient un peu la tête de temps à autre : lors d'une simple interrogation des registres DMI via la commande dmidecode j'obtenais ceci
Product Name: IBM System x -[7870TH4]-
alors que j'attendais
Product Name: BladeCenter HS22 -[7870TH4]-

Il est possible de changer ce comportement via l'utilitaire asu fourni par IBM : en effet en lançant la commande asu show all on constate que l'on a les éléments suivants :
SYSTEM_PROD_DATA.SysInfoProdName=7870TH4
SYSTEM_PROD_DATA.SysInfoProdIdentifier=
SYSTEM_PROD_DATA.SysInfoSerialNum=1234567
Le champ SYSTEM_PROD_DATA.SysInfoProdIdentifier est vide ; si on compare avec un serveur HS22 qui répond correctement on observe que ce champ contient normalement l'information qui va bien :
SYSTEM_PROD_DATA.SysInfoProdName=7870TH4
SYSTEM_PROD_DATA.SysInfoProdIdentifier=BladeCenter HS22
SYSTEM_PROD_DATA.SysInfoSerialNum=1234567

Pour changer cette valeur on lance la commande suivante :
# asu set SYSTEM_PROD_DATA.SysInfoProdIdentifier 'BladeCenter HS22'
Après un reboot de la machine, la commande dmidecode répond correctement.
À noter que cette commande peut servir aussi à changer le numéro de série ou le type de machine ; utile lors du remplacement de la carte-mère.

Connaître la version du firmware des cartes fibres QLogic

Rédigé par jdrien - - aucun commentaire
Aide-mémoire : connaître la version des pilotes et des firmwares utilisés pour les cartes QLogic.

Nous devions mettre à jour un serveur IBM x3650 M3 sous CentOS 5.4 64 bits (noyau : 2.6.18-164.15.1.el5) avec 2 cartes bi-ports QLogic en utilisant le paquet qlgc_fw_fc_4g-mb1.90-2-sysx_linux_32-64.bin. Ce paquet, selon le changelog, devait apporter les versions suivantes :
* BIOS version 2.16
* EFI version 2.27
* FCode version 3.13
* Firmware version 5.03.06
Problème : nous ne savions pas où vérifier les versions des éléments qui devaient être mis à jour. En effet, nous utilisions, à tort, la commande systool qui nous indiquait une versions de fimrware qui nous semblait pertinente :
# systool -c fc_host -v
Class = "fc_host"
  Class Device = "host5"
  Class Device path = "/sys/class/fc_host/host5"
[...]
    supported_speeds    = "1 Gbit, 2 Gbit, 4 Gbit"
    symbolic_name       = "QLE2462 FW:v4.04.09 DVR:v8.03.00.1.05.05-k"
[...]
Sous Linux, on trouve dans le répertoire /sys/class/fc_host/host?/device/scsi_host:host? on trouve des fichiers optrom_* :
# cat optrom_bios_version
2.16
# cat optrom_efi_version
2.27
# cat optrom_fcode_version
3.13
# cat optrom_fw_version
5.03.06 1154
On trouve également deux autres fichiers qui correspondent au pilote utilisé :
# cat fw_version
4.04.09 (486)
# cat driver_version
8.03.00.1.05.05-k
Pour résumer, nous avons donc une carte avec deux firmwares bien distincts :
 - le firmware embarqué sur la carte (partie matérielle) ;
 - le firmware utilisé et chargé par le pilote (partie système).
Fil Rss des articles de ce mot clé