GuiGui's Show

Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Stretch.

Nommage des interfaces réseau

Désormais, les interfaces réseau portent des noms dit cohérents. Soit tu mets à jour ton fichiers interfaces, soit tu désactives ce nouveau nommage. Attention si tu bosses sur des machines distantes en adressage static : ne rebootes pas avant d'avoir fait une modif' ;) .

dictionaries-common/default-ispell

Sur une seule de mes machines, celle équipée d'aspell (pour Roundcube via php-pspell), le message suivant s'est affiché durant la mise à jour :

Base de données de configuration probablement corrompue

Le réglage pour « dictionaries-common/default-ispell»  est manquant mais des paquets fournissant des candidats pour ce réglage sont installés : « ifrench-gut ».

Cela peut être dû à une corruption de la base de données de configuration (« debconf »). Veuillez consulter le fichier (non traduit en français) /usr/share/doc/dictionaries-common/README.problems au chapitre « Debconf database corruption ». │

Dans cette situation, il est possible d'exécuter la commande « /usr/share/debconf/fix_db.pl » pour remettre la base de données de configuration dans un état cohérent.

Il est probable que certaines questions seront alors posées afin de replacer le système de gestion des dictionnaires dans un état (temporairement) opérationnel.

À la fin de la mise à jour, j'ai exécuté /usr/share/debconf/fix_db.pl avec succès puis j'ai vérifié : les paquets ispell et ifrench-gut ne sont pas installés… Erreur transitoire ?

OpenSSH

Les paramètres « RSAAuthentication » et « RhostsRSAAuthentication » sont dépréciés d'où un message s'affiche dans le log.

Postfix

Postfix passe en version 3.X. Elle apporte un filet de sécurité qui prévient, dans le log, des réglages implicites qui ont changé. Exemple : dans cette nouvelle version, les diffférents modules (nommés services) de Postfix ne sont plus exécutés dans un chroot par défaut. Dans mon fichier master.cf, dans la colonne « chroot », il y a la valeur implicite « - » qui signifiait « yes » avant et « no » maintenant donc Postfix émet un avertissement dans le log : /etc/postfix/master.cf: line 36: using backwards-compatible default setting chroot=y pour chaque service configuré.

Comme je suis certain de vouloir chrooter les services Postif (car ça a toujours bien fonctionné ainsi…), je mets toute la colonne « chroot » à « y » à l'exception des services local, pipe, spawn, virtual et proxymap puis je redémarre Postfix. Notons qu'une commande de type postconf -F <nom_service>/<type>/chroot=y pour chaque service produira le même résuultat (mise à « y » dans master.cf).

Dovecot

Dans la configuration de tous mes services réseau, je désactive explicitement SSLv2 et SSLv3. Avec Dovecot, cela donne ssl_protocols = !SSLv2 !SSLv3.

Or, les devs OpenSSL ont (enfin !) totalement désactivé SSLv2 entre la version 1.0.2h et 1.1.0 (voir /usr/share/doc/openssl/changelog.gz). Ainsi, le symbole « SSLv2 » n'existe plus, donc Dovecot retourne l'erreur : imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'. Notons que d'autres logiciel, comme Postfix, ne remontent pas d'erreur quand on interdit l'usage de SSLv2 dans leur config'. J'imagine que cette diffférence provient de la manière d'appeler les fonctions de la lib OpenSSL…

La correction est simple : dans la conf' de Dovecot, je n'utilise plus que : ssl_protocols = !SSLv3.

Sympa

Après la mise à jour, le menu de l'interface web (« connexion », « assistance/documentation », « chercher une liste/index des listes », etc.) n'était plus cliquable : dès que j'essayais de cliquer sur un sous-item du menu, pouf, le menu se ferme. Idem pour la connexion : impossible de saisir mon identifiant et mon mot de passe.

La raison est que j'utilise une configuration Apache httpd un peu plus contraignante que celle fournie par défaut avec Sympa (voir /etc/apache2/conf-available/sympa.conf ). Notamment, dans le dossier /var/lib/sympa/static_content, j'autorise le suivi des liens symboliques uniquement si le propriétaire du lien est le même que la destination du lien (« +SymLinksIfOwnerMatch »). Or, dans dans /var/lib/sympa/static_content, on trouve, par exemple external/jquery* qui est un lien symbolique root:root qui pointe vers un fichier sympa:sympa. Apache httpd ne le suivra donc pas. Or, en 2017, il faut obligatoirement du JS pour faire fonctionner un menu… Ceci explique cela.

Changer le propriétaire du lien ne résistera pas à une prochaine mise à jour. Il vaut donc mieux supprimer « +SymLinksIfOwnerMatch » des « Options » du dossier.

Langue

Sympa dispose de plusieurs paramètres pour adapter la langue. « lang » dans la conf' permet de changer la langue par défaut des mails envoyés automatiquement. Chaque utilisateur peut également configurer sa langue dans ses préférences dans l'interface web.

Quant à la langue par défaut de l'interface web (quand on ne s'authentifie pas), ça reste un mystère pour moi… Elle s'adapte à la langue annoncée par le navigateur web du visiteur grâce à l'entête HTTP « Accept-Language ». Avec mon Firefox packagé dans Debian configuré en Français, l'interface reste en anglais. Pourtant, Firefox annonce bien FR-fr puis en-US puis en… En revanche, si dans les préférences Firefox, Contenu, Langues, je supprime toutes les langues sauf le français, l'interface web de Sympa s'affiche en français. Avec curl, qui n'envoie pas l'entête « Accept-Language », l'interface est en français… Est-ce un bug de Firefox qui annonce mal la priorité de chaque langue supportée ou un bug de Sympa qui interprête mal les différente langues supportées par un navigateur web ? Aucune idée…

PHP 7

PHP 7 est installé durant la mise à jour, mais il n'est pas forcément activé… et comme la sécurité de PHP 5 n'est plus prise en charge dans cette version de Debian, je pense qu'il vaut mieux cesser de l'utiliser et passer en 7.0.

D'abord, il faudra porter ta configuration de /etc/php5 vers /etc/php. Par exemple, dans mes php.ini, je modifie toujours les valeurs des paramètres disable_functions, openssl.cafile, memory_limit, html_errors, post_max_size, date.timezone, session.save_path (pour pointer sur un RAMdisk / tmpfs). Elles ne sont pas importées automatiquement dans la nouvelle configuration.

Il faut désactiver PHP 5 avec a2dismod php5 puis virer les paquets php5-* et libapache2-mod-php5 puis vérifier que libapache2-mod-php7.0 et les modules php-* (oui, on note l'apparition de ces metapaquets) correspndant aux php5-* désactivés sont bien installés. Enfin, il faut activer PHP 7 avec a2enmod php7.0 && systemctl restart apache2.

Il faut vérifier que tous tes sites web fonctionnent. S'il n'y a pas de doute à avoir avec les logiciels packagés dans Debian (c'est tout l'intérêt d'une distribution), il n'en va pas de même avec les extensions ni avec les logiciels installés en dehors du gestionnaire de paquets. Exemple : j'utilisais l'extension WordPress ContentOverSSL. Celle-ci utilise la fonction PHP ereg qui a été supprimée dans PHP 7.0. Si tes logs sont bien fichus, tu devrais y trouver les fonctions problèmatiques, genre PHP Fatal error: Uncaught Error: Call to undefined function ereg() in </chemin/vers/fichier.php>.

PHP 7 + TLS dans un chroot

Attention, un chroot Apache httpd incomplet ne pardonne plus avec PHP 7.0. En effet, mon chroot ne contenait pas /dev/random et /dev/urandom et un file_get_contents('https://shaarli.guiguishow.info'); sortait en erreur :

PHP Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
\nerror:24064064:random number generator:RAND_bytes:PRNG not seeded in /var/www/shaarli/test.php on line 2
PHP Warning: file_get_contents(): Failed to enable crypto in /var/www/shaarli/test.php on line 2
PHP Warning: file_get_contents(https://shaarli.guiguishow.info): failed to open stream: operation failed in /var/www/shaarli/test.php on line 2

Pour réparer :

mkdir $chrootdir/dev
mknod /var/apache/chroot/dev/random c 1 8
mknod /var/apache/chroot/dev/urandom c 1 9
systemctl restart apache2

MySQL

La mise à jour et le passage à MariaDB se passe bien… sauf si l'on utilise un chroot.

En premier lieu, j'ai eu une erreur relative à /usr/share/mysql/errmsg.sys. J'y suis habitué : il faut copier ce fichier dans le chroot.

Ensuite, j'ai eu l'erreur InnoDB: ./ib_logfile0 can't be opened in read-write mode. Le web conseille de supprimer ib_logfile0 et ib_logfile1.

ENfin, j'ai eu les erreurs InnoDB: Could not find a valid tablespace file for 'mysql/gtid_slave_pos'., InnoDB: Could not find a valid tablespace file for 'mysql/innodb_index_stats'., InnoDB: Could not find a valid tablespace file for 'mysql/innodb_table_stats'..

J'ai essayé de terminer le script /usr/scripts/scripts/mysql_install_db, mais il était impossible de lancer MySQL, même avec les fichiers ib_logfile* remis à leur place et le mode safe…

Dès l'origine, j'ai configuré salement ce chroot, avec des liens symboliques (et d'autres choses qu'il ne faut pas faire avec un chroot) afin de contenter MySQL. Il m'apparaît, plus de 5 ans après, que le fonctionnement dans un chroot n'est pas vraiment bien intégré dans MySQL en comparaison d'Apache ou de Postfix (la copie du fichier errmsg.sys en est une illustration). Je pense que ce chroot m'apporte plus d'ennuis que de sécurité. Donc, j'ai décidé de le supprimer. J'ai donc déinstallé MySQL (en répondant non à la question "faut-il supprimer l'ensemble des bases de données ?"), j'ai viré tout ce qui est relatif à MySQL de mon arborescence, à l'exception de /var/lib/mysql. J'ai installé MySQL et… ça a fonctionné. \o/

Logrotate

La nuit suivant cette ré-installation de MySQL, logrotate a terminé en erreur :

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

La solution se trouve ici : il faut saisir le mot de passe de l'utilisateur de la base de données « debian-sys-maint » dans /etc/mysql/debian.cnf. Si tu ne le connais plus, connectes-toi en root à la base de données puis change-le avec SET PASSWORD FOR 'debian-sys-maint'@'localhost' = PASSWORD('<nouveau_mdp>');.

RoundCube

Durant l'installation, dbconfig produisait des erreurs du genre "je n'arrive pas à me connecter à la base de données" mais en beaucoup moins trivial (la base de données fonctionnait et le message d'erreur était plus cryptique que ce que j'en rapporte ici). J'ai décidé de quitter dbconfig sans rien configurer. Une fois la mise à jour terminée, roundcube ne savait plus pour quels domaines il devait répondre… Je l'ai reconfiguré avec dpkg-reconfigure roundcube-core et tout est devenu OK.

OpenDKIM

Dans mes logs, OpenDKIM s'écrivait milter socket must be specified tandis que systemd s'écrivait opendkim.service: PID file /var/run/opendkim/opendkim.pid not readable (yet?) after start: No such file or directory

Dans Stretch, OpenDKIM abandonne son script sysvinit et utilise une unit systemd. /etc/default/opendkim n'est donc plus lu. Il faut donc indiquer la socket directement dans la configuration d'OpenDKIM (/etc/opendkim.conf).

De même, systemd s'attend à obtenir le PID d'OpenDKIM dans le fichier /var/run/opendkim/opendkim.pid . Il faut donc ajouter PidFile /var/run/opendkim/opendkim.pid dans /etc/opendkim.conf.

Dans le modèle de configuration qui nous est proposé, remarquons la directive « UserID » qui permet de ne plus exécuter OpenDKIM en root.

OpenDNSSEC

OpenDNSSEC passe de sa version 1.4.6 à sa version 2.0.4 donc, forcément, ça implique une importante migration. Migration assez mal préparée dans le paquet Debian puisque le message nous indique « The enforcer does require a full migration, as the internal database has been completely revised. See the upstream documentation in the /usr/share/opendnssec/1.4-2.0_db_convert/README.md » alors que le dossier /usr/share/opendnssec/1.4-2.0_db_convert/ est vide et les fichiers nécessaires sont éparpillés dans /usr/share/opendnssec… … …

Bref, voici comment j'ai mis à jour :

• Vérifie qu'une clé n'est pas en train d'être changée ou d'être préparée à l'être : echo 'SELECT zones.name FROM dnsseckeys JOIN zones on zones.id = dnsseckeys.zone_id WHERE dnsseckeys.keytype = 257 AND dnsseckeys.active IS NULL AND dnsseckeys.zone_id NOT IN (SELECT dnsseckeys.zone_id FROM dnsseckeys WHERE dnsseckeys.keytype = 257 AND dnsseckeys.state = 4);' | slite3 /var/lib/opendnssec/kasp.db . Si c'est le cas, la doc' d'OpenDNSSEC conseille d'attendre que le rollover soit terminé pour mettre à jour ;
  
  
• Récupére le KeyTag de tes clés actuelles avec ods-ksmutil key list --verbose ;
  
  
• Fais une copie de /var/lib/opendnssec/kasp.db et /var/lib/softhsm/slot0.db , ça te permettra de rollback. Testé et approuvé ;) ;
  
  

• On arrête toute la machinerie et on l'empêche de démarrer durant la mise à jour :

  systemctl stop opendnssec-enforcer.service
  systemctl stop opendnssec-signer.service
  systemctl disable opendnssec-enforcer.service
  systemctl disable opendnssec-signer.service
  systemctl mask opendnssec-enforcer.service
  systemctl mask opendnssec-signer.service
  systemctl mask opendnssec-signerd.service

• Procéde à la mise à jour du système… Conserve les fichiers de conf' actuels d'OpenDNSSEC ;
  
  
• Mets à jour le schéma de la base de données d'OpenDNSSEC vers celui de la version 1.4.8 : cat /usr/share/opendnssec/migrate_1_4_8.sqlite3 | sqlite3 /var/lib/opendnssec/kasp.db ;
  
  

• Mets à jour le contenu de la base de données d'OpenDNSSEC de la version 1.X à 2.X :

  cd /usr/share/opendnssec/
  ./convert_sqlite -i /var/lib/opendnssec/kasp.db -o /var/lib/opendnssec/kasp.db.new
  mv /var/lib/opendnssec/kasp.db.new /var/lib/opendnssec/kasp.db

• Retrouve la cohérence des KeyTags suite à la migration : ods-migrate ;
  
  
• Évite l'erreur « ods-signerd[27373]: [file] unable to stat file /var/lib/opendnssec/enforcer/zones.xml: ods_fopen() failed » : cp /etc/opendnssec/zonelist.xml /var/lib/opendnssec/enforcer/zones.xml ;
  
  

• Démarre l'enforcer et vérifie que tes clés sont toujours là (à l'aide des KeyTags mis de côté au début ;) ) :

  ods-enforcer start
  ods-enforcer key list --verbose

• Si tout est OK, démarre le signer et tente de signer une modification de ta zone DNS :

  ods-signer start
  <Fais une modification de ton fichier de zone ici>
  ods-signer sign <nom_zone>
  <Vérifie que ta modification est effective>

• Si tout est OK, on re-active le lancement d'OpenDNSSEC au boot :

  ods-signer stop
  ods-enforcer stop
  systemctl unmask opendnssec-signerd.service
  systemctl unmask opendnssec-signer.service
  systemctl unmask opendnssec-enforcer.service
  systemctl enable opendnssec-enforcer.service
  systemctl enable opendnssec-signerd.service
  systemctl start opendnssec-enforcer.service
  systemctl start opendnssec-signer.service

Changement dans les conf'

• conf.xml :

  • Enforcer / « Interval » n'est plus utilisé et est déprécié dès la version 2.1 ;
    
    
  • Enforcer / ajout de « P1Y » : pré-génère les paires de clés nécessaires pour couvrir un an dès l'ajout d'une zone ;
    
    
  • Enforcer / ajout de « /var/lib/opendnssec/enforcer » ;
    
    
  • Signer / changement de la valeur de « WorkingDirectory » pour « /var/lib/opendnssec/signer » ;

• kasp.xml :

  • Les zones ont désormais un paramètre « MaxZoneTTL » avec une valeur par défaut d'un jour. Si la zone contient des enregistrements plus grands que la valeur de ce paramètre, ils seront cappés.
• zonelist.xml n'est plus vraiment utilisé et est remplacé par des commandes qui interrogent la base de données interne.

SoftHSM

SoftHSM passe lui aussi d'une version 1.X à 2.X, donc une migration nous attend. Notons que cette migration n'est pas obligatoire à mon sens, car le paquet softhsm version 1.X est toujours maintenu dans cette version de Debian.

Voici comment j'ai procédé :

• Évite l'erreur « ERROR: Could not initialize the library. » : mkdir /var/lib/softhsm/tokens ;
  
  
• Créer un nouveau coffre-fort dans la nouvelle version de SoftHSM : softhsm2-util --init-token --slot 0 --label OpenDNSSEC ;
  
  
• Copie l'ancien coffre-fort dans le nouveau : softhsm2-migrate --db /var/lib/softhsm/slot0.db --token OpenDNSSEC ;
  
  
• Fais utiliser SoftHSM2 par OpenDNSSEC en modifiant la section « Repository » de /etc/opendnssec/conf.xml : <Module>/usr/lib/softhsm/libsofthsm.so</Module> devient <Module>/usr/lib/softhsm/libsofthsm2.so</Module>. Change le PIN si t'as configuré un nouveau USER PIN sur le coffre-fort version 2 ;
  
  
• Redémarre OpenDNSSEC et vérifie que tout est OK ;
  
  
• Si tout est OK, tu peux virer la version 1.X de SoftHSM : apt-get autoremove --purge softhsm-common softhsm.

Si besoin de rollback

• Coupe tout OpenDNSSEC et empêche-le de démarrer automatiquement durant le rollback :

  systemctl stop opendnssec-enforcer.service
  systemctl stop opendnssec-signer.service
  systemctl disable opendnssec-enforcer.service
  systemctl disable opendnssec-signer.service
  systemctl mask opendnssec-enforcer.service
  systemctl mask opendnssec-signer.service
  systemctl mask opendnssec-signerd.service

• Copie tes sauvegardes des fichiers /var/lib/opendnssec/kasp.db et /var/lib/softhsm/slot0.db à leur emplacement d'origine ;
  
  
• Ajoute les dépôts Jessie dans ton sources.list et réinstalle la précédente version : apt-get install opendnssec=1:1.4.6-6 softhsm=1.3.7-2+deb8u1 opendnssec-enforcer-sqlite3=1:1.4.6-6 opendnssec-signer=1:1.4.6-6 opendnssec-common=1:1.4.6-6 libhsm-bin=1:1.4.6-6 opendnssec-enforcer=1:1.4.6-6 libsofthsm=1.3.7-2+deb8u1 softhsm-common=1.3.7-2+deb8u1 ;
  
  
• Recommence la migration à tête reposée en vérifiant que tu n'as rien oublié.

ejabberd

Le bug que je rencontrais lorsque je spécifiais des suites de chiffrement PFS à utiliser lors des connexions c2s (client to server) a disparu.

De même, cette version autorise enfin des dhparam > 1024 (directives « dhfile » et « s2s_dhfile »).

J'ai remarqué de nombreux changements entre ma config' et celle qui est proposée par le paquet. Exemples :

max_user_sessions:
all: 10

devient :

max_user_sessions: 10

max_user_offline_messages:
admin: 5000
all: 100

devient :

max_user_offline_messages:

• 5000: admin
• 100

Conclusion : j'ai décidé de ne pas avoir une conf' passoire et/ou une conf' qui peut se casser d'un rien donc j'ai accepté la conf' proposée et je l'ai adaptée à mes besoins.

icedtea-8-plugin

Les applets Java prennent enfin en charge TLS version 1.2. Utile pour les consoles à distance des BMC (même si Dell propose de l'HTML 5 depuis iDRAC 8).

OpenVPN

Il est désormais à nouveau possible de négocier la version de TLS utilisée. Cela permettra à court terme de forcer l'usage de TLS 1.2 / TLS 1.1 sans avoir à modifier la conf' des clients…

Unbound

On peut enfin activer qname minimisation, ce qui est une bonne nouvelle pour la vie privée.

Apache httpd

On peut enfin spécifier des dhparam personnalisés.

Soit un contrôleur iDRAC 8. Jusqu'à aujourd'hui, j'ai bossé exclusivement avec des iDRAC 6 mais bon, ça doit bien rien changer, non ? Comme d'hab, je lance la console virtuelle. Comme d'hab, je récupére un fichier « .jnlp ». Pour l'exécuter, sous Debian GNU/Linux Jessie (l'actuelle stable), il faut les packages openjdk-7-jre icedtea-7-plugin.

Mais, cette fois-ci, l'exécution foire : « Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. ». La console java est juste imbitable donc allons-y pour exécuter en ligne de commande :

$ javaws viewer.jnlp
Attempted to download https://192.0.2.1:443/images/logo.gif, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctKVMIOLinux64.jar, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctKVM.jar, but failed to connect!
JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
[…]

Hum, donc l'applet n'arrive pas à récupérer des libs et des ressources en HTTPS depuis la BMC et donc forcément, elle n'a aucun code à exécuter… Pourtant, depuis ma machine, un wget https://192.0.2.1:443/images/logo.gif fonctionne très bien.

Sortons Wireshark. En utilisant l'applet java, on constate que la BMC interrompt directement la communication après la réception (ack) du message TLS « Client Hello ». Avec wget, aucun problème. Ça ne peut pas être un erreur de certificat puisque le serveur a refusé d'établir une session TLS avant même de transmettre son certif'. Dans ce type de cas, généralement, on est sur des grosses erreur bateau genre version de TLS ou suite d'algo de chiffrement/intégrité.

Avec l'applet java, la version TLS demandée au serveur est TLS 1.0. Avec wget, la version TLS demandée est TLS 1.2. Huuum, sortons notre openssl :

$ openssl s_client -connect 192.0.2.1:443 -tls1
CONNECTED(00000003)
140316040763024:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
[…]

Hé oui, à partir d'iDRAC 7 ou 8 version 2.40.40 ou supérieure, TLS 1.0 est désactivé par défaut.

Que faire ?

• Activer la prise en charge de TLS 1.0 côté BMC en utilisant racadm : nope, nope, nope. La version 1.0 de TLS est une passoire et le fait que la BMC soit dans un VLAN isolé n'est pas un motif suffisant pour l'utiliser !
  
  
• openjdk-8-jre et icedtea-8-plugin, dont on peut attendre une prise en charge de TLS 1.2 (ou au moins 1.1 :- ) ne sont dans dans Debian stable à l'heure actuelle. Je ne vais pas utiliser des packages de testing.
  
  
• Se passer de Java. Surtout que les applets Java seront dépréciées dans Java 9. C'est possible à partir d'iDRAC 8 qui propose une version HTML 5 de la console virtuelle. Pour l'activer, il faut aller dans l'item « Console virtuelle » du menu « Présentation générale ». Il faut changer la valeur de « Type de plug-in » pour « HTML5 ».

Une BMC, c'est une carte contrôleur greffée à la carte mère d'un ordinateur (on trouve ça plutôt sur les serveurs) qui permet le management à distance de la bécane (accès console, reboot, monitoring bas niveau,...). Super utile en cas de panne ou de fausse manip' puisque ça évite de bouger au datacenter où les machines sont hébergées pour debug.

Comme ces contrôleurs sont exposés sur Internet (adresse IP publique, interface web, SSH, etc.) et qu'ils permettent de grandes choses (reboot de la machine, accès à distance, etc.), il est important de les maintenir à jour. Cf http://shaarli.guiguishow.info/?-leLhg pour une étude du niveau actuel de délabrement.

Pour un serveur Dell PowerEdge R710 avec iDRAC6, c'est par ici : http://www.dell.com/support/home/us/en/19/product-support/product/poweredge-r710/drivers , dans la catégorie « Embedded Server Management », « Dell iDRAC Monolithic Release X.XX ».

Pour un serveur HP ProLiant DL380G6 avec un iLO 2, c'est par ici : http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=3884088&swLangOid=8&swEnvOid=4064 , dans la catégorie « Firmware - Lights-Out Management », « Online ROM Flash Component for Windows » ou pour winwin x64, ça n'a pas d'importance.

Une fois l'exécutable téléchargé, on le décompresse avec 7zip, par exemple : 7z x ESM_Firmware_J7YYK_WN32_2.85_A00.EXE.

Parmi les fichiers décompressés, on trouve :

• Pour Dell : payload/firmimg.d6
• Pour HP : ilo2_<version>.bin

Il suffit d'uploader ces firmwares en utilisant l'interface web de la BMC pour que la mise à jour se fasse.

Les BMC, c'est un truc auquel on pense rarement. Il faut donc se tenir informé par RSS ou par mail de la sortie des mises à jour, pour être sûr de ne pas zapper une mise à jour de sécurité, importante de fait. Dell et HP proposent tous deux leur service de « driver and support alerts » ou « Driver and Firmware Update notifications » :

• Chez Dell, c'est accessible en bas de la page concernant un produit, comme celle que j'ai pointée ci-dessus.
• Pour HP, il faut cliquer sur un driver/firmware depuis la page concernant un produit, genre iLO, puis descendre en bas de la page.