Un script de gestion des patches

fonctionnent
sur chaque serveur. Ensuite, vous
utiliserez le script shell que montre le listing
1 pour accéder à  cette table.

Pour associer le nom de serveur local
avec un nom de serveur dans la table
ComputerApps et extraire une liste des applications
qui sont installées sur ce serveur,
le script exécute une instruction SQL SELECT
qui contient une clause WHERE, comme le montre le
renvoi B du listing 1. La plus grande partie de la logique du
script se trouve dans la boucle For, que montre le renvoi C.
Ce code analyse la liste et appelle la sous-routine appropriée
pour chaque application (par exemple, sous-routine :IIS
pour Microsoft IIS). La sous-routine détermine si l’application
a besoin d’un patch et, si oui, applique celui qui
convient.

Ce script est une ossature qui patche Win2K et IIS. Vous
pouvez facilement l’adapter à  votre site et l’étendre pour appliquer
des patches – et même pour renforcer des scripts –
destinés à  d’autres logiciels. Pour adapter le script à  votre
site, trouvez le code que montre le renvoi A. Remplacez la valeur
de la variable SVR de mysqlsvr par le nom d’hôte de
votre serveur MySQL, changez la valeur de la variable DB
pour qu’elle indique votre base de données MySQL, définissez
la variable USER d’après le username, spécifiez le mot de
passe de l’utilisateur pour la variable PW et remplacez la valeur
de la variable PATCH_UNC par le chemin vers vos fichiers
patch. Après avoir configuré le script en fonction de
votre réseau, vous pouvez utiliser Scheduled Tasks pour
l’exécuter automatiquement, ou bien l’exécuter manuellement
pendant l’interruption administrative.

Pour donner un autre exemple de la puissance d’une
simple base de données NetworkData, imaginez d’exécuter
un ensemble de scripts d’installation post-serveur développés
en interne, sur un système Windows Server 2003 nouvellement
installé. Ces scripts détermineraient les besoins
applicatifs du serveur local d’après le nom du serveur et
les enregistrements dans NetworkData, installeraient et
configureraient les applications listées puis exécuteraient les
scripts de verrouillage (par exemple, pour IIS). L’automatisation
de ces tâches s’harmonise parfaitement avec un plan
de reprise après sinistre et peut soulager des administrateurs
surchargés, confrontés aux déploiements de serveurs quotidiens.