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.
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' ;) .
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 ?
Les paramètres « RSAAuthentication » et « RhostsRSAAuthentication » sont dépréciés d'où un message s'affiche dans le log.
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).
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
.
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.
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 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>
.
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
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/
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>');
.
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.
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 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 :
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 ;ods-ksmutil key list --verbose
;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
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
ods-migrate
;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
conf.xml :
kasp.xml :
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é :
mkdir /var/lib/softhsm/tokens
;softhsm2-util --init-token --slot 0 --label OpenDNSSEC
;softhsm2-migrate --db /var/lib/softhsm/slot0.db --token OpenDNSSEC
;<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 ;apt-get autoremove --purge softhsm-common softhsm
.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
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
;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.
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).
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…
On peut enfin activer qname minimisation, ce qui est une bonne nouvelle pour la vie privée.
On peut enfin spécifier des dhparam personnalisés.
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 (via Internet) de la bécane (accès console, reboot, monitoring bas niveau,...). C'est 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.
Quelques notes sur les BMC IBM IMM :
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 ?
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 !Suite au dernier problème rencontré sur l'infra d'ARN, je viens de mettre à jour cette page. On y parle des split-brain DRBD et de que faire lorsqu'un gnt-instance --cleanup
reste bloqué Si ça peut aider des gens…
En gros, voici ce qui s'est passé : je souhaitais appliquer la màj de sécurité de Linux ajoutée dans Debian 8.7. Je migre toutes les VMs sur le 2e hypeviseur, je màje le premier hyperviseur, je le reboot, il revient à la vie, les DRBD remontent, etc.
Je migre toutes les VMs sur le 1er hyperviseur, je màj le deuxième hyperviseur, je reboot. Le deuxième hyperviseur revient à la vie, les premiers DRBD commencent à peine à remonter et là… perte de contrôle sur le premier hyperviseur : plus de SSH (pas même de SSHoIPv6), plus de ping (mais encore ping6 !) sur le lien d'interco direct entre les deux hyperviseurs, plus de BGP (IPv4 comme IPv6) entre les deux hyperviseurs, impossible d'obtenir un quelconque affichage sur la console virtuelle de la BMC, etc. Évidemment, rien dans les logs sinon ça rend le post-mortem trop facile.
À ce stade, j'aurais pu tenter de mettre en sécurité les VMs dont le DRBD était remonté (pour autant qu'il y en ait eu, ce que je ne sais pas) en forçant le 2e hyperviseur à devenir le master puis en migrant les VMs sur ce 2e hyperviseur. Je n'y ai pas pensé.
Vu l'ampleur du problème, je décide de forcer le redémarrage physique du premier hyperviseur avec la BMC. Je reprends la main dans la console de la BMC et via SSH.
Tous les DRBD remontent et Ganeti démarre toutes les VMs… Mais, notre monitoring me remonte qu'un DRBD est dans un sale état : « 24: cs:WFBitMapS ro:Primary/Secondary ds:UpToDate/Consistent C r----- ».
On est typiquement dans une conséquence d'un split-brain DRBD. Sauf qu'il est d'un type nouveau que nous n'avons pas encore documenté. C'est désormais chose faite. Notons qu'après coup, je ne suis pas satisfait de la solution car elle répond plutôt à la question « comment annuler un job dans l'état running ? » qu'à la question « comment résoudre ce type de split-brain ? ». Il aurait pu être intéressant de tenter un gnt-instance activate-disks
plutôt qu'un gnt-instance --cleanup
mais bon…
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 :
payload/firmimg.d6
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 » :