Procédure de contrôle de version des personnalisations système sur les serveurs CA SDM

Le contrôle de version de CA SDM vous permet de gérer les personnalisations système sur tous les serveurs CA SDM (clients et serveurs). Selon la configuration de CA SDM, le client et les serveurs suivants sont utilisés :
casm173
Le contrôle de version de CA SDM vous permet de gérer les personnalisations système sur tous les serveurs CA SDM (clients et serveurs). Selon la configuration de CA SDM, le client et les serveurs suivants sont utilisés :
  • Configuration conventionnelle
    • Client : serveur secondaire
    • Serveur : serveur principal
  • Configuration de disponibilité avancée
    • Client : serveurs d'applications et de secours
    • Serveur : serveur d'arrière-plan
Exemple : En tant qu'administrateur système, vous avez ajouté un champ dans la page detail_usp_server.htmpl de CA SDM. Vous voulez synchroniser ce changement sur le client et les serveurs. Cet exemple est utilisé tout au long du scénario pour expliquer la synchronisation des personnalisations.
Le diagramme suivant présente la procédure à suivre pour contrôler la version des personnalisations système sur les serveurs CA SDM :
Diagramme illistrant la procédure de contrôle de version des personnalisations système sur les serveurs CA SDM
Procédez comme suit :
  1. Effectuez des modifications dans CA SDM. Dans cet exemple, ajoutez le nouveau champ dans la page HTMPL de CA SDM.
Vérification des prérequis
Procédez aux vérifications suivantes :
  • Vérifiez que l'option ver_ctl est définie sur la valeur
    Mise à niveau
    . Lorsqu'une erreur de version est détectée, une mise à niveau des composants concernés est tentée sur le client. Si la mise à niveau est réussie, la connexion client au serveur continue. Sinon, la connexion s'arrête. Pour en savoir plus sur l'option ver_ctl, consultez l'
    Aide en ligne
    .
  • Vérifiez que le fichier server_secondary_custom.ver est créé dans le répertoire $NX_ROOT\site\mods du serveur principal ou du serveur d'arrière-plan (selon la configuration de CA SDM). Toutes les personnalisations apportées à un composant de contrôle de version doivent être effectuées dans ce fichier. Si le fichier n'existe pas, créez-le dans le même emplacement.
Modification du fichier de contrôle de version de serveur
Une fois que vous avez terminé la personnalisation (par exemple, un champ ajouté dans la page HTMPL) ajoutez ou mettez à jour les composants de contrôle de version dans le fichier de contrôle de version du serveur. Un composant de version de contrôle peut correspondre à un fichier, à un répertoire ou au fichier de variables d’environnement client_nx.env.
Procédez comme suit :
  1. Connectez-vous au serveur suivant, selon la configuration de CA SDM :
    • Configuration conventionnelle : serveur principal
    • Disponibilité avancée : serveur d'arrière-plan
  2. Accédez au répertoire suivant :
    $NX_ROOT\site\mods
  3. Ouvrez le fichier server_secondary_custom.ver.
  4. Ajoutez les composants suivants :
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    Pour plus d'informations sur l'ajout ou la mise à jour de composants de contrôle de version, consultez la section Composants de contrôle de version.
  5. Enregistrez le fichier server_secondary_custom.ver.
    Le composant de contrôle de version est ajouté au fichier de contrôle de version.
Composants de contrôle de version
Pour définir un nouveau composant,
  • utilisez la syntaxe suivante. Les éléments en
    italique
    représentent les données que vous fournissez. Les paramètres
    nom-composant
    et version sont obligatoires. D’autres paramètres peuvent être requis en fonction de la valeur du paramètre
    control-type
    . Tous les autres éléments représentent des mots clés que vous devez saisir exactement comme indiqué ci-dessous :
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    Pour plus d'informations sur les paramètres, consultez la section Paramètres de contrôle de version. Pour plus d'informations sur la structure et la syntaxe des fichiers de contrôle de version, consultez les fichiers .ver installés dans le répertoire $NX_ROOT\site. Ces fichiers contiennent des commentaires et des exemples de paramètres qui peuvent vous être utiles.
Pour mettre à jour une entrée de composant existante,
  • modifiez le paramètre. Par exemple, modifiez le numéro de version.
Pour supprimer le contrôle d'un composant,
  • modifiez les champs, comme suit :
    ! uncontrol component-name
Paramètres de contrôle de version
Les paramètres suivants s'appliquent au contrôle de version :
  • [ nom-composant ]
    Spécifie le nom d’un élément sous le contrôle de version. Le nom doit être unique et placé entre crochets. le
    nom du composant
    n'est pas sensible à la casse. Ce paramètre est obligatoire pour commencer une définition de composant.
  • version="x.x. yyymmd"
    Spécifie un numéro de version (
    x.x
    ) et une date (
    ddmmyyyy
    ) définissant la version du composant. Ce paramètre est obligatoire et doit être placé entre guillemets. Le contrôle de version vérifie la version d’un composant en comparant son numéro et sa date sur le serveur avec le numéro et la date de la version installée sur le client. Les numéros et les dates de version doivent être identiques pour que le composant soit considéré comme synchrone entre le client et le serveur. A titre facultatif, si la propriété checksum est activée, le fichier est vérifié à l’aide de cette dernière avant la mise à jour.
  • type-contrôle
    Spécifie le type de contrôle de version pour ce composant. Les paramètres suivants sont valides pour le type de contrôle :
Paramètre
Description
dir_ctl
Spécifie que le composant représente un répertoire. Vous devez définir le paramètre directory pour spécifier le chemin du répertoire. Vous pouvez également fournir le paramètre de nom de fichier pour filtrer un ensemble de fichiers dans le répertoire. Les sous-répertoires ne sont mis à niveau ni sous UNIX ni sous Windows.
file_ctl
Spécifie que le composant représente un fichier. Vous devez définir les paramètres directory et nom-fichier pour spécifier le chemin du fichier.
Nxenv_ctl
Indique que le composant représente le fichier client_nx.env, dans lequel les variables d'environnement de CA SDM sont enregistrées. Le contrôle de version de CA SDM et le gestionnaire d'options conservent automatiquement ce fichier. Il existe un seul composant nxenv_ctl, dont le nom doit être CLIENT_NXENV.
ver_ctl
Il s’agit du type de contrôle par défaut. Il spécifie qu’il s’agit d’un composant générique, c’est-à-dire qu’il n’est associé à aucun objet externe spécifique. Vous pouvez utiliser un composant générique pour fournir le contrôle de version au client dans son ensemble ou pour un fichier ou un répertoire trop volumineux pour une mise à niveau automatique. Vous ne pouvez pas mettre à niveau les composants dont le type de contrôle est ver_ctl. Si une erreur de version sur un composant ver_ctl est détectée alors que le serveur est en mode UPGRADE, la connexion du client échoue.
  • filename="nom-fichier"
    Spécifie le nom d’un fichier sous contrôle de version. Ce paramètre ne contient pas d’indications sur le répertoire. Il est obligatoire pour les composants file_ctl et facultatif pour les composants de contrôle de répertoire (dir_ctl). Si vous l’utilisez avec des composants de répertoire, le paramètre nom-fichier agit comme un masque de fichier pour limiter le nombre de fichiers associés au composant dir_ctl. Par exemple, si le nom de fichier d’un composant dir_ctl est *.README, une mise à niveau à partir de ce répertoire inclut uniquement les fichiers dont le nom se termine par « .README ».
  • directory="répertoire"
    Spécifie le chemin du répertoire des composants dir_ctl ou du répertoire qui contient le fichier pour les composants file_ctl. Ce paramètre est ignoré pour les composants ver_ctl et nxenv_ctl. Le chemin du répertoire doit être placé entre guillemets et peut contenir des références à des variables d’environnement précédées du signe $.
    Utilisez toujours des barres obliques (non inverses) pour séparer les sous-répertoires dans le nom de chemin d'accès, même sur un serveur Windows.
  • link="répertoire-liens"
    Spécifie un répertoire de liens sur le client, dont le format est identique à celui décrit pour le paramètre directory. Ce paramètre est facultatif pour les composants file_ctl et dir_ctl et est ignoré pour les composants ver_ctl et nxenv_ctl. S’il est défini, une mise à niveau vers un client Linux entraîne l’insertion d’un lien symbolique dans le répertoire de liens, pointant sur le fichier réel copié à l’emplacement spécifié par le paramètre directory. La mise à niveau d’un client Windows entraîne la copie du fichier réel dans les deux emplacements (paramètres link et directory).
  • source="répertoire-source"
    (Facultatif) Spécifie un autre répertoire sur le serveur dont ce dernier extrait les fichiers à distribuer. Le format de ce paramètre est celui du paramètre directory décrit précédemment. Il est utile si les fichiers à distribuer au client diffèrent de ceux se trouvant à l'emplacement du répertoire sur le serveur. Ce paramètre permet d’indiquer au serveur d’extraire le fichier du
    répertoire-source
    et de l’envoyer à l’emplacement sur le client spécifié par le paramètre directory. Le paramètre directory est obligatoire si vous définissez le paramètre source.
  • effectivity="spéc-appl"
    (Facultatif) Indique si le client doit recevoir ce composant. Il vous permet d'exclure le téléchargement sur certains clients. Si un client n’est pas inclus dans la spécification d’application, il ne reçoit pas le composant. Si ce paramètre n'est pas défini, tous les clients reçoivent le composant. La spécification d'application utilise les symboles suivants :
    • + (signe plus)
      Indique d’ajouter un groupe de clients.
    • - (signe mois)
      Indique d’exclure un groupe de clients.
Les groupes de clients suivants sont valides.
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
Par exemple, la spécification suivante signifie que seuls les clients UNIX reçoivent les fichiers :
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Indique que le composant sera mis à niveau si le total de contrôle du composant sur le client ne correspond pas à son équivalent sur le serveur. Lorsque vous appliquez le total de contrôle à un répertoire, il s’applique à tous les fichiers.
  • min_release="version" et max_release="version"
    Spécifient le client le plus ancien et le client le plus récent sur lesquels ce composant peut être distribué. Les instructions figurant dans le fichier server_default.ver définissent les versions. Ces paramètres présentent la forme suivante, où Ga
    xx
    indique la version et où les valeurs suivantes sont des genlevels associés à la version.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    L’ordre indique que GA50 est plus récent que GA45.
  • component_type
    Spécifie le type de composant utilisé. Les types de composants suivants sont utilisés :
Paramètre
Description
fichier
Il s’agit du type de composant par défaut. Il spécifie que les fichiers copiés sur le client sont récupérés directement depuis l’emplacement sur le serveur indiqué par le paramètre directory.
exe_file
Spécifie que les fichiers copiés sur le client sont récupérés depuis un emplacement sur le serveur qui dépend du système d'exploitation du client, comme indiqué ci-dessous :
Windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix (AIX)
linux (Linux)
linux390 (Linux390)
L’emplacement de ces sous-répertoires dépend de la définition du paramètre directory. Si ce paramètre est défini, ils se trouvent dans le
répertoire
indiqué. Dans le cas contraire, ils se trouvent dans le répertoire bin du répertoire d'installation principal de CA SDM.
  • o_mode="mode-propriétaire"
    Spécifie les autorisations d’accès au fichier pour le propriétaire du fichier.
  • g_mode="mode-groupe"
    Spécifie les autorisations d’accès au fichier pour les utilisateurs appartenant au groupe du propriétaire du fichier (uniquement pour les clients UNIX).
  • w_mode="mode-public"
    Spécifie les autorisations d’accès au fichier pour les utilisateurs n’appartenant pas au groupe du propriétaire du fichier (uniquement pour les clients UNIX).
    Les trois paramètres de mode permettent de gérer différentes versions du fichier exécutable sur le serveur. Ils précisent les autorisations d’accès au fichier lorsque vous le copiez sur le client. Ces paramètres sont utilisés uniquement lors d’une opération de mise à niveau. Ils comportent un à trois caractères dont la signification est indiquée ci-après :
Paramètre
Description
R
Lecture
W
Ecriture
X
Exécuter
Les clients PC ignorent les autorisations Lecture et Exécution.
Vous pouvez définir n’importe quelle combinaison de modes d’accès au fichier. Sur les clients UNIX, le mode d’accès indiqué est appliqué au fichier. Sur les clients PC, le fichier est accessible en écriture ou en lecture seule, selon que le paramètre w_mode est défini ou non.
Redémarrage de CA SDM sur le client
Vous redémarrez CA SDM sur les serveurs client pour mettre à jour les fichiers de contrôle de version du client avec les personnalisations.
Cliquez sur
Démarrer
,
Paramètres
,
Panneau de configuration
,
Outils d'administration
,
Services
. Cliquez avec le bouton droit de la souris sur le
serveur CA SDM
et sélectionnez
Démarrer
pour démarrer ou redémarrer un serveur.
Procédez comme suit :
  1. Pour la configuration conventionnelle, redémarrez le serveur secondaire.
  2. Pour la configuration de disponibilité avancée, procédez comme suit :
    1. Redémarrez tous les serveurs de secours.
    2. Redémarrez-le.
    3. Lancez le serveur d'applications.
    4. Effectuez les étapes d et e pour les autres serveurs d'applications.
    Le client se connecte au serveur pour envoyer une liste des composants contrôlés. Le serveur compare cette liste à sa propre liste principale. Les composants concernés sur le client sont mis à niveau.
Identification du serveur d'applications le moins actif
Vous choisissez le serveur d'applications sur lequel l'activité des utilisateurs est la moins importante. Exécutez la commande suivante sur chaque serveur d'applications pour choisir celui sur lequel les sessions actives sont minimales ou inexistantes.
pdm_webstat
: Cette commande ne capture pas les sessions de service Web SOAP ou REST.
Arrêt de l'autre serveur d'applications
Avant d'arrêter un serveur d'applications, vous informez tous les utilisateurs connectés qu'ils doivent se connecter au serveur d'applications le moins actif. Vérifiez que vous avez redémarré le serveur d'applications le moins actif avant d'y déplacer tous les utilisateurs.
Procédez comme suit :
  1. (Recommandé) Informez tous les analystes d'automatisation du support actifs sur le serveur d'applications que vous voulez arrêter, qu'ils doivent créer un ticket dans CA SDM avec leurs informations de session. Ce processus permet de garantir que ces informations ne sont pas perdues. Par exemple, l'analyste d'automatisation du support est connecté à une session avec un client afin de résoudre un problème matériel. Dans ce cas, l'analyste d'automatisation du support peut créer une demande client dans CA SDM avec les informations sur la session avant la fermeture du serveur d'applications.
  2. Envoyez une notification (par exemple, une notification par courriel) à tous les utilisateurs actifs sur le serveur d'applications leur indiquant d'utiliser le serveur d'applications le moins actif que vous venez de redémarrer. Cette notification peut inclure les détails du serveur d'applications mis à jour.
  3. Exécutez la commande suivante sur le serveur d'applications :
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Affiche la page d'aide.
    • -q intervalle -s nom_serveur
      Indique la mise en suspension d'un serveur local ou d'applications selon l'intervalle spécifié. Cet intervalle correspond au nombre de secondes avant la mise hors ligne du serveur. Lorsque vous utilisez cette option sans spécifier un nom de serveur, le serveur local est mis en suspension. Vous ne pouvez pas utiliser cette option pour un serveur d'arrière-plan ou de secours.
    Un message contextuel s'affiche pour tous les utilisateurs actifs sur le serveur d'applications, afin de les notifier de l'arrêt du serveur et du temps restant avant l'arrêt. Les utilisateurs doivent enregistrer leur travail et se déconnecter dans l'intervalle. Le serveur d'applications s'arrête après la durée spécifiée. Les utilisateurs se connectent à l'autre serveur d'applications pour reprendre leur travail. L'analyste d'automatisation du support peut consulter le ticket et reprendre son travail.
    Le serveur d'applications est arrêté.
Vérification des personnalisations sur le client
Vous vérifiez le fichier de contrôle de version sur le client pour vous assurer que toutes les personnalisations ont été synchronisées.
Procédez comme suit :
  1. Connectez-vous au client suivant, selon votre configuration de CA SDM :
    • Configuration conventionnelle : serveur secondaire
    • Configuration de disponibilité avancée : serveur de secours et serveur d'applications
  2. Ouvrez le fichier stdlog à partir de l'emplacement suivant :
    $NX_ROOT\log
  3. Déterminez si toutes les personnalisations effectuées sur le serveur sont appliquées au client.