Cómo controlar versiones de las personalizaciones del sistema en los servidores de CA SDM

El control de la versión de CA SDM ayuda a gestionar las personalizaciones del sistema en todos los servidores de CA SDM (clientes y servidores). En función de la configuración de CA SDM, se utilizan los siguientes servidores y clientes:
casm173
El control de la versión de CA SDM ayuda a gestionar las personalizaciones del sistema en todos los servidores de CA SDM (clientes y servidores). En función de la configuración de CA SDM, se utilizan los siguientes servidores y clientes:
  • Configuración convencional
    • Cliente: servidor secundario
    • Servidor: servidor principal
  • Configuración de disponibilidad avanzada
    • Cliente: servidores en espera y de aplicaciones
    • Servidor: Servidor en segundo plano
Ejemplo: como administrador del sistema, se agrega un campo en la página detail_usp_server.htmpl de CA SDM. Ahora, se recomienda sincronizar este cambio con servidores y clientes. Este ejemplo se utiliza en todo el escenario para explicar cómo se sincroniza la personalización.
El siguiente diagrama muestra cómo controlar versiones de las personalizaciones del sistema en los servidores de CA SDM:
Diagrama que muestra cómo controlar versiones de las personalizaciones del sistema en los servidores de CA SDM
Siga estos pasos:
Verificación de los requisitos previos
Compruebe los siguientes requisitos:
  • Garantice que la opción ver_ctl se establece con el valor de
    actualización
    . Cuando se detecta una discrepancia entre versiones, se intenta realizar una actualización de los componentes afectados en el cliente. Si la actualización se realiza correctamente, la conexión del cliente con el servidor continúa; en caso contrario, finaliza. Para obtener más información sobre la opción ver_ctl, consulte la
    ayuda en línea
    .
  • Asegúrese de que el archivo server_secondary_custom.ver se ha creado en el directorio $NX_ROOT\site\mods del servidor principal o del servidor de fondo (en función de la configuración de CA SDM). Todas las personalizaciones de un componente de control de versiones se deberán realizar en este archivo. Si el archivo no existe, asegúrese de crearlo en la misma ubicación.
Modificación del archivo de control de versiones del servidor
Tras completar la personalización (por ejemplo, agregar un campo en la página de HTMPL) agregue o actualice los componentes de control de versiones en el archivo de control de versiones del servidor. El componente de control de versiones puede representar un archivo, un directorio o el archivo de variables de entorno client_nx.env.
Siga los pasos siguientes:
  1. Inicie sesión en el siguiente servidor, en función de la configuración de CA SDM:
    • Convencional: Servidor principal
    • Disponibilidad avanzada: Servidor en segundo plano
  2. Vaya al directorio siguiente:
    $NX_ROOT\site\mods
  3. Abra el archivo server_secondary_custom.ver.
  4. Agregue estos componentes:
    [ 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
    Para obtener más información acerca de la adición o actualización de componentes del control de versiones, consulte el tema Componentes del control de versiones.
  5. Guarde el archivo server_secondary_custom.ver.
    El componente del control de versiones se agrega al archivo de control de versiones.
Componentes del control de versiones
Siga estos pasos para definir un nuevo componente:
  • Utilice la siguiente sintaxis. Los elementos en
    cursiva
    representan los datos que se deben proporcionar. Los parámetros de
    nombre-componente
    y versión son siempre obligatorios. Se requieren otros parámetros, en función del valor del
    tipo de control
    . Todos los demás elementos representan palabras clave que se deben escribir exactamente como se muestra en el siguiente ejemplo:
    [ 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"
    Para obtener más información sobre los parámetros, consulte Parámetros de control de versiones. Para obtener más información sobre la estructura y la sintaxis de los archivos de control de versiones, consulte los archivos .ver instalados en el directorio $NX_ROOT\site. Estos archivos contienen comentarios y valores de configuración de ejemplo que pueden ser de gran utilidad.
Siga estos pasos para actualizar la entrada de un componente existente:
  • Cambie el parámetro. Por ejemplo, cambie el número de versión.
Siga estos pasos para eliminar el control de un componente:
  • Edite los campos como se indica a continuación:
    ! uncontrol component-name
Parámetros de control de versiones
Los siguientes parámetros son aplicables al control de versión:
  • [ nombre-componente ]
    Especifica el nombre del elemento sometido al control de versión. El nombre debe ser único y encerrarse entre corchetes. El
    nombre del componente
    no distingue entre mayúsculas y minúsculas. Este parámetro es obligatorio al principio de la definición de los componentes.
  • versión = "x.x. aaammd"
    Especifica el número (
    x.x
    ) y la fecha (
    yyyymmdd
    ) que definen la versión de los componentes. Este parámetro es obligatorio y se debe encerrar entre comillas dobles. El control de versión verifica la versión de los componentes comparando el número de versión y la fecha que se guardan en el servidor con el número de versión y la fecha presentes en los clientes. Ambos valores, número de versión y fecha, deben coincidir para que se considere que el componente está sincronizado entre el cliente y el servidor. Si se desea y está activada la propiedad checksum, antes de actualizar el archivo pertinente, se verifica mediante una suma de comprobación.
  • tipo-control
    Especifica el tipo de control de versión del componente. La siguiente configuración es válida para el tipo de control:
Valor
Descripción
dir_ctl
Especifica que el componente representa un directorio. Es preciso aportar el parámetro directory para especificar la ruta de acceso al directorio. También se puede proporcionar el parámetro del nombre de archivo para especificar aquel con el que se desea filtrar un conjunto de archivos en el directorio. Los subdirectorios no se actualizan ni en UNIX ni en Windows.
file_ctl
Especifica que el componente representa un archivo. Es preciso aportar los parámetros directory y filename para especificar la ruta de acceso al archivo.
nxenv_ctl
Especifica que el componente representa el archivo client_nx.env, que sirve para almacenar variables de entorno internas de CA SDM. El control de versión de CA SDM y el gestor de opciones mantienen automáticamente este archivo. Existe un solo componente nxenv_ctl cuyo nombre de componente debe ser CLIENT_NXENV.
ver_ctl
Se trata del tipo de control predeterminado. Especifica que el componente es genérico, es decir, que no está asociado a ningún objeto externo. Los componentes genéricos se pueden utilizar para ofrecer el control de versión a los clientes como un todo, o bien, a archivos o directorios demasiado grandes para admitir la actualización automática. Los componentes con el tipo de control ver_ctl no se pueden actualizar. Si las versiones de los componentes ver_ctl no coinciden y el servidor se encuentra en modo ACTUALIZAR, se produce un fallo en la conexión del cliente.
  • filename = "nombre-archivo"
    Especifica el nombre del archivo sometido al control de versión. No contiene ninguna especificación de directorio. Este parámetro es obligatorio para los componentes file_ctl pero opcional para los componentes de control de directorios (dir_ctl). Si se emplea con los componentes de directorios, el parámetro filename actúa como máscara de archivo que restringe los archivos asociados al componente dir_ctl. Por ejemplo, si el valor de filename para un componente dir_ctl es *.README, la actualización de ese directorio solo incluye los archivos que terminen por “.README”.
  • directory = "directorio"
    Especifica la ruta al directorio en los componentes dir_ctl o al directorio que contiene el archivo en los componentes file_ctl. Este parámetro se ignora en los componentes ver_ctl y nxenv_ctl. La ruta del directorio se debe encerrar entre comillas y puede contener referencias a variables de entorno con el símbolo $ delante.
    Escriba siempre barras diagonales (no barras inversas) para separar los subdirectorios en los nombres de rutas, incluso en el caso de los servidores de Windows.
  • link = "directorio-vínculo"
    Especifica un directorio de vínculo del cliente en el mismo formato que el parámetro directory. Este parámetro es opcional para los componentes file_ctl y dir_ctl, y se omite en los componentes ver_ctl y nxenv_ctl. Si se especifica, las actualizaciones en los clientes de Linux provocan la colocación de un vínculo simbólico en el directorio de vínculo que señale al archivo copiado en la ubicación especificada por el parámetro directory. Las actualizaciones en los clientes de Windows provocan la copia del archivo tanto en la ubicación de link como en la de directory.
  • source = "directorio-origen"
    (Opcional) Especifica un directorio diferente en el servidor donde este puede recuperar archivos para la entrega. Tiene el mismo formato que el parámetro directory. Resulta de gran utilidad si los archivos que se deben entregar al cliente son distintos de los archivos de la ubicación de directorio del servidor. Con este parámetro, se insta al servidor a recuperar el archivo del
    directorio-origen
    y a entregarlo en la ubicación del cliente que especifique el parámetro directory. El parámetro directory es obligatorio si se especifica el parámetro source.
  • effectivity = "especificación-efectividad"
    (Opcional) Especifica si el cliente debe obtener el componente. Permite excluir la descarga a algunos clientes. Los clientes que no estén incluidos en la especificación de efectividad no obtienen el componente. Si se omite este parámetro, todos los clientes reciben el componente. La especificación de efectividad emplea los siguientes símbolos:
    • + (signo más)
      Indica que se agregue un grupo de clientes.
    • - (signo menos)
      Indica que se excluya un grupo de clientes.
Los grupos de clientes siguientes son válidos:
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
Por ejemplo, la siguiente especificación indica que solo obtengan los archivos los clientes de UNIX:
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Instruye al componente a actualizarse si la suma de comprobación del componente del cliente no coincide con la suma de comprobación correspondiente del servidor. Si se aplica a un directorio, la suma de comprobación se aplica a cada uno de sus archivos.
  • min_release = "versión" y max_release = "versión"
    Especifican, respectivamente, los clientes más antiguo y más reciente a los que se deba distribuir el componente. Las instrucciones del archivo server_default.ver definen las versiones. Estos parámetros adoptan el formato siguiente, donde GA
    xx
    indica la versión y los valores siguientes son valores Genlevel asociados a la versión.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    El orden indica que GA50 es más reciente que GA45.
  • component_type
    Especifica el tipo de componente utilizado. Se utilizan los siguientes tipos de componentes:
Valor
Descripción
archivo
Se trata del tipo de componente predeterminado. Especifica que los archivos copiados en el cliente se pueden obtener directamente de la ubicación del servidor que indique el parámetro directory.
exe_file
Especifica que los archivos copiados en el cliente se obtienen de una ubicación del servidor que depende del sistema operativo del cliente, como se muestra a continuación:
windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix (AIX)
linux (Linux)
linux390 (Linux390)
Las ubicaciones de estos subdirectorios dependen del valor del parámetro directory. Si se define este parámetro, los subdirectorios se ubican en el
directorio
indicado. De lo contrario, se ubican en el directorio bin del directorio de instalación principal de CA SDM.
  • o_mode = "modo-propietario"
    Especifica permisos de acceso en el archivo para el propietario del archivo.
  • g_mode = "modo-grupo"
    Especifica los permisos de acceso al archivo de los usuarios del grupo del propietario del archivo (solo se emplea para clientes de UNIX).
  • w_mode = "modo-general"
    Especifica los permisos de acceso al archivo de los usuarios que no estén en el grupo del propietario del archivo (solo se emplea para clientes de UNIX).
    Los tres parámetros mode permiten el mantenimiento de distintas versiones del mismo ejecutable en el servidor. Especifican controles de acceso al archivo una vez copiado en el cliente. Estos parámetros solo se utilizan durante las operaciones de actualización. Tienen de uno a tres caracteres con el significado siguiente:
Valor
Descripción
R
Read
W
Escribir
X
Execute
Los equipos cliente ignoran los permisos de escritura y ejecución.
Es posible especificar cualquier combinación de modos de acceso a los archivos. En los clientes de UNIX, se otorga al archivo el modo de acceso especificado. En los equipos cliente, el archivo permite la escritura o es de solo lectura según se haya especificado o no el parámetro w_mode.
Reinicio de CA SDM en el cliente
Reinicie CA SDM en los servidores de cliente para actualizar los archivos del control de versiones del cliente con las personalizaciones.
Seleccione
Inicio
,
Configuración
,
Panel de control
,
Herramientas administrativas
,
Servicios
. Haga clic derecho en
Servidor de CA SDM
y seleccione
Iniciar
para reiniciar o iniciar un servidor.
Siga los pasos siguientes:
  1. En el caso de la configuración convencional, reinicie el servidor secundario.
  2. En el caso de la configuración de disponibilidad avanzada, realice estos pasos:
    1. Reinicie todos los servidores en espera.
    2. Reinicie el servidor de aplicaciones con menor nivel de actividad.
    3. Inicie el servidor de aplicaciones.
    4. Realice los pasos d y e para más servidores de aplicaciones.
    El cliente se conecta al servidor para enviar una lista de componentes controlados. El servidor compara entonces esa lista con su propia lista principal. Se actualizarán los componentes afectados en el cliente.
Selección del servidor de aplicaciones con menor nivel de actividad
Debe seleccionarse un servidor de aplicaciones con el menor nivel de actividad de usuarios. Ejecute el siguiente comando en cada servidor de aplicaciones con el fin de elegir uno con ninguna sesión activa o la menor cantidad posible de estas.
pdm_webstat
: Este comando no captura las sesiones de servicio web REST o SOAP.
Detención del otro servidor de aplicaciones
Informa a todos los usuarios activos en un servidor de aplicaciones de que deben cambiarse al servidor de aplicaciones con menor nivel de actividad antes de que se detenga. Asegúrese de que ha reiniciado el servidor de aplicaciones con menor actividad antes de trasladar a él todos los usuarios.
Siga estos pasos:
  1. (Recomendado) Se debe informar a todos los analistas activos de la automatización de soporte acerca del servidor de aplicaciones que se desea detener con el fin de crear un ticket en CA SDM con la información de la sesión. Este proceso garantiza que la información de sesión no se pierde. Por ejemplo, el analista de la automatización de soporte se encuentra en una sesión con un cliente para resolver una incidencia de hardware. En tal caso, el analista de la automatización de soporte puede crear una incidencia en CA SDM con la información de la sesión antes de que el servidor de aplicaciones se cierre.
  2. Envíe una notificación (por ejemplo, por correo electrónico) a todos los usuarios activos en el servidor de aplicaciones para su traslado al servidor de aplicaciones con menor actividad que se acaba de reiniciar. Esta notificación puede incluir los detalles del servidor de aplicaciones actualizado.
  3. Ejecute el siguiente comando en el servidor de aplicaciones:
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Muestra la página de ayuda.
    • -q interval -s server_name
      Indica a un servidor de aplicaciones local o remoto que utilice el modo de inactividad en un período especificado. Este intervalo corresponde al número de segundos previos a la desconexión del servidor. Al utilizar esta opción sin server_name, se indica al servidor local que utilice el modo inactivo. No se puede utilizar esta opción para un servidor de fondo o en espera.
    Se muestra un mensaje emergente a todos los usuarios activos en el servidor de aplicaciones con objeto de informarles acerca del cierre del servidor y el tiempo que queda para que este se produzca. Los usuarios deben guardar su trabajo y cerrar sesión dentro del plazo indicado. El servidor de aplicaciones se detiene tras el plazo especificado. Los usuarios se conectan al otro servidor de aplicaciones para reanudar su trabajo. El analista de la automatización de soporte puede hacer referencia al ticket y reanudar su trabajo.
    El servidor de aplicaciones se detiene correctamente.
Verificación de las personalizaciones en el cliente
Debe verificarse el archivo de control de versiones en el cliente con el fin de comprobar si todas las personalizaciones se han sincronizado.
Siga los pasos siguientes:
  1. Inicie sesión en el siguiente cliente, en función de la configuración de CA SDM:
    • Convencional: Servidor secundario
    • Disponibilidad avanzada: servidor en espera y servidor de aplicaciones
  2. Abra el archivo stdlog en la siguiente ubicación:
    $NX_ROOT\log
  3. Compruebe si todas las personalizaciones realizadas en el servidor se han aplicado en el cliente.