PI Services

Le blog des collaborateurs de PI Services

Desired State Configuration (Partie 5) : Création d’une ressource personnalisée

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu l'implémentation du mode Pull via un web service.

Desired State Configuration est fourni avec un certain nombre de ressources. Malgré qu'il y en ai peu, et comme évoqué dans le précédent article, Microsoft et la communauté se sont employés à créer des nouvelles ressources. Dans cette cinquième et dernière partie, nous évoquerons la création d’une ressource personnalisée. Cette dernière permettra de prendre en charge un scénario non présent dans les ressources existantes : la présence d'un partage NFS.

Fonctionnement

Une ressource est constituée de plusieurs fichiers :

  • Un fichier .SCHEMA.MOF contenant sa définition et plus particulièrement toutes les propriétés que l'on pourra renseigner.
  • Un module Powershell contenant quelques fonctions obligatoires (.PSM1)
  • Un fichier .PSD1 représentant le manifest du module Powershell. Ce dernier contiendra les fonctions a exporter de notre module. Ce dernier est principalement utilisé pour versionner le module et avoir quelques informations dessus.

Le module Powershell doit obligatoirement comporter trois fonctions. Elles seront appelées lorsqu'un fichier de configuration contiendra une ressource du type que l'on aura créé. “Get-TargetResource” permet de récupérer la configuration telle qu'elle a été définie. “Set-TargetResource” applique une configuration (création, modification et suppression) et “Test-TargetResource” effectue le test de validité (elle retourne un booléen).

Il convient à la personne créant le module de développer le corps de ces fonctions (le squelette étant toujours identique), c'est à dire les paramètres et les process effectués.

Pré-requis

Au lancement de Powershell 4.0, il pouvait être fastidieux de développer ses propres ressources car il fallait respecter une certaine syntaxe. Cependant, Microsoft a développé un module permettant de faciliter la création de ressource à destination de DSC : xDscResourceDesigner. Ce dernier va nous permettre de générer nos fichiers automatiquement. Il est disponible en suivant le lien ci-dessous : http://gallery.technet.microsoft.com/scriptcenter/xDscResourceDesigne-Module-22eddb29

Il suffit ensuite de placer ce module dans le dossier :
C:\Program Files\WindowsPowerShell\Modules”.

DSC xDscResourceDesigner

Création de la ressource

Pour créer la ressource, on commence par définir ses propriétés avec la cmdlet “New-xDscResourceProperty”. Celles-ci possèdent à minima un nom, un type et des attributs. Ces derniers permettent de définir l'accessibilité (lecture, écriture,...). Lorsque l'on définit une nouvelle ressource, au moins une de ses propriétés devra posséder l'attribut “Key” et ne pourra être un tableau. Cet attribut permet d'indiquer la propriété utilisée lors de la recherche d'une ressource.

Dans l'exemple ci-dessous, on définit 3 propriétés :

  • le nom du partage
  • le chemin vers lequel le partage pointe
  • la présence ou l'abscence du partage
Ensuite, il est nécessaire de créer la ressource via la cmdlet “New-xDscResource”. Il faut spécifier toutes les propriétés utilisées dans cette ressource, le nom de la ressource et éventuellement le chemin où l'on va la stocker (sinon il sera placé dans un répertoire “DSCResources” à l’intérieur du répertoire dans lequel on se trouve).
Nous nous retrouvons avec le fichier .MOF ci-dessous :

Un module Powershell qui ne comprend pour l'instant que le fichier .PSM1 a aussi été généré. Il faut maintenant définir la logique de nos 3 fonctions à l'intérieur de ce module.

Get-TargetResource

Le code intégré à la fonction “Get-TargetResource” récupère le partage NFS s'il existe et retourne le chemin vers lequel il pointe. S'il n'y a pas de partage NFS avec ce nom, alors un message est écrit dans l'invite de commande Powershell.

Set-TargetRessource

Dans le code ci-dessous, on récupère un éventuel partage avec le nom défini en paramètre. Si ce dernier existe, alors on le met à jour avec le bon chemin (obligation de supprimer puis de recréer le partage NFS) sinon le partage NFS est créé. Si le partage est présent alors que la propriété “Ensure” a pour valeur “Absent” alors le partage NFS est supprimé. Il est à noter que cette fonction n'est appelée que lors de la modification d'un fichier de configuration d'un serveur ou lorsqu’une configuration est incorrecte.

NB : Lors de la génération du template de module à remplir, il est indiqué dans le corps de la fonction qu'il faut positionné la variable globale “$global:DSCMachineStatus” avec la valeur 1 si une configuration nécessite un reboot après son application.

Test-TargetResource

Cette dernière fonction valide qu'une configuration est bien appliquée. Elle vérifie l'existence du partage ainsi que le chemin vers lequel il pointe si le paramètre “Ensure” a pour valeur “Present”. Si “Ensure” vaut “Absent” alors il est vérifié que le partage NFS n'existe pas. Les différents tests retournent la valeur “$true” si la configuration est bonne et “$false” dans le cas contraire. 

A noter, qu'à la fin de notre module, la cmdlet “Export-ModuleMember” est présente et obligatoire afin que Powershell découvre correctement les méthodes de la ressource.

Génération du manifest

Enfin, il faut générer le fichier de manifest du module. Afin de réaliser cette opération, il faut utiliser la commance New-ModuleManifest en spécifiant les paramètres “FunctionsToExport”, “RequiredModules” et “Path”. Attention, le chemin indiqué doit être la racine de la ressource créée (Au même niveau que le dossier DSCResources), sinon il vous sera impossible d'importer la ressource. De même, le nom du manifest doit être le même que le nom du module.

Les autres champs du fichier .PSD1 généré peuvent aussi être spécifiés via la cmdlet précédente ou en remplissant manuellement le fichier (via un éditeur de texte). Certaines propriétés seront même automatiquement remplies (exemple : auteur avec le samaccountname de l'utilisateur ayant lancé la commande).

Voici un lien menant vers le manifest généré pour cette ressource : Manifest

Import de la ressource et utilisation

Il suffit de placer notre ressource (Répertoire C:\NFSShare dans notre exemple) dans “C:\Program Files\WindowsPowerShell\Modules\

En utilisant la commande “Get-DSCResource”, on remarque que notre ressource NFSShare est disponible. On s'aperçoit aussi que la propriété DependsOn est automatiquement rajouté sur cette ressource. Il s'agit d'une propriété par défaut disponible sur toutes les ressources DSC. Pour rappel elle permet de lier des configurations entre elles en spécifiant qu’une configuration dépend de la réussite d’une autre.
 DSC List Resources
Il est ensuite possible de générer un fichier de configuration pour un serveur. Il est nécessaire d'ajouter la commande “Import-DscResource” en renseignant le paramètre “ModuleName” dans le bloc de configuration lorsque l'on utilise des ressources personnalisées.
Enfin, on applique la configuration via la ligne de commande ci-dessous et on obtient bien la création du partage NFS :

DSC Result

Conclusion

Lors de cet article, nous avons vu la création d'une ressource permettant de gérer des partages NFS. Il est possible de l'améliorer en gérant d'autres propriétés de ce type de partage comme les permissions. 

Desired State Configuration (Partie 4) : Configuration du mode pull (via web service)

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu le fonctionnement du mode Pull puis son implémentation. Cette dernière se base sur un partage SMB permettant à tous les clients d'aller récupérer leur configuration par ce biais.

Dans cette quatrième partie, nous aborderons l'implémentation du mode Pull via un web service.

Fonctionnement

Le fonctionnement du mode Pull est expliqué dans la Partie 2 de ce guide sur DSC. Dans le mode Pull via web services, seul la façon de publier les fichiers de configurations et l'implémentation changent. Au lieu d'utiliser un partage, les clients DSC interrogerons à intervalle régulier une URL pour récupérer leur configuration :
http://PullServerName:8080/PSDSCPullServer/PSDSCPullServer.svc" où PullServerName représente le nom du serveur Pull.

Contrairement au mode Pull via partage SMB, il n'est possible de déployer le Web Services que sur une version Serveur de Windows. Celui-ci se base sur la fonctionnalité Windows Powershell Desired State Configuration Service. Cependant, via le web service, il est possible de sécuriser la connexion avec l'usage de certificat.

Nous retrouvons les mêmes étapes que pour un serveur Pull via partage. Les clients ont un GUID unique de configuration. Ils récupèrent le fichier .mof portant ce GUID. Une vérification d'intégrité du fichier est effectuée grâce à un fichier portant le même GUID avec l'extension .mof.checksum.

Implémentation du web service

Dans cette section, j'explique comment mettre en place un serveur Pull avec Web Service de façon manuelle afin de comprendre les différentes briques de cette fonctionnalité. Dans le dernier paragraphe, vous trouverez des liens vers des ressources Desired State Configuration permettant de réaliser toute cette configuration beaucoup plus rapidement.

Tout d'abord, on installe le service DSC en graphique ou via la commande :

Install DSC Service

Toute une série de dépendance est ainsi installée dont notamment IIS et le Windows Process Activation Service.

Capture d_écran 2014-04-20 à 11.52.16

Puis dans IIS, on crée un nouveau pool d'application (DSCApplicationPool) qui sera lancé avec le compte Local System (Sur le pool d’application choisir “Advanced Settings” puis “Identity”).

Add PoolConfigure Pool

On crée un nouveau site (Exemple : DSCPullSite) utilisant notre pool d’application nouvellement créé et on le fait pointer vers un dossier de son choix. Ce dernier contiendra les sources du web service.

Add Site

Dans le dossier du site web IIS, on crée un répertoire bin dans lequel on copie le fichier Microsoft.Powershell.DesiredStateConfiguration.Service.dll contenu dans $pshome/modules/psdesiredstateconfiguration/pullserver ($pshome correpond à C:\Windows\System32\WindowsPowerShell\v1.0 si vous avez une installation classique de Windows). 

Il faut ensuite copier les fichiers suivants contenu dans le dossier  $pshome/modules/psdesiredstateconfiguration/pullserver à la racine du site web :

  • Global.asax 
  • PSDSCPullServer.mof 
  • PSDSCPullServer.svc 
  • PSDSCPullServer.xml 
  • PSDSCPullServer.config : il doit être renommé en web.config

L'arborescence doit être identique à celle ci-dessous :

Arborscence

Il faut ensuite autoriser les différentes méthodes d'authentification en réalisant un "unlock" sur les sections adéquate du fichier web.config que nous avons copié (anciennement PSDSCPullServer.config).

Voici un script permettant de réaliser cette opération :

Le résultat peut être vérifié dans le fichier C:\Windows\System32\inetsrv\config\applicationHost.config 

web.config

Enfin, dans ce même fichier web.config il faut ajouter les lignes suivantes dans le noeud appsettings :

Lors de l'installation du service DSC, une hiérarchie de dossier a été créée dans C:\Program Files\WindowsPowerShell\DscService :

  • Configuration : dans ce dossier, il faut placer les fichiers .mof et .mof.checksum (renommé avec un GUID, voir Partie 2).
  • Modules : Contient les éventuels modules dont on pourrait avoir besoin.

Pour terminer la configuration du serveur Pull, il faut copier le fichier $pshome/modules/psdesiredstateconfiguration/pullserver/Devices.mdb vers le dossier C:\Program Files\WindowsPowerShell\DscService

L'url du web service (http://PullServerName/PSDSCPullServer.svc) est maintenant opérationnelle !

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager (déjà rencontrée dans les autres articles sur DSC) doit être configurée pour utiliser le web service.

Cette configuration est similaire à celle de la Partie 2 et 3. On retrouve le ConfigurationID permettant de récupérer les bons fichiers .mof. Les paramètres à changer sont :

  • DownloadManagerName : Il prend la valeur WebDownloadManager. 
    DownloadManagerCustomData : Il contient un hashtable avec l'url du web service et un second paramètre AllowUnsecureConnection utile si vous n'utilisez pas de certificat.
Voici une configuration d'exemple :

Annexe

Depuis la sortie de Powershell V4.0, Microsoft s'est employé à fournir de nombreuses nouvelles ressources pour DSC. Celles-ci sont disponibles en suivant le lien ci-dessous :
http://gallery.technet.microsoft.com/scriptcenter/DSC-Resource-Kit-All-c449312d

Ces ressources sont précédées d'un "x" car elles sont encore considérées comme expérimentales. Parmis toutes ces nouvelles ressources (plus d'une cinquantaine !), il y en a une pour déployer un server Pull facilement (xDscWebService). Cette dernière permet d'effectuer toutes les opérations fastidieuses que l'on a mis en place dans la section précédente (création d'un pool d'application, d'un site web, copie des différents fichiers,...).

Voici un exemple d'utilisation de cette ressource :

On retrouve les paramètres tel que le nom du pool d'application (EndpointName), le chemin vers le site web (PhysicalPath),... Cela nous permet aussi de pouvoir customiser simplement les chemins qui vont contenir nos fichiers .mof et .mof.checksum ainsi que les ports utilisés par DSC et l'intégration d'un certificat.

Desired State Configuration (Partie 3) : Configuration du mode pull (via smb)

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Après avoir montré la configuration du mode Push, cette troisième partie est consacrée au mode Pull et plus particulièrement lorsqu'on l'utilise conjointement à un partage de fichier Samba.

Ainsi, j'expliquerai comment fonctionne le mode Pull ainsi que les différentes étapes de configuration.

Fonctionnement

Pour rappel, DSC fonctionne de la manière suivante :

  • Récupération de la configuration
  • Application de la configuration

Ces deux étapes se répètent indéfiniment selon le temps d'actualisation qui a été défini pour chacune d'entre elles.

La principale différence entre les modes Pull et Push concerne la récupération de la configuration. Le mode Pull utilise le principe inverse du mode Push. Au lieu de transmettre les modifications de configurations à nos serveurs, ces derniers vont interroger eux-même un "dépôt" central (appelé serveur Pull) qui contiendra l'ensemble des configurations gérées par DSC. Le serveur appliquant sa configuration et donc aussi à l'origine de la connexion pour vérifier s'il y a une nouvelle version de sa configuration. Lors de la récupération d'une nouvelle version, le fichier MOF récupéré est vérifié via un fichier checksum présent sur serveur Pull. Ci-dessous un schéma récapitulatif des deux modes (Pull et Push) :

image 

En mode Pull, nous n'avons plus à nous préoccuper de savoir si un de nos serveurs possède la bonne configuration (si elle lui a bien été transmise). Concernant le mode Pull, il existe actuellement deux types de dépôts pour centraliser les fichiers de configurations :

  • Un partage de fichier (expliqué dans cet article)
  • Un web service (son fonctionnement sera détaillé dans la partie 4 de ce guide sur DSC).

Ceux-ci seront interrogés par les serveurs utilisant DSC.

Comme pour le mode Push, il est nécessaire de configurer la ressource LocalConfigurationManager qui définira les différents paramètres de fonctionnement de DSC sur les machines clientes.
L'un des principaux paramètres configuré est le ConfigurationId. Il s'agit d'un GUID utilisé pour reconnaître le bon fichier de configuration à télécharger depuis le serveur Pull. Ce GUID est inscrit dans le nom du fichier de configuration (exemple : 6c7544f9-4fa9-4a62-a715-04aebfd70b85.mof).

La configuration du mode Pull s'effectue en différentes étapes :

  • Configuration de la ressource LocalConfigurationManager. Un fichier .meta.mof est créé par serveur pour appliqué la nouvelle configuration de la ressource sur chaque serveur.
  • Génération des fichiers de configuration des serveurs : il s'agit des fichiers .MOF contenant les configurations des serveurs utilisant DSC (un fichier par serveur).
  • Copie des fichiers sur le partage (serveur Pull).
  • Renommage des fichiers MOF avec le GUID de chaque machine concerné.
  • Création des fichiers checksums afin de vérifier l'intégrité des fichiers MOF lors de la récupération d'une configuration par un client (fichier .mof.checksum).

Dans la suite de cet article, je fournis des scripts pour automatiser l'ensemble de ces étapes. Certaines fonctions sont inspirés par l'article de Johan Akerström (http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/) sur le sujet. Les scripts présents en fin d’article sont compatibles avec Windows 7/2008R2 car ils n'utilisent pas les nouvelles Cmdlet Powershell 3.0 et 4.0 uniquement disponibles sur Windows 8/2012 et supérieur. Cela permet de mettre en place un environnement DSC sur une infrastructure ne possédant pas les toutes dernières version des systèmes d'exploitation Microsoft. Avec ces scripts, il est possible de déployer un serveur Pull via DSC, d'automatiser la configuration de DSC sur les serveurs à gérer ainsi que la génération des fichiers de configuration.

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager est expliquée dans la Partie 2 ; je vous invite donc à vous y référer en complément des paramètres liés au mode Pull.

  • RefreshMode : C’est le mode de fonctionnement du client DSC, la valeur attendue est Pull (pour que cela soit fonctionnel les paramètres DownloadManager et DownloadManagerCustomData sont obligatoire)
  • DownloadManager : Les valeurs possibles sont WebDownloadManager ou DSCFileDownloadManager. Lorsque l'on utilise le mode Pull en mode fichiers (et non web service) alors il faut choisir DSCFileDownloadManager.
  • DownloadManagerCustomData : Il s'agit ici d'indiquer dans un hashtable (via la clé SourcePath), le chemin d'accès aux fichiers MOF.
  • RefreshFrequencyMins : C'est le temps de refresh du fichier de config à partir de la source (ici SMB)).
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • ConfigurationId : Un GUID pour récupérer les bons fichiers de configurations. La machine n'appliquera que le .MOF portant son ConfigurationID.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect (voir partie 2 pour l'explication).

Exemple de reconfiguration du LocalConfigurationManager pour le mode Pull via partage SMB :

NB : Pour appliquer cette configuration, le remote Powershell doit être activé sur les machines clientes (actif par défaut sur Windows 2012/R2)

Partage SMB

Le partage SMB est crucial car il contiendra l'intégralité des fichiers MOF et des fichiers checksums. A partir de Windows 8/2012 est supérieur, il existe un module permettant de gérer simplement les partages SMB (création avec New-SMBShare). Voici une méthode en WMI pour les postes n'ayant pas ce module. Cette dernière ajoute aussi les permissions de partage de contrôle total pour le groupe Everyone.

Ensuite, il est nécessaire d'appliquer des permissions NTFS en lecture et exécution pour le groupe Everyone :

ConfigurationID

Le GUID attendu par le paramètre ConfigurationId peut être généré automatiquement :

On peut aussi utiliser le GUID de l'ordinateur dans Active Directory comme l'explique Johan Akerström dans son article sur DSC : http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/

1 2 3 4 5 6 7 8 9 10 11 12 13 14
# Define Get Computer GUID Function
# Credit: Johan Åkerström
# http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/
 
Function Get-ComputerGuid {
param(
[Parameter(Mandatory=$true)]
[string]$ComputerName
)
 
process {
([guid]([adsisearcher]"(samaccountname=$ComputerName`$)").FindOne().Properties["objectguid"][0]).Guid
}
}

On peut ensuite copier tous nos fichiers MOF de configuration sur le partage en changeant leurs noms avec le GUID.

Checksum des fichiers MOF

Depuis Powershell 4, il existe une cmdlet permettant de généré un hash : "Get-FileHash". L'algorithme à choisir est SHA256 (celui par défaut).Voici le lien vers la documentation :
http://technet.microsoft.com/en-us/library/dn520872.aspx

Il nous suffit ensuite de créer les fichiers checksum contenant ce hash.

Scripts

Deux scripts sont accessibles via les liens ci-dessous.

Configuration du serveur Pull avec DSC : ici

Librairie de fonctions nécessaires au serveur Pull : ici

L'outil permet de déployer un serveur DSC en mode PULL via DSC. Toutes les étapes sont automatisées. Les fichiers de configurations des clients sont automatiquement générés (copy et renommage avec le guid, création des fichiers checksum, création de tous les fichiers .meta.mof contenant la configuration du LocalConfigurationManager avec la commande Set-DSCLocalConfigurationManager). Il n'y a plus qu'à déployer les ressources LocalConfigurationManager sur les clients (avec un compte possédant les droits nécessaires). Voici les différentes étapes réalisées par le script par ordre d’exécution (chacune d’entre elles nécessite la réussite de la précédente via le paramètre de ressource DSC  DependsOn) :

  1. Un dossier contenant le partage avec les configurations est créé.
  2. La permission NTFS "ReadAndExecute" est ajouté au group everyone ainsi que la permission "FullControl" pour le compte ordinateur du serveur Pull. En effet, il va créer des dossiers et générer des fichiers. C'est ce compte qui exécute les fichiers de configuration dans DSC.
  3. Un partage est généré.
  4. Sur ce partage, le groupe everyone possède la permission "Change". Le compte ordinateur du serveur Pull a des droits "FullControl".
  5. Une arborescence de dossier est généré :
        image Il y a un dossier contenant les configurations créées par l'administrateur (OriginalConfiguration). Un second répertoire (Configuration) a les même configurations renommées avec le GUID de l'ordinateur (pré requis du mode Pull pour que le client récupère sa configuration, voir explication sur le ConfigurationId). Ce dernier contient aussi un fichier checksum pour chaque fichier de configuration .MOF. Un script de librairie est présent dans un troisième dossier (Scripts). Enfin, un répertoire nommé LCM possède tous les fichiers ".meta.mof" de configuration de la ressource LocalConfigurationManager des machines clients.
  6. Le script Powershell contenant les fonctions suivantes est copié dans le répertoire des scripts du serveur Pull :
    • Récupération d'ordinateurs sans module Active Directory (via adsisearcher)
    • Génération automatique des fichiers checksum à partir d'un fichier .MOF
    • Récupération du GUID d'un ordinateur
    • Configuration de la ressource LocalConfigurationManager
  7. Les fichiers de configuration de la ressource LocalConfigurationManager sont générées pour chaque machine client via le filtre qui a été convenu. Il est possible de sélectionner des ordinateurs par unité d'organisation ou par groupe Active Directory suivant les paramètres entrées lors de la génération du fichier de configuration MOF du serveur Pull.
  8. Copie des fichiers de configurations créer par l'utilisateur sur le répertoire contenant les .MOF renommés avec un GUID ; ainsi que création des fichiers checksum associés pour que les clients vérifient l'intégrité de la configuration récupérée. Gràce à cette étape dès qu'une nouvelle configuration ou une modification de l'une d'entre elles a lieu, elle est automatiquement mis à jour avec un une regénération du fichier checksum.

Les étapes 1,2,3,4,5,7,8 sont des ressources DSC de types "script" tandis que l'étape 6 est de type "file".

NB : DSC possède son propre journal d'événements pour vérifier son bon fonctionnement : Applications and Services Logs / Microsoft / Windows Desired State Configuration. Ce dernier permet de superviser DSC lorsqu’on ne déploie plus les configurations manuellement (en mode Push).

Desired State Configuration (Partie 2) : LocalConfigurationManager et Mode Push

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

  • Push
  • Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

001
Get-DscLocalConfigurationManager

 

Le résultat par défaut est le suivant :image Les attributs intéressants pour le mode Push sont :

  • RefreshMode : La valeur doit être à PUSH.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
  • RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

    Voici un exemple de script configurant la ressource LocalConfigurationManager :

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    Configuration SetPushMode
    {
        Node WEBSRV01 {
           
            LocalConfigurationManager {
                ConfigurationMode = "ApplyandMonitor" 
                RefreshMode = "Push"
                RefreshFrequencyMins = 30
            }
        }
    }

    On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

    001
    002
    SetPushMode -OutputPath C:\DSCConfig
    Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

    Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

    Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

001
Start-DscConfiguration -ComputerName WEBSRV01 -Path C:\dscconfig -Verbose -Wait

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.