Ansible CISCO CIMC : installation d’un firmware

L’installation d’un firmware sur une CIMC via la GUI n’est nativement pas possible (enfin pas totalement, on nuance un peu nos propos car il existe une façon de faire via le dépôt du firmware localement sur le serveur via SFTP (WinSCP est parfait pour ce type d’action) par exemple, puis de faire l’update de firmware via la GUI de la CIMC),  le downgrade est lui bien  possible ;). Si vous souhaitez upgrader le firmware d’un serveur CISCO vous pouvez aussi passer par la Cisco IMC Supervisor (via la GUI ou les APIs),  dans notre cas  nous souhaitions passer directement par la CIMC afin de simplifier (et éviter un spof) notre automatisation d’upgrade de fimware.  Dans le cas présent nous avons automatisé l’upgrade de firmware sur des serveurs CISCO (C220 m4/C240 m5) via un partage NFS (le CIFS est possible). Nous vous partageons le playbook ci-dessous qui permet l’upgrade/downgrade de firmware des serveurs CISCO (testé sur des C220 m4/C240 m5) .

Les pré-requis :

  • Un partage NFS (ou CIFS)
  • Le(s) firmware CISCO
  • Renseignez les variables imc_hostname, bundle_ver_file, nfsserver et nsf_remoteShare

et c’est tout bon 😉 .

---
- hosts: localhost
  gather_facts: false

  vars:
    imc_hostname: "YourServrer.fqdn"
    bundle_ver_file: "YouFirmwareISOFile.iso"
    nfsserver: "Yourserver.fqdn"
    nsf_remoteShare: "/vol_xxxyyyy/pathvol/{{ bundle_ver_file }}"

  tasks:      
    
    
    - name: Upgrade firmware on {{ imc_hostname }} - {{currentSite}}
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configConfMo>
            <inConfig> 
              <huuFirmwareUpdater dn='sys/huu/firmwareUpdater' adminState='trigger' 
                remoteIp='{{nsf_remoteIp}}' remoteShare='{{nsf_remoteShare}}'
                mapType='nfs' username='' password="" stopOnError='yes' 
                timeOut='200' verifyUpdate='yes' updateComponent='all' >
              </huuFirmwareUpdater>
            </inConfig>
          </configConfMo>
      register: CIMC_upgrade

    - debug:
        msg: "{{CIMC_upgrade}}"

    # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
    # Check firmware status with block et rescue section
    # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
    - name: Check status firmware Block
      block:
        # The delay is 300 with retrie 20 for to avoid losing the CIMC during the upgrade
        - name: Check status firmware ( !!!! retry 20 - delay 480 !!!! )
          community.general.imc_rest:
            hostname: '{{ imc_hostname }}'
            username: '{{ imc_username }}'
            password: '{{ imc_password }}'
            validate_certs: no
            content: |
              <configResolveClass inHierarchical="true" classId="huuFirmwareUpdateStatus" dn="sys/huu/firmwareUpdater/updateStatus"/>
          retries: 20
          delay: 480
          register: CIMC_upgrade_status
          until: "CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes.updateEndTime != 'NA'"

        - debug:
            msg: 
              - "{{CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes}}"

      rescue:
        - name: "***** RESCUE BLOCK ******"
          debug:
            msg: "****** RESCUE BLOCK Start **********"

        - name: RESCUE Pause for 10 minutes (wait reboot CIMC)
          ansible.builtin.pause:
            minutes: 10
        
        - name: RESCUE Check status firmware ( !!!! retry 20 - delay 600 !!!! )
          community.general.imc_rest:
            hostname: '{{ imc_hostname }}'
            username: '{{ imc_username }}'
            password: '{{ imc_password }}'
            validate_certs: no
            content: |
              <configResolveClass inHierarchical="true" classId="huuFirmwareUpdateStatus" dn="sys/huu/firmwareUpdater/updateStatus"/>
          retries: 20
          delay: 600
          register: CIMC_upgrade_status
          until: "CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes.updateEndTime != 'NA'"

        - debug:
            msg: 
              - "{{CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes}}"


    - name : Set variable fw_starttime and fw_endtime
      set_fact:
        fw_starttime: "{{CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes.updateStartTime}}"
        fw_endtime: "{{CIMC_upgrade_status.configResolveClass.children[0].outConfigs.children[0].huuFirmwareUpdateStatus.attributes.updateEndTime}}"


    - name: Display Start time and End time upgrade firmware
      debug:
        msg: 
          - "Start time : {{ fw_starttime }}"
          - "End time : {{ fw_endtime }}"
      when: "fw_starttime != 'NA' and fw_endtime != 'NA'"


    - name: Upgrade firmware in minutes
      debug:
        msg: "Number of minutes : {{ (((fw_endtime | to_datetime) - (fw_starttime | to_datetime)).seconds / 60 ) | round | int }}"
      when: "fw_starttime != 'NA' and fw_endtime != 'NA'"


    - name: Check firmware version
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="true" classId="firmwareRunning" />
      retries: 60
      delay: 120
      register: CIMC_upgrade_version


    - name: Set variable currentfirmware
      set_fact:
        currentfirmware: "{{CIMC_upgrade_version.configResolveClass.children[0].outConfigs.children[1].firmwareRunning.attributes.version}}"


    - name: Display current firmware on {{ imc_hostname }} after upgrade
      debug:
        msg: "Current firmware : {{ currentfirmware }}"

Une fois lancé,  le playbook va vous donner le retour du code HTTP (logiquement 200 si tout va bien), puis va checker toutes les 480 secondes (X20)  le statut de l’upgrade du firmware (cela permet de gérer l’inaccessibilité de la CIMC lors de son upgrade, si toutefois le check tombe pendant l’inaccessibilité de la CIMC alors ça passe via le block rescue et on recommence via un check toutes les 600 secondes x 20), une fois l’upgrade terminé vous aurez la liste des composants upgraded/skipped, le start time et le end time de l’upgrade (ainsi que la durée de l’upgrade/downgrade) et l’affichage de la version du firmware après upgrade/downgrade.

Enjoy 😉

Post to Twitter

Ansible CISCO CIMC : Reset CIMC

Cela faisait un moment que l’on souhaitait intégrer un reset CIMC dans nos workflows de type souscription/décommissionnement de host CISCO (afin de rendre la CIMC le plus “propre” au début du workflow). C’est désormais chose faite via l’ajout du playbook ci-dessous. 

  - hosts: localhost
  
    vars:
      imc_hostname: "your_IMC"
      imc_username: "IMC_username"
      imc_password: "IMC_password"
      
    tasks:
  
      - name: Reset CIMC
        ignore_errors: yes
        community.general.imc_rest:
          hostname: '{{ imc_hostname }}'
          username: '{{ imc_username }}'
          password: '{{ imc_password }}'
          validate_certs: no
          timeout: 30
          content: |
            <configConfMo>
              <inConfig>
                <computeRackUnit adminPower="bmc-reset-immediate" dn="sys/rack-unit-1">
                </computeRackUnit>
              </inConfig>
            </configConfMo>
        register: result
      
       - debug:
          var: result
        
       - name: Pause for 5 minutes to wait cimc reset
         ansible.builtin.pause:
           minutes: 5
         
       - name: Check uri CIMC
        uri:
          url: "{{ imc_hostname }}"
          validate_certs: no
          status_code: 200
        register: result_cimcuri
        retries: 5
        delay: 10
        until: result_cimcuri is not failed
  
  
      - name: Stop play if result is not 200
        ansible.builtin.fail:
          msg:  "!!! Please check uri {{ imc_hostname }} !!!"
        when: result_cimcuri.status != 200 
  
      - debug:
          msg: "{{ result_cimcuri }}"

Une fois la task lancée, après le time-out (quelle que soit la durée du time-out)  vous obtiendrez l’erreur ci-dessous (c’est pour cela que l’on a ajouté le “ignore_errors: yes” ).

msg”: “Task failed with error -1: Connection failure: The read operation timed out”

L’erreur n’empêche pas le reset CIMC et avec le “ignore_errors: yes” nous pouvons passer à la task suivante (nous avons ajouté une pause de 5 mn afin de laisser le temps à la CIMC de “remonter”), afin de vérifier que la CIMC est bien remontée on check l’uri de la CIMC via la task “Check uri CIMC”, si la CIMC ne répond (code retour http 200) alors la task “Stop play if result is not 200” arrête le play avec le message d’erreur “!!! Please check uri {{ imc_hostname }} !!!”

Généralement nous recherchons les call API de CIMC via l’url “http://CIMC/visore.html“, mais pour le reset de CIMC impossible de trouver le call API en question (au pire on pouvait passer en SSH sur la CIMC, mais ce n’était pas le but). C’est en googlelant que nous sommes tombés sur sur le call API permettant le reset CIMC : reset CIMC with call API

Post to Twitter

Script : Supprimer les applications d’un utilisateur ou d’un groupe

Dans Citrix Virtual and Desktops supprimer un utilisateur ou un groupe de toutes ses applications ou bureaux publiés peut vite s’averer fastidieux.

Le fameux Testdf1 qui nous suit depuis tant d’années 🙂

Comme on est sympa on ne va pas vous laisser supprimer à la mano tous ces utilisateurs/groupes. Le script Powershell “Xa7x_Unpublished” va juste vous demander de rentrer le nom de l’utilisateur ou groupe que vous souhaitez supprimer (ou visualiser) des applications et bureau publiés.

  1. Lancez le script
  2. Entrez le nom de l’utilisateur ou groupe
  3. Entrer 1 si vous souhaitez supprimer l’utisateur/groupe ou 2 si vous souhaitez uniquement visualiser le resultat
  4. Un fichier de log ( Xa7x_Unpublished.log) est disponible dans le répertoire d’exécution du script.

Le script en mode affichage

Le script en mode suppression


Post to Twitter

XenApp : création d’applications en masse

Ca nous est tous arrivé un jour de se retrouver devant LA fameuse demande de création d’applications en masse (dans notre cas plus 300 applications one shoot).

En plein match de la coupe du monde, 300 applis à créer, avec 300 tickets différents bien sûr 🙂

 

Le script powershell joint à ce billet permet la création des applications “en masse”, avec les utilisateurs/groupes et l’icone associée au binaire de publication (sauf si votre chemin applicatif est un bacth, script etc..). Là où c’est pratique c’est que le script repose sur un fichier de configuration (format csv) dans lesquel vos productions applicatives vont rentrer toutes les informations nécessaires à la création des applications (sinon c’est à vous de le faire 😉 ).

En argument lors du lancement vous pouvez indiquez un Delivery Controller (exemple : Xa7x_CreateApps.ps1 MonDeliveryController), en l’absence d’argument le script considère que le serveur local est un Delivery Controller.

 


XA7x_CreateApps.zip

 

 

 

 

Post to Twitter

XenApp_Usr7x V2

UPDATE : 31/05/2018
V2.1

  • Formulaire principal : possibilité de faire un gpupdate sur le serveur hébergeant l’utilisateur sélectionné
  • Formulaire principal : possibilité d’afficher les informations d’un process (process id, command line, creation date, executable path et le WorkingSetSize en dinamique)
  • Formulaire principal : envoi dans le clipboard de toutes les informations utilisateurs affichées
  • Formulaire principal : ajout du menu action (permettant de faire une recherche d’une Application/server/Delivery Group…)
  • Formulaire Server : lancement d’un GPUPDATE sur le serveur
  • Formulaire Server : possibilité de mettre en maintenance un serveur
  • Formulaire Delivery Group : possibilité de mettre en maintenance un Delivery Group
  • Formulaire Application : possibilité de mettre en maintenance une application
  • Admin guide au format pdf
  • Nouveau SplashScreen

A l’époque lors de l’écriture de  XenApp_Usr7x  nous avions longuement hésité à passer sous C#, puis par facilité et manque de temps nous avions continué à faire du GUI sous PowerShell (on n’était dejà pas fan mais la fascilité l’emportait). Pour le passage de XenApp_Usr7x en V2 nous avons donc franchi le pas et avons donc écrit XenApp_Usr7x V2 sous C# 🙂 .

Pour rappel XenApp_Usr7x  (et XenApp_Usr) est un outil permettant de rechercher une session au sein d’une ferme XenApp/Xendesktop (version 7x) et d’afficher les informations se rapportant à la session de l’utilisateur recherché (ce qui évite les allers-retours entre les consoles Studio et Director).

A qui s’adresse XenApp_Usr7x ? Aux collègues du support qui pourront rapidement rechercher une session utilisateur et disposer des informations et actions néccéssaires (sans devoir jongler entre les consoles Studio et Director) au support niveau 1, puis escalader si besoin l’incident avec toutes les informations disponibles, aux collègues administrateurs qui pourront à leur tour aller plus loin dans l’investigation (affichage de compteurs de performance, métrique utilisateur, action sur les process, check de la database etc..etc..).

 

Les nouveautés par rapport à l’ancienne version :

  • Un beau SplashScreen (ok faut aimer les dinos)
  • Amélioration des temps d’ouverture de toutes les fenêtres
  • Utilisateur :
    • Affichage de l’historique des connections
    • Affichage du RTT ICA, Latence ICA, Input Bandwith Used et Output Bandwith Used
  • Server
    • Affichage en temps réel de la consommation CPU, RAM, Paging File Used, Disk free space, Avg disc sec/read et Avg disc sec/write
  • Delivery Group
    • Un graphique circulaire affiche le pourcentage de charge du DG
  • Process
    • Un double clique sur un process entraine l’ouverture d’une fenêtre affichant les principales informations du process (dont notamment le Working Set Size refresh en temps réel)
  • Base
    • Check de la base de données (Database)
  • Prise en compte de l’ajout de Controller une fois le fichier de configuration modifié (plus besoin de passer par le menu refresh)
  • Tooltips (bulle d’information) sur les différents bouttons

 

Pré-requis :

  • Exécutez XenApp_Usr7x  à partir d’un serveur Windows 2012R2/2016
  • Les snapins Citrix doivent être installé sur le serveur

Installation/Execution :

  • Décompressez le contenu de l’archive et double cliquez sur le fichier XenApp_Usr7x-V2.exe

 

 


Entrez le nom d’un Controller dans le champ DDC puis cliquez sur le bouton  (situé à droite du champ DDC)
Le bouton  permet de rajouter des Controllers afin de permettre de passer d’une ferme à une autre facilement

 

Entrez le nom de l’utilisateur recherché dans le champ Username puis cliquez sur le bouton  (situé à droite du champ Username)

 


Cliquez sur la session souhaitée afin d’afficher les informations relative à la session
Les champs encadrés en rouge sont cliquables

 

Un clique sur le bouton  permet d’afficher l’historique des sessions.

 

Un clique sur le bouton  permet d’afficher en temps réel  le RTT ICA, la latence ICA, l’Input/Output bandwith used.

 

Un clique sur le bouton  permet de lancer une assistance à distance sur la session.

 

Un clique sur le bouton  permet d’envoyez un message à l’utisateur au sein de la session.

 

un clique sur le bouton  permet de fermer la session.

 

Le champ server est cliquable et permet d’afficher les principales informations concernant le serveur (charge, type de serveur, cpu, ram, Ip, Os, sessions, Gpo(s), process etc..)

 

Un clique sur le bouton  du formulaire Server permet d’afficher les compteurs Cpu, Ram, Paging file used, Disk free space, Avg disc sec/read, Avg disc sec/write.

 

Le champ Delivery Group est cliquable et permet d’afficher les principales informations concernant le Delivery Group du serveur hébergeant la session (Type de DG, liste des serveurs membres du DG, liste des applications publiées dans le DG etc.. etc..).

 

Un clique sur le champ Farm name (du formulaire principale) ouvre une fenêtre affichant les principales informations concernant la ferme en cour.

 

 

Un clique sur le bouton   permet de lancer des checks sur la Database.

 

 

Vos remarques et suggestions sont comme d’habitude les bienvenues 😉 .

 

XenApp_Usr7x-V2.rar

 

Un grand merci à Etienne, Baderedine, Kamel, Frederic et Jorge pour leurs tests et retours.

Post to Twitter

XenApp_LoadMonitor pour XenApp 7.x

Mise à jour de XenApp_LoadMonitor afin de pouvoir superviser les silos d’une ferme XenApp 7.x.

Pour ceux (et celles) qui ne connaissent pas (encore) XenApp_LoadMonitor nous vous invitons à lire le billet “Supervision de silo serveurs“,

Une modification a été apportée sur le fichier justgage.1.0.1.min.js afin que les gauges passent en orange à partir de 50 % de load.

 

var percentColors = [“#a9d70b”,”#a9d70b”,”#EEA73D”, “#ff0000”];

 


Les serveurs en maintenance sont exclus du calcul de charge des silos.

 

Pour rappel le détail de chaque silo s’obtient en cliquant sur le silo correspondant.

 

XenApp_LoadMonitor_7x.rar

 

 

Post to Twitter

XenApp_Usr7x V1.15

Après les œufs au chocolat nous avons opté pour quelque chose de moins calorifique…… une mise à jour de XenApp_Usr7x (qui passe en 1.15) afin de laisser notre estomac tranquille :), la liste des ajouts et corrections sont listés ci-dessous :

 

  • Possibilité de rajouter plusieurs DDC (un DDC par ligne) via le menu “Tools-Modify DDC” afin de pouvoir passer d’une ferme à une autre sans relancer XenApp_Usr7x (afin de prendre en compte la mise à jour des DDC il faut aller dans le Menu “Tools-Refresh DDC”)
  • Détection de l’OS sur lequel est lancé XenApp_Usr7x (Windows 2012 mini)
  • Les actions d’activation/désactivation d’application et de mise en maintenance de serveur sont désormais enregistrées dans la base de loging
  • Le type de licence Citrix et leur nombre sont disponibles dans le formulaire “Farm Info”
  • Un test de ping est réalisé sur chaque serveur appeler via le formulaire “Server”, le résultat du ping est affiché dans le formulaire “Server”
  • La liste des utilisateurs connectés sur un serveur est disponible dans le formulaire “Server”
  • Export des Applications et Serveurs au format csv via le menu “Tools-Export”
    – L’export des applications comprend les items :  ApplicationName, PublishedName, BrowserName, Name, AdminFolderName, ClientFolder, CommandLineExecutable, CommandLineArguments, Description, Enabled, Visible
    – L’export des serveurs comprend les items : DNSName, Name, MachineName, DesktopGroupName, CatalogName, FunctionalLevel, IPAddress , OSType, RegistrationState, ZoneName

 

Le test de “ping” a un timeout de 500 ms (logiquement en ça passe sinon y a un blem 😉 )



Un clic sur le bouton “Licence Inventory” permettra l’affichage des licences présentes sur le serveur de licence Citrix ainsi que leur consommation


Désormais vous pouvez via le menu “Tools-Modify DDC” rajouter autant de DDC (un par ligne) que vous le souhaitez (un DDC par ferme par exemple afin de passer d’une ferme à une autre rapidement), une fois les DDC rentrés il faudra faire un “Refresh DDC” afin qu’ils soient pris en compte dans XenApp_Usr7x.


 

Certains admins vont être content, vous pouvez désormais exporter rapidement et simplement vos applications et serveurs d’une ferme (et de plusieurs si vous avez rentré plusieurs DDC 😉 ) au format CSV.

 

 

XenApp_Usr_7X .rar

 

Le billet original est par ici.

 

A venir :

  • Ajout de l’affichage cpu/mémoire/disque sur les serveurs et au niveau des Delivery Group (afin de permettre rapidement de comparer le silo sur ces éléments)
  • Ajout de l’affichage du détail des valeurs du load evaluator du serveur dans le formulaire “Server”
  • Liste des utilisateurs sur les Delivery Group
  • Liste de process lancés sur un serveur (et possibilité de les killer)
  • Manuel d’utilisation au format pdf (english version only)

Post to Twitter

Vérifier la validité d’un certificat SSL

Récemment nous avons constaté qu’on ne monitorait pas la validité des certificats SSL de nos StoreFront et Netscaler/F5)  (on avait juste des alertes émanant des collègues de la sécu).

Un script PowerShell plus loin c’est chose faite 🙂 :

 


Les certificats ayant une date d’expiration inférieur à 30 jours apparaissent en warning 😉



Dans un prochain billet nous vous indiquerons comment remonter ces valeurs facilement dans Zabbix via un agent actif.

 

Pour utiliser le script il faut au préalable modifier ce dernier en ligne 2 afin de rentrer les urls à checker (si vous souhaitez modifiez le seuil d’alerte des 30 jours, modifiez la valeur “30” en ligne  33 du script.

 



CheckSslExp.ps1


Pour notre script nous nous sommes inspiré du post “How to read Certificates and CRLs using PowerShell” de nos collègues de NETWORKWORLD.

 

 

Post to Twitter

XenApp_Usr7x V1.1

Après trois semaines d’existence, 112 download et suite à vos nombreux retours (merci pour vos remarques et suggestions), nous avons mis à jour XenApp_Usr_7x

 

Les ajouts sont listés ci-dessous :

  • Possibilité de copier dans le clipboard les informations de Session, Serveur, Machine Catalog, Delivery Group, Application via le bouton Clipboard situé en bas à gauche des formulaires concernés.
  • Lorsqu’un serveur est registered dans le formulaire Serveur, le champ statut est vert (orange lorsque le serveur est unregistered)
  • Possibilité d’afficher les propriétés d’un serveur à partir d’un Machine Catalog ou d’un Delivery Group Mise en maintenance d’un serveur à partir du formulaire Serveur
  • Possibilité de désactiver/Activer une application à partir du formulaire Application Surbrillance en bleu des champs cliquables lors du passage de la souris
  • Gpo(s)computer disponibles dans le formulaire Serveur
  • Compteur des sessions trouvées lors de la recherche

 

Ci-dessous quelques screenshots des principaux ajouts.

 

Formulaire principal

 

Formulaire Machine(serveur)

 

Formulaire Application

 

Le billet original est par ici.

 



XenApp_Usr_7X .rar

Post to Twitter

Cacher toutes les applications désactivées d’une ferme XenApp 6.5

Histoire d’éviter de devoir renvoyer par mail, lync, telegram and co, nous partageons avec vous un tout petit (vraiment petit 🙂 ) oneliner permettant de cacher toutes les applications désactivées d’une ferme XenApp 6.5 qui ne sont pas cachées (pourquoi vous nous direz, parce que certains désactivent les applications et oublient de les cacher……)

get-xaapplication |?{$_.enabled -eq $False -and $_.HideWhenDisabled -eq $False}|%{set-xaapplication -browsername $_.browsername -HideWhenDisabled $True}

 

Post to Twitter