ftp.dell.com direct iDRAC update – MAJ

MAJ 27/07/2016 : Il semblerait que la valeur “/catalog” pour la Catalog Location offre des versions nettement plus up2date.

Parmi les nombreuses méthodes pour upgrader les firmware des composants d’un serveur Dell, il y en une qui nous intéressait beaucoup mais que nous n’arrivions pas à faire fonctionner : la méthode ftp.dell.com

The repository could either be ftp.dell.com or a user generated repository on the local network share.

Sur les serveurs Dell relativement récents, il est en effet possible de “stager” et “scheduler” toutes les updates matérielles possibles directement depuis l’iDRAC en live depuis le ftp Dell. Et depuis la version v.2.21.21.21 les firmwares des HDD/SSD sont complètement supportés même sur un contrôleur en mode HBA (passthrough).

Malheureusement impossible de trouver dans les docs Dell les informations nécessaires pour y arriver :

Mais ça c’était avant de connaitre Lionel, Onsite System Engineer chez Dell, qui nous a donné le trick :

FTP Address : ftp.dell.com
User Name : anonymous
Password : user@domain.com
Catalog Location : /
Catalog Filename : Catalog.xml.gz

D’après le serveur ftp de Dell, le password doit etre un e-mail : “Anonymous access allowed, send identity (e-mail name) as password.

Ensuite vous rebootez quand vous voulez et les patchs sont appliqués (rapidement) par le Lifecycle Controler :

Merci Lionel ;)

Tags: ,

#vExpert16

C’est avec un peu de retard que je rédige ce billet, comme le veut la coutume, pour tous vous remercier de votre soutien et votre fidélité qui m’on permis d’obtenir pour la 7eme année consécutive le fameux titre de vExpert.

Scratch Reset

On ne compte plus le nombre de références détaillant comment configurer un chemin pour rentre la fameuse “scratch” d’ESXi persistante, la meilleure étant la kb VMware Creating a persistent scratch location. Paradoxalement, aucune référence n’indique comment remettre le paramétrage par défaut, à savoir *blank* traduit en “/tmp/scratch” par ESXi :

Du coup, on a bêtement essayé mais évidement ça aurait été trop beau :

C’est dans une autre kb VMware que nous trouvons la solution :

Deleting the /etc/vmware/locker.conf file is not a supported method of removing the link to the scratch location. To remove the scratch location reference, empty the file rather than deleting it.

En vidant le fichier /etc/vmware/locker.conf c’est effectivement beaucoup plus efficace et on fini par un petit “flush firmware configuration” pour forcer un backup de la conf :

#vim-cmd hostsvc/advopt/view ScratchConfig.ConfiguredScratchLocation
#cat /etc/vmware/locker.conf
#cat /dev/null > /etc/vmware/locker.conf
#cat /etc/vmware/locker.conf
#vim-cmd hostsvc/advopt/update ScratchConfig.ConfiguredScratchLocation string ""
#vim-cmd hostsvc/advopt/view ScratchConfig.ConfiguredScratchLocation
#vim-cmd hostsvc/firmware/sync_config

Administrators = root

Dans le what’s new de vSphere 6.0 nous avions remarqué un paragraphe intéressant concernant la gestion des comptes locaux des ESX avec esxcli :

ESXi 6.0 enables management of local accounts on the ESXi server, using new ESXCLI commands. The ability to add, list, remove, and modify accounts across all hosts in a cluster can be centrally managed using a vCenter Server system. Previously, the account and permission management functionality for ESXi hosts was available only with direct host connections. Setting, removing, and listing local permissions on ESXi servers can also be centrally managed.

Nous avons enfin pris le temps de tester cette nouvelle fonctionnalité et pouvons confirmer qu’il est maintenant possible de changer le password du compte root des ESX sans le connaitre pour peu qu’on soit admin du vcenter (alors qu’il fallait bien une connexion direct pre 6.0) :

Get-VMHost|%{($_|Get-EsxCli).system.account.set($null,"root","NewPassword","NewPassword")}

Par contre, les contraintes de cette manipulation sont nombreuses comparé à un simple “passwd” :

An uppercase character that begins a password does not count toward the number of character classes used.

A number that ends a password does not count toward the number of character classes used.

Nous avons aussi découvert à nos dépends qu’un $ au milieu du password était mal interprété. Il convient donc d’être vigilant et de bien tester que le changement soit effectif.

Dump ElasticSearch en Powershell

Parce que les logs d’ESXi sont particulièrement éphémères, il est fortement recommandé de les rediriger vers un syslog. Dans le cadre d’un SR chez VMware, il nous a fallu extraire le contenu d’une appliance SexiLog pour plusieurs ESX sur une période donnée. On a fait chauffé le notepad++ pour faire un truc en powershell qui fait le taff comme il faut :

$i=0
$pre = '{"fields" : ["message"],"from":'
$post = ',"size": 2000,"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"hostname.raw:esx.vmware.com"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1450738800000,"to":1450997999999}}}]}}}}}'
$msgs=1

while ($msgs) {
$msgs=$false
$body = $pre + $i + $post
$msgs=(Invoke-RestMethod -URI "http://demo.sexilog.fr:9200/_search?pretty=1" -Method 'POST' -ContentType 'application/json' -Body $body -TimeoutSec 5).hits.hits.fields.message
$msgs|%{$_.Trim()}|Out-File -FilePath c:\temp\esx.vmware.com.log -Append
$i=$i+2000
}

Il convient de remplacer les FQDN esx.vmware.com et demo.sexilog.fr par les vôtres et d’ajuster les valeurs from/to en epoch.

Le script extrait tous les messages pour le serveur donné, sur la période donné vers un fichier de log par batch de 2000 :

Et une fois l’export terminé, le script se termine par une erreur “attendue” :

A titre indicatif, il a fallut 1h pour extraire 1Go de log. Egalement dispo sur GitHub si besoin.

Tags: , ,