tuto:gestion_de_parc:fwsupdates:start

Ceci est une ancienne révision du document !


FWSUpdates

FWSUpdates est une interface graphique ainsi qu'un système de déploiement de mises à jour, basé sur WPKG. Par rapport à un WPKG brut, il permet de:

  • Télécharger les mises à jour sur les postes en background
  • Permet le déploiement sur des postes distants (fallback en webdav si le dépôt n'est pas accessible en samba)
  • Avertir l'utilisateur des mises à jour, quand elles sont disponibles
  • Ne s'exécute durant l'arrêt que si programmé
  • Donne le choix aux utilisateurs (installer au prochain arrêt, par défaut, ou repousser à plus tard). Avec cependant une date butoir: 7 jours après la disponibilité des mises à jour, si toujours pas installées, les mises à jour sont forcées
  • Feedback lors du déploiement

Les paquets WPKG en eux même restent identiques à une utilisation simple de WPKG du moment qu'ils utilisent une variables %SOFTWARE% pour définir l'emplacement des paquets. Dans ce cas, seule la valeur de cette variable est modifiée (de \\192.168.7.1\wpkg\softwares elle devient %SystemDrive%\FWSUpdates\repository\softwares).

Le principe est simple: plutôt que le dépôt central (accessible via samba) soit utilisé directement, chaque poste va dans un premier temps synchroniser son contenue en local (via une tâche planifiée). Puis, à partir de cette copie local, il va déterminer si des changements sont nécessaires, et si oui, va proposer à l’utilisateur de les appliquer au prochain redémarrage.

Ce changement va régler les principaux problèmes rencontrés avec WPKG, à savoir:

  • L'extrême lenteur d'exécution pour les postes distants (samba est très lent sur du WAN): tout étant exécuté depuis une copie local, il n'y a plus de différence que le poste soit à l'intérieur ou à l'extérieur du réseau. Seule la synchronisation sera plus lente, mais elle est faite en arrière plan
  • L'impossibilité de pousser des mises à jour sur des postes distants, s'il n'ont pas le VPN connecté
  • La communication vers les utilisateurs: il seront automatiquement avertie des mises à jour (plus besoin de faire un mail séparé)
  • La possibilité de repousser la mise à jour (tout en forçant l'installation au bout d'un moment)
  • Un affichage plus propre qu'une fenêtre DOS affichant simplement que des mises à jour sont en cours
  • Aucun délais à l'extinction si aucune mise à jour n'est nécessaire (affecte principalement les postes distants, qui pouvaient prendre ~1 minutes pour se rendre compte qu'il n'y avait rien à faire)
  • Un feedback durant l'exécution (la barre de progression bouge à chaque installation/mise à jour/suppression)

L'inconvénient avec cette nouvelle méthode est que chaque poste doit stocker la totalité du dépôt central (même les logiciels qui ne seront pas installés sur le poste). Cependant, ce dépôt représente ~2.5Go (dans notre cas), l'impact est donc assez faible

Vérification des mises à jour Affichage des mises à jour disponibles Aucune mise à jour n'est disponible Des mises à jour sont disponibles

Les options de l'interfaces varient selon la situation. Un utilisateur simple ne pourra par exemple pas vérifier la disponibilité des mises à jour. L'utilisation dans une session distante (RDP) n'est possible que pour un compte administrateur

FWSUpdates est constitué de plusieurs petits scripts et outils divers, décris ci-dessous. Le coeur est installé dans le répertoire C:\FWSUpdates (plus précisément dans %SystemDrive%\FWSUpdates)

  • C:\FWSUpdates
    • assets: contient les ressources graphiques
      • img: contient les images utilisées par l'interface
        • fws.bmp: logo utilisé sur la partie gauche de l'interface
        • fws.ico: icône utilisé dans la barre des tâches
    • bin: ce répertoire contient les scripts et binaires de l'outil
      • chkupd.bat: ce script est l'interface à proprement parler. Il peut être exécuté directement, auquel cas il lance l'interface, ou il peut être exécuté avec l'argument loop. Dans ce cas, le script n'affiche dans l'immédiat, mais vérifie régulièrement dans le registre si des mises à jour sont disponibles. Si des mises à jour deviennent disponible, l'interface s'affiche et propose de les installer au prochain arrêt ou de repousser l'installation
      • chkupd_launcher.bat et chkupd_wrapper.vbs: il s'agit de simple wrappers pour lancer chkupd.bat, permettant une exécution sans afficher la fenêtre DOS
      • delayed_sync.bat: un wrapper qui attends une durée aléatoire avant de lancer le script sync.bat. La synchronisation des mises à jour sur les postes étant contrôlée par une tâche planifiée, ce délais aléatoire permet de distribuer la charge et d'éviter de surcharger le serveur
      • now.vbs: un tout petit script qui ne fait qu'afficher le nombre de secondes depuis le premier Janvier 1970 sur la sortie standard
      • on_shutdown.bat: script exécuté à chaque arrêt de la machine. Si une mise à jour est programmée, alors wpkg_feedback.bat est lancé, sinon, le script se termine instantanément
      • sync.bat: ce script permet de synchroniser le dépôt de mises à jour du serveur central sur le poste, dans le répertoire C:\FWSUpdates\repository. Il vérifie ensuite si des changements sont à apporter, et les inscrit dans le registre. Dans un premier temps, l'accès sera testé par samba, et si ce n'est pas possible, le poste fait cette synchronisation par webdav (plus lent, mais fonctionne depuis n'importe où)
      • WizApp.exe: c'est l'application qui génère les “formulaires”: http://wizapp.sourceforge.net/
      • wpkg_feedback.bat: ce script exécute les mise à jour en attente, et affiche ce qui est en train d'être fait sur le système avec une barre de progression. C'est cette interface qui est visible durant l'arrêt de la machine (ou lors de l'installation manuelle des mises à jour)
    • conf: ce répertoire contient la configuration
      • adm: contient les fichiers sensibles, accessibles uniquement aux administrateurs
        • conf.bat: ce fichier contient les identifiants / mot de passe du compte utilisé pour accéder au dépôt, les URL d'accès, etc…
      • user: contient la configuration accessible aux utilisateurs
        • conf.bat: contient la durée maximale de report des mises à jour
    • lang: ce répertoire contient la localisation de l'interface. Seuls l'anglais et le français sont disponibles (l'anglais étant la valeur par défaut, si la langue du Windows sur lequel le script est exécuté n'est pas disponible). Les fichiers sont nommés en utilisant la valeur hexadécimale de la local ID (voir https://msdn.microsoft.com/en-us/goglobal/bb895996.aspx). le contenu doit être encodé en CP850
    • prodkeys: ce répertoire contiendra les clés de produit de la machine (Windows, Office etc…). Les fichiers stockés ici seront ensuite envoyé au serveur par webdav
    • repository: ce répertoire contiendra la copie local du dépôt de mise à jour (dont le script wpkg.js)
    • status: ce répertoire contient les journaux de synchronisation
    • offline_upgrade.bat: ce script permet de mettre à jour FWSUPdates au prochain redémarrage (nécessite une procédure à part, car il ne peut mettre à jour ses propres scripts qui sont en cours d'exécution)

D'autres éléments sont utilisés:

  • le fichier C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\chkupd_bgmon.vbs exécuté à l'ouverture de session lance chkupd.bat avec l'argument loop (pas d'affichage tant qu'aucune mise à jour n'est disponible, vérification régulière)
  • Les clés de registre utilisées sont dans HCLM\Software\FWS\Updates
    • ChangesAvailableSince: date de disponibilité des mises à jour (stockée sous forme de nombre, eg 20160326 pour le 26 Mars 2016)
    • ClientVersion: version de FWSUPdates
    • PendingChanges: Nombre de mises à jour à appliquer
    • PendingCHangesList: liste des programmes à installer/mettre à jour/supprimer
    • RunOnShutdown: détermine si les mises à jour doivent être exécutées au prochain arrêt
    • User
      • RunOnShutdown: détermine si les mises à jour doivent être exécutées au prochain arrêt (la différence est que cette clé est accessible en écriture aux utilisateurs, qui peuvent alors décider d'eux même si l'installation se fait. Au delà d'un certains délais, la clé supérieure, accessible en écriture qu'aux administrateurs sera mise à 1, et forcera l'installation quoi qu'il arrive)
  • Une tâche planifiée sync_wpkg est exécutée toutes les 3 heures, et lance le script sync.bat (delayed_sync.bat plus précisément): cette tâche synchronise le dépôt central sur le poste, dans le répertoire C:\FWSUpdates\repository

Pour installer FWSUpdates sur l'iPasserelle

yum --enablerepo=wpkg-testing install wpkg-fwsupdates
yum --enablerepo=wpkg-testing,ipasserelle-testing update wpkg\* ipasserelle-gp
signal-event ipasserelle-update
signal-event wpkg-update

Dans le fichier \\sas\wpkg\profiles.xml assurez-vous que les paquets logs et cacert ne soient plus inclus dans le profile default (ils ne sont plus nécessaires, et plus compatibles avec FWSUpdates)

À partir de ce moment là, seuls les postes migrés vers FWSUpdates remonteront leurs journaux d'installation et les clés de licences utilisés, les postes utilisant l'ancienne version de WPKG ne le feront plus

L'installation est simple. Il suffit d'aller sur \\sas\tools\scripts\fwsupdates et d'exécuter en tant qu'admin le script install.bat

Pour un poste qui utilisait déjà WPKG auparavant, et dans le cas d'une mise à jour progressive d'un parc, il faut utiliser une petite astuce. Il faut commencer par installer FWSUpdates comme expliqué précédemment, puis éditer le fichier \\sas\wpkg\hosts.xml et ajouter un fragment:

    <host name="WIN7" profile-id="fwsupdates">
        <profile id="workstation" />
    </host>
Dans cet exemple, le poste en question se nomme WIN7
L'important est d'ajouter le profile fwsupdates à la racine de l'entité XML. Ce profile permet de changer le chemin source des mises à jour pour utiliser la copie locale, sans impacter le reste des postes qui utilisent encore l'ancienne version.

Il faut maintenant renommer le fichier C:\Windows\System32\wpkg.xml (ajouter .old par exemple)

Il faut également lancer l'outil gpedit.msc, puis aller dans Configuration Ordinateur → Paramètres Windows → Scripts (démarrage/arrêt) → Arrêt du système. Dans la liste, il faut sélectionner et supprimer le script wpkg.bat (et ne laisser que fwsupdates.vbs)

Quand l'ensemble du parc aura été migré, il suffira d'inclure le profile fwsupdates au profile “default”, et toutes les définitions individuelles des postes faite pendant la migration pourront être supprimées
  • tuto/gestion_de_parc/fwsupdates/start.1456912547.txt.gz
  • Dernière modification: 02/03/2016 10:55
  • de dani