IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Anuncio
Tivoli Provisioning Manager
®
Versión 7.1.1
Guía de migración
Tivoli Provisioning Manager
®
Versión 7.1.1
Guía de migración
Nota
Antes de utilizar esta información y el producto al que da soporte, lea la información del apartado “Avisos” en la página
289.
Esta edición se aplica a IBM Tivoli Provisioning Manager 7.1.1 y a todos los releases y modificaciones posteriores
mientras no se indique lo contrario en nuevas ediciones.
© Copyright International Business Machines Corporation 2009.
Contenido
Capítulo 1. Visión general de la
migración . . . . . . . . . . . . . . 1
Cambios entre la versión 5.1.1.2 y la versión 7.1.1
Mapa de migración . . . . . . . . . .
Lista de comprobación: planificación . . .
Lista de comprobación: tareas previas a la
migración . . . . . . . . . . . .
Lista de comprobación: tareas de migración .
Lista de comprobación: tareas posteriores a la
migración . . . . . . . . . . . .
.
.
.
. 3
. 4
. 4
.
.
. 4
. 6
.
. 8
Capítulo 2. Planificación y preparación
Planificar la topología . . . . . . . . .
Despliegue de varios servidores . . . .
Despliegue en un solo sistema . . . . .
Plataformas soportadas y compatibilidad para la
migración . . . . . . . . . . . . .
Hardware necesario . . . . . . . . .
Contraseñas necesarias . . . . . . . .
Consideraciones acerca del servidor de bases de
datos . . . . . . . . . . . . . .
Consideraciones acerca del servidor LDAP . .
Creación de un entorno de prueba. . . . .
11
.
.
.
. 11
. 11
. 14
.
.
.
. 15
. 17
. 18
.
.
.
. 19
. 20
. 24
Capítulo 3. Tareas previas a la
migración . . . . . . . . . . . . . 25
Actualización del servidor de suministro a la
versión 5.1.1.2 . . . . . . . . . . . . .
Actualización del agente común a la versión 1.3.2.29
Preparación de las imágenes de migración . . . .
Copia de los archivos para la instalación de la
infraestructura de distribución escalable . . . . .
Copia de las herramientas de copia de seguridad en
el servidor de suministro 5.1.1.2 . . . . . . .
Copia de seguridad del servidor LDAP . . . . .
Tareas previas a la migración para Tivoli Directory
Server . . . . . . . . . . . . . . . .
Actualización de Tivoli Directory Server . . . .
Configuración de Tivoli Directory Server para
migración . . . . . . . . . . . . . .
Requisitos previos para la migración de paquetes de
automatización . . . . . . . . . . . . .
Cambios en los paquetes de automatización para
7.1.1 . . . . . . . . . . . . . . . .
Copia de seguridad de los paquetes de
automatización personalizados . . . . . . .
Paquetes de automatización 5.1.1.2 . . . . .
Verificación de la versión del paquete de
automatización . . . . . . . . . . . .
Exportación de la consulta de informe 5.1.1.2 . . .
Migración de repositorios de archivos . . . . .
Migración de las imágenes creadas utilizando Tivoli
Provisioning Manager for OS Deployment
Embedded Edition . . . . . . . . . . . .
Eliminación de apodos y vistas . . . . . . . .
© Copyright IBM Corp. 2009
25
25
27
28
29
29
30
30
30
32
32
34
35
35
36
36
37
39
Instalación de Tivoli Provisioning Manager 7.1.1
para la migración . . . . . . . . . . . . 40
Verificación de los requisitos de los componentes 42
Asignación de hardware . . . . . . . . . 55
Verificación de los requisitos de nombres,
contraseñas y cuentas de usuario . . . . . . 61
Verificación del entorno . . . . . . . . . 64
Inicio del Launchpad . . . . . . . . . . 71
Instalación del middleware en Windows, AIX y
Linux . . . . . . . . . . . . . . . 73
Instalación del middleware en Solaris . . . . 125
Creación de la base de datos y del usuario del
servidor de bases de datos . . . . . . . . 142
Instalación de los componentes principales de
Tivoli Provisioning Manager . . . . . . . 144
Validación de la instalación. . . . . . . . 154
Adición de valores de parámetros al archivo de
propiedades . . . . . . . . . . . . . . 155
Parámetros para el script de copia de seguridad
del sistema 5.1.1.2 . . . . . . . . . . . 160
Parámetros para los scripts de migración que se
ejecutan en el sistema 7.1.1 . . . . . . . . 165
Capítulo 4. Migración de Tivoli
Provisioning Manager. . . . . . . . 175
Tareas de migración para el servidor de suministro
5.1.1.2.. . . . . . . . . . . . . . . .
Visión general: la copia de seguridad de la
versión 5.1.1.2 . . . . . . . . . . . .
Cancelación de tareas y planes de actividades
Detención del servidor de suministro . . . .
Copia de seguridad de un servidor de bases de
datos remoto . . . . . . . . . . . .
Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2. . . . . . . . . . . .
Tareas de migración para el servidor de suministro
7.1.1 . . . . . . . . . . . . . . . .
Visión general: restauración de los datos 5.1.1.2
Inicio del middleware . . . . . . . . .
Acceso a los archivos de migración . . . . .
Creación de las vías de acceso de base de datos
DB2 . . . . . . . . . . . . . . .
Restauración del servidor de bases de datos
remoto . . . . . . . . . . . . . .
Restauración y migración de los datos a 7.1.1
Copia de seguridad de la configuración de base
de datos y WebSphere Application Server . . .
Instalación de los servicios básicos y los
componentes web . . . . . . . . . . . .
Instalación de servicios básicos . . . . . .
Instalación de los componentes web . . . . .
Asignación de los nombres de host . . . . . .
Asignación del nombre de host 5.1.1.2 al
servidor de suministro de 7.1.1 . . . . . .
175
175
177
178
179
180
182
182
184
190
191
192
195
198
199
199
216
218
218
iii
Actualización del nombre de host del servidor
de bases de datos . . . . . . . . . . .
Actualización de los nombres de host restantes
Continuación de la migración en el servidor de
suministro 7.1.1. . . . . . . . . . . . .
Inicio del servidor de suministro 7.1.1 . . . .
Validación de la migración . . . . . . . .
Restauración de la información de LDAP 5.1.1.2
a 7.1.1 . . . . . . . . . . . . . . .
Migración de los grupos de acceso . . . . .
Copia de seguridad de la base de datos . . .
Migración de grupos dinámicos . . . . . .
221
222
224
224
225
226
230
231
231
Capítulo 5. Tareas posteriores a la
migración . . . . . . . . . . . . . 235
Tareas posteriores a la instalación . . . . .
Copia de seguridad de la estación de trabajo
administrativa . . . . . . . . . . .
Configuración de SSL con IBM HTTP Server
Utilización de Tivoli Monitoring Agent . . .
Configuración manual de la tarea cron
VMMSYNC para Microsoft Active Directory .
Sincronización de usuarios y grupos. . . .
Actualización del identificador exclusivo global
en Solaris. . . . . . . . . . . . .
Restaure los valores de WebSphere Application
Server . . . . . . . . . . . . . . .
Configuración del servidor de suministro para la
integración con otros productos . . . . . .
Volver a crear los roles personalizados . . . .
Volver a crear las imágenes de Tivoli Provisioning
Manager for OS Deployment Embedded Edition
Clonación de las imágenes de su entorno 7.1.1
de prueba . . . . . . . . . . . .
Migración de los GUID de Tivoli Application
Dependency Discovery Manager . . . . . .
Importación de un certificado SSL para VMware
Restauración y eliminación de paquetes de
automatización . . . . . . . . . . . .
iv
. 235
. 235
236
. 238
. 239
. 240
. 242
. 243
. 243
. 244
. 244
. 245
. 246
247
Paquetes de automatización personalizados . .
Paquetes de automatización 5.1.1.2 en desuso
Restauración de los repositorios de archivos locales
Volver a crear la información de conformidad . .
Volver a crear los informes personalizados . . .
Cambios en los informes predefinidos . . . .
Migración de las extensiones de inventario . . .
Plan de actividades y tareas de puntos finales . .
248
249
250
250
251
252
253
254
Capítulo 6. Recuperación de errores
de la migración . . . . . . . . . . 255
Códigos de retorno . . . . . . . . . . .
Recuperación de errores de la migración . . . .
Error de creación de objeto . . . . . . . . .
Objetos creados con los avisos de compilación
durante la restauración . . . . . . . . . .
Error al crear el usuario durante la restauración de
Oracle . . . . . . . . . . . . . . . .
Error de nombre no definido durante la
restauración . . . . . . . . . . . . . .
La instalación de Common Agent Services falla . .
La instalación de los servicios básicos falla . . .
Reanudar la instalación utilizando el programa
de utilidad taskrunner . . . . . . . . .
El cambio de los nombres de host falla en AIX con
la base de datos Oracle . . . . . . . . . .
Falta el paquete Solaris necesario . . . . . . .
Errores de autenticación tras la migración . . . .
255
265
273
274
275
276
277
277
278
278
279
280
Capítulo 7. Consulta . . . . . . . . 281
Correlación del objeto de modelo de datos y la
aplicación . . . . . . . . . . . . .
Variables de vía de acceso . . . . . . . .
. 281
. 282
Índice. . . . . . . . . . . . . . . 285
Avisos . . . . . . . . . . . . . . 289
. 247
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 1. Visión general de la migración
Para migrar Tivoli Provisioning Manager versión 5.1.1.2 a la versión 7.1.1, es
necesaria la instalación de 7.1.1 en un nuevo sistema. Los artefactos y datos de la
versión 5.1.1.2 se migran al sistema 7.1.1.
Los productos IBM® Tivoli Intelligent Orchestrator and IBM Tivoli Provisioning
Manager for Software se migrarán a Tivoli Provisioning Manager versión 7.1.1.
El siguiente gráfico muestra una visión general del método de migración. Revise el
método y lea las descripciones para comprender el proceso de migración a la
versión 7.1.1.
Inicio
Tareas de migración
Tareas previas a la migración
Copia de seguridad del
servidor de suministro 5.1.1.2
¿El servidor de
suministro está al
nivel 5.1.1.2?
Sí
Restaurar y migrar los datos
a 7.1.1
No
Actualizar el servidor de
suministro a la versión 5.1.1.2
Completar la instalación de 7.1.1
(servicios básicos y componentes
web)
Actualizar el agente común
al nivel 5.1.1.2
Asignar los nombres de host
de 5.1.1.2 a 7.1.1
Instalar los componentes de
Tivoli Provisioning Manager
7.1.1 sólo para migración
Iniciar el servidor de suministro 7.1.1
Tareas posteriores a la migración
Completar el archivo de propiedades
Leyenda
Recrear y migrar objetos de
datos de 5.1.1.2 adicionales
Tareas para el entorno de
suministro 5.1.1.2
Tareas para el entorno de
suministro 7.1.1
Migración finalizada
Actualice el servidor de suministro a la versión 5.1.1.2
La única vía de acceso de migración soportada a la versión 7.1.1 es desde
Tivoli Provisioning Manager 5.1.1.2. Los productos Tivoli Intelligent
Orchestrator and Tivoli Provisioning Manager for Software también se
deben actualizar a Tivoli Provisioning Manager 5.1.1.2. La migración se
© Copyright IBM Corp. 2009
1
puede completar desde cualquier nivel de arreglo intermedio en 5.1.1.2
(por ejemplo, si tiene la versión 5.1.1.2 con el arreglo intermedio 3), aunque
no es necesario instalar ningún arreglo intermedio antes de realizar la
migración.
Actualice el agente común
El agente común se debe actualizar al nivel 5.1.1.2; versión 1.3.2.29, o
versión 1.3.2.30 si ha instalado arreglos intermedios de la versión 5.1.1.2.
La actualización se debe realizar en los servidores de depósito y en los
puntos finales que participan en el proceso de distribución de software.
Instale Tivoli Provisioning Manager versión 7.1.1
En un nuevo sistema, instale la versión 7.1.1.
Importante: Los pasos de instalación correspondientes a la migración
difieren de los correspondientes a una instalación típica, de modo que debe
seguir la documentación de la guía de migración. Por ejemplo, al instalar
los componentes principales no instalará los siguientes componentes:
v IBM Tivoli Common Agent Services
v IBM Tivoli Provisioning Manager for Dynamic Content Delivery
v IBM Tivoli Device Manager Service
Estos componentes de la instalación de la versión 7.1.1 se completarán
durante los pasos de la migración. Además, debe realizar ciertos pasos de
migración antes de instalar los servicios básicos y los componentes web.
Consejo: Parte de la información que especifique durante la instalación se
necesita para configurar el archivo de propiedades, el siguiente paso de la
migración. Tenga abierto el archivo de propiedades para poder completar
las dos tareas simultáneamente.
Complete el archivo de propiedades
En la migración participan una serie de scripts que automatizan el proceso.
Se proporciona un archivo de propiedades para que pueda especificar toda
la información necesaria al principio de la migración. Durante la
migración, los scripts recuperarán los valores del archivo de propiedades.
Es muy importante que se añadan los valores correctos al archivo de
propiedades. Si se especifican valores incorrectos, se producirán errores y
retrasos en el proceso de migración.
Antes de restaurar los datos de la versión 5.1.1.2, tiene que volver a editar
el archivo de propiedades para asegurarse de que los valores siguen siendo
correctos para el entorno de suministro 7.1.1.
Copia de seguridad de los datos 5.1.1.2
Hay dos tareas de copia de seguridad que debe ejecutar para recuperar la
información antes de migrar a la versión 7.1.1:
1. Copia de seguridad de la configuración del servidor de suministro
5.1.1.2.
2. Copia de seguridad de la base de datos de suministro.
En función del entorno, estas copias de seguridad se realizarán en uno o
en dos pasos. Si utiliza un servidor de bases de datos local para la versión
5.1.1.2, será una copia de seguridad de un paso: la copia de seguridad de
la configuración y la de la base de datos local se completan a la vez. Si
tiene un servidor de bases de datos remoto para 5.1.1.2, se realizará en dos
pasos. Realizará una copia de seguridad del servidor de bases de datos
2
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
remoto y luego hará una copia de seguridad de la configuración de la
versión 5.1.1.2 en el servidor de suministro.
Restaure y migre los datos de la versión 5.1.1.2
Restaure los datos de copia de seguridad de la versión 5.1.1.2 al servidor
de suministro y al servidor de bases de datos de la versión 7.1.1. Si tiene
un servidor de bases de datos remoto, restaurará la información de la base
de datos en la base de datos remota y luego restaurará la información de
configuración del servidor de suministro en el servidor de suministro 7.1.1.
Si tiene una base de datos local para la versión 7.1.1, la restauración se
completa en un paso. La migración de datos también instala os
componentes que no se instalaron durante la instalación de la versión 7.1.1:
v Common Agent Services
v Dynamic Content Delivery
v Servicio del gestor de dispositivos
Complete la instalación de la versión 7.1.1
Instale los servicios básicos y los componentes web de Tivoli Provisioning
Manager.
Asigne los nombres de host de la versión 5.1.1.2 a la 7.1.1
Asigne el nombre de host y la dirección IP del servidor de suministro
5.1.1.2 al servidor de suministro 7.1.1. Actualice los nombres de host
correspondientes al servidor de directorios, IBM WebSphere Application
Server, la infraestructura de distribución escalable e IBM Tivoli
Provisioning Manager for OS Deployment.
Inicie el servidor de suministro 7.1.1
Inicie el servidor de suministro por primera vez desde la migración de
datos. Durante el arranque, comienza la migración del paquete de
automatización.
PRECAUCIÓN:
El primer inicio completo del servidor de suministro puede tardar un
rato. Antes de comenzar ninguna tarea o de cerrar el servidor de
suministro, asegúrese de que se haya iniciado por completo.
Vuelva a crear y migre objetos de datos adicionales de la versión 5.1.1.2
Tras la migración, se pueden completar tareas adicionales fuera de la
ventana de mantenimiento de migración. Estas tareas incluyen la
recreación de imágenes para Tivoli Provisioning Manager for OS
Deployment, la recreación de paquetes de automatización e informes
personalizados y la migración de GUID de IBM Tivoli Application
Dependency Discovery Manager (TADDM). Si las operaciones de
suministro de la versión 5.1.1.2 han utilizado objetos de datos, puede
añadirlos al entorno de suministro 7.1.1.
Cambios entre la versión 5.1.1.2 y la versión 7.1.1
Después de actualizar a la versión 7.1.1, observará muchos cambios en las
funciones y el diseño de Tivoli Provisioning Manager.
Revise las nuevas características y mejoras que se han añadido después de la
versión 5.1.1.2:
v http://publib.boulder.ibm.com/infocenter/tivihelp/v11r1/topic/
com.ibm.tivoli.tpm.admin.doc/overview/rovw_whatsnew.html
Capítulo 1. Visión general de la migración
3
Nota: El soporte de remediación basado en el cliente para la gestión de parches
se ha eliminado en la versión 7.1.
v Novedades de la versión 7.1.1
Mapa de migración
El proceso de migración requiere una serie de tareas en cada fase de la migración.
Utilice las listas de comprobación para ayudarle a navegar por las tareas. Si sigue
las listas de comprobación para asegurarse de que se han realizado todas las tareas
necesarias la migración a la versión 7.1.1 se realizará correctamente.
Lista de comprobación: planificación
Revise la visión general y la información de planificación antes de iniciar el
proceso de migración. Tenga en cuenta el entorno 7.1.1 y las tareas de migración
que se completarán para su plataforma específica.
Tabla 1. Planificación de la migración
Tarea
Sistema
1.Capítulo 1, “Visión general de la migración”, en la página 1
Configuración
Tarea completada
Todas
Lea la visión general para comprender cómo funcionará la migración.
2. Planificación y preparación
Todas
Decida si utilizará una topología de un único servidor o de varios
servidores, el tipo de servidor LDAP y el tipo de servidor de bases de
datos que utilizará en su entorno 7.1.1.
Hay tareas específicas para los diferentes casos de ejemplo de entornos.
3. “Creación de un entorno de prueba” en la página 24
Servidor de suministro
de desarrollo
Todas
Opcional. Antes de comenzar el proceso de migración en su entorno de
producción, complete la migración en un entorno de prueba.
Lista de comprobación: tareas previas a la migración
Antes de ejecutar la ventana de mantenimiento de migración, se deben completar
todas las tareas previas a la migración.
Tabla 2. Tareas que se han de completar antes de iniciar la migración a 7.1.1
Tarea
1. “Actualización del servidor de suministro a la versión 5.1.1.2” en la
página 25
Sistema
Configuración
Servidor de suministro
5.1.x.x
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
7.1.1.
Todas
La actualización a Tivoli Provisioning Manager versión 5.1.1.2 es
necesaria para todos los productos:
v Tivoli Provisioning Manager
v Tivoli Intelligent Orchestrator
v Tivoli Provisioning Manager for Software
2. “Actualización del agente común a la versión 1.3.2.29” en la página
25
Recomendado: Actualice el agente común a la versión más reciente.
Si no se actualizan los agentes comunes antes de la migración, no se
podrán actualizar posteriormente. Los agentes se tendrán que
desinstalar y se instalará el nuevo agente 7.1.1.
3. Descarga de imágenes para la migración.
Recupere las imágenes, ya sea desde el DVD o las descargadas desde
Passport Advantage y colóquelas en el sistema donde instalará Tivoli
Provisioning Manager versión 7.1.1.
4
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea completada
Tabla 2. Tareas que se han de completar antes de iniciar la migración a 7.1.1 (continuación)
Tarea
4. “Copia de los archivos para la instalación de la infraestructura de
distribución escalable” en la página 28
Sistema
Configuración
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor LDAP
Tivoli Directory Server
Tarea completada
Coloque los archivos de instalación para Tivoli Provisioning Manager
for Dynamic Content Delivery, el Servicio del gestor de dispositivos y
Common Agent Services en los directorios especificados.
Estos componentes se instalan durante la migración.
5. “Copia de las herramientas de copia de seguridad en el servidor de
suministro 5.1.1.2” en la página 29
Copie el archivo migration.zip, desde el DVD o desde la imagen de
Passport Advantage, en el servidor de suministro 5.1.1.2.
6. “Copia de seguridad del servidor LDAP” en la página 29
Microsoft® Active
Directory
Recomendado: Realice una copia de seguridad del servidor de LDAP
para que se pueda restaurar si es necesario.
7. “Actualización de Tivoli Directory Server” en la página 30
Servidor LDAP
Tivoli Directory Server
Servidor LDAP
Tivoli Directory Server
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Si resulta aplicable.
Opcional: Actualice Tivoli Directory Server al último nivel soportado de
Tivoli Provisioning Manager.
8. “Configuración de Tivoli Directory Server para migración” en la
página 30
Este paso sólo es necesario si utilizará su servidor LDAP versión 5.1.1.2
en su entorno de suministro 7.1.1.
9. “Copia de seguridad de los paquetes de automatización
personalizados” en la página 34
Si ha creado paquetes de automatización en 5.1.1.2, cópielos en una
ubicación fuera del servidor de suministro, de modo que pueda
añadirlos al servidor de suministro 7.1.1 después de la migración.
10. “Paquetes de automatización 5.1.1.2” en la página 35
Cree una lista de los paquetes de automatización que está utilizando.
Algunos paquetes de automatización de la versión 5.1.12 han quedado
en desuso pero es posible que estén disponibles para descargarlos
desde OPAL después de la migración.
11. Verifique que los paquetes de automatización no tengan una versión
superior a la versión 7.1.1.
Asegúrese de que ninguno de los paquetes de automatización de 5.1.1.2
tengan una versión superior a la versión 7.1.1. Las versiones superiores
pueden crear errores durante la migración.
12. “Exportación de la consulta de informe 5.1.1.2” en la página 36
Exporte la consulta del informe y guárdela en una ubicación fuera del
servidor de suministro 5.1.1.2 para que pueda utilizarla en el entorno
7.1.1.
13. “Migración de repositorios de archivos” en la página 36
Los repositorios de archivos locales no se migran. Anote los repositorios
de archivos locales y su ubicación y haga una copia de seguridad de los
archivos binarios de software en los repositorios de archivos. Puede
volver a crear los repositorios de archivos después de la migración.
14. “Migración de las imágenes creadas utilizando Tivoli Provisioning
Manager for OS Deployment Embedded Edition” en la página 37.
Las imágenes creadas con Tivoli Provisioning Manager for OS
Deployment Embedded Edition no se pueden migrar. Utilice los
métodos proporcionados para volver a crear las imágenes para 7.1.1.
Capítulo 1. Visión general de la migración
5
Tabla 2. Tareas que se han de completar antes de iniciar la migración a 7.1.1 (continuación)
Tarea
Sistema
15. Elimine los apodos y las vistas creadas por la Coexistencia de Tivoli
Configuration Manager.
Servidor de suministro
de 5.1.1.2
Tarea completada
Tivoli Provisioning
Manager o Tivoli
Manager for Software
configurado con la
coexistencia de Tivoli
Configuration Manager.
La coexistencia con Tivoli Configuration Manager no está soportada en
la migración a la versión 7.1.1. Debe desconectar los apodos y las vistas
antes de iniciar la migración. Asimismo, si desea migrar los puntos
finales de Tivoli Management Framework, los debe actualizar al punto
final SDI (Scalable Distribution Infrastructure).
16. Instalación del middleware de Tivoli Provisioning Manager 7.1.1.
Configuración
Servidor de suministro
de 7.1.1
Todas
Servidor LDAP
Microsoft Active
Directory
Reviste la sección de requisitos de componentes para conocer los
requisitos de hardware, software y usuarios.
Instalación del middleware en Windows®, AIX y Linux®
Instalación del middleware en Solaris
17. “Configuración de Microsoft Active Directory para 7.1.1” en la
página 117
Se deben crear usuarios y grupos específicos para la versión 7.1.1.
Después de instalar Microsoft Active Directory, o si está realizando la
migración utilizando un Microsoft Active Directory existente, asegúrese
de que se han creado los usuarios y grupos necesarios utilizando esta
configuración.
18. “Creación de la base de datos y del usuario del servidor de bases de Servidor de suministro
datos” en la página 142
de 7.1.1
Todas
Cree la base de datos y el usuario para la configuración de la base de
datos Maximo.
19. “Instalación de los componentes principales de Tivoli Provisioning
Manager” en la página 144
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 5.1.1.2
Todas
Instale los componentes principales pero no instale los componentes
siguientes durante este paso de instalación:
Tivoli Provisioning Manager for Dynamic Content Delivery
Common Agent Services
Servicio del gestor de dispositivos.
20. “Validación de la instalación” en la página 154
Antes de continuar, complete algunas tareas de validación para verificar
que la versión 7.1.1 se ha instalado correctamente.
20. Completar el archivo de propiedades
Un archivo de propiedades contiene toda la información que requieren
los scripts de migración. Escriba los valores en el archivo, de modo que
esté preparado cuando inicie la migración.
Lista de comprobación: tareas de migración
Todas las tareas de esta sección se han diseñado para que se realicen en la ventana
de mantenimiento de la migración.
Tabla 3. Tareas de migración que se han de completar
Tarea
1. “Cancelación de tareas y planes de actividades” en la página 177
Sistema
Configuración
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 5.1.1.2
Todas
Antes de concluir el servidor de suministro 5.1.1.2 por última vez,
cancele todas las tareas que se estén ejecutando
2. “Detención del servidor de suministro” en la página 178.
Detenga el servidor de suministro antes de iniciar la copia de
seguridad. Una vez concluido el servidor de suministro, no se debe
reiniciar.
6
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea completada
Tabla 3. Tareas de migración que se han de completar (continuación)
Tarea
3. “Copia de seguridad de un servidor de bases de datos remoto” en la
página 179.
Sistema
Configuración
Servidor de bases de
datos
Sólo el servidor de
bases de datos remoto.
Servidor de suministro
de 5.1.1.2
Todas
Servidor de suministro
de 7.1.1
Todas
Tarea completada
Si utiliza un servidor de bases de datos remoto en el entorno de
suministro 5.1.1.2, complete esta tarea.
4. “Copia de seguridad de Tivoli Provisioning Manager 5.1.1.2” en la
página 180
Esta copia de seguridad se debe completar para los servidores de bases
de datos locales y remotos. El script tpm5112backup realiza la copia de
seguridad de la configuración 5.1.1.2 y de la base de datos local.
5. “Inicio del middleware” en la página 184.
Inicie el middleware antes de ejecutar los scripts en el servidor de
suministro 7.1.1.
6. “Acceso a los archivos de migración” en la página 190
Todas
Copie los archivos de copia de seguridad y el archivo de propiedades
en el entorno 7.1.1.
7. “Creación de las vías de acceso de base de datos DB2” en la página
191
Servidor de bases de
datos 7.1.1
Cuando restaure la base de datos, las vías de acceso de base de datos
que tenía en 5.1.1.2 deben existir en 7.1.1 para que la restauración sea
correcta. Asegúrese de que las vías de base de datos se hayan creado
antes de restaurar la base de datos.
8. “Restauración del servidor de bases de datos remoto” en la página
192
Servidor de bases de
datos 7.1.1
Sólo el servidor de
bases de datos remoto.
Servidor de bases de
datos 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Estación de trabajo
administrativa
Todas
Estación de trabajo
administrativa
Todas
Si está utilizando un servidor de bases de datos remoto en el entorno
de suministro 7.1.1, restaure la copia de seguridad de la versión 5.1.1.2
en la base de datos remota.
9. Actualización del archivo de propiedades
Antes de comenzar el proceso de migración en el sistema 7.1.1, abra el
archivo de propiedades y asegúrese de que todos los valores de los
parámetros sean correctos. Es posible que su entorno 7.1.1 sea diferente
de su entorno 5.1.1.2. En especial, asegúrese de que los valores de los
siguientes parámetros sean correctos:
1. dbIsRemote
2. dbHostName
3. orclOSUser
4. wasUser
10. “Restauración y migración de los datos a 7.1.1” en la página 195
Este paso se debe completar para los servidores de bases de datos
locales y remotos. Los scripts tpm711restore y tpm711migrate restauran
y migran la configuración 5.1.1.2 y la base de datos local.
11. “Copia de seguridad de la configuración de base de datos y
WebSphere Application Server” en la página 198
Recomendado: Una vez migrados los datos del servidor de suministro
5.1.1.2 al servidor de suministro 7.1.1, realice la copia de seguridad de
la configuración de la base de datos y del servidor de aplicaciones, de
modo que pueda retrotraerla si surgen problemas durante la instalación
de los servicios básicos.
12. “Instalación de servicios básicos” en la página 199
Instalar los servicios básicos en la estación de trabajo de administración.
13. “Instalación de los componentes web” en la página 216
Instalar los componentes web para Tivoli Provisioning Manager en la
estación de trabajo administrativa.
Capítulo 1. Visión general de la migración
7
Tabla 3. Tareas de migración que se han de completar (continuación)
Tarea
Sistema
Configuración
14. “Asignación del nombre de host 5.1.1.2 al servidor de suministro de
7.1.1” en la página 218
Servidor de suministro
de 7.1.1
Todas
Estación de trabajo
administrativa
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor LDAP
Todas
v Servidor de
suministro de 7.1.1
Todas
Tarea completada
Asignar el nombre de host y la dirección IP del servidor de suministro
5.1.1.2 al servidor de suministro 7.1.1.
15. “Actualización del nombre de host del servidor de bases de datos”
en la página 221
Actualizar el nombre de host del servidor de bases de datos en el
archivo maximo.properties de la estación de trabajo administrativa.
16. “Actualización de los nombres de host restantes” en la página 222
Ejecutar el script, de modo que se actualicen todas las otras instancias
del nombre de host del entorno de suministro 7.1.1.
17. “Inicio del servidor de suministro 7.1.1” en la página 224
Iniciar el servidor de suministro 7.1.1 por primera vez.
Iniciar el servidor de suministro puede tardar algún tiempo debido a
que los paquetes de automatización se actualizan a medida que se
inicia el servidor de suministro. Espere hasta que se haya iniciado el
servidor de suministro para realizar las tareas.
18. “Validación de la migración” en la página 225
Verifique que la migración se ha completado correctamente realizando
algunas operaciones básicas de suministro.
19. “Restauración de la información de LDAP 5.1.1.2 a 7.1.1” en la
página 226
Añada los usuarios y roles de 5.1.1.2 al servidor LDAP 7.1.1.
Este paso es necesario para todos los casos de ejemplo del servidor
LDAP, incluido si ha utilizado la autenticación del sistema operativo en
5.1.1.2.
20. “Migración de los grupos de acceso” en la página 230
Sincronizar el servidor LDAP y el servidor de suministro y luego
migrar los grupos de acceso 5.1.1.2.
21. “Migración de grupos dinámicos” en la página 231
v estación de trabajo
administrativa
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Los grupos dinámicos están disponibles después de la migración pero
es necesario volver a crear la consulta para rellenar los grupos para
7.1.1.
Lista de comprobación: tareas posteriores a la migración
Las tareas de esta sección se pueden completar una vez completada la migración,
si lo permite su planificación.
Tabla 4. Tareas que se han de completar después de la migración
Tarea
1. “Copia de seguridad de la estación de trabajo administrativa” en la
página 235
Sistema
Configuración
Estación de trabajo
administrativa
Todas
Servidor de suministro
de 7.1.1
Todas
La estación de trabajo administrativa no es necesaria para que funcione
Tivoli® Provisioning Manager después de la instalación. No obstante, es
necesaria para instalar parches, actualizaciones, aplicaciones, gestores
de procesos y paquetes de idioma adicionales.
2. Configuración de SSL con IBM HTTP Server
Configure IBM® HTTP Server SSL, de modo que pueda utilizar un
HTTP server externo para acceder a la interfaz de usuario web.
8
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea completada
Tabla 4. Tareas que se han de completar después de la migración (continuación)
Tarea
3. Utilización de Tivoli Monitoring Agent
Sistema
Configuración
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Microsoft Active
Directory
Servidor de suministro
de 7.1.1
Todas
Tarea completada
Opcional. Instale el agente de supervisión con el servidor de suministro.
El agente de supervisión puede identificar, notificar y corregir
problemas comunes de la aplicación que supervisa.
4. Configuración manual de la tarea cron VMMSYNC para Microsoft
Active Directory
Si utiliza Microsoft Active Directory como servidor de directorios,
deberá configurar manualmente la tarea cron VMMSYNC para
sincronizar información de usuarios y grupos.
5. Sincronización de usuarios y grupos
Configurar la planificación de la sincronización entre los repositorios
LDAP y Tivoli Provisioning Manager.
6. Configuración del protocolo https en Solaris
Servidor de suministro
de 7.1.1
Si el servidor de suministro está instalado en Solaris, debe completar
esta tarea de modo que el servidor de suministro reconozca el protocolo
HTTPS correctamente con los motores de Tivoli Provisioning Manager.
7. “Restaure los valores de WebSphere Application Server” en la página
243
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Estación de trabajo
administrativaServidor
de suministro de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Todas
Restaure cualquier valor d configuración que ha utilizado en la versión
5.1.1.2.
8. “Configuración del servidor de suministro para la integración con
otros productos” en la página 243
Si desea integrar Tivoli Provisioning Manager con SRM (Service
Request Manager) o CCMDB (Change and Configuration Management
Database), alguna configuración es necesaria.
9. “Volver a crear los roles personalizados” en la página 244
Añada los roles que ha utilizado en las versión 5.1.1.2.
10. “Volver a crear las imágenes de Tivoli Provisioning Manager for OS
Deployment Embedded Edition” en la página 244
Si ha vuelto a capturar las imágenes de 5.1.1.2 utilizando un servidor
de desarrollo 7.1.1 antes de la migración, ahora puede clonarlas en el
servidor de producción 7.1.1. O puede volver a crear las imágenes de la
versión 5.1.1.2 utilizando el servidor de suministro de la versión 7.1.1.
11. “Migración de los GUID de Tivoli Application Dependency
Discovery Manager” en la página 246
Si utiliza Tivoli Application Dependency Discovery Manager, migre los
GUID de modo que se puedan almacenar correctamente en 7.1.1.
12. “Importación de un certificado SSL para VMware” en la página 247
Si utiliza VMware, importe los certificados SSL al servidor de
suministro de modo que el servidor de suministro se pueda conectar
con VMware Virtual Center.
13. “Restauración y eliminación de paquetes de automatización” en la
página 247
Complete la migración de los paquetes de automatización para la
versión 7.1.1.
14. “Restauración de los repositorios de archivos locales” en la página
250
Ahora que se ha completado la migración, vuelva a crear los
repositorios de archivos y restaure los archivos de software.
15. “Volver a crear la información de conformidad” en la página 250
Ejecute las comprobación de conformidad en los sistemas de destino
para cumplir las recomendaciones y actualizar el estado de
conformidad del servidor de suministro 7.1.1.
Capítulo 1. Visión general de la migración
9
Tabla 4. Tareas que se han de completar después de la migración (continuación)
Tarea
16. “Volver a crear los informes personalizados” en la página 251
Sistema
Configuración
Servidor de suministro
de 7.1.1
Todas
Servidor de suministro
de 7.1.1
Si resulta aplicable.
Servidor de suministro
de 7.1.1
Todas
La versión 7.1.1 utiliza la herramienta de informes BIRT. Vuelva a crear
cualquiera de los informes 5.1.1.2 personalizados.
17. “Migración de las extensiones de inventario” en la página 253
Si utiliza las extensiones de inventario, vuelva a crear las definiciones
de informes para la versión 7.1.1 e importe los informes al servidor de
suministro 7.1.1.
18. “Plan de actividades y tareas de puntos finales” en la página 254
Si el plan de actividades o la tarea de punto final no se ha ejecutado
nunca en la versión 5.1.1.2, se asignará al usuario MAXADMIN durante la
migración. El usuario MAXADMIN puede compartir la tarea con otros
usuarios.
10
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea completada
Capítulo 2. Planificación y preparación
Antes de comenzar la migración a la versión 7.1.1, planifique su entorno 7.1.1.
Existen pasos de migración para los entornos específicos, en función de la
ubicación de la base de datos y del tipo de servidor LDAP.
Revise los temas siguientes para ver los casos de ejemplo soportados y el hardware
necesario para la migración 7.1.1.
Planificar la topología
Utilice esta información para determinar la mejor opción de despliegue del entorno
y las necesidades empresariales.
Hay dos estrategias principales de despliegue:
Custom
Default
XML
Custom
Default
XML
Un solo servidor
La topología de un solo servidor consiste en cargar todos los componentes
de tiempo de ejecución, incluido todo el middleware, la estación de trabajo
administrativa y los gestores de procesos en un sistema. Se suele utilizar a
efectos de evaluación, como una demostración o como un entorno de
aprendizaje. Para gestionar los procesos y los activos empresariales,
normalmente deberá implementar una topología de varios servidores.
Topología de varios servidores
La topología de varios servidores consiste en repartir los componentes en
varias máquinas diferentes. Esto es una ventaja, ya que optimiza el uso de
los recursos y disminuye la carga de trabajo de cada sistema. Este tipo de
despliegue es el típico para los entornos de producción en una empresa.
Un proceso de despliegue típico puede empezar con una topología de un solo
servidor que pasará por las fases de demostración, prueba de concepto funcional e
integración de prueba en el entorno existente, y gradualmente pasará a un entorno
de varios servidores antes de implementar finalmente un despliegue de producción
en la empresa.
Estación de trabajo administrativa
El software que despliega el componente de soporte de Tivoli Provisioning
Manager.
Despliegue de varios servidores
Custom
Default
XML
La topología de despliegue recomendada para un entorno de producción es el
despliegue en varios sistemas.
Custom
Default
XML
El despliegue en varios sistemas sólo está disponible para una
instalación personalizada. Cuando diseñe la estrategia de despliegue, deberá
determinar si incluye sistemas ya establecidos en la red. La instalación de todos los
componentes nuevos utilizando el middleware y los programas de instalación de
Tivoli Provisioning Manager simplifica el despliegue. Si tiene previsto reutilizar o
© Copyright IBM Corp. 2009
11
migrar recursos que ya existen en la red, realice ajustes en el plan de despliegue
para permitir el tiempo necesario para cambiar los recursos existentes a niveles de
versión compatibles con Tivoli Provisioning Manager.
En la siguiente figura, Tivoli Provisioning Manager se ha desplegado en un
conjunto de sistemas.
Servidor de directorios
Servidor de bases de datos
Servidor de suministro
Estación de trabajo administrativa
- Componentes principales - Carpeta de despliegue de Maximo
- Servidor de aplicaciones
- Componentes web
- Servicios básicos
En esta figura, los componentes de Tivoli Provisioning Manager se instalan en
sistemas diferentes para promover el equilibrio de carga, la redundancia, la
reutilización, la seguridad y la disponibilidad. Los componentes también pueden
agruparse de forma lógica e instalarse en el mismo sistema. En un entorno dispar,
el conjunto de sistemas puede ser una combinación de sistemas Windows y
UNIX®. La carpeta de despliegue se utiliza para instalar o actualizar el producto,
pero no es necesaria durante el funcionamiento del producto.
La carpeta de despliegue de estación de trabajo administrativa está soportada en
los siguientes sistemas operativos:
Tabla 5. Plataformas y topologías soportadas para estación de trabajo administrativa
Plataforma utilizada para servidor
de suministro
Mismo sistema
Sistema diferente:
cualquier plataforma
Windows soportada
Windows: cualquier plataforma
soportada
AIX 6.1 TL2 SP2 (IBM System p de
64 bits)
AIX 5.3 TL8 SP2 (IBM System p de
64 bits)
SUSE Linux Enterprise Server 10
SP2 (x86 de 64 bits)
12
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Sistema diferente:
AIX 6.1 TL2 SP2
(IBM System p de 64
bits)
Sistema diferente:
SUSE Linux
Enterprise Server 10
SP2 (x86 de 64 bits)
Tabla 5. Plataformas y topologías soportadas para estación de trabajo administrativa (continuación)
Plataforma utilizada para servidor
de suministro
Mismo sistema
Sistema diferente:
cualquier plataforma
Windows soportada
Sistema diferente:
AIX 6.1 TL2 SP2
(IBM System p de 64
bits)
Sistema diferente:
SUSE Linux
Enterprise Server 10
SP2 (x86 de 64 bits)
v Red Hat Enterprise Linux 5
Update 1 o Update 3 (x86 de 64
bits)
v Red Hat Enterprise Linux 5
Update 1 o Update 3 (IBM
System z de 64 bits)
v Red Hat Enterprise Linux 4 AS
Update 5 (x86 de 64 bits)
v SUSE Linux Enterprise Server 10
SP1 y SP2 (IBM System z de 64
bits)
Solaris 10 (SPARC)
Aunque Tivoli Provisioning Manager requiere un nuevo WebSphere Application
Server para despliegue, cuando se ha desplegado Tivoli Provisioning Manager,
puede añadir el servidor de aplicaciones que utiliza Tivoli Provisioning Manager
como un miembro nuevo de un clúster IBMWebSphere Application Server
Network Deployment existente. Para obtener información acerca de cómo crear un
clúster en WebSphere Application Server Network Deployment, consulte Creación
de un clúster de WebSphere Application Server Network Deployment. Para obtener
información acerca de cómo añadir un miembro a un clúster de WebSphere
Application Server Network Deployment existente, consulte el centro de
información de WebSphere Application Server Network Deployment .
Topologías de varios servidores soportadas
Los siguientes componentes pueden estar en otro sistema:
v El servidor de bases de datos
v El servidor de directorios
v Los estación de trabajo administrativa. Este debe ser un sistema diferente, si se
ha instalado servidor de suministro en una plataforma que no está soportada
por el software de despliegue para servicios básicos y los componentes web.
Reutilización del middleware
Puede reutilizar el middleware existente como componentes de Tivoli Provisioning
Manager. Por ejemplo, puede tener una instancia de base de datos en un servidor
de bases de datos existente que ya haya establecido políticas de acceso, medidas de
redundancia y planes de copia de seguridad. Si tiene previsto utilizar el
middleware existente, asegúrese de que tenga el nivel soportado por Tivoli
Provisioning Manager. Los programas de instalación y de middleware no
proporcionan un mecanismo para crear parches de servidores con niveles de
versiones anteriores, ni proporcionan comprobaciones remotas de requisitos
previos para garantizar que tienen el nivel correcto.
El siguiente middleware puede reutilizarse:
Se puede configurar automáticamente
IBM DB2 9.5 FP3a e IBM Tivoli Directory Server 6.2.0.2 y 6.1.0.10. Para
obtener información acerca de las plataformas específicas para las que está
Capítulo 2. Planificación y preparación
13
soportado Tivoli Directory Server 6.1.0.10, consulte “Verificación de los
requisitos de los componentes” en la página 41. Para obtener información
sobre la reutilización del middleware existente, consulte el apartado
Reutilización del middleware utilizando el instalador de middleware.
Se debe instalar y configurar manualmente
WebSphere Application Server, Oracle Database y Microsoft Active
Directory. Para obtener más información, consulte Utilización del
middleware configurado manualmente.
Despliegue en un solo sistema
El despliegue de un solo sistema se utiliza a menudo como una configuración de
evaluación, formación o demostración.
Esta es la topología que se utiliza para una instalación predeterminada. Todos los
componentes, incluida la estación de trabajo administrativa, se instalan en un
sistema individual con valores predeterminados. Para la instalación personalizada,
un despliegue de servidor individual es una de las topologías posibles.
Nota: La instalación predeterminada sólo está soportada en Windows.
Servidor de suministro
- Componentes principales de
suministro
- Servidor de bases de datos
- Servidor de directorios
- Servidor de aplicaciones
- Componentes web
- Servicios básicos
Puede instalar todos los componentes en un solo sistema si utiliza uno de los
siguientes sistemas operativos:
v Windows Server 2008 Enterprise Edition SP1 (x86 de 64 bits)
v Windows Server 2008 Standard Edition SP1 (x86 de 64 bits)
v
v
v
v
v
Windows Server
Windows Server
Windows Server
Windows Server
AIX 6.1 TL2 SP2
2003 R2 Enterprise Edition SP2 (x86 de 64 bits)
2003 Standard Edition SP2 (x86 de 64 bits)
2003 Enterprise Edition SP2 (x86 de 64 bits)
2003 Standard Edition SP2 (x86 de 32 bits)
(IBM System p de 64 bits)
v SUSE Linux Enterprise Server 10 SP2 (x86 de 64 bits)
La estación de trabajo administrativa debe ser un sistema separado si el servidor
de suministro está instalado en una plataforma que no recibe soporte del software
de despliegue para los servicios básicos y los componentes web. El software de
despliegue sirve para instalar o actualizar el producto, pero no es necesario
durante la operación normal del producto. Para ver detalles sobre las plataformas
de instalación soportadas para componentes del producto, consulte Paso 2 previo a
la instalación: Verificar los requisitos de los componentes.
14
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
La siguiente figura muestra un despliegue con todos los componentes de tiempo
de ejecución de Tivoli Provisioning Manager en un solo sistema y un sistema
separado que actúa como estación de trabajo administrativa.
Servidor de suministro
Estación de trabajo administrativa
- Componentes principales de
suministro
- Servidor de bases de datos
- Servidor de directorios
- Servidor de aplicaciones
- Componentes web
- Servicios básicos
- Carpeta de despliegue de Maximo
Plataformas soportadas y compatibilidad para la migración
Para migrar correctamente desde la versión 5.1.1.2 a la versión 7.1.1, su entorno
debe estar soportado.
La tabla lista los casos de uso soportados para la migración desde Tivoli
Provisioning Manager versión 5.1.1.2 a Tivoli Provisioning Manager versión 7.1.1.
Versión de producto
El servidor de suministro, debe tener el nivel de versión 5.1.1.2 para realizar la
migración a la versión 7.1.1. No es necesario instalar los arreglos internos para la
versión 5.1.1.2 antes de migrar a la versión 7.1.1.
Tabla 6. Vía de acceso de migración
Producto
Versión necesaria para la migración
Tivoli Provisioning Manager
Versión 5.1.1.2.
Tivoli Intelligent Orchestrator
Actualización a Tivoli Provisioning Manager versión
5.1.1.2.
Tivoli Provisioning Manager for Software
Actualización a Tivoli Provisioning Manager versión
5.1.1.2.
Importante: La coexistencia de Tivoli Configuration
Manager no está soportada para la migración a Tivoli
Provisioning Manager 7.1.1. Debe migrar las pasarelas de
Tivoli Configuration Manager a Tivoli Common Agent
Services antes de migrar a la versión 7.1.1.
Plataformas de sistema operativo
Considere los casos de ejemplo soportados para las plataformas de sistemas
operativos
1. Migración del servidor de suministro a la misma plataforma de sistema
operativo.
Por ejemplo, puede migrar un servidor de Tivoli Provisioning Manager 5.1.1.2
en Windows a un servidor 7.1.1 de Windows. No puede migrar desde una
plataforma Windows a una plataforma UNIX.
Capítulo 2. Planificación y preparación
15
2. Migración a las plataformas de 64 bits. No está soportada la migración de 32
bits a 32 bits.
3. Migración a plataformas de sistemas operativos soportadas. Si una plataforma
estaba soportada para la versión 5.1.1.2 pero no está soportada para la versión
7.1.1, no se puede migrar el servidor de suministro a dicha plataforma.
Tabla 7. Plataformas no soportadas en la versión 7.1.1
Plataforma 5.1.1.2
Vía de migración a 7.1.1
Red Hat Enterprise Linux en iSeries y pSeries
No hay una vía de migración soportada.
SUSE Linux Enterprise Server (SLES) en iSeries y pSeries
No hay una vía de migración soportada.
HP-UX en Itanium®
No hay una vía de migración soportada.
Solaris 9
Solaris 10
SLES 9
SLES 10
Red Hat Enterprise Linux 4 86-32
Red Hat Enterprise Linux 5 x86-64
Middleware
Los siguientes casos de ejemplo de middleware no están soportados para la
migración a la versión 7.1.1:
Servidor de bases de datos
1. Base de datos Oracle como servidor de bases de datos instalado en Windows.
2. Actualización desde la base de datos Oracle entre la copia de seguridad y la
restauración de la base de datos. Por ejemplo:
v Actualización de Oracle 10g a Oracle 11g durante la migración. Si realiza una
copia de seguridad de la base de datos 5.1.1.2 Oracle 10g, debe realizar la
restauración a una base de datos Oracle 10g de la versión 7.1.1.
v Restauración de una copia de seguridad de Oracle 10.2.0.1. a Oracle 10.2.0.3.
No se puede restaurar una copia de seguridad realizada en Oracle 10.2.0.1 y
10.2.0.2 en Oracle 10.2.0.3 y superior. Asegúrese de que la base de datos
Oracle utilizada para la copia de seguridad y la restauración esté en el
mismo nivel de versión.
Servidor LDAP
El tipo de servidor LDAP utilizado en la versión 7.1.1 debe tener el mismo tipo
que se ha utilizado en 5.1.1.2. No puede migrar a un tipo de LDAP diferente.
Tabla 8. Casos de ejemplo LDAP soportados
LDAP utilizado en la versión 5.1.1.2
LDAP utilizado en la versión 7.1.1
Microsoft Active Directory
Microsoft Directory Server
Tivoli Directory Server
Tivoli Directory Server
Compatibilidad con FIPS (Federal Information Processing
Standard) 140-2
FIPS (Federal Information Processing Standard) es un estándar emitido por NIST (
National Institute of Standards and Technology) de EE. UU: para los sistemas
informáticos gubernamentales. El estándar 140-2 especifica los requisitos para los
módulos criptográficos. FIPS no está soportado en la migración de 5.1.1.2 a 7.1.1.
16
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Automation Package Developer Environment
Automation Package Developer Environment sólo está soportado en sistemas
Windows y Linux de 32 bits. Dado que la migración del servidor de suministro
sólo está soportada en sistemas Windows y Linux de 64 bits, no se puede instalar
Automation Package Developer Environment en el mismo sistema que el servidor
de suministro. Se debe instalar en un sistema remoto. Para obtener las
instrucciones detalladas, consulte el tema Instalación de Automation Package
Developer Environment en un sistema remoto en el centro de información de Tivoli
Provisioning Manager versión 7.1.1.
Hardware necesario
Revise la lista del hardware necesario para realizar la migración desde 5.1.1.2 a
7.1.1.
La tabla lista el hardware necesario para migrar Tivoli Provisioning Manager desde
la versión 5.1.1.2 a la versión 7.1.1.
Tabla 9. Hardware necesario
Nombre
Descripción
Uso
Servidor de suministro de 5.1.1.2
El servidor de suministro original
que está migrando a la versión 7.1.1.
Haga una copia de seguridad de la
base de datos original y exporte la
configuración y los valores originales.
Servidor de suministro de 7.1.1
El nuevo sistema en que se instalará
Tivoli Provisioning Manager versión
7.1.1. El nombre de host y la
dirección IP del servidor de
suministro 5.1.1.2 se cambiará por el
de este sistema nuevo.
Importante: Antes de comenzar la
migración, consulte al administrador
de la red para asegurarse de que la
dirección IP del servidor de
suministro 7.1.1 se puede modificar.
Los datos del servidor de suministro
5.1.1.2 se restaurarán en este sistema.
Servidor LDAP
Las versiones 5.1.1.2 y 7.1.1
apuntarán al mismo LDAP si se
utiliza el mismo servidor LDAP
corporativo.
Se migrarán los usuarios LDAP, roles,
grupos de acceso y permisos de
grupo.
Si se utiliza el mismo servidor LDAP
corporativo, se debe completar la
copia de seguridad del esquema
LDAP 5.1.1.2 antes de iniciar la
migración, de modo que se pueda
retrotraer un usuario al esquema
LDAP y datos existentes si se
produce un problema con la
migración.
Si el servidor LDAP está instalado y
se gestiona en el mismo servidor que
el servidor de suministro 5.1.1.2, se
debe instalar un servidor LDAP
nuevo en el servidor de suministro
7.1.1. El servidor LDAP original no se
debe modificar.
Servidor de bases de datos
Si está utilizando un servidor de
bases de datos DB2, versión 9.5, se
debe instalar en el servidor de
suministro 7.1.1 nuevo.
Estación de trabajo administrativa
Se utiliza este sistema Windows
Para las plataformas siguientes, no se
separado para configurar los servicios necesita otro sistema:
básicos.
v Windows
Se utilizará una instancia de base de
datos diferente para migrar los datos
5.1.1.2.
v AIX 6.1.1
v SLES 10 x86-64
Capítulo 2. Planificación y preparación
17
Tabla 9. Hardware necesario (continuación)
Nombre
Descripción
Uso
Servidor de desarrollo 7.1.1.
Recomendado: cree un servidor de
desarrollo 7.1.1 para validar el
proceso de migración antes de
ejecutar la migración en un servidor
de producción.
Este sistema se utiliza para ejecutar y
verificar el proceso de migración
antes de aplicar la migración al
servidor de producción 7.1.1.
Este sistema también se utilizará para
volver a crear las imágenes de la
versión 5.1.1.2 de IBM Tivoli
Provisioning Manager for OS
Deployment que se copiarán en el
servidor de suministro 7.1.1.
Contraseñas necesarias
Revise la lista de contraseñas que se necesitan durante el proceso de migración.
La migración se completa utilizando una serie de scripts de copia de seguridad,
restauración, migración y actualización de los datos 5.1.1.2 en el servidor de
suministro 7.1.1. Cuando ejecute los scripts, se le solicitarán varias contraseñas.
Antes de continuar, revise la lista de todas las contraseñas necesarias y téngalas
preparadas para cuando comience el proceso de migración.
Tabla 10. Contraseñas para la configuración de DB2
Contraseña
Descripción
Usuario de base de datos
La contraseña del usuario de la instancia de base de
datos
Usuario administrador de base de datos
La contraseña del usuario administrador de base de
datos.
Tabla 11. Contraseñas para la configuración de base de datos Oracle
Contraseña
Descripción
Usuario SYS
La contraseña del usuario Oracle, SYS.
Usuario CDSSCHEMA
La contraseña del usuario Oracle, CDSSCHEMA.
Tabla 12. Contraseñas para el gestor de agentes
Contraseña
Descripción
Gestor de agentes
La contraseña del gestor de agentes que se ha utilizado
en la versión 5.1.1.2.
Registro del agente
La contraseña del registro del gestor de agentes que se ha
utilizado en la versión 5.1.1.2.
Gestor de recursos del gestor de agentes
La contraseña para el nombre de usuario del gestor de
agentes para el gestor de atentes.
Nota: El instalador de Tivoli Provisioning Manager
5.1.1.2 crea la contraseña para este usuario. La contraseña
predeterminada que crea el instalador es password. Utilice
esta contraseña a menos que haya modificado la
contraseña después de la instalación de 5.1.1.2.
SSL del gestor de recursos
La contraseña SSL del gestor de recursos. La contraseña
predeterminada es CDSRMPASS
Tabla 13. Contraseñas para el servidor de suministro
18
Contraseña
Descripción
Almacén de claves de Tivoli Provisioning Manager
La contraseña del almacén de claves que se ha utilizado
en la versión 5.1.1.2.
Usuario de la interfaz web de suministro
La contraseña del usuario maxadmin.
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 14. Contraseñas para la configuración de WebSphere Application Server
Contraseña
Descripción
Contraseña de WebSphere Administrative Server
La contraseña del administrador de WebSphere
Application Server.
Consideraciones acerca del servidor de bases de datos
Revise los casos de ejemplo de migración para migrar la información del servidor
de bases de datos.
Durante el proceso de migración, se realiza una copia de seguridad de la
información de base de datos en el servidor de bases de datos de 5.1.1.2 y se
restaura en el servidor de bases de datos 7.1.1.
Existen opciones diferentes para la migración, en función del entorno de
suministro 5.1.1.2. Por ejemplo, si el servidor de bases de datos 5.1.1.2 es local (en
el mismo sistema que Tivoli Provisioning Manager) debe utilizar un servidor de
bases de datos nuevo para la versión 7.1.1. El nuevo servidor de bases de datos
puede ser local o remoto (en un sistema Tivoli Provisioning Manager diferente).
Consulte la tabla para ver las opciones de migración para su entorno específico.
Tabla 15. vías de migración soportadas para el servidor de bases de datos 5.1.1.2
Servidor de bases de datos
5.1.1.2
Servidor de bases de datos
7.1.1 nuevo
Servidor de bases de datos
7.1.1 remoto (nuevo o
existente)
DB2 local
DB2 remoto
Base de datos Oracle local
Base de datos Oracle remota
Pasos de migración para el servidor de bases de datos
Los pasos para la migración del servidor de bases de datos son diferentes para los
servidores de bases de datos local y remoto. Las tablas describen los pasos
necesarios para migrar la base de datos 5.1.1.2 a la versión 7.1.1.
Tabla 16. Pasos de migración para una base de datos local
Instalación de un servidor de bases
de datos nuevo
Pasos previos a la migración
Nueva base de datos local
“Instalación del
middleware con el instalador de
middleware” en la página 83
Oracle
2000
Instalación de la base
de datos Oracle
Base de datos remota nueva
“Instalación del
middleware con el instalador de
middleware” en la página 83
Oracle
2000
Instalación de la base
de datos Oracle
Pasos de migración
1. “Copia de seguridad de Tivoli
Provisioning Manager 5.1.1.2” en
la página 180
2. “Restauración y migración de los
datos a 7.1.1” en la página 195
1. “Copia de seguridad de Tivoli
Provisioning Manager 5.1.1.2” en
la página 180
2. “Restauración del servidor de
bases de datos remoto” en la
página 192
3. “Restauración y migración de los
datos a 7.1.1” en la página 195
Capítulo 2. Planificación y preparación
19
Tabla 17. Pasos de migración para una base de datos remota
Instalación de un servidor de bases
de datos nuevo
Instalar una base de datos remota
nueva
Pasos previos a la migración
“Instalación del
middleware con el instalador de
middleware” en la página 83
Oracle
2000
Instalación de la base
de datos Oracle
Pasos de migración
1. “Copia de seguridad de un
servidor de bases de datos
remoto” en la página 179
2. “Copia de seguridad de Tivoli
Provisioning Manager 5.1.1.2” en
la página 180
3. “Restauración del servidor de
bases de datos remoto” en la
página 192
4. “Restauración y migración de los
datos a 7.1.1” en la página 195
Consideraciones acerca del servidor LDAP
Existen varios casos de ejemplo para la migración del servidor LDAP. Utilice esta
información para identificar su caso, de modo que pueda gestionar la migración.
Servidores de directorios soportados para la versión 7.1.1:
1. Tivoli Directory Server
2. Microsoft Active Directory
Nota: Se da soporte a la autenticación del sistema operativo en Tivoli Provisioning
Manager 5.1.1.2. Cuando migra a 7.1.1, debe instalar un servidor LDAP para
utilizarlo en el entorno de suministro.
Vías de migración soportadas
Se da soporte a varias vías de acceso de migración, en función del entorno LDAP
5.1.1.2 existente.
LDAP local
Si está utilizando un servidor LDAP local, el LDAP está en el mismo
sistema que el servidor de suministro de 5.1.1.2, debe instalar un nuevo
servidor LDAP para la versión 7.1.1.
LDAP remota
Si está utilizando un servidor LDAP remoto, el LDAP está en un sistema
diferente al del servidor de suministro 5.1.1.2, puede utilizar el LDAP
existente para 7.1.1 o puede instalar un LDAP nuevo.
Consulte la tabla siguiente para ver las vías de migración soportadas para su
entorno LDAP.
Tabla 18. Vías de acceso de migración soportadas para la versión 7.1.1
Entorno 5.1.1.2
Instale el nuevo LDAP
local 7.1.1
Autenticación del sistema
operativo
Tivoli Directory Server local
Tivoli Directory Server
remoto
Microsoft Active Directory
local
Microsoft Active Directory
remoto
20
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Instale el nuevo LDAP
remoto 7.1.1
Use el LDAP remoto
5.1.1.2 existente
Este diagrama proporciona una visión general del proceso de migración para los
usuarios y roles del entorno 5.1.1.2. Hay tareas específicas necesarias, en función de
su entorno de suministro 7.1.1. Por ejemplo, el proceso de migración para reutilizar
un servidor LDAP remoto existente es diferente de si está utilizando un servidor
LDAP nuevo.
Revise el diagrama y la descripción de los procesos siguientes para ver qué tareas
serán necesarias en la migración de su entorno específico.
Tareas previas a la migración
No
Tivoli Directory Server
Microsoft Active Directory
Autenticación del SO
¿Utilizar servidor
LDAP existente
para 7.1.1?
¿Utilizar servidor
LDAP existente
para 7.1.1?
¿Utilizar
Microsoft Active
Directory?
Sí
Sí
Copia de seguridad
del servidor LDAP
Copia de seguridad
del servidor LDAP
Actualizar Tivoli Directory
Server (opcional)
Configurar Microsoft
Active Directory para 7.1.1
No
Sí
No
Instalar Microsoft Active
Directory
Configurar Tivoli Directory
Server para la migración
Instalar Tivoli
Directory Server
durante la
instalación de 7.1.1
Instalar Tivoli Provisioning
Manager versión 7.1.1
Instalar Tivoli
Directory Server
durante la
instalación de 7.1.1
Migración
Copia de seguridad de Tivoli
Provisioning Manager 5.1.1.2
Adding the 5.1.1.2 users
and roles to the 7.1.1
LDAP
Estas tablas proporcionan los detalles del proceso de migración para los servidores
de LDAP soportados en 7.1.1. Revise el proceso del entorno de suministro.
Capítulo 2. Planificación y preparación
21
Tabla 19. Autenticación del sistema operativo
Utilice un servidor LDAP nuevo o existente
Pasos previos de la migración para 7.1.1
Pasos de migración para 7.1.1
Instale el nuevo LDAP
Instale uno de los servidores LDAP soportados
para la versión 7.1.1.
1. “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Si estaba utilizando la autenticación del sistema
operativo para la seguridad de usuario y grupos Instale Tivoli Directory Server
de una versión anterior, debe utilizar un
v Instale Tivoli Directory Server (local o remoto)
servidor LDAP de la versión 7.1.1.
durante la instalación de middleware de
Tivoli Provisioning Manager.
Durante la copia de seguridad del servidor
de suministro de 5.1.1.2, los usuarios del
sistema operativo se extraerán de la base de
datos de suministro y se importarán a un
archivo LDIF.
2. “Restauración de la información de LDAP
5.1.1.2 a 7.1.1” en la página 226
o
Instale Microsoft Active Directory
1. Instalación de Microsoft Active Directory
Importe la información de usuarios de 5.1.1.2
al servidor de suministro 7.1.1.
Instale manualmente Microsoft Active
Directory (remoto o local).
2. Configuración de Microsoft Active Directory
Configure Microsoft Active Directory para
crear los usuarios y grupos necesarios para
la versión 7.1.1.
3. “Configuración de Microsoft Active
Directory para 7.1.1” en la página 117
En la versión 7.1.1, los usuarios y grupos
deben pertenecer a unidades organizativas
(ou) diferentes. Asegúrese de que ha creado
unidades organizativas diferentes antes de
iniciar la migración.
Tabla 20. Tivoli Directory Server
Utilice un servidor LDAP nuevo o existente
Pasos previos de la migración para 7.1.1
Pasos de migración para 7.1.1
Instale el nuevo LDAP
Instale Tivoli Directory Server (local o remoto)
durante la instalación de middleware de Tivoli
Provisioning Manager 7.1.1.
1. “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Si utiliza un servidor LDAP local para 5.1.1.2,
no se debe modificar. Debe instalar un servidor
LDAP nuevo, ya sea local o remoto.
Durante la copia de seguridad, se recopila la
información de usuarios y roles de la base
de datos de suministro y la información de
usuarios del servidor de LDAP. Sólo se
recopilará la información de usuarios que es
común entre la base de datos de suministro
y LDAP; es posible que haya muchos
usuarios en LDAP que no necesiten acceder
al servidor de suministro. La copia de
seguridad también correlaciona los roles de
5.1.1.2 con los roles de 7.1.1, de forma que se
puedan utilizar en la versión 7.1.1.
Se crea un archivo LDIF, que contienen
información de usuarios, grupos y miembros
de grupos.
2. “Restauración de la información de LDAP
5.1.1.2 a 7.1.1” en la página 226
Restaure la información de usuarios y
grupos de 5.1.1.2, contenida en el archivo
LDIF, al servidor de suministro 7.1.1.
22
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 20. Tivoli Directory Server (continuación)
Utilice un servidor LDAP nuevo o existente
Pasos previos de la migración para 7.1.1
Pasos de migración para 7.1.1
Utilice el LDAP existente
1. “Copia de seguridad del servidor LDAP” en
la página 29
1. “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Sólo puede utilizar su servidor LDAP existente
si su LDAP 5.1.1.2 es remoto y no está en el
mismo sistema que el servidor de suministro
5.1.1.2.
Realice una copia de seguridad de su
servidor LDAP existente. Se debe realizar
una copia de seguridad de los datos LDAP
antes de iniciar la migración para que sea
posible retrotraer los datos originales si
encuentra problemas durante la migración.
2. “Actualización de Tivoli Directory Server”
en la página 30
Opcional. Actualice Tivoli Directory Server a
la versión más reciente soportada para 7.1.1:
3. “Configuración de Tivoli Directory Server
para migración” en la página 30
Configure su servidor LDAP existente de
modo que los usuarios sean compatibles con
la versión más reciente de WebSphere
Application Server 6.1.
Durante la copia de seguridad, se recopila la
información de usuarios y roles de la base
de datos de suministro y la información de
usuarios del servidor de LDAP. Sólo se
recopilará la información de usuarios que es
común entre la base de datos de suministro
y LDAP; es posible que haya muchos
usuarios en LDAP que no necesiten acceder
al servidor de suministro. La copia de
seguridad también correlaciona los roles de
5.1.1.2 con los roles de 7.1.1, de forma que se
puedan utilizar en la versión 7.1.1.
Se crea un archivo LDIF, que contienen
información de usuarios, grupos y miembros
de grupos.
2. “Restauración de la información de LDAP
5.1.1.2 a 7.1.1” en la página 226
Restaure la información de usuarios y
grupos de 5.1.1.2, contenida en el archivo
LDIF, al servidor de suministro 7.1.1.
Tabla 21. Microsoft Active Directory
Utilice un servidor LDAP nuevo o existente
Pasos previos de la migración para 7.1.1
Pasos de migración para 7.1.1
Instale el nuevo LDAP
1. Instalación de Microsoft Active Directory
1. “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Si utiliza un servidor LDAP local para 5.1.1.2,
no se debe modificar. Debe instalar un servidor
LDAP nuevo, ya sea local o remoto.
Instale manualmente Microsoft Active
Directory (remoto o local).
2. “Configuración de Microsoft Active
Directory para 7.1.1” en la página 117
Configure Microsoft Active Directory para
crear los usuarios y grupos necesarios para
la versión 7.1.1.
Utilice el LDAP existente
Sólo puede utilizar su servidor LDAP existente
si su LDAP 5.1.1.2 es remoto.
1. “Copia de seguridad del servidor LDAP” en
la página 29.
Realice una copia de seguridad de su
servidor LDAP existente. Se debe realizar
una copia de seguridad de los datos LDAP
antes de iniciar la migración para que sea
posible retrotraer los datos originales si
encuentra problemas durante la migración.
2. “Configuración de Microsoft Active
Directory para 7.1.1” en la página 117
Configure Microsoft Active Directory para
crear los usuarios y grupos necesarios para
la versión 7.1.1.
Este paso crea el archivo LDIF con la
información de usuarios y grupos.
2. “Restauración de la información de LDAP
5.1.1.2 a 7.1.1” en la página 226
Restaure la información de usuarios y
grupos de 5.1.1.2, contenida en el archivo
LDIF, al servidor de suministro 7.1.1.
1. “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Durante la copia de seguridad, se recopila la
información de usuarios y roles de la base
de datos de suministro y la información de
usuarios del servidor de LDAP. Sólo se
recopilará la información de usuarios que es
común entre la base de datos de suministro
y LDAP; es posible que haya muchos
usuarios en LDAP que no necesiten acceder
al servidor de suministro. La copia de
seguridad también correlaciona los roles de
5.1.1.2 con los roles de 7.1.1, de forma que se
puedan utilizar en la versión 7.1.1.
Se crea un archivo LDIF, que contienen
información de usuarios, grupos y miembros
de grupos.
2. “Restauración de la información de LDAP
5.1.1.2 a 7.1.1” en la página 226
Restaure la información de usuarios y
grupos de 5.1.1.2, contenida en el archivo
LDIF, al servidor de suministro 7.1.1.
Capítulo 2. Planificación y preparación
23
Creación de un entorno de prueba
Recomendado. Cree un entorno de prueba utilizando un servidor de desarrollo para
realizar una migración de prueba antes de intentar realizar el proceso de migración
en un servidor de producción mediante su ventana de mantenimiento.
Instale Tivoli Provisioning Manager versión 7.1.1 en un sistema de prueba para
ejecutar y verificar el proceso de migración. Hay muchos pasos en la migración de
5.1.1.2 a 7.1.1. Completar la ejecución de una prueba le ayudará a que la ejecución
del proceso de migración al servidor de suministro de producción se realice sin
problemas.
También se puede utilizar un entorno de prueba para ayudarle a volver a crear las
imágenes de Tivoli Provisioning Manager for OS Deployment que tiene en su
servidor de suministro 5.1.1.2. Estas imágenes no se pueden migrar porque el
formato de imagen no es compatible con el producto Tivoli Provisioning Manager
for OS Deployment que se utiliza en la versión 7.1.1. Utilice el entorno de prueba
para volver a capturar las imágenes que necesita y una vez completado el proceso
de migración, podrá clonarlas en el servidor de suministro 7.1.1 de producción.
Para obtener más información acerca de cómo utilizar un servidor de suministro
de desarrollo para capturar las imágenes de la versión 5.1.1.2, consulte el tema
“Migración de las imágenes creadas utilizando Tivoli Provisioning Manager for OS
Deployment Embedded Edition” en la página 37.
24
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 3. Tareas previas a la migración
Complete las tareas que son requisitos previos para la migración.
Actualización del servidor de suministro a la versión 5.1.1.2
La versión del servidor de suministro debe ser el nivel de versión 5.1.1.2, de modo
que pueda realizar la migración a Tivoli Provisioning Manager 7.1.1. Si el servidor
de suministro tiene una versión inferior a la versión 5.1.1.2, debe actualizarlo antes
de iniciar la migración.
Actualice a la versión 5.1.1.2 si actualmente está ejecutando cualquiera de los
siguientes productos y versiones:
Tabla 22. Actualización de la versión 5.1 a la versión 5.1.1
Producto
Información de actualización
Tivoli Provisioning Manager
http://publib.boulder.ibm.com/infocenter/tivihelp/
v20r1/index.jsp
Tivoli Intelligent Orchestrator
http://publib.boulder.ibm.com/infocenter/tivihelp/
v19r1/index.jsp
Tabla 23. Actualización de la versión 5.1.1 a la versión 5.1.1.1
Producto
Información de actualización
Tivoli Provisioning Manager
http://www-01.ibm.com/support/
docview.wss?uid=swg24018403
Tivoli Intelligent Orchestrator
http://www-01.ibm.com/software/sysmgmt/products/
support/Q548236O32114F76-download.html
Tivoli Provisioning Manager for Software
http://www-01.ibm.com/software/sysmgmt/products/
support/M588299R65585S90-download.html
Tabla 24. Actualización de la versión 5.1.1.1 a la versión 5.1.1.2
Cabecera
Cabecera
Tivoli Provisioning Manager
http://www-01.ibm.com/support/
docview.wss?&uid=swg24021726
Tivoli Intelligent Orchestrator
http://www-01.ibm.com/software/
sysmgmt/products/support/
Q548236O32114F76-download.html
Tivoli Provisioning Manager for Software
http://www-01.ibm.com/software/
sysmgmt/products/support/
M588299R65585S90-download.html
Qué hacer a continuación
“Actualización del agente común a la versión 1.3.2.29”
Actualización del agente común a la versión 1.3.2.29
Actualice el agente común al nivel más reciente antes de realizar la migración a
7.1.1, de modo que tenga las funciones más recientes.
© Copyright IBM Corp. 2009
25
Antes de empezar
Actualice el servidor de suministro a la versión 5.1.1.2 antes de actualizar el agente
común.
El agente común se debe actualizar a la versión 1.3.2.29 en los dos servidores de
depósito y los puntos finales que participan en el proceso de distribución de
software. Los servidores de depósito se debe actualizar antes de actualizar los
sistemas de destino. No actualice los sistemas de depósito y de destino al mismo
tiempo.
Si decide no actualizar los agentes comunes antes de la migración, no se podrán
actualizar después de la migración. Los agentes se tendrán que desinstalar y se
instalará el nuevo agente 7.1.1.
1. Publique la actualización de Tivoli Common Agent instalable en el depósito de
servidor de carga preferido. Utilice el archivo instalable para su plataforma
específica, como se indica más adelante. Para obtener información detallada
acerca de cómo publicar los archivos en los depósitos, consulte el tema
″Publicación de archivos en servidores de depósito″ en el centro de información
de Tivoli Provisioning Manager versión 5.1.1.: http://publib.boulder.ibm.com/
infocenter/tivihelp/v20r1/topic/com.ibm.tivoli.tpm.ept.doc/software/
tsfd_publishfiles.html
v Archivo instalable de actualización TCA-1.3.2.29 AIX
v Archivo instalable de actualización TCA-1.3.2.29 HP-UX en Itanium
v Archivo instalable de actualización TCA-1.3.2.29 HP-UX
v Archivo instalable de actualización TCA-1.3.2.29 Linux390
v Archivo instalable de actualización TCA-1.3.2.29 Linux86
v Archivo instalable de actualización TCA-1.3.2.29 LinuxPPC
v Archivo instalable de actualización TCA-1.3.2.29 Solaris
v Archivo instalable de actualización TCA-1.3.2.29 Solaris x86
v Archivo instalable de actualización TCA-1.3.2.29 Windows
2. Para actualizar los sistemas de destino, inicie la sesión en la interfaz web y
vaya a Gestión de software → Actualizar → Producto de software.
3. En la sección Seleccionar software, seleccione el archivo instalable de
actualización de Tivoli Common Agent, TCA-1.3.2.29.
4. En la sección Seleccionar sistemas, utilice la lista Visualización para filtrar los
sistemas visualizados. Seleccione los sistemas de destino en los que actualizar el
agente común. No seleccione el servidor de depósito. Los sistemas que ha
seleccionado se pueden verificar en la sección Sistemas seleccionados.
5. En la sección Planificar, haga clic en Ahora para ejecutar la tarea de instalación
del agente común de forma inmediata o especifique la fecha y hora en la que
desea que se inicie la tarea.
6. Si desea que se le notifique acerca del estado de la tarea, especifique los valores
de notificación adecuados en la sección Notificación.
7. Haga clic en Enviar.
Resultados
Cuando envía la tarea, se muestra la página Realizar seguimiento de tareas. Puede
hacer clic en el nombre de la tarea para ver detalles sobre su estado y supervisar
su proceso hasta que finalice la tarea. Haga clic en Renovar para actualizar su
estado.
26
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Qué hacer a continuación
“Preparación de las imágenes de migración”
Preparación de las imágenes de migración
Guarde las imágenes en el sistema donde instalará Tivoli Provisioning Manager
versión 7.1.1.
El paquete de Tivoli Provisioning Manager incluye en soporte de instalación
correspondiente a Tivoli Provisioning Manager y el software de requisito previo.
Como cliente bajo licencia, puede obtener el soporte de instalación de:
v El sitio web de IBM Passport Advantage
v Los DVD de instalación
Nota:
No se proporcionan imágenes de instalación de Oracle
Database. Si está utilizando la Oracle Database, debe obtener por su cuenta el
soporte de instalación.
v No se proporcionan imágenes de instalación de Microsoft Active Directory. Si
está utilizando la Microsoft Active Directory, debe obtener por su cuenta el
soporte de instalación.
1. Descargue las imágenes desde Passport Advantage. Para obtener más
información vaya a: http://www.ibm.com/support/docview.wss?rs=1015
&uid=swg24023802
v
UNIX
2.
Linux
UNIX
En el sistema donde instalará la versión 7.1.1, inicie la
Linux
sesión como root.
3. Coloque las imágenes descargadas en un único directorio en el sistema. Por
ejemplo: Windows
C:\install_images
UNIX
/install_images
UNIX
Nota:
v Extraiga los archivos en el sistema donde ejecuta el instalador porque los
archivos deben tener los permisos correctos cuando se extraen de las
imágenes.
v Si su estación de trabajo administrativa está en otro sistema, sólo deberá
extraer el contenido de la imagen de instalación en la estación de trabajo
administrativa. Esta es la imagen que contiene TPM_V711_Install en el
nombre.
4. Extraiga el contenido de las imágenes en el directorio que ha creado.
v
Windows
v
AIX
v
5.
Utilice Winzip
Utilice gtar
Linux
Utilice tar
Si tiene instalado Cygwin, ejecute el mandato siguiente para
establecer los permisos adecuados:
Windows
chmod -R 775 dir_extracción
Capítulo 3. Tareas previas a la migración
27
donde dir_extracción es la vía de acceso completa del directorio donde ha
extraído las imágenes.
Qué hacer a continuación
“Copia de los archivos para la instalación de la infraestructura de distribución
escalable”.
Copia de los archivos para la instalación de la infraestructura de
distribución escalable
Extraiga las imágenes de la infraestructura de distribución escalable en el sistema,
de modo que se instalen durante la migración.
Durante la migración, se instalará la infraestructura de distribución escalable:
Common Agent Services
Tivoli Provisioning Manager for Dynamic Content Delivery
Servicio del gestor de dispositivos
Antes de ejecutar los scripts de migración, prepare las instalaciones creando los
directorios y copiando las imágenes en los directorios.
1. En el sistema en el que instalará la versión 7.1.1, abra la carpeta een la que ha
extraído las imágenes de los DVD del producto o que ha descargado desde
Passport Advantage.
2. Busque el archivo comprimido de los componentes principales para su sistema
operativo específico. Por ejemplo, TPM_V711_CoreComp_1of2_LinuxX64.tar o
TPM_V711_CoreComp_WinX64.zip. En cada archivo encontrará imágenes para la
instalación de la infraestructura de distribución de software.
3. Extraiga las imágenes y guárdelas en la ubicación especificada en el sistema
7.1.1:
Windows
a. Archivos binarios de Common Agent Services: Extraiga el archivo
AM_V142_Windows.zip en el directorio \<dir_imágenes>\CASInstaller.
b. Archivos binarios de Dynamic Content Delivery: Extraiga el archivo
DCD_V21_Windows.zip en el directorio \<dir_imágenes>\DCDInstaller.
c. Archivos binarios del Servicio del gestor de dispositivos: Extraiga el
archivo DMS_V20_multiplatf.zip en el directorio \<dir_imágenes>\
DMSInstaller.
UNIX
a. Archivos binarios de Common Agent Services: Extraiga el archivo
AM_V142_<plataforma>.tar en el directorio /<dir_imágenes>/CASInstaller.
b. Archivos binarios de Dynamic Content Delivery: Extraiga el archivo
DCD_V21_<plataforma>.tar en el directorio /<dir_imágenes>/DCDInstaller.
c. Archivos binarios del Servicio del gestor de dispositivos: Extraiga el
archivo DMS_V20_multiplatf.tar.gz en el directorio /<dir_imágenes>/
DMSInstaller.
donde plataforma es el sistema operativo específico y dir_imágenes es la
ubicación de las imágenes.
Consejo: Recuerde el valor de dir_imágenes. Necesitará este valor cuando
rellene el archivo de propiedades.
28
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Qué hacer a continuación
“Copia de las herramientas de copia de seguridad en el servidor de suministro
5.1.1.2”
Copia de las herramientas de copia de seguridad en el servidor de
suministro 5.1.1.2
Para realizar la copia de seguridad del servidor de suministro 5.1.1.2, necesita el
archivo de script y el archivo de propiedades que completan la copia de seguridad.
Extraiga estos archivos de la imagen del producto en el servidor de suministro
5.1.1.2.
1. Inicie la sesión en el servidor de suministro 5.1.1.2.
v
Windows
Inicie la sesión como tioadmin.
UNIX
Inicie la sesión como root.
v
2. Cambie el nombre de la carpeta TIO_HOME/migration por migration_old.
Donde TIO_HOME es el directorio de instalación de Tivoli Provisioning
Manager. El directorio predeterminado es:
v
Windows
C:\Archivos de programa\IBM\tivoli\tpm
/opt/IBM/tivoli/tpm
3. En el DVD de instalación de Tivoli Provisioning Manager, Versión 7.1.1, busque el
archivo migration/tpm5112migration.zip. Si está descargando las imágenes de
Passport Advantage, el archivo tpm5112migration.zip está en la imagen
TPM_V711_Install_<platform>, donde platform es Win o Unix.
4. Copie el archivo tpm5112migration.zip en un directorio temporal del servidor
de suministro.
5. Extraiga el archivo en el directorio TIO_HOME del servidor de suministro
5.1.1.2. Este crea una carpeta denominada migration que contiene todos los
scripts necesarios para realizar la copia de seguridad de los datos de
suministro.
v
UNIX
Linux
Qué hacer a continuación
“Copia de seguridad del servidor LDAP”
Copia de seguridad del servidor LDAP
Antes de iniciar la migración, cree una copia de seguridad del servidor LDAP de
modo que pueda regresar a la versión original si es necesario.
Si va a utilizar el servidor LDAP existente después de la migración a 7.1.1, se le
recomienda que cree una copia de seguridad de su servidor LDAP, de modo que
se pueda restaurar si es necesario.
Siga las instrucciones del producto para su servidor LDAP soportado:
v Tivoli Directory Server: http://publib.boulder.ibm.com/infocenter/tivihelp/
v2r1/index.jsp?topic=/com.ibm.IBMDS.doc_6.1/admin_gd43.htm
v Microsoft Active Directory: http://technet.microsoft.com/en-us/library/
bb727048.aspx
Capítulo 3. Tareas previas a la migración
29
Qué hacer a continuación
v Si está utilizando su Tivoli Directory Server existente para el entorno de
suministro 7.1.1, consulte “Tareas previas a la migración para Tivoli Directory
Server”
v Si está utilizando un Tivoli Directory Server nuevo o Microsoft Active Directory
en 7.1.1, consulte “Requisitos previos para la migración de paquetes de
automatización” en la página 32.
Tareas previas a la migración para Tivoli Directory Server
Si está utilizando un Tivoli Directory Server existente para su entorno de
suministro 7.1.1, prepare el servidor de directorios para la migración.
Actualización de Tivoli Directory Server
Si utiliza Tivoli Directory Server, puede actualizar la versión soportada más
reciente antes de iniciar la migración.
Antes de empezar
Copia de seguridad de Tivoli Directory Server. Para obtener más información,
consulte “Copia de seguridad del servidor LDAP” en la página 29.
Opcional. Se recomienda realizar la actualización de Tivoli Directory Server a la
versión soportada más reciente para Tivoli Provisioning Manager, pero no es
necesaria.
No se da soporte a la actualización del servidor LDAP para Microsoft Active
Directory.
Actualice Tivoli Directory Server a las siguientes versiones:
v
Windows
Versión 6.0.1 a versión 6.2
v
UNIX
Versión 6.0.1 a versión 6.1:
Consulte el centro de información de centro de información de Tivoli Directory Server
para obtener instrucciones de actualización detalladas: http://
publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDS.doc/
install07.htm#migrate
Qué hacer a continuación
“Configuración de Tivoli Directory Server para migración”
Configuración de Tivoli Directory Server para migración
Este paso sólo es necesario si tiene previsto utilizar su Tivoli Directory Server
existente en el entorno de suministro 7.1.1.
Antes de empezar
v Asegúrese de que ha extraído el archivo tpm5112migration.zip en la carpeta
TIO_HOME/migration del servidor de suministro 5.1.1.2.
v
30
UNIX
Asegúrese de que los scripts de la carpeta de migración tengan el
permiso ejecutable.
1. Inicie la sesión en el servidor de suministro como root.
2. En un shell de mandatos, vaya a la carpeta TIO_HOME/migration/scripts.
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
3. Ejecute los mandatos siguientes para asegurarse de que los scripts de la
carpeta de migración tienen el permiso ejecutable:
chmod 775 TIO_HOME/migration/scripts/FixLdapUserForWAS61.sh
chmod 664 TIO_HOME/migration/lib/com.ibm.tivoli.tpm.rt5112Migration.jar
4. Cambie al usuario tioadmin:
su - tioadmin
Ahora está preparado para completar los pasos de configuración de Tivoli
Directory Server.
WebSphere Application Server 6.1 se instala con Tivoli Provisioning Manager 7.1.1.
Los pasos de esta tarea configuran los usuarios de su Tivoli Directory Server
existente, de modo que sean compatibles con la versión del servidor de
aplicaciones más reciente.
Windows
Inicie la sesión en el servidor de suministro como tioadmin.
1.
2. En el servidor de suministro 5.1.1.2, vaya a TIO_HOME/migration/scripts/ y
ejecute el mandato siguiente:
v
FixLdapUserForWAS61.cmd -u <usuario_was> -o
<directorio_salida>
v
UNIX
FixLdapUserForWAS61.sh -u <usuario_was> -o
<directorio_salida>
Windows
donde
usuario_was es el nombre de usuario del administrador de WebSphere
Application Server.
directorio_salida es la ubicación donde se creará el archivo LDIF.
Al ejecutar este mandato se crea un archivo LDIF denominado
ModifyAttrForITDS.ldif.
3. Vaya a la ubicación <directorio-salida> y copie el archivo LDIF en el servidor de
directorios.
4. En el servidor de directorios, abra una ventana de mandatos y vaya a la
ubicación TDS_HOME\bin.
5. Ejecute el siguiente mandato desde dicha ubicación:
v
Windows
ldapmodify -D <DN_enlace> -w <contraseña> -i
<directorio_TDS>\ModifyAttrForITDS.ldif
v
UNIX
./ldapmodify.sh -D <DN_enlace> -w <contraseña> -i
<directorio_TDS>/ModifyAttrForITDS.ldif
donde
DN_enlace es el nombre de usuario distinguido del enlace LDAP, por
ejemplo, cn=root
contraseña es la contraseña de DN_enlace.
directorio_TDS es el directorio donde se encuentra el archivo LDIF en el
servidor de directorios.
Resultados
Los usuarios existentes están ahora configurados con los atributos necesarios, de
modo que son compatibles con WebSphere Application Server 6.1.
Capítulo 3. Tareas previas a la migración
31
Qué hacer a continuación
“Copia de seguridad de los paquetes de automatización personalizados” en la
página 34
Requisitos previos para la migración de paquetes de automatización
Hay cambios en los paquetes de automatización de 7.1.1. Antes de comenzar la
migración, haga una copia de seguridad de los paquetes de automatización,
asegúrese de que todos los paquetes de automatización instalados están en el nivel
de versión correcto y liste los paquetes de automatización 5.1.1.2 que utiliza en sus
operaciones de suministro.
Cambios en los paquetes de automatización para 7.1.1
Revise los cambios en los paquetes de automatización. Algunos paquetes de
automatización 5.1.1.2 se han eliminado y muchos se han migrado a la versión
7.1.1. También existen nuevos paquetes de automatización para 7.1.1.
Tabla 25. Paquetes de automatización que se migrarán desde 5.1.1.2 a 7.1.1
Paquetes de automatización migrados
AIX-Operating-System.tcdriver
Patch_Remediation_Tools.tcdriver
AIX_PATCH.tcdriver
pSeries-Server.tcdriver
AIX_WPAR_Virtual_Infrastructure
RedHat_EL_Update.tcdriver
apache.tcdriver
redhat-linux-operating-system.tcdriver
Apache-Web-Server-Windows.tcdriver
redline.tcdriver
CDS.tcdriver
remediation_antivirus.tcdriver
CiscoSwitchDiscovery.tcdriver
remediation_software_config
CitScannerAgent.tcdriver
remediation_windows.tcdriver
com.ibm.tivoli.tpm.compliance.remediation.tcdriver
RXA.tcdriver
Cygwin.tcdriver
sample-compliance-validation.tcdriver
db2.tcdriver
SCMCollectorAgent.tcdriver
DiscoveryWizards
sles-operating-system.tcdriver
eDMS_LWI.tcdriver
software_simulator.tcdriver
HP-UX.tcdriver
solaris-operating-system.tcdriver
HPUX_Ignite
SolarisZones_Virtual_Infrastructure
IBM-BladeCenter-Management.tcdriver
SPBHandler.tcdriver
IBM-Http-Server.tcdriver
Sun_Update_Connection.tcdriver
IBM-WebSphere-App-Server.tcdriver
Sun_Update_Connection_Enterprise.tcdriver
IBM-WebSphere-Edge.tcdriver
suse_patch.tcdriver
IBMTPC
SymantecAV.tcdriver
itds60.tcdriver
TADDMDiscovery.tcdriver
ITM6.1.tcdriver
TivoliCommonAgent.tcdriver
jes.client
TivoliCommonAgent-core.tcdriver
jumpstart.tcdriver
TMAInstall.tcdriver
kickstart.tcdriver
Tpmfosd
LocalFileRepository.tcdriver
TPMNetworkDiscovery.tcdriver
MSAD_Discovery.tcdriver
UNIX_File_Compliance.tcdriver
MS-Exchange-Server.tcdriver
VMware_Virtual_Infrastructure.tcdriver
MS-SQL2K.tcdriver
weblogic.tcdriver
MS_WSUS.tcdriver
WebsiteSample.tcdriver
NIM.tcdriver
windows-operating-system.tcdriver
oracle9i.tcdriver
yast.tcdriver
oracle10g.tcdriver
32
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 26. Los paquetes de automatización 5.1.1.2 están en desuso
Paquete de automatización
AIX_FIX
jds-task
CSM-Linux-Install
microsoft-patch
IBM-ESS
netview
IBM-RDM
nuke
IBM-WebSphere-Edge
PeopleSoftTools
ITM LPAR-cpu
rdp-altiris
MS-Exch2K
siebel
MSADS
site-td-qalab
MS_SOA_PATCH
Tuxedo
newview
xen
Provider1
IBM-JRE
RXA-Windows
eclipse
TCMCoexistence
apde-plugin
TCA_EndPoint_Migration_51
apde
application-service
CHAMPS
application-topologies
jes-subagent
cisco-discovery
networking-advanced
core_reports
PlantsByWebSphere
cvsserver
Tomcat-Windows
discovery-library
IBM-TIO-TPM-InstallHelper
discovery-simulation
DSMUtils
domino
MS_VirtualServer
emc-symmetrix
DataSynapse_GridServer
forum
TADDMDiscovery_rest
group-stats-populator
MS_MBSA
itcm
Sun_Update_Connection_Enterprise
itds
MS_PATCH_OFFLINE_FOR_SDI_5_1
jds
TCAupgradeSPB
Nota: Los registros de los paquetes de automatización en desuso estarán en la base
de datos de suministro 7.1.1 pero es posible que no funcionen. Algunos de los
paquetes de automatización están disponibles para su descarga desde OPAL (Open
Process Automation Library): http://www-01.ibm.com/software/tivoli/features/
opal/. Después de la migración, hay pasos detallados para descargarlos e
instalarlos en el servidor de suministro 7.1.1.
Tabla 27. Paquetes de automatización que son nuevos en la versión 7.1.1
Paquete de automatización
AIX_WPAR_Virtual_Infrastructure
Patch__Tools
DiscoveryWizards
Sun_Update_Connection_Enterprise MS_PATCH_OFFLINE_FOR_SDI
TCAupgradeSPB
YUM
jes.client
cPM711Migration
Com.ibm.tivoli.osgi.service.jes.impl
SDI
com.ibm.tivoli.osgi.service.event
emc-symmetrix
com.ibm.tivoli.tpm.osgi.service.TpmSubagent
forum
com.ibm.tivoli.agentext.tpmagentext
group-stats-populator
com.ibm.osg.service.osgiagent
itcm
tpm.management.agent.feature
itds
remediation_software_config
jds
SolarisZones_Virtual_Infrastructure
jds-task
tpmfosd
microsoft-patch
Capítulo 3. Tareas previas a la migración
33
Tabla 27. Paquetes de automatización que son nuevos en la versión 7.1.1 (continuación)
Paquete de automatización
com.ibm.tivoli.cds.depot.cas.CdsDepot
PeopleSoftTools
HPUX_Ignite
rdp-altiris
IBMTPC
Copia de seguridad de los paquetes de automatización
personalizados
Los paquetes de automatización personalizados se migrarán a 7.1.1. pero es posible
que no funcionen. Cree una copia de seguridad de los paquetes de automatización
de modo que pueda restaurarlos en el sistema 7.1.1 después de la migración.
Antes de empezar
1. Haga una lista de todos los paquetes de automatización que ha creado y
utilizado en su entorno de suministro.
2. Asegúrese de que todos los paquetes de automatización personalizados tengan
un nombre exclusivo. No pueden tener el mismo nombre que un paquete de
automatización de suministro predefinido. Por ejemplo, si ha personalizado un
paquete de automatización predefinido pero lo ha guardado con su nombre
original, se producirá un conflicto durante la migración y se generará un error.
El proceso de migración mantendrá el registro de base de datos de los paquetes de
automatización y los flujos de trabajo de suministro pero es posible que no
funcionen en la versión 7.1.1. Después de la migración, deberá configurar
Automation Package Developer Environment y volver a compilar los paquetes de
automatización en la versión 7.1.1.
Nota: Sólo se da soporte a Automation Package Developer Environment en
entornos Windows y Linux de 32 bits. En 7.1.1, para los entornos Windows y
Linux, el servidor de suministro sólo se puede migrar a los sistemas operativos de
64 bit, por lo tanto, se debe instalar Automation Package Developer Environment
en un sistema remoto.
Antes de iniciar la migración, cree una copia de seguridad de los paquetes de
automatización personalizados:
1. Inicie la sesión en el servidor de suministro 5.1.1.2.
2. Vaya a TIO_HOME/drivers
3. Copie los paquetes de automatización personalizados en una ubicación que no
esté en el servidor de suministro 5.1.1.2. Debe ser una ubicación diferente ya
que después de realizar la copia de seguridad completa del servidor de
suministro 5.1.1.2, el servidor de suministro se concluirá y no se podrá utilizar
después de la migración. Copie los paquetes de automatización en una
ubicación a la que se pueda acceder después de la migración a la versión 7.1.1.
Resultados
Se ha realizado una copia de seguridad de los paquetes de automatización que ha
creado. Después de la migración, añádalos a su entorno 7.1.1.
Qué hacer a continuación
“Paquetes de automatización 5.1.1.2” en la página 35
34
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Paquetes de automatización 5.1.1.2
Revise la lista de los paquetes de automatización que utiliza en el entorno de
suministro 5.1.1.2.
Repase detenidamente la lista de los Tabla 26 en la página 33, y tome nota de los
que ha utilizado en sus operaciones de suministro. Estos paquetes de
automatización de la versión 5.1.1.2 están en desuso en la versión 7.1.1, pero
algunos están disponibles en el sitio web de OPAL (Open Process Automation
Library): http://www-01.ibm.com/software/tivoli/features/opal/.
Cuando se haya completado la migración, puede descargar los paquetes de
automatización 5.1.1.2 desde OPAL y restaurar sus paquetes de automatización
personalizados 5.1.1.2. Se recomienda desinstalar los paquetes de automatización
en desuso que no utilice en sus operaciones de suministro. Al desinstalar los
paquetes de automatización se eliminará su registro de la base de datos de
suministro.
Qué hacer a continuación
“Verificación de la versión del paquete de automatización”
Verificación de la versión del paquete de automatización
Los paquetes de automatización que se instalan en el servidor de suministro no
puede tener una versión superior a la versión 7.1.1.0. Antes de comenzar la
migración, compruebe la versión de los paquetes de automatización instalados y
elimine cualquier paquete cuya versión sea superior.
1. En el servidor de suministro, abra un indicador de mandatos y ejecute el
mandato siguiente:
v
Windows
v
UNIX
TIO_HOME\tools\tc-driver-manager.cmd l
TIO_HOME/tools/tc-driver-manager.sh l
La herramienta muestra el número de versión y el estatus de instalación
(instalado o no instalado) de todos los paquetes de automatización.
2. Compruebe si cualquiera de los paquetes de automatización tienen una versión
posterior a la versión 7.1.1.0.
3. Si los paquetes de automatización pertenecientes a Tivoli Provisioning Manager
tienen una versión superior a la versión 7.1.1.0, desinstálelos y limpie todos los
objetos de modelos de datos creados por la instalación de paquetes de
automatización.
Qué hacer a continuación
Asegúrese de que no surgen conflictos de nombres con los paquetes de
auomatización.
Eliminación de los paquetes de automatización duplicados
Para evitar errores durante la migración, asegúrese de que sus paquetes de
automatización personalizados no tienen el mismo nombre que los paquetes de
automatización predefinidos.
Qué hacer a continuación
“Exportación de la consulta de informe 5.1.1.2” en la página 36
Capítulo 3. Tareas previas a la migración
35
Exportación de la consulta de informe 5.1.1.2
Antes de migrar los datos de la versión 5.1.1.2 al servidor de suministro 7.1.1,
exporte la consulta de informe 5.1.1.2.
Antes de empezar
Asegúrese de que el servidor de bases de datos se esté ejecutando. Debe conectarse
a la base de datos para ejecutar la consulta.
Utilice una consulta SQL para exportar la consulta de informe. La consulta
personalizada en la salida se utilizará para migrar los informes personalizados
utilizando el entorno de desarrollo BIRT en la versión 7.1.1.
1. Inicie la sesión en el servidor de suministro 5.1.1.2.
2. Coloque el mandato SQL siguiente en un script.
SELECT DCM_OBJECT.NAME REPORT_NAME,
CASE
WHEN QUERY.EDITED_QUERY is not null then QUERY.EDITED_QUERY
ELSE QUERY.QUERY_STRING
END QUERY
FROM QUERY , DCM_OBJECT, REPORT41
WHERE QUERY.QUERY_ID=REPORT41.QUERY_ID and DCM_OBJECT.ID = REPORT41.REPORT_ID
Por ejemplo, coloque la consulta SQL en un script denominado
exportReportQuery.sql.
3. Ejecute el script para exportar la consulta de informe. Por ejemplo, ejecute el
mandato siguiente para el script exportReportQuery.sql:
db2 -tvf exportReportQuery.sql > reportQuery.txt
4. Guarde reportQuery.txt en una ubicación a la que se pueda acceder después
de la migración 7.1.1.
Resultados
La consulta de informe se ha guardado y se podrá utilizar después de la migración
para crear informes personalizados utilizando BIRT Report Designer.
Nota: Se cambiará el nombre de la tabla de consulta Tivoli Provisioning Manager
a query5112 durante la migración. Todo el contenido de la tabla de consultas se
retendrá. Necesitará el nombre de la tabla de consultas para utilizar la consulta
para crear informes nuevos después de la migración a 7.1.1.
Qué hacer a continuación
“Migración de repositorios de archivos”
Migración de repositorios de archivos
Los archivos binarios de software que se encuentran en los repositorios de archivos
locales de la versión 5.1.1.2 no se migrarán a la versión 7.1.1 debido a que la
ubicación del repositorio de archivos puede cambiar. Haga una copia de seguridad
manual de los archivos binarios de software y anote los directorios de los
repositorios de archivos, de modo que pueda volver a crearlos en el servidor de
suministro 7.1.1. después de la migración.
36
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Antes de empezar
Asegúrese de que todos los archivos que desea utilizar después de la migración se
encuentren en un repositorio de archivos. Los archivos que están en los
repositorios de archivos se migrarán. Los archivos que se encuentren fuera de los
repositorios de archivos no se migrarán. Por ejemplo, los archivos que se publican
en los servidores de almacén y que no están en un repositorio de archivos no se
migrarán.
Complete los pasos siguientes en el servidor de suministro 5.1.1.2 para realizar la
copia de seguridad en los repositorios de archivos:
1. Vaya a Inventario → Gestión de infraestructura → Repositorios de archivos.
2. Para cualquier repositorio de archivos local que haya creado, anote la ubicación
del directorio especificada en la columna Vía de acceso raíz.
3. Haga una copia de seguridad de los archivos binarios situados en cada uno de
los repositorios de archivos y guárdela en una ubicación que no esté en el
servidor de suministro de la versión 5.1.1.2. El servidor de suministro concluirá
después de realizar una copia de seguridad completa de los datos, de modo
que los archivos binarios se deben guardar en una ubicación donde pueda
accederse a los mismos después de la migración.
Resultados
Después de la migración, puede volver a crear estos repositorios de archivos y
restaurar los archivos binarios de software.
Qué hacer a continuación
“Migración de las imágenes creadas utilizando Tivoli Provisioning Manager for OS
Deployment Embedded Edition”
Migración de las imágenes creadas utilizando Tivoli Provisioning
Manager for OS Deployment Embedded Edition
No existe una migración para las imágenes creadas con Tivoli Provisioning
Manager for OS Deployment Embedded Edition 5.1.1.2. Las imágenes de la versión
5.1.1.2 tienen un formato diferente a las imágenes creadas con Tivoli Provisioning
Manager for OS Deployment, el producto integrado en Tivoli Provisioning
Manager 7.1.1.
Hay dos modos para volver a crear las imágenes de la versión 5.1.1.2. Puede
utilizar una de las siguientes opciones:
1. Volver a crear las imágenes en el entorno de suministro 7.1.1. después de la
migración.
2. Utilizar un entorno de prueba 7.1.1 para volver a capturar las imágenes
contenidas en el entorno de suministro 5.1.1.2.
Este método requiere la siguiente secuencia de pasos:
a. Despliegue de un servidor de desarrollo 7.1.1.
b. Despliegue de las imágenes de Tivoli Provisioning Manager for OS
Deployment Embedded Edition 5.1.1.2 en los sistemas de destino.
c. Utilización del servidor de desarrollo de 7.1.1 para capturar las nuevas
imágenes de los sistemas de destino.
Capítulo 3. Tareas previas a la migración
37
d. Una vez completada la migración completa de los datos del servidor de
producción 7.1.1, ejecute un flujo de trabajo de suministro en el servidor de
suministro 7.1.1 para clonar las imágenes del entorno de prueba y moverlas
al entorno de producción (migrado).
Nota: Antes de iniciar la migración a la versión 7.1.1, se debe utilizar un
entorno de prueba para capturar las imágenes de la versión 5.1.1.2. Una vez
realizada una copia de seguridad del servidor de suministro 5.1.1.2 e iniciar la
migración, no se puede volver a utilizar el servidor de suministro 5.1.1.1 y las
imágenes ya no estarán disponibles.
Antes de empezar
v Instale Tivoli Provisioning Manager versión 7.1.1 en un servidor de desarrollo.
Siga los pasos de la sección “Instalación de Tivoli Provisioning Manager 7.1.1
para la migración” en la página 40.
v Asegúrese de que la contraseña que utiliza para iniciar la sesión en la interfaz
web de Tivoli Provisioning Manager for OS Deployment es la misma para el
sistema de desarrollo 7.1.1 y para el sistema de producción 7.1.1 en el que está
clonando las imágenes. Cuando instale Tivoli Provisioning Manager 7.1.1 en los
sistemas de desarrollo y producción, utilice la misma contraseña para el usuario
maxadmin, de modo que las contraseñas coincidan. Si las contraseñas no
coinciden, el flujo de trabajo de suministro que ejecutará después de la
migración no se ejecutará correctamente.
Siga estos pasos para desplegar las imágenes de la versión 5.1.1.2 en los sistemas
de destino y capturar a continuación las imágenes nuevas en el entorno de prueba
7.1.1.
1. Instale las imágenes que ha creado con la versión 5.1.1.2 en los sistemas de
destino. Siga las indicaciones de la documentación de la versión 5.1.1.2 para
Instalar una imagen del sistema operativo en el Centro de información de Tivoli
Provisioning Manager 5.1.1.
2. Con el servidor de suministro 7.1.1, capture una imagen de cada sistema de
destino donde acaba de desplegar las imágenes del paso 1. Para realizar esta
tarea, siga la documentación para Crear una imagen del Centro de información de
Tivoli Provisioning Manager 7.1.1.
Resultados
Una vez completado el proceso de migración en su entorno de producción,
ejecutará el flujo de trabajo de suministro denominado TPMfOSd_CloneRemoteServer
para clonar las imágenes que acaba de capturar en el entorno de prueba y
moverlas al entorno de producción.
Qué hacer a continuación
“Eliminación de apodos y vistas” en la página 39 Para Tivoli Provisioning Manager
o Tivoli Provisioning Manager for Software configurados con la existencia de Tivoli
Configuration Manager.
“Instalación de Tivoli Provisioning Manager 7.1.1 para la migración” en la página
40
38
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Eliminación de apodos y vistas
No se da soporte a la migración por motivos coexistencia con la pasarela Tivoli
Configuration Manager que está configurada e integrada con Tivoli Provisioning
Manager o Tivoli Provisioning Manager for Software. Para poder realizar la
migración a la versión 7.1.1, todas las pasarelas y puntos finales de Tivoli
Monitoring Framework se deben actualizar al punto final SDI (Scalable
Distribution Infrastructure) y se deben eliminar los apodos y las vistas creados por
la coexistencia con Tivoli Configuration Manager.
Antes de empezar
Esta tarea sólo es necesaria si está utilizando DB2.
Si no necesita migrar sus puntos finales Tivoli Monitoring Framework, no es
necesario que los actualice al punto final SDI. Para obtener más información acerca
de cómo migrar Tivoli Monitoring Framework, consulte el siguiente documento en
el centro de información de Tivoli Provisioning Manager versión 5.1.1: Despliegue
de infraestructuras y arquitecturas de infraestructuras.
Realice una copia de seguridad de la base de datos 5.1.1.2, de modo que pueda
retrotraerla si es necesario. Utilice sus propias herramientas de copia de seguridad
para realizar una copia de seguridad completa del sistema o consulte:
https://www.ibm.com/developerworks/wikis/display/
tivoliprovisioningmanager/Backing+up+the+database+and+important+data
La coexistencia con Tivoli Configuration Manager ha creado los apodos y las vistas
que se deben eliminar antes de iniciar la migración a la versión 7.1.1.
Para eliminar los apodos y vistas predefinidos, complete el paso 1. Si ha creado
apodos o vistas personalizados, complete también los pasos 2 a 7 para buscar y
eliminar estos objetos.
1. Vaya a TIO_HOME/migration/scripts y ejecute el mandato siguiente:
v
Windows
dropTCMview.cmd
UNIX
dropTCMview.sh
v
Los apodos y vistas predefinidos se habrán eliminado. Si tiene vistas y apodos
personalizados, continúe y complete los pasos 2 a 7.
2. Conéctese a la base de datos. Abra una ventana de mandatos de DB2 y ejecute
el mandato siguiente:
connect to tc user nombreusuariobd using contraseña
donde
nombreusuariobd es el nombre de usuario de base de datos utilizado para la
conexión y definido en el archivo TIO_HOME/config/dcm.xml.
contraseña es la contraseña del usuario de base de datos.
3. Ejecute la siguiente sentencia SQL para comprobar si tiene apodos definidos
por el usuario en su entorno 5.1.1.2:
select tabname from syscat.nicknames;
4. Si al ejecutar la sentencia SQL se devuelven apodos, ejecute esta consulta para
ver qué vistas dependen de qué apodos:
select VIEWNAME, BNAME from SYSCAT.VIEWDEP where BTYPE = 'N';
Capítulo 3. Tareas previas a la migración
39
5. Revise las vistas y los apodos. Se deben desconectar antes de ejecutar el script
tpm5112backup para realizar la copia de seguridad de la base de datos y migrar
los datos de la versión 5.1.1.2. Si continúan siendo necesarios, decida cómo
migrarlos después de que se haya completado la migración a la versión 7.1.1.
6. Ejecute las consultas siguientes para poder generar la sentencia y desconectar
las vistas y apodos.
a. select distinct 'drop view ' || VIEWNAME || ';' from SYSCAT.VIEWDEP
where BTYPE = 'N';
b. select 'drop nickname ' || BNAME || ';' from SYSCAT.VIEWDEP where
BTYPE = 'N';
7. Ejecute las sentencias generadas para desconectar las vistas y apodos.
Resultados
Las vistas y apodos se han eliminado ahora del servidor de suministro 5.1.1.2.
Qué hacer a continuación
“Instalación de Tivoli Provisioning Manager 7.1.1 para la migración”
Instalación de Tivoli Provisioning Manager 7.1.1 para la migración
Instale Tivoli Provisioning Manager 7.1.1 en un sistema nuevo, de modo que esté
preparado en el momento en que se realice la copia de seguridad de los datos de
la versión 5.1.1.2.
Para migrar su servidor de suministro de la versión 5.1.1.2 a 7.1.1, instale el 7.1.1
en un sistema nuevo. Complete las tareas para instalar y configurar el sistema
nuevo para 7.1.1
Importante: Siga la secuencia de instalación describa en la Guía de migración para
instalar la versión 7.1.1. No siga el proceso de instalación descrito en la Guía de
instalación. La secuencia de instalación es diferente para los dos escenarios. Por
ejemplo, cuando instale los componentes principales, no instale los Common Agent
Services, Dynamic Content Delivery o el servicio de gestor de dispositivos. Estos
componentes se instalan durante la migración. Asimismo, existen pasos de
migración que ha de realizar antes de instalar los servicios básicos y los
componentes web. Siga la documentación de migración como guía para el proceso
de instalación.
Durante esta fase de la instalación, únicamente instale lo siguiente:
1. Instale o reutilice el middleware
El servidor de bases de datos, el servidor de directorios y el servidor de
aplicaciones deben instalarse primero. Puede utilizar el middleware soportado
existente que ya tiene instalado o puede utilizar el instalador de middleware
para instalar el middleware.
v Para obtener información sobre la utilización del middleware existente,
consulte el apartado Reutilización del middleware utilizando el instalador de
middleware.
Nota: Sólo se puede reutilizar un servidor de bases de datos remoto o un
servidor LDAP remoto en la versión 7.1.1.
40
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v Para realizar una nueva instalación del middleware, consulte el apartado
“Instalación del middleware con el instalador de middleware” en la página
83.
2. Instale los componentes principales de Tivoli Provisioning Manager.
Los componentes principales deben instalarse en el sistema donde ha instalado
WebSphere Application Server durante el paso de instalación de middleware.
Nota: No instale los siguientes componentes:
v Common Agent Services
v Dynamic Content Delivery
v Servicio del gestor de dispositivos
Estos componentes se instalan durante la migración de los datos.
Verificación de los requisitos de los componentes
Verifique los requisitos de los componentes antes de realizar la instalación a Tivoli
Provisioning Manager 7.1.1.
Las tablas siguientes muestran los sistemas operativos soportados y las
combinaciones de middleware. El software de Tivoli Provisioning Manager se
instala en el mismo sistema que el servidor de aplicaciones. Si está utilizando una
topología de varios servidores, asegúrese de que comprueba los requisitos de los
componentes en cada sistema de la topología.
Nota: Se requiere Cygwin 1.5.10 o superior en el servidor de suministro. Cygwin puede instalarse automáticamente
durante la instalación o puede instalarlo previamente de forma manual.
Base de datos
Sistema operativo y plataforma
DB2 9.5 FP3a
Oracle
Database
Servidor de
aplicaciones
IBM
WebSphere
Application
Server
Network
Deployment
6.1.0.23
Servidor de directorios
Tivoli
Directory
Server 6.1.0.10
o 6.2.0.2
Windows Server 2008 Enterprise Edition SP1
(x86 de 64 bits)
Sólo 6.2.0.2
Windows Server 2008 Standard Edition SP1
(x86 de 64 bits)
Sólo 6.2.0.2
Windows Server 2003 R2 Enterprise Edition
SP2 (x86 de 64 bits)
Sólo 6.2.0.2
Microsoft
Active
Directory 2003
SP2
Estación de
trabajo
administrativa
Windows Server 2003 Standard Edition SP2
(x86 de 64 bits)
Windows Server 2003 Enterprise Edition SP2
(x86 de 64 bits)
Windows Server 2003 Standard Edition SP2
(x86 de 32 bits)
Windows Server 2003 Enterprise Edition SP2
(x86 de 32 bits)
Capítulo 3. Tareas previas a la migración
41
Nota: No se da soporte a Oracle Real Application Clusters (RAC).
Base de datos
Sistema operativo y plataforma
DB2 9.5 FP3a
Oracle
Database
10.2.0.4g o 11g
R1
Servidor de
aplicaciones
IBM
WebSphere
Application
Server
Network
Deployment
6.1.0.23
Servidor de directorios
Tivoli
Directory
Server 6.2.0.2
Microsoft
Active
Directory 2003
SP2
Estación de
trabajo
administrativa
Red Hat Enterprise Linux 5 Update 1 o
Update 3 (x86 de 64 bits)
Utilice un
sistema
Windows
separado
Red Hat Enterprise Linux 5 Update 1 o
Update 3 (IBM System z de 64 bits)
Utilice un
sistema
Windows
separado
Red Hat Enterprise Linux 4 AS Update 5 (x86
de 64 bits)
Sólo
10.2.0.4g
SUSE Linux Enterprise Server 10 SP2 (x86 de
64 bits)
Sólo
10.2.0.4g
Utilice un
sistema
Windows
separado
SUSE Linux Enterprise Server 10 SP1 y SP2
(IBM System z de 64 bits)
Utilice un
sistema
Windows
separado
Nota: No se da soporte a Oracle Real Application Clusters (RAC).
Base de datos
Sistema operativo y plataforma
DB2 9.5 FP3a
Oracle
Database
10.2.0.4g o 11g
R1
Servidor de
aplicaciones
IBM
WebSphere
Application
Server
Network
Deployment
6.1.0.23
AIX 6.1 TL2 SP2 (IBM System p de 64 bits)
Servidor de directorios
Tivoli
Directory
Server 6.1.0.10
o 6.2.0.2
Microsoft
Active
Directory 2003
SP2
Estación de
trabajo
administrativa
Sólo 6.2.0.2
AIX 5.3 TL8 SP2 (IBM System p de 64 bits)
Sólo
10.2.0.4g
Utilice un
sistema AIX
6.1 o Windows
separado
Nota: No se da soporte a Oracle Real Application Clusters (RAC).
Base de datos
Sistema operativo y plataforma
DB2 9.5 FP3a
Oracle
Database
10.2.0.4g o 11g
R1
Servidor de
aplicaciones
IBM
WebSphere
Application
Server
Network
Deployment
6.1.0.23
Servidor de directorios
Tivoli
Directory
Server 6.2.0.2
Microsoft
Active
Directory 2003
SP2
Solaris 10 (SPARC)
Estación de
trabajo
administrativa
Utilice un
sistema
Windows
separado
Tareas previas a la instalación del sistema operativo
Antes de realizar la instalación, efectúe estas tareas en función de su sistema
operativo.
42
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Windows
Tareas previas a la instalación en Windows
Tarea previa a la
instalación
Pasos
Compruebe que el
formato de archivo 8.3
esté habilitado
Abra una ventana de indicador de mandatos y ejecute fsutil behavior query disable8dot3. Si la
salida es disable8dot3 = 0, el formato de archivo 8.3 está habilitado. De lo contrario, ejecute fsutil
behavior set disable8dot3 0
Compruebe los requisitos En el Panel de control, abra el panel Servicio y compruebe los servicios siguientes:
de los servicios Windows v Cliente DNS: Inhabilite este servicio para que los nombres de host no se guarden en la memoria
caché y estén siempre resueltos por un servidor DNS con direcciones IP actuales.
v Windows Management Instrumentation: Asegúrese de que se ha iniciado este servicio.
v Registro remoto: Asegúrese de que este servicio esté habilitado.
Compruebe los valores
del servidor de terminal
Para ver si se ha instalado Terminal Server, en el Panel de control, abra el panel Agregar o quitar
programas y compruebe la lista de los programas instalados actualmente. Si el servidor de terminal
está instalado, configure el servidor de terminal en modalidad de instalación abriendo un indicador de
mandatos y ejecutando change user /install
Seleccione Windows
Scripting Host
De forma predeterminada, Windows Scripting Host está instalado en Windows 2003 y Windows 2008.
Para comprobar si Windows Scripting Host está habilitado:
1. En Windows Explorer, abra Herramientas → Opciones de carpeta.
2. Haga clic en el separador Tipos de archivos y compruebe que el archivo de script VBScript se lista
como un tipo de archivo registrado.
Compruebe que se haya
habilitado NetBIOS.
NetBIOS debe estar habilitado porque el sistema Tivoli Provisioning Manager tiene una dirección IP
estática. Para verificar que NetBIOS está habilitado:
1. En el Panel de control, abra el panel Conexiones de red.
2. Haga clic con el botón derecho del ratón en la conexión de área local y, a continuación, haga clic en
Propiedades.
3. En la lista, seleccione Protocolo de Internet (TCP/IP) y, a continuación, haga clic en Propiedades.
4. Haga clic en Avanzado y luego haga clic en el separador WINS.
5. En el valor NetBIOS, seleccione Predeterminado y haga clic en Aceptar hasta que se cierren todos
los recuadros de diálogo.
AIX
Tareas previas a la instalación en AIX
Tarea previa a la
instalación
Pasos
Verifique que el sistema
esté ejecutándose en
modalidad de kernel de
64 bits
Ejecute el mandato prtconf -k
Inhabilite el daemon
automount de AIX
Si actualmente se está ejecutando, detenga el daemon y vuelva a arrancar el sistema con el daemon
inhabilitado.
Capítulo 3. Tareas previas a la migración
43
Tarea previa a la
instalación
Aumente el espacio de
paginación
predeterminado en al
menos 4 GB.
Pasos
Como mínimo, establezca el espacio de paginación en la cantidad total de memoria física del sistema, o
preferiblemente duplique el tamaño de la memoria física.
Para determinar la cantidad actual del espacio de paginación disponible en el servidor, ejecute el
siguiente mandato:
lsps -a
Este mandato produce una salida parecida a la siguiente:T
Page Space
hd6
Physical Volume
hdisk0
Volume Group
rootvg
Size
5632MB
%Used
2
Para determinar el tamaño de una partición lógica, ejecute el siguiente mandato:
lslv hd6
Este mandato producirá una salida que incluirá información sobre la partición parecida a la siguiente:
LPs:
PP SIZE:
44
128 megabyte(s)
En la salida de ejemplo, hay un total de 44 particiones lógicas, cada una de las cuales tiene un tamaño
de 128 MB. Este resultado muestra un total de 5.632 MB de espacio de paginación disponible en el
sistema.
Para agregar más espacio de paginación, debe agregar más particiones lógicas al sistema.
Para agregar más particiones lógicas, utilice el siguiente mandato:
chps -s xx yyy
donde xx es el número de particiones lógicas que agregar y yyy identifica el volumen lógico.
Por ejemplo,
chps -s 10 hd6
agrega 10 particiones lógicas al volumen lógico hd6, dando como resultado una adición de 1.280 Mb al
espacio de paginación.
Establezca el número
máximo de procesos por
usuario en 2048 como
mínimo.
Este valor es necesario para el inicio del servidor de suministro.
1. Ejecute el siguiente mandato.
smit chgsys
2. Asegúrese de que el valor correspondiente a Número máximo de PROCESOS sea como mínimo
2048.
44
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea previa a la
instalación
Habilite los tamaños de
archivos grandes en el
sistema de archivos
Pasos
Si el sistema de archivos /home es JFS, asegúrese de que Archivo grande habilitado sea true o
reconstruya el sistema de archivos /home en JFS2 (JFS mejorado). En AIX 6.1, el sistema de archivos
JFS2 es el sistema de archivos predeterminado. Para comprobar el tipo de sistema de archivos y
habilitar tamaños de archivos grandes para un sistema de archivos JFS:
1. Ejecute el mandato mount para comprobar el tipo de sistema de archivos. Los resultados del
mandato muestran el tipo de sistema de archivos de todos los sistemas de archivos montados. En el
ejemplo siguiente, el sistema de archivos /home es JFS2:
/dev/fslv00
/home
jfs2
Sep 17 10:45 rw,log=/dev/loglv00
2. Ejecute el siguiente mandato para comprobar el valor de tamaño de archivo grande:
smit chfs
Seleccione Cambiar/Mostrar características de un sistema de archivos de diario y, a continuación,
seleccione /home en la lista.
3. Compruebe que Archivo grande habilitado esté establecido en true. Si está establecido en false,
siga estos pasos:
a. Haga una copia de seguridad de los datos de /home.
b. Desmonte y elimine el sistema de archivos /home utilizando el mandato smit storage. Siga los
menús correctos.
c. Cree un nuevo sistema de archivos /home como JFS2 con el mandato:
smit crfs
d. Seleccione Agregar un sistema de archivos de diario mejorado.
e. Vuelva a montar /home con el mandato smit storage.
f. Restaure los datos de la copia de seguridad de /home.
Establezca los límites de
usuario
1. Inicie la sesión como root.
2. Compruebe el archivo /etc/security/limits. Elimine o comente los valores predeterminados. Si los
límites correspondientes a root o ctginst1 no están actualmente establecidos en unlimited, cambie
los límites configurados en el archivo del siguiente modo:
ctginst1:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
root:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
nofiles = 8192
Nota: Asegúrese de que no hayan líneas vacías entre los nombres de usuario y los límites de
usuario.
3. Cierre la sesión como root y vuelva a iniciarla para que los cambios surtan efecto.
4. Si DB2 ya está instalado, reinicie la instancia de base de datos.
5. Compruebe los valores desde una ventana de mandatos ejecutando ulimit -a.
Establezca el tamaño de
intercambio
Dado que Tivoli Provisioning Manager es una aplicación que puede ocupar muchos recursos, se le
recomienda que configure y ajuste el sistema para máximo rendimiento, incluido el valor de tamaño
espacio de intercambio que se utiliza en el sistema. Normalmente, el tamaño de intercambio
establecido debe ser equivalente al doble de la cantidad de RAM física del sistema. Puede crear espacio
de intercambio adicional disponible de este modo:
v Aumentando el tamaño de la partición de intercambio existente
v Creando una nueva partición de intercambio adicional
v Creando un archivo de intercambio
Para obtener más información, consulte la documentación del sistema operativo.
Compruebe los requisitos El indicador de mandatos debe terminar por $, # o >.
del indicador de
mandatos
Capítulo 3. Tareas previas a la migración
45
Tarea previa a la
instalación
Pasos
Establezca la variable de
entorno si está utilizando
Compiz
Ejecute el mandato de exportación AWT_TOOLKIT=MToolkit
Permisos de /tmp
Establezca los permisos de /tmp en 1777.
Linux
Tareas previas a la instalación en Linux
Tarea previa a la
instalación
Pasos
Verifique que la versión
del kernel sea 2.6
Ejecute el mandato uname -r
Para Red Hat Linux 5, o
para otros sistemas
operativos con SELinux
habilitado, establezca
SELinux en permissive o
disabled.
Efectúe una de las siguientes tareas:
Inhabilite la limpieza
automática del directorio
/tmp.
Establezca el tamaño de
intercambio
v Inhabilite temporalmente SELinux ejecutando setenforce 0. Una vez completada la instalación,
vuelva a habilitar SELinux ejecutando setenforce 1
v Ejecute chcon -R -t textrel_shlib_t <dir_instalación/jvm/jre>
v Edite el archivo /etc/selinux/config y establezca SELINUX en permissive o disabled. No obstante,
esta solución afecta al nivel de seguridad de todo el sistema.
De manera predeterminada, el programa de utilidad tmpwatch se ejecuta diariamente y elimina
archivos de /tmp a los que no se haya accedido en 10 días. El planificador anacron también ejecuta
scripts de etc/cron.daily cuando se arranca el sistema. Dado que el programa de instalación se instala
bajo /tmp, debe inhabilitar la limpieza automática de /tmp:
1. Compruebe /etc/crontab y /etc/anacrontab para ver qué scripts de /etc/cron.daily se llaman.
2. Si se llama a los scripts de /etc/cron.daily, cambie el nombre de los scripts siguientes:
v
/etc/cron.daily/tmpwatch
v
/etc/cron.daily/suse.de-clean-tmp
Dado que Tivoli Provisioning Manager es una aplicación que puede ocupar muchos recursos, se le
recomienda que configure y ajuste el sistema para máximo rendimiento, incluido el valor de tamaño
espacio de intercambio que se utiliza en el sistema. Normalmente, el tamaño de intercambio
establecido debe ser equivalente al doble de la cantidad de RAM física del sistema. Puede crear espacio
de intercambio adicional disponible de este modo:
v Aumentando el tamaño de la partición de intercambio existente
v Creando una nueva partición de intercambio adicional
v Creando un archivo de intercambio
Para obtener más información, consulte la documentación del sistema operativo.
Establezca los parámetros Establezca los parámetros de kernel necesarios en /etc/sysctl.conf:
de kernel para DB2
kernel.core_uses_pid=1
kernel.sem=250 256000 32 1024
kernel.shmmax=2147483648
kernel.shmall=3828665548 *
kernel.msgmax=65535
kernel.msgmnb=65535
* 90% de la RAM total. Por ejemplo, el 90% de 4 GB es 3828665548
Después de establecer los parámetros de kernel, ejecute el mandato /sbin/sysctl -p para que la nueva
configuración surta efecto.
46
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tarea previa a la
instalación
Establezca los límites de
usuario
Pasos
1. Inicie la sesión como root.
2. Compruebe el archivo /etc/security/limits.conf. Si no se ha configurado específicamente un
límite para un usuario, se utilizará el valor predeterminado. El valor predeterminado suele ser
unlimited para todos los límites necesarios salvo para el tamaño de pila.
v Elimine cualquier entrada existente para ctginst1 de modo que se asignen los límites
predeterminados. Asegúrese de que los límites predeterminados estén establecidos en unlimited.
v Para cambiar el tamaño de pila por el valor máximo para ctginst1 y root, agregue las entradas
siguientes al archivo:
ctginst1 - stack unlimited
root - stack unlimited
v Establezca el límite de los descriptores de archivos abiertos en 8192 o más para el usuario root y
agregue la entrada siguiente al archivo:
root - nofiles 8192
3. Cierre la sesión como root y vuelva a iniciarla para que los cambios surtan efecto.
4. Si DB2 ya está instalado, reinicie la instancia de base de datos.
5. Compruebe los valores desde una ventana de mandatos ejecutando ulimit -a.
Compruebe los requisitos El indicador de mandatos debe terminar por $, # o >.
del indicador de
mandatos
Establezca la variable de
entorno si está utilizando
Compiz
Para comprobar si se ha instalado Compiz, ejecute rpm -qa | grep Compiz. Si está instalado, establezca
la variable de entorno ejecutando export AWT_TOOLKIT=MToolkit
Permisos de /tmp
Establezca los permisos de /tmp en 1777.
Tareas previas a la instalación en Solaris
Tarea previa a la
instalación
Pasos
Verifique el shell de
inicio de sesión del
usuario root
El shell de inicio de sesión del usuario root debe estar establecido en /bin/bash
Verifique las variables
Abra el archivo /etc/default/login y verifique que:
v La variable CONSOLE está comentada.
v Las variables PATH y SUPATH existen.
Establezca la variable de
entorno si está utilizando
Compiz
Ejecute el mandato de exportación AWT_TOOLKIT=MToolkit
Permisos de /tmp
Establezca los permisos de /tmp en 1777.
Cree el directorio
/export/home/maximo
Ejecute el mandato mkdir -p /export/home/maximo
Cambie el propietario del Para la cuenta de usuario maximo, ejecute el mandato chown -R maximo /export/home/maximo
directorio de instalación
de maximo.
Cree el enlace simbólico
que se ha de esperar
Ejecute el mandato ln -sf /usr/local/bin/expect /usr/bin/expect
Modifique
/etc/ssh/sshd_config
Cambie PermitRootLogin por yes. Si se está ejecutando SSH, deténgalo y reinícielo de modo que se
actualice la ubicación para SSH.
Modifique
/etc/ftpd/ftpusers
Elimine la línea que contiene root
Capítulo 3. Tareas previas a la migración
47
Establezca los límites de
usuario
Si no se ha configurado específicamente un límite para un usuario, se utilizará el valor
predeterminado. El valor predeterminado suele ser unlimited para todos los límites necesarios salvo
para el tamaño de pila. Para cambiar el tamaño de pila del usuario root:
1. Cree un archivo .profile en el directorio /, si todavía no existe.
2. Agregue ulimit -s unlimited al archivo.
3. Cierre la sesión como root y vuelva a iniciarla para que los cambios surtan efecto.
4. Compruebe los valores desde una ventana de mandatos ejecutando ulimit -s.
Establezca el tamaño de
intercambio
Dado que Tivoli Provisioning Manager es una aplicación que puede ocupar muchos recursos, se le
recomienda que configure y ajuste el sistema para máximo rendimiento, incluido el valor de tamaño
espacio de intercambio que se utiliza en el sistema. Normalmente, el tamaño de intercambio
establecido debe ser equivalente al doble de la cantidad de RAM física del sistema. Puede crear espacio
de intercambio adicional disponible de este modo:
v Aumentando el tamaño de la partición de intercambio existente
v Creando una nueva partición de intercambio adicional
v Creando un archivo de intercambio
Para obtener más información, consulte la documentación del sistema operativo.
Compruebe los requisitos El indicador de mandatos debe terminar por $, # o >.
del indicador de
mandatos
Paquetes necesarios (sólo UNIX y Linux)
En UNIX y Linux, son necesarios algunos paquetes para instalar Tivoli
Provisioning Manager.
En las secciones siguientes se listan los paquetes necesarios:
v
v
v
v
v
“Requisitos de UNIX y Linux”
“Paquetes de AIX necesarios”
“Paquetes Red Hat Linux necesarios ” en la página 50
“Paquetes SUSE Linux necesarios ” en la página 51
“Paquetes necesarios para Solaris” en la página 52
UNIX
Linux
Requisitos de UNIX y Linux
Los siguientes programas de utilidad son necesarios y deben estar disponibles
desde las ubicaciones siguientes:
v Bash: /bin/bash
v Expect, tar, gzip: /usr/bin
Si no están instalados en estas ubicaciones, cree un enlace simbólico entre estos
directorios y la ubicación real.
AIX
Paquetes de AIX necesarios
Se necesitan los siguientes paquetes para AIX. Si una determinada versión del
paquete no aparece listada, utilice la versión nativa del paquete que se incluye con
el sistema operativo al nivel de actualización actual. Para verificar qué paquetes se
instalan, utilice el mandato lslpp. Por ejemplo, lslpp -L|grep unzip
48
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 28. Paquetes de AIX necesarios
Requisito
Detalles
Paquetes necesarios
para todos los sistemas
operativos AIX
soportados
bash
bash-doc
cairo-1.0.2-6
Expect 5.4 o superior
glib
gtk2 2.8.3
perl-5.8.2
tcl
tk
unzip
wget-1.9
Para obtener estos paquetes, vaya a http://www.ibm.com/systems/p/os/aix/linux/toolbox/
download.html.
Programas de utilidad
tar necesarios para
todos los sistemas
operativos AIX
soportados
tar de UNIX nativo
GNU tar
Estos dos programas de utilidad son necesarios. Dado que el programa de utilidad nativo no da soporte
a los nombres de archivos largos, debe asegurarse de que esté instalado GNU tar versión 1.14 o superior,
de modo que se puedan extraer los archivos de instalación.
1. Para obtener GNU tar, vaya a http://www.ibm.com/systems/p/os/aix/linux/toolbox/
download.html.
2. Asegúrese de que /bin/tar es el UNIX tar nativo ejecutando el siguiente mandato: /bin/tar -version. La salida del mandato muestra la información de uso.
3. Para comprobar la versión de GNU tar, ejecute el mandato siguiente gtar --version. La salida del
mandato muestra la versión de GNU tar y la información de copyright.
openssh
openssl
Instale la versión adecuada de openssh y openssl para su versión de AIX. Para verificar si estos paquetes
están instalados y su versión, ejecute:
necesario para todos
los sistemas operativos
AIX soportados
lslpp -l |grep openssh
lslpp -l |grep openssl
La versión mínima de openssh es 5.0.0.5301. Si no se ha instalado openssh, descárguelo desde
https://sourceforge.net/projects/openssh-aix.
Si openssl no está instalado:
1. Vaya a http://www.ibm.com/systems/p/os/aix/linux/toolbox/download.html.
2. Haga clic en AIX Toolbox Cryptographic Content.
3. Inicie una sesión en el sitio web. Debe estar registrado para descargar el paquete.
Componentes del
Para AIX 5.3, los componentes necesarios son:
entorno de tiempo de
ejecución necesarios, en xlC.rte.9.0.0.1
función de la versión
xlC.aix50.rte.9.0.0.1
de AIX
Para obtener el paquete con los componentes, vaya a http://www-01.ibm.com/support/
docview.wss?uid=swg24016630.
Para AIX 6.1, los componentes necesarios son:
xlC.rte.9.0.0.1
xlC.aix61.rte.9.0.0.1
Para obtener el paquete con los componentes, vaya a http://www-01.ibm.com/support/
docview.wss?rs=0&uid=swg24018471.
Para comprobar si se ha instalado el paquete xlC.rte y su versión, ejecute $ lslpp -La |grep xlC.rte
Capítulo 3. Tareas previas a la migración
49
Tabla 28. Paquetes de AIX necesarios (continuación)
Requisito
Oracle
2000
Paquetes
adicionales necesarios
si se utiliza la base de
datos Oracle
Detalles
gcc
gcc-c++
libgcc
libstdc++
libstdc++_devel
Para obtener los paquetes, vaya a http://www.ibm.com/systems/p/os/aix/linux/toolbox/
download.html.
bos.adt.libm
bos.adt.prof
bos.cifs_fs.rte
bos.perf.proctools
Para obtener los paquetes, vaya a http://www.ibm.com/eserver/support/fixes. Especifique IBM System
p para la familia de productos y luego seleccione su versión de AIX. A continuación, puede buscar cada
paquete.
Paquetes adicionales
necesarios si se
gestionan parches para
sistemas de destino de
Red Hat Enterprise
Linux 5
urlgrabber 3.0.0
python 2.4.3 o superior
Nota: python 3 o superior no están soportadospython debe estar instalado o enlazado en el directorio
/usr/bin. Para comprobar si el paquete python está instalado y su versión, ejecute /usr/bin/python -V.
Para descargar python, vaya a http://www.python.org/.
Paquetes Red Hat Linux necesarios
Los siguientes paquetes son necesarios para Red Hat Linux. Si una determinada
versión del paquete no aparece listada, utilice la versión nativa del paquete que se
incluye con el sistema operativo al nivel de actualización actual. Para verificar qué
paquetes están instalados, utilice el mandato rpm. Por ejemplo, rpm -qa | grep
compat
Tabla 29. Paquetes Red Hat Linux necesarios
Requisito
Detalles
Paquetes necesarios
para todos los sistemas
operativos Red Hat
Linux soportados
compat-db-4.1.25-9
64-bit compat-libstdc++
expect 5.42
ftp
libstdc++
openssh
perl
rpm-build-4.3.3-22_nonptl
tcl
telnet
tk
wget
xorg-x11-xfs
xorg-x11-font-utils
Un gestor de ventanas, por ejemplo GNOME o KDE
Paquetes adicionales
necesarios para Red
Hat Enterprise Linux 5
(x86 64-bits)
32-bit compat-libstdc++-33
libXmu-1.0.2-5.i386.rpm
libXp-1.0.0-8.1.el5.i386.rpm
xorg-x11-fonts-base
xorg-x11-fonts-75dpi
xorg-x11-fonts-100dpi
50
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 29. Paquetes Red Hat Linux necesarios (continuación)
Requisito
Detalles
Paquetes y bibliotecas
adicionales necesarios
para Red Hat
Enterprise Linux 5
(IBM System z 64 bits)
32-bit compat-libstdc++-33
libaio.so.1 (bibliotecas necesarias en el directorio /usr/lib64 para los servidores de DB2 que
utilizan E/S asíncrona)
libstdc++.so.5 (bibliotecas necesarias en el directorio /usr/lib64 para servidores y clientes de DB2)
libXmu-1.0.2-5.s390x.rpm
libXp-1.0.0-8.1.el5.s390x.rpm
xorg-x11-fonts-base
xorg-x11-fonts-75dpi
xorg-x11-fonts-100dpi
Paquetes adicionales
necesarios para Red
Hat Enterprise Linux 4
AS Update 5 (x86 64
bits)
fonts-xorg-base
fonts-xorg-75dpi
fonts-xorg-100dpi
Los paquetes siguientes se deben instalar en el orden siguiente:
32-bit libgcc-3.4.3-9
32-bit compat-libstdc++-33
Oracle
2000
Paquetes
adicionales necesarios
si se utiliza el cliente
de Oracle
Paquetes adicionales
necesarios si se
gestionan parches para
sistemas de destino de
Red Hat Enterprise
Linux 5
compat-gcc-34 version 3.2.3 o superior
compat-gcc-34-c++ version 3.2.3 o superior
compat-libgcc
urlgrabber 3.0.0
python 2.4.3 o superior
Nota: python 3 o superior no están soportadospython debe estar instalado o enlazado en el directorio
/usr/bin. Para comprobar si está instalado el paquete python y su versión, ejecute: rpm -q python. Para
descargar python, vaya a http://www.python.org/.
Paquetes SUSE Linux necesarios
Los siguientes paquetes son necesarios para SUSE Linux. Si una determinada
versión del paquete no aparece listada, utilice la versión nativa del paquete que se
incluye con el sistema operativo al nivel de actualización actual. Para verificar qué
paquetes están instalados, utilice el mandato rpm. Por ejemplo, rpm -qa | grep
compat
Tabla 30. Paquetes SUSE Linux necesarios
Requisito
Detalles
Paquetes necesarios
para todos los sistemas
operativos SUSE Linux
64-bit compat-libstdc++
Expect 5.42
gtk+
libstdc++
ncftp
openssh
perl
tcl
telnet
tk
wget
Un gestor de ventanas, por ejemplo GNOME o KDE
Oracle
2000
Paquetes
adicionales necesarios
si se utiliza el cliente
de Oracle
compat-libgcc
Capítulo 3. Tareas previas a la migración
51
Tabla 30. Paquetes SUSE Linux necesarios (continuación)
Requisito
Detalles
libaio.so.1 (necesario para los servidores de DB2 utilizando E/S asíncrono)
Paquetes libstdc++so.5 (necesario para clientes y servidores de DB2)
adicionales necesarios
para SUSE Linux
Enterprise Server (IBM
System z 64 bits) si se
utiliza DB2
Paquetes adicionales
necesarios si se
gestionan parches para
sistemas de destino de
Red Hat Enterprise
Linux 5
urlgrabber 3.0.0
python 2.4.3 o superior
Nota: python 3 o superior no están soportadosPara comprobar si el paquete python está instalado y su
versión, ejecute rpm -q python. Para descargar python, vaya a http://www.python.org/.
Paquetes necesarios para Solaris
Los siguientes paquetes son necesarios para Solaris. Si una versión específica del
paquete no está listada, utilice la versión disponible más reciente para el sistema
operativo.
Tabla 31. Paquetes necesarios para Solaris
Requisito
Detalles
Paquetes necesarios
para todos los sistemas
operativos Solaris
perl
SSH
SUNWmlib
SUNWscpu
SUNWxcu4
SUNWgtar
SUNWsshd
Si no está instalado SUNWgtar, tar-1.15.1-sol10-sparc-local (SMCtar) es necesario.
Los paquetes anteriores están incluidos de forma predeterminada con el sistema operativo.
expect-5.40-sol10-sparc-local
gtk+
libgcc-3.3-sol10-sparc-local
libiconv-1.8-sol10-sparc-local
tcl-8.4.9-sol10-sparc-local
tk-8.4.9-sol10-sparc-local
unzip
wget
coreutils-6.4-sol10-sparc-local.gz
Para obtener los paquetes anteriores, vaya a http://www.sunfreeware.com.
Vías de acceso de
programas de utilidad
de tar
1. Asegúrese de que SMCtar o SUNWgtar sea el programa de utilidad tar predeterminado utilizado. Para
verificar esto, ejecute tar --version y verifique que se ha devuelto la versión tar.
2. Si se devuelve un error, asegúrese de que la variable PATH contiene la vía de acceso SMCtar o
SUNWgtar y que la vía de acceso se ha definido antes que cualquier otra vía de acceso tar en el
sistema. Por ejemplo, si se utiliza un programa de utilidad tar instalado en /usr/bin y SMCtar está
instalado en /usr/local/bin, la variable PATH es similar al ejemplo siguiente:
PATH=/usr/local/bin:/usr/sbin:/usr/bin
52
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 31. Paquetes necesarios para Solaris (continuación)
Requisito
Detalles
Paquetes
adicionales necesarios
si se utiliza el cliente
de DB2
gmp-4.2.1-sol10-sparc-local
libintl. Para obtener el paquete, vaya a http://www.sunfreeware.com.
Paquetes adicionales
necesarios si se utilizan
idiomas que no son el
idioma inglés
Paquetes adicionales
necesarios si se
gestionan parches para
sistemas de destino de
Red Hat Enterprise
Linux 5
urlgrabber 3.0.0
python 2.4.3 o superior
Nota: python 3 o superior no están soportadosPara comprobar si está instalado el paquete python y su
versión, ejecute: pkginfo -l | grep python. Para descargar python, vaya a http://www.python.org/.
Requisitos del servidor de bases de datos y directorios
Asegúrese de que cumple con los requisitos de su sistema operativo o base de
datos antes de instalar Tivoli Provisioning Manager.
Requisitos del servidor de bases de datos
Se da soporte a las siguientes versiones de bases de datos. Asegúrese de que
cumple con los requisitos de su sistema operativo antes de instalar y configurar la
base de datos.
Tabla 32. Requisitos del servidor de bases de datos
Base de datos
Requisitos y limitaciones
v
UNIX
Linux
Para cumplir con los requisitos de espacio de disco del espacio de tablas
para la instalación de DB2, asegúrese de que tiene un mínimo de 8 gigabytes de espacio libre en
el directorio de inicio de la instancia de base de datos DB2. De forma predeterminada, la
ubicación es /home/ctginst1.
v
Windows
Para cumplir con los requisitos de espacio de disco del espacio de tablas para la
instalación de DB2, asegúrese de que tiene un mínimo de 8 gigabytes de espacio libre en el
directorio de instalación de DB2.
v
AIX
En AIX 5.3, asegúrese de que está habilitada la E/S asíncrona, de modo que las
instancias de base de datos se puedan iniciar correctamente. Para habilitar la E/S asíncrona:
DB2 Enterprise
Server 9.5 FP3a
1. Inicie una sesión en el sistema como root.
2. Ejecute smit chgaio
3. En el recuadro de diálogo Herramienta de la interfaz de gestión del sistema (SMIT), cambie
el ESTADO para que se configure al reiniciar el sistema a disponible y haga clic en Aceptar.
4. Salga de SMIT.
5. Ejecute smit aio
6. En el recuadro de diálogo Herramienta de la interfaz de gestión del sistema (SMIT),
seleccione Configurar E/S asíncrona definida y pulse Intro.
7. Rearranque el sistema para habilitar los cambios.
v
Linux
Asegúrese de que se ha habilitado la E/S asíncrona (AIO). Para utilizar AIO, debe
instalar libaio-0.3.96 o posterior y tener un kernel que dé soporte a AIO, por ejemplo, la versión
2.6).
Capítulo 3. Tareas previas a la migración
53
Tabla 32. Requisitos del servidor de bases de datos (continuación)
Base de datos
Requisitos y limitaciones
Oracle
2000
v Sólo se da soporte a Oracle Database para Tivoli Provisioning Manager instalado en UNIX o
Linux.
Oracle Database
10.2.0.4g o 11g
v Debe obtener sus propios soporte de instalación de Oracle Database antes de instalar Tivoli
R1
Provisioning Manager. Antes de instalar y configurar Oracle Database, asegúrese de cumple con
los requisitos del sistema operativo, como se describe en la documentación de Oracle Database.
v Oracle Text debe estar instalado y configurado correctamente. Si Oracle Text está inhabilitado,
debe habilitarlo antes de instalar Tivoli Provisioning Manager.
v EZCONNECT debe estar habilitado para el cliente de base de datos Oracle, de modo que el
cliente se pueda conectar con el servidor utilizando el nombre de servicio. Para habilitar
EZCONNECT:
1. Asegúrese de que el archivo sqlnet.ora del directorio $ORACLE_HOME/network/admin en el
cliente de Oracle contiene la información siguiente:
NAMES.DIRECTORY_PATH=
(TNSNAMES, EZCONNECT)
2. Añada el SID a SID_ LIST en el archivo listener.ora del directorio $ORACLE_HOME/network/
admin en el servidor de Oracle. Por ejemplo:
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=maxdb71.databaseServer.ibm.com)
(SID_NAME=maxdb71)
(ORACLE_HOME=C:\oracle\Administrator\product\11.1.0)
)
)
donde GLOBAL_DBNAME es el nombre de servicio utilizado para conectar con el servidor
de Oracle.
Requisitos del servidor de directorios
Los requisitos siguientes se aplican al servidor de directorios.
Tabla 33. Requisitos del servidor de directorios
Servidor de
directorios
Tivoli Directory
Server y
Microsoft
Active
Directory
Requisitos y limitaciones
Compruebe los siguientes valores en el archivo /etc/nsswitch.conf
passwd: file ldap
shadow: file ldap
group: file ldap
Si tiene la opción ldap configurada, una consulta buscará los archivos locales primero y luego
buscará el servidor de directorios. Si el servidor de directorios contiene un usuario denominado
tioadmin o un grupo denominado tivoli, el instalador no podrá crear el usuario tioadmin o el
usuario tivoli en el sistema operativo y la instalación será errónea. Para evitar este problema de
instalación, cambie la configuración en /etc/nsswitch.conf por:
passwd: file
shadow: file
group: file
54
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 33. Requisitos del servidor de directorios (continuación)
Servidor de
directorios
Requisitos y limitaciones
Tivoli Directory v Si está instalando un nuevo Tivoli Directory Server, y no tiene establecidos procedimientos para
Server
modificar las contraseñas corporativas, debe realizar los pasos de la sección “Modificación de
las contraseñas de usuario” en la página 229 antes de intentar modificar las contraseñas de
usuario.
v
AIX
El módulo de entorno local loc.iso.en_US debe estar instalado y su nivel debe ser
5.3.0.0 o superior. Para ver si se ha instalado el módulo loc.iso.en_US, ejecute lslpp -l | grep
bos.loc.iso.en_US
Microsoft
v No se da soporte a Microsoft Active Directory Application Mode (ADAM).
Windows
v Debe obtener sus propios soporte de instalación de Microsoft Active Directory antes de instalar
Server 2003 SP2
Tivoli Provisioning Manager. Antes de instalar y configurar Microsoft Active Directory,
Active
asegúrese de cumple con todos los requisitos, como se describe en la documentación de
Directory
Microsoft Active Directory.
Requisitos del navegador
Tivoli Provisioning Manager requiere un navegador para ejecutar el Launchpad de
instalación y la interfaz web. Asegúrese de que reúne los requisitos del navegador.
Se da soporte a los siguientes navegadores web:
v Microsoft Internet Explorer versión 6.0 o 7.0 con los parches más recientes
v Mozilla Firefox 3.0 y superior.
v
AIX
Mozilla Firefox 2.0.0.20 y cairo-1.0.2-6
Para verificar la información de la versión de Mozilla Firefox, ejecute firefox
-version. Asegúrese de que el mandato no devuelve errores antes de continuar con
la instalación.
Nota: Puede eliminar el navegador y los paquetes asociados después de que se
haya completado la instalación.
La única plataforma UNIX en la que se ha certificado Firefox es Red
Hat Linux.
AIX
Para obtener un navegador para AIX, vaya a http://www.ibm.com/
systems/p/os/aix/browsers/index.html . Dependiendo de la configuración del
sistema operativo actual, puede que sea necesario instalar algunos paquetes
adicionales antes de instalar el navegador. Para obtener los paquetes necesarios,
vaya a http://www.ibm.com/systems/p/os/aix/linux/toolbox/download.html
Asignación de hardware
Los requisitos de hardware dependen del uso. La instalación de la mayoría de los
componentes es de una sola hebra y no aprovecha por completo los procesadores
duales. Para obtener los requisitos de hardware del software que no figuran en la
lista, consulte la documentación del producto suministrada con el mismo.
Requisitos de procesador para el servidor de suministro
v
Windows
v
Linux
Linux
Procesador 2.4 GHz x86 64-bit o AMD64
en IBM System z: z/Architecture (z800)
Capítulo 3. Tareas previas a la migración
55
v
AIX
1.5 GHz Power5 (100% de un procesador si se utiliza la micro
partición)
1.4 GHz SPARC64/UltraSPARC
v
Requisitos mínimos de memoria
Topología de servidor
individual
v
Windows
Procesador
de 32 bits: 4 GB de
RAM
v Procesador de 64 bits:
8 GB de RAM
Topología de varios servidores
Servidor de DB2
2 GB RAM
WebSphere Application Server Network Deployment
4 GB de RAM
Tivoli Directory Server
1 GB de RAM
Requisitos de estaciones de trabajo administrativas
v Procesador de 2 GHz (mínimo)
v 1 GB de RAM (mínimo)
v Conexión de red de 10 Mbit/s entre el sistema administrativo y los servidores
de middleware (mínimo)
Nota: Windows El motor de despliegue que utilizan los servicios básicos siempre
se instala, de forma predeterminada en el directorio raíz del sistema Windows de
la estación de trabajo administrativa C:\Archivos de programa\ibm\acsi,
independiente del directorio especificado durante la instalación. Asegúrese de que
los permisos se establecen de modo que se permita la instalación del motor de
despliegue en el directorio raíz de Windows.
Espacio de disco
En la tabla siguiente se especifica el espacio de disco que debe asignarse a cada
directorio para el proceso de instalación. Aunque estos directorios no existan antes
de la instalación, asegúrese de que el directorio padre de estos directorios tenga
espacio suficiente disponible para la instalación.
Sistemas de archivos de red: Tivoli Provisioning Manager incluye un tiempo de
ejecución de la infraestructura ligera que utiliza el bloqueo del sistema de archivos
para gestionar la simultaneidad. Estos archivos de bloqueo se gestionan en el
directorio de instalación de la infraestructura ligera, en el directorio TIO_HOME
del sistema de archivos. Si instala Tivoli Provisioning Manager en un sistema de
archivos de red, asegúrese de que el sistema de archivos tenga el soporte de
gestión de bloqueos necesario. Por ejemplo, en una configuración de recuperación
tras desastre de alta disponibilidad, si el sistema primario falla y ya no está
disponible, el sistema de archivos debe poder desbloquear automáticamente todos
los bloqueos asociados con el sistema primario. Si este tipo de soporte de bloqueo
no está disponible, puede crear enlaces de software para los directorios siguientes
con un sistema de archivos local para corregir el soporte de gestión de bloqueos:
v TIO_HOME/lwi/conf
v TIO_HOME/lwi/logs
Windows
56
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Requisitos de espacio de disco de Windows
Asegúrese de que tiene 60 GB de espacio disponible en el disco C:\, como se
describe en la tabla siguiente.
Tabla 34. Requisitos de espacio de disco para Windows
Espacio
necesario
Componente
Directorio
Imágenes de instalación
ubicación especificada por el usuario
12 GB
Estación de trabajo administrativa
Carpeta de despliegue de Maximo
C:\ibm\SMP
5 GB
Paquete de idioma de servicios básicos
c:\ibm\SMP
100 MB
Directorio temporal del sistema
%TEMP%
2.5 GB
Espacio temporal
Si utiliza el directorio temporal del sistema (%TEMP%) para los tres tipos de espacio temporal, se necesita un total
de 6 GB. De lo contrario, asegúrese de que tiene espacio suficiente en cada una de las ubicaciones temporales.
Espacio temporal para instalador de middleware
ubicación especificada por el usuario (el valor
predeterminado es %TEMP%)
1 GB
Espacio temporal para el repositorio de software
ubicación especificada por el usuario (el valor
predeterminado es %TEMP%)
6 GB
Directorio temporal del sistema
%TEMP%
2.5 GB
Componentes de la instalación
Cygwin
C:\Cygwin
200 MB
Kit de herramientas de GSK
C:\ibm\gsk7
Tivoli Provisioning Manager
C:\Archivos de programa\IBM\tivoli\tpm
Tivoli Monitoring Agent
C:\ibm\tivoli\ITM
Tivoli Provisioning Manager for OS Deployment
C:\Archivos de programa\IBM\TPMfOSd
Directorio de datos de Tivoli Provisioning
Manager for OS Deployment
C:\tpmfosd
150 MB
El gestor de agentes
C:\Archivos de programa\IBM\AgentManager
100 MB
10 MB
6 GB
250 MB
5 MB
Federador de Tivoli Provisioning Manager for Job C:\Archivos de programa\IBM\DeviceManager
Management Service
200 MB
Tivoli Provisioning Manager for Dynamic
Content Delivery
C:\Archivos de programa\IBM\tivoli\CDS
150 MB
Archivos comunes de Tivoli, incluidos los
registros comunes
C:\Archivos de programa\IBM\tivoli\common\
COP\logs
100 MB
Servidor de DB2
Unidad_sistema:\Archivos de
programa\IBM\SQLLIB
Instancia de base de datos de DB2
C:\CTGINST1
1 GB
10 GB
Cliente de DB2 (para el despliegue de Unidad_sistema:\Archivos de
programa\IBM\SQLLIB
varios servidores)
Custom
Default
XML
1.5 GB
Tivoli Directory Server
C:\Archivos de programa\IBM\LDAP\V6.2
450 MB
Base de datos de Tivoli Directory Server
C:\IDSCCMDB
900 MB
Archivos de la base de datos de Tivoli Directory
Server
C\idslap-idsccmdb
1 MB
WebSphere Application Server
C:\Archivos de programa\IBM\WebSphere\
AppServer
4 GB
Capítulo 3. Tareas previas a la migración
57
Tabla 34. Requisitos de espacio de disco para Windows (continuación)
Espacio
necesario
Componente
Directorio
IBM HTTP Server
C:\Archivos de programa\IBM\HTTPServer
Archivos del instalador de middleware
C:\ibm\tivoli\mwi
1.1 GB
100 MB
Instalador de soluciones que utilizan el instalador C:\Archivos de programa\IBM\Common\acsi
de middleware y el instalador de servicios
básicos
400 MB
Archivos comunes de Tivoli
150 MB
C:\Archivos de programa\Common Files\IBM
Tivoli
C:\Archivos de programa\tivoli
IBM JRE
C:\Archivos de programa\IBM\Java50
Archivos de copia de seguridad de una
instalación predeterminada
C:\backup
25 MB
250 MB
2 GB
Nota:
v Es posible que necesite mucho más espacio en las unidades FAT (File Allocation Table) con tamaños grandes de
clúster que en las unidades NTFS (New Technology File System).
v Planifique un espacio de disco adicional para el crecimiento de la base de datos. El espacio de disco depende de
diversos factores, incluida la configuración de la base de datos y el número de sistemas de destino gestionados.
Por ejemplo, si gestiona 50.000 destinos, asigne 50 GB de espacio de disco libre. Considere la posibilidad de
almacenar la base de datos en un dispositivo de almacenamiento dedicado independiente para que el rendimiento
no se vea afectado por el acceso de otras aplicaciones al mismo dispositivo.
UNIX
Linux
Requisitos de espacio de disco en UNIX y Linux
Asegúrese de que tiene el espacio disponible necesario en los directorios siguientes.
Los números excluyen el espacio necesario para la estación de trabajo
administrativa y para las imágenes de instalación (13 GB). Asimismo, se presupone
que se utilizan los directorios predeterminados.
Tabla 35. Requisitos de espacio de disco consolidados para AIX
Directorio
Espacio necesario
/home
10.3 GB
/opt
10.3 GB
/tmp
3,5 GB
/usr
5.6 GB
/var
6 GB
Linux
Tabla 36. Requisitos de espacio de disco consolidados para Solaris y Linux
58
Directorio
Espacio necesario
/home
10.3 GB
/opt
15.4 GB
/tmp
3,5 GB
/usr
500 MB
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
6 GB
/var
Consulte la siguiente tabla para obtener información detallada.
Tabla 37. Requisitos de espacio de disco detallados para UNIX y Linux
Espacio
necesario
Componente
Directorio
Imágenes de instalación
ubicación especificada del usuario
13 GB
Estación de trabajo administrativa
La estación de trabajo administrativa sólo está soportada en sistemas operativos específicos y en topologías
específicas. Para obtener más información, consulte Despliegue de varios servidores.
Carpeta de despliegue de Maximo
Directorio temporal del sistema
v
Windows
v
UNIX
5 GB
C:\ibm\SMP
Linux
/opt/IBM/SMP
%TEMP%
2.5 GB
Espacio temporal
Si utiliza el directorio temporal del sistema (/tmp) para los tres tipos de espacio temporal, se necesita un total de 6
GB. De lo contrario, asegúrese de que tiene espacio suficiente en cada una de las ubicaciones temporales.
Espacio temporal designado para su uso por el
instalador de middleware
ubicación especificada por el usuario (el valor
predeterminado es /tmp)
1 GB
Espacio temporal para el repositorio de software ubicación especificada por el usuario (el valor
predeterminado es /var/tmp)
6 GB
Directorio temporal del sistema
/tmp
2.5 GB
El espacio de trabajo del instalador de
middleware
v
Windows
v
Linux
v
AIX
C:\ibm\tivoli\mwi\workspace
600 MB
/root/ibm/tivoli/mwi/workspace
/ibm/tivoli/mwi/workspace
Componentes instalados
Tivoli Provisioning Manager
/opt/IBM/tivoli/tpm
6 GB
Tivoli Provisioning Manager for OS Deployment /opt/IBM/tpmfos
150 MB
Directorio de datos de Tivoli Provisioning
Manager for OS Deployment
/opt/tpmfosd_files
150 MB
El gestor de agentes
/opt/IBM/AgentManager
100 MB
Federador de Tivoli Provisioning Manager for
Job Management Service
/opt/IBM/DeviceManager
200 MB
Tivoli Provisioning Manager for Dynamic
Content Delivery
/opt/IBM/tivoli/CDS
150 MB
Archivos comunes de Tivoli, incluidos los
registros comunes
/usr/ibm/tivoli/common/COP/logs
100 MB
Tivoli Monitoring Agent
/opt/IBM/tivoli/ITM
250 MB
Servidor de DB2
Instancia de base de datos de DB2
2,1 GB
v
AIX
v
Linux
/opt/ibm/db2/V9.5
v
Linux
en IBM System z: /opt/IBM/db2/V9.5
/opt/IBM/db2/V9.5
/home/ctginst1
10 GB
Capítulo 3. Tareas previas a la migración
59
Tabla 37. Requisitos de espacio de disco detallados para UNIX y Linux (continuación)
Espacio
necesario
Componente
Directorio
Cliente de DB2 (para topologías de varios
servidores)
v
AIX
v
Linux
/opt/ibm/db2/V9.5
v
Linux
en IBM System z: /opt/IBM/db2/V9.5
400 MB
/opt/IBM/db2/V9.5
Tivoli Directory Server
/opt/IBM/ldap/V6.2
Nota: Si ha creado un sistema de archivos
separado, por ejemplo, /opt/ibm/ldap u /opt/ibm
para la ubicación de instalación de Tivoli Directory
Server, asegúrese de que tanto /opt como el
directorio de instalación de Tivoli Directory Server
cumplan con los requisitos de espacio de disco.
800 MB
Base de datos de Tivoli Directory Server
/home/idsccmdb
300 MB
WebSphere Application Server
v
AIX
/usr/IBM/WebSphere/AppServer
Linux
v
3,5 GB
/opt/IBM/WebSphere/
AppServer
Instalador de actualizaciones de WebSphere
Application Server
v
AIX
/usr/IBM/WebSphere/
UpdateInstaller
Linux
v
500 MB
/opt/IBM/WebSphere/
UpdateInstaller
IBM HTTP Server
v
AIX
Linux
v
Instalador de soluciones que utilizan el
instalador de middleware y el instalador de
servicios básicos
/usr/IBM/HTTPServer
1.1 GB
/opt/IBM/HTTPServer
/usr/ibm/common/acsi
400 MB
Nota:
v Planifique un espacio de disco adicional para el crecimiento de la base de datos. El espacio de disco depende de
diversos factores, incluida la configuración de la base de datos y el número de sistemas de destino gestionados.
Por ejemplo, si gestiona 50.000 destinos, asigne 50 GB de espacio de disco libre. Considere la posibilidad de
almacenar la base de datos en un dispositivo de almacenamiento dedicado independiente para que el rendimiento
no se vea afectado por el acceso de otras aplicaciones al mismo dispositivo.
Requisitos mínimos de memoria
Topología de servidor
individual
v
Windows
Procesador
de 32 bits: 4 GB de
RAM
v Procesador de 64 bits:
8 GB de RAM
60
Topología de varios servidores
Servidor de DB2
2 GB RAM
WebSphere Application Server Network Deployment
4 GB de RAM
Tivoli Directory Server
1 GB de RAM
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Unidad de DVD
Si utiliza DVD para instalar el producto, cada sistema de la topología debe tener
una unidad de DVD.
Verificación de los requisitos de nombres, contraseñas y
cuentas de usuario
Revise las reglas importantes de las cuentas de usuario, los nombres de usuario,
las contraseñas y los nombres de los objetos de DB2 como, por ejemplo, las
instancias de base de datos.
Nombres de usuario y contraseñas para el entorno 7.1.1.
Se aplican las reglas siguientes para las credenciales de usuarios y sistemas para la
migración a la versión 7.1.1:
v Los nombres de usuarios y contraseñas que se utilizaban en el entorno 5.1.1.2 se
deben utilizar en el entorno 7.1.1. Por ejemplo, en la versión 7.1.1. la contraseña
para el usuario tioadmin debe ser la misma que en la versión 5.1.1.2.
Para cambiar las contraseñas después de finalizada y validad la migración,
utilice la herramienta changePassword.
v Vuelva a utilizar las credenciales del sistema local para sus sistemas 5.1.1.2 en la
versión 7.1.1.
Si cambia las credenciales durante la migración y luego intenta ejecutar las
operaciones de suministro en el entorno 7.1.1, las operaciones fallarán con
errores de autenticación.
Reglas generales de nombre de usuario, nombre de instancia y
contraseña
Las siguientes reglas generales se aplican a todos los nombres de usuario y
contraseñas. Las reglas de los nombres de usuario de DB2 también se aplican a los
nombres de instancia de base de datos.
Nombre de usuario
v A menos que se indique lo contrario en las reglas siguientes, los
nombres de usuario sólo pueden contener caracteres alfanuméricos del
alfabeto inglés o los caracteres siguientes: punto (.), arroba (@), signo
menos (-) y subrayado (_).
v DB2 impone las siguientes restricciones adicionales en los nombres de
usuario.
– Los nombres no pueden comenzar con un número ni con el carácter
de subrayado.
– No puede utilizar palabras reservadas de SQL.
–
UNIX
Linux
- Los nombres deben escribirse con caracteres en minúsculas.
- Los nombres pueden contener letras minúsculas de a-z, números de
0-9 y _ (subrayado).
- Los nombres de grupo y los nombres de usuario pueden contener
hasta 8 caracteres.
–
Windows
- Los nombres pueden escribirse en mayúsculas y en minúsculas.
- Los nombres de grupo y los nombres de usuario pueden contener
hasta 30 caracteres.
Capítulo 3. Tareas previas a la migración
61
- Cuando no se utiliza la autenticación de cliente, los clientes de 32
bits que no son de Windows y se conectan a Windows con nombres
de usuario de más de 8 caracteres están soportados cuando el
nombre de usuario y la contraseña se especifican explícitamente
– Los nombres de usuario y de grupo no pueden:
- Ser USERS, ADMINS, GUESTS, PUBLIC, LOCAL o cualquier otra
palabra reservada de SQL
- Comenzar por IBM, SQL o SYS.
– Los nombres de usuario y de grupo también deben cumplir las reglas
que aplican los sistemas relacionados en sistemas operativos
específicos. Por ejemplo, en las plataformas Linux y UNIX, los
nombres de usuario y los nombres de grupo primario deben cumplir
estas reglas:
- Caracteres permitidos: letras minúsculas de a-z, números de 0-9 y _
(subrayado) para los nombres que no empiezan con un número de
0-9.
- La longitud debe ser menor o igual a 8 caracteres.
Nombres de base de datos y de instancia de base de datos
Para los nombres de instancia, se aplican las reglas de los nombres de
usuario y de grupo. Además:
Instancia de base de datos de DB2
v Los nombres de instancia pueden tener hasta 8 bytes
v En Windows, ninguna instancia puede tener el mismo nombre
que un nombre de servicio.
v Los nombres de instancia no pueden contener el carácter #.
Nombres de base de datos y de instancia de Tivoli Directory Server
v Los nombres de base de datos deben ser exclusivos en la
ubicación en la que se catalogan. En las implementaciones de
Linux y UNIX del gestor de base de datos de DB2®, esta
ubicación es una vía de acceso de directorios, mientras que en
las implementaciones de Windows, es un disco lógico
v Los nombres de alias de base de datos deben ser exclusivos en el
directorio de base de datos del sistema. Cuando se crea una
nueva base de datos, el alias toma el nombre de la base de datos
de forma predeterminada. Como resultado, no puede crear una
base de datos utilizando un nombre que exista como alias de
base de datos, aunque no haya ninguna base de datos con ese
nombre.
v Los nombres de base de datos y de alias de base de datos
pueden tener hasta 8 bytes.
v Los nombres de base de datos y de instancia:
– Pueden tener hasta 8 caracteres
– No pueden ser los siguientes: USERS, ADMINS, GUESTS,
PUBLIC, LOCAL, idsldap
– No pueden empezar por: IBM, SQL, SYS
– No pueden incluir caracteres acentuados
– Pueden incluir los siguientes caracteres:
- A-Z
- a-z
- 0-9
62
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
– Deben empezar por uno de los siguientes caracteres:
- A-Z
- a-z
Nota: No utilice los caracteres especiales @, # y $ en un nombre de
base de datos si tiene previsto utilizar la base de datos en un
entorno de comunicaciones. Asimismo, como estos caracteres no
son comunes para todos los teclados, no los utilice si tiene previsto
utilizar la base de datos en otro idioma.
Contraseñas
Las contraseñas que puede utilizar están sujetas a algunas restricciones.
Compruebe los requisitos siguientes:
v Las contraseñas sólo pueden contener caracteres alfanuméricos del
alfabeto inglés o los caracteres siguientes: punto (.), arroba (@), signo
menos (-) y subrayado (_).
v No utilice estos caracteres en las contraseñas:
&, ^, <, >, ", ', ), (, |, !, $, #, % ` ' \
| +
v La contraseña del administrador de WebSphere Application Server debe
tener exactamente 8 caracteres
v Si utiliza DB2 como base de datos, se aplican las reglas siguientes a las
contraseñas de usuario de DB2. Consulte la documentación de DB2 para
obtener más información.
– Las contraseñas pueden ser como máximo de 14 caracteres en
Windows y 8 caracteres en UNIX o Linux.
– Las contraseñas no pueden comenzar con un carácter &.
v Algunos sistemas operativos pueden tener más reglas de contraseña, por
ejemplo, de longitud mínima y simplicidad. Consulte la documentación
del sistema operativo correspondiente.
Consideraciones adicionales
Algunos controles de seguridad configurados en el entorno pueden
impedir que el instalador de Tivoli Provisioning Manager cree las cuentas
de usuario necesarias en el sistema para la instalación. Algunos de los
factores son:
v Los permisos o listas de control de accesos configurados para el sistema
pueden impedir que el instalador cree usuarios, cree archivos y
directorios relacionados con usuarios o asigne permisos.
v Si una contraseña especificada durante la instalación no cumple la
política de contraseñas configurada en el entorno, el proceso de creación
de usuarios falla para el usuario asociado con la contraseña
incompatible.
Si detecta problemas con la creación de usuarios durante la instalación, es
posible que tenga que crear los usuarios necesarios manualmente para
asegurar la conformidad con todas las políticas de seguridad y la
conformidad con los requisitos de Tivoli Provisioning Manager. Luego el
instalador puede utilizar las cuentas de usuario y los valores de usuario
configurados para realizar la instalación.
Windows
Capítulo 3. Tareas previas a la migración
63
Requisitos de usuario en Windows
v Además de los usuarios creados, se necesita un usuario con acceso de
administrador para iniciar la instalación. El usuario debe pertenecer al grupo
Administradores. El usuario Administrador de Windows predeterminado tiene
el acceso necesario.
v Los usuarios se crean como cuentas del sistema en el sistema operativo. Los
usuarios de cuentas de dominio definidos en un servidor de directorio no
reciben soporte para los usuarios necesarios durante la instalación.
UNIX
Requisitos de usuario en UNIX y Linux
Requisitos de usuario root
El valor umask se debe establecer en 002 para el usuario root. Si ya existe
un valor de umask, cambie dicho valor por 002. Puede volver al valor
original después de la instalación. Para establecer el valor umask:
AIX
En el archivo /etc/security/user, cambie el valor de umask
v
correspondiente a root por umask = 002.
Linux
Si utiliza el shell bash, en el directorio padre de root, agregue
v
la línea umask 002 al final del archivo .bashrc.
Linux
Si utiliza el shell Korn, en el directorio padre de root, agregue
v
la línea umask 002 al archivo .profile.
v
UNIX
En el archivo /etc/profile, cambie el valor de umask
correspondiente a root por umask = 002.
Linux
Requisitos de usuario de base de datos
Si el servidor de bases de datos de DB2 está en un sistema diferente al
servidor de suministro, asegúrese de que cumple con los requisitos
siguientes:
UNIX
Linux
El usuario de la instancia de base de datos debe
v
existir en el servidor de DB2. Por ejemplo, si piensa crear la instancia de
DB2 ctginst1, debe crear un usuario (incluido el directorio padre del
usuario) en el servidor de DB2. El grupo db2iadm1 debe existir.
Debe crear manualmente un usuario de sistema operativo
denominado maximo en el servidor de bases de datos. El instalador
establecerá los permisos necesarios para el usuario.
Servicio de información de red (NIS) y valores en nsswitch.conf
v NIS no recibe soporte para gestionar cuentas de usuario o grupos.
Asegúrese de que la gestión de usuarios NIS esté inhabilitada.
v Compruebe la configuración para nsswitch.conf. Para obtener más
información, consulte Requisitos de base de datos y servidor de
directorios.
v
Verificación del entorno
Revise las reglas para nombres de host, direcciones IP, puertos, conexiones remotas
y otros requisitos del entorno.
Resolución de nombres de host con un servidor DNS
Si utiliza un servidor DNS para resolver nombres de host, el nombre de host debe
estar definido en el servidor DNS. Durante la instalación, el mandato nslookup
verifica que el nombre de host del sistema esté definido en el servidor DNS.
También compara el nombre de host definido en el servidor DNS con el nombre de
host local definido en el sistema operativo para asegurarse de que coincidan.
64
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
1. Compruebe que puede ejecutar el mandato ping localhost correctamente. Si
recibe un error, la información de esta sección puede ayudarle a identificar el
origen del problema.
2. Para comprobar el nombre de host configurado en el sistema operativo, ejecute
el siguiente mandato en el indicador de mandatos:
hostname
El mandato devuelve el nombre de host abreviado para el sistema. Por ejemplo:
admin
3. Para comprobar el nombre de host configurado en un servidor DNS, ejecute el
mandato siguiente en el indicador de mandatos:
nslookup nombre_host
donde nombre_host es el valor que se ha devuelto en el paso anterior. El
mandato devuelve el nombre de dominio completo registrado en el servidor
DNS. Por ejemplo: admin.example.com.
v Si el nombre de host abreviado no coincide con la primera parte del nombre
de dominio completo registrado en el servidor DNS, deberá cambiar el valor
configurado en el sistema operativo.
v Si el mandato no incluye el nombre de dominio correcto, asegúrese de que la
conexión de red está correctamente configurada para resolver nombres de
dominio.
Nota: El mandato nslookup solo sirve para comprobar la resolución del nombre
de host en el servidor DNS. Si utiliza un archivo hosts, este mandato no
devuelve el nombre de dominio completo.
UNIX
Si los nombres de host no coinciden, utilice el mandato hostname
4.
para cambiar el valor configurado en el sistema operativo.
hostname nombre_nuevo
donde nombre_nuevo es el nombre del host nuevo.
Windows
Si utiliza un servidor DNS, verifique el método para resolver el
5.
nombre de dominio.
a. Haga clic en Inicio -> Configuración -> Panel de control -> Conexiones de
red.
b. Haga clic con el botón derecho del ratón en la conexión de área local y, a
continuación, haga clic en Propiedades.
c. Seleccione Protocolo de Internet (TCP/IP) y, a continuación, haga clic en
Propiedades.
d. Haga clic en Avanzadas.
e. Haga clic en el separador DNS.
f. Si Anexar estos sufijos DNS está seleccionado, asegúrese de que el nombre
de dominio aparezca al principio de la lista de sufijos DNS. Si no está
incluido en la lista, haga clic en Agregar para agregar el nombre de dominio
y haga clic en el botón de flecha hacia arriba para colocarlo al principio de
la lista.
g. Haga clic en Aceptar.
Windows
Verifique la información sobre nombre de sistema:
6.
a. En el escritorio de Windows, haga clic con el botón derecho del ratón en Mi
PC y luego haga clic en Propiedades.
b. Haga clic en el separador Nombre de equipo.
c. Compruebe que el campo Nombre completo de equipo muestra el nombre
de dominio completo del sistema. Por ejemplo, mycomputer.example.com.
d. Si necesita modificar el nombre, realice los siguientes pasos:
1) Haga clic en Cambiar.
Capítulo 3. Tareas previas a la migración
65
2) En la ventana Cambios en el nombre de equipo, verifique que el campo
Nombre de equipo contiene el nombre de host correcto. Por ejemplo,
mycomputer.
3) Haga clic en Más.
4) En la ventana Sufijo DNS y nombre NetBIOS del equipo, asegúrese de
que se ha configurado el sufijo del nombre de dominio correcto. Por
ejemplo, example.com.
5) Haga clic en Aceptar y cierre las otras ventanas.
Resolución de nombres de host con un archivo hosts
Si utiliza un archivo hosts para resolver direcciones IP, el archivo debe estar
correctamente configurado. El archivo se encuentra normalmente en: Windows
C:\WINDOWS\system32\drivers\etc\hosts
UNIX
Linux
/etc/hosts
Compruebe que puede ejecutar el mandato ping localhost correctamente. Si
recibe un error, es posible que haya un problema con el formato del archivo hosts.
El archivo debe incluir la información siguiente en el orden especificado:
v La dirección IP, el nombre de dominio completo y el nombre de host del sistema
en el que ejecuta el instalador como primera entrada.
v La dirección IP 127.0.0.1, el nombre de dominio completo
localhost.localdomain y el nombre de host localhost
v
Generalmente, existe una entrada127.0.0.2 en el archivo
/etc/hosts en los sistemas SUSE Linux. Debe comentar dicha entrada.
UNIX
Linux
Asegúrese de que el archivo /etc/hosts incluya la
Nota:
dirección IP estática para localhost y el nombre de host real del sistema.
Por ejemplo, para un sistema con el nombre de host river, el contenido del
archivo es el siguiente:
#IP address Fully Qualified Domain Name
10.0.0.12
river.example.com
127.0.0.1
localhost.localdomain
Short Name
river
localhost
Configuración remota de las topologías de varios servidores
Si utiliza una topología de varios servidores, la instalación de servicios básicos
utiliza RXA (Remote Execution and Access) para configurar el middleware. Para
utilizar RXA, debe habilitar un protocolo de acceso remoto soportado en cada
sistema donde desee instalar middleware y debe configurar un usuario
administrativo en cada sistema para el acceso remoto.
v En una configuración remota no se da soporte al acceso a unidades de red en el
sistema local o remoto.
66
v
Windows
Debe utilizar un nombre de usuario con acceso administrativo para
conectarse al sistema.
v
El protocolo de acceso remoto debe ser SMB. Asegúrese de que se
hayan habilitado los protocolos predeterminados:
– Clientes para redes Microsoft o el servidor equivalente
– Compartir archivos e impresoras para redes Microsoft
Windows
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v
Windows
Cygwin SSH no está soportado. Si Cygwin está instalado en un
sistema Windows remoto, debe detenerse el daemon SSH. Para detener SSH,
ejecute: cygrunsrv --stop sshd
v
Windows
Si utiliza un cortafuegos, los puertos 137 (servicio de nombres de
NetBIOS) y 139 (sesión de NetBIOS) no pueden estar bloqueados.
v
RXA requiere acceso al compartimiento de disco administrativo
remoto oculto para poder acceder al directorio %TEMP% del sistema y a otros
directorios para garantizar un funcionamiento correcto. También es necesario el
acceso a IPC$ (Interprocess Communications Share) para que RXA pueda
acceder a los registros remotos.
v
AIX
Las instalaciones predeterminadas de los sistemas AIX puede que no
incluyan el protocolo adecuado y deberán tener un protocolo compatible
habilitado.
v
El nombre de usuario root y la contraseña son necesarios para la
conexión remota. Asegúrese de que el usuario root tenga permiso de acceso a los
sistemas remotos con SSH.
Windows
UNIX
Requisitos de redes y puertos
v
Windows
Si desea dar soporte al direccionamiento IPv6 en Tivoli Provisioning
Manager, debe estar instalado Cygwin 1.7 o superior.
v Si servidor de suministro se instalará en plataformas UNIX o Linux que
requieren una estación de trabajo administrativa o si piensa instalar servicios
básicos en un sistema diferente, verifique los valores de los puertos de servidor
de suministro y del sistema donde instalará los servicios básicos. En ambos
sistemas, asegúrese de que coincidan los valores de velocidad de puerto de la
tarjeta de interfaz de red y el conmutador de puerto. Si los valores no coinciden,
la transferencia de archivos entre los sistemas durante la instalación puede fallar.
Se recomienda establecer la velocidad de puerto en comunicaciones
bidireccionales en la tarjeta de interfaz de red y en el conmutador de puerto.
Valores de velocidad de soportes de redes
Windows
1. Abra el gestor de dispositivos ejecutando el mandato siguiente: devmgmt.msc
desde el menú Inicio → Ejecutar.
2. Haga clic con el botón derecho en Adaptadores de red y seleccione
Propiedades.
3. Bajo el separador Avanzados, establezca la velocidad de los puertos.
AIX
1. Ejecute el mandato smitty.
2. Seleccione Dispositivos → Comunicación → Adaptador Ethernet → Adaptadores
→ Cambiar / Mostrar características de un sistema de archivos de diario.
3. Seleccione el adaptador correcto.
4. Seleccione Velocidad de soporte y cámbielo por Auto_Negotiation.
v Asegúrese de que el archivo /platform/sun4u/kernel/drv/bge.conf incluye el
contenido siguiente:
Capítulo 3. Tareas previas a la migración
67
adv_autoneg_cap=0
adv_1000fdx_cap=0
adv_1000hdx_cap=0
adv_100fdx_cap=1
adv_100hdx_cap=0
adv_100T4_cap=0
adv_10fdx_cap=0
adv_10hdx_cap=0;
Linux
v Utilice el mandato ethtool. Por ejemplo:
ethtool -s <nombre_adaptador> speed 100 duplex full
Requisitos de puertos dinámicos
Verifique la asignación de los puertos dinámicos:
1. En un indicador de mandatos, ejecute:
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
2. En la salida, compruebe el valor de puerto de inicio. Si se listan números de
puertos están en el rango de 9000 a 10000, cambie el valor del puerto de inicio
ejecutando:
netsh int <ipv4|ipv6> set dynamic <tcp|udp> start=número num=rango
donde número es el número de puerto de inicio y rango es el número total de
puertos. Asegúrese de que no establece el número de puerto de inicio en un
valor dentro del rango de 9000 a 10000, ya que los puertos de este rango los
utiliza WebSphere Application Server.
Los puertos que se listan en esta tabla deben estar disponibles. Para comprobar la
disponibilidad de los puertos, ejecute netstat -a. En la lista de conexiones y
puertos de escucha que se muestra, verifique que no figuren los puertos necesarios.
Nota: Si se emite un mandato PING desde la estación de trabajo administrativa
durante la instalación deberá recibir una respuesta de cada servidor implicado en
el despliegue. Asegúrese de que cada servidor de host de middleware esté
configurado para responder a las solicitudes PING.
Tabla 38. Puertos de comunicación utilizados por Tivoli Provisioning Manager. En la columna Dirección, la flecha
apunta desde el puerto de origen al puerto de destino.
Uso
Protocolo
Puerto del servidor de
suministro
Dirección
Puerto del sistema gestionado
El gestor de agentes
TCP
9511, 9512, 9513
→
cualquiera
BootDiscovery
UDP
(multidifusión)
4011
←
cualquiera
DCHP REPLY
UDP
67
→
68
DHCP REQUEST
UDP (difusión)
67
←
cualquiera
IP:233.1.0.1
Puerto daemon de
administración del
servidor de directorios
3538
Puerto daemon seguro
de administración del
servidor de directorios
3539
68
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 38. Puertos de comunicación utilizados por Tivoli Provisioning Manager (continuación). En la columna
Dirección, la flecha apunta desde el puerto de origen al puerto de destino.
Puerto del servidor de
directorios
389
Puerto seguro del
servidor de directorios
636
Base de datos Eclipse
incluida
TCP
1527
←
cualquiera
FASTPort
UDP
4025
←
cualquiera
FileServerPort
UDP
4013
←
cualquiera
FileMCAST-Address
UDP
cualquiera
→
10000
HTTPServer
80 (9080)
MTFTPPort
UDP
4015
←
cualquiera
MTFTPClients
UDP
(multidifusión)
cualquiera
→
8500
NBPServer
UDP
4012
←
cualquiera
Servicio de nombres
NetBIOS
TCP
137
←
→
137
IP:233.1.0.1
Utilizado durante la instalación.
En topologías de varios
servidores, habilite el puerto en
un servidor de bases de datos
remoto o en un servidor de
directorios remoto.
Oracle
1521
PROXY DHCP
UDP
4011
←
cualquiera
SMB/NetBIOS
TCP
cualquiera
→
139
SNMP
UDP
cualquiera
→
161
SNMP-TRAP
UDP
162
←
cualquiera
SSH
TCP
cualquiera
→
22
Telnet
TCP
23
←
cualquiera
TFTP
UDP
69
←
cualquiera
TS
TCP
cualquiera
→
3389
WebSphere Application
Server
TCP
8881, 9082, 9045, 9046,
9443
→
cualquiera
Puerto SOAP de
WebSphere Application
Server
8879
Puerto seguro de la
consola de
administración de
WebSphere Application
Server
9043, 9044
Consola administrativa
de WebSphere
Application Server
9060, 9061
Puerto del servidor web
9430
Capítulo 3. Tareas previas a la migración
69
Tabla 38. Puertos de comunicación utilizados por Tivoli Provisioning Manager (continuación). En la columna
Dirección, la flecha apunta desde el puerto de origen al puerto de destino.
Puerto de la instancia de
base de datos
50005
UNIX
Linux
SSH
Asegúrese de que se cumplen los siguientes requisitos:
1. El archivo /etc/ssh/sshd_config existe. Este archivo contiene valores de
configuración de SSH que se utilizan para validar otros requisitos de SSH para
la instalación.
2. Se permite el acceso root mediante el daemon SSH (sshd). En
/etc/ssh/sshd_config, asegúrese de que PermitRootLogin esté establecido en
yes.
3. SSH debe estar ejecutándose para poder realizar la instalación. Para comprobar
el estado de SSH, ejecute ps -ef | grep sshd. Si se está ejecutando SSH, se
muestra una entrada para /usr/sbin/sshd.
AIX
Utilizando una sesión X
Si desea ejecutar de forma remota la instalación en AIX utilizando una sesión X
desde un sistema Windows, debe utilizar software X que dé soporte a la
visualización del instalador. El software Cygwin X no da soporte a la visualización
del instalador. Como alternativa, puede utilizar VNC. Para configurar VNC en el
sistema:
1. Descargue el paquete VNC desde http://www-03.ibm.com/systems/power/
software/aix/linux/toolbox/download.html.
2. Instale el paquete ejecutando el mandato: rpm -ivh nombre_paquete, donde
nombre_paquete es el nombre del paquete que ha descargado.
3. Inicie una sesión como el usuario que se conectará a VNC.
4. Inicie el servidor VNC. VNC le solicita la contraseña para una conexión VNC.
Deberá ajustar la profundidad de color y la resolución con las opciones -depth
y -geometry. Por ejemplo, Firefox en AIX requiere una profundidad de color de
24 bits o superior. Una profundidad de color menor generará anomalías del
navegador. La opción de geometría debe establecerse de modo que el tamaño
de la ventana de VNC sea el adecuado para los valores de la tarjeta de vídeo y
pantalla actuales. El siguiente mandato establece la profundidad de color en 24
bits y la resolución en 1280 por 1024.
/usr/bin/X11/vncserver -depth 24 -geometry 1280x1024
Para conectar con el escritorio de VNC en AIX desde un sistema Windows:
v Utilizando HTTP:
1. Abra un navegador web.
2. Vaya al URL:
http://nombre_host:5801
v Utilizando el cliente de VNC:
1. Instale el cliente de VNC.
2. Ejecute el cliente de VNC y escriba:
nombre_host:número_puerto
70
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
donde nombre_host es el nombre de host del sistema AIX. El número de puerto
predeterminado para la conexión es 5801. Encontrará el número de puerto en
$HOME/.vnc/nombre_host:número_visualización.log
También puede acceder al escritorio de VNC utilizando otros clientes VNC.
UNIX
Linux
Soporte de instalación
La instalación desde imágenes almacenadas en una unidad montada de solo
lectura no está soportada.
Software antivirus o software con muchos procesos
Busque en los sistemas de la topología de instalación los procesos que consuman
muchos recursos del sistema como, por ejemplo, una exploración de antivirus
planificada. Estos procesos pueden hacer que algunas operaciones de instalación
excedan el tiempo de espera. Detenga o vuelva a planificar estos procesos antes de
iniciar la instalación.
Inicio del Launchpad
El Launchpad le permite instalar todo el software y los componentes necesarios
para Tivoli Provisioning Manager.
Antes de empezar
Linux
Si está utilizando Firefox para ejecutar el Launchpad, establezca la
variable de entorno BROWSER:
v
Puede agregar este mandato a .bash_profile para el usuario root.
Por ejemplo, export BROWSER=/usr/bin/firefox.
v
Cree un archivo denominado /root/.bashrc y agregue la línea
export al archivo.
Para iniciar el Launchpad:
1.
Windows
Inicie sesión con una cuenta con privilegios de administración del
sistema.
UNIX
2.
Linux
Inicie la sesión como root.
Windows
Si utiliza los DVD, inserte el DVD de Instalación de Windows. El
disco debe estar insertado mientras dura todo el proceso de instalación.
Si está utilizando los DVD, inserte el DVD de Instalación
en UNIX y Linux y monte la unidad de DVD. El DVD debe estar insertado
mientras dura todo el proceso de instalación. No cambie el directorio en el
punto de montaje, porque esto bloquea la unidad de DVD e impide que se
cambien los discos. Asimismo, debe desmontar la unidad de DVD antes de
expulsar el DVD. De lo contrario, la bandeja de DVD permanece bloqueada y
no puede cambiar los discos.
UNIX
Linux
Los pasos siguientes proporcionan información acerca de cómo montar una
unidad de DVD.
AIX
En los pasos siguientes, se utiliza /cdrom como punto de montaje de
la unidad de DVD.
Capítulo 3. Tareas previas a la migración
71
a. Si hay actualmente un disco en la unidad, desmonte la unidad montada
actualmente y retire el disco:
eject /cdrom
b. Inserte el DVD de Instalación en UNIX y Linux en la unidad de DVD.
c. Para comprobar que el DVD se ha montado automáticamente, liste los
archivos en el punto de montaje:
ls /cdrom
d. Si no aparecen los archivos en el DVD, siga estos pasos:
1) Si el directorio del punto de montaje no existe, créelo:
mkdir /cdrom
2) Monte el pack de unidades de forma manual:
mount -rv cdrfs /dev/cd0 /cdrom
e. Desmonte el DVD:
umount /cdrom
En los pasos siguientes, se utiliza /mnt/cdrom como punto de montaje
de la unidad de DVD.
Linux
a. Si hay actualmente un disco en la unidad, desmonte la unidad montada
actualmente y retire el disco:
eject /mnt/cdrom
b. Inserte el DVD de Instalación en UNIX y Linux en la unidad de DVD.
c. Para comprobar que el DVD se ha montado automáticamente, liste los
archivos en el punto de montaje:
ls /mnt/cdrom
d. Si no aparecen los archivos en el DVD, siga estos pasos:
1) Si el directorio del punto de montaje no existe, créelo:
mkdir /mnt/cdrom
2) Monte la unidad de DVD manualmente:
mount -t iso9660 /dev/cdrom /mnt/cdrom
e. Desmonte el DVD:
umount /mnt/cdrom
En los pasos siguientes, se utiliza /cdrom como punto de montaje de
la unidad de DVD.
a. Si hay actualmente un disco en la unidad, desmonte la unidad montada
actualmente y retire el disco:
eject /cdrom
b. Inserte el DVD de Instalación en UNIX y Linux en la unidad de DVD.
c. Para comprobar que el DVD se ha montado automáticamente, liste los
archivos en el punto de montaje:
ls /cdrom
d. Si no aparecen los archivos en el DVD, siga estos pasos:
1) Si el directorio del punto de montaje no existe, créelo:
mkdir -p /cdrom
2) Busque el nombre de la unidad de DVD:
iostat -En
3) Monte la unidad de DVD manualmente:
mount -F hsfs -o ro /dev/dsk/<nombre_unidad> /cdrom
e. Desmonte el DVD:
72
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
umount /cdrom
3.
Windows
Ejecute el Launchpad desde el directorio raíz:
launchpad.exe
4.
UNIX
Ejecute el Launchpad fuera del punto de montaje de DVD:
Linux
/cdrom/launchpad.sh
donde /cdrom es el punto de montaje de DVD.
AIX
Si el navegador predeterminado es Firefox, es posible que el
Launchpad no se ejecute correctamente debido a la interfaz del shell ksh. Para
utilizar el Launchpad con el navegador Firefox:
a. Copie todos los archivos del DVD de Instalación en UNIX y Linux en un
directorio local, por ejemplo, /user_dir. Si ha descargado las imágenes de
instalación, en lugar de utilizar los DVD, descargue y extraiga las imágenes
de instalación.
b. Abra /user_dir/launchpad/Firefox.sh y elimine las líneas siguientes:
typeset +r LOGNAME 2>/dev/null
LOGNAME=lp_user_$$; export LOGNAME
c. Ejecute el Launchpad desde /user_dir.
5. En el Launchpad, seleccione un idioma y haga clic en Aceptar.
Resultados
Se muestra el panel del Launchpad.
Cuando se ejecuta un launchpad, los mensajes del launchpad generados se
capturan en un marco de registro oculto. Para mostrar el marco de registro en la
parte inferior de los paneles del launchpad durante la ejecución, mantenga pulsado
Control y haga clic en el marco del mensaje de cabecera del launchpad. Los
mensajes que se generan cuando se ejecuta el launchpad no se guardan
automáticamente en la unidad de disco duro. Para guardar manualmente los
mensajes de una sesión de tiempo de ejecución, haga clic en Guardar en la parte
inferior del marco de registro y especifique dónde desea guardar el archivo.
Instalación del middleware en Windows, AIX y Linux
Antes de instalar Tivoli Provisioning Manager, debe desplegar varios productos de
middleware.
El instalador de middleware proporciona una interfaz para instalar y desplegar el
middleware de un modo fiable. La tabla siguiente describe las opciones de
despliegue de middleware:
Tabla 39. Opciones de instalación de middleware
Aplicación
Opciones de instalación
Servidor de
aplicaciones
Debe instalar una instancia nueva de WebSphere Application
Server 6.1.0.23. Si desea utilizar un WebSphere Application Server
existente, debe instalarlo y configurarlo manualmente.
El despliegue del servidor de aplicaciones debe protegerse con un
servidor de directorios. Debe elegir utilizar un Tivoli Directory
Server o un Microsoft Active Directory local o remoto.
Capítulo 3. Tareas previas a la migración
73
Tabla 39. Opciones de instalación de middleware (continuación)
Aplicación
Opciones de instalación
Servidor de bases de
datos
DB2
Puede instalar una instancia nueva de DB2 o utilizar una
instancia existente.
Base de datos de Oracle
La base de datos Oracle sólo está soportada para UNIX y
Linux. Debe instalar y configurar manualmente la base de
datos Oracle.
Servidor de
directorios
Tivoli Directory Server
Puede instalar una nueva instancia de Tivoli Directory
Server o utilizar una instancia existente.
Si elige instalar una nueva instancia de Tivoli Directory
Server, debe elegir instalar una nueva instancia de DB2 o
reutilizar un servidor de DB2 existente. De manera
alternativa, puede utilizar el servidor de bases de datos de
Tivoli Provisioning Manager para el almacén de datos de
DB2, si el servidor de bases de datos de Tivoli
Provisioning Manager utiliza DB2. Si elige instalar el
servidor de directorios, pero no el servidor de bases de
datos, el instalador de middleware intentará ubicar una
instancia de base de datos existente para su uso. Si no
puede ubicar una instancia existente, instalará una base de
datos para su uso con el servidor de directorios.
Microsoft Active Directory
Debe instalar y configurar el software manualmente.
Software adicional
El instalador de middleware realiza varias tareas adicionales. Si no
va a utilizar el instalador de middleware y configurará
manualmente los recursos de middleware existentes, también debe
realizar las tareas siguientes:
v Configure VMM una vez instalados y configurados el servidor
de aplicaciones y el servidor de directorios. El servidor de
directorios contiene información acerca de los usuarios y grupos
de Tivoli Provisioning Manager y comunica esta información a la
base de datos Maximo utilizando VMM para proporcionar
seguridad y acceso a las aplicaciones de Tivoli Provisioning
Manager. Para obtener más información, consulte Configuración
manual de Virtual Member Manager en WebSphere Application
Server.
v Configure los servicios de autenticación. Para obtener más
información, consulte Configuración manual del servicio de
autenticación .
El instalador de middleware despliega el software en el sistema donde se está
ejecutando. Para desplegar el middleware en diferentes sistemas, el instalador de
middleware se debe ejecutar en cada sistema de la topología que haya elegido.
Asegúrese de tener una estrategia para desplegar el middleware de cada uno de
los sistemas que tenga previsto utilizar en el despliegue. Si despliega un
componente utilizando el instalador de middleware en un sistema, por ejemplo,
DB2, y decide más adelante que también desea agregar Tivoli Directory Server al
mismo sistema, deberá anular el despliegue de DB2 antes de volver a desplegarlo
en el mismo plan de despliegue del instalador de middleware que incluye Tivoli
74
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Directory Server. Cuando se instala el middleware de Tivoli Provisioning Manager
en un sistema, debe instalar a la vez todo el middleware previsto para el sistema.
Cada vez que se utiliza el instalador de middleware para instalar o desinstalar un
conjunto de productos de middleware, se genera un ID de proceso. El ID de
proceso aparecerá en el sistema de archivos en varios lugares relacionados con los
registros y los archivos generados como, por ejemplo, los nombre de archivo, los
nombres de directorio y los mensajes de registro. El ID de proceso se utiliza para
agrupar los registros y otros archivos generados que están relacionados con la
misma invocación del instalador de middleware. También separa los registros y
otros archivos generados que están relacionados con otras invocaciones del
instalador de middleware. El ID de proceso es una cadena con el formato
[operación_MMdd_HH.mm], donde operación es una cadena que indica la
operación que se está realizando, por ejemplo, ″INSTALL″ o ″UNINSTALL″, MM
es un número de dos dígitos (1-12) que indica el mes actual, dd es un número de
dos dígitos (1-31) que indica el día actual del mes, HH es un número de dos
dígitos (0-23) que indica la hora actual y mm es un número de dos dígitos (0-59)
que indica el minuto actual. A continuación, se proporcionan algunos ejemplos de
valores de ID de proceso:
v [INSTALL_0924_15.45]
Una instalación iniciada el 24 de septiembre a las 15:45
v [UNINSTALL_1216_09.59]
Una desinstalación iniciada el 16 de diciembre a las 9:59
Planificación de la hoja de trabajo de middleware
Estas tablas incluyen los valores que debe proporcionar cuando se instala el
middleware. Aunque pueden aceptarse muchos de los valores predeterminados
cuando se navega por los paneles del instalador de middleware, puede revisar esta
hoja de trabajo si tiene previsto configurar manualmente o reutilizar el middleware
existente. En un caso de ejemplo de despliegue de varios sistemas, deberá tener en
cuenta varios valores.
Tabla 40. Lista de usuarios y grupos creados durante la instalación
Usuario
db2admin
Grupo
Descripción
Administrador de DB2. ID de usuario
de servicio Windows.
Windows
v DB2USERS
v DB2ADMNS
idsccmdb
El instalador de middleware creará este
usuario si no existe todavía.
Usuario de IBM Tivoli Directory Server.
Windows
v Usuarios
v Administradores
AIX
Su valor
Este usuario lo creará el programa de
instalación del middleware si todavía
no existe.
Linux
v idsldap
v db2iadm1
maximo
v Usuarios
v Administradores
Se utiliza para la configuración de base
de datos de maximo.
Este usuario lo creará el programa de
instalación si todavía no existe.
Capítulo 3. Tareas previas a la migración
75
Tabla 40. Lista de usuarios y grupos creados durante la instalación (continuación)
Usuario
Grupo
ctginst1
Descripción
Su valor
El usuario del sistema que se utiliza
como propietario de instancia de base
de datos en las plataformas UNIX.
Windows
v Usuarios
v Administradores
AIX
El instalador de middleware creará este
usuario si no existe todavía.
Linux
v ctginst1 debe ser miembro de
db2iadm1 con los grupos
secundarios de personal y
dasadm1
db2fenc1
UNIX
Linux
db2fgrp1
El usuario del sistema UNIX que se
utiliza como ID de usuario de barrera
para DB2.
El instalador de middleware creará este
usuario si no existe todavía.
wasadmin
Un usuario que no sea el usuario Este es un ID de usuario que se crea
del sistema.
para su uso con WebSphere.
El instalador de middleware creará este
usuario si no existe todavía.
Tabla 41. instalador de middleware
Configuración
Valor predeterminado
Directorio del espacio de trabajo
<directorio padre de
usuario>\ibm\tivoli\mwi\workspace
Su valor
Directorio de origen de imágenes de
middleware
Directorio de imágenes comprimidas
Directorio de imágenes extraídas
Tabla 42. Configuración de DB2
Configuración
Valor predeterminado
Directorio de instalación
v
v
Windows
Unidad_sistema:\
Archivos de programa\IBM\SQLLIB
AIX
/opt/IBM/db2/V9.5
v
v
Usuario de DAS
Linux
/opt/ibm/db2/V9.5
Linux
en IBM System z:
/opt/IBM/db2/V9.5
Windows
db2admin
UNIX y Linux
dasusr1
Usuario de barrera
76
UNIX y Linux
db2fenc1
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Su valor
Tabla 42. Configuración de DB2 (continuación)
Configuración
Nombre de grupo de usuario de
barrera
Directorio padre de usuario de
barrera
Valor predeterminado
UNIX y Linux
db2fgrp1
UNIX y Linux
/home/db2fenc1
Nombre de la instancia
ctginst1
Puerto
50005
Directorio padre de nombre de
usuario de la instancia
ID de usuario de instancia de base
de datos
Su valor
UNIX y Linux
/home/ctginst1
Windows
db2admin
UNIX y Linux
ctginst1
Grupo de administradores de DB2
Windows
DB2ADMNS
UNIX y Linux
db2iadm1
Grupo de usuarios de DB2
Windows
DB2USERS
Utilice el mismo nombre de usuario
y la misma contraseña para los
restantes servicios de DB2
SÍ
Configurar catálogo de herramientas
NO
Este valor sólo es relevante para los
casos de ejemplo de reutilización.
Habilitar seguridad de O/S para los
objetos de DB2
SÍ
Este valor sólo es relevante para los
casos de ejemplo de reutilización.
Puerto de instancia de DB2
Nombre de espacio de tabla de datos MAXDATA
Tamaño de espacio de tabla de datos
5000 Mb
Nombre de espacio de tabla temporal MAXTEMP
Tamaño de espacio de tabla temporal 1000 Mb
Capítulo 3. Tareas previas a la migración
77
Tabla 43. Configuración de Oracle
Configuración
Valor predeterminado
Directorio de instalación
v
UNIX
Su valor
Linux
/u01/app/oracle/
product/10.2.0/db_1 (para
Oracle 10g)
UNIX
v
Linux
/u01/app/oracle/
product/11.1.0/db_1 (para
Oracle 11g)
ID de usuario administrador sys
ID de propietario de
software de Oracle
UNIX
Ubicación de la instancia
UNIX
v
Linux
oracle
Linux
/u01/app/oracle/
product/10.2.0/db_1 (para
Oracle 10g)
UNIX
v
Linux
/u01/app/oracle/
product/11.1.0/db_1 (para
Oracle 11g)
Nombre del espacio de
tablas de datos
MAXDATA
Tamaño de espacio de tabla
de datos
1000 Mb
Nombre de espacio de tabla
temporal
MAXTEMP
Tamaño de espacio de tabla
temporal
1000 Mb
Tabla 44. Configuración de WebSphere Application Server
Configuración
Valor predeterminado
Directorio de instalación
v
v
Windows
C:\Archivos de
programa\IBM\WebSphere\
AppServer
AIX
/usr/IBM/WebSphere/
AppServer
Linux
v
/opt/IBM/WebSphere/AppServer
Nombre de usuario de
administración de WebSphere
wasadmin
Nombre de perfil del gestor de
despliegue
ctgDmgr01
Nombre de perfil del servidor de
aplicaciones
ctgAppSrv01
78
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Su valor
Tabla 44. Configuración de WebSphere Application Server (continuación)
Configuración
Valor predeterminado
Su valor
Directorio del perfil
v /usr/IBM/WebSphere/AppServer/
profiles
Linux
v
/opt/IBM/WebSphere/AppServer/
profiles
Nombre de célula
ctgCell01
Nombre de nodo del gestor de
despliegue
ctgCellManager01
Nombre de nodo del servidor de
aplicaciones
ctgNode01
Ubicación de instalación del servidor
v
HTTP
Windows
C:\Archivos de
programa\IBM\HTTPServer
AIX
v
/usr/IBM/HTTPServer
Linux
v
/opt/IBM/HTTPServer
Puerto HTTP
80
Windows
Es posible que este
Nota:
puerto ya se esté utilizando.
Asegúrese de que libera este puerto o
que utiliza otro puerto que no esté
asignado.
Puerto del servidor de
administración HTTP
8008
Nombre de perfil del plug-in HTTP
ctgAppSrv01
Tabla 45. Configuración de IBM Tivoli Directory Server
Configuración
Valor predeterminado
Directorio de instalación
v
Su valor
Windows
C:\Archivos de
programa\IBM\LDAP\V6.2
UNIX
v
Linux
/opt/IBM/ldap/V6.2
Nombre distinguido del
administrador
cn=root
Unidad organizativa
ou=SWG
Sufijo de organización y país
o=IBM,c=US
Puerto del servidor de directorios
389
Puerto seguro del servidor de
directorios
636
Puerto de administración
3538
Puerto seguro de administración
3539
Nombre de la base de datos
seguridad
Nombre de la instancia
idsccmdb
Puerto de instancia
50006
Capítulo 3. Tareas previas a la migración
79
Tabla 45. Configuración de IBM Tivoli Directory Server (continuación)
Configuración
Valor predeterminado
Nombre de usuario de la instancia
idsccmdb
Su valor
Tabla 46. Configuración de Microsoft Active Directory
Configuración
Valor predeterminado
Puerto del servidor de directorios
389
Su valor
Entrada básica LDAP
Sufijo de usuario
Sufijo de grupo
Sufijo de contenedor de organización
Nombre distinguido del enlace
El espacio de trabajo del instalador de middleware
El instalador de middleware está diseñado para registrar las opciones seleccionadas
durante la instalación en un directorio conocido como workspace y, a continuación,
configurar los componentes seleccionados como una única aplicación desplegada.
Otros instaladores también pueden importar las opciones registradas, de forma que
algunos campos pueden rellenarse automáticamente.
Una vez desplegado un plan, el instalador de middleware no puede desplegar
productos y características adicionales en el sistema más adelante. Primero debe
eliminarse completamente el plan existente mediante el instalador de middleware
para poder desplegar un conjunto diferente de productos y características.
La composición y los detalles del despliegue, así como los registros generados por
el proceso del instalador de middleware se encuentran en el espacio de trabajo.
De forma predeterminada, el espacio de trabajo del instalador de middleware se
define como:
v
Windows
v
AIX
v
Linux
C:\ibm\tivoli\mwi\workspace
/ibm/tivoli/mwi/workspace
/root/ibm/tivoli/mwi/workspace
El espacio de trabajo puede definirse en un recurso compartido que estará
disponible para todos los sistemas que ejecutarán el instalador de middleware.
Ubicar el espacio de trabajo en un recurso compartido evita la necesidad de copiar
manualmente archivos como el archivo de topología de un sistema a otro.
El espacio de trabajo contiene los siguientes elementos:
Plan de despliegue
El plan de despliegue es un conjunto de pasos de instalación, parámetros
de configuración para dichos pasos e información del sistema de destino.
Se genera mediante el instalador de middleware y reside en el directorio
workspace.
Cuando se modifican los pasos del despliegue, el plan de despliegue
existente se suprime y se sustituye por el nuevo plan de despliegue.
Los archivos de configuración del plan de despliegue contienen
información sobre el propio plan de despliegue. Cuando se modifica un
80
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
plan de despliegue, lo que incluye reconfigurar las opciones de despliegue
existentes, los archivos de configuración del plan de despliegue se
suprimen y se vuelven a generar cuando se vuelve a desplegar el plan de
despliegue.
Archivo de topología
El archivo de topología describe los parámetros de configuración del
despliegue de middleware. Este archivo se crea y se actualiza después de
cada despliegue o anulación de despliegue. Si no ha definido un espacio
de trabajo ubicado centralmente que sea accesible para todos los sistemas
que vayan a recibir middleware, este archivo deberá copiarse en el espacio
de trabajo de cada sistema donde se esté desplegando el middleware. El
programa de instalación de Tivoli Provisioning Manager puede utilizar el
contenido de este archivo para rellenar los paneles con valores
predeterminados significativos.
Este archivo se guarda en <workspace>/topology.xml.
Registros
Los archivos de registro que contienen información sobre el despliegue
pueden encontrarse en el directorio workspace. Asimismo, los archivos de
registro que son nativos del middleware también están contenidos en este
directorio.
Los registros del instalador de middleware
Los archivos de registro del instalador de middleware se encuentran en el
directorio de espacio de trabajo que se ha definido en el programa de instalación
de middleware.
A continuación, se describen los distintos tipos de archivos de registro.
Registros de la interfaz de usuario
Los registros generados por la interfaz de usuario del programa de
instalación de middleware se encuentran en el directorio de espacio de
trabajo.
El programa de instalación de middleware registra toda la información en
<ubicación_espaciotrabajo>/mwi.log. Las ubicaciones predeterminadas de
los espacios de trabajo son:
Windows
C:\ibm\tivoli\mwi\workspace
Linux /root/ibm/tivoli/mwi/workspace
AIX
/ibm/tivoli/mwi/workspace
El archivo mwi.log es el archivo de registro de alto nivel que ha generado
la invocación más reciente del programa de instalación de middleware. Si
se produce un error, examine primero este archivo de registro. Una entrada
en este archivo de registro puede dirigirle a un archivo de registro de nivel
inferior.
Los archivos de registro llamados mwi.logX, donde X es un número, son
copias del archivo mwi.log de invocaciones anteriores del programa de
instalación de middleware. Así, mwi.log0, por ejemplo, se genera tras la
primera invocación del programa de instalación de middleware, mwi.log1
se genera tras la segunda invocación del programa de instalación de
middleware, y así sucesivamente.
Registros para los pasos ejecutados por la interfaz de usuario
Además de recopilar la entrada del usuario, la interfaz de usuario del
Capítulo 3. Tareas previas a la migración
81
programa de instalación de middleware también realiza varias
comprobaciones del sistema. Algunos ejemplos de las comprobaciones del
sistema ejecutadas por la interfaz de usuario son:
v comprobación de dependencia para garantizar que el sistema operativo
cumple los requisitos de despliegue
v inventario del software en el sistema para localizar las instancias
existentes de los productos de middleware desplegados por el programa
de instalación de middleware
v comprobación del espacio de disco disponible para asegurarse de que
hay suficiente espacio para el despliegue
Cada una de estas comprobaciones se realiza como un paso, para que
también se pueda ejecutar como parte del plan de despliegue. Cuando la
interfaz de usuario ejecuta un paso, copia el paso en un subdirectorio del
directorio de espacio de trabajo. Los archivos de registro generados por un
paso se encuentran en el mismo subdirectorio y siguen el mismo patrón
que un paso ejecutado como parte del plan de despliegue.
Registros del plan de despliegue
El plan de despliegue se encuentra en el directorio <Directorio
Espaciotrabajo>/nombre host/deploymentPlan, donde nombre host es el
nombre de host del sistema actual. Cada vez que se utiliza el plan de
despliegue para instalar o desinstalar los productos de middleware, se
asigna un ID de proceso y se generan archivos de registro.
Los archivos de registro del plan de despliegue se encuentran en el
subdirectorio logs/Idproceso. El archivo de registro principal del plan de
despliegue es DeploymentPlan.log, un archivo de registro de alto nivel que
incluye los pasos que se invocan como parte del plan de despliegue.
Registros del plan de la estación de trabajo
El plan de máquina se encuentra en el directorio <Directorio
Espaciotrabajo>/nombre host/deploymentPlan/MachinePlan_nombre host.
Los archivos de registro del plan de la máquina se encuentran en el
subdirectorio logs. Los archivos de registro principales del plan de
máquina se denominan MachinePlan_nombre host_IDproceso. Estos
archivos de registro contienen la salida generada por ANT cuando se
ejecuta el script ANT del plan de la máquina.
Registros para los pasos en el plan de despliegue
Cada paso del plan de despliegue se encuentra en un directorio llamado
<Directorio Espaciotrabajo>/nombre host/deploymentPlan/
MachinePlan_nombre host/númPaso_IDpaso, donde númPaso es el número de
secuencia de este paso en el orden de proceso de la instalación del plan de
despliegue e IDpaso identifica el paso. Los archivos de registro del paso se
encuentran en el subdirectorio logs.
Algunos pasos pueden proporcionar un archivo de registro de mensajes
denominado IDpaso_IDproceso.message, que contiene varias entradas que
resumen el resultado de invocar el paso. Todos los pasos proporcionarán
un archivo de registro de rastreo denominado IDpaso_IDproceso.log, que
contiene muchas entradas, que normalmente incluyen información sobre
los parámetros de entrada y los subpasos invocados.
Registros para los subpasos
Cada paso contiene uno o varios subpasos. Los subpasos realizan la
instalación, desinstalación y trabajo de comprobación reales para el
programa de instalación de middleware.
82
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Cada subpaso se encuentra en el directorio <Directorio
Espaciotrabajo>/nombre host/deploymentPlan/MachinePlan_nombre
host/númPaso_IDpaso/operación/númSubpaso_IDsubpaso, donde operación es
el destino ANT del script ANT de pasos que invoca el subpaso.
númSubpaso es el número de secuencia de este subpaso en el orden de
proceso del paso e IDsubpaso identifica el subpaso. Los valores típicos para
la operación son instalar, desinstalar y comprobar.
Los archivos de registro del subpaso se encuentran normalmente en un
subdirectorio denominado IDproceso/logs.
Los archivos de registro generados por los programas nativos e instalación
del middleware también se guardarán aquí.
Por ejemplo, el archivo de registro generado por el programa de instalación de
middleware durante la instalación de DB2 en un sistema UNIX se encontrarían en
el siguiente directorio: <espaciotrabajo>/<nombre_máquina>/deploymentPlan/
MachinePlan_<nombre_máquina>/000XX_DB2_9.5/install/01_BASE/
<Indicación_Fechahora>/logs/db2setup.log
Instalación del middleware con el instalador de middleware
En este procedimiento se explica cómo utilizar el instalador de middleware para
crear un plan de despliegue que sea responsable de instalar y configurar los
productos de middleware de requisito previo.
Antes de empezar
v Utilice siempre nombres de dominio completos cuando especifique valores para
los nombres de host. Para UNIX y Linux, asegúrese de que el mandato hostname
-f devuelva un nombre de host completo. Si no es así, consulte la
documentación del sistema operativo. Para Windows, asegúrese de que haya un
sufijo de DNS primario de Windows definido. Para verificar un nombre de host
completo:
1. En el escritorio, haga clic con el botón derecho en Mi PC y haga clic en
Propiedades.
2. En el separador Nombre de equipo, haga clic en Cambiar.
3. Escriba el nombre de host completo en el campo Nombre de equipo y luego
haga clic en Más.
4. Verifique que el campo Sufijo de DNS primario muestre el nombre de
dominio y haga clic en Aceptar.
5. En el panel Cambios de nombre de equipo, haga clic en Aceptar y luego en
Aplicar.
v Puede forzar el uso de nombres de host alfanuméricos en el programa de
instalación de middleware invocándolo desde la línea de mandatos y utilizando
el parámetro forceHostname=true. Por ejemplo:
mwi-console -V forceHostname=true
v Cuando instale y configure middleware, tenga en cuenta las siguientes
restricciones sobre caracteres especiales:
Capítulo 3. Tareas previas a la migración
83
Nombre
Restricción
Convenios de denominación de DB2 para
Los nombres de grupo y los ID de grupo en
nombres de grupo, nombres de usuario e ID los sistemas operativos Linux y UNIX
de grupo.
pueden contener un máximo de 8 caracteres
y solo pueden contener caracteres en
minúsculas.
Los nombres de grupo y los nombres de
usuario en Windows pueden contener un
máximo de 30 caracteres.
Los nombres e ID no pueden tener ninguno
de los siguientes valores : USERS, ADMINS,
GUESTS, PUBLIC, LOCAL o cualquier
palabra reservad de SQL.
Los nombres y los ID no pueden comenzar
por IBM, SQL ni SYS. Tampoco pueden
empezar por el carácter de subrayado (_).
Convenios de denominación de DB2 para
instancias de DB2.
Los nombres de instancia pueden contener
hasta 8 caracteres.
En Windows, ninguna instancia puede tener
el mismo nombre que un servicio.
Convenios de denominación de DB2 para
contraseñas.
Para sistemas UNIX, las contraseñas pueden
tener un máximo de ocho caracteres.
Para sistemas Windows, las contraseñas
pueden tener un máximo de 14 caracteres.
Convenios de IBM Tivoli Directory Server
para bases de datos y alias de bases de
datos.
Los nombres de base de datos deben ser
exclusivos en la ubicación en la que se
catalogan. Para Linux y UNIX, esta
ubicación es una vía de acceso a directorio,
Para Windows es un disco lógico.
Los nombres de alias de base de datos
deben ser exclusivos en el directorio de base
de datos del sistema. Cuando se crea una
nueva base de datos, el alias toma el nombre
de la base de datos de forma
predeterminada. Como resultado, no puede
crear una base de datos utilizando un
nombre que exista como alias de base de
datos, aunque no haya ninguna base de
datos con ese nombre.
Los nombres de base de datos y de alias de
base de datos pueden tener hasta ocho
caracteres.
Tenga en cuenta que caracteres especiales @,
# y $ no son comunes a todos los teclados y
se deben evitar cuando se crea un nombre
de base de datos.
84
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nombre
Restricción
Convenios de IBM Tivoli Directory Server
para usuarios, grupos, bases de datos e
instancias
Los valores no deben superar los ocho
caracteres.
Los valores no pueden ser los siguientes:
USERS, ADMINS, GUESTS, PUBLIC,
LOCAL, idsldap
Los valores no pueden empezar por IBM,
SQL, ni SYS.
Los valores no deben incluir caracteres
acentuados.
Los valores pueden incluir caracteres de la A
a la Z, de la a a la z y del 0 al 9.
Los valores deben empezar por caracteres de
la A a la Z o de la a a la z.
No se pueden utilizar caracteres de doble
byte en valores de contraseñas de usuario.
Las contraseñas no pueden contener los
siguientes caracteres especiales: ` ’ \ ″ |
Convenios de WebSphere Application Server El nombre del administrador no puede
contener los siguientes caracteres: / \ * ,:
;=+?|< > & % ’″] [> # $ ~ ( )
El nombre del administrador no puede
empezar por un punto.
El nombre del administrador no puede
empezar ni termina por un espacio.
La contraseña del administrador debe
contener ocho caracteres.
Programa de instalación de middleware
El programa de instalación middleware no
valida que la contraseña cumpla con el
sistema operativo del host de destino, de
modo que debe asegurarse de que los
valores de contraseña que especifique sean
válidos para el entorno.
No puede utilizar el carácter ’%’ en
Windows ni los caracteres !, $, #, % en
UNIX.
El programa de instalación de middleware
no comprueba si hay caracteres acentuados
en los valores de nombre de usuario. Si se
utilizan caracteres acentuados pueden
producirse errores.
v Cuando especifique valores de LDAP para campos del panel de instalación de
Provisioning Manager, entradas en archivos LDIF o valores que especifique
directamente en una instancia de directorio utilizando las herramientas propias
del servidor de directorios, tenga en cuenta las reglas de sintaxis específicas del
producto sobre el uso de caracteres especiales en una cadena de caracteres de
LDAP. En la mayoría de los casos, los caracteres especiales deben ir precedidos
de un carácter de escape para que el servidor de directorios pueda leerlos. Si no
Capítulo 3. Tareas previas a la migración
85
se agrega el carácter de escape a los caracteres especiales contenidos en una
cadena LDAP que se utiliza con Provisioning Manager, se producirán errores de
Provisioning Manager.
Muchos productos de servidores de directorios consideran el carácter en blanco
como un carácter especial que forma parte de la cadena LDAP. Por lo tanto, si
especifica por error una cadena LDAP que contiene un espacio en blanco, por
ejemplo, al final de un valor de campo, y el carácter en blanco no va precedido
por un carácter de escape, aparecerán errores de Provisioning Manager que
serán difíciles de resolver.
Consulte la documentación del producto correspondiente a su servidor de
directorios para obtener más información sobre los caracteres especiales en las
cadenas LDAP.
AIX
Si el programa de instalación de middleware indica que no
Nota:
tiene suficiente espacio para instalar el middleware, debe liberar espacio de
disco en el sistema y luego reiniciar el programa de instalación de middleware.
v Cuando instale middleware utilizando el programa de instalación de
middleware, se le solicitarán ID de usuario para iniciar la instalación de DB2,
WebSphere Application Server y IBM Tivoli Directory Server. Puede especificar
un ID de usuario del sistema existente o dejar que el programa de instalación de
middleware cree un nuevo ID de usuario. La instalación puede fallar si
suministra una cuenta de usuario existente para instalar DB2 o IBM Tivoli
Directory Server y dicha cuenta de usuario no se encuentra bajo el directorio
/home.
v En algunos casos, los campos y las etiquetas que aparecen en el instalador de
middleware no se muestran correctamente en el panel cuando se realiza la
instalación mediante sesiones remotas. Se recomienda utilizar el instalador de
middleware localmente en el sistema que alojará el middleware. Si tiene
problemas de visualización, minimice y maximice el instalador de middleware
para que vuelva a mostrar el panel.
v Cuando instale middleware utilizando el instalador de middleware, no instale
varios productos en el mismo directorio personal izado. Por ejemplo, si instala
DB2, IBM Tivoli Directory Server, y WebSphere Application Server Network
Deployment en el mismo sistema, no los instale todos en un directorio
personalizado llamado, por ejemplo, C:\ISM_middleware. Sin embargo, podría
instalarlos en C:\ISM_middleware\DB2, C:\ISM_middleware\ITDS y
C:\ISM_middleware\WAS respectivamente. Tampoco puede instalar un producto
de middleware en un directorio personalizado y luego instalar otro producto de
middleware en un subdirectorio de dicho directorio personalizado. Así, por
ejemplo no puede instalar WebSphere Application Server Network Deployment
en el directorio personalizado C:\ISM_middleware y luego instalar IBM Tivoli
Directory Server en C:\ISM_middleware\ITDS.
v Para instalar una instancia de DB2 para un usuario existente, ejecute el siguiente
mandato:
ln -s /home_directory/<nombreusuario> /home/<nombreusuario>
Las instrucciones que se proporcionan en esta sección son para una instalación
típica donde se utilizan los valores predeterminados. Asimismo, en estas
instrucciones se supone que utiliza el instalador de middleware para instalar un
conjunto completo de middleware para su uso con Tivoli Provisioning Manager en
una máquina individual. Si tiene previsto desplegar productos de middleware en
una matriz de máquinas, deberá ejecutar el instalador de middleware en cada uno
de los sistemas y elegir qué parte de middleware desea instalar en cada uno de
86
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
ellos. En este caso, encontrará un subconjunto de los paneles que se incluyen en
estas instrucciones que son relevantes para el middleware que ha elegido instalar
en un sistema.
Para instalar los productos de middleware de requisito previo:
1. Compruebe si hay una instalación existente del instalador de soluciones. La
ubicación de instalación predeterminada es:
v
Windows
v
UNIX
C:\Archivos de programa\IBM\Common\acsi
Linux
/usr/ibm/common/acsi
Si el instalador de soluciones ya está instalado, inicie el servicio.
Windows
Consulte el panel de control de Servicios. Si el servicio ADE de IBM
no se está ejecutando, inícielo.
UNIX o Linux
a. Escriba ps -ef|grep acsisvc
b. Si el servicio se está ejecutando, se muestran el proceso y un PID
asociado. Si el servicio no se está ejecutando, ejecute el mandato:
/usr/ibm/common/acsi/bin/acsisrv.sh -start
2. Si instala el middleware en un sistema con una dirección IP virtual, el
instalador de middleware no permite realizar una selección en una lista de
nombres de host o direcciones IP. Siga estos pasos en cada sistema donde
desee instalar el middleware con el instalador de middleware:
a. Configure el sistema para que utilice la dirección IP virtual. Por ejemplo, si
el sistema está configurado actualmente para la dirección 9.31.26.3, pero la
dirección IP virtual es 9.31.26.12, configure el sistema para 9.31.26.12.
b. Configure el sistema para que utilice el nombre de host virtual enlazado
con la dirección IP virtual. Por ejemplo, si el sistema está configurado
actualmente para el nombre de host real.example.com, pero el nombre de
host virtual es virtual.example.com, configure el sistema para el nombre de
host virtual.example.com.
c. Ahora puede iniciar el instalador de middleware. Asegúrese de especificar
el nombre de host virtual y la dirección IP virtual de cada aplicación de
middleware que se instale en un sistema donde ha configurado una
dirección IP virtual y un nombre de host virtual.
3. En el sistema donde está instalando el middleware, Inicie el Launchpad.
4. En el panel de navegación del launchpad, haga clic en Instalación
personalizada.
5. Bajo 1. Instalar el middleware, haga clic en Verificar requisitos previos de
instalación de middleware. Después de verificar y de confirmar los requisitos
previos, vuelva a la página de instalación personalizada.
6. Haga clic en Instalar middleware.
7. Seleccione un idioma para la instalación y haga clic en Aceptar.
8. En el panel de bienvenida, haga clic en Siguiente.
9. Acepte el acuerdo de licencia y haga clic en Siguiente.
10. En el panel Elegir espacio de trabajo, especifique el directorio correspondiente
al espacio de trabajo del instalador de middleware y haga clic en Siguiente.
La ubicación predeterminada del espacio de trabajo es la ubicación del espacio
de trabajo más reciente que utiliza este usuario, tal como se especifica en el
nodo de preferencias del usuario de middleware.
Capítulo 3. Tareas previas a la migración
87
v Si no existe ninguna ubicación de espacio de trabajo anterior en el nodo de
preferencias de usuario de middleware, la ubicación predeterminada del
espacio de trabajo será C:\ibm\tivoli\mwi\workspace para Windows y
/root/ibm/tivoli/mwi/workspace para UNIX.
v Si el directorio seleccionado no existe, se creará.
v Si especifica una vía de acceso no válida, se utilizarán las letras de la vía de
acceso para crear un directorio en Launchpad\Install\MWI. Por ejemplo,
supongamos que especifica una vía de acceso de myworkspace en Windows
y falta una letra de unidad en la vía de acceso. El espacio de trabajo se
creará en Launchpad\Install\MWI\myworkspace.
Después del despliegue, el instalador de middleware también genera un
archivo de topología en este directorio denominado topology.properties. Si
instala el middleware en más de un sistema, deberá copiar este archivo en
cada uno de los sistemas donde vaya a instalar el middleware. Por ejemplo, si
instala primero el servidor de bases de datos en un sistema A y, a
continuación, instala el servidor de directorios y el servidor de aplicaciones en
el sistema B, debe:
a. Copiar el archivo topology.properties del sistema A en el espacio de trabajo
de middleware del sistema B.
b. Editar el archivo topology.properties en el sistema B para que el instalador
de middleware reconozca que los valores del servidor de bases de datos
son de otro sistema. En cada línea, cambie machine1 por machine2. Por
ejemplo, esta línea para el servidor de bases de datos:
machine1.DB2_SERVER_9_1_1.db2.fenced.user=tx2fenc1
Debe cambiarse por
machine2.DB2_SERVER_9_1_1.db2.fenced.user=tx2fenc1
El archivo topology.properties original en el sistema A permanece sin
modificar.
Cuando finalice la instalación del servidor de directorios y el servidor de
aplicaciones en el sistema B, el archivo topology.properties incluirá los valores
de machine2 para el servidor de bases de datos y los valores de machine1 para
el servidor de directorios y el servidor de aplicaciones. El archivo
topology.properties también se utiliza después de la instalación de middleware
en el instalador de Tivoli Provisioning Manager para configurar los
componentes principales del producto.
11. En el panel Instalar el Motor de despliegue autónomo de IBM, haga clic en
Siguiente.
12. En el panel Opciones de despliegue, seleccione las características que desee
instalar en este sistema y haga clic en Siguiente.
Servidor de bases de datos
La base de datos de Tivoli Provisioning Manager se utiliza para
almacenar información sobre los elementos de configuración y cómo
se relacionan entre ellos.
Directory Server
Los datos mantenidos por el servidor de directorios se utilizan para
proteger Tivoli Provisioning Manager.
Si instala Tivoli Directory Server, DB2 también se instalará, porque
Tivoli Directory Server utiliza DB2 como su base de datos.
88
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Servidor J2EE
El servidor J2EE se utiliza para alojar y gestionar la aplicación de
Tivoli Provisioning Manager.
Si elige instalar sólo la parte del servidor J2EE del middleware de
Tivoli Provisioning Manager, deberá proporcionar el servidor de
directorios que desea utilizar para protegerlo. Las opciones serán
protegerlo con una instancia existente de Tivoli Directory Server o una
instancia existente de Microsoft Active Directory.
13.
14.
15.
16.
Proteja el servidor J2EE con Directory Server
Esta opción permite utilizar un servidor de directorios para proteger
el servidor J2EE. Tenga en cuenta que esta opción es necesaria si
instala la opción Servidor J2EE. De forma predeterminada, esta opción
está seleccionada. Debe permanecer seleccionada para poder habilitar
la opción Servidor de directorios. Si elige no mantener el servidor
J2EE utilizando el servidor de directorios, no podrá instalar el servidor
de directorios mediante el instalador de middleware.
En la ventana Resumen del plan de despliegue, haga clic en Siguiente.
En el panel Nombre de host configurable, si desea especificar manualmente el
nombre de host del sistema desde el que está realizando la instalación,
seleccione la opción Alterar el nombre de host de la máquina local y
especifique un valor de nombre de host en el campo Nombre de host.
Seleccione esta opción únicamente si desea especificar manualmente el nombre
de host del sistema en lugar de dejar que el programa de instalación lo
detecte mediante programación. Esta opción resulta útil cuando hay más de
un nombre de host individual asignado al sistema, como por ejemplo cuando
un sistema tiene más de una interfaz de red o está configurado para dar
soporte a direcciones IP virtuales. Si se selecciona esta opción, tiene que
especificar un nombre de host que se pueda resolver. No puede deseleccionar
esta opción una vez seleccionada, aunque puede cambiar el valor del campo
Nombre de host. Si ha iniciado el programa de instalación de middleware
desde la línea de mandatos utilizando el parámetro forceHostname=true,
tendrá que especificar un valor alfanumérico en el campo Nombre de host.
Una dirección IP dará como resultado un mensaje de error. Una vez
seleccionada esta opción, no puede deseleccionarla, aunque puede cambiar el
valor que especifique en el campo Nombre de host.
En el panel Reutilización de contraseñas, puede seleccionar Utilizar el valor
de esta contraseña en las siguientes contraseñas, escribir un valor de
contraseña y luego hacer clic en Siguiente, lo cual le permitirá utilizar la
misma contraseña que el valor de contraseña de usuario predeterminado en
todos los paneles del programa de instalación de middleware. Si no desea
utilizar esta opción, pase por alto la opción Utilizar esta contraseña como
valor para las siguientes contraseñas y haga clic en Siguiente.
Especifique los siguientes parámetros de configuración para DB2 Enterprise
Edition Server y luego haga clic en Siguiente:
Ubicación de instalación
Especifique la ubicación para instalar DB2. El valor predeterminado
es:
Unidad_sistema:\Archivos de programa\IBM\SQLLIB
v
Windows
v
AIX
v
Linux
/opt/ibm/db2/V9.5
v
Linux
en IBM System z: /opt/IBM/db2/V9.5
/opt/IBM/db2/V9.5
Capítulo 3. Tareas previas a la migración
89
Nombre de usuario del servidor de administración de DB2
Especifique el nombre de la cuenta administrativa de DB2.
Windows
El valor predeterminado es db2admin
UNIX y Linux
El valor predeterminado es dasusr1
Contraseña del servidor de administración de DB2
Especifique la contraseña de la cuenta administrativa de DB2.
UNIX
Usuario de barrera
Especifique un ID de usuario del sistema que pueda utilizarse como
cuenta de usuario de barrera de DB2. El valor predeterminado es
db2fenc1.
Linux
Nota: Durante la instalación, el instalador de middleware crea
automáticamente las siguientes instancias predeterminadas de DB2:
Windows
DB2
UNIX
Linux
db2inst1
La contraseña de la instancia predeterminada es la misma contraseña que se
proporciona para la contraseña del servidor de administración de DB2 (DAS)
17. Escriba los siguientes parámetros de configuración para la instancia de base
de datos predeterminada y haga clic en Siguiente.
Nombre de instancia predeterminada
Escriba el nombre de la instancia de base de datos predeterminada. El
valor predeterminado es db2inst1.
Puerto de instancia predeterminada
Especifique el puerto que utilizará la instancia de base de datos
predeterminada. El valor predeterminado es 50000.
Nombre de usuario de instancia predeterminada
Especifique el nombre de usuario de la instancia de base de datos
predeterminada:
Windows
El valor predeterminado es db2admin
Linux El valor predeterminado es db2inst1
AIX
El valor predeterminado es db2inst1
Contraseña de nombre de usuario de instancia predeterminada
Especifique la contraseña del nombre de usuario de la instancia de
base de datos predeterminada.
18. Especifique información sobre los grupos de usuarios de DB2:
Grupo de administradores de DB2
Especifique el nombre del grupo de administradores de DB2. El valor
predeterminado es:
Windows
UNIX
90
DB2ADMNS
Linux
db2iadm1
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Windows
Grupo de usuarios de DB2
Especifique el nombre del grupo de usuarios de DB2.
El valor predeterminado es DB2USERS
19. Especifique los siguientes parámetros de configuración para IBM Tivoli
Directory Server y haga clic en Siguiente.
Ubicación de instalación
Especifique la ubicación para instalar Tivoli Directory Server. El valor
predeterminado es:
Windows
Linux
AIX
C:\Archivos de programa\IBM\LDAP\V6.2
/opt/IBM/ldap/V6.2
/opt/IBM/ldap/V6.2 Este valor no se puede modificar.
Nombre distinguido del administrador
Especifique el nombre distinguido del administrador de Tivoli
Directory Server.
El valor predeterminado para todas las plataformas es cn=root.
Contraseña del administrador
Especifique la contraseña del administrador de Tivoli Directory Server.
20. Especifique los siguientes parámetros de configuración para IBM Tivoli
Directory Server y haga clic en Siguiente.
Unidad organizativa
Especifique el nombre de la unidad organizativa de Tivoli Directory
Server que se utiliza con Tivoli Provisioning Manager.
El valor predeterminado para todas las plataformas es ou=SWG.
Sufijo de organización y país
Especifique el nombre del sufijo de organización y país de Tivoli
Directory Server que se utiliza con Tivoli Provisioning Manager.
El valor predeterminado para todas las plataformas es o=IBM,c=US.
Puerto del servidor de directorios
Especifique el número de puerto de Tivoli Directory Server.
El valor predeterminado para todas las plataformas es 389.
Puerto seguro del servidor de directorios
Especifique el número de puerto seguro de Tivoli Directory Server.
El valor predeterminado para todas las plataformas es 636.
Puerto de administración
Especifique el número de puerto de administración de Tivoli Directory
Server.
El valor predeterminado para todas las plataformas es 3538.
Puerto seguro de administración
Especifique el número de puerto de administración seguro de Tivoli
Directory Server.
El valor predeterminado para todas las plataformas es 3539.
21. Especifique los siguientes parámetros de configuración para la instancia de
base de datos de Tivoli Directory Server y haga clic en Siguiente.
Capítulo 3. Tareas previas a la migración
91
Nombre de la base de datos
Especifique el nombre de la base de datos de DB2 que está utilizando
para mantener los datos de Tivoli Directory Server.
El valor predeterminado para todas las plataformas es security.
Nombre de la instancia
Especifique el nombre de la instancia de base de datos de Tivoli
Directory Server.
El valor predeterminado para todas las plataformas es idsccmdb.
Puerto Especifique el nombre de puerto que utiliza la instancia de base de
datos de Tivoli Directory Server.
El valor predeterminado para todas las plataformas es 50006.
Contraseña de usuario de la instancia
Escriba la contraseña del ID de usuario de la instancia.
22. Especifique los siguientes parámetros de configuración para la seguridad de
WebSphere Application Server y haga clic en Siguiente.
Importante: El instalador de middleware no valida todos los valores LDAP
que especifica en el instalador.
v Cuando especifique valores de instalación, entradas en archivos LDIF o
valores que se especifican directamente en una instancia de directorio
utilizando las propias herramientas del servidor de directorios, tenga en
cuenta las reglas de sintaxis específicas del producto para el uso de
caracteres especiales en una cadena LDAP. En la mayoría de los casos, los
caracteres especiales deben ir precedidos de un carácter de escape para que
el servidor de directorios pueda leerlos. Si no se agrega el carácter de
escape a los caracteres especiales contenidos en una cadena LDAP que se
utiliza con Tivoli Provisioning Manager, se producirán errores.
Muchos productos de servidores de directorios consideran el carácter en
blanco como un carácter especial que forma parte de la cadena LDAP. Por
lo tanto, si especifica por error una cadena LDAP que contiene un espacio
en blanco, por ejemplo, al final de un valor de campo, y el carácter en
blanco no va precedido por un carácter de escape, aparecerán errores que
serán difíciles de resolver.
Consulte la documentación del producto correspondiente a su servidor de
directorios para obtener más información sobre los caracteres especiales en
las cadenas LDAP.
Nombre de host de LDAP
Especifique el nombre de dominio completo del sistema que aloja la
instancia LDAP que se utiliza para la seguridad de WebSphere
Application Server.
Un nombre de dominio completo incluye el nombre de host y el sufijo
de dominio. Por ejemplo, tpmserver.example.com. Si utiliza nombres
de host virtuales y direcciones IP para el sistema, asegúrese de
especificar el nombre de host virtual correcto en el nombre de
dominio completo.
Puerto del servidor de directorios
Especifique el nombre de puerto que utiliza el servidor LDAP para la
seguridad de WebSphere Application Server.
El valor predeterminado es 389.
92
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Entrada básica LDAP
Especifique la entrada básica LDAP de la instancia LDAP que se
utiliza para la seguridad de WebSphere Application Server.
El valor predeterminado es ou=SWG,o=IBM,c=US
Sufijo de usuario
Especifique el sufijo de usuario de la instancia LDAP que se utiliza
para la seguridad de WebSphere Application Server.
El valor predeterminado es ou=users,ou=SWG,o=IBM,c=US
Sufijo de grupo
Especifique el sufijo de grupo de la instancia LDAP que se utiliza para
la seguridad de WebSphere Application Server.
El valor predeterminado es ou=groups,ou=SWG,o=IBM,c=US
Sufijo de contenedor de organización
Especifique el sufijo de contenedor de organización de la instancia
LDAP que se utiliza para la seguridad de WebSphere Application
Server.
El valor predeterminado es ou=SWG,o=IBM,c=US
23. Especifique los siguientes parámetros de configuración para la seguridad de
WebSphere Application Server y haga clic en Siguiente.
Nombre distinguido del enlace
Especifique el nombre distinguido del enlace con la instancia LDAP.
El valor predeterminado es cn=root
Contraseña del enlace
Especifique la contraseña del nombre distinguido del enlace.
24. Especifique los siguientes parámetros de configuración para WebSphere
Application Server y haga clic en Siguiente.
Ubicación de instalación
Especifique la ubicación para instalar WebSphere Application Server.
El valor predeterminado es:
v
Windows
v
AIX
v
C:\Archivos de programa\IBM\WebSphere\AppServer
/usr/IBM/WebSphere/AppServer
Linux
/opt/IBM/WebSphere/AppServer
Nombre de usuario de administración de WebSphere
Especifique el nombre de la cuenta administrativa de WebSphere
Application Server.
El valor predeterminado para todas las plataformas es wasadmin.
Contraseña de administración de WebSphere
Especifique la contraseña de la cuenta administrativa de WebSphere
Application Server.
25. Especifique los siguientes parámetros de configuración para WebSphere
Application Server y haga clic en Siguiente.
Nombre de perfil del gestor de despliegue
Especifique el nombre del perfil de WebSphere Application Server del
servidor del gestor de despliegue.
El valor predeterminado para todas las plataformas es ctgDmgr01.
Capítulo 3. Tareas previas a la migración
93
Nombre de perfil del servidor de aplicaciones
Especifique el nombre del perfil de WebSphere Application Server del
servidor de aplicaciones.
El valor predeterminado para todas las plataformas es ctgAppSrv01.
26. Especifique los siguientes parámetros de configuración para WebSphere
Application Server y haga clic en Siguiente.
Nombre de célula
Especifique el nombre de la célula de WebSphere Application Server.
El valor predeterminado para todas las plataformas es ctgCell01.
Nombre de nodo del gestor de despliegue
Especifique el nombre del nodo del gestor de despliegue de
WebSphere Application Server.
El valor predeterminado para todas las plataformas es
ctgCellManager01.
Nombre de nodo del servidor de aplicaciones
Especifique el nombre del nodo de WebSphere Application Server.
El valor predeterminado para todas las plataformas es ctgNode01.
Ubicación de instalación del instalador de actualizaciones
Especifique la ubicación donde se instalará el instalador de
actualizaciones de WebSphere Application Server. El valor
predeterminado es:
Windows
C:\Archivos de programa\IBM\WebSphere\
UpdateInstaller
Linux
/opt/IBM/WebSphere/UpdateInstaller
/usr/IBM/WebSphere/UpdateInstaller
27. Especifique los siguientes parámetros de configuración para IBM HTTP Server
y haga clic en Siguiente.
AIX
Ubicación de instalación
Especifique la ubicación para instalar IBM HTTP Server. El valor
predeterminado es:
Windows
C:\Archivos de programa\IBM\HTTPServer
Tenga en cuenta que si instala IBM HTTP Server en una vía de acceso
a directorio que incluya espacios, como por ejemplo Archivos de
programa, no podrá iniciar ni detener IBM HTTP Server desde la
consola administrativa de WebSphere. Tendrá que iniciar y detener
IBM HTTP Server desde la línea de mandatos. Si decide instalar IBM
HTTP Server en una vía de acceso a directorio que no contenga
espacios, podrá iniciar y detener IBM HTTP Server desde la consola
administrativa de WebSphere.
Linux
/opt/IBM/HTTPServer
AIX
/usr/IBM/HTTPServer
Puerto HTTP
Especifique el puerto que utiliza IBM HTTP Server.
El valor predeterminado para todas las plataformas es 80.
94
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Puerto del servidor de administración
Especifique el puerto que se utiliza para administrar IBM HTTP
Server.
El valor predeterminado para todas las plataformas es 8008.
28. Especifique los siguientes parámetros de configuración para el plug-in de
WebSphere Application Server de IBM HTTP Server y haga clic en Siguiente.
Nombre de perfil
Especifique el nombre del perfil.
El valor predeterminado para todas las plataformas es ctgAppSrv01.
Este valor no puede cambiarse.
29. Especifique la ubicación de las imágenes de middleware y haga clic en
Siguiente. Si realiza la instalación desde DVD, inserte el DVD de Middleware
antes de hacer clic en Siguiente.
Copie las imágenes de instalación de middleware del soporte de origen en
el directorio especificado
Seleccione esta opción para copiar las imágenes de middleware del
soporte del producto en el directorio que elija.
Especifique un directorio que contenga todas las imágenes de instalación de
middleware necesarias
Seleccione esta opción si desea especificar un directorio que ya
contiene todas las imágenes de instalación del middleware.
30. Si selecciona la opción de copiar las imágenes de instalación del soporte de
origen, especifique los directorios de origen y destino y, a continuación, haga
clic en Siguiente. Si selecciona la opción de especificar un directorio que ya
contiene las imágenes de middleware, especifique dicho directorio y haga clic
en Siguiente.
31. Especifique el directorio que desea utilizar para los archivos temporales del
instalador de middleware y las imágenes de instalación de middleware
extraídas y, a continuación, haga clic en Siguiente.
32. En el panel Operación del plan de despliegue, seleccione Desplegar el plan y
haga clic en Siguiente.
También puede realizar cambios en el plan de despliegue o en los parámetros
que ha configurado previamente en este panel.
33. En la ventana Resumen del plan de despliegue, haga clic en Siguiente.
34. Cuando el despliegue finalice correctamente, haga clic en Finalizar.
35. Si instala el middleware en más de un sistema, siga estos pasos:
v Asegúrese de copiar el archivo topology.properties del espacio de trabajo en
el espacio de trabajo del siguiente sistema donde está instalando el
middleware.
v Si el servidor de bases de datos de DB2 está en un sistema diferente al
servidor de suministro, asegúrese de que cumple con los requisitos
siguientes:
–
El usuario de la instancia de base de datos debe
existir en el servidor de DB2. Por ejemplo, si piensa crear la instancia de
DB2 ctginst1, debe crear un usuario (incluido el directorio padre del
usuario) en el servidor de DB2. El grupo db2iadm1 debe existir.
–
Debe crear manualmente un usuario de sistema operativo
denominado maximo en el servidor de bases de datos. El instalador
establecerá los permisos necesarios para el usuario.
UNIX
Linux
Capítulo 3. Tareas previas a la migración
95
36. Si instala el middleware en un sistema con una IP virtual, siga estos pasos:
a. Compruebe que el nombre de host y la dirección IP virtual se hayan
configurado correctamente.
v En el espacio de trabajo de middleware, compruebe el archivo
topology.properties. La ubicación predeterminada es:
–
Windows
–
AIX
C:\ibm\tivoli\mwi\workspace
/ibm/tivoli/mwi/workspace
Linux
/root/ibm/tivoli/mwi/workspace
–
v Para DB2, compruebe el archivo db2nodes.cfg.
Windows
El archivo se encuentra en el directorio de instalación de
DB2. La ubicación predeterminada es: C:\Archivos de
programa\IBM\SQLLIB
–
Si el nombre de instancia es ctginst1, el archivo se
encuentra en: /home/ctginst1
b. En cada uno de los sistemas donde ha configurado el nombre de host y la
dirección IP virtual, ahora puede configurar los valores originales de
nombre de host y dirección IP, y configurar la dirección IP virtual como
una dirección IP secundaria. Para continuar con el ejemplo en el paso 2,
debe realizar los cambios siguientes:
1) Cambie la dirección IP 9.31.26.12 al valor original 9.31.26.3.
2) Cambie el nombre de host virtual.example.com al valor original
real.example.com.
–
UNIX
3) Ejecute el mandato para configurar la segunda dirección IP. Por
ejemplo:
ifconfig eth0:1 9.31.26.12 netmask 255.255.255.240
37. Si utiliza una dirección IP virtual en el sistema donde se ha instalado el
servidor de DB2 para Tivoli Provisioning Manager o el servidor de DB2 para
Tivoli Directory Server, ejecute el siguiente mandato de DB2 en el sistema:
db2set -g DB2SYSTEM=nombre_host_virtual
Sustituya nombre_host_virtual por el nombre de host virtual.
Ejemplo: si se instala DB2 en un sistema con el nombre de host virtual
database.example.com y se instala Tivoli Directory Server en un sistema con el
nombre de host virtual ldap.example.com:
a. Ejecute este mandato en el sistema database.example.com:
db2set -g DB2SYSTEM=database.example.com
b. Ejecute este mandato en el sistema ldap.example.com:
db2set -g DB2SYSTEM=ldap.example.com
Resultados
El middleware ya está instalado.
El instalador de middleware informa acerca de si la instalación del middleware se
ha realizado correctamente o no. Si la instalación falla, consulte el directorio de
registro para ver los informes de errores:
96
v
Windows
v
UNIX
C:\ibm\tivoli\mwi\workspace
/root/ibm/tivoli/mwi/workspace
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Reutilización de middleware utilizando el instalador de
middleware
Puede utilizar instalador de middleware para configurar algunos productos de
middleware. Otros productos de middleware deben configurarse manualmente si
desea reutilizarlos.
Si desea reutilizar los servidores de middleware existentes con Tivoli Provisioning
Manager, deben configurarse antes de instalar Tivoli Provisioning Manager. Esta
sección contiene información acerca de cómo configurar los servidores de DB2,
Tivoli Directory Server y Microsoft Active Directory utilizando el instalador de
middleware, que se utilizará con Tivoli Provisioning Manager.
No puede utilizar el instalador de middleware para realizar la configuración en un
Oracle Database o WebSphere Application Server existente. Consulte Utilización
del middleware configurado manualmente para obtener más información acerca de
estos servidores. Esta información también se aplica si decide que desea reutilizar
los servidores de middleware existentes, pero prefiere configurarlos para trabajar
manualmente con Tivoli Provisioning Manager en lugar de permitir que el
programa de instalación de Tivoli Provisioning Manager los configure.
Cuando realice la instalación y configuración de middleware en instalador de
middleware y en el programa de instalación de Tivoli Provisioning Manager, tenga
en cuenta las restricciones siguientes:
Nombre
Restricción
Convenios de denominación de DB2 para
nombres de grupos, nombres de usuarios e
ID de usuarios.
Los nombres de grupo y los ID de grupo en
los sistemas operativos Linux y UNIX
pueden contener un máximo de 8 caracteres
y solo pueden contener caracteres en
minúsculas.
Los nombres de grupos y los nombres de
usuarios en Windows pueden contener hasta
30 caracteres.
Los nombres y los ID no pueden tener los
valores siguientes: USERS, ADMINS,
GUESTS, PUBLIC, LOCAL ni cualquier
palabra reservada de SQL.
Los nombres y los ID no pueden comenzar
por IBM, SQL o SYS. Tampoco pueden
comenzar por el carácter de subrayado (_).
Convenios de denominación de DB2 para
instancias de DB2.
Los nombres de instancias deben tener un
máximo de ocho caracteres.
en Windows, ninguna instancia puede tener
el mismo nombre que un nombre de
servicio.
Convenios de denominación de DB2 para
contraseñas.
En los sistemas UNIX, las contraseñas puede
tener un máximo de ocho caracteres.
En los sistemas Windows, las contraseñas
pueden tener un máximo de 14 caracteres.
Capítulo 3. Tareas previas a la migración
97
Nombre
Restricción
Convenios de IBM Tivoli Directory Server
Los nombres de base de datos deben ser
para bases de datos y alias de base de datos. exclusivos en la ubicación en la que se
catalogan. En Linux y UNIX, esta ubicación
es una vía de acceso de directorio. Para
Windows es un disco lógico.
Los nombres de alias de base de datos
deben ser exclusivos en el directorio de base
de datos del sistema. Cuando se crea una
nueva base de datos, el alias toma el nombre
de la base de datos de forma
predeterminada. Como resultado, no puede
crear una base de datos utilizando un
nombre que exista como alias de base de
datos, aunque no haya ninguna base de
datos con ese nombre.
Los nombres de base de datos y de alias de
base de datos pueden tener hasta ocho
caracteres.
Evite los caracteres especiales @, # y $
cuando cree un nombre de base de datos.
Convenios de IBM Tivoli Directory Server
para usuarios, grupos, bases de datos e
instancias
Los valores no deben tener más de ocho
caracteres.
Los valores no pueden ser los siguientes:
USERS, ADMINS, GUESTS, PUBLIC,
LOCAL o idsldap
Los valores no pueden comenzar por IBM,
SQL o SYS.
Los valores no deben incluir caracteres
acentuados.
Los valores pueden incluir los caracteres
A-Z, a-z y 0-9.
Los valores deben comenzar por los
caracteres A-Z o a-z.
Los caracteres de doble byte no se pueden
utilizar en los valores de contraseñas de
administrador.
Las contraseñas no pueden contener los
siguientes caracteres especiales: ` ’ \ ″ |
Convenios de WebSphere Application Server El nombre del administrador no puede
contener los caracteres siguientes: / \ * ,:
;=+?|< > & % ’″] [> # $ ~ ( )
El nombre de administrador no puede
comenzar por un punto.
El nombre de administrador no puede
contener espacios iniciales ni de cola.
La contraseña del administrador debe
constar de ocho caracteres.
98
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nombre
Restricción
El programa de instalación de middleware
El programa de instalación de middleware
no valida que la contraseña cumpla con el
sistema operativo del host de destino, por lo
tanto, asegúrese de que proporciona valores
de contraseña válidos para su entorno.
El programa de instalación de middleware
no permite el uso del carácter ’%’ en
Windows ni el uso de los caracteres !, $, #, %
en UNIX.
El programa de instalación de middleware
no comprueba los caracteres acentuados en
los valores de nombre de usuario. El uso de
caracteres acentuados puede generar errores.
Configuración de una instalación de DB2 existente con el instalador de
middleware:
Antes de empezar
v Verifique los requisitos previos de instalación descritos en la sección Tareas
previas a la instalación.
v Para evitar errores de instalación, asegúrese de revisar atentamente todos los
requisitos que se describen en el apartado “Verificación de los requisitos de
nombres, contraseñas y cuentas de usuario” en la página 61. El instalador de
middleware no valida todos los nombres y contraseñas especificados en el
instalador.
v Utilice siempre nombres de dominio completos cuando especifique valores para
los nombres de host del sistema.
v Los siguientes usuarios y grupos deben existir previamente en el sistema. Si no
existen en el sistema, deberá crearlos antes de ejecutar el programa de
instalación de Tivoli Provisioning Manager.
Usuarios
db2admin
–
Windows
–
UNIX
Linux
db2inst1
–
UNIX
Linux
dasusr1
UNIX
Linux
db2fenc1
–
– Si el servidor de bases de datos de DB2 está en un sistema diferente
al servidor de suministro, asegúrese de que cumple con los requisitos
siguientes:
-
UNIX
Linux
El usuario de la instancia de base de datos
debe existir en el servidor de DB2. Por ejemplo, si piensa crear la
instancia de DB2 ctginst1, debe crear un usuario (incluido el
directorio padre del usuario) en el servidor de DB2. El grupo
db2iadm1 debe existir.
-
Debe crear manualmente un usuario de sistema
operativo denominado maximo en el servidor de bases de datos. El
instalador establecerá los permisos necesarios para el usuario.
Grupos
–
Windows
db2admns
Capítulo 3. Tareas previas a la migración
99
–
UNIX
Linux
dasadm1
–
UNIX
Linux
dbgrp1
–
UNIX
Linux
db2fgrp1
Para configurar una instancia de base de datos existente para volver a utilizarla
con Tivoli Provisioning Manager:
1. Inicie la sesión como usuario con autorización administrativa.
2. Inicie el instalador de middleware desde el launchpad.
3. Continúe en los paneles del instalador de middleware como se indica en el
apartado “Instalación del middleware con el instalador de middleware” en la
página 83, hasta que llegue al panel Opciones de despliegue.
4. En el panel Opciones de despliegue, seleccione Servidor de bases de datos y
haga clic en Siguiente. El instalador de middleware de Tivoli muestra las
instancias de DB2 encontradas en el sistema.
5. En el menú desplegable Instalación, seleccione la instancia que desee reutilizar
y haga clic en Siguiente.
6. Complete la instalación continuando en los restantes paneles del instalador de
middleware. Consulte el apartado “Instalación del middleware con el instalador
de middleware” en la página 83 para obtener más información.
7. Si utiliza una dirección IP virtual en el sistema donde está instalado el servidor
de DB2 para Tivoli Provisioning Manager, ejecute el siguiente mandato de DB2
en el sistema:
db2set -g DB2SYSTEM=nombre_host_virtual
Sustituya nombre_host_virtual por el nombre de host virtual.
Ejemplo: si se instala DB2 en un sistema con el nombre de host virtual
database.example.com, ejecute este mandato en el sistema
database.example.com:
db2set -g DB2SYSTEM=database.example.com
Qué hacer a continuación
1. Después de configurar DB2, instale el cliente de DB2.
Instalación del cliente de DB2:
Este apartado contiene instrucciones básicas de instalación para una instalación
típica de DB2. Si necesita más información, consulte la información de instalación
en el Centro de información de DB2.
Utilice el soporte de instalación de DB2 que se proporciona con Tivoli Provisioning
Manager para asegurarse de que utiliza la versión correcta.
Si utiliza DB2 en otro nodo, el cliente de DB2 debe estar preinstalado en el sistema
de Tivoli Provisioning Manager. Durante la instalación de Tivoli Provisioning
Manager, el cliente de la base de datos se utiliza para conectar con el servidor de
DB2 y para configurarlo para que se utilice con Tivoli Provisioning Manager.
1. Inicie la sesión como usuario con acceso de administrador.
2. Si utiliza DVD, inserte el disco en la unidad de disco.
UNIX
Monte el DVD y vaya al directorio en el que está montado el DVD
especificando el siguiente mandato:
cd /cdrom
100
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
3. Si utiliza imágenes, copie el archivo de archivado que comienza por
DB2_CLIENT_V91 en el directorio en el que desea instalar DB2.
4.
Vaya a la carpeta que comienza por las letras client/disk1 y escriba
./db2setup para iniciar el asistente de instalación de DB2.
UNIX
Windows
Vaya a la carpeta CLIENT y ejecute setup.exe para iniciar el
asistente de instalación de DB2.
6. Se abre el Launchpad de instalación de IBM DB2. En esta ventana, revise los
requisitos previos de la instalación y las notas del release para ver la
información más actualizada y luego continúe con la instalación.
7. Haga clic en Instalar productos.
5.
8.
9.
10.
11.
12.
13.
Seleccione Cliente de administración de DB2 y haga clic en Siguiente.
En la ventana de bienvenida, haga clic en Siguiente.
Acepte el acuerdo de licencia y haga clic en Siguiente.
Acepte el valor predeterminado (Típica) y haga clic en Siguiente.
UNIX
Seleccione Crear una instancia de DB2.
Especifique el propietario de la instancia de DB2. Utilice el mismo
nombre de usuario que ha utilizado para la instalación del servidor de DB2.
Por ejemplo, db2inst1.
Por ejemplo, especifique db2inst1 para el propietario de la base de datos y
db2iadm1 como grupo primario.
UNIX
Nota:
v El nombre de usuario y la contraseña de DB2 deben coincidir con el nombre
de usuario y la contraseña de la instancia en el servidor de DB2.
v Asegúrese de que el directorio del cliente de la base de datos es el
directorio sqllib bajo el directorio padre del propietario de la instancia. Por
ejemplo, si el directorio padre es /home/db2inst1, la ubicación del cliente es
/home/db2inst1/sqllib.
14. Acepte los valores predeterminados para los paneles restantes.
15. En el panel de resumen, revise los valores. Tome nota del directorio de
instalación del cliente de DB2. Necesitará esta información para la instalación
de Tivoli Provisioning Manager.
16. Haga clic en Finalizar para comenzar la instalación.
17.
AIX
Tras la instalación, establezca el shell predeterminado del
propietario de la instancia de la base de datos (por ejemplo, db2inst1) en el
shell Korn.
Comprobación de un Tivoli Directory Server existente con el instalador de
middleware:
Si tiene una instalación de IBM Tivoli Directory Server existente que desearía
volver a utilizar para Provisioning Manager, puede verificar que funcionará con
Provisioning Manager utilizando el instalador de middleware.
Antes de empezar
v Compruebe los requisitos previos de instalación que se describen en el
“Verificación de los requisitos de nombres, contraseñas y cuentas de usuario” en
la página 61.
v Para evitar errores de instalación, asegúrese de revisar atentamente todos los
requisitos que se describen en el apartado “Verificación de los requisitos de
Capítulo 3. Tareas previas a la migración
101
nombres, contraseñas y cuentas de usuario” en la página 61. El instalador de
middleware no valida todos los nombres y contraseñas especificados en el
instalador.
v Utilice siempre nombres de dominio completos cuando especifique valores para
los nombres de host del sistema.
v Si encuentra errores durante la instalación, consulte la guía de resolución de
problemas.
El instalador de middleware valida la información siguiente:
v La versión de Tivoli Provisioning Manager.
v Se está ejecutando Tivoli Directory Server.
v La información del nombre distinguido básico que suministre en Tivoli
Provisioning Manager.
El instalador de middleware no crea una nueva instancia de Tivoli Directory
Server para su uso con Tivoli Provisioning Manager. Si desea reutilizar un Tivoli
Provisioning Manager existente, suministre el nombre distinguido de
administrador y la contraseña correctos, DNbase de LDAP, puerto de servidor
de directorio y la información del puerto de administración para dicha instancia
en los paneles del instalador de middleware cuando se le solicite. Si tiene
previsto alojar una instancia nueva de Tivoli Directory Server en su Tivoli
Directory Server existente, debe crearla antes de ejecutar instalador de
middleware. Puede encontrar más información acerca de cómo crear una
instancia nueva en la sección Configuración manual de Tivoli Directory Server.
Proporcione los valores correctos de nombre distinguido de administrador y
contraseña, DN base de LDAP, puerto del servidor de directorios y la
información del puerto de administración para dicha instancia en los paneles del
instalador de middleware.
Para verificar una instancia existente de Tivoli Directory Server:
1. Inicie la sesión como usuario con autorización administrativa.
2. Inicie el instalador de middleware desde el launchpad.
3. Continúe por los paneles de instalador de middleware como se indica en la
sección Instalación y configuración del middleware con el instalador de
middleware, hasta que llegue al panel Opciones de despliegue.
4. En el panel Opciones de despliegue, seleccione Servidor de directorios y haga
clic en Siguiente. El instalador de middleware muestra las instancias de Tivoli
Directory Server encontradas en el sistema.
5. En el menú desplegable Instalación, seleccione la instancia que desee reutilizar
y haga clic en Siguiente.
6. Complete la instalación continuando en los restantes paneles del instalador de
middleware. Consulte la sección Instalación y configuración del middleware
con el instalador de middleware para obtener más información.
7. Si utiliza una dirección IP virtual en el sistema donde está instalado Tivoli
Directory Server, ejecute el siguiente mandato de DB2 en el sistema:
db2set -g DB2SYSTEM=nombre_host_virtual
Sustituya nombre_host_virtual por el nombre de host virtual.
Ejemplo: si se instala Tivoli Directory Server en un sistema con el nombre de
host virtual ldap.example.com, ejecute este mandato en el sistema
ldap.example.com:
db2set -g DB2SYSTEM=ldap.example.com
102
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Utilización del middleware configurado manualmente
Las instalaciones manuales requieren la configuración de los componentes de
middleware, el servidor de bases de datos, el servidor de directorios y el servidor
de aplicaciones para que trabajen con Tivoli Provisioning Manager antes de utilizar
el programa de instalación de Tivoli Provisioning Manager.
Puede seleccionar que se configuren uno o varios componentes de middleware de
Tivoli Provisioning Manager mediante el instalador de middleware. De manera
alternativa, puede configurar manualmente uno o varios de los servidores de
middleware para que trabajen con Tivoli Provisioning Manager.
Debe realizar la configuración manual de cada uno de los servidores no que tenga
previsto configurar utilizando la característica de configuración automática del
programa de instalación de Tivoli Provisioning Manager antes de ejecutar el
programa de instalación de Tivoli Provisioning Manager.
Instalación del servidor de DB2:
Antes de empezar
v Para DB2 en sistemas UNIX, asegúrese de que tiene un mínimo de 8 gigabytes
de espacio libre en el directorio padre de la instancia de base de datos de DB2
(/home/db2inst1) para cumplir los requisitos predeterminados de espacio de
disco del espacio de tabla de la instalación de DB2. Para DB2 en Windows,
asegúrese de que tiene un mínimo de 8 gigabytes de espacio libre en el
directorio de instalación de DB2.
v Asegúrese de que el sistema cumpla los otros requisitos de instalación, de
memoria y de disco. Para obtener información sobre los requisitos de DB2 y
problemas de seguridad a tener en cuenta al instalar DB2, consulte la
documentación de DB2. El instalador DB2 calcula automáticamente el espacio de
disco necesario y determina si tiene suficiente espacio de disco. Asegúrese
también de que ha asignado suficiente espacio de disco para el crecimiento de la
base de datos.
v
UNIX
El asistente de instalación de DB2 es un instalador gráfico. Debe tener
un software X Window capaz de ofrecer una interfaz gráfica de usuario para
poder ejecutar el asistente de instalación de DB2 en el sistema.
v
Asegúrese de que la E/S asíncrona (AIO) esté habilitada. Debe estar
habilitada para que DB2 se pueda instalar correctamente. Para utilizar AIO en
Linux, debe instalar libaio-0.3.96 o posterior y tener un kernel que dé soporte a
AIO (por ejemplo, la versión 2.6).
UNIX
Este apartado contiene instrucciones básicas de instalación para una instalación
típica de DB2. Si necesita más información, consulte la información de instalación
en el Centro de información de DB2.
Utilice el soporte de instalación de DB2 que se proporciona con Tivoli Provisioning
Manager para asegurarse de que utiliza la versión correcta.
Para instalar el servidor de DB2:
1. Inicie la sesión como root (UNIX) o como un usuario con acceso
administrativo (Windows).
2.
Si utiliza discos, busque el soporte de DB2 correcto para su idioma.
Monte el DVD y vaya al directorio en el que está montado el DVD
especificando el siguiente mandato:
UNIX
cd /cdrom
Capítulo 3. Tareas previas a la migración
103
donde /cdrom representa el punto de montaje de la unidad de disco.
Windows
Si utiliza discos, inserte el DVD.
3.
4. Si utiliza imágenes de instalación, copie el archivo de archivado que comienza
por DB2_ESE_V91 en el directorio en el que desea instalar DB2. Seleccione el
archivo correspondiente al idioma que desea instalar. Extraiga el contenido del
archivo de archivado.
5.
Vaya a la carpeta que comienza por las letras ese y escriba
./db2setup para iniciar el asistente de instalación de DB2.
UNIX
Windows
Vaya a la carpeta ese\image y ejecute setup.exe para iniciar el
asistente de instalación de DB2.
7. Se abre el Launchpad de instalación de IBM DB2. En esta ventana, revise los
requisitos previos de la instalación y las notas del release para ver la
información más actualizada y luego continúe con la instalación.
8. Haga clic en Instalar productos.
6.
Seleccione DB2 UDB Enterprise Server Edition y haga clic en Siguiente.
En la ventana de bienvenida, haga clic en Siguiente.
Acepte el acuerdo de licencia y haga clic en Siguiente.
Acepte el valor predeterminado (Típica) y haga clic en Siguiente.
Marque el recuadro de selección Instalar DB2 UDB Enterprise Server Edition
en este sistema y haga clic en Siguiente.
14. Continúe con la instalación y utilice los valores predeterminados que sugiere
el instalador. .
9.
10.
11.
12.
13.
15. Una vez finalizada la instalación, se abre una página de estado. Haga clic en
el separador Informe de estado para asegurarse de que la instalación se ha
realizado correctamente.
16. Realice los siguientes pasos posteriores a la instalación:
a. Ejecute los mandatos siguientes:
db2set
db2set
db2set
db2set
DB2COMM=TCPIP
DB2BQTRY=120
DB2BQTIME=2
DB2AUTOSTART=YES
b. Si utiliza una dirección IP virtual en el sistema donde está instalado el
servidor de DB2 para Tivoli Provisioning Manager, ejecute el siguiente
mandato de DB2 en el sistema
db2set -g DB2SYSTEM=nombre_host_virtual
Sustituya nombre_host_virtual por el nombre de host virtual.
Ejemplo: si se instala DB2 en un sistema con el nombre de host virtual
database.example.com, ejecute este mandato en el sistema
database.example.com:
db2set -g DB2SYSTEM=database.example.com
Qué hacer a continuación
Después de instalar DB2, debe:
1. Configurarlo para su uso con Tivoli Provisioning Manager configurando
manualmente los valores o ejecutando el instalador de middleware para
configurar automáticamente los valores. Consulte Configuración de una
instalación de DB2 existente con el instalador de middleware.
2. Instale el cliente de DB2. Consulte Instalación del cliente de DB2.
104
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
.
Instalación del cliente de DB2:
Este apartado contiene instrucciones básicas de instalación para una instalación
típica de DB2. Si necesita más información, consulte la información de instalación
en el Centro de información de DB2.
Utilice el soporte de instalación de DB2 que se proporciona con Tivoli Provisioning
Manager para asegurarse de que utiliza la versión correcta.
Si utiliza DB2 en otro nodo, el cliente de DB2 debe estar preinstalado en el sistema
de Tivoli Provisioning Manager. Durante la instalación de Tivoli Provisioning
Manager, el cliente de la base de datos se utiliza para conectar con el servidor de
DB2 y para configurarlo para que se utilice con Tivoli Provisioning Manager.
1. Inicie la sesión como usuario con acceso de administrador.
2. Si utiliza DVD, inserte el disco en la unidad de disco.
Monte el DVD y vaya al directorio en el que está montado el DVD
especificando el siguiente mandato:
UNIX
cd /cdrom
3. Si utiliza imágenes, copie el archivo de archivado que comienza por
DB2_CLIENT_V91 en el directorio en el que desea instalar DB2.
4.
UNIX
Vaya a la carpeta que comienza por las letras client/disk1 y escriba
./db2setup para iniciar el asistente de instalación de DB2.
5.
Windows
Vaya a la carpeta CLIENT y ejecute setup.exe para iniciar el
asistente de instalación de DB2.
6. Se abre el Launchpad de instalación de IBM DB2. En esta ventana, revise los
requisitos previos de la instalación y las notas del release para ver la
información más actualizada y luego continúe con la instalación.
7. Haga clic en Instalar productos.
8. Seleccione Cliente de administración de DB2 y haga clic en Siguiente.
9. En la ventana de bienvenida, haga clic en Siguiente.
10. Acepte el acuerdo de licencia y haga clic en Siguiente.
11. Acepte el valor predeterminado (Típica) y haga clic en Siguiente.
12.
13.
UNIX
Seleccione Crear una instancia de DB2.
UNIX
Especifique el propietario de la instancia de DB2. Utilice el mismo
nombre de usuario que ha utilizado para la instalación del servidor de DB2.
Por ejemplo, db2inst1.
Por ejemplo, especifique db2inst1 para el propietario de la base de datos y
db2iadm1 como grupo primario.
Nota:
v El nombre de usuario y la contraseña de DB2 deben coincidir con el nombre
de usuario y la contraseña de la instancia en el servidor de DB2.
v Asegúrese de que el directorio del cliente de la base de datos es el
directorio sqllib bajo el directorio padre del propietario de la instancia. Por
ejemplo, si el directorio padre es /home/db2inst1, la ubicación del cliente es
/home/db2inst1/sqllib.
14. Acepte los valores predeterminados para los paneles restantes.
Capítulo 3. Tareas previas a la migración
105
15. En el panel de resumen, revise los valores. Tome nota del directorio de
instalación del cliente de DB2. Necesitará esta información para la instalación
de Tivoli Provisioning Manager.
16. Haga clic en Finalizar para comenzar la instalación.
17.
AIX
Tras la instalación, establezca el shell predeterminado del
propietario de la instancia de la base de datos (por ejemplo, db2inst1) en el
shell Korn.
Instalación de Oracle Database: Si desea utilizar la Oracle Database como
servidor de bases de datos, debe instalar siguiendo los pasos de esta sección. Para
obtener más información, consulte la documentación de Oracle.
Instalación del servidor de Oracle Database en AIX, Linux (x86 64 bits) y Solaris:
Para asegurarse de que la instalación de Tivoli Provisioning Manager se ha
realizado correctamente, compruebe que la Oracle Database se ha preinstalado y
configurado correctamente.
Antes de empezar
1. Verifique la versión de la Oracle Database que desea instalar. Las versiones
soportadas son Oracle 10g Release 2 parche 3 (10.2.0.4g) u Oracle 11g R1.
2. Compruebe que el sistema reúne los requisitos de hardware y software de la
Oracle Database. Para obtener más información, consulte la documentación de
Oracle.
3. Inicie la sesión como root.
4. Establezca un número de parámetros necesarios para la instalación de Tivoli
Provisioning Manager. En el archivo /etc/sysctl.conf, agregue los parámetros
siguientes:
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
A continuación, ejecute el mandato /sbin/sysctl -p para que los valores surtan
efecto.
5.
Linux
Ejecute el mandato siguiente en una sola línea, para comprobar todos
los paquetes necesarios:
rpm -q binutils compat-db control-center gcc gcc-c++ glibc glibc-common gnome-libs
libstdc++ libstdc++-devel make pdksh sysstat xscreensaver libaio openmotif21
Si falta cualquier paquete, instálelo.
106
6.
Ejecute el mandato smit chgsys para establecer el número máximo
de procesos por usuario. Verifique que el valor de Número máximo de
PROCESOS sea 2048 o más.
7.
AIX
Ejecute el mandato lsps -a para verificar el espacio de paginación y
luego ejecute el mandato chps -s para aumentar el espacio, si es necesario.
Utilice las siguientes directrices:
AIX
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 47. Espacio de paginación para AIX
RAM
Espacio de intercambio
Entre 1024 MB y 2048 MB
1,5 veces el tamaño de RAM
Entre 2049 MB y 8192 MB
Igual al tamaño de RAM
Más de 8192 MB
0,75 veces el tamaño de RAM
Por ejemplo, el siguiente mandato agrega tres particiones lógicas de 128 MB al
espacio de paginación hd6:
chps -s 3 hd6
Para obtener más información, consulte la documentación de AIX.
8. Cree y configure el usuario oracle:
a. Cree los grupos oinstall (establecer como el grupo primario) y dba y
agregue el usuario oracle a los grupos.
b. Asegúrese de que /home/oracle sea el directorio padre del usuario oracle.
El directorio padre del usuario oracle debe tener un archivo
.profile, el cual debe incluir las líneas siguientes:
AIX
umask 022
export AIXTHREAD_SCOPE=S
9. Configure el directorio base para los productos Oracle:
a. Cree el directorio base, por ejemplo, /u01/app/oracle. El directorio de
instalación de Oracle Database se creará en este directorio.
b. Configure la propiedad de este directorio en el usuario oracle y el grupo
oinstall. Por ejemplo, ejecute el siguiente mandato:
chown -R oracle:oinstall /u01/app/oracle
c. Establezca los permisos 775 para el directorio de instalación, todos sus
directorios padre y todos sus subdirectorios. Por ejemplo, si el directorio de
instalación es /u01/app/oracle, debe establecer 755 permisos para /u01,
/u01/app, /u01/app/oracle y para todos los subdirectorios de
/u01/app/oracle. Ejecute el mandato siguiente:
chmod -R 775 /u01
Para instalar el servidor de Oracle Database:
1. Inicie la sesión como oracle.
2. Asegúrese de que el usuario oracle tenga permisos de lectura sobre el soporte
de instalación de Oracle. Si utiliza un archivo de imagen de instalación,
extraiga la imagen como el usuario oracle.
3. Inicie la instalación de Oracle Database y seleccione la opción de instalación
avanzada.
4. Establezca los siguientes valores en los paneles de instalación:
v Ubicación padre de Oracle: Especifique un subdirectorio del directorio base
para los productos Oracle.
Por ejemplo, /u01/app/oracle/product/10.2.0.1.0/db_1.
v Grupo DBA de UNIX: Seleccione oinstall.
v Nombre de base de datos local: Especifique el nombre del SID de Oracle
para la base de datos de Tivoli Provisioning Manager. Por ejemplo, ctginst1.
El nombre de la base de datos sólo puede contener letras mayúsculas, letras
minúsculas y números.
Capítulo 3. Tareas previas a la migración
107
5. Complete la instalación como se describe en la documentación de la Oracle
Database. Cuando se le solicite el juego de caracteres de base de datos,
especifique UTF-8.
6. Establezca el parámetro nls_length_semantics en char. Para obtener
información acerca de cómo llevarlo a cabo, consulte la documentación de
Oracle.
Qué hacer a continuación
1. Compruebe que todavía no existen los siguientes usuarios de base de datos y
que sus restricciones permite crearlos. Esto es necesario pero que estos usuarios
se crearán durante la instalación de Tivoli Provisioning Manager.
v Un usuario para Dynamic Content Delivery, denominado CDSSCHEMA (en
mayúsculas).
v Un usuario para conectarse a la base de datos de Tivoli Provisioning
Manager. Por ejemplo, tpmadmin.
2. Defina los valores siguientes en el perfil de usuario de oracle si todavía no
existen:
Tabla 48. Variables de entorno para Oracle Database
Variable de entorno
Detalles de la configuración
ORACLE_BASE
El directorio en el que está instalado todo el software de
Oracle. Por ejemplo, /u01/app/oracle.
ORACLE_HOME
El directorio en el que se ha instalado Oracle Database
en relación con el valor de $ORACLE_BASE. Por ejemplo,
$ORACLE_BASE/product/10.2.0.4.0/db_1.
ORACLE_SID
El nombre de la base de datos que ha creado para Tivoli
Provisioning Manager, por ejemplo, ctginst1. Si tiene más
de una instancia de base de datos, asegúrese de que
especifica la instancia de base de datos de Tivoli
Provisioning Manager.
.PATH
La variable PATH debe incluir $HOME/bin y
$ORACLE_HOME/bin
PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin
Linux
LD_LIBRARY_PATH
AIX
LIBPATH
La vía de acceso a la biblioteca de Oracle.
Linux
$LD_LIBRARY_PATH:$ORACLE_HOME/lib
AIX
$LIBPATH:$ORACLE_HOME/lib
3. Si el valor del parámetro plsql_compiler_flag se establece en NATIVE, debe
especificar un valor para el parámetro plsql_native_library_dir para instalar
correctamente el servicio de gestor de dispositivos.
Establezca el valor de plsql_native_library_dir en el directorio donde se
almacenan los objetos compartidos generados por el compilador PL/SQL
nativo. Por ejemplo:
ALTER SYSTEM SET plsql_native_library_dir = '/u01/app/oracle/product/10.2.0.4.0/plsql_libs';
Para obtener más información, consulte la documentación de Oracle.
4. Establezca el valor de OPEN_CURSORS en 500, como lo recomienda Oracle:
ALTER SYSTEM SET OPEN_CURSORS=500
5. Compruebe la lista de bases de datos en el archivo oratab:
108
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
a. Si el archivo contiene varias bases de datos con el mismo nombre, suprima
o comente las entradas adicionales.
b. Agregue o edite la línea siguiente al final del archivo:
<nombre_bd_global>:<inicio_oracle>:Y
Por ejemplo, ctginst1:/u01/app/oracle/product/10.2.0.4.0/db_1:Y
Instalación del cliente de Oracle Database en AIX, Linux (x86 64 bits) y Solaris:
El cliente de Oracle Database debe instalarse en el sistema donde instalará el
sistema Tivoli Provisioning Manager.
Antes de empezar
1. Compruebe que el sistema reúne los requisitos de hardware y software de la
Oracle Database. Para obtener más información, consulte la documentación de
Oracle.
2. Inicie la sesión como root.
3.
AIX
Ejecute el mandato smit chgsys para establecer el número máximo
de procesos por usuario. Verifique que el valor de Número máximo de
PROCESOS sea 2048 o más.
4.
AIX
Ejecute el mandato lsps -a para verificar el espacio de paginación y
luego ejecute el mandato chps -s para aumentar el espacio, si es necesario.
Utilice las siguientes directrices:
Tabla 49. Espacio de paginación para AIX
RAM
Espacio de intercambio
Entre 1024 MB y 2048 MB
1,5 veces el tamaño de RAM
Entre 2049 MB y 8192 MB
Igual al tamaño de RAM
Más de 8192 MB
0,75 veces el tamaño de RAM
Por ejemplo, el siguiente mandato agrega tres particiones lógicas de 128 MB al
espacio de paginación hd6:
chps -s 3 hd6
Para obtener más información, consulte la documentación de AIX.
5. Cree y configure el usuario oracle:
a. Cree los grupos oinstall (establecer como el grupo primario) y dba y
agregue el usuario oracle a los grupos.
b. Asegúrese de que /home/oracle sea el directorio padre del usuario oracle.
AIX
El directorio padre del usuario oracle debe tener un archivo
.profile, el cual debe incluir las líneas siguientes:
umask 022
export AIXTHREAD_SCOPE=S
6. Configure el directorio base para los productos Oracle:
a. Cree el directorio base, por ejemplo, /u01/app/oracle. El directorio de
instalación de Oracle Database se creará en este directorio.
b. Configure la propiedad de este directorio en el usuario oracle y el grupo
oinstall. Por ejemplo, ejecute el siguiente mandato:
chown -R oracle:oinstall /u01/app/oracle
c. Establezca los permisos 775 para el directorio de instalación, todos sus
directorios padre y todos sus subdirectorios. Por ejemplo, si el directorio de
Capítulo 3. Tareas previas a la migración
109
instalación es /u01/app/oracle, debe establecer 755 permisos para /u01,
/u01/app, /u01/app/oracle y para todos los subdirectorios de
/u01/app/oracle. Ejecute el mandato siguiente:
chmod -R 775 /u01
Para instalar el cliente de Oracle Database:
1. Establezca los permisos 755 para el directorio donde va a instalar el cliente de
Oracle y todos sus subdirectorios. Ejecute el siguiente mandato para cambiar
los permisos.
chmod -R 755 dir_destino
donde dir_destino es el directorio en el que está instalando el cliente de Oracle
Database.
Nota: Si el directorio de instalación está bajo el directorio padre del usuario
oracle, el directorio padre y todos sus subdirectorios deben tener permisos 750.
Este permiso se necesita porque el usuario tioadmin estará en el mismo grupo
primario que oracle y necesita acceso para ejecutar mandatos sqlplus.
2. Inicie la sesión como usuario oracle.
3. Inicie el cliente de Oracle Database. Cuando se le solicite el tipo de instalación,
seleccione Administrador del cliente de Oracle 10g o Administrador.
Qué hacer a continuación
1. Compruebe que las herramientas de exportación exp e imp estén en el
subdirectorio bin del directorio de instalación del cliente de Oracle Database.
2. Compruebe que se hayan establecido las variables de entorno siguientes:
v LD_LIBRARY_PATH o LIBPATH incluye el directorio $ORACLE_HOME/lib.
v NLS_LANG contiene la información del entorno local para el servidor de
Tivoli Provisioning Manager.
3. Cree el archivo $ORACLE_HOME/network/admin/tnsnames.ora y configure los
valores necesarios. Para asegurarse de que el cliente de Oracle pueda
comunicarse con el servidor de Oracle, asegúrese de que el identificador del
sistema (SID) esté configurado con el nombre de host correcto. El nombre de
servicio debe contener el nombre de la instancia de base de datos y el nombre
de host del servidor Oracle completo. En el siguiente ejemplo,
oracleserver.example.com es el nombre de host del servidor de Oracle.
ctginst1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oracleserver.example.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ctginst1)
)
)
Si la configuración tiene varias instancias de base de datos, escriba el nombre
completo del nombre de servicio, por ejemplo, SERVICE_NAME =
ctginst1.oracleserver.example.com.
Verificación de la instalación de la base de datos Oracle:
Antes de realizar el paso siguiente del proceso de instalación, compruebe que se ha
iniciado la base de datos y que puede conectarse a la base de datos.
Para verificar la instalación:
110
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
1. Cambie al usuario de Por ejemplo, si el nombre de usuario es oracle:
su - oracle
2. Abra el archivo $ORACLE_HOME/bin/dbstart y sustituya la línea
ORACLE_HOME_LISTNER por ORACLE_HOME_LISTNER=$ORACLE_HOME
3. Inicie el escucha de Oracle Database:
$ORACLE_HOME/bin/lsnrctl start
4. Inicie Oracle Database:
dbstart
5. Verifique la conexión con el servicio Oracle. Si Oracle está instalado en otro
sistema, compruebe que pueda establecer conexión desde el cliente de Oracle
del sistema de Tivoli Provisioning Manager.
tnsping nombre_bd
donde nombre_bd es el nombre de la base de datos para Tivoli Provisioning
Manager. El nombre de base de datos predeterminado es ctginst1. Si la
conexión es correcta, se muestra un mensaje que indica que la instalación ha
sido satisfactoria.
6. Conecte con la base de datos:
sqlplus sys/contraseña@nombre_bd as sysdba
donde contraseña es la contraseña del usuario sys. Si la conexión es
satisfactoria, se muestra un mensaje Conectado.
7. Si no puede conectarse a la base de datos, ejecute el mandato siguiente en
ORACLE_HOME/bin:
dbua
Configuración manual del servidor de directorios: Debe realizar la configuración
manual del servidor de directorios antes de utilizar el programa de instalación de
Tivoli Provisioning Manager si elige que el programa de instalación de Tivoli
Provisioning Manager no lo configure automáticamente.
Tenga en cuenta que los distintos valores de DN y sufijo que se incluyen en estas
secciones deben sustituirse por los valores aplicables a las jerarquías LDAP
existentes en la organización.
Importante: Cuando especifique valores LDAP en los campos del panel de
instalación de Tivoli Provisioning Manager, entradas en archivos LDIF o valores
que se especifican directamente en una instancia de directorio utilizando las
propias herramientas del servidor de directorios, tenga en cuenta las reglas de
sintaxis específicas del producto para el uso de caracteres especiales en una cadena
LDAP. En la mayoría de los casos, los caracteres especiales deben ir precedidos de
un carácter de escape para que el servidor de directorios pueda leerlos. Si no se
agrega el carácter de escape a los caracteres especiales contenidos en una cadena
LDAP que se utiliza con Tivoli Provisioning Manager, se producirán errores de
Tivoli Provisioning Manager.
Muchos productos de servidores de directorios consideran el carácter en blanco
como un carácter especial que forma parte de la cadena LDAP. Por lo tanto, si
especifica por error una cadena LDAP que contiene un espacio en blanco, por
ejemplo, al final de un valor de campo, y el carácter en blanco no va precedido por
un carácter de escape, aparecerán errores de Tivoli Provisioning Manager que serán
difíciles de resolver.
Capítulo 3. Tareas previas a la migración
111
Consulte la documentación del producto correspondiente a su servidor de
directorios para obtener más información sobre los caracteres especiales en las
cadenas LDAP.
Configuración manual de IBM Tivoli Directory Server:
Para configurar Tivoli Directory Server antes de iniciar el programa de instalación
de Tivoli Provisioning Manager, debe crear una instancia nueva de IBM Tivoli
Directory Server.
Antes de empezar
Nota: No se recomienda compartir una instancia de DB2 entre Tivoli Provisioning
Manager y Tivoli Directory Server. Durante la instalación, se reinicia la instancia de
base de datos, lo cual puede interrumpir la disponibilidad de Tivoli Directory
Server en su empresa. Si está utilizando los programas de instalación
automatizados, se crean instancias diferentes para que las utilice Tivoli
Provisioning Manager y Tivoli Directory Server.
1. Cree un usuario en el sistema y asígnelo al grupo adecuado.
Windows
Cree el usuario idsccmdb y hágalo miembro de los siguientes grupos:
v Administradores de Windows
v DB2ADMNS
v DB2USERS
UNIX y Linux
Cree el usuario idsccmdb y hágalo miembro de los grupos raíz,
db2iadm1 e idsldap. El usuario idsccmdb debe tener asignado root
como grupo primario.
2. Si no se ha iniciado todavía la herramienta Instance Administration Tool,
asegúrese de que haya iniciado una sesión como administrador del sistema e
inicie la herramienta:
Windows
Haga clic en Programas → IBM Tivoli Directory Server 6.2 → Instance
Administration Tool.
UNIX Ejecute /opt/IBM/ldap/V6.2/sbin/idsxinst
3. En Instance Administration Tool, haga clic en Crear una instancia.
4. En la ventana Crear un nuevo servidor de directorios, haga clic en Crear una
nueva instancia del servidor de directorios y haga clic en Siguiente.
5. En la ventana Detalles de la instancia, complete los campos siguientes y haga
clic en Siguiente.
Nombre de usuario
Seleccione idsccmdb como ID de usuario del sistema del usuario que
será el propietario de la instancia del servidor de directorios. Este
nombre también será el nombre de la instancia del servidor de
directorios.
Ubicación de instalación
Especifique la ubicación donde se almacenarán los archivos de la
instancia del servidor de directorios.
Cadena de semilla de cifrado
Escriba una cadena de caracteres que se utilizará como una semilla de
cifrado. Este valor debe tener un mínimo de 12 caracteres.
112
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Descripción de la instancia
Especifique una breve descripción de la instancia.
6. En el panel de detalles de la instancia de DB2, escriba idsccmdb como el valor
del campo de nombre de instancia de DB2 y luego haga clic en Siguiente.
7. En el panel Valores de TCP/IP para hosts con varias interfaces de red,
seleccione Escuchar en todas las direcciones IP configuradas y haga clic en
Siguiente.
8. En el panel Valores de puerto TCP/IP, complete los campos siguientes y haga
clic en Siguiente.
Número de puerto de servidor
Especifique 389 como puerto de contacto del servidor.
Número de puerto seguro de servidor
Especifique 636 como puerto seguro del servidor.
Número de puerto de daemon de administración
Especifique 3538 como puerto de daemon de administración.
Número de puerto seguro de daemon de administración
Especifique 3539 como puerto seguro de daemon de administración.
9. En el panel Pasos de opciones, deje seleccionadas las siguientes opciones y
haga clic en Siguiente.
Configurar DN y contraseña del administrador
Debe configurar ahora el DN y la contraseña del administrador de la
instancia del servidor de directorios.
Configurar base de datos.
Debe configurar ahora la base de datos para la instancia del servidor
de directorios.
10. En el panel Configurar DN y contraseña del administrador, complete los
campos siguientes y haga clic en Siguiente.
DN del administrador
Especifique cn=root para el nombre distinguido del administrador.
Contraseña del administrador
Especifique una contraseña para el DN de administrador.
11. En el panel Configurar base de datos, complete los campos siguientes y haga
clic en Siguiente.
Nombre de usuario de base de datos
Especifique idsccmdb como usuario de la base de datos.
Contraseña
Especifique la contraseña del usuario idsccmdb.
Nombre de la base de datos
Especifique idsccmdb como la base de datos que se utilizará con esta
instancia de directorio.
12. En el panel Opciones de base de datos, complete los campos siguientes y haga
clic en Siguiente.
Ubicación de instalación de base de datos
Especifique la ubicación donde ha instalado DB2.
Windows
Este valor debe ser una letra de unidad.
Capítulo 3. Tareas previas a la migración
113
UNIX y Linux
La ubicación debe ser un nombre de directorio, por ejemplo,
/home/ldapdb.
Asegúrese de que tiene al menos 80 MB de espacio de disco duro libre
en la ubicación que especifique y que haya espacio de disco adicional
disponible para acomodar el número de entradas nuevas que se
añaden al directorio.
Opción de conjunto de caracteres
Deje seleccionada la opción Crear una base de datos DB2 Universal
Database (UTF-8/UCS-2).
13. En el panel Verificar valores, revise los detalles de creación de instancia que se
proporcionan y haga clic en Finalizar para crear la instancia idsccmdb.
14. Haga clic en Cerrar para cerrar la ventana y volver a la ventana principal de
la herramienta Instance Administration Tool.
15. Haga clic en Cerrar para salir de Instance Administration Tool.
16. Asegúrese de que se haya detenido el servidor.
Windows
IBM Tivoli Directory Server Instance V6.2 - idsccmdb
UNIX V6.2 ibmslapd server daemon
17. Inicie la herramienta de configuración de IBM Tivoli Directory Server:
Windows
Haga clic en Programas → IBM Tivoli Directory Server 6.2 →
Herramienta de administración de instancias.
UNIX Escriba ./opt/IBM/ldap/V6.2/sbin/idsxcfg en la línea de mandatos.
18. Seleccione Gestionar sufijos.
19. En el panel Gestionar sufijos, escriba el siguiente sufijo y haga clic en Agregar.
o=IBM,c=US
20. Haga clic en Aceptar.
21. Cree y guarde un archivo LDIF.
Agregue la información de DN, por ejemplo:
v ou=SWG,o=IBM,c=US
v ou=users
v ou=groups
Nota: ou=SWG,o=IBM,c=US en este ejemplo hace referencia a una unidad
organizativa denominada SWG, que es donde deseamos crear las unidades
organizativas ou=groups y ou=users para colocar los usuarios creados para
Provisioning Manager. DC=IBM y DC=COM indican un bosque de dominios
ibm.com. Sustituya el ejemplo por la estructura de directorios de su propia
organización.
Defina el usuario wasadmin en el archivo LDIF, de modo que VMM pueda
proteger Tivoli Provisioning Manager.
Importante: Antes de crear el archivo de ejemplo, asegúrese de que se ha
creado el usuario wasadmin en el repositorio LDAP.
El siguiente es un ejemplo de un archivo LDIF que utiliza los valores
predeterminados:
114
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
dn: o=ibm,c=us
objectClass: top
objectClass: organization
o: IBM
dn: ou=SWG, o=ibm,c=us
ou: SWG
objectClass: top
objectClass: organizationalUnit
dn: ou=groups,ou=SWG, o=ibm,c=us
ou: groups
objectClass: top
objectClass: organizationalUnit
dn: ou=users,ou=SWG, o=ibm,c=us
ou: users
objectClass: top
objectClass: organizationalUnit
dn: cn=wasadmin,ou=users,ou=SWG, o=ibm,c=us
uid: wasadmin
userpassword: wasadmin
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: person
objectclass: top
title: WebSphere Administrator
sn: wasadmin
cn: wasadmin
Nota: Windows Si crea el archivo LDIF en Windows, elimine los caracteres ^M
del archivo antes de utilizarlo.
22. En la herramienta de configuración de IBM Tivoli Directory Server, haga clic
en Importar datos LDIF.
23. Localice el archivo LDIF y haga clic en Importar.
24. Cierre la herramienta de configuración de IBM Tivoli Directory Server y
reinicie el servidor.
25. Si utiliza una dirección IP virtual en el sistema donde está instalado Tivoli
Directory Server, ejecute el siguiente mandato de DB2 en el sistema:
db2set -g DB2SYSTEM=nombre_host_virtual
Sustituya nombre_host_virtual por el nombre de host virtual.
Ejemplo: si se instala Tivoli Directory Server en un sistema con el nombre de
host virtual ldap.example.com, ejecute este mandato en el sistema
ldap.example.com:
db2set -g DB2SYSTEM=ldap.example.com
Qué hacer a continuación
Continúe en el Instalación de los componentes principales de Tivoli Provisioning
Manager.
Instalación de Microsoft Active Directory:
Debe instalar manualmente Microsoft Active Directory antes de instalar Tivoli
Provisioning Manager.
Capítulo 3. Tareas previas a la migración
115
Antes de empezar
Asegúrese de que el sistema cumpla con los requisitos de hardware y software
para Microsoft Active Directory en Windows 2003. Los requisitos para su uso con
Tivoli Provisioning Manager incluyen:
v Microsoft Active Directory debe estar instalado en otro sistema.
v Está instalado el último Service Pack de Windows 2003.
v La tarjeta de red primara tiene una dirección IP estática. Esta configuración es
necesaria para los subsistemas DNS y Active Directory.
1. Haga clic en Inicio → Panel de control → Conexiones de red.
2. Haga clic con el botón derecho del ratón en la conexión que represente el
adaptador de red primario y haga clic en Propiedades.
3. Seleccione Protocolo Internet (TCP/IP) y haga clic en Propiedades.
4. Asegúrese de que Utilizar la siguiente dirección IP esté seleccionado y
especifique la dirección IP y la máscara de subred correspondientes al
servidor. Agregue una pasarela si es necesario.
5. Especifique la dirección IP del servidor en el campo Servidor DNS
preferido.
v Instale y configure el servicio DNS. Si no está instalado actualmente, siga los
pasos siguientes:
1. En el Panel de control de Windows, haga doble clic en Agregar o quitar
programas y luego haga clic en Agregar o quitar componentes de Windows.
2. Haga clic en Servicios de red en la lista de componentes, pero no marque el
recuadro de selección si aún no estaba seleccionado. Haga clic en Detalles y
marque el recuadro de selección Sistema de nombres de dominio.
3. Haga clic en Aceptar y luego en Siguiente y complete la instalación de DNS.
Para instalar Microsoft Active Directory:
1. Asegúrese de que inicia sesión en el sistema con una cuenta de administrador
para llevar a cabo la instalación.
2. Haga clic en Inicio → Herramientas administrativas → Configurar el servidor.
3. En la página de bienvenida, haga clic en Siguiente.
4. En el panel de compatibilidad del sistema operativo, haga clic en Siguiente.
5. En el panel Tipo de controlador de dominio, seleccione Controlador de
dominio para un nuevo dominio y haga clic en Siguiente.
6. En el panel Crear nuevo dominio, seleccione Dominio en un nuevo bosque y
haga clic en Siguiente.
7. En el panel Nuevo nombre de dominio, especifique el sufijo de DNS
correspondiente al nuevo Active Directory. Este nombre se utilizará durante la
instalación de Tivoli Provisioning Manager, de modo que es mejor que lo
anote. Haga clic en Siguiente.
8. En el panel Nombre de dominio de NetBIOS, especifique el nombre de
NetBIOS del dominio. La primera parte del nombre de DNS suele ser
suficiente. Haga clic en Siguiente.
9. En el panel Base de datos y registros, seleccione las carpetas para la Base de
datos y los Registros. C:\Windows\NTDS es el valor predeterminado., Haga
clic en Siguiente.
10. En el panel Volumen del sistema compartido, especifique un directorio válido
para el volumen del sistema. C:\Windows\Sysvol es el valor predeterminado.
Haga clic en Siguiente para continuar.
116
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
11. Si ha configurado DNS correctamente, se muestra el panel Valor de permisos.
Seleccione Permisos compatibles solo con Windows 2000 o Windows Server
2003. Haga clic en Siguiente.
12. En el panel Contraseña de administrador del Modo de restauración de
servicios de directorio, especifique una contraseña válida que se utilizará para
ejecutar los servicios de directorio en modo de restauración. Haga clic en
Siguiente
13. Verifique los valores y haga clic en Siguiente para comenzar la configuración
de Active Directory. El servidor se volverá a arrancar como parte del proceso.
Qué hacer a continuación
Ahora ya está preparado para configurar Microsoft Active Directory.
Configuración de Microsoft Active Directory para 7.1.1:
Se deben crear usuarios y grupos específicos para la versión 7.1.1. Después de
instalar Microsoft Active Directory, o si está realizando la migración utilizando un
Microsoft Active Directory existente, asegúrese de que se crean los usuarios y
grupos necesarios utilizando esta configuración.
Antes de empezar
Importante: Los usuarios y contraseñas creados en los pasos siguientes deben
coincidir con esta configuración exacta para que el despliegue se realice
correctamente. Es posible que sea necesario alterar temporalmente la política de
seguridad de Microsoft Active Directory para permitir que se creen estas cuentas
en el formato descrito. Una vez realiza correctamente la instalación, se pueden
modificar estas contraseña predeterminadas para que cumplan con una política de
seguridad más estricta.
Microsoft Active Directory no da soporte a grupos y usuarios con el mismo
nombre en la misma unidad organizativa (ou). Si está migrando a la versión 7.1.1
utilizando un Microsoft Active Directory existente, compruebe la configuración
actual. Si los usuarios y grupos están en la misma unidad organizativa, sepárelos
mientras completa los pasos de configuración siguientes.
Para configurar manualmente un recurso de Microsoft Active Directory para poder
utilizarlo con el programa de instalación de Tivoli Provisioning Manager, siga estos
pasos antes de instalar Tivoli Provisioning Manager 7.1.1:
1. Haga clic en Inicio → Panel de control → herramientas de administración →
Microsoft Active Directory Usuarios y equipos y luego seleccione el dominio
con el que trabajará.
2. Edite el nivel funcional del dominio seleccionando Acción → Subir el nivel
funcional del dominio.
3. Seleccione Microsoft Windows Server 2003 en el menú desplegable
Seleccionar un nivel funcional de dominio disponible y luego haga clic en
Subir.
4. Haga clic en Aceptar.
5. Cuando la tarea de subir el dominio haya finalizado, haga clic en Aceptar.
6. En la interfaz de usuario de Usuarios y equipos de Microsoft Active Directory,
haga clic con el botón derecho del ratón sobre el dominio con el que desea
trabajar y seleccione Nueva → Unidad organizativa.
Capítulo 3. Tareas previas a la migración
117
7. Especifique un nombre para la nueva Unidad organizativa (OU), por ejemplo,
SWG y haga clic en Aceptar.
8. Cree un objeto de grupo en la unidad organizativa SWG:
a. Haga clic con el botón derecho del ratón sobre la OU SWG y seleccione
Nueva → Unidad organizativa.
b. Especifique Grupos como nombre de la nueva OU y haga clic en Aceptar.
9. Cree un objeto de usuarios en la unidad organizativa SWG:
a. Haga clic con el botón derecho del ratón sobre la OU SWG y seleccione
Nueva → Unidad organizativa.
b. Especifique Usuarios como nombre de la nueva OU y haga clic en
Aceptar.
10. Cree el grupo MAXADMIN:
a. Haga clic con el botón derecho del ratón sobre la OU Grupos y seleccione
Nuevo → Grupo.
b. En el diálogo Nuevo objeto - Grupo, especifique los siguientes valores y
haga clic en Aceptar:
Nombre de grupo
Escriba MAXADMIN como el nombre de grupo.
Este valor debe ir en mayúsculas.
Nombre de grupo (anterior a Windows 2000)
Escriba MAXADMINPRE2K como el nombre de grupo anterior a
Windows 2000.
Este valor debe ir en mayúsculas y debe ser distinto al nombre
especificado anteriormente como Nombre de grupo.
Ámbito de grupo
Global
Tipo de grupo
Seguridad
11. Cree el grupo MAXIMOUSERS:
a. Haga clic con el botón derecho del ratón sobre la OU Grupos y seleccione
Nuevo → Grupo.
b. En el diálogo Nuevo objeto - Grupo, especifique los siguientes valores y
haga clic en Aceptar:
Nombre de grupo
Escriba MAXIMOUSERS como el nombre de grupo.
Este valor debe ir en mayúsculas.
Nombre de grupo (anterior a Windows 2000)
Escriba MAXIMOUSERS como el nombre de grupo anterior a Windows
2000.
Este valor debe ir en mayúsculas.
Ámbito de grupo
Global
Tipo de grupo
Seguridad
12. Cree el usuario wasadmin:
118
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
a. Haga clic con el botón derecho del ratón sobre la OU Usuarios y seleccione
Nuevo → Usuario.
b. En el diálogo Nuevo objeto - Usuario, especifique los siguientes valores y
haga clic en Siguiente:
Nombre
Escriba wasadmin.
Iniciales
Deje este campo en blanco.
Apellidos
Deje este campo en blanco.
Nombre completo
Escriba wasadmin.
Nombre de inicio de sesión de usuario
Escriba wasadmin en el primer campo. Deje el valor
predeterminado del segundo campo.
Nombre de inicio de sesión de usuario (anterior a Windows 2000)
Este campo debe rellenarse con el mismo valor (wasadmin)
especificado para el Nombre de inicio de sesión de usuario.
c. En el siguiente panel, especifique la siguiente información y haga clic en
Siguiente:
Contraseña
Especifique una contraseña de 7 caracteres para wasadmin.
El usuario debe cambiar la contraseña en el siguiente inicio de sesión.
Asegúrese de que este recuadro de selección esté deseleccionado.
El usuario no puede cambiar la contraseña
Asegúrese de que este recuadro de selección esté seleccionado.
La contraseña nunca caduca
Asegúrese de que este recuadro de selección esté seleccionado.
La cuenta está deshabilitada
Asegúrese de que este recuadro de selección esté deseleccionado.
Los valores anteriores son ejemplos. Debe establecer estos campos en
valores que cumplan la directiva de contraseñas de su organización.
d. Revise los valores de contraseña del panel de resumen y haga clic en
Finalizar.
13. Cree el usuario maxadmin:
a. Haga clic con el botón derecho del ratón sobre la OU Usuarios y seleccione
Nuevo → Usuario.
b. En el diálogo Nuevo objeto - Usuario, especifique los siguientes valores y
haga clic en Siguiente:
Nombre
Escriba maxadmin.
Iniciales
Deje este campo en blanco.
Apellidos
Deje este campo en blanco.
Nombre completo
Escriba maxadmin.
Capítulo 3. Tareas previas a la migración
119
Nombre de inicio de sesión de usuario
Escriba maxadmin en el primer campo. Deje el valor
predeterminado del segundo campo.
Nombre de inicio de sesión de usuario (anterior a Windows 2000)
Este campo debe rellenarse con el mismo valor (maxadmin)
especificado para el Nombre de inicio de sesión de usuario.
c. En el siguiente panel, especifique la siguiente información y haga clic en
Siguiente:
Contraseña
Especifique maxadmin como contraseña del usuario maxadmin.
Este valor de contraseña es necesario para el programa de
instalación de Provisioning Manager.
Si debe utilizar un valor de contraseña diferente para este usuario,
difiera el paso de configuración de la instalación, modifique los
valores de la propiedad y complete la configuración utilizando el
programa de utilidad taskrunner.
Complete los pasos siguientes si decide utilizar un valor diferente
para la contraseña maxadmin:
1) Complete la instalación y configuración de middleware,
incluidas las tareas de configuración manual de Microsoft
Active Directory que se describen en este tema, suministrando
un valor de contraseña distinto a maxadmin para el usuario
maxadmin.
2) Inicie la instalación de los servicios básicos. En el panel
Ejecutar el paso de configuración, seleccione la opción Copiar
ahora los archivos y realizar la configuración de instalación
manualmente más tarde. Complete la instalación de los
servicios básicos.
3) Ejecute manualmente la instalación de los componentes
principales:
Windows
install\bin\setupwinAMD64.exe -W Wzd_SetDisableMaxadmin_LDAP.active="False"
o bien
Windows
install\bin\setupwin32.exe -W Wzd_SetDisableMaxadmin_LDAP.active="False"
AIX
install/bin/setupAix64.bin -W Wzd_SetDisableMaxadmin_LDAP.active="False"
Linux
install/bin/setupLinux.bin -W Wzd_SetDisableMaxadmin_LDAP.active="False"
install/bin/setupSolarisSparc64.bin -W Wzd_SetDisableMaxadmin_LDAP.active="False"
Complete la instalación.
4) Edite el archivo Maximo_HOME\etc\install.properties y
proporcione el valor que desea para la propiedad
mxe.adminPasswd.
5) Complete la configuración de producto utilizando el programa
de utilidad taskrunner:
120
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Maximo_HOME\scripts\taskrunner CONTINUE <STOPONERROR|NOSTOPONERROR>
6) Edite el archivo Maximo_HOME\maximo\reports\birt\tools\
reporttools.properties y proporcione el mismo valor de
contraseña para la propiedad maximo.report.birt.password.
7) Importante: en el paso de componentes principales, debe
ejecutar el archivo ejecutable con un distintivo de alteración
temporal de bean. Esto le permitirá especificar un nombre de
usuario diferente, en lugar de maxadmin en el panel LDAP:
install/bin/[platform binary] -W Wzd_SetDisableMaxadmin_LDAP.active="False"
Por ejemplo, para Windows de 64 bits:
install/bin/setupwinAMD64.exe -W Wzd_SetDisableMaxadmin_LDAP.active="False"
El usuario debe cambiar la contraseña en el siguiente inicio de sesión.
Asegúrese de que este recuadro de selección esté deseleccionado.
El usuario no puede cambiar la contraseña
Asegúrese de que este recuadro de selección esté seleccionado.
La contraseña nunca caduca
Asegúrese de que este recuadro de selección esté seleccionado.
La cuenta está deshabilitada
Asegúrese de que este recuadro de selección esté deseleccionado.
Los valores anteriores son ejemplos. Debe establecer estos campos en
valores que cumplan la directiva de contraseñas de su organización.
d. Revise los valores de contraseña del panel de resumen y haga clic en
Finalizar.
14. Cree el usuario mxintadm:
a. Haga clic con el botón derecho del ratón sobre la OU Usuarios y seleccione
Nuevo → Usuario.
b. En el diálogo Nuevo objeto - Usuario, especifique los siguientes valores y
haga clic en Siguiente:
Nombre
Escriba mxintadm.
Iniciales
Deje este campo en blanco.
Apellidos
Deje este campo en blanco.
Nombre completo
Escriba mxintadm.
Nombre de inicio de sesión de usuario
Escriba mxintadm en el primer campo. Deje el valor
predeterminado del segundo campo.
Nombre de inicio de sesión de usuario (anterior a Windows 2000)
Este campo debe rellenarse con el mismo valor (mxintadm)
especificado para el Nombre de inicio de sesión de usuario.
c. En el siguiente panel, especifique la siguiente información y haga clic en
Siguiente:
Contraseña
Especifique un valor de 7 caracteres como contraseña del usuario
mxintadm.
Capítulo 3. Tareas previas a la migración
121
El usuario debe cambiar la contraseña en el siguiente inicio de sesión.
Asegúrese de que este recuadro de selección esté deseleccionado.
El usuario no puede cambiar la contraseña
Asegúrese de que este recuadro de selección esté seleccionado.
La contraseña nunca caduca
Asegúrese de que este recuadro de selección esté seleccionado.
La cuenta está deshabilitada
Asegúrese de que este recuadro de selección esté deseleccionado.
Los valores anteriores son ejemplos. Debe establecer estos campos en
valores que cumplan la directiva de contraseñas de su organización.
d. Revise los valores de contraseña del panel de resumen y haga clic en
Finalizar.
15. Cree el usuario maxreg:
a. Haga clic con el botón derecho del ratón sobre la OU Usuarios y seleccione
Nuevo → Usuario.
b. En el diálogo Nuevo objeto - Usuario, especifique los siguientes valores y
haga clic en Siguiente:
Nombre
Escriba maxreg.
Iniciales
Deje este campo en blanco.
Apellidos
Deje este campo en blanco.
Nombre completo
Escriba maxreg.
Nombre de inicio de sesión de usuario
Escriba maxreg en el primer campo. Deje el valor predeterminado
del segundo campo.
Nombre de inicio de sesión de usuario (anterior a Windows 2000)
Este campo debe rellenarse con el mismo valor (maxreg)
especificado para el Nombre de inicio de sesión de usuario.
c. En el siguiente panel, especifique la siguiente información y haga clic en
Siguiente:
Contraseña
Especifique un valor de 7 caracteres como contraseña del usuario
maxreg.
El usuario debe cambiar la contraseña en el siguiente inicio de sesión.
Asegúrese de que este recuadro de selección esté deseleccionado.
El usuario no puede cambiar la contraseña
Asegúrese de que este recuadro de selección esté seleccionado.
La contraseña nunca caduca
Asegúrese de que este recuadro de selección esté seleccionado.
La cuenta está deshabilitada
Asegúrese de que este recuadro de selección esté deseleccionado.
Los valores anteriores son ejemplos. Debe establecer estos campos en
valores que cumplan la directiva de contraseñas de su organización.
122
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
d. Revise los valores de contraseña del panel de resumen y haga clic en
Finalizar.
16. Agregue usuarios al grupo MAXADMIN:
a. Haga clic en el objeto Grupos en la OU SWG.
b. Haga clic con el botón derecho del ratón sobre el grupo MAXADMIN que
aparece en el panel Grupos.
c. En el diálogo de propiedades de MAXADMIN, seleccione el separador
Miembros y haga clic en Agregar.
d. En el diálogo Seleccionar usuarios, contactos, equipos o grupos, haga clic
en Avanzados.
e. En el panel Avanzados, haga clic en Buscar ahora.
f. En la lista Resultados de la búsqueda, seleccione los usuarios maxadmin y
mxintadm y, a continuación, haga clic en Aceptar. Asegúrese de que ha
seleccionado el usuario maxadmin y no el grupo maxadmin en la lista.
g. Haga clic en Aceptar para agregar los usuarios.
17. Agregue usuarios al grupo MAXIMOUSERS:
a. Haga clic en el objeto Grupos en la OU SWG.
b. Haga clic con el botón derecho del ratón sobre el grupo MAXIMOUSERS
que aparece en el panel Grupos.
c. En el diálogo de propiedades de MAXIMOUSERS, seleccione el separador
Miembros y haga clic en Agregar.
d. En el diálogo Seleccionar usuarios, contactos, equipos o grupos, haga clic
en Avanzados.
e. En el panel Avanzados, haga clic en Buscar ahora.
f. En la lista Resultados de la búsqueda, seleccione los usuarios maxadmin,
mxintadm y maxreg. A continuación, haga clic en Aceptar. Asegúrese de
que ha seleccionado el usuario maxadmin y no el grupo maxadmin en la
lista.
g. Haga clic en Aceptar para agregar los usuarios.
18. Salga de la interfaz de usuario Usuarios y equipos de Microsoft Active
Directory.
Protección de WebSphere Application Server con Microsoft Active Directory utilizando el
programa de instalación de middleware:
Si tiene una instancia existente de Microsoft Active Directory, puede utilizarla para
proteger WebSphere Application Server cuando lo instala en el sistema. Se puede
configurar manualmente o utilizando el programa de instalación de middleware.
Antes de empezar
Tenga en cuenta que antes de ejecutar el programa de instalación de Provisioning
Manager, debe crear manualmente los usuarios y grupos que se especifican en
“Configuración de Microsoft Active Directory para 7.1.1” en la página 117. Este
paso se puede realizar después de instalar el middleware utilizando el programa
de instalación de middleware, pero se debe completar antes de comenzar a utilizar
el programa de instalación de Provisioning Manager.
El programa de instalación de middleware le solicitará los parámetros de
configuración de LDAP que se utilizarán con WebSphere Application Server.
Capítulo 3. Tareas previas a la migración
123
Para que el programa de instalación de middleware utilice una instancia de
Microsoft Active Directory existente para proteger a WebSphere Application Server,
siga estos pasos:
1. Inicie la sesión como usuario con autorización administrativa.
2. Inicie el programa de instalación de middleware desde el Launchpad.
3. Vaya a los paneles del programa de instalación de middleware como se indica
en “Instalación del middleware con el instalador de middleware” en la página
83, hasta que llegue al panel de Opciones de despliegue.
4. En el panel Opciones de despliegue, deseleccione la opción de despliegue del
servidor de directorios y haga clic en Siguiente. En el siguiente panel, tendrá
la opción de seleccionar una instancia existente de IBMTivoli Directory Server
o Microsoft Active Directory para proteger WebSphere Application Server.
5. En la ventana Resumen del plan de despliegue, haga clic en Siguiente para
configurar los parámetros que se muestran. Se genera el plan de despliegue y
se proporcionan los detalles sobre el plan.
6. En el panel Nombre de host configurable, si desea especificar manualmente el
nombre de host de la máquina en la que está ejecutando la instalación,
seleccione Alterar temporalmente el nombre de host de la máquina local y
escriba un valor de nombre de host en el campo Nombre de host. Seleccione
esta opción únicamente si desea especificar manualmente el nombre de host
del sistema, en lugar de hacer que el programa de instalación lo detecte de
forma programada. Esta opción resulta útil cuando se ha asignado más de un
solo nombre de host al sistema, por ejemplo, en los caos en los que un sistema
tiene más de una interfaz de red o cuando se ha configurado para dar soporte
a direcciones IP virtuales. Cuando se selecciona esta opción, es necesario que
proporcione un nombre de host que se pueda resolver. No puede
deseleccionar esta opción una vez seleccionada, no obstante, puede cambiar el
valor del campo Nombre de host. Si ha iniciado el programa de instalación de
middleware desde la línea de mandatos utilizando el parámetro
forceHostname=true, se le solicitará que proporcione un valor alfanumérico
en el campo Nombre de host. Una dirección IP generará un mensaje de error.
Cuando haya seleccionado esta opción, no podrá deseleccionarla. No obstante,
podrá cambiar el valor del campo Nombre de host.
7. En el panel Reutilización de contraseñas, puede seleccionar Utilizar el valor
de esta contraseña en las siguientes contraseñas, escribir un valor de
contraseña y luego hacer clic en Siguiente, lo cual le permitirá utilizar la
misma contraseña que el valor de contraseña de usuario predeterminado en
todos los paneles del programa de instalación de middleware. Si no desea
utilizar esta opción, ignore la opción Utilizar el valor de esta contraseña en
las siguientes contraseñas y haga clic en Siguiente.
8. Seleccione Proteger con Microsoft Active Directory y haga clic en Siguiente.
9. Configure los valores siguientes para la seguridad de WebSphere Application
Server y luego haga clic en Siguiente.
Nombre de host de LDAP
Especifique el nombre completo del servidor que aloja Microsoft
Active Directory.
Puerto del servidor de directorios
Especifique el puerto del servidor de directorios. Por ejemplo, 389.
Entrada básica LDAP
Especifique la entrada básica LDAP de la instancia. Por ejemplo,
DC=itsm,DC=com.
124
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Sufijo de usuario
Especifique el sufijo de usuario de la instancia. Por ejemplo,
OU=Users,OU=SWG,DC=itsm,DC=com.
Sufijo de grupo
Especifique el sufijo de grupo de la instancia. Por ejemplo,
OU=Groups,OU=SWG,DC=itsm,DC=com.
Sufijo de contenedor de organización
Especifique el sufijo de contenedor de organización de la instancia.
Por ejemplo, DC=itsm,DC=com.
En este ejemplo, itsm es el nombre de dominio. Debe sustituir itsm
por el nombre de su propio dominio.
10. Suministre los valores de configuración siguientes para WebSphere
Application Server y haga clic en Siguiente.
Nombre distinguido del enlace
Especifique el nombre distinguido de enlace de la instancia. Por
ejemplo, CN=Administrator,CN=Users,DC=itsm,DC=com.
Este valor presupone que el usuario administrador ya es miembro del
dominio itsm. Debe sustituir itsm por el nombre de su propio
dominio.
Contraseña del enlace
Especifique la contraseña del usuario administrador en el sistema que
aloja Microsoft Active Directory.
11. Complete la instalación navegando por el resto de los paneles del programa
de instalación de middleware.
Instalación del middleware en Solaris
Las aplicaciones de middleware que no puede instalar el programa del instalador
de middleware se instalan mediante los programas de instalación gráficos que se
proporcionan con cada producto de middleware.
Puede utilizar los pasos de esta sección para instalar los siguientes productos en
Solaris 10 SPARC:
v IBM DB2 Enterprise Server Edition 9.5 FP3a
v IBM WebSphere Application Server Network Deployment 6.1.0.23
v IBM Tivoli Directory Server 6.2.0.2
v IBM HTTP Server 6.1 FP23
Para obtener información acerca de cómo instalar la base de datos Oracle, consulte
Instalación de Oracle Database.
Requisitos de Solaris 10
Es posible que algunos parámetros de configuración del kernel en Solaris 10 no
sean suficientes para ejecutar IBM DB2 9.5.
Para asegurarse de que el sistema Solaris tiene los parámetros del kernel
necesarios, debe ejecutar el programa de utilidad db2osconf después de instalar
IBM DB2, pero antes de crear los objetos de base de datos. Para obtener más
información, consulte Modificación de los parámetros del kernel (sistema operativo
Solaris) en el centro de información de DB2.
Capítulo 3. Tareas previas a la migración
125
Instalación de los componentes
Después de configurar el sistema operativo tal y como sea necesario, instale los
componentes de middleware.
Los componentes de middleware se instalan en el orden siguiente:
1. IBM DB2
2. IBM Tivoli Directory Server
3. IBM WebSphere Application Server Network Deployment
4. IBM HTTP Server
Nota: El soporte del sitio web que utilice para instalar el middleware tiene
ubicaciones específicas para cada uno de los sistemas operativos soportados. La
estructura de directorios es sistema_operativo/producto.
Para visualizar los directorios bajo el directorio sistema_operativo/producto,
ejecute:
cd sistema_operativo
ls
Dentro de cada subdirectorio sistema_operativo, puede encontrar los directorios de
instalación para cada producto de middleware. Por ejemplo:
ls solaris64
DB2-ESE_9.5
DB2-ESE_9.5_FP3a
TIV-DirectoryServer_6.2.0
WS-ESS_6.1_GA
WS-WAS_IHS_6.1.0_FP23
WS-WAS_ND6.1.0.23_Custom_ISCAE71
WS-WAS_ND_6.1.0_Supplemental
WS-WAS_Plugins_6.1.0_FP23
WS-WAS_UpdateInstaller_7.0.0.3
Instalación de DB2 en Solaris:
Ejecute el programa db2setup para instalar DB2.
Antes de empezar
Revise los requisitos en el centro de información de DB2 en http://
publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp para obtener
información específica del sistema operativo.
Antes de iniciar el asistente de configuración de DB2, tenga en cuenta lo siguiente:
v db2setup inicia un instalador del sistema, de modo que XWindows debe estar
instalado y en ejecución antes de iniciar el programa instalador DB2. Exporte su
pantalla:
export DISPLAY= su_dirección_ip:0
v Si se utiliza NIS, NIS+ o un software de seguridad similar en el entorno, debe
crear manualmente los usuarios de DB2 necesarios antes de iniciar el asistente
de configuración de DB2. Consulte el tema sobre consideraciones para la gestión
centralizada de usuarios en el centro de información de DB2 en
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/
com.ibm.db2.luw.qb.server.doc/doc/r0007059.html.
v Puede optar por diferir algunas actividades de instalación. Por ejemplo, puede
optar por no establecer las notificaciones por correo electrónico de los sucesos de
126
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
base de datos durante la instalación. Si desea diferir actividades de instalación
específicas, seleccione esta opción y configúrelas después.
v Algunos productos de middleware tienen requisitos o convenios específicos para
nombres de cuentas y otros valores. Altere temporalmente los valores
predeterminados de la instalación, como se muestra, si los valores
predeterminados suministrados no son satisfactorios. En los paneles que
solicitan contraseñas, tanto la contraseña como su entrada de confirmación se
debe especificar antes de que el instalador pueda continuar en el panel siguiente.
Este procedimiento describe cómo se realiza una instalación típica de DB2 en un
solo sistema. Si tiene que instalar los componentes de DB2 en varios sistemas,
consulte el centro de información de DB2.
Las bases de datos deben contener una sola partición y datos Unicode (UTF-8).
De forma predeterminada, DB2 se instala en el directorio /opt/IBM/db2/V9.5.
El directorio /opt/IBM/db2/V9.5/logs contiene un archivo db2install.history.
Este archivo contiene los valores de instalación utilizados y los errores que se
producen durante el proceso de instalación. El archivo vmrfis.history contiene
información acerca del mantenimiento que se ha aplicado a DB2 como, por
ejemplo, los fixpacks que se han instalado.
El archivo db2setup.log captura toda la información de instalación de DB2
incluidos los errores. El archivo db2setup.err captura cualquier salida de error
devuelta por Java™ (por ejemplo, la información de excepciones y trampas). De
forma predeterminada, los dos registros se crean en el directorio /tmp, a menos que
cambie dicha ubicación durante el proceso de instalación.
1. Inicie la sesión como root.
2. Copie el archivo solaris64/DB2-ESE_9.5/DB2_ESE_V95_SUN_SPARC.tar en un
disco grabable.
3. Vaya al directorio donde ha copia el archivo tar y ejecute el mandato
siguiente:tar -xvf NombreArchivotar.tar,
4. Extraiga el archivo DB2_Enterp_Svr_OEM_Activation.zip en un directorio
adecuado. Por ejemplo, solaris64/DB2-ESE_9.5/
5. Inicie el instalador ejecutando ./db2setup.
6. En el launchpad, seleccione Instalar un producto y luego haga clic en Instalar
nuevo.
7. Acepte el acuerdo de licencia.
8. Acepte todos los valores predeterminados, excepto donde deba proporcionar
valores personalizados. Por ejemplo, el valor predeterminado de la dirección
de correo electrónico del destinatario de las notificaciones de correo
electrónico de sucesos de base de datos es nombre_host@nombre_servidor_local.
Este valor se ha de modificar por una dirección de correo electrónico válida si
opta por habilitar las notificaciones SMTP. Este valor también se puede
modificar posteriormente.
9. Deje los recuadros de selección para las opciones GUI y UID seleccionados, ya
que se asignarán automáticamente.
10. En el panel Iniciar copia de archivos y crear archivo de respuestas, haga clic
en Finalizar para iniciar la instalación. En los paneles del instalador de DB2,
cuando se le indique, cree la instancia de base de datos ctginst1 y el usuario
administrador de base de datos ctginst1. Tome nota del puerto de servicio
que se está configurando, cuyo valor predeterminado es 50001.
Capítulo 3. Tareas previas a la migración
127
11. Inicie la instancia de DB2.
12. Cree usuarios del sistema.
a. Inicie una sesión en el sistema como un usuario que tenga permisos
administrativos en el sistema.
b. DB2 requiere cuentas de usuario que sean cuentas de usuario del sistema
operativo. Cree los siguientes usuarios del sistema operativo, utilizando las
herramientas de gestión de usuarios disponibles en el sistema:
v ctginst1
v maximo
c. Asegúrese de que los límites de usuario se hayan configurado
correctamente para el propietario de la instancia de la base de datos. Para
obtener más información, consulte Paso 5 previo a la instalación: Verificar
los requisitos de nombres, contraseñas y cuentas de usuario.
13. Cree y configure la instancia de DB2:
a. Cree la instancia de DB2:
db2icrt -a SERVER -s ese -p 50005 -u db2fenc1 ctginst1
En función del entorno, es posible que tenga que ejecutar este mandato
desde el directorio /opt/ibm/db2/V9.5/instance. De manera alternativa,
puede agregar esta información a la variable PATH.
b. Inicie la instancia de base de datos ctginst1:
su - ctginst1
db2start
14. Registre la licencia del servidor DB2:
a. Cambie al usuario de la instancia:
su - ctginst1
b. Utilice el mandato de la herramienta de gestión de licencias DB2 para
aplicar la licencia:
db2licm -a <vía completa al archivo de licencias>
El archivo de licencia se encuentra en solaris64/DB2-ESE_9.5/
DB2_Enterp_Svr_OEM_Activation/db2/license/db2ese_o.lic.
c. Detenga y luego reinicie la instancia de DB2, utilizando los mandatos
db2stop y db2start respectivamente.
d. Verifique que la licencia se haya instalado correctamente:
db2licm -l
Este mandato debe generar una salida similar a la siguiente:
Product name:
License type:
Expiry date:
Product identifier:
Version information:
"DB2 Enterprise Server Edition"
"Restricted"
"Permanent"
"db2ese"
"9.5"
Qué hacer a continuación
Si no se puede iniciar la base de datos, es posible que sea debido a que los valores
de sysadm_group y svcename no se han configurado correctamente. En este caso,
realice los pasos siguientes:
1. Cambie al usuario de la instancia: su - ctginst1
2. Ejecutar
db2 update dbm cfg using SYSADM_GROUP nombre_grupo
128
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
donde nombre_grupo es el grupo principal del usuario de la instancia. Para
buscar el nombre del grupo, busque el valor de inst1.GROUP_NAME en el archivo
de respuestas de instalación /tmp/db2ese.rsp. Por ejemplo,
db2 update dbm cfg using SYSADM_GROUP db2grp1
Obtendrá un mensaje similar a:
DB20000I El mandato UPDATE DATABASE MANAGER CONFIGURATION se ha completado correctamente.
3. Ejecutar
db2 update dbm cfg using SVCENAME número_puerto
donde número_puerto es el número de puerto de la instancia. Para buscar el
nombre del grupo, busque el valor de inst1.PORT_NUMBER en el archivo de
respuestas de instalación /tmp/db2ese.rsp. Por ejemplo,
db2 update dbm cfg using SVCENAME 50000
Obtendrá un mensaje similar a:
DB20000I El mandato UPDATE DATABASE MANAGER CONFIGURATION se ha completado correctamente.
Después de iniciar la base de datos, continúe en Instalación de los fixpacks de DB2.
Instalación de los fixpacks de DB2:
Instalación del fixpack para DB2 para asegurarse de que tiene instalados los
arreglos más recientes.
Antes de empezar
Detenga todas las instancias de DB2:
Inicie la sesión como root.
Ejecute db2ilist para ver todas las instancias.
Conviértase en el propietario de la instancia (su) de una cuenta de DB2.
Detenga cada instancia ejecutando db2stop instanceName para cada instancia.
Copie el archivo tar del fixpack DB2-ESE_9.5_FP3a/
v9.5fp3a_sun64_server.tar.gz en un disco grabable.
2. Extraiga el archivo:
1.
2.
3.
4.
1.
gzip -dfv nombre_fixpack.tar.gz
3. Desempaquete el archivo:
tar -xvf nombre_fixpack.tar
4. Vaya al directorio /server.
5. Para iniciar la instalación del fixpack, escriba ./installFixPack -b $DB2DIR,
donde $DB2DIR es la ubicación del producto DB2 que desea actualizar, por
ejemplo, /opt/IBM/db2/V9.5.
6. Escriba el directorio de instalación donde ha instalado DB2. La ubicación
predeterminada es un directorio específico de la versión bajo /opt/IBM/db2.
7. Ejecute el mandato update en cada instancia:
DB2DIR/instancia/db2iupdt -e
8. Ejecute el mandato DB2DIR/instancia/dasupdt.
9. Reinicie cada instancia que haya detenido antes de instalar el fixpack.
Instalación de IBM Tivoli Directory Server en Solaris:
Capítulo 3. Tareas previas a la migración
129
Generalmente IBM Tivoli Directory Server se instala en un sistema que no aloja
otros productos de middleware.
1. Inicie la sesión como root.
2. Copie los archivos C1N9LML.tar y C1N9QML.tar desde el directorio
solaris64/TIV-DirectoryServer_6.2.0 a un disco grabable.
3. Extraiga los archivos:
tar -xvf C1N9LML.tar
tar -xvf C1N9QML.tar
4. Vaya al directorio /tdsV6.2/tds y luego escriba ./install_tds.bin
Puede especificar un directorio temporal que no sea el directorio temporal del
sistema. Para utilizar esta opción, cambie los directorios por el directorio
adecuado y escriba lo siguiente en un indicador de mandatos:
./install_tds.bin -is:tempdir directorio
donde directorio es el directorio que desea utilizar para el espacio temporal.
Asegúrese de que tiene al menos 400 MB de espacio libre en este directorio.
Por ejemplo:
./install_tds.bin -is:tempdir /opt/tmp
5. Cuando se inicia el asistente de instalación, seleccione un idioma para
utilizarlo para el proceso de instalación, acepte el acuerdo de licencia y
seleccione una instalación personalizada.
6. Deseleccione DB2 V9.1, Embedded WebSphere Application Server y Tivoli
Directory Integrator y haga clic en Siguiente.
Estos productos los instalará por separado. Se deben seleccionar las opciones
siguientes: Cliente C, Cliente Java, Herramienta de administración Web,
Servidor proxy y Servidor.
7. En el panel Seleccionar WebSphere Application Server, seleccione No
especificar. Lo desplegaré manualmente en otro momento y luego haga clic
en Siguiente.
8. Haga clic en Instalar.
9. Haga clic en Finalizar.
10. Cierre la herramienta de creación de instancias.
11. Cree la instancia idsccmdb. Para obtener más información, consulte
Configuración manual de IBM Tivoli Directory Server.
12. Aplique el archivo de arreglos provisionales 6.2.0.0-TIV-ITDS-SolarisSparcIF0002.tar, del directorio solaris64/TIV-DirectoryServer_6.2.0 del soporte
del producto. Extraiga el archivo de arreglo provisional en un directorio
temporal y luego ejecute ./idsinstall -u.
13. Inicie el servidor de directorios, ejecutando:
a. /opt/ibm/ldap/V6.2/sbin/idsdiradm -I idsccmdb
b. /opt/ibm/ldap/V6.2/bin/idsdirctl -D <ID usuario admin> -w
<contraseña usuario admin>
Instalación de WebSphere Application Server Network Deployment en Solaris:
WebSphere Application Server Network Deployment debe estar instalado y debe
crear dos perfiles que se necesitarán posteriormente.
1. Inicie la sesión como root.
2. Copie el archivo WS-WAS_ND_6.1.0.23_Custom_ISCAE71/WAS-ND_Solaris-SparcCustom_v61023_ISC7106.tar.gz en un disco grabable.
3. Descomprima el archivo:
130
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
gzip -dfv nombre_archivo.gz
4. Extraiga el archivo:
tar -xvf Nombrearchivotar.tar
5.
6.
7.
8.
Elimine los archivos tar y gz.
Vaya al directorio donde ha desempaquetado el archivo tar.
Vaya al directorio WAS.
Escriba ./install
9. Acepte el acuerdo de licencia y acepte los valores predeterminados
suministrados.
10. En el panel de directorio de instalación, acepte el directorio de instalación
predeterminado, que es /opt/IBM/WebSphere/AppServer.
Si cambie el directorio de instalación, no utilice los enlaces simbólicos como el
directorio de destino y no añada caracteres de espacio a la vía de acceso.
11. En el panel de entornos de IBM WebSphere Application Server, seleccione
Ninguno como su entorno y luego haga clic en Siguiente.
Al seleccionar Ninguno creará la célula de despliegue, el perfil del gestor de
despliegue y el perfil del servidor de aplicaciones utilizando la herramienta de
gestión de perfiles.
12. Haga clic en Sí para indicar que desea continuar.
13. Vaya hasta el final de la instalación y haga clic en Finalizar.
Creación de perfiles de WebSphere Application Server Network Deployment en Solaris:
La versión de 64 bits de WebSphere Application Server Network Deployment
incluye la herramienta de línea de mandatos manageprofiles, que utilizará para
crear los perfiles.
Antes de empezar
Asegúrese de que está familiarizado con las limitaciones de caracteres para los
mandatos o el shell que está utilizando. En algunos casos, es posible que tenga que
especificar los mandatos por orden para no sobrepasar estas limitaciones, Consulte
la documentación de WebSphere Application Server Network Deployment para
obtener más información acerca de cómo especificar mandatos largos en más de
una línea.
Los siguientes mandatos pueden ser útiles para gestionar perfiles:
Tabla 50. Mandatos de perfil
Tarea
Mandato
Suprimir un perfil
WAS_HOME/bin/manageprofiles.sh -delete
-profileName nombre_perfil
Renovar el registro de perfiles (por ejemplo,
después de suprimir un perfil)
WAS_HOME/bin/manageprofiles.sh
-validateAndUpdateRegistry
Listar perfiles existentes
WAS_HOME/bin/manageprofiles.sh
-listProfiles
WAS_HOME es igual a la ubicación donde se ha instalado WebSphere Application
Server Network Deployment, por ejemplo, /opt/IBM/WebSphere/AppServer/.
Capítulo 3. Tareas previas a la migración
131
1. Origen del script setupCmdLine.sh en el directorio bin de la carpeta WAS_HOME
para establecer el entorno de WebSphere Application Server Network
Deployment en la instancia de configuración. Generalmente WAS_HOME está
en /opt/IBM/WebSphere/AppServer.
. WAS_HOME/bin/setupCmdLine.sh
2. Cree un archivo de puertos de perfil para el perfil ctgDmgr01. Este archivo se
utilizará en el mandato manageprofiles para establecer los puertos que
utilizará este perfil.
Nota: Es importante asegurarse de que no aparecen espacios después de
ningún valor de este archivo. Si existen espacios de cola adicionales después
de los valores, como puede suceder si se corta y pega un ejemplo, WebSphere
utilizará el espacio como el último carácter de dicho valor. Por ejemplo, es
posible que desee especificar el valor ″WC_adminhost=9060″, pero si se
escribe un espacio adicional después de 9060, el valor se interpretará como
WC_adminhost=9060<espacio>″ (donde <espacio> representa un carácter de
espacio).
a. Cree un nuevo archivo de texto denominado _portdef_DMgr.props y
escriba el texto siguiente:
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9403
WC_adminhost=9060
DCS_UNICAST_ADDRESS=9352
BOOTSTRAP_ADDRESS=9809
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9401
CELL_DISCOVERY_ADDRESS=7277
SOAP_CONNECTOR_ADDRESS=8879
ORB_LISTENER_ADDRESS=9100
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9402
WC_adminhost_secure=9043
b. Coloque el archivo en el directorio WAS_HOME.
3. Cree el perfil ctgDmgr01 utilizando el mandato manageprofiles. Escriba lo
siguiente, en una sola línea, con un espacio entre cada una de las entradas:
WAS_HOME/bin/manageprofiles.sh
-create
-templatePath WAS_HOME/profileTemplates/dmgr
-hostName suhostcompleto
-profileName ctgDmgr01
-profilePath WAS_HOME/profiles/ctgDmgr01
-portsFile WAS_HOME/_portdef_DMgr.props
-cellName ctgCell01
-nodeName ctgCellManager01
-enableAdminSecurity "false"
4. Inicie el servidor ctgDmgr01:
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
5. Cree un archivo de puertos de perfil para el perfil ctgAppSrv01. Este archivo
lo utilizará el mandato manageprofiles para establecer los puertos que
utilizará este perfil.
a. Cree un nuevo archivo de texto denominado _portdef_AppSvr.props y
escriba el texto siguiente:
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9201
DCS_UNICAST_ADDRESS=9353
NODE_DISCOVERY_ADDRESS=7272
NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS=5001
BOOTSTRAP_ADDRESS=2809
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9901
SOAP_CONNECTOR_ADDRESS=8878
132
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
NODE_MULTICAST_DISCOVERY_ADDRESS=5000
ORB_LISTENER_ADDRESS=9101
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9202
b. Coloque el archivo en el directorio WAS_HOME.
6. Cree el perfil ctgAppSrv01 utilizando el mandato manageprofiles:
WAS_HOME/bin/manageprofiles.sh
-create
-templatePath
WAS_HOME/profileTemplates/managed
-hostName suhostcompleto
-profileName ctgAppSrv01
-profilePath WAS_HOME/profiles/ctgAppSrv01
-cellName ctgNodeCell01
-nodeName ctgNode01
-portsFile WAS_HOME/_portdef_AppSvr.props
-dmgrHost suhostcompleto
-dmgrPort 8879
-isDefault
7. Inicie el nodo ctgAppSrv01.
WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
8. Aumente el perfil tgDmgr01:
WAS_HOME/bin/manageprofiles.sh
-augment
-templatePath WAS_HOME/profileTemplates/iscae71
-profileName ctgDmgr01
-serverName dmgr
9. Reinicie los servidores.
WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
WAS_HOME/profiles/ctgAppSrv01/bin/stopNode.sh
WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
10. Inicie firststeps.sh y seleccione la opción Verificación de la instalación para
confirmar que el servidor se ha instalado e iniciado correctamente.
WAS_HOME/profiles/ctgDmgr01/firststeps/firststeps.sh
Instalación del instalador de actualizaciones de WebSphere en Solaris:
Este procedimiento es opcional. Se puede realizar ahora o más tarde, cuando desee
utilizar el instalador de actualizaciones para aplicar mantenimiento. Durante la
instalación inicial del middleware, el mantenimiento no se aplica utilizando el
instalador de actualizaciones.
Antes de empezar
Revise los requisitos previos en http://publib.boulder.ibm.com/infocenter/
wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/
tins_updi_install.html.
El instalador de actualizaciones simplifica el mantenimiento de WebSphere
Application Server Network Deployment y de sus componentes relacionados
como, por ejemplo, el plugin de HTTP Server y los fixpacks.
1. Copie el archivo WS-WAS_UpdateInstaller_7.0.0.3/7.0.0.3-WS-UPDISolarisSparc64.zip en un disco grabable.
2. Descomprima el archivo ejecutando unzip nombre_archivo.zip
3. Vaya al directorio que contiene los archivos que ha extraído y escriba: ./install
4. Acepte el acuerdo de licencia.
Capítulo 3. Tareas previas a la migración
133
5. Acepte el directorio de instalación predeterminado (/opt/IBM/WebSphere/
UpdateInstaller) o cámbielo si lo desea.
6. Antes de finalizar la instalación, deseleccione la opción Iniciar instalador de
actualizaciones de IBM para software WebSphere al salir.
Instalación y configuración de IBM HTTP Server en Solaris:
Este procedimiento proporciona información de tareas para instalar y configurar
manualmente IBM HTTP Server.
1. Inicie la sesión como root, en el sistema donde ha instalado WebSphere
Application Server Network Deployment.
2. Inicie la sesión en la consola de administración de WebSphere y asegúrese de
que el gestor de despliegue de ctgDmgr01 se está ejecutando y que el puerto
SOAP se ha establecido para que escuche en el puerto correcto (8879 es el
número de puerto predeterminado).
Si es necesario iniciar el gestor de despliegue, utilice el mandato siguiente:
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
3. Copie el archivo solaris64/WS-WAS_ND_6.1.0_Supplemental/C943UML.tar.gz en
un disco grabable.
4. Descomprima el archivo C943UML.tar.gz.
5. Extraiga el contenido del archivo C943UML.tar.
6. Cambie al directorio IHS e inicie el programa de instalación:
./install
7. En el panel Bienvenido, haga clic en Siguiente.
8. Acepte el acuerdo de licencia y haga clic en Siguiente.
9. En el panel de requisitos previos del sistema, haga clic en Siguiente.
10. Especifique la ubicación de instalación (el valor predeterminado es
/opt/IBM/HTTPServer) y haga clic en Siguiente.
11. En el panel Asignación de valores de puertos, especifique los siguientes
valores y haga clic en Siguiente.
Puerto HTTP
80
Puerto de administración HTTP
8008
12. En el panel Autenticación del servidor de administración HTTP, especifique
los valores siguientes y haga clic en Siguiente.
Cree un ID de usuario para la autenticación del servidor de administración
de IBM HTTP.
Habilite esta opción seleccionando este recuadro de selección.
ID de usuario
Especifique wasadmin.
Contraseña
Escriba la contraseña para el usuario wasadmin.
13. En el panel Configuración del servidor de administración HTTP, especifique
los valores siguientes y haga clic en Siguiente.
Configure el servidor de administración IBM para que administre IBM
HTTP Server
Habilite esta opción seleccionando este recuadro de selección.
134
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Cree un ID de usuario y grupo exclusivos para la administración de IBM
HTTP Server.
Habilite esta opción seleccionando este recuadro de selección.
ID de usuario
Especifique wasadmin.
Grupo Especifique ihsadmin
14. En el panel Plugin de IBM HTTP para WebSphere Application Server,
especifique los valores siguientes y haga clic en Siguiente.
Instale el plugin de IBM HTTP Server para IBM WebSphere Application
Server Marque o desmarque este recuadro de selección para inhabilitar esta
opción como corresponda a su configuración. En un entorno en el que
tiene varios perfiles de gestor de despliegue, resulta más práctico
ejecutar la tarea de instalación de los plugin de servidor web por
separado ejecutando el programa de instalación de plugin después de
salir del programa de instalación de IBM HTTP Server. No obstante, si
el entorno de WebSphere sólo contiene un perfil de gestor de
despliegue, puede dejar seleccionada la opción de plugin de
WebSphere. Cuando está seleccionada, se inicia la tarea de instalación
de los plugins de servidor web después de hacer clic en Siguiente.
Para obtener más información acerca de los casos de ejemplo de
despliegue para IBM HTTP Server, consulte http://
publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/
com.ibm.websphere.ihs.doc/info/welcome_ihs.html
Si decide instalar ahora el plugin de HTTP Server, debe configurarlo.
Realice estos pasos para configurar el plugin.
a. Detenga e inicie el gestor de despliegue:
WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
b. Copie el archivo /opt/IBM/HTTPServer/Plugins/bin/
configurewebserver1.sh en WAS_HOME/bin/
c. Vaya al directorio WAS_HOME/bin y ejecute:
./configurewebserver1.sh
d. Inicie los servidores HTTP:
/opt/IBM/HTTPServer/bin/adminctl start
/opt/IBM/HTTPServer/bin/apachectl start
e. Inicie la sesión en la consola del administrador de WebSphere y asegúrese
de que se ha iniciado webserver1.
Instalación de los fixpacks de IBM HTTP server en Solaris:
El fixpack 23 de HTTP Server se debe instalar para actualizar la instalación base de
HTTP Server al nivel de mantenimiento más reciente.
1. Copie el archivo solaris64\WS-WAS_IHS_6.1.0_FP23\6.1.0-WS-IHSSolarisSparc64-FP0000023.pak en el directorio /opt/IBM/HTTPServer/
maintenance. Cree este directorio si no existe.
2. Detenga HTTP Server. Escriba /opt/IBM/HTTPServer/bin/apachectl stop
3. Detenga el servidor de administración. Escriba /opt/IBM/HttpServer/bin/
adminctl stop.
4. Detenga WebSphere y los nodos gestionados utilizando los mandatos
siguientes.
Capítulo 3. Tareas previas a la migración
135
a. WAS_HOME/profiles/ctgAppSrv01/bin/stopNode.sh
b. WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
5. Instalar el fixpack.
a. Inicie el asistente del instalador de actualizaciones:
/opt/IBM/WebSphere/UpdateInstaller/update.sh
b. Vaya al directorio /opt/IBM/HTTPServer/maintenance y seleccione el archivo
del fixpack (.pak) de la lista de archivos e instálelo.
6. Inicie HTTP Server. Escriba /opt/IBM/HTTPServer/bin/apachectl start
7. Inicie el servidor de administración. Escriba /opt/IBM/HTTPServer/bin/adminctl
start.
8. Reinicie WebSphere y los nodos gestionados:
a. WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
b. WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
Instalación y configuración del plugin de WebSphere en Solaris:
Este procedimiento proporciona información de tareas para instalar y configurar
manualmente el plugin de WebSphere para IBM HTTP Server. Este procedimiento
es opcional si decide instalar y configurar el plugin WebSphere cuando ha
instalado IBM HTTP Server.
Antes de empezar
1. Inicie la sesión como root en el sistema en el que ha instalado WebSphere.
2. Vaya al directorio en el que anteriormente ha extraído el archivo tar C943UML,
cuando ha instalado IBM HTTP Server. Por ejemplo, solaris64/WSWAS_ND_6.1.0_Supplemental/plugin.
3. Vaya al directorio plugin.
4. Desde una línea de mandatos, inicie el programa de instalación del plugin de
WebSphere.
./install
5. En el panel de bienvenida, deseleccione la opción para obtener más
información Mapa de instalación: Visión general y casos de ejemplo de
instalación. Haga clic en Siguiente.
6. Acepte el acuerdo de licencia y haga clic en Siguiente.
7. en el panel de selección de plugin, seleccione el plugin IBM HTTP Server V6 ó
6.1 y luego haga clic en Siguiente.
8. En el panel del caso de ejemplo de instalación, seleccione Máquina
WebSphere Application Server (local) y luego haga clic en Siguiente.
9. Acepte o cambie el directorio de instalación. El valor predeterminado es
/opt/IBM/HTTPServer/Plugins1 ya que ha decidido instalar después de salir
de la instalación de IBM HTTP Server. Haga clic en Siguiente.
10. Especifique la ubicación donde ha instalado el servidor de aplicaciones. El
valor predeterminado es /opt/IBM/WebSphere/AppServer. Haga clic en
Siguiente.
11. En el panel de selección de perfiles, seleccione ctgDmgr01 en la lista
desplegable y luego haga clic en Siguiente.
12. En el panel del archivo de configuración del servidor web, especifique lo
siguiente:
136
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Seleccione el archivo httpd.conf de IBM HTTP Server
Vaya a la ubicación del archivo httpd.conf. El valor predeterminado
es /opt/IBM/HTTPServer/conf/httpd.conf.
Especifique el puerto del servidor web
El puerto predeterminado es 80.
Si hace clic en Siguiente en este punto es posible que se muestre un mensaje
de aviso que indica que el archivo de configuración de IBM HTTP Server
seleccionado ya contiene entradas de plugin. Si continúa, este archivo de
configuración se actualizará con la nueva ubicación del archivo XML
plugin-cfg nuevo. Haga clic en Aceptar para continuar.
13. En el panel de definición de servidor web, especifique un nombre de
definición de servidor web exclusivo, por ejemplo, webserver1.
14. Acepte el nombre del archivo de configuración del plugin de servidor web
predeterminado plugin-cfg.xml y su ubicación.
15. Haga clic en Siguiente para reconocer los pasos de configuración manuales.
16. En el panel de resumen de la instalación, haga clic en Siguiente.
17. Cuando se haya completado la instalación, haga clic en Finalizar.
18. Detenga e inicie el gestor de despliegue:
WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
19. Copie el archivo /opt/IBM/HTTPServer/Plugins1/configurewebserver1.sh en
WAS_HOME/bin/
20. Vaya al directorio WAS_HOME/bin y ejecute:
./configurewebserver1.sh
21. Inicie los servidores HTTP:
/opt/IBM/HTTPServer/bin/adminctl start
/opt/IBM/HTTPServer/bin/apachectl start
22. Inicie la sesión en la consola del administrador de WebSphere y asegúrese de
que se ha iniciado webserver1.
Instalación de los fixpacks del plugin de WebSphere en Solaris:
El fixpack 23 del plugin de WebSphere se debe instalar para actualizar la
instalación base del plugin al nivel de mantenimiento más reciente.
1. Copie el archivo del fixpack solaris64/WS-WAS_Plugins_6.1.0_FP23/6.1.0-WSPLG-SolarisSparc64-FP0000023.pak en el directorio /opt/IBM/WebSphere/
UpdateInstaller/maintenance. Cree este directorio si no existe.
2. Detenga HTTP Server ejecutando /opt/IBM/HTTPServer/bin/apachectl stop
3. Detenga WebSphere y los nodos gestionados utilizando los mandatos
siguientes.
a. WAS_HOME/profiles/ctgAppSrv01/bin/stopNode.sh
b. WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
4. Instalar el fixpack.
a. Inicie el asistente del instalador de actualizaciones:
/opt/IBM/WebSphere/UpdateInstaller/update.sh
b. Vaya al directorio /opt/IBM/WebSphere/UpdateInstaller/maintenance y
seleccione el archivo del fixpack (.pak) desde la lista de archivos e instálelo.
5. Inicie HTTP Server ejecutando /opt/IBM/HTTPServer/bin/apachectl start
6. Reinicie WebSphere y los nodos gestionados:
Capítulo 3. Tareas previas a la migración
137
a. WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
b. WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
Configuración de Virtual Member Manager en IBM WebSphere
Application Server Network Deployment
VMM (Virtual Member Manager) le permite acceder y mantener los datos de
usuario en varios repositorios y federar estos datos en un repositorio virtual
individual.
Antes de empezar
Cree una imagen de copia de seguridad del sistema. Esto le permite restaurar el
sistema a su estado anterior, lo que le permite volver a configurar VMM para que
utilice un servidor LDAP diferente si decide cambiar la ubicación de los datos
LDAP en el futuro.
Consulte el apartado Configuración manual de Virtual Member Manager en
WebSphere Application Server para obtener más información acerca de cómo
agregar un repositorio de IBM Tivoli Directory Server a VMM. Esta es una tarea
necesaria que se debe llevar a cabo.
El repositorio federado gestionado por VMM consta de un solo dominio con
nombre, que es un conjunto de repositorios de usuarios independientes. Cada
repositorio puede ser un repositorio totalmente externo o, en el caso de LDAP, un
subárbol en el repositorio. La raíz de cada repositorio se correlaciona con una
entrada básica en el repositorio federado, que es un punto de partida en el espacio
de nombres jerárquico del dominio virtual.
Para agregar un directorio LDAP al repositorio virtual de VMM, debe agregar
primero el directorio LDAP a la lista de repositorios disponibles para la
configuración del repositorio federado y, a continuación, agregar la raíz de
baseEntries a una base de búsqueda en el directorio LDAP. Pueden agregarse
varias entradas básicas con distintas bases de búsqueda para un directorio LDAP
individual.
Ejecución de las tareas de configuración de WebSphere
Application Server Network Deployment
Utilice este procedimiento para ejecutar las tareas de configuración de WebSphere
Application Server Network Deployment.
Si decide configurar manualmente el middleware de Provisioning Manager para
utilizarlo con Provisioning Manager, tendrá que configurar manualmente
WebSphere Application Server Network Deployment.
1. Copie manualmente el archivo de almacén de claves del host del gestor de
WebSphere Application Server Network Deployment en el sistema
administrativo de Maximo donde está instalando Provisioning Manager:
<WAS_HOME>/profiles/ctgDmgr01/etc/trust.p12
2. Invoque una ventana de navegador y abra la consola administrativa
escribiendo: http://<nombre_servidor>:9060/admin. Esta dirección URL incluye
el número de puerto predeterminado (9060) y el contexto (admin) de la consola
administrativa. Especifique un nombre de usuario para iniciar una sesión.
Tenga en cuenta que se le redirigirá a un puerto seguro (9043).
3. Cree el servidor de aplicaciones MXServer. Este paso sólo es necesario si no ha
instalado WebSphere Application Server Network Deployment utilizando el
programa de instalación de middleware.
138
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
a.
b.
c.
d.
e.
Expanda el enlace Servidores y haga clic en Servidores de aplicaciones.
Haga clic en Nuevo.
Escriba MXServer y haga clic en Siguiente.
Acepte todos los valores predeterminados y haga clic en Siguiente.
Acepte los valores predeterminados y haga clic en Siguiente.
f. Haga clic en Finalizar.
g. Haga clic en Preferencias.
h. Seleccione el recuadro de selección Sincronizar cambios con nodos y haga
clic en Aplicar.
i. Haga clic en Guardar.
j. Haga clic en Aceptar.
4. Edite los valores de memoria de la JVM para el servidor de aplicaciones.
a. En el enlace Servidores en la vista de árbol, haga clic en Servidores de
aplicaciones.
b. Haga clic en MXServer en la ventana principal.
c. En el grupo Infraestructura de servidor, expanda el enlace Gestión de java
y procesos.
d. Haga clic en Definición de proceso.
e. Haga clic en Máquina Virtual Java.
f. Desplácese y escriba 512 como tamaño inicial del almacenamiento dinámico
y 1024 como tamaño máximo de almacenamiento dinámico y haga clic en
Aceptar.
g. Haga clic en Guardar en el recuadro de mensajes.
5. Edite los valores de memoria de la JVM para el gestor de despliegue.
a. En el enlace Administración del sistema en la vista de árbol, haga clic en
Gestor de despliegue.
b. En el grupo Infraestructura de servidor, expanda el enlace Gestión de java
y procesos.
c. Haga clic en Definición de proceso.
d. Haga clic en Máquina Virtual Java.
e. Desplácese y escriba 512 como tamaño inicial del almacenamiento dinámico
y 1024 como tamaño máximo de almacenamiento dinámico y haga clic en
Aceptar.
f. Haga clic en Guardar en el recuadro de mensajes.
6. Inicie el servidor de aplicaciones.
a. En el enlace Servidores en la vista de árbol, haga clic en Servidores de
aplicaciones.
b. Seleccione el recuadro de selección que aparece al lado de MXServer.
c. Haga clic en Inicio.
7. Identifique los números de puerto de transferencia HTTP.
a. Expanda Servidores → Servidores de aplicaciones y haga clic en MXServer
desde la ventana principal.
b. Abra Valores de contenedor web y haga clic en Cadenas de transporte de
contenedor web.
c. Anote el número de puerto predeterminado como aparece con
WCInboundDefault (9080).
8. Cree el host virtual.
Capítulo 3. Tareas previas a la migración
139
Expanda el enlace Entorno desde la vista de árbol.
Haga clic en Hosts virtuales.
Haga clic en Nuevo.
En la sección Propiedades generales, escriba maximo_host en el recuadro
Nombre.
e. Haga clic en Aplicar.
f. Haga clic en Guardar.
g. En la ventana Hosts virtuales, haga clic en maximo_host.
a.
b.
c.
d.
h. Haga clic en el enlace Alias de host.
i. Haga clic en Nuevo.
j. Escriba * (asterisco) como nombre de host y escriba el número de puerto
HTTP (el valor predeterminado es 80).
k. Haga clic en Aceptar.
l. Haga clic en Nuevo.
m. Escriba * (asterisco) como nombre de host y escriba 9061 como número de
puerto.
n. Haga clic en Aceptar.
o. Haga clic en Nuevo.
p. Escriba * (asterisco) como nombre de host y escriba 9443 para el número de
puerto.
q. Haga clic en Aceptar.
r. Haga clic en Nuevo.
s. Escriba * (asterisco) como nombre de host y escriba 9080 como número de
puerto.
t. Haga clic en Aceptar.
u. Haga clic en Nuevo.
v. Escriba * (asterisco) como nombre de host y escriba 9044 como número de
puerto.
w. Haga clic en Aceptar.
x. En la indicación de ruta de navegación, haga clic en maximo_host.
y. Haga clic en Aplicar y luego haga clic en Aceptar.
z. Haga clic en Guardar.
9. Habilite el arranque automático del servidor de aplicaciones cuando se haya
iniciado el agente de nodos:
a. En el enlace Servidores en la vista de árbol, haga clic en Servidores de
aplicaciones.
b. Haga clic en MXServer en la ventana principal.
c. En el grupo Infraestructura de servidor, expanda el enlace Gestión de java
y procesos.
d. Haga clic en Política de supervisión.
e. Establezca el Estado de reinicio del nodo en RUNNING y haga clic en
Aceptar.
f. Haga clic en Guardar.
Qué hacer a continuación
Continúe en Configuración manual del servicio de autenticación .
140
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Configuración del servicio de autenticación de IBM WebSphere
Application Server Network Deployment
El servicio de autenticación permite el “inicio en contexto”. El inicio en contexto
permite realizar un inicio desde una aplicación, como IBM Maximo Asset
Management, a la interfaz de usuario de una aplicación externa basada en la web
como Tivoli Application Dependency Discovery Manager. Las dos aplicaciones
deben utilizar el mismo servidor de directorios para autenticación y la aplicación
externa debe tener instalado el cliente de autenticación. Los usuarios se autentican
una sola vez, en el servidor que aloja el cliente. No es necesario que se vuelvan a
autenticar en la aplicación externa cuando realizan el inicio en contexto en la
misma.
1. Abra un indicador de mandatos en el servidor que aloja IBM WebSphere
Application Server.
2. Vaya a WAS_HOME/bin.
3. Inicie la sesión en el shell wsadmin utilizando el mandato siguiente. Si no ha
cambiado el nombre de usuario wsadmin o la contraseña cuando ha instalado
el servidor de aplicaciones, el valor predeterminado es wsadmin para el usuario
y wsadmin para la contraseña.
./wsadmin.sh
4. Compruebe que no tenga desplegados servicios de autenticación previamente:
wsadmin>$AdminApp view authnsvc_ctges
Si el mandato devuelve un mensaje que indica que la aplicación
authnsvc_ctges, los servicios de autenticación no se han desplegado.
5. Abra una nueva ventana X y copie el archivo os/WS-ESS_6.1_GA/
IBMESSAuthnSvc.ear en una unidad local. Por ejemplo, solaris64/WSESS_6.1_GA/IBMESSAuthnSvc.ear
6. Regrese a la ventana del shell wsadmin y despliegue IBMESSAuthnSvc.ear
utilizando el mandato siguiente. Todos los caracteres se deben escribir como
se muestran.
wsadmin>$AdminApp install vía_acceso/IBMESSAuthnSvc.ear
"-usedefaultbindings -deployws -appname authnsvc_ctges"
Por ejemplo, para Solaris, vía_acceso puede ser solaris64/WS-ESS_6.1_GA/.
7. Guarde la configuración:
wsadmin>$AdminConfig save
8. Salga del shell de wsadmin escribiendo exit.
9. Detenga WebSphere y los nodos gestionados utilizando los mandatos
siguientes.
a. WAS_HOME/profiles/ctgAppSrv01/bin/stopNode.sh
b. WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
10. Copie el archivo os/WS-ESS_6.1_GA/
com.ibm.security.ess.server_config.6.1.0.jar en el directorio
WAS_HOME/plugins.
Este archivo se encuentra en el directorio os/WS-ESS_6.1_GA en el DVD de
middleware.
11. Reinicie WebSphere y los nodos gestionados:
a. WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
b. WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
12. Vaya a WAS_HOME/bin.
13. Escriba ./wsadmin.sh para iniciar la sesión en el shell wsadmin.
Capítulo 3. Tareas previas a la migración
141
14. Configure el servicio, escriba lo siguiente en el indicador de wsadmin:
$AdminTask configureESS.
15. Escriba el siguiente mandato wsadmin para verificar que el servicio se ha
configurado: $AdminTask isESSConfigured. Si se devuelve true, se configura el
servicio.
16. Cree una clave LTPA (Lightweight Third Party Authentication), necesaria para
dar soporte al inicio de sesión único, escribiendo el mandato siguiente. La
contraseña que especifique es la contraseña de la clave LTPA. Anótela en un
lugar seguro. Si se pierde la contraseña de la clave, deberá crear una clave
nueva. Asegúrese de que todos los clientes que se conectan al servicio utilizan
el archivo de claves de exportación que ha creado en el paso 19.
wsadmin>$AdminTask createESSLTPAKeys ″-password contraseña″
Nota: Si la contraseña de la clave se pierde, deberá crear una nueva clave.
Asegúrese de que todos los clientes que se conectan al servicio utilicen el
nuevo archivo de claves de exportación que ha generado.
17. Sincronice la configuración.
wsadmin>$AdminConfig save
wsadmin>set dmgr [$AdminControl completeObjectName type=DeploymentManager,*]
wsadmin>$AdminControl invoke $dmgr syncActiveNodes true
wsadmin>quit
18. Detenga y reinicie WebSphere y los nodos gestionados:
a. WAS_HOME/profiles/ctgAppSrv01/bin/stopNode.sh
b. WAS_HOME/profiles/ctgDmgr01/bin/stopManager.sh
c. WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
d. WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
19. Exporte la clave que acaba de crear:
# wsadmin
wsadmin>$AdminTask exportESSLTPAKeys
"-pathname nombre_vía_acceso"
Por ejemplo,
wsadmin>$AdminTask exportESSLTPAKeys "-pathname
/root/avenESSLTPAKeyFile.exported"
Qué hacer a continuación
Antes de instalar los componentes principales, haga una copia de seguridad de la
configuración de WebSphere. Se recomienda realiza esta tarea para poder restaurar
esta copia de seguridad si falla la instalación.
Creación de la base de datos y del usuario del servidor de
bases de datos
Cree la base de datos y el usuario para la configuración de la base de datos
Maximo.
Antes de empezar
v El servidor de bases de datos debe estar ejecutándose. Para obtener información
acerca de cómo iniciar el servidor de bases de datos, consulte “Inicio del
middleware en UNIX y Linux” en la página 188 o “Inicio de middleware en
Windows” en la página 186.
142
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Base de datos DB2
Inicie la sesión en el servidor de bases de datos.
1.
v
Windows
Inicie la sesión el servidor de bases de datos como Administrator.
UNIX
v
Inicie la sesión en el servidor de bases de datos como root.
2. Cree el usuario maximo y cambie la contraseña de usuario.
v
v
Windows
DB2 requiere cuentas de usuario que sean cuentas de usuario del
sistema operativo. Cree el usuario del sistema operativo maximo utilizando las
herramientas de gestión de usuarios disponibles.
UNIX
Ejecute los mandatos siguientes:
useradd -d /home/maximo -m maximo
passwd maximo
v
AIX
Ejecute el mandato siguiente de modo que no necesite cambiar la contraseña
de maximo después del primer inicio de sesión.
pwdadm -c maximo
Windows
3.
Inicie la ventana de mandatos de DB2.
4. Cambie al usuario ctginst1:
v
UNIX
su - ctginst1
v
Windows
set DB2INSTANCE=ctginst1
5. Cree el nombre de base de datos maxdb71 para la base de datos de Tivoli
Provisioning Manager y especifique el conjunto de códigos como UTF-8 cuando
cree la base de datos.
db2 create db maxdb71 using codeset UTF-8 territory US
Nota: Puede crear la base de datos en cualquier instancia. Tome nota del
nombre de la instancia, necesitará el nombre durante la instalación de los
componentes principales. Si está utilizando un servidor de bases de datos
remoto, necesitará el número de puerto de la instancia del servidor de bases de
datos y no el nombre de la instancia.
6. Para validar que se ha creado correctamente la base de datos, ejecute el
mandato siguiente:
db2 list database directory
Base de datos de Oracle
En la base de datos Oracle, cree manualmente el nombre de base de datos,
maxdb71. El usuario de base de datos, maximo, se crea cuando ejecuta el mandato
para registrarlo como el usuario de la base de datos.
1. Inicie la sesión en la base de datos Oracle como el usuario oracle.
2. Cree el nombre de base de datos maxdb71 para la base de datos de Tivoli
Provisioning Manager. Utilice la herramienta DBCA (Database Configuration
Assistant) de Oracle para crear maxdb71. Para obtener información detallada
acerca de cómo crear una base de datos, consulte la sección denominada Using
the Database Configuration Assistant (DBCA) to Create a Database en la
documentación de la base de datos Oracle: http://www.oracle.com/
technology/obe/2day_dba/install/install.htm.
Capítulo 3. Tareas previas a la migración
143
Nota: Para la mayor parte de las páginas del asistente de DBCA, puede aceptar
los valores predeterminados. No obstante, en el Paso 10 de 12: Parámetros de
inicialización, asegúrese de que selecciona el separador Juegos de caracteres y
seleccione Utilizar Unicode para poder almacenar los idiomas.
3. Acceda al DVD de instalación de Tivoli Provisioning Manager y extraiga el
archivo migration.zip en el servidor de bases de datos.
4. En el directorio migration/sql/oracle, copie el archivo ora_config.sql y
péguelo en el directorio HOME predeterminado para Oracle en el servidor de
bases de datos, por ejemplo, /home/oracle o /export/home/oracle.
5. Desde el directorio HOME predeterminado, ejecute el mandato para registrar el
usuario en la base de datos Oracle:
$ORACLE_HOME/bin/sqlplus /NOLOG @ora_config.sql
<ORA_NOMBREBD> <ORA_USUARIOADMIN> <ORA_CONTRASEÑAADMIN> maximo <ORA_CONTRASEÑA>
donde
ORA_NOMBREBD es el nombre de la base de datos.
ORA_USUARIOADMIN es el usuario administrativo. Generalmente el
nombre es sys.
ORA_CONTRASEÑAADMIN es la contraseña del usuario administrativo
sys.
ORA_CONTRASEÑA es la contraseña del usuario de Oracle maximo.
Por ejemplo:
$ORACLE_HOME/bin/sqlplus /NOLOG @ora_config.sql maxdb71 sys password maximo password
Qué hacer a continuación
“Instalación de los componentes principales de Tivoli Provisioning Manager”
Instalación de los componentes principales de Tivoli
Provisioning Manager
Instale los componentes principales de Tivoli Provisioning Manager en el sistema.
Antes de empezar
v Asegúrese de que se han iniciado las aplicaciones de middleware. Si ha instalado
el middleware con el instalador de middleware, las aplicaciones de middleware
se inician automáticamente después de la instalación. Si ha reiniciado el sistema
o si ha instalado manualmente el middleware, consulte “Inicio de middleware
en Windows” en la página 186 o “Inicio del middleware en UNIX y Linux” en la
página 188.
v Durante la instalación:
– Utilice siempre nombres de dominio completos cuando especifique valores
para los nombres de host del sistema.
– Las vías de acceso a directorios no pueden contener una barra inclinada como
último carácter de la vía de acceso (\ en Windows o / en UNIX y Linux).
– Si utiliza un nombre de host virtual en el sistema donde está instalando los
componentes principales, tenga en cuenta que Tivoli Provisioning Manager
for OS Deployment no da soporte a los nombres de host virtuales. Sólo se
puede acceder a Tivoli Provisioning Manager for OS Deployment utilizando
el nombre de host local del sistema.
– Si obtiene errores, consulte la Guía de resolución de problemas.
144
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Se instala el software siguiente:
v Tivoli Provisioning Manager
v Tivoli Provisioning Manager for OS Deployment
v Tivoli Monitoring Agent
Importante: No instale los siguientes componentes:
v Gestor de agentes
v Tivoli Provisioning Manager for Dynamic Content Delivery
v Servicio del gestor de dispositivos
Estos componentes se instalan durante la migración.
Los componentes principales deben estar instalados en el servidor de suministro.
Para instalar los componentes principales:
1. En el sistema donde está instalado WebSphere Application Server, Inicie el
Launchpad.
2. En el panel de navegación del launchpad, haga clic en Instalación
personalizada. Desplácese hacia abajo hasta 3. Instalar componentes
principales de Tivoli Provisioning Manager y haga clic en Verificar
requisitos previos de instalación de componentes principales. Después de
verificar y de confirmar los requisitos previos, vuelva a la página de
instalación personalizada.
3. Haga clic en Instalar componentes principales.
4. Seleccione el idioma para la instalación y haga clic en Aceptar.
5. En el panel de bienvenida, haga clic en Siguiente.
6. Acepte el acuerdo de licencia y haga clic en Siguiente.
7. En el panel Configuración de topología, especifique todos los campos
necesarios y haga clic en Siguiente.
Información de base de datos
v Seleccione la base de datos. En Windows, sólo se da soporte a DB2.
v Si la base de datos se ha configurado durante una instalación
anterior de Tivoli Provisioning Manager o de otro producto como,
por ejemplo, IBM Tivoli Change and Configuration Management
Database, seleccione el recuadro de configuración No configurar la
base de datos.
v Si el servidor de bases de datos está en otro sistema, seleccione el
recuadro de selección Utilizar base de datos remota.
Información del servidor de directorios LDAP
Seleccione el servidor de directorios que está utilizando con Tivoli
Provisioning Manager.
Para confirmar que existe el usuario maxadmin en el repositorio LDAP,
seleccione el recuadro de selección correspondiente.
Nota: Desmarque este recuadro de selección si no ha añadido
manualmente el usuario maxadmin a su Tivoli Directory Server. El
usuario maxadmin no lo crea el instalador de middleware.
Información de espacio de trabajo del instalador de middleware
v Si ha instalado el middleware con el instalador de middleware,
marque el recuadro de selección Importar datos para espacio de
trabajo de instalador de middleware y luego especifique la
Capítulo 3. Tareas previas a la migración
145
ubicación del espacio de trabajo del instalador de middleware. En
una topología de varios servidores, esta es la ubicación que ha
especificado durante la instalación del middleware. El valor
predeterminado es C:\ibm\tivoli\mwi\workspace para Windows y
/root/ibm/tivoli/mwi/workspace para UNIX y Linux.
v Seleccione el recuadro de selección Utilizar IP de servicio si está
utilizando nombres de host y direcciones IP virtuales para todos los
sistemas de la topología de instalación. Los nombres de host y las
direcciones IP virtuales que utilice en este instalador deben coincidir
con los valores especificados durante la instalación del middleware.
8. En el panel Seleccionar componentes, seleccione los componentes que se han
de instalar. No seleccione los componentes siguientes:
v Copia de seguridad de la configuración de la base de datos y WebSphere
Application Server
v Gestor de agentes
v Tivoli Provisioning Manager for Dynamic Content Delivery
v Tivoli Provisioning Manager for Job Management Service
Nota: Si ha utilizado el instalador de middleware para instalar el servidor de
DB2 y está utilizando una configuración en la que Tivoli Directory Server y
Tivoli Provisioning Manager están en el mismo sistema, pero DB2 está
instalada en otro sistema, no seleccione el recuadro de selección Cliente DB2.
9. Si ha seleccionado Tivoli Provisioning Manager for OS Deployment, acepte el
acuerdo de licencia y haga clic en Siguiente.
10.
Si no desea instalar Cygwin porque ya está instalado, especifique el
directorio en el que está instalado Cygwin y haga clic en Siguiente.
Windows
v Si no necesita soporte para la comunicación IPv6 en el entorno de Tivoli
Provisioning Manager, se necesita Cygwin 1.5.10 o superior.
v Si necesita soporte para la comunicación IPv6 en el entorno de Tivoli
Provisioning Manager, se necesita Cygwin 1.7 o posterior.
Si desea instalar Cygwin, especifique todos los campos obligatorios y haga clic
en Siguiente.
Seleccione un sitio de descarga de Cygwin
Seleccione la ubicación que desea utilizar para descargar los archivos
de instalación de Cygwin. Se recomienda la ubicación que resulte más
próxima geográficamente.
Nombre de usuario
Especifique el nombre de usuario que utilizará Windows para ejecutar
el servicio de Cygwin SSH.
11. En el panel Directorios para los componentes principales,especifique todos los
campos necesarios y haga clic en Siguiente.
v El estándar FIPS (Federal Information Processing Standard) 140-2 no está
soportado para la migración. No seleccione el recuadro de selección
correspondiente.
v Si está utilizando imágenes de instalación descargadas, especifique el
directorio en el que se encuentran.
v Si desea copiar las imágenes de instalación desde los DVD, especifique el
directorio de destino y seleccione el recuadro de selección Copiar imágenes
de instalación del soporte.
v Especifique el directorio de los archivos de registro y los scripts de servicio.
146
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nota: No especifique /tmp para este directorio. Ya que el instalado actualiza
dinámicamente el directorio /tmp y esto puede hacer que la instalación falle.
El valor predeterminado es:
–
Windows
%ProgramFiles%\IBM\tivoli\common
UNIX
Linux
/usr/ibm/tivoli/common
–
v Especifique el directorio para los archivos temporales.
v Especifique el directorio para los archivos de copia de seguridad.
El directorio que especifique debe tener 755 permisos.
12. Si está utilizando DB2, en el panel de configuración de DB2, especifique todos
los campos necesarios y haga clic en Siguiente. Los valores deben coincidir
con los valores que ha especificado cuando ha instalado DB2. Si ha utilizado
el instalador de middleware, se proporcionan los valores predeterminados.
v Si se ha instalado el servidor de DB2 en Linux, seleccione el recuadro de
selección correspondiente.
UNIX
Linux
Nombre de dominio completo o dirección IP
El nombre de dominio completo del servidor en el que está instalado
DB2, como por ejemplo database.example.com. Si utiliza una dirección
IP virtual o un nombre de host, asegúrese de especificar el nombre de
host virtual correcto.
Número de puerto de instancia de servidor DB2
El número de puerto TCP/IP de DB2 que este servidor utilizará para
realizar la escucha de solicitudes de conexión de los clientes, por
ejemplo 50005.
Nombre de la base de datos de IBM Tivoli Provisioning Manager
El nombre de la base de datos sólo puede contener letras mayúsculas,
letras minúsculas y números. El valor predeterminado es MAXDB71.
Propietario de la instancia del servidor DB2
El usuario propietario de la instancia de la base de datos. Para
Windows, el valor predeterminado es db2admin. Para UNIX y Linux,
el valor predeterminado es ctginst1.
Contraseña del propietario de la instancia del servidor DB2
La contraseña del propietario de la instancia.
Utilice la configuración de instancia recomendada de Tivoli Provisioning
Manager
Deje este recuadro de selección marcado para que el instalador
configure la instancia con los valores de rendimiento. Esta es la opción
recomendada para la instalación.
Utilice la configuración de base de datos recomendada de Tivoli
Provisioning Manager
Deje este recuadro de selección marcado para que el instalador
configure la base de datos con los valores de rendimiento. Esta es la
opción recomendada para la instalación.
Nombre de usuario de servidor de bases de datos DB2
El nombre del usuario administrador en el servidor donde se ha
instalado DB2. El valor predeterminado es maximo.
Importante: El valor no puede ser el mismo que el nombre de usuario
de la instancia de DB2.
Capítulo 3. Tareas previas a la migración
147
Contraseña de usuario de servidor DB2
La contraseña del usuario administrador especificado en el servidor de
bases de datos.
UNIX
Linux
Nombre de grupo de instancia local de DB2
El nombre del grupo correspondiente al propietario de la instancia del
cliente de DB2. Si el servidor de DB2 está en otro sistema, utilice el
nombre de grupo del propietario de la instancia del cliente de DB2 en
el sistema de Tivoli Provisioning Manager. El valor predeterminado es
ctginst1.
Directorio SQLLIB de instancia de DB2 local
La ubicación de la instancia de DB2 local para el cliente de DB2.
Windows
13.
v
UNIX
Modifique este valor para que coincida con el nombre de
usuario especificado en el campo Propietario de la instancia de
servidor de DB2. Por ejemplo, si la instancia de DB2 local es
ctginst1, este directorio es /home/ctginst1/sqllib.
v
El valor predeterminado es Unidad_sistema:\Archivos de
programa\IBM\SQLLIB.
Windows
Nombre de instancia de DB2 local
El nombre de la instancia de base de datos para el cliente de DB2. El
valor predeterminado es ctginst1. Si ha utilizado el instalador de
middleware para instalar el servidor de DB2 y utiliza una
configuración en la que Tivoli Directory Server y Tivoli Provisioning
Manager están instalados en el mismo sistema, mientras que DB2 está
instalado en otro, especifique un nombre de instancia existente, como
por ejemplo DB2.
UNIX
Si utiliza Oracle Database, en el panel Configuración de base de
datos Oracle especifique todos los campos obligatorios y haga clic en
Siguiente.
Nombre de dominio completo
Especifique el nombre de dominio completo del sistema en el que está
instalado Oracle Database, como por ejemplo database.example.com.
Número de puerto de la instancia de servidor de Oracle
Especifique un puerto de host para Oracle Database. El número de
puerto predeterminado es 1521.
Identificador del sistema (SID) de la base de datos de Tivoli Provisioning
Manager
Especifique el SID de la base de datos de Tivoli Provisioning Manager.
El SID sólo puede contener letras mayúsculas, letras minúsculas y
números. Si no ha utilizado el nombre ctginst1 durante la instalación,
especifique el nombre correcto.
Nombre de servicio de la base de datos de Tivoli Provisioning Manager
Especifique el nombre de servicio. En Oracle 11g, el nombre de
servicio es el nombre de base de datos global, que consta del nombre
de la base de datos y del nombre del dominio, como por ejemplo
database.example.com. Para buscar el nombre de servicio, consulte la
documentación de Oracle.
Nombre del administrador de base de datos
Especifique el nombre de usuario que tiene privilegios sysdba para
esta base de datos.
148
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Contraseña del administrador de base de datos
Especifique la contraseña del administrador de base de datos.
Nombre de usuario de base de datos
Especifique el usuario que Tivoli Provisioning Manager utilizará para
conectarse al servidor de bases de datos y para gestionar los datos.
Escriba el mismo valor que el ID de usuario de base de datos Oracle
utilizado durante la instalación de los servicios básicos. El valor
predeterminado es maximo.
Contraseña de usuario de la base de datos
Especifique la contraseña del nombre de usuario del servidor de bases
de datos Oracle.
Directorio de instalación del cliente de base de datos Oracle
Especifique el directorio de instalación del cliente de Oracle.
Asegúrese de que no haya espacios adicionales antes o después de la
vía de acceso especificada.
14. En el panel de configuración de WebSphere Application Server Network
Deployment, especifique todos los campos necesarios. Para obtener más
información acerca de la configuración de WebSphere Application Server, por
ejemplo, la configuración de células y nodos, consulte la documentación de
WebSphere Application Server.
Directorio de instalación
El directorio en el que está instalado WebSphere Application Server. El
valor predeterminado es:
v
Windows
v
AIX
v
C:\Archivos de programa\IBM\WebSphere\AppServer
/usr/IBM/WebSphere/AppServer
Linux
/opt/IBM/WebSphere/AppServer
El nombre de dominio completo de WebSphere Application Server
El nombre de dominio completo del sistema donde ha está instalando
los componentes principales de servidor de suministro. Por ejemplo,
tpmserver.example.com. Si utiliza una dirección IP virtual o un
nombre de host, asegúrese de especificar la dirección IP o el nombre
de host correctos.
Nombre de célula
Especifique el nombre de la célula de WebSphere Application Server.
El valor predeterminado para todas las plataformas es ctgCell01.
Nombre de perfil de WebSphere Deployment Manager
Especifique el nombre del perfil de WebSphere Application Server del
servidor del gestor de despliegue.
El valor predeterminado para todas las plataformas es ctgDmgr01.
Nombre de nodo del servidor de aplicaciones
Especifique el nombre del nodo de WebSphere Application Server.
El valor predeterminado para todas las plataformas es ctgNode01.
Nombre de perfil del servidor de aplicaciones
Especifique el nombre del perfil de WebSphere Application Server del
servidor de aplicaciones.
El valor predeterminado para todas las plataformas es ctgAppSrv01.
Capítulo 3. Tareas previas a la migración
149
Nombre de servidor
Escriba el nombre del servidor de aplicaciones Maximo, por ejemplo,
MXServer.
Usuario administrador de gestor de despliegue
Especifique el nombre de la cuenta administrativa de WebSphere
Application Server.
El valor predeterminado para todas las plataformas es wasadmin.
Contraseña de administrador de gestor de despliegue
Especifique la contraseña de la cuenta administrativa de WebSphere
Application Server.
Puerto de gestor de despliegue
Especifique el puerto del administrador de WebSphere Application
Server. El valor predeterminado es 8879.
15. En el panel de configuración del servidor LDAP, especifique todos los campos
necesarios. Para obtener más información sobre los valores específicos del
servidor de directorios, consulte la documentación del servidor de directorios.
Utilizar SSL para servidor LDAP
Solo se aplica a Tivoli Directory Server.
Seleccione esta opción para habilitar la comunicación segura con el
servidor de directorios. El servidor de directorios contiene información
sobre los usuarios, por lo que se recomienda habilitar esta opción para
asegurarse de que la transmisión de datos entre el servidor de
directorios y otros sistemas sea segura.
Nombre de dominio completo o dirección IP
El nombre de dominio completo del servidor de directorios, como por
ejemplo ldap.example.com. Si utiliza una dirección IP virtual o un
nombre de host, asegúrese de especificar el nombre de host virtual
correcto.
Puerto público de host
El número de puerto de Tivoli Directory Server o Microsoft Active
Directory. El valor predeterminado es 389.
Puerto SSL del host
Se aplica únicamente a Tivoli Directory Server.
Especifique el número de puerto seguro de Tivoli Directory Server.
El valor predeterminado para todas las plataformas es 636.
DN base de usuario
Solo se aplica a Tivoli Directory Server.
Especifique el nombre distinguido (DN) base del servidor de
directorios. Los valores deben coincidir con la unidad organizativa y
el sufijo de organización y país especificados en el instalador de
middleware. Por ejemplo ou=SWG,o=IBM,c=US. Si desea utilizar el
nombre distinguido del usuario que ha especificado como Nombre de
usuario de enlace de LDAP, seleccione el recuadro de selección que
aparece debajo de este campo.
Nombre del dominio del servidor de Microsoft Active Directory
Solo se aplica a Microsoft Active Directory.
El nombre de dominio de Microsoft Active Directory, por ejemplo
testmsad.com.
150
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nombre distinguido de usuario de enlace de LDAP
Se aplica únicamente a Tivoli Directory Server.
Especifique el nombre distinguido del enlace con la instancia LDAP.
El valor predeterminado es cn=root
ID de usuario administrador de la instancia
El ID de usuario del administrador de la instancia, tal como se ha
especificado durante la instalación de los servicios básicos. El valor
predeterminado es maxadmin.
Contraseña del administrador de la instancia
La contraseña del administrador de la instancia, tal como se ha
especificado durante la instalación de los servicios básicos. El valor
predeterminado es maxadmin.
Nombre de usuario de enlace de LDAP
Solo se aplica a Microsoft Active Directory.
El nombre de usuario de enlace de Microsoft Active Directory, por
ejemplo Administrador.
Contraseña de usuario de enlace de LDAP
Especifique la contraseña del nombre distinguido del enlace.
Atributo de nombre de inicio de sesión de usuario
Especifique el atributo LDAP de los nombres de usuario del servidor
de directorios. Por ejemplo uid (ID de usuario), cn (Nombre común) o
sAMAccountName.
Filtro de búsqueda de usuario
Especifique el filtro de búsqueda que desea utilizar para recuperar
usuarios del servidor de directorios. Por ejemplo,
(&(sAMAccountName=%v)(objectcategory=user))
16. En el panel Configuración de IBM Tivoli Provisioning Manager, especifique
todos los campos obligatorios y haga clic en Siguiente.
v Especifique el directorio de instalación. El valor predeterminado es:
–
Windows
–
UNIX
C:\Archivos de programa\IBM\tivoli\tpm
Linux
/opt/IBM/tivoli/tpm
Nota: Para algunos componentes, como por ejemplo GUID o el motor de
despliegue, el programa de instalación utiliza ubicaciones de instalación
predefinidas para estos componentes, de modo que siempre guarda varios
archivos en %SystemDrive% para Windows y /usr, /opt, o /var en UNIX y
Linux.
v Especifique la contraseña del usuario tioadmin. El usuario tioadmin se crea
durante la instalación y se utiliza para iniciar los servicios de Tivoli
Provisioning Manager.
AIX
Nota: Asegúrese de que el atributo El usuario puede iniciar la sesión de
forma remota tenga el valor true para el usuario tioadmin. Si tiene el valor
false, ejecute el siguiente mandato:
chuser "rlogin=true" tioadmin
v Especifique los siguientes números de puerto:
Puerto SSL del servidor de la infraestructura de distribución de software
Especifique el puerto para la comunicación con el servidor de
Capítulo 3. Tareas previas a la migración
151
suministro. Se trata del puerto HTTPS de WebSphere Application
Server. El valor predeterminado es 9045.
Puerto SSL del cliente de la infraestructura de distribución de software
Especifique un puerto para la comunicación con los clientes
utilizando SSL autenticado mutuamente. El valor predeterminado es
9046.
Puerto no SSL de la infraestructura de distribución de software
Especifique el puerto HTTP seguro para la comunicación con el
servidor de suministro.
Puerto SSL de Tivoli Provisioning Manager
Un puerto que utiliza SSL del lado del servidor para realizar el
cifrado y para autenticar WebSphere Application Server en el resto
de los servidores. El número de puerto predeterminado es 9443.
v Especifique la información sobre almacén de claves y almacén de confianza:
Nombre de almacén de claves SSL de Tivoli Provisioning Manager
Especifique el nombre de archivo del archivo de almacén de claves
de Tivoli Provisioning Manager. El archivo de almacén de claves es
un archivo de base de datos de claves que contiene claves públicas
y claves privadas para la comunicación SSL.
Contraseña de almacén de claves SSL de Tivoli Provisioning Manager
Especifique la contraseña del almacén de claves de Tivoli
Provisioning Manager.
Nombre de almacén de confianza de Tivoli Provisioning Manager
Especifique el nombre de archivo del almacén de confianza de
Tivoli Provisioning Manager. Un archivo de almacén de confianza
es un archivo de base de datos de claves que contiene las claves
públicas para la comunicación SSL con los sistemas de destino.
Contraseña de almacén de confianza de Tivoli Provisioning Manager
Especifique la contraseña del almacén de confianza de Tivoli
Provisioning Manager.
Nombre de la empresa
Especifique el nombre de la empresa. Este nombre se utiliza en el
certificado SSL que se crea durante la instalación.
Los agentes se conectarán al gestor de agentes de la siguiente manera
Especifique si desea que los agentes en los sistemas gestionados se
conecten al gestor de agentes utilizando la dirección IP o el nombre
de dominio completo del servidor.
17. En el panel Tivoli Provisioning Manager for OS Deployment, especifique
todos los campos obligatorios y haga clic en Siguientes.
a. Puerto HTTP: el puerto HTTP de la consola de Tivoli Provisioning
Manager for OS Deployment. El valor predeterminado es 8080.
b. Puerto HTTPS: el puerto HTTP seguro de la consola de Tivoli
Provisioning Manager for OS Deployment. El valor predeterminado es 443.
c. Directorio de datos: el directorio de los archivos y las imágenes del
sistema operativo que gestiona Tivoli Provisioning Manager for OS
Deployment.
En Windows, el valor predeterminado es C:\tpmfosd files\. Si
utiliza el directorio raíz de una unidad, asegúrese de que el valor que
especifique termine por \. Por ejemplo, D:\.
Windows
152
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
UNIX
d.
En UNIX, el valor predeterminado es /opt/tpmfosd_files
UNIX
Linux
Especifique el directorio de instalación. El valor
predeterminado es /opt/IBM.
Nota: El idioma de la instalación de Tivoli Provisioning Manager for OS
Deployment es el idioma del sistema operativo. Para cambiar el idioma tras la
instalación, haga clic en Ir a → Despliegue → Gestión de SO → Servidores de
arranque y seleccione el separador Configuración.
18. En el panel Configuración de Tivoli Monitoring Agent, especifique todos los
campos obligatorios y haga clic en Siguientes.
a. Deje la clave de cifrado predeterminada generada por el instalador o
especifique su propia clave de cifrado para la comunicación entre el agente
y el servidor de Tivoli Enterprise Monitoring.
b. Especifique el directorio de instalación del agente.
Nota: Windows En un sistema Windows de 64 bits, el agente no puede
instalarse en C:\Archivos de programa o en un subdirectorio de
C:\Archivos de programa.
Cuando haga clic en Siguiente, el instalador validará la información y
mostrará un resumen de los valores de instalación. Si ha seleccionado la
opción de copiar los archivos de instalación desde DVD, se le solicitará que
inserte los DVD para que se puedan copiar los archivos. Una vez copiados los
DVD, vuelva a insertar el DVD de Instalación.
Nota: La configuración de DB2 puede fallar si se ejecuta más de una vez. Si
continúa recibiendo un error y tiene los valores correctos, salga del instalador
y volver a iniciar la instalación.
19. Revise el resumen de los valores de instalación y haga clic en Siguientes.
20. Cuando finalice la instalación, haga clic en Finalizar.
21.
UNIX
Si ha instalado DB2 en otro sistema, deberá detener y reiniciar la
instancia de base de datos antes de continuar con la instalación.
Antes de reiniciar el servidor, configure el registro de DB2 con valores que
reduzcan la posibilidad de exceder el tiempo de espera de bloqueo de base de
datos. DB2 utiliza bloqueos cómo método de impedir que los cambios no
confirmados realizados por un proceso de aplicación sean percibidos por otro
proceso de aplicación y para evitar que un proceso de aplicación actualice
datos a los que está accediendo otro proceso. Un bloqueo está diseñado para
ayudar a proteger la integridad de los datos, al impedir que usuarios
simultáneos accedan a datos incoherentes. Hay varios factores que afectan al
uso de bloqueos y a su efecto sobre el rendimiento de las aplicaciones.
El registro de DB2 se configura automáticamente con los valores necesarios si
se ha instalado en el sistema de Tivoli Provisioning Manager.
Para configurar el registro de base de datos y reiniciar el servidor de DB2:
a. Ejecute los siguientes mandatos en el sistema donde se haya instalado el
servidor de DB2:
su - db_inst
db2set DB2_WORKLOAD=TPM
Sustituya db_inst por el nombre de la base de datos de instancia. El valor
predeterminado es ctginst1.
b. Reinicie la base de datos.
Capítulo 3. Tareas previas a la migración
153
El servidor no tiene una IP virtual
Ejecute los mandatos siguientes:
db2stop force
db2start
El servidor tiene una IP virtual
Si utiliza una dirección IP virtual para el servidor de DB2, utilice
los siguientes mandatos:
db2gcf -d -p 0 -i db_inst
db2gcf -u -p 0 -i db_inst
Sustituya db_inst por el nombre de la base de datos de instancia. El
valor predeterminado es ctginst1.
El registro de DB2 se ha actualizado. Para ver las variables de registro que se
han establecido con la variable DB2_WORKLOAD, ejecute el siguiente
mandato:
db2set -gd DB2_WORKLOAD=TPM
Resultados
Los componentes principales están ahora instalados.
Qué hacer a continuación
“Validación de la instalación”
Validación de la instalación
Antes de comenzar la migración de los datos de la versión 5.1.1.2 al nuevo sistema,
asegúrese de que la instalación de la versión 7.1.1 se ha realizado correctamente.
Una vez instalados los componentes principales, realice un par de comprobaciones
para asegurarse de que todo se ha instalado correctamente.
1. Inicie la sesión en el servidor de suministro como tioadmin.
2. Vaya al directorio TIO_HOME
v
Windows
C:\Archivos de programa\IBM\tivoli\tpm
UNIX
Linux
/opt/IBM/tivoli/tpm
v
3. Verifique que el código de los componentes principales se ha instalado en este
directorio. Por ejemplo, valide que se han creado las carpetas /drivers y /xml.
4. Vaya al directorio TIO_HOME/config y valide que se han creado los siguientes
archivos de configuración:
a. dcm.xml
b. user-factory.xml
c. crypto.xml
5. Vaya al directorio TIO_LOGS y valide que puede acceder a los archivos de
registro del servidor de suministro.
154
v
Windows
v
UNIX
C:\Archivos de programa\IBM\tivoli\common\COP\logs
Linux
/usr/ibm/tivoli/common/COP/logs
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Resultados
Si se han creado los directorios y archivos, los componentes principales se han
instalado correctamente.
Qué hacer a continuación
“Adición de valores de parámetros al archivo de propiedades”
Adición de valores de parámetros al archivo de propiedades
Durante la migración, ejecutará una serie de scripts. Complete el archivo de
propiedades con todos los valores de los parámetros que utilizan los scripts
durante el proceso de migración.
Antes de empezar
El archivo de propiedades está empaquetado en el archivo tpm5112migration.zip
en el DVD Tivoli Provisioning Manager Version 7.1.1 Installation o en la imagen de
TPM_V711_Install en Passport Advantage. Asegúrese de que ha extraído el archivo
comprimido en el servidor de suministro 5.1.1.2, de modo que pueda encontrar el
archivo de propiedades.
Existe un archivo de propiedades que gestiona todos los parámetros necesarios
para que los scripts realicen la copia de seguridad del servidor de suministro
5.1.1.2 y completen la migración en el servidor de suministro 7.1.1. Edite el archivo
de propiedades y añada todos los valores de los parámetros. Cuando ejecuta los
scripts durante la migración, los scripts extraen los valores de los parámetros desde
este archivo.
Consulte la lista de parámetros y sus valores predeterminados, o los valores de
ejemplo y las descripciones.
v “Parámetros para el script de copia de seguridad del sistema 5.1.1.2” en la
página 160. Estos parámetros se utilizan para el script tpm5112backup.
v “Parámetros para los scripts de migración que se ejecutan en el sistema 7.1.1” en
la página 165. Estos parámetros se utilizan para los scripts que se ejecutan en el
servidor de suministro 7.1.1:
– tpm711restore
– tpm711migrate
– tpm711ChangeDBHost
– tpm711ChangeOtherHost
Importante: Requisitos para los archivos de propiedades
v Todos los parámetros que especifiquen un valor entre corchetes ([]) son valores
de ejemplo y se deben revisar. Si el valor del ejemplo es correcto, suprima los
corchetes. Si el valor de ejemplo no es correcto, suprima el valor de ejemplo y
los corchetes y escriba el valor correcto. El script comprueba que se hayan
eliminado todos los corchetes de los parámetros necesarios.
v
UNIX
. Elimine los parámetros específicos de Oracle del archivo
tpmmigrate_unix.properties:
1. orclChangeWordSize
2. orclOSUser
Capítulo 3. Tareas previas a la migración
155
Siga los pasos para configurar el archivo de propiedades:
1. Abra el archivo de propiedades.
v
Windows
TIO_HOME\migration\scripts\tpmmigrate_win.properties
TIO_HOME/migration/scripts/
tpmmigrate_unix.properties
2. Añada los valores de los parámetros para el script de copia de seguridad. Los
valores son sensibles a las mayúsculas y minúsculas. Todos los valores de estos
parámetros hacen referencia al entorno 5.1.1.2.
v
UNIX
Linux
Tabla 51. Parámetros para el script tpm5112backup
Archivo de propiedades
Windows
tpmmigrate_win.properties
Parámetros necesarios
Parámetros opcionales
v dbIsRemote
v baseDN
v outputDir
v userBaseDN
v groupBaseDN
v ldapType
v ldapUseNew
v removeAuditData
v wasUser
v zipBackupFiles
UNIX
tpmmigrate_unix.properties
v dbIsRemote
v ldapType
v outputDir
v ldapUseNew
v baseDN
v orclOSUser
v userBaseDN
v wasUser
v groupBaseDN
v removeAuditData
v zipBackupFiles
3. Añada los valores de los parámetros para el script de restauración. Los valores
son sensibles a las mayúsculas y minúsculas.
Tabla 52. Parámetros para el script tpm711restore
Archivo de propiedades
Windows
tpmmigrate_win.properties
Parámetros necesarios
Parámetros opcionales
v dbAdminUser
v backupDir
v dbIsRemote
v dbOldSchemaName
v dbNewSchemaName
v dbInstanceName
UNIX
tpmmigrate_unix.properties
v dbAdminUser
v orclChangeWordSize
v dbOSUser
v dbIsRemote
v backupDir
v dbOldSchemaName
v dbNewSchemaName
v dbInstanceName
4. Añada los valores de los parámetros para el script de migración. Los valores
son sensibles a las mayúsculas y minúsculas.
156
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 53. Parámetros para el script tpm711migrate
Archivo de propiedades
Windows
tpmmigrate_win.properties
Parámetros necesarios
Parámetros opcionales
v dbAdminUser
v dbAdminGroup
v dbPort
v dbHome
v dbInstanceName
v dbIsRemote
v dbOSUser
v wasUser
v wasNode
v amUser
v amProfileName
v amProfilePort
v amPort
v amCrlPort
v amCellName
v amNodeName
v amHome
v cdsHome
v dmsHome
v fq711HostName
v fq5112HostName
v backupDir
v imagesDir
v tpmHttpPort
v tpmHttpsPort
v tpmUiUser
v dbHostname
v midDbBackup
v sdiClientSSLPort
v sdiServerSSLPort
v wasCellName
Capítulo 3. Tareas previas a la migración
157
Tabla 53. Parámetros para el script tpm711migrate (continuación)
Archivo de propiedades
UNIX
tpmmigrate_unix.properties
Parámetros necesarios
Parámetros opcionales
v dbAdminUser
v dbPort
v dbHome
v dbOSUser
v dbAdminGroup
v dbInstanceName
v dbIsRemote
v amUser
v wasUser
v amProfileName
v amProfilePort
v amPort
v amCrlPort
v amHome
v amNodeName
v amCellName
v cdsHome
v dmsHome
v fq711HostName
v fq5112HostName
v backupDir
v imagesDir
v tpmHttpPort
v tpmHttpsPort
v tpmUiUser
v wasNode
v dbHostname
v midDbBackup
v sdiClientSSLPort
v sdiServerSSLPort
v wasCellName
5. Añada los valores de los parámetros del script para cambiar el nombre de host
del servidor de bases de datos. Los valores son sensibles a las mayúsculas y
minúsculas.
Tabla 54. Parámetros para el script tpm711ChangeDbHost
Archivo de propiedades
Windows
tpmmigrate_win.properties
Parámetros necesarios
Parámetros opcionales
v dbInstanceName
dasUserName
v fq711HostName
v fq5112HostName
v dbIsRemote
v dbOSUser
UNIX
tpmmigrate_unix.properties
v dbOSUser
dasUserName
v dbIsRemote
v fq711HostName
v fq5112HostName
v dbOSUser
6. Añada los valores de los parámetros del script para cambiar los otros nombres
de host. Los valores son sensibles a las mayúsculas y minúsculas.
158
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 55. Parámetros para el script tpm711ChangeOtherHost
Archivo de propiedades
Windows
tpmmigrate_win.properties
Parámetros necesarios
Parámetros opcionales
v fq711HostName
v fq5112HostName
v dbHome
v dbPort
v dbIsRemote
v wasUser
v httpServerHome
v dmgrSoapPort
v dpmfosdDataDir
v CatalogueService.Host
v CertManagement.Host
v AgentQuery.Host
v RegistrationServer.Host
v TrustedCertificateQuery.Host
v AgentManagerQuery.Host
v amUser
v amPort
UNIX
tpmmigrate_unix.properties
v dbIsRemote
v fq711HostName
v fq5112HostName
v wasUser
v httpServerHome
v dmgrSoapPort
v dpmfosdDataDir
v CatalogueService.Host
v CertManagement.Host
v AgentQuery.Host
v RegistrationServer.Host
v TrustedCertificateQuery.Host
v AgentManagerQuery.Host
v dbPort
v cdsHome
v amUser
v amPort
7. Elimine los parámetros específicos de la base de datos que no se apliquen a su
entorno de suministro. Por ejemplo, si utiliza la base de datos DB2, elimine
cualquier parámetro específico a la base de datos Oracle.
8. Revise la lista de parámetros y valores para asegurarse de que son correctos.
9. Guarde el archivo de propiedades.
Qué hacer a continuación
Es importante que los parámetros de este archivo sean correctos. Compruebe dos
veces todos los valores de los parámetros para asegurarse de que sean correctos y
de que se han eliminado los corchetes ([]) de todos los valores. Asimismo, si utiliza
la base de datos DB2, elimine los parámetros específicos de la base de datos
Oracle. Los valores incorrectos generan errores y retardos en el proceso de
migración. Si no está seguro de algunos de los valores, consulte con alguien antes
de continuar.
Cuando esté seguro de que los valores de los parámetros son correctos, puede
iniciar la migración. Consulte el tema denominado “Tareas de migración para el
Capítulo 3. Tareas previas a la migración
159
servidor de suministro 5.1.1.2.” en la página 175 para ver las primeras tareas de la
migración.
Parámetros para el script de copia de seguridad del sistema
5.1.1.2
En esta sección se proporciona una lista completa de los parámetros, las
descripciones y los valores predeterminados o de ejemplo para los parámetros
necesarios para el script tpm5112backup. Todos los valores que especifique para
estos parámetros deben hacer referencia al entorno de suministro de 5.1.1.2.
Se proporciona una lista de los parámetros para el script de copia de seguridad de
cada sistema operativo:
Tabla 58 en la página 165
Tabla 59 en la página 168
Especifique un valor para todos los parámetros del script de copia de seguridad.
No existen valores predeterminados. Windows
Tabla 56. Parámetros para los scripts en los sistemas Windows. Añada los valores para los parámetros en el
archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
baseDN
El DN básico que se utilizará para
la migración. Especifique el valor
que se utilizará en el servidor
LDAP 7.1.1.
Valor predeterminado
Valor de ejemplo
ou=SWG,o=IBM,c=US
Este valor se debe validar para
asegurarse de que es correcto.
dbIsRemote
Indica la ubicación del servidor de
bases de datos.
no
v Especifique no si el servidor de
bases de datos es local; en el
mismo sistema que el servidor de
suministro.
v Especifique yes si el servidor de
bases de datos es remoto; en un
sistema diferente del servidor de
suministro.
Este valor se debe especificar.
Importante: Si el valor será
diferente para el entorno de
suministro de la versión 7.1.1,
cambie este valor después de
ejecutar el script tpm5112backup.
groupBaseDN
El DN basado en grupo que se
utilizará para la migración.
Especifique el valor que se utilizará
en el servidor LDAP 7.1.1.
ou=groups,ou=SWG,o=IBM,c=US
ldapType
Identifica el tipo de LDAP que se
utilizará en el entorno 7.1.1.
ITDS
v Especifique ITDS para Tivoli
Directory Service.
v Especifique MSAD para Microsoft
Active Directory.
Si estaba utilizando la autenticación
del sistema operativo de la versión
5.1.1, debe utilizar un servidor
LDAP de la versión 7.1.1.
Especifique el servidor LDAP que
utilizará.
160
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 56. Parámetros para los scripts en los sistemas Windows (continuación). Añada los valores para los
parámetros en el archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
ldapUseNew
Identifica el caso de ejemplo de
servidor LDAP para la versión
7.1.1.
Valor predeterminado
Valor de ejemplo
nuevos
v Especifique new si utilizará un
nuevo servidor LDAP.
v Especifique exist si utilizará el
servidor LDAP existente.
Si ha utilizado la autenticación del
sistema operativo para la versión
5.1.1, especifique new. Para obtener
más información acerca del valor
adecuado para su caso, consulte la
sección “Consideraciones acerca del
servidor LDAP” en la página 20.
Nota: Si no se especifica este
parámetro en el archivo de
propiedades, se le solicitará el valor
cuando ejecute el script de copia de
seguridad.
outputDir
El directorio donde se almacenarán
los archivos de copia de seguridad
en el sistema 5.1.1.2.
C:\Archivos de
programa\ibm\Tivoli\tpm\
migration\backup
Consideraciones para la creación
del directorio:
v El directorio debe tener espacio
de disco suficiente para
almacenar archivos como las
copias de seguridad de base de
datos, los archivos de copia de
seguridad del gestor de agentes y
los archivos LDIF.
v El tipo de atributo directory se
debe definir.
v Es posible que durante el proceso
de migración se modifiquen los
permisos del directorio y sus
subdirectorios.
Este directorio lo creará
tpm5112backup si todavía no existe.
Este valor se debe especificar.
removeAuditData
Indica si desea que se eliminen
todos los datos de las tablas de
auditoría antes de realizar la copia
de seguridad de la base de datos. Si
se eliminan las tablas se disminuye
la cantidad de tiempo y de datos
para los procesos de copia de
seguridad y restauración.
no
v Especifique no para dejar las
tablas de auditoría.
v Especifique yes para eliminar las
tablas de auditoría.
Importante: Si especifica no, las
tablas de auditoría se incluirán en
la copia de seguridad y se
restaurarán en el servidor de
suministro de 7.1.1 pero se
eliminarán durante la migración de
los datos.
Capítulo 3. Tareas previas a la migración
161
Tabla 56. Parámetros para los scripts en los sistemas Windows (continuación). Añada los valores para los
parámetros en el archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
Valor predeterminado
Valor de ejemplo
userBaseDN
El DN basado en usuario que se
utilizará para la migración.
Especifique el valor que se utilizará
en el servidor LDAP 7.1.1.
ou=users,ou=SWG,o=IBM,c=US
wasUser
El usuario administrador de
WebSphere Application Server.
wasadmin
zipBackupFiles
¿Desea crear un archivo
comprimido de todos los archivos
de copia de seguridad del script
tpm5112backup?
no
v Especifique yes para crear el
archivo comprimido.
v Especifique no para omitir el
archivo comprimido.
En ambas situaciones, se realizará
una copia de seguridad de los
archivos y se creará una estructura
de directorios para la copia de
seguridad.
Importante: Si decide crear un
archivo comprimido, el tamaño de
archivo será bastante grande
debido a que se comprimirá toda la
base de datos. Asegúrese de que
tiene espacio de disco suficiente
para el archivo antes de continuar.
UNIX
Tabla 57. Parámetros para los scripts en sistemas UNIX. Añada los valores a los parámetros del archivo
tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
baseDN
El DN básico que se utilizará para
la migración. Especifique el valor
que se utilizará en el servidor
LDAP 7.1.1.
Valor predeterminado
Valor de ejemplo
ou=SWG,o=IBM,c=US
Este valor se debe validar para
asegurarse de que es correcto.
dbIsRemote
Indica la ubicación del servidor de
bases de datos.
v Especifique no si el servidor de
bases de datos es local; en el
mismo sistema que el servidor de
suministro.
v Especifique yes si el servidor de
bases de datos es remoto; en un
sistema diferente del servidor de
suministro.
Este valor se debe especificar.
Importante: Si el valor será
diferente para el entorno de
suministro de la versión 7.1.1,
cambie este valor después de
ejecutar el script tpm5112backup.
162
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
no
Tabla 57. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
dbOSUser
El usuario del sistema operativo
que se puede conectar a la base de
datos. Cuando se define este
parámetro, el script lo utiliza para
su con el usuario de base de datos,
antes de ejecutar los subscripts de
base de datos.
Valor predeterminado
Valor de ejemplo
ctginst1
Para una base de datos local, el
valor puede ser el mismo que el
valor dbAdminUser.
Para la base de datos remota, este
valor es el usuario del sistema
operativo que puede acceder a las
herramientas del cliente de base de
datos.
groupBaseDN
El DN basado en grupo que se
utilizará para la migración.
Especifique el valor que se utilizará
en el servidor LDAP 7.1.1.
ou=groups,ou=SWG,o=IBM,c=US
ldapType
Identifica el tipo de LDAP que se
utilizará en el entorno 7.1.1.
ITDS
v Especifique ITDS para Tivoli
Directory Service.
v Especifique MSAD para Microsoft
Active Directory.
Si estaba utilizando la autenticación
del sistema operativo de la versión
5.1.1, debe utilizar un servidor
LDAP de la versión 7.1.1.
Especifique el servidor LDAP que
utilizará.
ldapUseNew
Identifica el caso de ejemplo de
servidor LDAP para la versión
7.1.1.
nuevos
v Especifique new si utilizará un
nuevo servidor LDAP.
v Especifique exist si utilizará el
servidor LDAP existente.
Si ha utilizado la autenticación del
sistema operativo para la versión
5.1.1, especifique new. Para obtener
más información acerca del valor
adecuado para su caso, consulte la
sección “Consideraciones acerca del
servidor LDAP” en la página 20.
Nota: Si no se especifica este
parámetro en el archivo de
propiedades, se le solicitará el valor
cuando ejecute el script de copia de
seguridad.
orclOsUser
El nombre de usuario del sistema
operativo para el administrador de
Oracle.
oracle
Este parámetro se puede eliminar si
está utilizando DB2.
Capítulo 3. Tareas previas a la migración
163
Tabla 57. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
outputDir
El directorio en el que se
almacenarán los archivos de copia
de seguridad.
Valor predeterminado
Valor de ejemplo
\opt\IBM\tivoli\tpm\migration\
backup
Consideraciones para la creación
del directorio:
v El directorio debe tener espacio
de disco suficiente para
almacenar archivos como las
copias de seguridad de base de
datos, los archivos de copia de
seguridad del gestor de agentes y
los archivos LDIF.
v El tipo de atributo directory se
debe definir.
v Es posible que durante el proceso
de migración se modifiquen los
permisos del directorio y sus
subdirectorios.
Este directorio lo creará
tpm5112backup si todavía no existe.
Este valor se debe especificar.
removeAuditData
Indica si desea que se eliminen
todos los datos de las tablas de
auditoría antes de realizar la copia
de seguridad de la base de datos.
Esto disminuye la cantidad de
tiempo y los datos de la copia de
seguridad.
no
v Especifique no para dejar los
datos en las tablas de auditoría.
v Especifique yes para eliminar los
datos de las tablas de auditoría.
userBaseDN
El DN basado en usuario que se
utilizará para la migración.
Especifique el valor que se utilizará
en el servidor LDAP 7.1.1.
ou=users,ou=SWG,o=IBM,c=US
wasUser
El usuario administrador de
WebSphere Application Server.
wasadmin
zipBackupFiles
¿Desea crear un archivo
comprimido de todos los archivos
de copia de seguridad del script
tpm5112backup?
no
v Especifique yes para crear el
archivo comprimido.
v Especifique no para omitir el
archivo comprimido.
En ambas situaciones, se realizará
una copia de seguridad de los
archivos y se creará una estructura
de directorios para la copia de
seguridad.
Importante: Si decide crear un
archivo comprimido, el tamaño de
archivo será bastante grande
debido a que se comprimirá toda la
base de datos. Asegúrese de que
tiene espacio de disco suficiente
para el archivo antes de continuar.
164
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Parámetros para los scripts de migración que se ejecutan en
el sistema 7.1.1
Para cada uno de los scripts que se utilizan en la migración se requieren diferentes
parámetros. En esta sección se proporciona una lista completa de los parámetros,
las descripciones y los valores de ejemplo.
Se proporciona una lista de los parámetros para el script de copia de seguridad de
cada sistema operativo:
Tabla 58
Tabla 59 en la página 168
Windows
Tabla 58. Parámetros para los scripts en los sistemas Windows. Añada los valores para los parámetros en el
archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
AgentManagerQuery.Host
El nombre de host completo del
servicio de consulta del gestor de
agentes.
Valor predeterminado
Valor de ejemplo
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
AgentQuery.Host
El nombre de host completo del
servicio de consulta del gestor de
agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
amCellName
El nombre de célula del gestor de
agentes.
example711Node01Cell
amCrlPort
El puerto público del gestor de
agentes.
9513
amHome
El directorio de instalación de
gestor de agentes.
C:\Archivos de programa
(x86)\ibm\AgentManager
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
Se puede utilizar el valor
predeterminado.
amNodeName
El nombre de nodo del gestor de
agentes.
example711Node01
amPort
El puerto de registro del gestor de
agentes.
9511
amProfileName
El nombre de perfil del gestor de
agentes de WebSphere Application
Server.
casprofile
amProfilePort
El puerto de inicio para la creación
del perfil de gestor de agentes.
21000
amUser
El nombre de usuario del gestor de
recursos para el gestor de agentes.
manager
El instalador de Tivoli Provisioning
Manager 7.1.1 crea el nombre de
usuario, manager. A menos que
haya modificado este nombre de
usuario después de la instalación,
utilice el valor predeterminado.
Capítulo 3. Tareas previas a la migración
165
Tabla 58. Parámetros para los scripts en los sistemas Windows (continuación). Añada los valores para los
parámetros en el archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
backupDir
El directorio donde se encuentran
los scripts de copia de seguridad.
Valor predeterminado
Valor de ejemplo
C:\Archivos de
programa\IBM\tivoli\tpm\
migration\tpm5112backup
Este directorio se debe crear
manualmente.
CatalogueService.Host
El nombre de host completo del
servicio de catálogo.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
Directorio de instalación de
Dynamic Content Delivery.
cdsHome
C:\Archivos de
programa\ibm\Tivoli\CDS
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
CertManagement.Host
El nombre de host completo del
gestor de certificación del gestor de
agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
dasUserName
El nombre de usuario del servidor
de administración de base de datos.
dbAdminGroup
El grupo de administración de base
de datos de la instancia.
dasusr1
db2grp1
Se puede utilizar el valor
predeterminado.
dbAdminUser
El propietario de la instancia del
servidor de DB2.
db2admin
dbHome
El directorio SQLLIB de la instancia
de DB2 local.
C:\Archivos de
programa\ibm\SQLLIB
dbHostname
El nombre de host completo del
servidor de bases de datos.
example.db.ibm.com
dbInstanceName
El nombre de la instancia de base
de datos DB2.
ctginst1
Se puede utilizar el valor
predeterminado.
dbIsRemote
no
Indica la ubicación del servidor de
bases de datos.
v Especifique no si el servidor de
bases de datos es local; en el
mismo sistema que el servidor de
suministro.
v Especifique yes si el servidor de
bases de datos es remoto; en un
sistema diferente del servidor de
suministro.
Este valor se debe especificar.
dbNewSchemaName
El nombre del esquema de base de
datos que se utilizará en la versión
7.1.1.
MAXIMO
Se puede utilizar el valor
predeterminado.
Nota: El valor es sensible a las
mayúsculas y minúsculas.
166
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 58. Parámetros para los scripts en los sistemas Windows (continuación). Añada los valores para los
parámetros en el archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
dbOldSchemaName
El nombre del esquema de base de
datos original que se ha utilizado
en la versión 5.1.1.2.
Nota: El valor es sensible a las
mayúsculas y minúsculas. Escriba
el nombre de esquema como se ha
definido para 5.1.1.2.
Valor predeterminado
Valor de ejemplo
TIOADMIN
Abra el archivo
TIO_HOME/config/dcm.xml en el
servidor de suministro de 5.1.1.2 y
busque la etiqueta <username>. El
valor especificado en la etiqueta es
el nombre de esquema 5.1.1.2.
Utilice este nombre como el valor
para el parámetro dbOldSchemaName.
dbPort
El puerto del host DB2.
50005
Se puede utilizar el valor
predeterminado.
Si ha configurado DB2 con un
puerto diferente, cambie el valor
por el número de puerto correcto.
dmgrSoapPort
El puerto SOAP del gestor de
despliegue.
8879
dmsHome
El directorio de instalación del
servicio del gestor de dispositivos.
C:\Archivos de
programa\ibm\DeviceManager
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
fq5112HostName
El nombre de host completo para el
sistema 5.1.1.2.
example5112.ibm.com
fq711HostName
El nombre de host completo para el
sistema 7.1.1.
example711.ibm.com
httpServerHome
El directorio padre del servidor
HTTP que ha instalado el instalador
de middleware de 7.1.1.
C:\Archivos de
programa\IBM\HTTPServer
imagesDir
Este es el directorio de instalación
raíz, donde se encuentran los
archivos binarios de Common
Agent Services, Dynamic Content
Delivery y del servicio del gestor
de dispositivos.
C:\TpmMediaImage
midDbBackup
¿Desea iniciar una copia de
seguridad para guardar la
información restaurada y migrada?
no
Este parámetro le proporciona la
opción de iniciar una copia de
seguridad después de restaurar
5.1.1.2 y migrarlo al sistema 7.1.1. Si
encuentra problemas en los
siguientes pasos de la migración,
puede restaurar esta copia de
seguridad, en lugar de restaurar
una copia de seguridad sin los
datos migrados.
La copia de seguridad tardará
algún tiempo en completarse, por
lo tanto, el valor predeterminado de
este parámetro es no.
Capítulo 3. Tareas previas a la migración
167
Tabla 58. Parámetros para los scripts en los sistemas Windows (continuación). Añada los valores para los
parámetros en el archivo tpmmigrate_win.properties
Nombre de parámetro
Descripción del parámetro
Registration.Server.Host
El nombre de host completo del
servidor de registro del gestor de
agentes.
Valor predeterminado
Valor de ejemplo
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
sdiClientSSLPort
El puerto SSL del cliente de la
infraestructura de distribución
escalable.
9046
sdiServerSSLPort
El puerto SSL del sistema de la
infraestructura de distribución
escalable.
9045
tpmfosdDataDir
El directorio donde se encuentran
los archivos de imágenes, de
registro y de configuración de
Tivoli Provisioning Manager for OS
Deployment.
Archivos de C:\tpmfosd
Si no los ha instalado, puede
eliminar el parámetro.
tpmHttpPort
El puerto no SSL de la
infraestructura de distribución
escalable.
tpmHttpsPort
El puerto SL del servidor de
suministro.
9080
9443
Se puede utilizar el valor
predeterminado.
tpmUiUser
El nombre de usuario
maxadmin
administrativo para el registro en la
interfaz web de suministro. Durante
la instalación nueva de 7.1.1, se crea
el usuario predeterminado
maxadmin.
Se puede utilizar el valor
predeterminado.
TrustedCertificateQuery.Host
El nombre de host completo para el
servicio de consulta de certificados
de confianza del gestor de agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
wasCellName
El nombre de célula de WebSphere
Application Server.
ctgCell01
wasNode
El nombre de nodo de WebSphere
Application Server.
ctgNode01
wasUser
El usuario administrador de
WebSphere Application Server.
wasadmin
UNIX
Tabla 59. Parámetros para los scripts en sistemas UNIX. Añada los valores a los parámetros del archivo
tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
AgentManagerQuery.Host
El nombre de host completo del
servicio de consulta del gestor de
agentes.
Valor predeterminado
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
168
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Valor de ejemplo
example5112.ibm.com
Tabla 59. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
AgentQuery.Host
El nombre de host completo del
servicio de consulta del agente.
Valor predeterminado
Valor de ejemplo
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
amCellName
El nombre de célula del gestor de
agentes.
example711Node01Cell
amCrlPort
El puerto público del gestor de
agentes.
9513
amHome
El directorio de instalación del
gestor de agentes.
/opt/IBM/AgentManager
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
Se puede utilizar el valor
predeterminado.
amNodeName
El nombre de nodo del gestor de
agentes.
example711Node01
amPort
El puerto de registro del gestor de
agentes.
9511
amProfileName
El nombre de perfil del gestor de
agentes.
casprofile
amProfilePort
El puerto de inicio para la creación
del perfil de gestor de agentes.
21000
amUser
El nombre de usuario para el gestor manager
de recursos del gestor de agentes.
El instalador de Tivoli Provisioning
Manager 7.1.1 crea el nombre de
usuario, manager. A menos que
haya modificado este nombre de
usuario después de la instalación,
utilice el valor predeterminado.
backupDir
El directorio donde se encuentran
los scripts de copia de seguridad.
/tmp/backupNew
Este directorio se debe crear
manualmente.
CatalogueService.Host
El nombre de host completo del
servicio de catálogo.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
cdsHome
El directorio de instalación de
Dynamic Content Delivery.
/opt/IBM/CDS
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
CertManagement.Host
El nombre de host completo del
gestor de certificación del gestor de
agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
dasUserName
El nombre de usuario del servidor
de administración de base de datos.
dasusr1
Capítulo 3. Tareas previas a la migración
169
Tabla 59. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
Valor predeterminado
dbAdminGroup
El grupo de administración de base
de datos de la instancia.
v
Se puede utilizar el valor
predeterminado.
dbAdminUser
El propietario de la instancia del
servidor de bases de datos. El
nombre de usuario que se conecta a
la base de datos como el
administrador del sistema.
dbHome
El directorio de la instancia de base
de datos local.
dbHostname
El nombre de host completo de la
base de datos.
dbInstanceName
El nombre de instancia de base de
datos de DB2, o el ID del sistema
Oracle (SID).
v
Valor de ejemplo
: db2grp1
Oracle
2000
: oinstall
sys
v
:
/home/ctginst1/sqllib
v
Oracle
2000
:
/u01/app/oracle/product/
10.2.0/db_1
example.db.ibm.com
ctginst1
Se puede utilizar el valor
predeterminado para DB2.
dbIsRemote
no
Indica la ubicación del servidor de
bases de datos.
v Especifique no si el servidor de
bases de datos es local; en el
mismo sistema que el servidor de
suministro.
v Especifique yes si el servidor de
bases de datos es remoto; en un
sistema diferente del servidor de
suministro.
Este valor se debe especificar.
dbNewSchemaName
El nombre del esquema de base de
datos que se utilizará en la versión
7.1.1.
Nota: El valor es sensible a las
mayúsculas y minúsculas.
MAXIMO
Se puede utilizar el valor
predeterminado.
dbOldSchemaName
El nombre del esquema de base de
datos original que se ha utilizado
en la versión 5.1.1.2.
Nota: El valor es sensible a las
mayúsculas y minúsculas. Escriba
el nombre de esquema como se ha
definido para 5.1.1.2.
Abra el archivo
TIO_HOME/config/dcm.xml en el
servidor de suministro de 5.1.1.2 y
busque la etiqueta <username>. El
valor especificado en la etiqueta es
el nombre de esquema 5.1.1.2.
Utilice este nombre como el valor
para el parámetro dbOldSchemaName.
170
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
DB2INST1
Tabla 59. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
dbOSUser
El usuario del sistema operativo
que se puede conectar a la base de
datos. Cuando se define este
parámetro, el script lo utiliza para
su con el usuario de base de datos,
antes de ejecutar los subscripts de
base de datos.
Valor predeterminado
Valor de ejemplo
ctginst1
Para una base de datos local, el
valor puede ser el mismo que el
valor dbAdminUser.
Para la base de datos remota, este
valor es el usuario del sistema
operativo que puede acceder a las
herramientas del cliente de base de
datos.
dbPort
El puerto del host de base de datos.
: 50005
v
Se puede utilizar el valor
predeterminado a menos que haya
configurado la base de datos para
que se ejecute en un puerto
diferente.
v
Oracle
2000
: 1521
dmgrSoapPort
El puerto SOAP del gestor de
despliegue.
8879
dmsHome
El directorio de instalación del
servicio del gestor de agentes.
/opt/IBM/DeviceManager
El directorio que especifique se
creará cuando el script
tpm711migrate instale el
componente.
fq5112HostName
El nombre de host completo para el
sistema 5.1.1.2.
example5112.ibm.com
fq711HostName
El nombre de host completo para el
sistema 7.1.1.
example711.ibm.com
httpServerHome
El directorio padre del servidor
HTTP que ha instalado el
instalador de middleware de 7.1.1.
/opt/IBM/HTTPServer
imagesDir
Este es el directorio de instalación
raíz, donde se encuentran los
archivos binarios de Common
Agent Services, Dynamic Content
Delivery y del servicio del gestor
de dispositivos.
/root/tpm711/tmp/
TPMMediaImage
midDbBackup
¿Desea iniciar una copia de
seguridad para guardar la
información restaurada y migrada?
no
Este parámetro le proporciona la
opción de iniciar una copia de
seguridad después de restaurar
5.1.1.2 y migrarlo al sistema 7.1.1.
Si encuentra problemas en los
siguientes pasos de la migración,
puede restaurar esta copia de
seguridad, en lugar de restaurar
una copia de seguridad sin los
datos migrados.
La copia de seguridad tardará
algún tiempo en completarse, por
lo tanto, el valor predeterminado
de este parámetro es no.
Capítulo 3. Tareas previas a la migración
171
Tabla 59. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
orclChangeWordSize
¿Es necesario modificar la base de
datos Oracle de 32 bits a 64 bits o
viceversa? Por ejemplo, si la
versión 5.1.1.2 utiliza la base de
datos Oracle de 32 bits y la versión
7.1.1 utiliza la de 64 bits,
especifique yes.
Valor predeterminado
Valor de ejemplo
no
v Especifique yes para cambiar el
tamaño de palabra en la base de
datos Oracle.
v Especifique no si el tamaño de
palabra no se debe modificar en
la base de datos Oracle.
Si está utilizando la base de datos
DB2, puede eliminar este parámetro
del archivo de propiedades.
Registration.Server.Host
El nombre de host completo del
servidor de registro del gestor de
agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
sdiClientSSLPort
El puerto SSL del cliente de la
infraestructura de distribución
escalable.
9046
sdiServerSSLPort
El puerto SSL del sistema de la
infraestructura de distribución
escalable.
9045
tpmfosdDataDir
El directorio donde se encuentran
los archivos de imágenes, de
registro y de configuración de
Tivoli Provisioning Manager for OS
Deployment.
/opt/tpmfosd_files
Si no se ha instalado, puede
eliminar este parámetro.
tpmHttpPort
El puerto no SSL del sistema de la
infraestructura de distribución
escalable.
tpmHttpsPort
El puerto SL del sistema del
servidor de suministro.
9080
9443
Se puede utilizar el valor
predeterminado.
tpmUiUser
maxadmin
El nombre de usuario
administrativo para el registro en la
interfaz web de suministro.
Durante la instalación nueva de
7.1.1, se crea el usuario
predeterminado maxadmin.
Se puede utilizar el valor
predeterminado.
TrustedCertificateQuery.Host
El nombre de host completo del
servicio de consulta de certificados
de confianza del gestor de agentes.
example5112.ibm.com
Generalmente el nombre es el
mismo que el nombre de host
completo de 5.1.1.2.
wasCellName
El nombre de célula de WebSphere
Application Server.
ctgCell01
wasNode
El nombre de nodo de WebSphere
Application Server.
ctgNode01
172
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 59. Parámetros para los scripts en sistemas UNIX (continuación). Añada los valores a los parámetros del
archivo tpmmigrate_unix.properties
Nombre de parámetro
Descripción del parámetro
wasUser
El usuario administrador de
WebSphere Application Server.
Valor predeterminado
Valor de ejemplo
wasadmin
Capítulo 3. Tareas previas a la migración
173
174
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 4. Migración de Tivoli Provisioning Manager
Durante la migración, es necesario realizar una serie de pasos en el servidor de
suministro 5.1.1.2 y en el nuevo servidor de suministro 7.1.1.
Tareas de migración para el servidor de suministro 5.1.1.2.
Haga una copia de seguridad del servidor de bases de datos y de la información
de configuración de 5.1.1.2 en el servidor de suministro, de modo que pueda
migrar la información al entorno 7.1.1.
Realice las siguientes tareas para realizar la copia de seguridad del servidor de
suministro 5.1.1.2:
Visión general: la copia de seguridad de la versión 5.1.1.2
Revise el proceso para realizar la copia de seguridad del servidor de suministro
versión 5.1.1.2. El proceso depende de si el entorno de suministro utiliza un
servidor de bases de datos remoto y local.
Para migrar el servidor de suministro 5.1.1.2, realizará una copia de seguridad de
la información de configuración y base de datos y, a continuación, restaurará la
información en el sistema donde ha instalado IBM Tivoli Provisioning Manager
versión 7.1.1. Si tiene un servidor de bases de datos local, la copia de seguridad de
la configuración y la base de datos 5.1.1.2 se completa ejecutando un script en el
servidor de suministro. Si el entorno de suministro 5.1.1.2 incluye un servidor de
bases de datos remoto, ejecutará el script en el servidor de suministro para realizar
la copia de seguridad de la información de configuración y ejecutará un script en
el servidor de bases de datos para realizar la copia de seguridad de la base de
datos.
El siguiente diagrama describe el proceso para un entorno con una base de datos
local y una base de datos remota. Si utiliza un servidor de bases de datos remoto,
serán necesarios todos los pasos descritos para el servidor de suministro 5.1.1.2 y el
servidor de bases de datos. Los usuarios de la base de datos local sólo realizan las
tareas de copia de seguridad para el entorno de suministro 5.1.1.2. Utilice el
diagrama para comprender cómo se completará la copia de seguridad.
© Copyright IBM Corp. 2009
175
Inicio del proceso de copia de seguridad
Inicio de la copia de seguridad
de la base de datos remota
Detener el servidor de suministro
Copiar el archivo RemoteDbTools.zip
en el servidor de bases de datos 5.1.1.2
Realizar copia de seguridad
de la base de datos
¿La base de datos es remota?
Sí
Copia de seguridad de la base
de datos remota finalizada
No
Realizar copia de seguridad de los
datos de 5.1.1.2
Local = configuración y base de datos
Remota = sólo configuración
Leyenda
Proceso de copia de seguridad finalizado
Tareas en el entorno de
suministro 5.1.1.2
Tareas en el servidor de
bases de datos remoto
Detenga el servidor de suministro 5.1.1.2
Antes de comenzar la copia de seguridad, detenga el servidor de
suministro de modo que la información de configuración y base de datos
5.1.1.2 esté sincronizada con la información que restaura en el sistema 7.1.1.
Copie los archivos que necesite para la copia de seguridad del servidor de
suministro.
Los archivos necesarios para la copia de seguridad están empaquetados en
el DVD del producto. Copiará el archivo comprimido,
tpm5112migration.zip, en el servidor de suministro y extráigalo para
obtener las herramientas de copia de seguridad. El archivo comprimido
contiene el script principal para la copia de seguridad y un archivo de
propiedades que controla el comportamiento del script de copia de
seguridad y el comportamiento de todos los otros scripts que utilizará para
la migración.
Edite el archivo de propiedades
Se proporciona un archivo de propiedades, de modo que puede especificar
toda la información que necesitan los scripts de migración. El script de
copia de seguridad es el primer script que ejecutará en el proceso de
migración, pero ahora configurará el archivo de propiedades para todos los
scripts. Cuando se ejecute el script, éste recuperará los valores del archivo
de propiedades y continuará sin solicitarle información. Es muy importante
que añada los valores correctos al archivo de propiedades. Los valores
incorrectos generarán errores y retrasos en el proceso de migración.
176
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Copia de seguridad de los datos 5.1.1.2
Ejecute el script tpm5112backup para realizar una copia de seguridad de los
datos 5.1.1.2. Cuando se ejecute el script, éste buscará los valores de los
parámetros que ha especificado en el archivo de propiedades. Para el script
de copia de seguridad, el parámetro dbIsRemote es muy importante porque
define de qué hará una copia de seguridad el script, en función de su
entorno:
Servidor de bases de datos remoto. Si tiene un servidor de bases de
datos remoto, el valor del parámetro dbIsRemote es yes. Este parámetro
indica al script tpm5112backup que sólo ha de hacer la copia de
seguridad de la información de configuración relacionada con el
servidor de suministro. Ejecutará un script separado en el servidor de
bases de datos remoto para realizar la copia de seguridad de dichos
datos.
Base de datos local. Si tiene una base de datos local, el valor del
parámetro dbIsRemote es no. El script tpm5112backup realizará la copia
de seguridad de la información de configuración y también invocará un
script para realizar la copia de seguridad de la base de datos local.
Detenga e inicie el servidor de bases de datos remoto.
Este paso es únicamente para los servidores de bases de datos remotos.
Antes de comenzar la copia de seguridad, detenga el servidor de bases de
datos y luego vuelva a iniciarla para asegurarse de que no hay
transacciones pendientes.
Copie el archivo RemoteDBTools.zip en el servidor de bases de datos remoto.
Este paso es únicamente para los servidores de bases de datos remotos.
Copie el archivo RemoteDBTools.zip desde el DVD del producto y
extráigalo en el servidor de bases de datos. El archivo comprimido
contiene los scripts que ejecutará para realizar la copia de seguridad de la
información de base de datos.
Copia de seguridad de la base de datos
Este paso es únicamente para los servidores de bases de datos remotos.
Ejecute el script de copia de seguridad db2BackupRemote o
oracleBackupRemote, para realizar la copia de seguridad del servidor de
bases de datos remoto.
Cancelación de tareas y planes de actividades
Para evitar bloqueos de base de datos y otros problemas, asegúrese de que no hay
ninguna tarea ni plan de actividades en ejecución antes de detener el servidor de
suministro e iniciar la migración.
Antes de concluir el servidor de suministro 5.1.1.2, permita que finalice la ejecución
de todas las tareas y planes de actividades o cancélelos.
1. Inicie la sesión en la interfaz web de suministro.
2. Para ver las tareas y planes de actividades, vaya a sus páginas respectivas:
v Planes de actividades: Gestión de tareas → Realizar seguimiento de planes
de actividades.
v Tareas: Gestión de tareas → Realizar seguimiento de tareas
para visualizar todas las tareas o planes de
3. En cada página, haga clic en
actividades que se están ejecutando.
4. Espere a que las tareas o planes de actividades se completen o cancélelas. Para
cancelarlas, junto a cada tarea o plan de actividad, haga clic en
→ Cancelar.
Capítulo 4. Migración de Tivoli Provisioning Manager
177
Qué hacer a continuación
“Detención del servidor de suministro”
Detención del servidor de suministro
Detenga el servidor de suministro utilizando los métodos suministrados para las
plataformas Windows o UNIX.
Detención del servidor de suministro en Windows
Puede detener el servidor de suministro de una de las siguientes maneras:
v Desde el escritorio de Windows
v En la línea de mandatos
De forma predeterminada, cuando detiene el servidor de suministro, los perfiles de
WebSphere Application Server asociados con el servidor de suministro también se
detienen.
Para obtener información sobre otras opciones de inicio y detención para el
servidor de suministro, busque mandato tio en el centro de información.
1. Inicie la sesión como tioadmin.
2. Detenga el servidor de suministro.
En el escritorio de Windows:
Haga doble clic en Detener TPM.
En la línea de mandatos
a. En un indicador de mandatos, vaya a TIO_HOME/tools, donde
TIO_HOME es el directorio de instalación para Tivoli Provisioning
Manager. El directorio predeterminado esC:\Archivos de
programa\IBM\tivoli\tpm.
b. Escriba tio.cmd stop.
Resultados
Cuando el cierre se realice correctamente, aparecerá el mensaje El cierre de TIO
se ha completado.
Si el servidor de suministro no se detiene, revise los errores de los siguientes
archivos de registro
v TIO_LOGS\tio_stop.log
v TIO_LOGS\tio_stop_service.log
Si el servidor de suministro no se detiene correctamente, haga clic en el icono
Detener TPM o vuelva a ejecutar el mandato tio.cmd stop.
Detención del servidor de suministro en UNIX o Linux
Antes de empezar
Para detener el servidor de suministro, debe saber cuál es la contraseña del
administrador en WebSphere Application Server.
De forma predeterminada, cuando detiene el servidor de suministro, los perfiles de
WebSphere Application Server asociados con el servidor de suministro también se
detienen.
178
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
1. Vaya a TIO_HOME/tools, donde TIO_HOME es el directorio de instalación de
Tivoli Provisioning Manager. El directorio predeterminado
es/opt/IBM/tivoli/tpm.
2. Escriba ./tio.sh stop.
3. Después de detener el servidor de suministro, es posible que algunos procesos
Java del cliente WebSphere se sigan ejecutando. Para detener estos procesos de
Java antes de reiniciar el servidor de suministro, ejecute el mandato pkill -9
java.
Resultados
Ahora ha detenido el servidor de suministro.
Si el servidor de suministro no se detiene, compruebe los archivos de registro
siguientes si hay errores:
v TIO_LOGS/tio_stop.log
v TIO_LOGS/tio_stop_service.log
Si el servidor de suministro no se detiene correctamente, vuelva a ejecutar el
mandato tio.sh stop.
Qué hacer a continuación
Realice una copia de seguridad del servidor de bases de datos.
v Si tiene un servidor de bases de datos remoto, consulte “Copia de seguridad de
un servidor de bases de datos remoto”
v Si tiene un servidor de bases de datos loca, consulte “Copia de seguridad de
Tivoli Provisioning Manager 5.1.1.2” en la página 180
Copia de seguridad de un servidor de bases de datos remoto
Este paso sólo es necesario si tiene un servidor de bases de datos remoto.
Si su entorno de suministro 5.1.1.2 utiliza un servidor de bases de datos remoto,
realizará dos copias de seguridad: una copia de seguridad de los datos del
servidor de bases de datos remoto y una copia de seguridad del servidor de
suministro 5.1.1.2 para tener una copia de seguridad de la información de
configuración.
Siga estos pasos para realizar una copia de seguridad de los datos del servidor de
bases de datos remoto:
1. Inicie la sesión en el servidor de bases de datos.
v
Inicie la sesión con el nombre de usuario y la contraseña del
administrador de la base de datos DB2.
Oracle
2000
Inicie la sesión como el usuario administrativo de Oracle.
v
2. Acceda al archivo migration/remoteDbTools.zip desde el DVD de instalación.
3. Copie y extraiga el archivo en el servidor de bases de datos.
4. Realice una copia de seguridad de la base de datos.
v
Oracle
2000
Ejecute el mandato siguiente:
oracleBackupRemote.sh [nombre bd][directorio copia de seguridad}
donde
Capítulo 4. Migración de Tivoli Provisioning Manager
179
nombre bd especifica el nombre de la base de datos de la que está
realizando una copia de seguridad.
directorio copia de seguridad especifica la ubicación en la que se
almacenarán los archivos de copia de seguridad cuando se haya
completado la copia de seguridad.
v
Windows
Abra una ventana de mandatos de base de datos y vaya al
directorio donde ha extraído el archivo remoteDbTools.zip. Ejecute el
mandato siguiente:
db2BackupRemote.cmd [nombre bd][nombre usuario bd][contraseña bd][directorio copia de seguridad]
donde
nombre bd especifica el nombre de la base de datos de la que está
realizando una copia de seguridad.
nombre usuario bd es el nombre de usuario para la conexión con la base
de datos.
contraseña bd especifica la contraseña del nombre de usuario.
directorio copia de seguridad especifica la ubicación en la que se
guardarán los archivos de copia de seguridad cuando se haya completado
la copia de seguridad.
UNIX
Ejecute el mandato siguiente:
db2BackupRemote.sh [nombre bd][nombre usuario bd][directorio copia de seguridad]
donde
nombre bd especifica el nombre de la base de datos de la que está
realizando una copia de seguridad.
nombre usuario bd es el nombre de usuario para la conexión con la base
de datos.
directorio copia de seguridad especifica la ubicación en la que se
guardarán los archivos de copia de seguridad cuando se haya completado
la copia de seguridad.
Cuando finaliza el mandato, se realizará una copia de seguridad de la
información de la base de datos y se almacenará en un archivo comprimido en
la ubicación que ha especificado.
Qué hacer a continuación
Ejecute una copia de seguridad local en el servidor de suministro para la
información de configuración de 5.1.1.2. Consulte “Copia de seguridad de Tivoli
Provisioning Manager 5.1.1.2”
En el archivo de propiedades, ha especificado el valor del parámetro dbIsRemote
como yes, por lo tanto, la siguiente copia de seguridad ignorará la copia de
seguridad de base de datos y sólo realizará una copia de seguridad de la
información de configuración del servidor de suministro 5.1.1.2.
Copia de seguridad de Tivoli Provisioning Manager 5.1.1.2
El primer paso de la migración es realizar la copia de seguridad del servidor de
suministro 5.1.1.2.
180
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Antes de empezar
Asegúrese de que ha completado las tareas siguientes antes de iniciar la copia de
seguridad:
1. Ha concluido el servidor de suministro.
2. Ha copiado el archivo tpm5112migration.zip desde el DVD al servidor de
suministro 5.1.1.2 y lo ha extraído para crear la carpeta migration.
3.
UNIX
Ejecute los mandatos siguientes para asegurarse de que los scripts de
la carpeta de migración tienen el permiso ejecutable:
./chmod -R 775 TIO_HOME/migration/scripts/*
./chmod -R 775 TIO_HOME/migration/scripts/.*
4. Si está utilizando la base de datos Oracle, la variable de entorno
$ORACLE_HOME está establecida para el usuario oracle. Para obtener más
detalles, consulte Instalación del servidor de Oracle Database en AIX, Linux
(x86 64 bits) y Solaris.
5. Añada los valores de los parámetros del script de copia de seguridad al archivo
de propiedades. Consulte “Adición de valores de parámetros al archivo de
propiedades” en la página 155. Compruebe por segunda vez que los valores de
los parámetros sean correctos antes de ejecutar el script de copia de seguridad.
En especial, el valor del parámetro dbIsRemote se debe configurar
correctamente. El valor es no si tiene una base de datos local y yes si tiene una
base de datos remota.
Importante: Si anteriormente ha ejecutado el script tpm5112backup, por ejemplo, si
ha ejecutado el script en una ventana de mantenimiento anterior, elimine o cambie
el nombre del archivo TIO_LOGS/migration/tpm5112backup_status.log. Para
obtener más información, consulte la sección en “Registros de estado ” en la
página 265.
Copia de seguridad del servidor de suministro 5.1.1.2
En función del servidor de bases de datos del entorno de suministro, esta tarea
realiza las siguientes copias de seguridad:
v Servidor de bases de datos local:
– Copia de seguridad de configuración del servidor de suministro 5.1.1.2
– Copia de seguridad de base de datos
v Servidor de bases de datos remoto
– Copia de seguridad de configuración del servidor de suministro 5.1.1.2
Siga los pasos siguientes para realizar la copia de seguridad:
1. Inicie sesión en el servidor de suministro.
v
Windows
Inicie la sesión como tioadmin.
UNIX
Inicie la sesión como root.
v
2. Abra una ventana de mandatos y vaya al directorio TIO_HOME/migration/
scripts/.
3. Ejecute el mandato para realizar la copia de seguridad de los datos 5.1.1.2:
v
Windows
: tpm5112backup.cmd
UNIX
: ./tpm5112backup.sh
v
Se le solicitará la contraseña del usuario de base de datos.
Capítulo 4. Migración de Tivoli Provisioning Manager
181
4. Para validar que la copia de seguridad se ha realizado correctamente, vaya a
TIO_LOGS/migration y abra el archivo tpm5112backup_status.log. El archivo de
registro lista el estado de cada paso que se ha completado. Todos los pasos
deben estar marcados como DONE.
El script tpm5112backup completa las siguientes tareas de copia de seguridad de
datos y configuración:
a. Prepara un archivo de exportación LDIF para los usuarios y roles definidos
para el servidor de suministro que no están en el directorio LDAP.
b. Ejecuta la herramienta de copia de seguridad y prepara un archivo
comprimido con los certificados y la configuración del gestor de agentes.
c. Opcional. Elimina las entradas de la tabla de auditoría. Esto dependerá de si
ha especificado el parámetro removeAuditData en el archivo de propiedades.
d. Copia todos los archivos en un volumen nuevo al que puede acceder el
sistema 7.1.1.
e. Si el servidor de bases de datos es local, crea una copia de seguridad de la
base de datos de suministro.
Si encuentra algún problema durante la ejecución del script de copia de
seguridad, visualice los problemas potenciales y los archivos de registro para
poder resolver el problema y continuar:
v Detalles de recuperación de los problemas que se producen en el script de
copia de seguridad
v “Códigos de retorno” en la página 255
Resultados
Si ha utilizado el parámetro zipBackupFiles en el archivo de propiedades, se
creará un archivo comprimido en la ubicación que ha especificado en el parámetro
outputDir. De lo contrario, la estructura del directorio de copia de seguridad estará
en la ubicación outputDir.
Cuando se haya realizado la copia de seguridad del servidor de suministro, podrá
continuar en el paso siguiente de la migración para preparar la restauración de los
datos 5.1.1.2 en el nuevo servidor de suministro 7.1.1.
Qué hacer a continuación
Las tareas de migración del entorno de suministro 5.1.1.2 se han completado.
Continúe con el proceso de migración en el servidor de suministro 7.1.1. Revise el
tema denominado “Visión general: restauración de los datos 5.1.1.2”.
Para el primer paso de migración en el servidor de suministro 7.1.1, consulte
“Inicio del middleware” en la página 184.
Tareas de migración para el servidor de suministro 7.1.1
Realice las tareas siguientes para completar la migración al servidor de suministro
versión 7.1.1.
Visión general: restauración de los datos 5.1.1.2
Revise el proceso para restaurar los datos de copia de seguridad del servidor de
suministro versión 5.1.1.2. El proceso depende de si el entorno de suministro
utiliza un servidor de bases de datos remoto y local.
182
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Para rellenar el sistema 7.1.1 con los datos de la copia de seguridad, copie los
datos del servidor de suministro 5.1.1.2 y guárdelos en el sistema 7.1.1. Si tiene un
servidor de bases de datos local, la restauración de la configuración y la base de
datos 5.1.1.2 se completa ejecutando un script en el sistema 7.1.1. Si el entorno de
suministro 5.1.1.2 incluye un servidor de bases de datos remoto, ejecutará el script
en el sistema 7.1.1 para realizar la copia de seguridad de la información de
configuración y ejecutará un script en el servidor de bases de datos nuevo para
realizar la copia de seguridad de la base de datos.
El siguiente diagrama describe el proceso para un entorno con una base de datos
local y una base de datos remota. Utilice el diagrama para comprender cómo se
restaurarán los datos.
Inicio de la restauración de la
base de datos remota
Inicio del proceso de restauración
¿La base de datos es remota?
Sí
Copiar el archivo RemoteDbTools.zip
en el servidor de bases de datos 7.1.1
No
Copiar los datos
al sistema 7.1.1
Copiar la copia de seguridad de la base de
datos al servidor de bases de datos 7.1.1
Restaurar la información de
la base de datos
Copiar el archivo de propiedades
al sistema 7.1.1
Restauración de bases de
datos remota finalizada
Restaurar los datos de 5.1.1.2
Local = configuración y base de datos
Remota = sólo configuración
Leyenda
Tareas en el entorno de
suministro 7.1.1
Proceso de restauración finalizado
Tareas en el servidor de
bases de datos remoto
Copie los datos en el sistema 7.1.1
Cuando se completa el script, los archivos de copia de seguridad se
guardan en el directorio que ha especificado en el archivo de propiedades.
Si ha especificado el parámetro para guardar los datos de copia de
seguridad en un archivo comprimido, habrá un archivo .zip disponible. De
lo contrario, puede comprimir el directorio de copia de seguridad o
simplemente copiar los datos en el sistema 7.1.1.
Copie el archivo de propiedades en el sistema 7.1.1
El archivo de propiedades que ha configurado para el script de copia de
seguridad tpm511backup también se utilizará para los otros scripts de la
migración. Copie el archivo desde el servidor de suministro 5.1.1.2 a la
misma ubicación del sistema 7.1.1, de modo que el resto de los scripts de
migración utilicen los valores de los parámetros que ha especificado.
Algunos parámetros del archivo de propiedades se utilizan para el servidor
de suministro 5.1.1.2 y el servidor de suministro 7.1.1. Después de copiar el
archivo de propiedades en el servidor de suministro 7.1.1, asegúrese de
Capítulo 4. Migración de Tivoli Provisioning Manager
183
que los valores de los parámetros continúan siendo válidos para su
entorno 7.1.1, en especial, compruebe los valores de los parámetros wasUser
y dbIsRemote.
Restaure los datos de suministro 5.1.1.2
Ejecute el script tpm711restore para llenar el sistema 7.1.1 con los datos del
servidor de suministro 5.1.1.2.
Servidor de bases de datos remoto. Si tiene un servidor de bases de
datos remoto, sólo se restaurará la información de configuración del
servidor de suministro 5.1.1.2. Ejecutará un script diferente en el
servidor de bases de datos remoto nuevo para restaurar la información
de base de datos.
Base de datos local. Si tiene una base de datos local, la información de
configuración y la información de base de datos se restaurarán.
Copie el archivo RemoteDBTools.zip en el servidor de bases de datos
Este paso es únicamente para los servidores de bases de datos remotos.
Copie el archivo remoteDbTools.zip desde el DVD del producto y
extráigalo en el servidor de bases de datos. El archivo comprimido
contiene los scripts que necesita para restaurar la información de base de
datos.
Copie los datos en el servidor de bases de datos 7.1.1
Este paso es únicamente para los servidores de bases de datos remotos. Los
archivos de copia de seguridad que se crean se han de mover al servidor
de bases de datos para poder utilizarlos en el entorno de suministro 7.1.1.
Copie los archivos en el nuevo servidor de bases de datos.
Restaure la base de datos
Este paso es únicamente para los servidores de bases de datos remotos.
Ejecute el script de restauración, db2RestoreRemote o oracleRestoreRemote
para restaurar el servidor de bases de datos remoto.
Inicio del middleware
Después de instalar la versión 7.1.1, inicie el middleware antes de iniciar los pasos
de migración.
Antes de empezar
v Instale la versión 7.1.1. No inicie Tivoli Provisioning Manager después de
instalarlo.
1. Compruebe el estado del middleware: “Comprobación del estado del
middleware”.
2. Si no se inicia el middleware, inicie el middleware en el orden que se indica:
v
Windows
v
UNIX
“Inicio de middleware en Windows” en la página 186
“Inicio del middleware en UNIX y Linux” en la página 188
Qué hacer a continuación
“Acceso a los archivos de migración” en la página 190
Comprobación del estado del middleware
Siga estos procedimientos para comprobar que se ha iniciado el middleware antes
de continuar con la migración a la versión 7.1.1.
v Para comprobar el estado de DB2:
Windows
184
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
1. Inicie la sesión como Administrador.
2. Abra el panel de control de Servicios.
3. Busque la instancia de DB2 y compruebe el estado del servicio. Si aparecen
listadas varias instancias de DB2, busque la correspondiente al propietario de
la base de datos de Tivoli Provisioning Manager.
UNIX
Linux
1. Cambie al propietario de la instancia de DB2.
2. Inicie DB2:
db2start
Si DB2 ya se está ejecutando, se muestra el siguiente mensaje: SQL1026N El
gestor de bases de datos ya está activo
v Para comprobar el estado de la base de datos Oracle:
1. Conmute al usuario oracle.
2. Vaya al directorio $ORACLE_HOME/bin.
3. Compruebe el estado de la base de datos Oracle. Inicie una sesión en
SQL*Plus. El estado de la base de datos se muestra cuando inicia la sesión.
4. Compruebe el estado del escucha de la base de datos Oracle. Ejecute lsnrctl
status
v Para comprobar el estado de Tivoli Directory Server:
Windows
1. Inicie la sesión como Administrador.
2. Abra el panel de control de Servicios.
3. Busque la entrada correspondiente a IBM Tivoli Directory Server y
compruebe el estado del servicio.
UNIX
Linux
1. Inicie una sesión en el sistema de Tivoli Directory Server. Si ha instalado el
cliente de Tivoli Directory Server en el servidor de suministro, en su lugar
puede comprobar el estado de Tivoli Directory Server desde el servidor de
suministro.
2. Ejecute el mandato siguiente:
ibmdirctl -D cn=root –w contraseña -h nombre_host status
contraseña
La contraseña del DN base (cn=root)
nombrehost
El nombre de host del sistema de Tivoli Directory Server.
La parte -h nombrehost del mandato sólo es necesaria si realiza la
conexión desde el sistema Tivoli Provisioning Manager.
v Para comprobar el estado de Microsoft Active Directory:
Haga clic en Inicio → Programas → Herramientas administrativas → Administrar
el servidor. En la lista de roles de servidor, verifique que el servidor esté
configurado con el rol Controlador de dominio (Active Directory).
v Para comprobar estado de WebSphere Application Server desde el perfil de
Tivoli Provisioning Manager: Windows
1. Vaya al directorio WAS_HOME\profiles\ctgAppSrv01\bin.
2. Ejecute el mandato:
serverStatus MXServer -username
nombreusuario_wasadmin -password
contraseña_wasadmin
Capítulo 4. Migración de Tivoli Provisioning Manager
185
UNIX
1. Directorio WAS_HOME/profiles/ctgAppSrv01/bin.
2. Ejecute el mandato:
./serverStatus.sh MXServer -username
nombreusuario_wasadmin -password
contraseña_wasadmin
donde
nombreusuario_wasadmin
El nombre del usuario administrador de WebSphere Application Server
contraseña_wasadmin
La contraseña del nombre de usuario especificado.
|
|
|
Inicio de middleware en Windows
|
|
El middleware que necesita instalar dependerá de la tarea actual. En la tabla
siguiente se resumen las opciones posibles:
Los servidores y servicios de middleware deben estar activos antes de ejecutar la
instalación de los componentes principales de Tivoli Provisioning Manager.
|
Tabla 60. Pasos necesarios para iniciar el middleware
|
Situación
Acción
|
|
|
|
|
El middleware está
instalado, pero no ha
completado la instalación
de Tivoli Provisioning
Manager.
El middleware se inicia automáticamente cuando finaliza la instalación de middleware.
Si no ha rearrancado el servidor o detenido el middleware, puede continuar con la
instalación
|
|
Ha rearrancado el sistema
El daemon de administración y la instancia de base de datos de Tivoli Directory Server
deben iniciarse manualmente.
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
Cuando se haya iniciado todo el middleware, continúe con el paso siguiente:
v Si está en proceso de instalar Tivoli Provisioning Manager, ahora puede continuar
con la instalación.
v Si ha completado la instalación de Tivoli Provisioning Manager, consulte el apartado
Inicio y detención del servidor de suministro en Windows para iniciar Tivoli
Provisioning Manager :
Ha detenido el
middleware.
Cuando se haya iniciado todo el middleware, continúe con el paso siguiente:
v Inicie el middleware que se ha detenido en el orden que se indica en el
procedimiento que se describe después de esta tabla.
Consulte el apartado “Comprobación del estado del middleware” en la página 184
para ver los pasos necesarios para comprobar que se ha iniciado el middleware.
v Si ha completado la instalación de Tivoli Provisioning Manager, consulte Inicio y
detención del servidor de suministro en Windows para iniciar Tivoli Provisioning
Manager:
Inicie el middleware en el orden siguiente:
1. Inicie una sesión como un usuario con permisos administrativos.
|
|
|
|
|
2. Inicie DB2.
En los pasos siguientes se supone que la instancia de base de datos se
denomina ctginst1.
El servidor no tiene una IP virtual
a. Inicie una sesión como un usuario con permisos administrativos.
|
|
186
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
|
|
|
|
b. Haga clic en Inicio y seleccione Ejecutar.
c. Escriba services.msc y haga clic en Aceptar.
d. Seleccione DB2 - DB2COPY1 - CTGINST1-0, y haga clic en Iniciar el
servicio.
|
|
De manera alternativa, puede utilizar el mandato db2start en una línea
de mandatos para iniciar CTGINST1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
El servidor tiene una IP virtual
a. Inicie una sesión como un usuario con permisos administrativos.
b. Utilice el mandato siguiente para iniciar la base de datos:
db2gcf -u -p 0 -i ctginst1
3. Si utiliza Tivoli Directory Server como servidor de directorios, inicie el servidor
de directorios:
En los pasos siguientes se supone que la instancia de base de datos de Tivoli
Directory Server se denomina idsccmdb.
a. Inicie la instancia de base de datos:
El servidor no tiene una IP virtual
1) Haga clic en Inicio y seleccione Ejecutar.
2) Escriba services.msc y haga clic en Aceptar.
3) Seleccione IBM Tivoli Directory Server Instance V6.1 - idsccmdb,
y haga clic en Iniciar el servicio.
Alternativamente, puede utilizar el mandato siguiente desde la línea
de mandaos para iniciar la instancia de Tivoli Directory Server:
idsslapd -I idsccmdb
|
|
|
El servidor tiene una IP virtual
1) Utilice el mandato siguiente para iniciar la base de datos:
|
|
|
Importante: La instancia del servidor de directorios debe permanecer como
un tipo de arranque manual para la sincronización correcta con la base de
datos en el contexto de Tivoli Provisioning Manager.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Si desea configurar Tivoli Directory Server para que se inicie
automáticamente con el sistema operativo, consulte las instrucciones del
apartado Inicio de la instancia del servidor de directorios durante el
arranque del sistema operativo en el centro de información de Tivoli
Directory Server.
db2gcf -u -p 0 -i idsccmdb
b. Inicie el daemon de administración del servidor de directorios:
1) Haga clic en Inicio y seleccione Ejecutar.
2) Escriba services.msc y haga clic en Aceptar.
3) Seleccione IBM Tivoli Directory Admin Daemon V6.1 - idsccmdb, y haga
clic en Iniciar el servicio.
De manera alternativa, puede utilizar el siguiente mandato en una línea de
mandatos para iniciar el daemon de administración de ITDS:
idsdiradm -I idsccmdb
4. Inicie el perfil webserver1 de WebSphere Application Server e IBM HTTP
Server
a. Haga clic en Inicio y seleccione Ejecutar
b. Escriba services.msc y haga clic en Aceptar.
Capítulo 4. Migración de Tivoli Provisioning Manager
187
c. Seleccione IBM HTTP Server 6.1, y haga clic en Iniciar el servicio.
De manera alternativa, puede escribir apache en la línea de mandatos para
iniciar el servidor HTTP.
5. Inicie otros perfiles de WebSphere Application Server.
|
|
|
|
|
|
Inicie el gestor de despliegue
WAS_HOME\profiles\ctgDmgr01\bin\startManager.bat
|
|
Inicie el nodo
WAS_HOME\profiles\ctgAppSrv01\bin\startNode.bat
|
|
Inicie el servidor de aplicaciones MXServer
WAS_HOME\profiles\ctgAppSrv01\bin\startServer.bat MXServer
Inicio del middleware en UNIX y Linux
|
Los servidores y servicios de middleware deben estar activos antes de ejecutar la
instalación de los componentes principales de Tivoli Provisioning Manager.
El middleware que necesita instalar dependerá de la tarea actual. En la tabla
siguiente se resumen las opciones posibles:
Tabla 61. Pasos necesarios para iniciar el middleware
Situación
Acción
El middleware está
instalado, pero no ha
completado la instalación
de Tivoli Provisioning
Manager.
El middleware se inicia automáticamente cuando finaliza la instalación de middleware.
Si no ha reiniciado el servidor o ha detenido el middleware, puede continuar con
“Instalación de los componentes principales de Tivoli Provisioning Manager” en la
página 144.
Ha rearrancado el sistema
Después de un rearranque, debe reiniciar todo el middleware:
1. Inicie el servidor de bases de datos
2. Inicie el servidor de directorios.
3. Inicie el servidor HTTP
4. Inicie los perfiles de WebSphere Application Server:
v Realice un Reinicio manual si no ha ejecutado todavía la instalación de Tivoli
Provisioning Manager.
v Después de que “Instalación de los componentes principales de Tivoli
Provisioning Manager” en la página 144, Tivoli Provisioning Manager inicia
automáticamente los perfiles cuando se inicia Tivoli Provisioning Manager.
Ha detenido el
middleware.
Cuando se haya iniciado todo el middleware, continúe con el paso siguiente:
v Inicie el middleware que se ha detenido en el orden que se indica en el
procedimiento que se describe después de esta tabla.
Consulte el apartado “Comprobación del estado del middleware” en la página 184
para ver los pasos necesarios para comprobar que se ha iniciado el middleware.
v Si ha completado la instalación de Tivoli Provisioning Manager, consulte Inicio del
middleware en UNIX y Linux para iniciar Tivoli Provisioning Manager:
Inicie el middleware en el orden siguiente:
1. Inicie sesión en el sistema con el middleware.
v Durante el proceso de instalación, debe iniciar una sesión como root para
iniciar todo el middleware.
v Después de la instalación, sólo Tivoli Directory Server requiere que inicie la
sesión como root. El administrador de la aplicación de middleware puede
iniciar las demás aplicaciones.
2. Inicie la base de datos que está utilizando con Tivoli Provisioning Manager.
188
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
DB2
Ejecute los mandatos siguientes. En este ejemplo, ctginst1 es el nombre
de la instancia de base de datos de Tivoli Provisioning Manager. En
este ejemplo, la instancia de base de datos es ctginst1.
su - ctginst1
db2start
Nota: Si está utilizando una dirección IP virtual para el servidor de
DB2, utilice el mandato db2gcf. En este ejemplo, ctginst1 es el nombre
de la instancia de base de datos: db2gcf -u -p 0 -i ctginst1
Oracle
a. Conmute al usuario de la base de datos Oracle. En este ejemplo, el
usuario se denomina oracle.
su - oracle
b. Inicie el escucha de Oracle Database con el mandato:
$ORACLE_HOME/bin/lsnrctl start
c. Inicie Oracle Database con el mandato:
dbstart
3. Si utiliza Tivoli Directory Server como servidor de directorios, inicie el servidor
de directorios:
En los pasos siguientes se supone que la instancia de base de datos de Tivoli
Directory Server se denomina idsccmdb.
a. Inicie la sesión como root.
b. Vaya al directorio TDS_HOME/sbin.
c. Inicie el daemon de administración de Tivoli Directory Server:
idsdiradm -I idsccmdb
d. Inicie el daemon Tivoli Directory Server:
El servidor no tiene una IP virtual
ibmslapd -I idsccmdb
El servidor tiene una IP virtual
db2gcf -u -p 0 -i idsccmdb
Si desea configurar Tivoli Directory Server para que se inicie automáticamente
con el sistema operativo, consulte las instrucciones Inicio de la instancia del
servidor de directorios durante el arranque del sistema operativo en el centro
de información de Tivoli Directory Server.
4. Inicie el perfil webserver1 de WebSphere Application Server e IBM HTTP
Server
Linux HTTP_HOME/bin/apachectl start
AIX
HTTP_HOME/bin/apachectl start
5. Inicie otros perfiles de WebSphere Application Server.
Inicie el gestor de despliegue
WAS_HOME/profiles/ctgDmgr01/bin/startManager.sh
Inicie el nodo
WAS_HOME/profiles/ctgAppSrv01/bin/startNode.sh
Inicie MXServer
WAS_HOME/profiles/ctgAppSrv01/bin/startServer.sh MXServer
Capítulo 4. Migración de Tivoli Provisioning Manager
189
Para validar los perfiles que se han iniciado, inicie la sesión en la consola
administrativa de WebSphere Application Server para ver el estado o ejecutar el
mandato siguiente y se le devolverá el estado de los perfiles:
WAS_HOME/bin/serverStatus.sh WEBSERVER_NAME
-profileName APPSRV_PROFILE -username WAS_USER -password WAS_PWD
Acceso a los archivos de migración
Asegúrese de que tiene acceso a todos los archivos que necesita antes de iniciar la
restauración de los datos de la copia de seguridad del entorno 5.1.1.2.
Guarde los archivos de migración en el sistema 7.1.1. Necesitará los archivos
siguientes:
v El archivo de propiedades para los scripts de migración. Ya ha especificado los
valores de los parámetros para los scripts de migración que se ejecutarán, por lo
tanto, copie el archivo completado en el directorio TIO_HOME\migration\
scripts\ del sistema 7.1.1.
v La copia de seguridad de configuración del servidor de suministro 5.1.1.2
v La copia de seguridad de base de datos del servidor de bases de datos 5.1.1.2. Si
utiliza un servidor de bases de datos local, este archivo de copia de seguridad
será el mismo archivo que el archivo de copia de seguridad de configuración.
Realice los pasos siguientes para mover los archivos necesarios al sistema 7.1.1.
1. Inicie la sesión en el servidor de suministro 7.1.1 como usuario de base de
datos de administración. Asegúrese de que el usuario tiene permiso completo
para la carpeta donde está copiando los datos de copia de seguridad de 5.1.1.2.
Por ejemplo, los usuarios de UNIX puede utilizar el mandato ls -la para
mostrar el permiso de usuario para las carpetas.
2. En el servidor de suministro 5.1.1.2, copie el archivo de propiedades desde la
ubicación siguiente y añada la ubicación idéntica al servidor 7.1.1:
v
Windows
TIO_HOME\migration\scripts\tpmmigrate_win.properties
v
UNIX
TIO_HOME/migration/scripts/tpmmigrate_unix.properties
De este modo, se sobregrabará el servidor de archivos de propiedades vacío
existente en el sistema 7.1.1.
3. En el sistema 5.1.1.2, busque los archivos de copia de seguridad desde la
ubicación que ha especificado en el parámetro outputDir y cópielos en el
sistema 7.1.1. Cópielos en la ubicación que ha especificado en el parámetro
backupDir.
Si tiene un servidor de bases de datos local, este archivo de copia de seguridad
incluirá la copia de seguridad de configuración y la copia de seguridad de base
de datos el servidor de suministro 5.1.1.2. Ahora tendrá todos los archivos
necesarios en el sistema 7.1.1.
Si tiene un servidor de bases de datos remoto, este archivo de copia de
seguridad sólo incluirá la copia de seguridad de configuración de suministro,
por lo tanto, continúe en el paso siguiente.
4. En un servidor de bases de datos remoto, busque el archivo de copia de
seguridad del servidor de bases de datos 5.1.1.2 y cópielo en el servidor de
bases de datos que utilizará en 7.1.1.
190
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Qué hacer a continuación
Los usuarios DB2 deben asegurarse de que las vías de acceso que
estaban en el entorno 5.1.1.2 se han creado para la versión 7.1.1. Consulte el tema
denominado “Creación de las vías de acceso de base de datos DB2”.
Oracle
2000
Restaure la información de base de datos 5.1.1.2 en el servidor de bases
de datos 7.1.1:
v Si tiene un servidor de bases de datos remoto, continúe con la tarea de
migración denominada “Restauración del servidor de bases de datos remoto” en
la página 192.
v Si tiene un servidor de bases de datos local, continúe con la tarea de migración
denominada “Restauración y migración de los datos a 7.1.1” en la página 195.
Creación de las vías de acceso de base de datos DB2
Antes de restaurar la copia de base datos 5.1.1.2, asegúrese de que las vías de
acceso se han creado en el servidor de bases de datos 7.1.1.
Esta tarea no es necesaria para las bases de datos Oracle. Es necesaria para las
bases de datos DB2 locales y remotas.
Cuando restaure la copia de seguridad de base de datos 5.1.1.2, deben existir las
mismas vías de acceso en el servidor de bases de datos 7.1.1. Compruebe las vías
de acceso de los contenedores en la copia de seguridad de base de datos y cree
cualquier vía de acceso necesaria en el servidor de bases de datos 7.1.1.
1. En el servidor de bases de datos 5.1.1.2, abra una ventana de mandatos y
cambie el directorio a la ubicación del archivo de copia de seguridad de base
de datos.
2. Ejecute el mandato siguiente:
db2ckbkp -T <nombre_copia_seguridad_base_datos>
donde <nombre_copia_seguridad_base_datos> es el nombre del archivo de copia de
seguridad.
3. En la salida del mandato, compruebe todos los espacios de tablas. Para cada
espacio de tablas, busque el nombre bajo Container CB. Si el nombre Container
CB coincide con el nombre del espacio de tablas, se creará el espacio de tablas
en la ubicación predeterminada. No será necesario volver a crear las vías de
acceso en el servidor de bases de datos 7.1.1. Si hay una vía de acceso
específica asociada al contenedor, cree la vía de acceso correspondiente en el
servidor de bases de datos 7.1.1.
Ejemplo
Si la base de datos se denomina TC y el Container CB especifica
Name:/db2data/TC/sms_IBM8KSPACE, debe crear la vía de acceso /db2data en el
servidor de bases de datos 7.1.1. También debe asignar el espacio adecuado, de
modo que coincida con el tamaño existente en el servidor de bases de datos 5.1.1.2.
Qué hacer a continuación
Restaure la información de base de datos 5.1.1.2 en el servidor de bases de datos
7.1.1:
Capítulo 4. Migración de Tivoli Provisioning Manager
191
v Si tiene un servidor de bases de datos remoto, consulte “Restauración del
servidor de bases de datos remoto”.
v Si tiene un servidor de bases de datos local, consulte “Restauración y migración
de los datos a 7.1.1” en la página 195.
Restauración del servidor de bases de datos remoto
Si está utilizando un servidor de bases de datos remoto para 7.1.1, restaure la
imagen de base de datos 5.1.1.2 en el servidor de bases de datos.
Antes de empezar
Se deben completar los requisitos previos siguientes antes de restaurar la base de
datos remota:
1. Copie la copia de seguridad de base de datos del servidor de bases de datos
5.1.1.2 a este servidor de bases de datos. Cambie los permisos, si es necesario,
para asegurarse de que el propietario de la instancia de base de datos tiene
permiso de lectura para la copia de seguridad.
2. Busque y anote el nombre de base de datos y el nombre de esquema de la base
de datos remota 5.1.1.2 de la que ha realizado una copia de seguridad. Estos
nombres son necesarios para restaurar la copia de seguridad de base de datos
en el servidor de bases de datos 7.1.1.
Nota: Asegúrese de que el nombre de base de datos que restaura no existe en
la base de datos remota 7.1.1. Si existe el nombre de base de datos, utilice un
nombre de base de datos diferente o desconecte la base de datos existente.
3.
Oracle
2000
Asegúrese de que se han establecido las siguientes variables de
entorno:
a. $ORACLE_HOME. Para obtener más detalles, consulte Instalación del servidor
de Oracle Database en AIX, Linux (x86 64 bits) y Solaris.
b. NLS_LANG. El parámetro NLS_LANG tiene tres componentes: idioma, territorio y
juego de caracteres. El parámetro se debe especificar con el formato
siguiente: NLS_LANG=idioma_territorio.juegocaracteres. Para obtener el
valor del servidor de bases de datos 5.1.1.2, ejecute la consulta siguiente en
dicho servidor de bases de datos como sysdba:
SELECT * from NLS_DATABASE_PARAMETERS;
Utilice los valores de la consulta para establecer el parámetro. Por ejemplo,
es posible que el parámetro sea similar al siguiente:
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
Para establecer la variable de entorno NLS_LANG, ejecute este mandato:
export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
Para obtener más información acerca de NLS_LANG, consulte la
documentación de la base de datos Oracle: http://www.oracle.com/
technology/tech/globalization/htdocs/nls_lang%20faq.htm#_Toc110410543
4. Desconecte la base de datos existente. La base de datos no se puede restaurar si
existe una base de datos con el mismo nombre.
v
Oracle
2000
Ejecute el mandato siguiente:
"$ORACLE_HOME"/bin/dbca -silent -deleteDatabase -sourceDB <NOMBRE_BD> -sysDBAPassword <CONTRASEÑA_ADMINBD_OPT>
donde
192
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
NOMBRE_BD es el nombre de base de datos almacenado en el archivo
dcm.xml.
CONTRASEÑA_ADMINBD_OPT es la contraseña del administrador de
base de datos.
Ejecute los mandatos siguientes:
v
db2 force applications all
db2 drop db <NOMBRE_BD_DB2>
donde NOMBRE_BD_DB2 es la base de datos almacenada en el archivo
dcm.xml.
Restauración de datos en la base de datos remota
Si anteriormente ha ejecutado el script para restaurar la base de datos (por
ejemplo, si ha ejecutado el script y ha dado errores), debe desconectar la base de
datos antes de volver a ejecutar el script.
Para restaurar la información de base de datos 5.1.1.2 en el servidor de bases de
datos remoto 7.1.1, siga estos pasos:
1. Acceda al archivo migration/remoteDbTools.zip desde el DVD de instalación.
2. Inicie la sesión en la base de datos 7.1.1 remota.
v
Inicie la sesión con el nombre de usuario y contraseña del
propietario de la instancia de base de datos DB2.
Oracle
2000
Inicie la sesión como el usuario administrativo de Oracle.
v
3. Pegue y extraiga el archivo remoteDbTools.zip en el servidor de bases de datos.
Restaure la información de base de datos.
4.
v
Oracle
2000
Ejecute el mandato siguiente en una línea:
./oracleRestoreRemote.sh [nombre_host] [nombre bd antigua] [nombre bd nueva] [directorio copia de seguridad]
[nombre esquema antiguo] [nombre esquema nuevo][change db word size (yes|no)]
donde
nombre_host es el nombre de host completo del servidor de bases de
datos 7.1.1.
nombre bd antigua especifica el nombre de la base de datos 5.1.1.2 de la
que se ha realizado una copia de seguridad.
nombre bd nueva especifica el nombre de la base de datos 7.1.1. El nombre
de base de datos no puede existir en el servidor de bases de datos. Si
existe el nombre, utilice un nombre diferente o desconecte la base de
datos existente.
directorio copia de seguridad especifica la carpeta donde se almacenan
los archivos de copia de seguridad de base de datos. Por ejemplo,
/5112backup/database
nombre esquema antiguo especifica el nombre del esquema de base de
datos que se cambiará.
nombre esquema nuevo especifica el nuevo nombre del esquema de base
de datos.
change db word size especifica si necesita cambiar la base de datos de 32
bits a 64 bits para la versión 7.1.1. Escriba yes o no.
v
Capítulo 4. Migración de Tivoli Provisioning Manager
193
Windows
Abra una ventana de mandatos de base de datos y vaya al
directorio donde ha extraído el archivo remoteDbTools.zip. Ejecute el
mandato siguiente en una línea:
db2RestoreRemote.cmd [nombre bd antiguo] [nombre bd nuevo] [propietario instancia bd] [contraseña bd]
[directorio copia de seguridad] [nombre esquema antiguo] [nombre esquema nuevo]
donde
nombre bd antigua especifica el nombre de la base de datos 5.1.1.2 de la
que se ha realizado una copia de seguridad.
nombre bd nueva especifica el nombre de la base de datos 7.1.1. El nombre
de base de datos no puede existir en el servidor de bases de datos. Si
existe el nombre, utilice un nombre diferente o desconecte la base de
datos existente.
propietario instancia bd especifica el nombre de usuario del propietario
de la instancia de DB2.
contraseña bd especifica la contraseña del propietario de la instancia.
directorio copia de seguridad especifica la carpeta donde se almacenan
los archivos de copia de seguridad de base de datos. Por ejemplo,
/5112backup/database
nombre esquema antiguo especifica el nombre del esquema de base de
datos que se cambiará.
nombre esquema nuevo especifica el nuevo nombre del esquema de base
de datos.
UNIX
Ejecute el mandato siguiente en una línea:
db2RestoreRemote.sh [nombre bd antigua] [nombre bd nueva] [propietario instancia bd]
[directorio copia de seguridad] [nombre esquema antiguo] [nombre esquema nuevo]
donde
nombre bd antigua especifica el nombre de la base de datos 5.1.1.2 de la
que se ha realizado una copia de seguridad.
nombre bd nueva especifica el nombre de la base de datos 7.1.1. El nombre
de base de datos no puede existir en el servidor de bases de datos. Si
existe el nombre, utilice un nombre diferente o desconecte la base de
datos existente.
propietario instancia bd especifica el nombre de usuario del propietario
de la instancia de DB2.
directorio copia de seguridad especifica la carpeta donde se almacenan
los archivos de copia de seguridad de base de datos. Por ejemplo,
/5112backup/database
nombre esquema antiguo especifica el nombre del esquema de base de
datos que se cambiará.
nombre esquema nuevo especifica el nuevo nombre del esquema de base
de datos.
El mandato de restauración restaura la información de base de datos 5.1.1.2 en
el nuevo servidor de bases de datos.
5.
194
Oracle
2000
Ejecute los mandatos siguientes para asegurarse de que la
información de conexión de base de datos de $ORACLE_HOME\network\admin\
tnsnames.ora en el servidor Oracle y el servidor del cliente contienen la misma
información. Al ejecutar los mandatos también se verifica que el servidor y el
cliente de Oracle se pueden comunicar entre sí.
a. tnsping <nombre_bd>
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Se devolverá un mensaje OK (x sec).
b.
sqlplus maximo/<contraseña_maximo>@<nombre_bd>
Se devolverá el mensaje connected.
Qué hacer a continuación
Restaure la información de configuración del servidor de suministro de 5.1.1.2.
Consulte “Restauración y migración de los datos a 7.1.1”.
Restauración y migración de los datos a 7.1.1
Ejecute los scripts para restaurar y migrar los datos de la versión 5.1.1.2 al servidor
de suministro de la versión 7.1.1.
Antes de empezar
Asegúrese de que ha completado los pasos siguientes antes de ejecutar cualquier
script de migración:
1. Ha añadido todos los valores de parámetros al archivo de propiedades. Para
obtener más información, consulte “Adición de valores de parámetros al
archivo de propiedades” en la página 155.
2. Abra el archivo de propiedades y valide que los valores de los siguientes
parámetros continúan siendo correctos para su entorno 7.1.1:
a. dbIsRemote
b. dbHostName
c. orclOSUser
d. wasUser
Por ejemplo, si tenía un servidor de bases de datos local en la versión 5.1.1.2 y
está utilizando un servidor de bases de datos remoto para la versión 7.1.1,
cambie el valor de dbIsRemote de no a yes.
3. Ha copiado los archivos necesarios en el sistema 7.1.1. Para obtener más
detalles, consulte “Acceso a los archivos de migración” en la página 190.
4. Tivoli Provisioning Manager no se está ejecutando. Después de la instalación,
no inicie Tivoli Provisioning Manager hasta que se haya completado la
migración.
5.
Oracle
2000
La variable de entorno $ORACLE_HOME debe estar establecida.
Para obtener más detalles, consulte Instalación del servidor de Oracle Database
en AIX, Linux (x86 64 bits) y Solaris.
6. Ha iniciado el middleware:
v Servidor de bases de datos
v WebSphere Application Server
v Servidor LDAP
v Daemon de administración del servidor LDAP
Para obtener información detallada acerca de estos sistemas, consulte “Inicio de
middleware en Windows” en la página 186 o “Inicio del middleware en UNIX
y Linux” en la página 188.
Utilice estos scripts para realizar la migración de IBM Tivoli Provisioning Manager
5.1.1.2 a 7.1.1
1. Inicie la sesión en el sistema 7.1.1.
Windows
Inicie la sesión como tioadmin.
Capítulo 4. Migración de Tivoli Provisioning Manager
195
Inicie una sesión como root.
2. Abra una ventana de mandatos y ejecute el script siguiente desde
TIO_HOME/migration/scripts:
UNIX
v
Windows
: tpm711restore.cmd
UNIX
: ./tpm711restore.sh
v
Se le solicitará la contraseña de usuario del administrador de base de datos.
3. Para validar que la restauración se ha completado correctamente, vaya a
TIO_LOGS/migration y abra tpm711restore_status.log. El archivo de registro
lista cada uno de los pasos de la restauración y muestra comentarios acerca del
estado de cada paso. Todos los pasos deben estar marcados como DONE. Por
ejemplo:
PRE_CHECK_ENV|DONE
VALIDATE_INPUT|DONE
El script tpm711restore restaura la información de configuración y de la base
de datos del servidor de suministro 5.1.1.2. Cuando ejecuta el script de
restauración, éste completa las tareas siguientes en el sistema 7.1.1:
a. Si el servidor de bases de datos no es remoto, se restaura la base de datos
5.1.1.2. Este paso también incluye el cambio de nombre del esquema de base
de datos.
b. Restaura y maneja las secuencias de GUID.
c. Copia la clave de base de datos desde el archivo crypto.xml de 5.1.1.2 al
archivo crypto.xml de 7.1.1.
Si encuentra algún problema durante la ejecución del script de restauración,
visualice los problemas potenciales y los archivos de registro para poder
resolver el problema y continuar:
v “Detalles de la recuperación de problemas generados en el script de
restauración” en la página 268
v “Códigos de retorno” en la página 255
“Error de creación de objeto” en la página 273
v
v
“Error al crear el usuario durante la restauración de Oracle” en la
página 275
v
Oracle
2000
“Objetos creados con los avisos de compilación durante la
restauración” en la página 274
Oracle
2000
v “Error de nombre no definido durante la restauración” en la página 276
4. Elimine las claves foráneas que ha creado entre las tablas personalizadas y las
tablas de Tivoli Provisioning Manager, en la versión 5.1.1.2. La migración fallará
si no se eliminan estas restricciones.
La migración da soporte a las claves foráneas que se han creado entre serverID
y discoveryID desde las tablas personalizadas a las tablas de suministro
discovery y server. Cualquier otra restricción creada con otras tablas de
suministro dentro de las tablas de personalización no está soportada y se debe
eliminar antes de continuar con la migración.
5. Asegúrese de que ha completado la tarea “Copia de los archivos para la
instalación de la infraestructura de distribución escalable” en la página 28.
Estos componentes se instalarán cuando se ejecute el script de migración en el
paso siguiente.
6. Ejecute el script de migración de datos desde /migration/scripts:
v
196
Windows
: tpm711migrate.cmd
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
UNIX
v
: ./tpm711migrate.sh
Cuando se ejecute el script de migración, se le solicitará las siguientes
contraseñas:
Tabla 62. Contraseñas necesarias para el script tpm711migrate
Contraseña
Descripción
Usuario administrador de base de datos
La contraseña del usuario administrador de base de
datos.
Usuario de base de datos
La contraseña del usuario de la instancia de base de
datos
Gestor de agentes
La contraseña del gestor de agentes que se ha utilizado
en la versión 5.1.1.2.
Registro del agente
La contraseña del registro del gestor de agentes que se ha
utilizado en la versión 5.1.1.2.
Gestor de recursos del gestor de agentes
La contraseña para el nombre de usuario del gestor de
agentes para el gestor de atentes.
Nota: El instalador de Tivoli Provisioning Manager
5.1.1.2 crea la contraseña para este usuario. La contraseña
predeterminada que crea el instalador es password. Utilice
esta contraseña a menos que haya modificado la
contraseña después de la instalación de 5.1.1.2.
Contraseña de WebSphere Administrative Server
La contraseña del administrador de WebSphere
Application Server.
Almacén de claves de Tivoli Provisioning Manager
La contraseña del almacén de claves que se ha utilizado
en la versión 5.1.1.2.
Usuario CDSSCHEMA
La contraseña del usuario Oracle, CDSSCHEMA.
7. Para validar que se ha ejecutado correctamente la migración de los datos, vaya
a TIO_LOGS/migration y abra el archivo tpm711migrate_status.log. El archivo
de registro lista cada uno de los pasos de la migración y muestra comentarios
acerca del estado del paso. Todos los pasos deben estar marcados como DONE.
El script tpm711migrate gestiona los datos restaurados de la versión 5.1.1.2, de
modo que el tiempo de ejecución de la versión 7.1.1 pueda utilizar el
contenido. El script actualiza el contenido de la base de datos 7.1.1 y aplica los
cambios a los componentes dependientes, por ejemplo, el gestor de agentes.
Cuando ejecuta el script de migración, éste completa las tareas siguientes:
a. Migra los datos de suministro y el esquema de base de datos de 5.1.1.2 a
7.1.1. La migración incluye datos de cumplimiento, parches, Tivoli
Provisioning Manager for OS Deployment, tareas favoritas, datos de
almacenamiento y de virtualización. Asimismo, se importan las firmas de
software y se elimina el paquete de automatización Rembo.
b. Realiza una copia de seguridad de la base de datos después de migrar los
datos.
c. Instala y migra Common Agent Services. Se crea el perfil de Common
Agent Services y se inicia el gestor de agentes.
d. Registra el servidor de suministro con Common Agent Services. Se cambia
la contraseña de registro y la contraseña del gestor de recursos.
e. Configura SSL para el servidor de suministro, Dynamic Content Delivery, y
Device Manager Service.
f. Crea el almacén de confianza y el almacén de claves de la interfaz de línea
de mandatos.
g. Instala y actualiza Dynamic Content Delivery.
h. Instala el servicio del gestor de dispositivos.
i. Configura WebSphere Application Server para que se inicie como el usuario
tioadmin.
Capítulo 4. Migración de Tivoli Provisioning Manager
197
Si encuentra algún problema durante la ejecución del script de migración,
visualice los problemas potenciales y los archivos de registro para poder
resolver el problema y continuar:
v “Detalles de la recuperación de problemas generados en el script de
migración” en la página 269
v “Códigos de retorno” en la página 255
v “Falta el paquete Solaris necesario” en la página 279
v “La instalación de Common Agent Services falla” en la página 277
Resultados
Cuando hayan finalizado estos scripts, los datos de la versión 5.1.1.2 se habrán
restaurado y migrado al servidor de suministro de la versión 7.1.1.
Qué hacer a continuación
“Copia de seguridad de la configuración de base de datos y WebSphere
Application Server”
Copia de seguridad de la configuración de base de datos y
WebSphere Application Server
Recomendado: Una vez migrados y restaurados los datos de 5.1.1.2 al servidor de
suministro 7.1.1, realice la copia de seguridad de la configuración de la base de
datos 7.1.1 y de WebSphere Application Server para poder retrotraerla si encuentra
problemas durante el resto del proceso de migración.
Realice una copia de seguridad manual de los datos del servidor de aplicaciones y
la base de datos
1. En el sistema donde está instalado WebSphere Application Server, inicie la
sesión como tioadmin.
2. Realice una copia de seguridad de los datos del servidor de aplicaciones con
los siguientes mandatos. Especifique cada mandato en una línea diferente:
Windows
"WAS_HOME/bin/backupConfig.bat" "C:\BACKUPS\dmgr_beforeMBSbackup.zip" -nostop -logfile
"C:\BACKUPS\backup_dmgr.log" -profileName ctgDmgr01
"WAS_HOME/bin/backupConfig.bat" "C:\BACKUPS\appSrv01_beforeMBSbackup.zip" -nostop -logfile
"C:\BACKUPS\backup_appSrv01.log" -profileName ctgAppSrv01
"WAS_HOME/bin/backupConfig.bat" "C:\BACKUPS\casprofile_beforeMBSbackup.zip" -nostop -logfile
"C:\BACKUPS\backup_casprofile.log" -profileName casprofile
AIX
Linux
Nota:
Verifique que existe el directorio /var/tmp/backups
antes de ejecutar los mandatos siguientes.
AIX
Linux
WAS_HOME/bin/backupConfig.sh /var/tmp/backups/dmgr_beforeMBSbackup.zip -nostop -quiet -logfile
/tmp/backup_dmgr.log -profileName ctgDmgr01
WAS_HOME/bin/backupConfig.sh /var/tmp/backups/appSrv01_beforeMBSbackup.zip -nostop -quiet -logfile
/tmp/backup_appSrv01.log -profileName ctgAppSrv01
WAS_HOME/bin/backupConfig.sh /var/tmp/backups/casprofile_beforeMBSbackup.zip -nostop -quiet -logfile
/tmp/backup_casprofile.log -profileName casprofile
3. Inicie una sesión en el sistema donde se ha instalado la base de datos como el
propietario de la instancia. El propietario de la instancia predeterminada es
ctginst1.
4. Realice una copia de seguridad de la base de datos. Las siguientes instrucciones
son para DB2. En Oracle, consulte la documentación de Oracle.
198
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Ejecute los mandatos siguientes:
Windows
set DB2INSTANCE=CTGINST1
db2cmd
db2stop force
db2start
db2 CONNECT TO NOMBRE_BD_DB2
db2 QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
db2 CONNECT RESET
db2 BACKUP DATABASE NOMBRE_BD_DB2 TO DIR_COPIA_SEGURIDAD_DB2
WITH 2 BUFFERS BUFFER 1024 PARALLELISM 1 COMPRESS WITHOUT PROMPTING
db2 CONNECT TO <NOMBRE_BD_DB2>
db2 UNQUIESCE DATABASE
db2 CONNECT RESET
AIX
Linux
db2stop force
db2start
db2 CONNECT TO NOMBRE_BD_DB2
db2 QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
db2 CONNECT RESET
db2 BACKUP DATABASE NOMBRE_BD_DB2 TO DIR_COPIA_SEGURIDAD_DB2
WITH 2 BUFFERS BUFFER 1024 PARALLELISM 1 COMPRESS WITHOUT PROMPTING
db2 CONNECT TO <NOMBRE_BD_DB2>
db2 UNQUIESCE DATABASE
db2 CONNECT RESET
Sustituya NOMBRE_BD_DB2 por el nombre de la base de datos y
DIR_COPIA_SEGURIDAD_DB2 por el directorio donde desea almacenar la
copia de seguridad.
Qué hacer a continuación
“Instalación de servicios básicos”
Instalación de los servicios básicos y los componentes web
Después de completar la migración de los datos de 5.1.1.2 a 7.1.1, hay algunas
tareas de migración que se deben completar en la estación de trabajo
administrativa, el sistema que despliega los servicios básicos y los componentes
web de Tivoli Provisioning Manager.
Instalación de servicios básicos
En este procedimiento se explica cómo utilizar el instalador de servicios básicos
para instalar los servicios básicos.
Antes de empezar
v Asegúrese de que las aplicaciones de middleware estén iniciadas. Si ha instalado
el middleware con el instalador de middleware, las aplicaciones de middleware
se inician automáticamente después de la instalación. Si ha reiniciado el sistema
o si ha instalado manualmente el middleware, consulte “Inicio de middleware
en Windows” en la página 186 o “Inicio del middleware en UNIX y Linux” en la
página 188.
v Para evitar errores de instalación, asegúrese de revisar atentamente todos los
requisitos que se describen en el apartado “Verificación de los requisitos de
nombres, contraseñas y cuentas de usuario” en la página 61.
Capítulo 4. Migración de Tivoli Provisioning Manager
199
v Algunos procesos, como los programas antivirus, puede afectar negativamente a
la instalación de Provisioning Manager en el sistema. Siempre debe cerrar
temporalmente los procesos no críticos antes de ejecutar el programa de
instalación de Provisioning Manager.
v Si tiene intención de utilizar la característica del programa de instalación que
automatiza la configuración del middleware, debe habilitar un servicio RXA
(Remote Execution and Access) para cada sistema en el que tenga intención de
instalar el middleware. Los sistemas de destino deben habilitar al menos uno de
los protocolos RXA soportados, como rsh, rexec, SSH y Windows SMB. Antes de
iniciar el programa de instalación, asegúrese de que se esté ejecutando uno de
estos protocolos y que aceptará inicios de sesión remotos utilizando un nombre
de usuario y una contraseña configurados en el sistema de destino. Si el sistema
remoto es un servidor Windows, debe configurar RXA para que funciones sobre
SMB. Es posible que las instalaciones predeterminadas de sistemas AIX no
incluyan un protocolo adecuado y deberán tener habilitados protocolos
compatibles con RXA.
v Si desea utilizar las funciones de configuración de base de datos completamente
automáticas del programa de instalación, asegúrese de que se cumplan las
siguientes condiciones:
Nota: Si ha instalado el middleware con los valores predeterminados, esto ya se
ha configurado correctamente.
– Para las instalaciones de DB2 en UNIX, debe crear el usuario de la instancia
en el servidor de DB2 antes de iniciar el programa de instalación. Por
ejemplo, si tiene intención de crear la base de datos de Maximo en una
instancia de DB2 (se recomienda ctginst1), debe crear un usuario (incluido el
directorio padre para el usuario) en el servidor de DB2 de UNIX antes de
iniciar la instalación.
– El ID de usuario especificado como el ID de usuario del administrador de la
instancia que especifique en el panel Administración de DB2 del programa de
instalación debe tener autorización de administración de DB2, que se
denomina autorización de SYSADMIN en la documentación del producto de
DB2. Para obtener más información sobre cómo crear este usuario, consulte la
documentación del producto de DB2.
– El ID de usuario especificado en el panel Autorización de acceso remoto del
programa de instalación debe tener autorización de administración de DB2. Se
utilizará para crear la instancia de DB2, la base de datos y el esquema. Debe
tener la autorización SYSADM, según lo definido por DB2. Este necesita que
el ID sea miembro del grupo definido por el parámetro de configuración
sysadm_group para la instancia de DB2 que tenga intención de utilizar. Por
ejemplo, en Windows, el usuario debe pertenecer al grupo DB2ADMNS. Para
obtener más información sobre cómo crear este usuario, consulte la
documentación del producto de DB2.
– Para sistemas UNIX, el usuario de barrera debe ser db2fenc1.
v Para sistemas UNIX, debe agregar root al grupo DB2GRP1 antes de iniciar el
programa de instalación.
v En todas las instalaciones de DB2, puede ocurrir que se dé un uso de memoria
del sistema cada vez mayor enlazado con DB2. Si experimenta este
comportamiento, establezca la siguiente propiedad de DB2 y, a continuación,
reinicie el servidor de DB2:
db2 update dbm cfg using KEEPFENCED NO
v Debido a los requisitos de instalación de DB2, es posible que haya tenido que
eliminar las variables de entorno TEMP y TMP en un sistema Windows para que
DB2 se instale correctamente (DB2 no se instalará si la cadena de caracteres de
200
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v
v
v
v
v
vía de acceso utilizada para las variables de entorno TMP y TEMP es demasiado
larga). Sin embargo, estas variables de entorno se deben definir antes de iniciar
el launchpad del producto o el programa de instalación del producto si va a
instalar el producto en el mismo sistema Windows que contiene DB2. Puede
solucionar este problema eliminando las variables de entorno temporales antes
de la instalación de DB2 y volviéndolas a definir luego, como preparación para
la instalación del producto.
Si instala Tivoli Provisioning Manager en un idioma distinto del inglés, deberá
aceptar los valores predeterminados para el tamaño de espacio de tabla de base
de datos y el tamaño de espacio de tabla de índice. Asimismo, en el panel de
resumen, estos valores aparecerán como nulos. Si necesita personalizar los
tamaños de espacio de tabla, deberá ejecutar el instalador de servicios básicos en
inglés y configurar manualmente la base de datos fuera del instalador de
servicios básicos, o bien modificar los tamaños de espacio de tabla después de la
instalación.
Para WebSphere Application Server Network Deployment, asegúrese de que la
célula y todos los nodos relacionados se estén ejecutando de forma activa.
El directorio padre del propietario de la instancia de base de datos debe tener 8
GB de espacio disponible independientemente de si se va a instalar una base de
datos en dicha ubicación.
No utilice localhost como valor de nombre de host en el programa de
instalación. Especifique un nombre de host completo del sistema para todos los
valores de nombre de host.
Si encuentra errores durante la instalación, consulte Resolución de problemas de
instalación.
Durante la instalación de los servicios básicos, el software de despliegue se instala
en la estación de trabajo administrativa. Este software despliega el software de
servicios básicos en el servidor de aplicaciones donde se ha instalado Tivoli
Provisioning Manager.
Las siguientes instrucciones están indicadas para una instalación de varios servidores
donde se utilizan los valores predeterminados y se supone que ha elegido que el
instalador de servicios básicos configure automáticamente el middleware en varias
máquinas para trabajar con Tivoli Provisioning Manager. Si no permite que el
instalador de servicios básicos configure automáticamente el middleware,
continuará realizando comprobaciones mediante programación para verificar que
los pasos manuales descritos se han ejecutado correctamente. Si se encuentran
errores, se muestra un mensaje de error. Debe solucionar los errores antes de
continuar con la instalación.
La información que especifica en el programa de instalación de los servicios
básicos se almacena en el archivo maximo.properties y en la base de datos de
Maximo. Estos valores se rellenarán en los campos de los paneles del programa de
instalación de los servicios básicos en los siguientes usos del programa. Por lo
tanto, si cancela el programa de instalación después de especificar valores en
varios paneles de instalación, el programa de instalación recuperará la mayoría de
los valores la próxima vez que inicie el programa de instalación de los servicios
básicos. Los valores que no se guarden de esta manera están en el directorio de
instalación de los servicios básicos y la opción de atajo elegida durante la
instalación. Puede restaurar los valores predeterminados del programa de
instalación de los servicios básicos si suprime Maximo_HOME/applications/
maximo/properties/maximo.properties. Si no puede ubicar el archivo
maximo.properties en el directorio Maximo_HOME, búsquelo en el directorio
temporal del sistema.
Capítulo 4. Migración de Tivoli Provisioning Manager
201
Para instalar el servicios básicos:
1. Compruebe si hay una instalación existente del instalador de soluciones. La
ubicación de instalación predeterminada es:
v
Windows
v
UNIX
C:\Archivos de programa\IBM\Common\acsi
Linux
/usr/ibm/common/acsi
Si el instalador de soluciones ya está instalado, inicie el servicio.
Windows
Consulte el panel de control de Servicios. Si el servicio ADE de IBM
no se está ejecutando, inícielo.
UNIX o Linux
a. Escriba ps -ef|grep acsisvc
b. Si el servicio se está ejecutando, se muestran el proceso y un PID
asociado. Si el servicio no se está ejecutando, ejecute el mandato:
/usr/ibm/common/acsi/bin/acsisrv.sh -start
2. Inicie el launchpad.
3. En el panel de navegación del launchpad, haga clic en Instalación
personalizada y luego haga clic en Verificar requisitos previos de instalación
de servicios básicos. Después de verificar y de confirmar los requisitos
previos, vuelva a la página de instalación personalizada.
4. Haga clic en Instalar servicios básicos y componentes necesarios.
5. Seleccione un idioma para la instalación y haga clic en Aceptar.
6. En el panel Introducción, haga clic en Siguiente.
7. En el panel Resumen de paquetes, revise las acciones de despliegue de
paquetes y haga clic en Siguiente.
8. Acepte el acuerdo de licencia y haga clic en Siguiente.
9. En el panel Elegir carpeta de instalación, especifique el directorio de
instalación de los servicios básicos y haga clic en Siguiente. La vía de acceso
que especifique no puede contener espacios. De forma predeterminada, este
valor es:
v
Windows
v
UNIX
C:\ibm\SMP
Linux
/opt/IBM/SMP
Si la carpeta está en un sistema UNIX o Linux, debe ir a la ubicación.
10. En el panel Elegir despliegue, seleccione la opción Personalizado. La opción
Simple no está soportada.
11. En el panel Importar información de configuración de middleware, especifique
que desea utilizar los valores de campos que ha especificado en los campos
del instalador de middleware como valores predeterminados para estos
mismos campos en el instalador de servicios básicos.
Importar información de configuración de middleware
Seleccione este recuadro de selección si desea permitir que el
instalador de servicios básicos reutilice los valores especificados en el
instalador de middleware.
Nota: Si selecciona esta característica cuando realice la instalación con
RXA, la ubicación del espacio de trabajo que especifique debe residir
localmente en el sistema remoto y no puede estar en una unidad de
red del sistema remoto.
202
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nombre de host
Especifique el nombre de dominio completo del sistema donde se ha
ejecutado el instalador de middleware.
ID de usuario
Especifique el ID de usuario que se ha utilizado para ejecutar el
instalador de middleware en el sistema especificado en el campo
Nombre de host.
Contraseña
Especifique la contraseña del usuario.
Ubicación de espacio de trabajo
Especifique la ubicación del archivo de topología que contiene los
valores especificados para el instalador de middleware. Este archivo se
encuentra en el espacio de trabajo que se ha definido durante la
instalación del middleware. Para obtener más información, consulte el
tema El espacio de trabajo del instalador de middleware de la Guía de
instalación.
12. En el panel Tipo de base de datos, seleccione el producto que se utilizará para
la base de datos de maximo y haga clic en Siguiente.
Importante: SQL Server no es una base de datos soportada. Oracle no está
soportada cuando se instala el servidor de suministro en Windows.
13. En el panel Información de base de datos, especifique información de
configuración sobre la base de datos y haga clic en Siguiente.
DB2
Nombre de host
Especifique el nombre de dominio completo del sistema que
aloja DB2. Por ejemplo, database.example.com.
Puerto Especifique el puerto que utiliza la instancia de DB2. El valor
predeterminado es 50005.
Nombre de la base de datos
Especifique el nombre de la base de datos que se utiliza con
Tivoli Provisioning Manager. El nombre predeterminado de la
base de datos es maxdb71. La base de datos se creará si aún
no existe.
Instancia
Especifique el nombre de la instancia de base de datos que se
utilizará con Tivoli Provisioning Manager. El nombre de la
instancia predeterminada es ctginst1. Esta instancia se creará si
no existe previamente, aunque el usuario y el directorio padre
asociado sí deben existir en el servidor de DB2.
ID de usuario de base de datos
Especifique el ID de usuario que se utiliza para Tivoli
Provisioning Manager para acceder a DB2. Este ID de usuario
no puede ser el mismo que se utiliza como ID de usuario de
administrador de la instancia. El valor predeterminado es
maximo.
Contraseña de la base de datos
Especifique la contraseña del ID de usuario que se utiliza para
acceder a DB2.
Oracle
Capítulo 4. Migración de Tivoli Provisioning Manager
203
Nombre de host
Especifique el nombre de dominio completo del sistema que
aloja Oracle. Por ejemplo, database.example.com.
Puerto Especifique el puerto que utiliza Oracle. El valor
predeterminado es 1521.
Instancia
Especifique el nombre de la instancia de base de datos de
Tivoli Provisioning Manager. El valor predeterminado es
ctginst1.
ID de usuario de base de datos
Especifique el ID de usuario que se utiliza para Tivoli
Provisioning Manager para acceder a Oracle. Este ID de
usuario se creará si aún no existe. El valor predeterminado es
maximo. El usuario no se puede llamar oracle.
Contraseña de la base de datos
Especifique la contraseña del ID de usuario que se utiliza para
acceder a Oracle.
14. En el panel Automatizar configuración de base de datos, seleccione
Automatizar configuración de base de datos y haga clic en Siguiente. Esto
permite al instalador de servicios básicos configurar automáticamente la base
de datos para que se utilice en Tivoli Provisioning Manager. Algunos ejemplos
de tareas automáticas son la creación de espacios de tabla, la creación de
tablas de base de datos y la creación de esquemas de base de datos.
Nota: Si no desea que el instalador de servicios básicos configure la base de
datos automáticamente, debe configurarla manualmente antes de la instalación
de los servicios básicos.
15. En el panel Autorización de acceso remoto, especifique información de
autorización para la característica de configuración automática de base de
datos y haga clic en Siguiente.
ID de usuario
Especifique un ID de usuario para que el instalador de servicios
básicos pueda acceder al sistema que aloja la base de datos que se
utilizará con Tivoli Provisioning Manager.
Windows
El usuario debe ser miembro del grupo DB2ADMNS. Para
una instalación de Windows DB2 remota, utilice administrator.
UNIX
Linux
El usuario debe ser root y miembro del un grupo
con la autoridad SYSADM para la instancia de base de datos.
Contraseña
Escriba la contraseña del ID de usuario.
Consulte Habilitación de la configuración remota para ver detalles sobre cómo
asegurar un acceso remoto correcto entre el programa de instalación de
Provisioning Manager y el servidor remoto.
16. En el panel Administración de base de datos, especifique información de
configuración sobre la base de datos y haga clic en Siguiente.
DB2
Directorio de instalación
Especifique el directorio en el que se ha instalado DB2. Los
valores predeterminados son:
204
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v
Windows
C:\Archivos de programa\IBM\SQLLIB
v
AIX
/opt/IBM/db2/V9.5
v
Linux
/opt/ibm/db2/V9.5
v
Linux
en IBM System z: /opt/IBM/db2/V9.5
ID de usuario de administrador de la instancia
Especifique el ID de usuario del administrador de la instancia
de DB2. Los valores predeterminados son:
v
Windows
v
UNIX
db2admin
Linux
ctginst1
Este ID de usuario no puede ser el mismo que el ID de
usuario de base de datos. Este usuario debe tener autoridad
de administración de DB2, lo que se conoce como autoridad
SYSADM en la documentación del producto DB2. Para
obtener más información sobre la creación de este usuario,
consulte la documentación del producto DB2.
Contraseña de administrador de la instancia
Especifique la contraseña del ID de usuario del administrador
de la instancia de DB2.
Windows
ID de usuario de servicio Windows
Especifique el ID de usuario que se utiliza para iniciar el
servicio de DB2 en Windows. Este ID de usuario debe tener
autoridad administrativa en el sistema. El valor
predeterminado es db2admin.
Windows
Contraseña de servicio Windows
Especifique la contraseña del ID de usuario que se utiliza para
iniciar el servicio de DB2 en Windows.
Oracle
Directorio de instalación
Especifique el directorio en el que se ha instalado Oracle. Por
ejemplo:
v
Windows
v
UNIX
C:\oracle\product\10.2.0\db_1
Linux
/opt/app/oracle/product/10.2.0/db_1
ID de usuario administrador
Especifique el ID de usuario del administrador de Oracle. El
valor predeterminado es sys.
Contraseña del administrador
Especifique la contraseña del ID de usuario del administrador
de Oracle.
ID de propietario de software de Oracle
Especifique el ID del usuario que se ha utilizado para instalar
Oracle. El valor predeterminado es oracle.
Contraseña de propietario de software de Oracle
Especifique la contraseña del usuario que se ha utilizado para
instalar Oracle.
17. En el panel Espacio de tabla de base de datos, especifique información sobre
el espacio de tabla de la base de datos y haga clic en Siguiente.
Capítulo 4. Migración de Tivoli Provisioning Manager
205
DB2
Nombre de espacio de tabla de datos
Especifique el nombre del espacio de tabla que se creará en
DB2 para Tivoli Provisioning Manager. Si el espacio de tabla
no existe todavía, se crea. El valor predeterminado es
MAXDATA.
Tamaño de espacio de tabla de datos
Especifique un tamaño, en megabytes, para el espacio de
tablas de datos. El valor debe ser 5000 MB o superior.
Nombre de espacio de tabla temporal
Especifique el nombre del espacio de tabla temporal que se
creará para DB2. Los espacios de tabla temporales mantienen
los datos mientras se ordenan o recopilan las acciones. Si el
espacio de tabla no existe todavía, se crea. El valor
predeterminado es MAXTEMP.
Tamaño de espacio de tablas temporal (Mb)
Especifique un tamaño para el espacio de tabla temporal. El
valor predeterminado es 1000 Mb.
Nombre de espacio de tabla de índice
Especifique un nombre para el espacio de tabla de índice. El
valor predeterminado es MAXDATA.
Tamaño de espacio de tabla de índice
Especifique un tamaño, en megabytes, para el espacio de
tablas de índice. El valor debe ser superior a 3000 Mb. El valor
predeterminado es 5000 Mb.
Oracle
Directorio básico de instancia
Especifique la vía de acceso donde se cargará la instancia de
base de datos. Por ejemplo:
v
Windows
v
AIX
C:\oracle\product\10.2.0\db_1\dbs
Linux
/opt/oracle/product/10.2.0/db_1/dbs
Nombre de espacio de tabla de datos
Especifique el nombre del espacio de tabla que se creará en
Oracle para Tivoli Provisioning Manager. El valor
predeterminado es MAXDATA.
Tamaño de espacio de tablas de datos (Mb)
Especifique un tamaño, en megabytes, para el espacio de
tablas de datos. El valor debe ser superior a 5000 Mb.
Nombre de espacio de tabla temporal
Especifique el nombre del espacio de tabla temporal que se
creará para Oracle. Los espacios de tabla temporales
mantienen los datos mientras se ordenan o recopilan las
acciones. El valor predeterminado es MAXTEMP.
Tamaño de espacio de tablas temporal (Mb)
Especifique un tamaño para el espacio de tabla temporal. El
valor predeterminado es 100 Mb.
206
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Nombre de espacio de tabla de índice
Especifique un nombre para el espacio de tabla de índice. El
valor predeterminado es MAXDATA.
Tamaño de espacio de tablas de índice (Mb)
Especifique un tamaño, en megabytes, para el espacio de
tablas de índice.
18. En el panel Tipo de servidor de aplicaciones, seleccione IBM WebSphere
Application Server.
Importante: Oracle WebLogic Server no recibe soporte de Tivoli Provisioning
Manager.
19. En el panel Conectividad de WebSphere, especifique información de host
sobre WebSphere Application Server y haga clic en Siguiente.
Nombre de host
Especifique el nombre de dominio completo del sistema que aloja
WebSphere Application Server. De manera alternativa, puede
proporcionar la dirección IP del sistema.
Puerto SOAP
Especifique el puerto SOAP del sistema WebSphere Application
Server. El valor predeterminado es 8879.
20. En el panel Automatizar configuración de WebSphere, seleccione Automatizar
configuración de WebSphere y haga clic en Siguiente. Esto permite que el
programa de instalación de Tivoli Provisioning Manager configure
automáticamente WebSphere Application Server para que lo pueda utilizar
Tivoli Provisioning Manager.
21. En el panel Autorización de acceso remoto de WebSphere, especifique
información de autorización para la configuración de WebSphere Application
Server y haga clic en Siguiente.
ID de usuario de sistema operativo
v
Windows
Especifique un ID de usuario válido para que el
instalador de servicios básicos pueda acceder al sistema que aloja
WebSphere Application Server. Este ID de usuario debe tener
derechos administrativos en la máquina a la que está accediendo.
v
UNIX
Debe especificar tioadmin como usuario para el acceso
remoto. Tivoli Provisioning Manager está configurado para iniciar
automáticamente los perfiles de WebSphere Application Server con
este nombre de usuario cuando inicia Tivoli Provisioning Manager.
Contraseña de sistema operativo
Especifique la contraseña del ID de usuario del sistema.
22. En el panel Configuración del gestor de despliegue de WebSphere, especifique
valores para los campos siguientes y haga clic en Siguiente.
Directorio de instalación de WebSphere
Especifique el directorio donde se ha instalado WebSphere Application
Server en el sistema host. Por ejemplo:
C:\Archivos de programa\IBM\WebSphere\AppServer
v
Windows
v
AIX
/usr/IBM/WebSphere/AppServer
v
Linux
/opt/IBM/WebSphere/AppServer
Capítulo 4. Migración de Tivoli Provisioning Manager
207
ID de usuario
Especifique el ID de usuario administrativo utilizado para acceder a
WebSphere Application Server. El valor predeterminado es wasadmin.
Contraseña
Escriba la contraseña del ID de usuario administrativo utilizado para
acceder a WebSphere Application Server.
Nombre de perfil
Escriba el nombre del perfil de WebSphere Application Server. El valor
predeterminado es ctgDmgr01.
23. En el panel Configuración de WebSphere Application Server, escriba la
siguiente información y haga clic en Siguiente.
Puerto del servidor web
Especifique el puerto del servidor web que utiliza WebSphere
Application Server. El valor predeterminado es 80.
Nombre del servidor web
Especifique el nombre del servidor web. El valor predeterminado es
webserver1.
Nombre de nodo
Especifique el nombre del nodo de WebSphere Application Server que
contiene el servidor de aplicaciones. El valor predeterminado es
ctgNode01.
Nombre de clúster
Especifique el nombre del clúster de WebSphere Application Server
que contiene el servidor de aplicaciones. El valor predeterminado es
MAXIMOCLUSTER.
Servidor de aplicaciones
Escriba el nombre del sistema WebSphere Application Server que
desea asociar a Tivoli Provisioning Manager. El servidor de
aplicaciones se creará si no existe. El valor predeterminado es
MXServer.
24. En el panel Seguridad, seleccione un método para autenticar y autorizar
usuarios y grupos y haga clic en Siguiente.
Utilizar la seguridad de aplicaciones de WebSphere para autenticación y
autorización.
Elija esta opción para configurar automáticamente la seguridad de
aplicaciones de WebSphere para gestionar usuarios y grupos con fines
de autenticación y autorización. Esta opción necesita que la seguridad
de aplicaciones esté habilitada en WebSphere.
Importante: Debe seleccionar la seguridad de aplicaciones de
WebSphere para autenticación y autorización para que los servicios
básicos se configuren para utilizar LDAP y Microsoft Active Directory.
Utilizar la seguridad de aplicaciones de WebSphere solo para autenticación
Elija esta opción para configurar automáticamente la seguridad de
aplicaciones WebSphere solo para autenticación y permitir que la
seguridad de Maximo gestione usuarios y grupos. Con esta opción,
cree todos los usuarios en el servidor de directorios, pero gestiona su
pertenencia a grupos en grupos de seguridad en la aplicación Grupos
de seguridad de los servicios básicos. Esta opción necesita que la
seguridad de aplicaciones esté habilitada en WebSphere.
208
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Si selecciona esta opción, el siguiente panel que encuentra le solicita
una entrada básica de usuario. Los usuarios maxadmin, maxreg y
mxintadm y los grupos MAXIMOUSERS y MAXADMIN deben
haberse creado antes de continuar pasado este panel.
Utilizar la seguridad de Maximo para autenticación y autorización
Si no desea utilizar la seguridad de aplicaciones de WebSphere,
seleccione esta opción para que la seguridad de Maximo gestione
usuarios y grupos para autenticación y autorización.
25. Si ha seleccionado Utilizar la seguridad de aplicaciones de WebSphere solo
para autenticación en el panel Seguridad, especifique los nombres
distinguidos de las entidades básicas de usuario y grupo que utiliza y elija la
forma en que se crean usuarios; luego haga clic en Siguiente.
Importante: Cuando especifique valores de LDAP para la instalación de
servicios básicos, las entradas de los archivos LDIF o los valores que
especifique directamente en una instancia de directorio utilizando las
herramientas del servidor de directorios siguen las reglas de sintaxis
específicas del producto en cuanto al uso de caracteres especiales en cadenas
de caracteres LDAP. En la mayoría de los casos, los caracteres especiales
deben ir precedidos de un carácter de escape para que el servidor de
directorios pueda leerlos.
Muchos productos de servidores de directorios consideran el carácter en
blanco como un carácter especial que forma parte de la cadena LDAP. Por lo
tanto, si especifica por error una cadena LDAP que contiene un espacio en
blanco, por ejemplo, al final de un valor de campo, y el carácter en blanco no
va precedido por un carácter de escape, aparecerán errores que serán difíciles
de resolver. Consulte la documentación del producto correspondiente a su
servidor de directorios para obtener más información sobre los caracteres
especiales en las cadenas LDAP.
Entrada básica de usuario
Especifique la entrada básica de usuario que se ha configurado para el
servidor de directorios. La entrada básica de usuario del esquema
LDAP predeterminado es ou=users,ou=SWG,o=IM,c=US
Asegúrese de que la entrada básica tenga el formato correcto y sea
precisa. El instalador de middleware no valida automáticamente la
entrada básica, pero el instalador de servicios básicos sí lo hace. Si ha
especificado una entrada básica incorrecta, debe especificarla
correctamente antes de continuar con la instalación de los servicios
básicos.
Entrada básica de grupo
Especifique la entrada básica de grupo que se ha configurado para el
servidor de directorios. La entrada básica de grupo del esquema
LDAP predeterminado es ou=groups,ou=SWG,o=IM,c=US
Asegúrese de que la entrada básica de grupo tenga el formato correcto
y sea precisa. El instalador de middleware no valida automáticamente
la entrada básica de grupo, pero el instalador de servicios básicos sí lo
hace. Si ha especificado una entrada básica de grupo incorrecta, debe
especificarla correctamente antes de continuar con la instalación de los
servicios básicos.
Crear los usuarios necesarios
Capítulo 4. Migración de Tivoli Provisioning Manager
209
Tivoli Directory Server
Deje seleccionada esta opción para permitir que el programa
de instalación cree los usuarios predeterminados en el Virtual
Member Manager (VMM) de WebSphere Application Server.
Esta operación requiere acceso de escritura en VMM.
Si no desea que el programa de instalación cree los usuarios,
debe crearlos manualmente antes de continuar con la
instalación. Consulte Sincronización de usuarios y grupos para
ver las tareas de sincronización que debe realizar tras la
instalación si decide personalizar el esquema.
Microsoft Active Directory
Deseleccione esta opción.
Si utiliza Microsoft Active Directory para proteger WebSphere
Application Server, ya ha creado el esquema utilizando los
pasos que se proporcionan en los apartados Protección de
WebSphere Application Server con Microsoft Active Directory
utilizando el programa de instalación de middleware y
Configuración manual de Microsoft Active Directory.
Antes de continuar con la instalación, compruebe los
siguientes requisitos en Microsoft Active Directory
a. Los siguientes usuarios existen en el servidor de
directorios:
Grupo
Usuarios
maxadmin
mxintadm
maxadmin
maximousers
mxintadm
maxadmin
maxreg
b. El nombre previo a Windows 2000 del grupo maxadmin
se cambia por otro nombre. Este cambio es necesario
porque el grupo maxadmin contiene un usuario que
también se denomina maxadmin.
Si no utiliza el esquema LDAP predeterminado, deberá crearlo
manualmente para poder avanzar de este panel. Se utilizarán los
valores especificados para los campos de entrada básica Usuario y
Grupo para configurar la tarea cron VMMSYNC. Consulte
Sincronización de usuarios y grupos para ver las tareas de
sincronización que debe realizar tras la instalación si decide
personalizar el esquema.
A continuación, se proporciona un ejemplo de los datos LDIF de
accesorios predeterminados que deberá modificar e importar al
repositorio LDAP si ha seleccionado personalizar el esquema y crear
sus propios usuarios manualmente.
dn: uid=maxadmin,ou=users,ou=SWG, o=ibm,c=us
userPassword: maxadmin
uid: maxadmin
objectClass: inetorgperson
objectClass: top
objectClass: person
objectClass: organizationalPerson
sn: maxadmin
210
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
cn: maxadmin
dn: uid=mxintadm,ou=users,ou=SWG, o=ibm,c=us
userPassword: mxintadm
uid: mxintadm
objectClass: inetorgperson
objectClass: top
objectClass: person
objectClass: organizationalPerson
sn: mxintadm
cn: mxintadm
dn: uid=maxreg,ou=users,ou=SWG, o=ibm,c=us
userPassword: maxreg
uid: maxreg
objectClass: inetorgperson
objectClass: top
objectClass: person
objectClass: organizationalPerson
sn: maxreg
cn: maxreg
dn: cn=maxadmin,ou=groups,ou=SWG, o=ibm,c=us
objectClass: groupofnames
objectClass: top
member: uid=dummy
member: uid=maxadmin,ou=users,ou=SWG,o=IBM,c=US
member: uid=mxintadm,ou=users,ou=SWG,o=IBM,c=US
cn: maxadmin
dn: cn=maximousers,ou=groups,ou=SWG, o=ibm,c=us
objectClass: groupofnames
objectClass: top
member: uid=dummy
member: uid=mxintadm,ou=users,ou=SWG,o=IBM,c=US
member: uid=maxreg,ou=users,ou=SWG,o=IBM,c=US
member: uid=maxadmin,ou=users,ou=SWG,o=IBM,c=US
cn: maximousers
26. En el panel Configuración JMS del adaptador de integración, especifique la
siguiente información y haga clic en Siguiente. Un servidor JMS requiere que
se configure un repositorio de datos de DB2 para mantener los mensajes. Si
utiliza otro tipo de base de datos, el programa de instalación no puede
configurar la permanencia de los mensajes.
Nombre de origen de datos JMS
Especifique el nombre de la base de datos que utilizará JMS. El valor
predeterminado es intjmsds.
Persistir los mensajes JMS
Seleccione esta opción si desea que el programa de instalación debe
mensajes permanentes en DB2. Para obtener más información,
consulte Creación manual de un origen de datos para el almacén
persistente.
No persistir los mensajes JMS
Seleccione esta opción si no desea que el programa de instalación
establezca la implementación JMS para persistir automáticamente los
mensajes. Si luego decide que no desea tener mensajes permanentes
de JMS, debe configurar la implementación de JMS manualmente.
Debe seleccionar esta opción si utiliza Oracle como base de datos.
Esta es la selección predeterminada. Se recomienda que utilice esta
opción.
Capítulo 4. Migración de Tivoli Provisioning Manager
211
27. En el panel Configuración de servidor de bases de datos DB2, escriba la
siguiente información y haga clic en Siguiente. El almacén de datos JMS solo
se puede crear como base de datos DB2.
Nombre de host
Especifique el nombre de dominio completo del servidor que aloja el
almacén de datos JMS.
Puerto Especifique el puerto que se utiliza para acceder al servidor de bases
de datos. El valor predeterminado es 50005.
Nombre de la base de datos
Especifique el nombre de la base de datos que sirve como almacén de
datos JMS. El valor predeterminado es maxsibdb.
ID de usuario
Especifique el ID de usuario que se utiliza para acceder al servidor de
bases de datos. Si el usuario no existe, se creará automáticamente. El
valor predeterminado es el ID de usuario de base de datos que se
especifica cuando selecciona el tipo de base de datos.
Contraseña
Especifique la contraseña del ID de usuario que se utiliza para acceder
al servidor de bases de datos.
28. En el panel Autorización de acceso remoto del servidor de bases de datos
DB2, especifique información de autorización para la característica de
configuración automática y haga clic en Siguiente.
ID de usuario
Especifique un ID de usuario que permitirá al instalador de servicios
básicos acceder al sistema que aloja la base de datos JMS. Este usuario
debe tener derechos administrativos en el sistema al que está
accediendo.
Windows
UNIX
Este usuario debe ser miembro del grupo DB2ADMNS.
Linux
Este usuario debe ser miembro del grupo
db2iadm1.
Contraseña
Escriba la contraseña del ID de usuario.
29. En el panel Configuración de la instancia de base de datos DB2, especifique la
siguiente información y haga clic en Siguiente.
Directorio de instalación
Especifique el directorio de instalación del servidor de DB2 que aloja
la base de datos JMS que contiene la instancia que se va a utilizar con
WebSphere Application Server. Por ejemplo:
v
Windows
v
Linux
C:\Archivos de programa\IBM\SQLLIB
/opt/IBM/db2/V9.5
Instancia
Especifique la instancia de base de datos JMS que se utilizará con
WebSphere Application Server. El valor predeterminado es ctginst1
ID de usuario de administrador de la instancia
Especifique el ID de usuario del administrador de la instancia de base
de datos JMS. Por ejemplo:
v
212
Windows
db2admin
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v
Linux
ctginst1
Contraseña de administrador de la instancia
Especifique la contraseña del ID de usuario del administrador de la
instancia de base de datos JMS.
30. En el panel Configuración de SMTP, especifique información sobre la
configuración de SMTP que utilizan los flujos de trabajo para comunicar con
los participantes en el flujo de trabajo.
Servidor SMTP
Especifique el nombre de host completo del servidor SMTP que
enviará mensajes a los participantes.
Correo electrónico del administrador
Escriba una dirección de correo electrónico válida. La dirección se
utilizará para enviar mensajes.
Puede diferir la configuración de SMTP si no especifica información en este
panel y haga clic para ir al siguiente panel. Sin embargo, debe configurar estos
parámetros mediante la interfaz del producto como tarea posterior a la
instalación, tal como se describe en Configuración de SMTP.
31. En el panel Ejecutar el paso de configuración, seleccione una opción para
realizar la configuración y desplegar los archivos de aplicación y luego haga
clic en Siguiente.
Realizar ahora la configuración de instalación
Seleccione esta opción para realizar el paso de configuración durante
la instalación.
Copiar archivos ahora y realizar la configuración de la instalación después
manualmente
Seleccione esta opción para que el programa de instalación solo copie
los archivos en el sistema.
El programa de instalación de Tivoli Provisioning Manager se utiliza
para realizar tres tareas: recopilar información sobre la configuración y
el despliegue de Tivoli Provisioning Manager, copiar archivos en el
sistema local, y ejecutar tareas de configuración utilizando los valores
que ha especificado. Si selecciona esta opción, el programa de
instalación obtendrá la información de configuración y copiará los
archivos de Tivoli Provisioning Manager en el sistema local ahora;
luego le permitirá ejecutar el paso de configuración más adelante.
Desplegar archivos de aplicación automáticamente
Seleccione esta opción para que el programa de instalación realice
automáticamente el despliegue de archivos EAR durante la
instalación.
Desplegar archivos de aplicación manualmente más adelante
Seleccione esta opción para diferir el despliegue de los archivos de
aplicación. El hecho de diferir el despliegue de archivos de aplicación
puede reducir el tiempo que se tarda en el despliegue general si tiene
intención de instalar más de un producto de gestión de servicios. Los
archivos se pueden desplegar cuando todos los productos han
agregado sus propias funciones a los archivos de aplicación. Es
posible que también desee utilizar esta opción si la organización tiene
restricciones de despliegue de aplicaciones que requieren que
despliegue archivos de aplicación manualmente o mediante otro
proceso aprobado.
Capítulo 4. Migración de Tivoli Provisioning Manager
213
Para ver instrucciones sobre el despliegue de aplicación manual para
WebSphere Application Server, consulte Despliegue de archivos EAR
de Provisioning Manager.
32. En el panel Elegir carpeta de atajos, seleccione el tipo de atajo correspondiente
a Tivoli Provisioning Manager y haga clic en Siguiente. Si selecciona En menú
Inicio para que se utilice con Internet Explorer, asegúrese de haber agregado
el URL de Tivoli Provisioning Manager a la zona de contenido web de sitios
fiables y de haber inhabilitado la opción que requiere verificación del servidor
para todos los sitios de la zona.
Nota: No utilice las opciones En barra de inicio rápido porque no creará
ningún atajo en la barra Inicio rápido.
33. En el panel Resumen de entradas, revise la información y haga clic en
Siguiente.
34. En el panel Resumen previo a la instalación, revise la información y haga clic
en Instalar.
35. En el panel Información del paquete de idioma, seleccione Sí y haga clic en
Siguiente para utilizar el programa de instalación del paquete de idioma para
seleccionar un nuevo idioma base o agregar soporte de idioma adicional a
Tivoli Provisioning Manager. De manera alternativa, puede seleccionar No
para diferir la adición del soporte de idioma. Puede agregar soporte de
idioma en cualquier momento después de un despliegue satisfactorio
utilizando el programa de instalación del paquete de idioma.
36. En el panel Instalación completa, haga clic en Siguiente.
Resultados
La instalación de servicios básicos ha finalizado.
Puede encontrar los registros en las siguientes ubicaciones:
v Maximo_HOME/logs
v Maximo_HOME/solutions/logs
v Maximo_HOME/maximo/tools/maximo/log
v
Windows
v
UNIX
C:\archivos de programa\ibm\common\acsi\logs
Linux
/usr/ibm/common/acsi/logs
Asimismo, encontrará los registros en los directorios de registro del servidor de
aplicaciones WebSphere Application Server, el servidor de despliegue y el agente
de nodo.
Si encuentra algún problema durante la instalación, consulte el tema “La
instalación de los servicios básicos falla” en la página 277 para ver los pasos de
recuperación.
Qué hacer a continuación
“Instalación de los componentes web” en la página 216
Detención del middleware
|
Utilice estos procedimientos para detener el middleware. Si necesita reiniciar una
aplicación de middleware, debe detener la aplicación antes de reiniciarla.
1. Detenga Tivoli Provisioning Manager.
|
|
|
214
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
|
|
2. Detenga la instancia de base de datos de DB2. Los mandatos de estos pasos
utilizan el nombre de instancia predeterminado ctginst1.
Inicie una sesión como propietario de la instancia.
|
a.
UNIX
|
b.
Windows
|
|
c.
En un indicador de mandatos, abra una ventana de DB2 con el
mandato db2cmd.
|
|
|
|
|
|
|
|
|
|
d.
Windows
Si tiene Tivoli Directory Server en el mismo sistema que la base
de datos de Tivoli Provisioning Manager, establezca el nombre de instancia.
|
|
|
Windows
set db2instance=ctginst1
e. Ejecute el mandato siguiente para comprobar otras aplicaciones que haya en
ejecución:
db2 list applications
f. Si el mandato lista otras aplicaciones, ejecute el mandato siguiente para
desconectarlas:
db2 force applications all
g. Detenga DB2:
El servidor no tiene una IP virtual
Ejecute el siguiente mandato:
db2stop
Nota: El mandato db2stop sólo se puede ejecutar en el servidor. No
se permiten las conexiones con la base de datos al ejecutar este
mandato, aunque, si hay conexiones de instancia se desactivarán
antes de que se detenga la instancia.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inicie la sesión como usuario con acceso de administrador.
El servidor tiene una IP virtual
Si utiliza una dirección IP virtual para el servidor de DB2, utilice el
siguiente mandato para detener la base de datos. En este ejemplo, la
instancia de base de datos es ctginst1.
db2gcf -d -p 0 -i ctginst1
3. Detenga el perfil MXServer de WebSphere Application Server.
Windows
a. Vaya al directorio WAS_HOME\profiles\ctgAppSrv01\bin.
b. Ejecute el mandato siguiente:
stopServer.bat MXServer -username
nombreusuario_wasadmin -password contraseña_wasadmin
UNIX
a. Vaya al directorio WAS_HOME/profiles/ctgAppSrv01/bin.
b. Ejecute el mandato siguiente:
./stopServer.sh MXServer -username
nombreusuario_wasadmin -password contraseña_wasadmin
Se utilizan los siguientes parámetros en los mandatos:
|
|
nombreusuario_wasadmin
El nombre del usuario administrador de WebSphere Application Server
|
|
|
|
|
contraseña_wasadmin
La contraseña del nombre de usuario especificado.
4. Detenga Tivoli Directory Server. Los mandatos de estos pasos utilizan el
nombre de instancia predeterminado idsccmdb.
a. Detenga la instancia de base de datos.
Capítulo 4. Migración de Tivoli Provisioning Manager
215
Inicie una sesión como propietario de la instancia.
|
1)
UNIX
|
2)
Windows
|
|
3)
En un indicador de mandatos, abra una ventana de DB2 con
el mandato db2cmd.
|
|
|
|
|
|
|
|
|
|
|
4)
Windows
Si tiene Tivoli Directory Server en el mismo sistema que la
base de datos de Tivoli Provisioning Manager, establezca el nombre de
instancia.
Inicie la sesión como usuario con acceso de administrador.
Windows
set db2instance=idsccmdb
5) Ejecute el mandato siguiente para comprobar otras aplicaciones que
haya en ejecución:
db2 list applications
6) Si el mandato lista otras aplicaciones, ejecute el mandato siguiente para
desconectarlas:
db2 force applications all
7) Detenga DB2:
El servidor no tiene una IP virtual
Ejecute el mandato siguiente:
|
|
|
db2stop
Nota: El mandato db2stop sólo se puede ejecutar en el servidor.
No se permiten las conexiones con la base de datos al ejecutar
este mandato, aunque, si hay conexiones de instancia se
desactivarán antes de que se detenga la instancia.
|
|
|
|
El servidor tiene una IP virtual
|
Si utiliza una dirección IP virtual para el servidor de DB2, utilice
el siguiente mandato para detener la base de datos.
|
|
|
|
|
|
|
db2gcf -d -p 0 -i idsccmdb
b. Vaya al directorio TDS_HOME/bin.
c. Detenga Tivoli Directory Server.
ibmdirctl –D cn=root –w contraseña -h
nombrehost stop
|
|
contraseña
La contraseña del DN base (cn=root)
|
|
nombrehost
El nombre de host del sistema de Tivoli Directory Server.
Linux
La parte -h nombrehost del mandato sólo es necesaria si
realiza la conexión desde el sistema Tivoli Provisioning Manager.
|
|
Instalación de los componentes web
|
Debe instalar los componentes web de Tivoli Provisioning Manager desde el
mismo sistema que se utiliza para la instalación de los servicios básicos.
Antes de empezar
v Asegúrese de que se haya iniciado el middleware. Si ha utilizado el instalador
de middleware para instalar el middleware, las aplicaciones de middleware se
inician después de la instalación. Si ha rearrancado el sistema o si ha instalado
manualmente el middleware, compruebe que se haya iniciado el middleware.
Consulte “Inicio del middleware” en la página 184.
216
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v No hay un instalador disponible para la instalación de los componentes web. Si
encuentra un error de instalación y necesita reinstalar los componentes web,
debe recuperar la copia de seguridad que ha creado antes de instalar los
componentes web.
Para instalar los componentes web:
1. Inicie el launchpad.
2. En el panel de navegación del launchpad, haga clic en Instalación
personalizada. Desplácese a 4. Instalar los componentes web de Tivoli
Provisioning Manager y haga clic en Instalar componentes web de Tivoli
Provisioning Manager.
3. En el panel de bienvenida, haga clic en Siguiente.
4. Acepte el acuerdo de licencia y haga clic en Siguiente.
5. En el panel Instalación de paquetes de instalador de solución de proceso,
especifique todos los campos necesarios y haga clic en Siguiente.
ID de usuario de base de datos
Especifique el ID de usuario que se utiliza para Maximo para acceder a
DB2. Debe ser el mismo ID de usuario que ha especificado durante la
instalación de los servicios básicos. El valor predeterminado es maximo.
Contraseña de la base de datos
Especifique la contraseña del nombre del usuario de base de datos
especificado.
Nombre del usuario administrador de WebSphere Application Server
Especifique el nombre del usuario administrador de WebSphere
Application Server. El valor predeterminado es wasadmin.
Contraseña de WebSphere Application Server
Especifique la contraseña del usuario administrador de WebSphere
Application Server.
Nombre del usuario de acceso remoto de WebSphere Application Server
Windows
Escriba Administrator.
UNIX
Linux
Escriba tioadmin.
Tivoli Provisioning Manager está configurado para iniciar
automáticamente los perfiles de WebSphere Application Server con este
nombre de usuario cuando inicia Tivoli Provisioning Manager.
Contraseña de acceso remoto de WebSphere Application Server
Especifique la contraseña del usuario de acceso remoto.
Directorio de instalación de servicios básicos
Especifique la vía de acceso completa del directorio de instalación de
servicios básicos. La ubicación predeterminada es:
v
Windows
v
UNIX
C:\ibm\SMP
Linux
/opt/IBM/SMP
Renueve los idiomas
Seleccione el recuadro de selección para actualizar los archivos para los
componentes web.
Importante: No seleccione este recuadro de selección si ha instalado un
producto Tpae (Tivoli process automation engine) que no instala el
soporte del paquete de idiomas de forma predeterminada.
Capítulo 4. Migración de Tivoli Provisioning Manager
217
Instale el hotfix de los servicios básicos
Marque el recuadro de selección para instalar los arreglos temporales
de disponibilidad limitada de los servicios básicos. Si opta por instalar
el arreglo temporal, el instalador comprueba la versión y sólo instala el
arreglo temporal si la versión instalada es anterior. Si ha instalado un
producto Tpae, es posible que instale otros arreglos temporales de
servicios básicos.
Importante: Si ha instalado el fixpack de servicios básicos 7.1.1.6 o
superior, no seleccione este recuadro de selección.
6. En el panel Presentación preliminar de la instalación, revise los valores de la
instalación y haga clic en Siguiente.
7. Cuando finaliza la instalación, se muestra el panel Resumen de la instalación.
Haga clic en Finalizar.
Resultados
Ahora se han instalado los componentes web de Tivoli Provisioning Manager.
Qué hacer a continuación
“Asignación del nombre de host 5.1.1.2 al servidor de suministro de 7.1.1”
Asignación de los nombres de host
Complete las siguientes tareas para asignar los nombres de host 5.1.1.2 al entorno
de suministro 7.1.1:
Asignación del nombre de host 5.1.1.2 al servidor de
suministro de 7.1.1
Ejecute el script para mover el nombre de host del servidor de suministro 5.1.1.2 al
sistema 7.1.1.
Antes de empezar
1. Asegúrese de que ha añadido los valores de los parámetros del script al archivo
de propiedades. “Adición de valores de parámetros al archivo de propiedades”
en la página 155. El script utiliza los valores que ha especificado en el archivo
de propiedades para rellenar los parámetros en el script. Compruebe por
segunda vez que los valores de los parámetros sean correctos antes de ejecutar
los scripts.
2. Asegúrese de que el siguiente middleware se esté ejecutando:
Servidor de bases de datos
WebSphere Application Server
servidor LDAP
Para obtener información detallada acerca de estos sistemas, consulte “Inicio de
middleware en Windows” en la página 186 o “Inicio del middleware en UNIX
y Linux” en la página 188.
Complete los pasos siguientes en el servidor de suministro 7.1.1.
1. Inicie la sesión en el servidor de suministro 7.1.1.
218
v
Windows
v
UNIX
Inicie la sesión como tioadmin.
Inicie la sesión como root.
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
2. Cambie el nombre de host y la dirección IP del servidor de suministro. Siga el
convenio de nombres que utiliza el nombre de host original que está
modificando. Por ejemplo, si actualmente el nombre de host es un nombre de
host completo, utilice un nombre de host completo para el nombre nuevo.
Para cambiar el nombre de host:
a. En el escritorio, haga clic con el botón derecho del ratón en Mi PC y
seleccione Propiedades.
b. En el separador Nombre de sistema, haga clic en Modificar.
c. En el campo Nombre de sistema, escriba el nombre de host del servidor de
suministro 5.1.1.2.
d. Haga clic en Aceptar para guardar los cambios.
Windows
Para cambiar la dirección IP:
a. Vaya a Panel de control → Conexiones de red y haga clic dos veces en la
conexión de red de área local que está utilizando.
b. En la lista, seleccione Protocolo Internet (TCP/IP) y haga clic en
Propiedades.
Windows
c. En el campo Dirección IP, escriba la dirección IP del servidor de suministro
5.1.1.2.
d. Guarde los cambios.
UNIX
Consulte la documentación específica del sistema operativo para
obtener los pasos detallados para modificar el nombre de host y la dirección IP.
3. Reinicie el servidor de suministro.
4. Vuelva a iniciar la sesión en el servidor de suministro.
v
Windows
Inicie la sesión como tioadmin.
UNIX
Inicie la sesión como root.
v
5. Detenga cualquier proceso Java de WebSphere Application Server que se esté
ejecutando.
v
Windows
Utilice el Gestor de tareas para detener los procesos que están en
ejecución.
v
UNIX
Ejecute el mandato siguiente:
ps -ef | grep java | grep WebSphere
Esto lista los procesos Java de WebSphere Application Server que se están
ejecutando. Utilice el ID de proceso, en la columna PID, para detener cada
proceso ejecutando el mandato siguiente:
kill -9 <ID_proceso>
Ejecute el mandato para cada proceso que se debe detener.
Oracle
2000
. Si está utilizando una base de datos Oracle local, asegúrese de que
se está ejecutando la base de datos.
7. Abra una ventana de mandatos o un shell de mandatos y ejecute el script
siguiente desde el directorio TIO_HOME/migration/scripts:
6.
v
Windows
tpm711ChangeDBHost.cmd
v
UNIX
./tpm711ChangeDBHost.sh
Oracle
2000
Los usuarios de la base de datos Oracle deben validar que el nombre
de host del servidor de suministro 7.1.1 se haya configurado correctamente en
los archivos siguientes:
Capítulo 4. Migración de Tivoli Provisioning Manager
219
v ORACLE_HOME/network/admin/listener.ora
v ORACLE_HOME/network/admin/tnsnames.ora
En el archivo listener.ora, asegúrese de que el valor de HOST es el nombre
completo del servidor de suministro que está utilizando para 7.1.1. Por ejemplo:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = mi_servidor_tpm_711.ibm.com)(PORT = 1521))
En el archivo tnsnames.ora, asegúrese de que los valores de HOST y
SERVICE_NAME son el nombre completo del servidor de suministro 7.1.1. Por
ejemplo:
MAXDB71 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mi_servidor_tpm_711.ibm.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = maxdb71.mi_servidor_tpm_711.ibm.com)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mi_servidor_tpm_711.ibm.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.mi_servidor_tpm_711.ibm.com)
)
)
donde mi_servidor_tpm_711, generalmente es el nombre de host del servidor de
suministro, pero puede ser diferente dependiendo de la configuración de su
base de datos. Por ejemplo, en una base de datos Oracle 10g remota, se lista el
nombre de host de la base de datos remota, en lugar del nombre de host del
servidor de suministro.Cuando verifique que la información es correcta, el
script continúa.
Cuando se ejecute el script, se le solicitarán las contraseñas siguientes:
Tabla 63. Contraseñas necesarias para el script tpm711ChangeDBHost
Contraseña
Descripción
Usuario administrador de base de datos
La contraseña del usuario administrador de base de
datos.
Usuario de base de datos
La contraseña del usuario de la instancia de base de
datos
8.
Si la base de datos es remota, reinicie la base de datos después de
ejecutar el mandato tpm711ChangeDBHost.
9. Para validar que el cambio se ha realizado correctamente, vaya a
TIO_LOGS/migration y abra tpm711ChangeDBHost_status.log. El archivo de
registro lista el estado de cada paso que se ha completado. Todos los pasos
deben estar marcados como DONE. También puede abrir un indicador de
mandatos y comprobar el cambio de nombre de host y dirección IP:
a. Nombre de host: en el indicador de mandatos, escriba hostname. Se
devuelve el nombre de host nuevo del servidor de suministro 7.1.1.
b. Dirección IP: en el indicador de mandatos, escriba ping <nombrehost>,
donde <nombrehost> es el nombre del servidor de suministro 7.1.1. Se
devuelve la nueva dirección IP del servidor de suministro 7.1.1.
220
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Resultados
Cuando se ejecuta el script, se actualiza el nombre de host del servidor de
suministro en las áreas siguientes: Windows
v La tabla MAXPROPVALUE
v Sólo el servidor de bases de datos local: el registro de DB2, la tabla MAXPROPVALUE
y los parámetros de configuración de base de datos relevantes.
UNIX
v La tabla MAXPROPVALUE.
v
Oracle
2000
(local): el archivo tnsnames.ora.
v
Oracle
2000
LDAP de DB2
v
(local): La tabla MAXPROPVALUE y los parámetros de configuración de
base de datos necesarios.
Si encuentra algún problema durante la ejecución del script de migración, visualice
los problemas potenciales y los archivos de registro para poder resolver el
problema y continuar:
v “Detalles de la recuperación de problemas generados durante las actualizaciones
del nombre de host. ” en la página 272
v “Códigos de retorno” en la página 255
Qué hacer a continuación
“Actualización del nombre de host del servidor de bases de datos”
Actualización del nombre de host del servidor de bases de
datos
Cambie el nombre de host y la dirección IP del servidor de bases de datos.
Antes de empezar
1. Asegúrese de que los sistemas siguientes se estén ejecutando:
a. El servidor de bases de datos.
b. El servidor de directorios.
Para obtener información detallada acerca de estos sistemas, consulte “Inicio de
middleware en Windows” en la página 186 o “Inicio del middleware en UNIX
y Linux” en la página 188.
En la estación de trabajo administrativa, actualice el archivo maximo.properties de
los servicios básicos para cambiar el IP o el nombre de host del servidor de bases
de datos, o para actualizar la contraseña.
1. Inicie la sesión en la estación de trabajo administrativa y vaya a
Maximo_HOME\maximo\applications\maximo\properties.
2. En la ubicación Maximo_HOME\etc, edite el archivo maximo.properties_orig y
actualice el nombre de host o la dirección IP para el servidor de bases de
datos. Si es necesario, actualice la contraseña del usuario para acceder a la
base de datos.
3. Si existe la línea siguiente en el archivo maximo.properties_orig, suprima la
línea:
mxe.crontask.donotrun=ALL
Capítulo 4. Migración de Tivoli Provisioning Manager
221
4. Guarde el archivo maximo.properties_orig.
5. Cree una copia de seguridad del archivo maximo.properties_orig. Por
ejemplo, cree una carpeta de copia de seguridad y coloque una copia del
archivo en dicha carpeta.
6. Suprima el archivo maximo.properties en Maximo_HOME\maximo\applications\
maximo\properties.
7. Copie el archivo Maximo_HOME\etc\maximo.properties_orig en
Maximo_HOME\maximo\applications\maximo\properties.
8. Cambie el nombre de Maximo_HOME\maximo\applications\maximo\properties\
maximo.properties_orig por maximo.properties.
9. Para cifrar el archivo maximo.properties, ejecute el mandato
UNIX
Windows encryptproperties.bat o
encryptproperties.sh, situado en el
directorio Maximo_HOME\maximo\tools\maximo.
10. Inicie la sesión en el servidor de suministro como tioadmin.
11. Vaya a TIO_HOME\lwi\runtime\tpm\eclipse\plugins\tpm_pmp\properties y
haga una copia del archivo maximo.properties existente.
12. Copie el archivo maximo.properties cifrado que se ha creado en la estación de
trabajo administrativa en el directorio TIO_HOME\lwi\runtime\tpm\eclipse\
plugins\tpm_pmp\properties del servidor de suministro 7.1.1. Sustituya el
archivo maximo.properties existente.
Qué hacer a continuación
“Actualización de los nombres de host restantes”
Actualización de los nombres de host restantes
Utilice el script para actualizar los nombres de host para el servidor de directorios,
WebSphere Application Server, la infraestructura de distribución de software y
Tivoli Provisioning Manager for OS Deployment.
Antes de empezar
Asegúrese de que ha realizado las acciones siguientes antes de continuar:
1. Ha añadido los valores de los parámetros del script al archivo de propiedades.
“Adición de valores de parámetros al archivo de propiedades” en la página
155. El script utiliza los valores que ha especificado en el archivo de
propiedades para rellenar los parámetros en el script. Compruebe por segunda
vez que los valores de los parámetros sean correctos antes de ejecutar los
scripts.
2. Ha actualizado el archivo maximo.properties en la estación de trabajo
administrativa. “Actualización del nombre de host del servidor de bases de
datos” en la página 221.
3. Se está ejecutando el middleware siguiente:
El servidor LDAP y el daemon de administración.
El servidor de bases de datos
Para ver detalles acerca de cómo iniciar el servidor LDAP, el daemon
administrativo y el servidor de bases de datos, consulte “Inicio de middleware
en Windows” en la página 186 o “Inicio del middleware en UNIX y Linux” en
la página 188
1. Abra una ventana de mandatos y ejecute el script siguiente desde el directorio
TIO_HOME/migration/scripts.
222
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v
Windows
: tpm711ChangeOtherHost.cmd
UNIX
: ./tpm711ChangeOtherHost.sh
v
Se le solicitarán las contraseñas siguientes:
Tabla 64. Contraseñas necesarias para el script tpm711ChangeOtherHost
Contraseña
Descripción
Contraseña de WebSphere Administrative Server
La contraseña del administrador de WebSphere
Application Server.
Usuario de base de datos
La contraseña del usuario de la instancia de base de
datos
Usuario CDSSCHEMA
La contraseña del usuario Oracle, CDSSCHEMA.
Gestor de recursos del gestor de agentes
La contraseña para el nombre de usuario del gestor de
agentes para el gestor de atentes.
Nota: El instalador de Tivoli Provisioning Manager
5.1.1.2 crea la contraseña para este usuario. La contraseña
predeterminada que crea el instalador es password. Utilice
esta contraseña a menos que haya modificado la
contraseña después de la instalación de 5.1.1.2.
SSL del gestor de recursos
La contraseña SSL del gestor de recursos. La contraseña
predeterminada es CDSRMPASS
2. Para validar que se han realizado correctamente los cambios, vaya a
TIO_LOGS/migration y abra tpm711ChangeOtherHost_status.log. El archivo de
registro lista el estado de cada paso que se ha completado. Todos los pasos
deben estar marcados como DONE. También puede comprobar los archivos
siguientes para ver la información actualizada:
a. Abra el archivo TIO_HOME/config/endpoint.properties para ver el nombre
de host del servidor de suministro.
b. Abra el archivo TIO_HOME/config/dcm.xml. La dirección web del código
<URL> debe apuntar al nombre de host de la base de datos.
Resultados
Cuando ejecuta el script de nombre de host, éste completa las tareas siguientes:
1. Actualiza el nombre de host en el archivo user-factory.xml si el servidor de
directorios se encuentra en el mismo sistema que el servidor de suministro
7.1.1.
2. Actualiza el nombre de host para WebSphere Application Server ND.
3. Actualiza el nombre de host para la infraestructura de distribución escalable.
4. Actualiza el nombre de host de Tivoli Provisioning Manager for OS
Deployment.
5. Actualiza el archivo dcm.xml.
6. Cambia el nombre de host de tivoli.send.conf y los archivos
tivoli.receive.conf.
Si encuentra algún problema durante la ejecución del script, visualice los
problemas potenciales y los archivos de registro para poder resolver el problema y
continuar:
v “Detalles de la recuperación de problemas generados durante las actualizaciones
del nombre de host. ” en la página 272
v “Códigos de retorno” en la página 255
v “El cambio de los nombres de host falla en AIX con la base de datos Oracle” en
la página 278
Capítulo 4. Migración de Tivoli Provisioning Manager
223
Qué hacer a continuación
“Inicio del servidor de suministro 7.1.1”
Continuación de la migración en el servidor de suministro 7.1.1
Cuando esté configurada la estación de trabajo administrativa, finalice las restantes
tareas de migración en el servidor de suministro 7.1.1.
Inicio del servidor de suministro 7.1.1
Una vez completados los scripts de migración, inicie el nuevo servidor de
suministro. La actualización del paquete de automatización se inicia cuando inicia
el servidor de suministro.
Antes de empezar
En el servidor de suministro 7.1.1, es posible que haya utilizado una contraseña
para el usuario tioadmin diferente a la contraseña utilizada en el servidor de
suministro 5.1.1.2. Si es así, utilice el mandato changePassword para actualizar la
contraseña tioadmin. La contraseña que se ha utilizado para tioadmin en la versión
5.1.1.2 se debe utilizar durante la migración.
v
Windows
changePassword.cmd -c tioadmin -n <contraseña_nueva> -u
<nombre_usuario_wasadmin> -p <contraseña_wasadmin>
v
changePassword.sh -c tioadmin -n <contraseña_nueva> -u
<nombre_usuario_wasadmin> -p <contraseña_wasadmin>
UNIX
Linux
donde
v contraseña_nueva es la nueva contraseña del usuariotioadmin.
v nombre_usuario_wasadmin es el nombre de usuario de la consola administrativa
de WebSphere Administrative Server
v contraseña_wasadmin es la contraseña del nombre de usuario de la consola
administrativa de WebSphere Administrative Server.
Después de completar la migración, puede cambiar la contraseña tioadmin por una
contraseña diferente.
Para obtener más información, consulte el tema sobre el Mandato changePassword
en el Centro de información de Tivoli Provisioning Manager versión 7.1.1.
Una vez ejecutado correctamente el script de migración, inicie servidor de
suministro.
Para iniciar el servidor de suministro, abra una ventana de mandatos en el sistema.
v
Windows
Vaya a TIO_HOME\tools y escriba tio.cmd start.
v
UNIX
Vaya a TIO_HOME/tools y escriba ./tio.sh start.
Resultados
Se ha iniciado el servidor de suministro. Al mismo tiempo, se inicia el flujo de
trabajo de suministro master_tc_driver_update para actualizar los paquetes de
automatización.
224
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Importante: Dado que esta es la primera vez que se inicia el servidor de
suministro y está realizando la actualización del paquete de automatización al
mismo tiempo, el servidor de suministro puede tardar un tiempo en iniciarse por
completo. Espere hasta que se haya iniciado por completo el servidor de
suministro antes de detenerlo o de intentar realizar otra tarea. El flujo de trabajo de
suministro fallará si no completa la actualización, lo cual puede generar algunos
problemas posteriormente cuando invoque un paquete de automatización durante
una tarea, ya que fallará debido a que no se ha actualizado correctamente.
Para asegurarse de que se ha iniciado por completo el servidor de suministro,
ejecute el mandato siguiente: Windows
tiostatus.cmd nombre_usuario_wasadmin contraseña_wasadmin
UNIX
Linux
./tioStatus.sh nombreusuario_wasadmin contraseña_wasadmin
donde nombre_usuario_wsadmin y contraseña_wasadmin es el nombre de usuario y la
contraseña para el administrador de WebSphere Application Server.
Inicie la sesión en la interfaz web de suministro para asegurarse de que se puede
iniciar:
1. Abra el navegador web y escriba: https://<nombre_host>:<puerto>/maximo,
donde nombre_host es el nombre de dominio completo del servidor de
suministro y puerto es el número de puerto del servidor de suministro. El
número de puerto seguro predeterminado (utilizando https://) es 9443. Si ha
actualizado el servidor de suministro de la versión 7.1 a la versión 7.1.1, el
número de puerto seguro predeterminado es 9045.
2. En la ventana de inicio de sesión, escriba el ID de usuario y la Contraseña y
haga clic en Iniciar sesión. Utilice el ID de usuario maxadmin y la contraseña
maxadmin.
3. Haga clic en Ir a → Gestión de tareas → Tareas de suministro → Estado de flujo
de trabajo de suministro. Asegúrese de que se esté ejecutando la tarea de flujo
de trabajo __master_tcdriver_update_. Espere a que se complete antes de
comenzar a utilizar Tivoli Provisioning Manager.
Qué hacer a continuación
“Validación de la migración”
Validación de la migración
Una vez completada la migración, realice algunas tareas para asegurarse de que el
servidor de suministro funciona como está previsto.
Antes de empezar
Complete todas las tareas de migración definidas en Capítulo 4, “Migración de
Tivoli Provisioning Manager”, en la página 175
Para verificar que la migración se ha realizado correctamente, ejecute las siguientes
operaciones de suministro:
1. Inicie la sesión en la interfaz web de suministro.
Capítulo 4. Migración de Tivoli Provisioning Manager
225
2. Compruebe que los sistemas de su entorno 5.1.1.2 figuren en su entorno de
suministro 7.1.1. Vaya a Ir a → Infraestructura de TI → Inventario de suministro
→ Sistemas de suministro.
3. Ejecute una tarea de suministro. Vaya a Ir a → Gestión de tareas → Tareas de
suministro → Definiciones de tarea de suministro.Para ver los pasos detallados
acerca de cómo ejecutar una tarea de suministro, consulte el tema Ejecución de
una tarea de suministro.
4. Ejecute un descubrimiento básico. Vaya a Ir a → Descubrimiento →
Descubrimiento de suministro → Configuraciones de descubrimiento.
Seleccione un descubrimiento para ejecutarlo. Para obtener más información
acerca del descubrimiento, consulte la guía de aprendizaje denominada
Descubrimiento de recursos de TI.
5. Ejecute un flujo de trabajo de suministro para asegurarse de que el motor de
despliegue funciona. Vaya a Ir a → Administración → Suministro → flujos de
trabajo de suministro. Seleccione un flujo de trabajo de suministro para
ejecutarlo. Para obtener los pasos detallados acerca de cómo ejecutar un flujo
de trabajo de suministro, consulte el tema Ejecución de un flujo de trabajo de
suministro desde el creador de flujo de trabajo de suministro.
Resultados
Al realizar estas operaciones se verifica que la migración se ha realizado
correctamente.
Qué hacer a continuación
“Restauración de la información de LDAP 5.1.1.2 a 7.1.1”
Restauración de la información de LDAP 5.1.1.2 a 7.1.1
Restaure la información de usuarios de 5.1.1.2 al servidor de directorios que está
utilizando para 7.1.1.
Antes de empezar
Se ha creado un archivo LDIF mediante el script tpm5112backup para almacenar la
información de usuario 5.1.1.2. El nombre del archivo depende del entorno de
suministro.
Si está utilizando la autenticación del sistema operativo 5.1.1.2:
LdapBackupOS.ldif
Si está utilizando un servidor LDAP existente para 7.1.1:
LdapBackupExisting.ldif
Si está utilizando un servidor LDAP para 7.1.1: LdapBackupNew.ldif
Abra el archivo y revise la información para asegurarse de que sea correcta antes
de restaurarla en el servidor LDAP 7.1.1. El archivo LDIF se encuentra en
<Dir_copia_seguridad>/ldap/, donde <Dir_copia_seguridad> es la ubicación donde
ha copiado los archivos de copia de seguridad desde el servidor de suministro
5.1.1.2 al sistema 7.1.1. En especial, asegúrese de que la información de cada
usuario sea exclusiva. Por ejemplo, cada usuario debe tener una dirección de
correo electrónico exclusiva. La restauración falla si se encuentra la misma
dirección de correo electrónico para más de un usuario.
Después de ejecutar los scripts de migración, restaure la información de usuario de
5.1.1.2, de modo que estos usuarios puedan acceder a 7.1.1. El archivo LDIF
226
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
también contiene la información de grupos nuevos y miembros de grupo que
necesitan los usuarios de 5.1.1.2 para la versión 7.1.1.
En función del caso de ejemplo LDAP, esto es, si se utiliza un LDAP nuevo o uno
existente, la denominación de los archivos LDIF es diferente. Se crean dos archivos
LDIF para Tivoli Directory Server. Se crea un archivo LDIF para Microsoft Active
Directory.
1. Sólo el servidor de directorios remoto. Si no tiene instalado un cliente LDAP en
el servidor de suministro 7.1.1, copie los archivos LDIF desde el servidor de
suministro a un directorio temporal del servidor LDAP:
Si está utilizando un Tivoli Directory Server existente, copie los archivos
siguientes:
v <Dir_copia_seguridad>/ldap/LdapBackupExisting.ldif
v <Dir_copia_seguridad>/ldap/creation_LdapBackupExisting.ldif.
Si está utilizando un Tivoli Directory Server nuevo, copie los archivos
siguientes:
v <dir_copia_seguridad>/ldap/LdapBackupNew.ldif
v <dir_copia_seguridad>/ldap/creation_LdapBackupNew.ldif.
Si está utilizando la autenticación del sistema operativo en 5.1.1.2 y está
utilizando un Tivoli Directory Server nuevo, copie los archivos siguientes:
v <Dir_copia_seguridad>/ldap/LdapBackupOS.ldif
v <Dir_copia_seguridad>/ldap/creation_LdapBackupOS.ldif.
Si está utilizando Microsoft Active Directory, copie el archivo adecuado:
v Si está utilizando un servidor LDAP nuevo: <Dir_copia_seguridad>/ldap/
LdapBackupNew.ldif .
v Si en 5.1.1.2 utilizaba la autenticación del sistema operativo y está utilizando
un servidor LDAP nuevo: <Dir_copia_seguridad>/ldap/LdapBackupOS.ldif
v Si está utilizando un LDAP existente: <Dir_copia_seguridad>/ldap/
LdapBackupExisiting.ldif
2. Sólo Tivoli Directory Server. En el servidor LDAP de 7.1.1, ya sea remoto o
local, abra un indicador de mandatos y vaya al directorio TDS_HOME/bin. En
dicho directorio, ejecute el mandato para su tipo de LDAP específico, ya sea un
servidor LDAP nuevo o existente.
Tivoli Directory Server existente:
v
Windows
ldapmodify.cmd -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\
creation_LdapBackupExisting.ldif
./ldapmodify -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>/ldap/
creation_LdapBackupExisting.ldif
Tivoli Directory Server nuevo:
v
v
UNIX
Windows
ldapmodify.cmd -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\creation_LdapBackupNew.ldif
./ldapmodify -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>/ldap/creation_LdapBackupNew.ldif
Autenticación de sistema operativo de 5.1.1.2 en un Tivoli Directory Server
nuevo:
v
v
UNIX
ldapmodify.cmd -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\creation_LdapBackupOS.ldif
Windows
Capítulo 4. Migración de Tivoli Provisioning Manager
227
v
UNIX
./ldapmodify -a -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>/ldap/creation_LdapBackupOS.ldif
donde
nombre_distinguido_enlace es el nombre distinguido para acceder al servidor
LDAP, por ejemplo, cn=root.
contraseña es la contraseña para acceder al servidor LDAP.
Dir_copia_seguridad es la ubicación que ha especificado para los scripts de
copia de seguridad en el archivo de propiedades.
Por ejemplo, un usuario que está restaurando un Tivoli Directory Server
existente debe ejecutar el mandato siguiente desde TDS_HOME\bin\:
ldapmodify.cmd -a -D cn=root -w password -i
C:\Archivos de programa\IBM\tivoli\tpm\migration\tpm5112backup\ldap\
creation_LdapBackupExisting.ldif
3. Ejecute los mandatos siguientes en el servidor LDAP:
Tivoli Directory Server existente: En el directorio TDS_HOME/bin, ejecute el
mandato:
v
ldapmodify.cmd -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\LdapBackupExisting.ldif
v
UNIX
./ldapmodify -D <nombre_distinguido_enlace> -w <contraseña>
-i <Dir_copia_seguridad>/ldap/LdapBackupExisting.ldif
Windows
Tivoli Directory Server nuevo: En el directorio TDS_HOME/bin, ejecute el
mandato:
v
Windows
ldapmodify.cmd -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\LdapBackupNew.ldif
v
UNIX
./ldapmodify -D <nombre_distinguido_enlace> -w <contraseña>
-i <Dir_copia_seguridad>/ldap/LdapBackupNew.ldif
Autenticación de sistema operativo de 5.1.1.2 en un Tivoli Directory Server
nuevo: En el directorio TDS_HOME/bin, ejecute el mandato:
v
Windows
ldapmodify.cmd -D <nombre_distinguido_enlace> -w
<contraseña> -i <Dir_copia_seguridad>\ldap\LdapBackupOS.ldif
v
./ldapmodify -D <nombre_distinguido_enlace> -w <contraseña>
-i <Dir_copia_seguridad>/ldap/LdapBackupOS.ldif
UNIX
Microsoft Active Directory
Windows
C:\WINDOWS\system32/ldifde.exe -i -f <nombre_archivo_LDIF>
-t 636
donde nombre_archivo_LDIF es LdapBackupExisting.ldif, LdapBackupNew.ldif o
LdapBackupOS.ldif (si estaba utilizando la autenticación del sistema operativo
en la versión 5.1.1.2).
4. Para los nuevos servidores LDAP, los usuarios deben actualizar sus
contraseñas. Por motivos de seguridad, las contraseñas de usuario no se
almacenan en los archivos LDIF. Para obtener información acerca de cómo
restaurar las contraseñas de usuario, consulte la documentación del tipo de
servidor LDAP adecuado:
v IBM Tivoli Directory Server: “Modificación de las contraseñas de usuario” en
la página 229
v Microsoft Active Directory: http://technet.microsoft.com/en-us/library/
cc782255.aspx
228
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Qué hacer a continuación
“Migración de los grupos de acceso” en la página 230
Modificación de las contraseñas de usuario
No se pueden cambiar contraseñas de usuario en la interfaz web. Tivoli Directory
Server proporciona una herramienta de administración web para que los usuarios
puedan cambiar su contraseña.
La herramienta de administración web no se instala de forma predeterminada.
Consulte la documentación para ver detalles sobre cómo instalar la herramienta de
administración web: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/
index.jsp?topic=/com.ibm.IBMDS.doc/install27.htm.
Una vez instalada la herramienta de administración web, los usuarios pueden
actualizar su contraseña:
1. Inicie la herramienta de administración web con el siguiente mandato:
v
Windows
v
UNIX
<víaacceso_instalación>\idstools\bin\startWebadminApp.bat
<víaacceso_instalación>/idstools/bin/startWebadminApp
donde víaacceso_instalación es el directorio en el que ha instalado Tivoli
Directory Server. Para ver instrucciones detalladas, consulte el tema sobre
ucómo iniciar el servidor de aplicaciones web para utilizar la herramienta de
administración web: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/
index.jsp?topic=/com.ibm.IBMDS.doc/install18.htm.
2. Inicie la herramienta utilizando la siguiente dirección web:
http://<nombrehost>:12100/IDSWebApp/IDSjsp/Login.jsp
donde nombrehost es el nombre de host de Tivoli Directory Server.
3. Inicie una sesión en la herramienta con su nombre de usuario.
4. Haga clic en Propiedades de usuario → Cambiar contraseña.
Si los usuarios reciben el siguiente error al intentar cambiar su contraseña,
significa que no tienen permiso para actualizar su propia contraseña:
GLPWCO025W
La contraseña no se puede cambiar. El usuario no tiene
autorización para modificar la contraseña.
El administrador de LDAP puede actualizar los permisos con el siguiente
mandato:
ldapmodify -D <adminDN> -w <AdminPwd> -i <modifyACL.ldif>
Por ejemplo:
ldapmodify -D cn=root -w password -i modifyACL.ldif
donde el archivo modifyACL.ldif contiene la siguiente información, por ejemplo:
dn: cn=tioappadmin,dc=ibm,dc=com
changetype: modify
add: aclentry
aclentry: access-id:cn=this:at.userpassword:rwsc
Sustituya cn=tioappadmin,dc=ibm,dc=com por su DN de usuario.
Una vez ejecutado el mandato, los usuarios deberían tener el permiso adecuado
para actualizar sus propias contraseñas.
Capítulo 4. Migración de Tivoli Provisioning Manager
229
Migración de los grupos de acceso
Sincronice el servidor de suministro y el servidor LDAP para la información de
usuarios y grupos y luego ejecute el flujo de trabajo de suministro para migrar los
grupos de acceso de 5.1.1.2 en el servidor de suministro 7.1.1.
Antes de empezar
Asegúrese de que ha completado los pasos para actualizar los nombres de host
antes de migrar los grupos de acceso:
1. “Asignación del nombre de host 5.1.1.2 al servidor de suministro de 7.1.1” en la
página 218
2. “Actualización de los nombres de host restantes” en la página 222
1. Inicie la sesión en la interfaz web de suministro.
2. Para sincronizar el servidor de suministro, haga clic en Ir a → Configuración
del sistema → Configuración de la plataforma → Configuración de la tarea
cron.
3. En el campo Tarea cron, escriba VMMSync y pulse Intro.
4. Para activar la sincronización de Virtual Member Manager, seleccione
¿Activo?.
.
5. Para guardar los cambios, haga clic en
6. Inicie la sesión en la estación de trabajo administrativa y vaya a
Maximo_HOME\maximo\applications\maximo\properties. La ubicación
predeterminada para Maximo_HOME es:
v
Windows
C:\ibm\SMP
UNIX
Linux
/opt/IBM/SMP
v
7. Suprima el archivo maximo.properties.
8. Vaya a Maximo_HOME\etc.
9. Copie el archivo maximo.properties_orig en Maximo_HOME\maximo\
applications\maximo\properties.
10. Cambie el nombre del archivo maximo.properties_orig por
maximo.properties.
11. Abra el archivo maximo.properties y añada la línea siguiente al archivo:
mxe.crontask.donotrun=ALL
12. Guarde los cambios.
13. Para cifrar el archivo, ejecute el mandato encryptproperties.bat o
encryptproperties.sh, situado en el directorio Maximo_HOME\maximo\tools\
maximo.
Nota: El archivo maximo.properties_orig descifrado contiene la información
de contraseña en texto sin formato. Para fines de seguridad, puede eliminar la
contraseña. Si necesita volver a utilizar este archivo, vuelva a añadir la
contraseña al archivo.
14. Copie el archivo maximo.properties en la ubicación TIO_HOME/lwi/runtime/
tpm/eclipse/plugins/tpm_pmp/properties del servidor de suministro 7.1.1.
15. Reinicie el servidor de suministro de modo que puedan verse los cambios
importados en la interfaz web.
16. Vuelva a iniciar la sesión en la interfaz web de suministro.
230
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
17. Para ejecutar el flujo de trabajo de suministro para migrar los grupos de
acceso 5.1.1.2 a 7.1.1, vaya a Ir a → Administración → Suministro → flujos de
trabajo de suministro.
18. En el campo Flujo de trabajo de suministro, busque el flujo de trabajo de
suministro denominado TPM711Migration_Security.
19. Haga clic en el flujo de trabajo de suministro para abrir el separador Flujos de
trabajo.
20. En la lista Seleccionar acción, seleccione Ejecutar flujo de trabajo.
Resultados
Cuando se complete el flujo de trabajo, se importarán los grupos de acceso al
servidor de suministro 7.1.1.
Qué hacer a continuación
“Copia de seguridad de la base de datos”
Copia de seguridad de la base de datos
Después de la instalación de Tivoli Provisioning Manager y de los servicios
básicos, haga una copia de seguridad de la base de datos 7.1.1.
Utilice sus propias herramientas de copia de seguridad para realizar una copia de
seguridad completa del sistema o consulte: https://www.ibm.com/
developerworks/wikis/display/tivoliprovisioningmanager/
Backing+up+the+database+and+important+data.
Qué hacer a continuación
“Migración de grupos dinámicos”
Migración de grupos dinámicos
Después de ejecutar los scripts de migración, vuelva a crear las consultas para
grupos dinámicos de modo que funcionen en la versión 7.1.1.
Antes de empezar
Ejecute los scripts de migración.
Nota: Esta migración no es necesaria para los grupos estáticos. Esta tarea
solamente es para grupos dinámicos.
Cuando migra grupos dinámicos de la versión 5.1.1.2 a la versión 7.1.1, los grupos
dinámicos están disponibles en la aplicación Grupos de suministro y tiene todos
sus parámetros pero no tienen contenido debido a que han perdido la consulta con
la que originalmente estaban enlazados.
La estructura de grupos dinámicos en la versión 5.1.1.2 se ha modificado en la
versión 7.1. Los grupos dinámicos de la versión 7.1.1 confían en las consultas de
servicios básicos que incorporan el SQL necesario para recuperar dinámicamente
los datos. Las consultas de servicios básicos están basadas en el objeto de
aplicación, por lo tanto, sólo se pueden crear consultas para objetos que tienen una
aplicación asociada. Por ejemplo, puede crear una consulta para un sistema
utilizando la aplicación Sistemas de suministro. Para obtener una lista de los
Capítulo 4. Migración de Tivoli Provisioning Manager
231
objetos que tienen aplicaciones, consulte el documento denominado “Correlación
del objeto de modelo de datos y la aplicación” en la página 281.
Después de crear una consulta, está disponible para el grupo dinámico mediante la
aplicación Grupos de suministro. Los grupos dinámicos sólo se pueden asociar a
estas consultas; no pueden estar asociadas a ninguna consulta basada en SQL,
como lo estaban en la versión 5.1.1.2. El nombre de la tabla QUERY de la versión
5.1.1.2 se cambia por QUERY5112 durante la migración y todo su contenido se
guarda.
Para volver a crear las consultas para los grupos dinámicos existentes:
1. Haga clic en Ir a → Despliegue → Grupos de suministro. . Escriba el nombre de
para rellenar el
un grupo dinámico 5.1.1.2 en el campo Grupo o haga clic en
separador Lista con todos los grupos.
2. Haga clic en el nombre de un grupo dinámico y verifique que no ninguna
consulta está asociada al grupo. El campo Consulta debe estar vacío.
3. Identifique qué objetos debe recuperar dinámicamente el grupo. Para los
grupos complejos puede utilizar un mandato SQL para recuperar la
información de consultas de la versión 5.1.1.2 desde la base de datos de
suministro 7.1.1:
SELECT CASE
WHEN Q.EDITED_QUERY is not null then Q.EDITED_QUERY
ELSE Q.QUERY_STRING
END query
FROM QUERY5112 Q, DCM_OBJECT O, BASIC_GROUP G
WHERE O.NAME=<nombre_grupo>
AND Q.QUERY_ID=G.QUERY_OBJECT_ID and G.GROUP_ID=O.ID
donde <nombre_grupo> es el nombre del grupo dinámico.
Por ejemplo, si tiene un grupo dinámico denominado Red Hat Linux Computers,
utilice el mandato SQL siguiente:
SELECT CASE
WHEN Q.EDITED_QUERY is not null then Q.EDITED_QUERY
ELSE Q.QUERY_STRING
END query
FROM QUERY5112 Q, DCM_OBJECT O, BASIC_GROUP G
WHERE O.NAME='Red Hat Linux Computers'
AND Q.QUERY_ID=G.QUERY_OBJECT_ID and G.GROUP_ID=O.ID
El mandato devuelve la información siguiente:
SELECT server_info_view.SERVER_NAME
FROM server_info_view WHERE
(server_info_view.OS_NAME LIKE '%Red%Hat%')
ORDER BY server_info_view.SERVER_NAME
En la información, puede identificar que esta consulta utiliza
server_info_view.OS_NAME LIKE ’%Red%Hat%’ para rellenar el grupo dinámico.
4. Cree la consulta para el grupo dinámico navegando al panel de la aplicación
correcta para configurar el filtro.
En el ejemplo Red Hat Linux Computers anterior, utilice la aplicación Sistemas
de suministro. Utilice la salida del mandato SQL para identificar la aplicación y
filtrar la información que necesitará para crear la consulta. En el ejemplo Red
Hat, server_info_view corresponde a la aplicación Sistemas de suministro y
OS_NAME LIKE ’%Red%Hat%’ identifica la información de filtro.
a. Haga clic en Ir a → Despliegue → Sistemas de suministro.
232
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
b. En el campo Sistema operativo, escriba la información de filtro. Por
ejemplo, escriba %Red%Hat%.
c. Pulse Intro para verificar que el filtro recupera todos los sistemas Red Hat
que están en la base de datos.
d. Haga clic en Guardar consulta para almacenar el filtro como una consulta.
Escriba un Nombre de consulta y una descripción para identificar la
consulte y luego haga clic en Aceptar.
5. Asocie la consulta al grupo dinámico. Haga clic en Ir a → Despliegue → Grupos
de suministro.
6. Localice y haga clic en el nombre del grupo dinámico y luego seleccione el
separador Grupo.
7. Junto al campo Consulta, haga clic en
8. Haga clic en
y seleccione la consulta de la lista.
para guardar los cambios del grupo dinámico.
Resultados
Ahora este grupo dinámico tiene una consulta.
Qué hacer a continuación
Estos pasos se deben repetir para cada grupo dinámico que ha migrado a la
versión 7.1.1.
La migración se ha completado. Hay una serie de tareas posteriores a la migración
que puede completar en cualquier momento. Consulte Capítulo 5, “Tareas
posteriores a la migración”, en la página 235.
Capítulo 4. Migración de Tivoli Provisioning Manager
233
234
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 5. Tareas posteriores a la migración
Revise la información de este capítulo para identificar las tareas que debe realizar
después de la migración.
Las tareas posteriores a la migración no se han de completar en ningún orden
concreto. Se pueden completar, cuando el tiempo lo permite, una vez finalizada la
migración.
Tareas posteriores a la instalación
Después de instalar Tivoli Provisioning Manager 7.1.1 y completar las tareas de
migración de la versión 5.1.1.2 a la versión 7.1.1, realice las tareas posteriores a la
migración necesarias para el nuevo servidor de suministro.
Copia de seguridad de la estación de trabajo administrativa
Si no desea mantener activa la estación de trabajo administrativa después de la
instalación, debe crear una copia de seguridad del software que se instala en el
sistema.
La estación de trabajo administrativa no es necesaria para que funcione Tivoli
Provisioning Manager después de la instalación. No obstante, el sistema es
necesario para instalar parches del programa, actualizaciones del producto, nuevas
aplicaciones, nuevos gestores de procesos y paquetes de idioma adicionales. Como
la instalación del software de despliegue de software en la estación de trabajo
administrativa también incluye cambios en el registro de Windows, debe realizar
una copia de seguridad de la instalación para que puedan restaurarse todos los
valores cuando necesite realizar cambios en la instalación.
Si está utilizando un servidor virtual para la estación de trabajo administrativa,
puede crear una imagen del servidor virtual para guardar la configuración de la
estación de trabajo administrativa. También puede hacer una copia de seguridad
de la estación de trabajo administrativa manualmente como se describe en esta
sección.
1. Haga una copia de seguridad de los servicios básicos y de los componentes
web.
a. Cambie al siguiente directorio:
v
Windows
v
UNIX
C:\Archivos de programa\IBM\Common\acsi\bin
/usr/ibm/common/acsi/bin
Linux
b. Ejecute el mandato siguiente:
Windows
de_backupdb.cmd -bfile C:\IBM\SMP\DE_BACKUPS\AFTER_INSTALL_PMP_7.1.1.0
UNIX
Linux
de_backupdb.sh -bfile /opt/IBM/SMP/DE_BACKUPS/AFTER_INSTALL_PMP_7.1.1.0
2. Cree una copia de seguridad del directorio de despliegue.
3.
© Copyright IBM Corp. 2009
v
Windows
v
UNIX
Windows
C:\ibm\SMP
Linux
/opt/IBM/SMP
Cree una copia de seguridad de las entradas de registro.
235
Tabla 65. Entradas de registro para los servicios básicos
Ubicación
Nombre de clave
Valor de clave
Mi PC\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\Tivoli
Base Services
InstallDir
C:\IBM\SMP
Versión
7.1.1.5
Resultados
Ahora tiene una copia de seguridad de la estación de trabajo administrativa. Si
posteriormente necesita restaurar la copia de seguridad, realice los pasos
siguientes:
1. Copie el directorio de despliegue en el nuevo sistema. La ubicación
predeterminada es
v
Windows
v
UNIX
C:\ibm\SMP
Linux
/opt/IBM/SMP
.
2. Copie las entradas de registro en el registro de Windows del nuevo sistema.
3. Instale el motor de despliegue del instalador de soluciones.
a. Cambie al siguiente directorio:
v
Windows
C:\ibm\SMP\de
UNIX
Linux
/opt/IBM/SMP/de
v
4. Ejecute el mandato siguiente para volver a instalar el motor de despliegue.
Windows
si_inst.bat
UNIX
Linux
si_inst.sh
5. Restaure la copia de seguridad de los paquetes instalados. Ejecute el mandato:
Windows
de_restoredb.cmd -bfile C:\IBM\SMP\DE_BACKUPS\AFTER_INSTALL_PMP_7.1.1.0
UNIX
Linux
de_restoredb.sh -bfile /opt/IBM/SMP/DE_BACKUPS/AFTER_INSTALL_PMP_7.1.1.0
Qué hacer a continuación
Configuración de SSL con IBM HTTP Server
Configuración de SSL con IBM HTTP Server
Después de la instalación de Tivoli Provisioning Manager, IBM HTTP Server SSL
no está configurado y, en las instalaciones de UNIX, el usuario root ejecuta el
servidor HTTP. De manera opcional, puede configurar el servidor para que se
ejecute como tioadmin en UNIX y configurar la comunicación SSL con IBM HTTP
Server. Después de esta configuración, puede utilizar un servidor HTTP externo
para acceder a la interfaz de usuario web.
236
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Antes de empezar
Para configurar IBM HTTP Server para que se ejecute como tioadmin:
v El puerto SSL en el que escucha IBM HTTP Server debe ser mayor que 1024. Los
puertos inferiores a 1024 sólo los puede utilizar el usuario root.
v El usuario tioadmin debe tener permiso de escritura para los directorios
siguientes:
– HTTP_HOME/Plugins/config/webserver1
– HTTP_HOME/logs
1. Cree un almacén de claves CMS de HTTP Server y cree un certificado
autofirmado. Para obtener más información, consulte Protección de las
comunicaciones SSL en el centro de información de IBM WebSphere
Application Server.
2. Configure el plug-in del servidor web para Secure Sockets Layer. Para obtener
más información, consulte Configuración del plugin del servidor web para
Secure Sockets Layer en el centro de información de IBM WebSphere
Application Server. Complete los pasos descrito en el orden siguiente:
UNIX
Nota: Utilice los siguientes valores para el contenedor web:
v Almacén de confianza del contenedor Web: TIO_HOME/cert/
tpmTrustStore.jks. En la documentación de WebSphere Application Server, se
hace referencia como raíz_servidor_aplicaciones/profiles/nombre_perfil/
etc/keys/WASWebContainer.jks.
v Certificado del contenedor Web: TIO_HOME/cert/tpmui.cer. En la
documentación de WebSphere Application Server, se hace referencia como
WASWebContainer (certificado autofirmado).
a. Complete el paso 1. Para las instalaciones de UNIX, asegúrese de que el
puerto HTTP es mayor que 1024.
b. Ignore el paso 2. Se ha creado automáticamente un certificado autofirmado
durante Tivoli Provisioning Manager.
c. Complete los pasos 3-5.
d. Ignore el paso 6. Los pasos del repertorio JSSE ya se han completado
durante la instalación de Tivoli Provisioning Manager.
e. Complete los pasos restantes.
3. Añada un puerto HTTP nuevo al host virtual maximo_host.
a. Inicie la sesión en la consola administrativa de WebSphere Application
Server.
https://nombre_host:9043/ibm/console
b. Vaya a Entorno → Hosts virtuales → maximo_host → Alias de host.
c. Elimine todos los puertos no utilizados. Conserve el puerto siguiente:
v Puerto SSL de Tivoli Provisioning Manager (valor predeterminado 9443)
d. Haga clic en Nuevo.
e. Especifique * como el nombre de host y como el puerto SSL de HTTP
Server. Haga clic en Aceptar.
f. Guarde la configuración.
g. Modifique la variable de WebSphere CTG_MAXIMO_SERVLET_URL.
1) Vaya a Entorno → Variables de WebSphere →
CTG_MAXIMO_SERVLET_URL.
2) Actualice el URL con el número de puerto SSL de HTTP Server. El URL
debe tener el formato:
Capítulo 5. Tareas posteriores a la migración
237
https://nombre_host:puerto/maximo/ii/
donde nombre_host es el nombre de host del servidor de aplicaciones
puerto es el puerto SSL de HTTP Server.
4. Reinicie el perfil MXServer.
a. Vaya a Servidores → Servidores de aplicaciones.
b. Seleccione MXServer.
c. Haga clic en Detener.
d. Haga clic en Inicio.
5. Verifique la conexión iniciando la sesión.
https://nombre_host:puerto/maximo
Donde nombre_host es el nombre de host del servidor de aplicaciones y puerto
es el puerto SSL de HTTP Server.
Resultados
Tivoli Provisioning Manager se ha configurado ahora para las comunicaciones SSL
con IBM HTTP Server.
Utilización de Tivoli Monitoring Agent
El agente de supervisión de Tivoli Provisioning Manager permite supervisar Tivoli
Provisioning Manager y realizar operaciones básicas con Tivoli Provisioning
Manager.
El agente de supervisión puede identificar, notificar y corregir problemas comunes
de la aplicación que supervisa. El software incluye las siguientes características:
v Supervisión
v Recopilación de datos
v Gestor de sucesos
El agente de supervisión de Tivoli Provisioning Manager proporciona las siguientes
funciones:
Supervisión de disponibilidad
Proporciona información sobre el servidor de suministro y los componentes
que dependen de Tivoli Provisioning Manager.
Supervisión de tareas
Recopila información sobre las tareas que se han ejecutado en los últimos
días y las tareas previstas para hoy.
Antes de utilizar el agente de supervisión para Tivoli Provisioning Manager, debe
instalar el soporte del agente de supervisión en el servidor de IBM Tivoli
Enterprise Monitoring, el servidor de IBM Tivoli Enterprise Portal y el cliente de
escritorio de IBM Tivoli Enterprise Portal. Para obtener información acerca de estas
tareas, consulte la sección Instalación y habilitación del soporte de aplicaciones en el
centro de información de Tivoli Monitoring.
Qué hacer a continuación
v Para obtener información acerca de cómo utilizar el agente de supervisión,
consulte la publicación Monitoring Agent for Tivoli Provisioning Manager Guía
del usuario.
238
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
v Para obtener información acerca de la instalación manual del agente de
supervisión, consulte la publicación Instalación manual de Monitoring Agent for
Tivoli Provisioning Manager
v Si ha actualizado la instalación de Tivoli Provisioning Manager pero no ha
actualizado el agente de supervisión durante la actualización, consulte la
documentación de Tivoli Monitoring para obtener información de actualización.
– Información del agente de despliegue
– Información de actualización del agente
Configuración manual de la tarea cron VMMSYNC para
Microsoft Active Directory
Si utiliza Microsoft Active Directory como servidor de directorios, deberá
configurar manualmente la tarea cron VMMSYNC para sincronizar información de
usuarios y grupos.
VMMSYNC es la tarea cron que planifica la sincronización entre el servidor de
suministro y el servidor de directorios, y se configura mediante la interfaz de
usuario de la consola de Maximo. Para obtener información más general sobre
cómo configurar la tarea cron de VMMSYNC, consulte el apartado Sincronización
de usuarios y grupos.
En los pasos siguientes se describe cómo reconfigurar la tarea cron VMMSYNC
para su uso con Microsoft Active Directory.
Para modificar la tarea cron VMMSYNC para Microsoft Active Directory, siga estos
pasos:
1. Abra un navegador web y vaya a http://nombre_host:puerto/maximo.
2. Inicie una sesión en Tivoli Provisioning Manager utilizando el ID de usuario
maxadmin.
3. Haga clic en Ir a → Configuración del sistema → Configuración de la
plataforma → Configuración de la tarea cron.
4. Escriba VMM en el campo Tarea cron y pulse Intro.
5. Localice la tarea cron VMMSYNC y púlsela.
6. Configure los valores siguientes:
¿Activo?
Habilite la opción ¿Activo? seleccionando el recuadro de selección.
Credencial
Contraseña de wasadmin en LDAP
GroupMapping
Edite la entrada <basedn> del archivo XML y personalícela para que
utilice los valores de unidad organizativa ou y nombre de dominio dc
que ha definido para la organización al configurar el middleware.
Por ejemplo,
<basedn>ou=Groups,dc=itsm,dc=com</basedn>
En este ejemplo, itsm es el nombre del dominio. Sustituya este valor
por el valor de su propio dominio.
GroupSearchAttribute
cn
Capítulo 5. Tareas posteriores a la migración
239
Principal
cn=wasadmin,ou=Users,ou=SWG,dc=itsm,dc=com
En este ejemplo, itsm es el nombre del dominio. Sustituya este valor
por el valor de su propio dominio.
SynchAdapter
psdi.security.vmm.DefaultVMMSyncAdapter
SynchClass
psdi.security.vmm.VMMSynchronizer
UserMapping
Edite la entrada <basedn> del archivo XML y personalícela para que
utilice los valores de unidad organizativa ou y nombre de dominio dc
que ha definido para la organización al configurar el middleware.
<basedn>ou=Users,ou=SWG,dc=itsm,dc=com</basedn>
En este ejemplo, itsm es el nombre del dominio. Sustituya este valor
por el valor de su propio dominio.
UserSearchAttribute
cn
Haga clic en la flecha que se encuentra en la cabecera de la tabla Parámetros de
la tarea cron para ver todos los parámetros.
7. Haga clic en el icono de guardar.
Los parámetros actualizados se utilizarán en la siguiente sincronización planificada.
Sincronización de usuarios y grupos
La sincronización planificada de usuarios y grupos que se produce entre los
repositorios LDAP y Tivoli Provisioning Manager está controlada por los
repositorios federados que VMM gestiona en WebSphere Application Server y la
tarea cron de VMM de Tivoli Provisioning Manager.
Para obtener información específica acerca de cómo configurar la tarea cron de
VMMSYNC para Microsoft Active Directory, consulte el apartado Configuración
manual de la tarea cron VMMSYNC para Microsoft Active Directory.
Para configurar la planificación de la sincronización entre los repositorios LDAP y
Tivoli Provisioning Manager:
1. Abra un navegador web y vaya a http://nombre_host/maximo.
2. Inicie una sesión en Tivoli Provisioning Manager utilizando el ID de usuario
maxadmin.
3. Haga clic en Ir a → Configuración del sistema → Configuración de la
plataforma → Configuración de la tarea cron.
4. Escriba VMM en el campo Tarea cron y pulse Intro.
5. Localice la tarea cron VMMSYNC y púlsela.
6. Asegúrese de que se utilicen los siguientes valores para cada campo.
Principal
cn=wasadmin,ou=users,ou=SWG,o=IBM,c=US
Este es el usuario que necesita la aplicación CronTask para conectarse al
servicio de VMM (Virtual Member Manager) local. Este valor puede ser
cualquier usuario administrativo de WebSphere Application Server con
240
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
autorización para conectarse al servicio Virtual Member Manager local.
Personalícelo para que utilice los valores de unidad organizativa ou y
nombre de dominio dc que ha definido para la organización al
configurar el middleware.
Credencial
Debe ser la contraseña que se utiliza para la cuenta Principal. En este
caso, especifique la contraseña de wasadmin.
GroupSearchAttribute
cn
Este valor es el atributo de objeto de grupo LDAP que se utiliza para
buscar los grupos en el subárbol de directorios configurado.
UserSearchAttribute
Uid
Este valor es el atributo de objeto de usuario LDAP que se utiliza para
buscar los usuarios en el subárbol de directorios configurado.
SynchAdapter
psdi.security.vmm.DefaultVMMSyncAdapter
Este valor es la clase Java que escribe datos LDAP en la base de datos.
SynchClass
psdi.security.vmm.VMMSynchronizer
Este valor es la clase Java que se conecta al servicio VMM (Virtual
Member Manager) local para buscar los objetos necesarios.
Correlación de grupos
Este campo contiene los archivos de correlación XML que correlacionan
los atributos de objeto LDAP con las columnas de tabla de repositorio
de base de datos. Cambie las siguientes entradas de objeto para que
utilicen el valor de unidad organizativa ou que ha definido para la
organización al configurar el middleware de Provisioning Manager.
Basedn
ou=groups,ou=SWG,o=IBM,c=US
Define el subárbol LDAP en el que la tarea cron de VMM
(Virtual Member Manager) buscará los objetos de grupo.
Filtro
Es la clase de objeto de VMM (Virtual Member Manager) que
utiliza el servicio para buscar los objetos de grupo en LDAP.
Grupo
Correlación de usuarios
Este campo contiene los archivos de correlación XML que correlacionan
los atributos de objeto LDAP con las columnas de tabla de repositorio
de base de datos. Cambie las siguientes entradas de objeto para que
utilicen el valor de unidad organizativa ou que ha definido para la
organización al configurar el middleware de Provisioning Manager.
Basedn
ou=users,ou=SWG,o=IBM,c=US
Define el subárbol LDAP en el que la tarea cron de VMM
(Virtual Member Manager) buscará los objetos de usuario.
Filtro
PersonAccount
Capítulo 5. Tareas posteriores a la migración
241
Es la clase de objeto de VMM (Virtual Member Manager) que
utiliza el servicio para buscar los objetos de usuario en LDAP.
7. Establezca la tarea en activa.
Resultados
Qué hacer a continuación
De forma predeterminada, la tarea cron ejecutará su tarea cada 5 minutos. Si desea
cambiar el intervalo, modifique el valor para el campo Planificación.
Actualización del identificador exclusivo global en Solaris
Si el servidor de suministro se ha instalado en Solaris, debe realizar el
procedimiento siguiente para el identificador exclusivo global (GUID) se actualice
correctamente. Esto es necesario para que funcionen correctamente las tareas de
distribución de software.
Antes de empezar
Realice los pasos siguientes en la estación de trabajo administrativa:
1. Si ha utilizado archivos descargados para la instalación, vaya al directorio
donde ha descargado el archivo TPM_V711_QS.zip. Si ha utilizado los DVD para
la instalación, este archivo se encuentra en el DVD de Inicio rápido.
2. Extraiga el archivo solaris_tivguid\guid_solaris_sparc.tar desde el archivo
TPM_V711_QS.zip.
3. Copie el archivo guid_solaris_sparc.tar desde la estación de trabajo
administrativa a un directorio del servidor de suministro, por ejemplo,
/var/tmp.
Para actualizar el GUID, realice los pasos siguientes en el servidor de suministro:
1. Inicie la sesión como tioadmin
2. Vaya a AM_HOME/guid.
3. Extraiga el archivo guid_solaris_sparc.tar ejecutando tar -xvf
/var/tmp/guid_solaris_sparc.tar
4. Ejecute su root
5. Ejecute ./installguid_solaris2.sh. Verá un mensaje de confirmación como el
siguiente:
Creating TIVOLI Global Unique Identifier ...
Tivoli GUID utility - Version 1, Release 3, Level 4.
(C) Copyright IBM Corporation 2002, 2009 All Rights Reserved.
BTATG0004I A GUID already exists on this host. A new GUID will not be created.
Guid:...
Qué hacer a continuación
Realice las otras tareas posteriores a la instalación, si corresponde. Para obtener
más información, consulte Tareas posteriores a la instalación .
242
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Restaure los valores de WebSphere Application Server
WebSphere Application Server se ha instalado con los valores predeterminados
para la versión 7.1.1. Después de la migración, puede restaurar manualmente
cualquier configuración que haya utilizado en la versión 5.1.1.2
Vuelva a crear cualquier valor de WebSphere Application Server que tenga en la
versión 5.1.1.2. Por ejemplo, es posible que desee restaurar el tamaño de la pila
Java o cambiar el intervalo de sondeo del gestor de dispositivos.
Ejemplo
Para cambiar el intervalo de sondeo del servicio del gestor de dispositivos:
1. Abra la consola administrativa de WebSphere Application Server.
2. Haga clic en Entorno → WebSphere Variables → server1 y, a continuación, haga
clic en Aplicar.
3. Edite la propiedad DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES para que
refleje el intervalo que desea.
4. Haga clic en Aplicar y, a continuación, haga clic en Guardar dos veces.
5. Reinicie el servidor de suministro.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Configuración del servidor de suministro para la integración con otros
productos
Después de haber migrado a la versión 7.1.1, si desea integrar Tivoli Provisioning
Manager con SRM (Service Request Manager) o CCMDB (Change and
Configuration Management Database), es necesario realizar algunas tareas de
configuración.
Antes de instalar CCMDB o SRM en el servidor de suministro, debe configurar el
nombre de host del servidor de suministro que se almacena en la estación de
trabajo administrativa. Cambie el nombre de host del servidor de suministro por el
nombre de host de 5.1.1.2.
1. Inicie la sesión en la estación de trabajo administrativa.
2. Vaya a C:\IBM\SMP\etc\.
3. Abra el archivo install.properties y sustituya todas las apariciones del
nombre de host del servidor de suministro 7.1.1 por el nombre de host del
servidor de suministro 5.1.1.2.
4. Edite el archivo <dir_instalación_CCMDB>\wasclient\ThinWsadmin.bat y
sustituya todas las apariciones del nombre de host del servidor de suministro
7.1.1 por el nombre de host del servidor de suministro 5.1.1.2, donde
dir_instalación_CCMDB es el directorio donde se ha instalado CCMDB.
5. En el servidor de suministro 7.1.1, vaya a WAS_HOME/profiles/ctgDmgr01/etc/ y
copie el archivo trust.p12.
6. En la estación de trabajo administrativa, pegue el archivo trust.p12 en
<dir_instalación_CCMDB>\wasclient\etc\.
Capítulo 5. Tareas posteriores a la migración
243
Resultados
Cuando se hayan realizado las actualizaciones, las actualizaciones SRM (Service
Request Manager) o CCMDB (Change and Configuration Management Database)
se puede instalar correctamente las actualizaciones en el servidor de suministro
7.1.1 nuevo.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Volver a crear los roles personalizados
Añada los roles que ha creado para su entorno de suministro 5.1.1.2.
Para crear el rol para su servidor de suministro 7.1.1, añada el nuevo grupo de
seguridad y asigne los miembros al grupo.
1. Vaya a Ir a → Seguridad → Grupos de seguridad.
para agregar un grupo nuevo.
2. Haga clic en
3. Escriba el nombre del grupo nuevo.
para guardar el grupo nuevo.
4. Haga clic en
5. Para agregar miembros nuevos al grupo, haga clic en el separador Usuarios.
6. Haga clic en Seleccionar usuarios.
7. Seleccione los usuarios que desea agregar al grupo y haga clic en Aceptar.
Resultados
El rol personalizado que tenía en el servidor de suministro 5.1.1.2 se vuelve a crear
en el entorno 7.1.1.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Volver a crear las imágenes de Tivoli Provisioning Manager for OS
Deployment Embedded Edition
Las imágenes creadas con Tivoli Provisioning Manager for OS Deployment
Embedded Edition 5.1.1.2 no se migran. Si ha vuelto a capturar las imágenes de
5.1.1.2 utilizando un servidor de suministro de prueba 7.1.1 antes de la migración,
ahora puede clonarlas en el servidor de producción 7.1.1. O puede volver a crear
las imágenes de la versión 5.1.1.2 utilizando el servidor de suministro de la versión
7.1.1.
Hay dos modos para volver a crear las imágenes de la versión 5.1.1.2. Puede
utilizar una de las siguientes opciones:
1. Utilizar un entorno de suministro 7.1.1 de prueba para volver a capturar las
imágenes contenidas en el entorno de suministro 5.1.1.2. Cuando se complete la
244
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
migración de los datos, ejecute el flujo de trabajo de suministro para clonar las
imágenes en su servidor de suministro 7.1.1. de producción.
Nota: Este proceso se debe completar antes de iniciar la migración a la versión
7.1.1. Las imágenes 5.1.1.2 ya no están disponibles porque el servidor de
suministro no se puede utilizar después de haber realizado la copia de
seguridad.
2. Volver a crear las imágenes en el entorno de suministro 7.1.1. después de la
migración.
Para volver a crear las imágenes, consulte el documento Despliegue de sistemas
operativos en el Centro de información de Tivoli Provisioning Manager versión 7.1.1..
La siguiente información proporciona los pasos para completar el proceso
ejecutando el flujo de trabajo para mover las imágenes desde el entorno de prueba
al entorno de producción.
Clonación de las imágenes de su entorno 7.1.1 de prueba
Antes de empezar
Los pasos siguientes se deben completar antes de iniciar la migración:
v Ha vuelto a crear las imágenes 5.1.1.2 de su entorno de suministro de prueba.
Consulte “Migración de las imágenes creadas utilizando Tivoli Provisioning
Manager for OS Deployment Embedded Edition” en la página 37.
v Ha instalado la versión 7.1.1 en un servidor de suministro de producción y ha
migrado los datos de 5.1.1.2.
v Asegúrese de que la contraseña que utiliza para iniciar la sesión en la interfaz
web para Tivoli Provisioning Manager for OS Deployment es la misma que la
del servidor de suministro 7.1.1 de prueba y el servidor de suministro 7.1.1 de
producción donde está clonando las imágenes. Cuando instala Tivoli
Provisioning Manager 7.1.1 en los sistemas de prueba y producción, utilice la
misma contraseña para el usuario maxadmin, de modo que las contraseñas ya
coincidan. Si las contraseñas no coinciden, el flujo de trabajo de suministro que
clona las imágenes no se ejecutará correctamente.
Ejecute el flujo de trabajo de suministro denominado TPMfOSd_CloneRemoteServer.
El flujo de trabajo de suministro clona las imágenes desde el servidor de
suministro 7.1.1 de prueba al servidor de producción. También elimina todas las
imágenes y los módulos de software desde el servidor de producción y las
sustituye con las imágenes y los módulos de software que está clonando desde el
servidor de suministro de prueba.
1. Inicie la sesión en el servidor de suministro 7.1.1 de producción.
2. Vaya a Ir a → Administración → Provisioning → flujos de trabajo de suministro.
3. En el campo Flujo de trabajo de suministro, escriba el nombre
TPMfOSd_CloneRemoteServer.
4. Haga clic en el nombre del flujo de trabajo de suministro.
5. Haga clic en Seleccionar acción → Ejecutar flujo de trabajo. La página
Parámetro de entrada para flujo de trabajo muestra los parámetros de flujo de
trabajo de suministro que requiere el flujo de trabajo de suministro.
6. Especifique la dirección IP del servidor de suministro 7.1.1 de prueba.
7. Si desea ejecutar el flujo de trabajo de suministro en un momento concreto o a
intervalos regulares, expanda Planificación, haga clic en el botón Planificación
y especifique las opciones adecuadas.
Capítulo 5. Tareas posteriores a la migración
245
8. Haga clic en Ejecutar.
Resultados
La página Estado del flujo de trabajo se visualiza con el estado de la ejecución del
flujo de trabajo. Si el flujo de trabajo de suministro tarda mucho en ejecutarse,
haga clic en Renovar para actualizar el estado del flujo de trabajo de suministro.
Haga clic en
para ver el resultado del flujo de trabajo de suministro.
Se iniciará un descubrimiento de imágenes, de modo que las imágenes que se
acaban clonar se descubran en la base de datos del servidor de suministro de
producción.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Migración de los GUID de Tivoli Application Dependency Discovery
Manager
Si utiliza Tivoli Application Dependency Discovery Manager, ejecute la
herramienta para migrar los GUID de modo que se puedan almacenar
correctamente en la versión 7.1.1.
En la versión 7.1.1, los GUID (Global Unique Identifiers) para Tivoli Application
Dependency Discovery Manager se almacenan de una forma diferente a cómo lo
hacían en la versión 5.1.1.2.
1. En el servidor de suministro 7.1.1, abra una ventana de mandatos y vaya al
directorio de script.
v
Windows
TIO_HOME\migration\scripts\
UNIX
TIO_HOME/migration/scripts/
v
2. Ejecute el mandato para migrar los GUID de Tivoli Application Dependency
Discovery Manager:
v
Windows
migrateTaddmGuidsFrom5112.cmd
UNIX
./migrateTaddmGuidsFrom5112.sh
v
3. Si la miración se ejecuta correctamente, se crea un archivo con indicación de la
hora, TIO_LOGS/migrateTaddmGuidsFrom5112.ok.
4. La versión de Tivoli Application Dependency Discovery Manager se debe
actualizar a la versión 7.1.2 para que pueda funcionar con Tivoli Provisioning
Manager versión 7.1.1. y, por lo tanto, se pueden utilizar los GUID migrados.
Siga las instrucciones del Centro de información de Tivoli Application Dependency
Discovery Manager versión 7.1.2 para actualizar Tivoli Application Dependency
Discovery Manager: http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/
topic/com.ibm.taddm.doc_7.1.2/InstallGuide/c_cmdb_upgradeoverview.html.
Resultados
Archivo de registro
246
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Si surgen problemas durante la migración del GUID de Tivoli Application
Dependency Discovery Manager, consulte los archivos de registro para obtener
información:
Windows
TIO_LOGS/MigrateTaddmGuidsFrom5112.log
UNIX
TIO_LOGS/MigrateTaddmGuidsFrom5112.log
La herramienta sólo se debe ejecutar una vez en el servidor de suministro 7.1.1. Si
debe volver a ejecutar la herramienta, en primer lugar suprima el
archivomigrateTaddmGuidsFrom5112.ok del directorio TIO_LOGS y luego vuelva a
ejecutar la herramienta.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Importación de un certificado SSL para VMware
Para utilizar VMware con la versión 7.1.1, importe los certificados SSL al servidor
de suministro de modo que el servidor de suministro pueda conectarse con
VMware Virtual Center.
El servidor de suministro utiliza el protocolo HTTPS para conectarse al centro
virtual y acceder a los servidores virtuales. Importe los certificados SSL para
habilitar la conexión HTTPS.
Para obtener los pasos detallados, consulte el documento Importación del
certificado SSL en el Centro de información de Tivoli Provisioning Manager 7.1.1.
Qué hacer a continuación
Después de importar los certificados SSL, vuelva a descubrir los servidores de la
plataforma del host y los servidores virtuales para migrar el servidor virtual y el
servidor de la plataforma del host. Para ver los pasos detallados, consulte el tema
Descubrimiento de los servidores de la plataforma del host y los servidores
virtuales.
Para obtener información acerca de la virtualización de VMware utilizando Tivoli
Provisioning Manager, consulte Gestión de servidores virtuales y servidores de
plataformas utilizando VMware.
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Restauración y eliminación de paquetes de automatización
Instale los paquetes de automatización personalizados de 5.1.1.2 de los que ha
hecho una copia de seguridad antes de la migración. Asimismo, si hay paquetes de
automatización de 5.1.1.2 que durante la migración han pasado a estar en desuso,
descárguelos desde OPAL e instálelos en el servidor de suministro 7.1.1. Desinstale
cualquier paquete de automatización en desuso que no utilice.
Capítulo 5. Tareas posteriores a la migración
247
Antes de empezar
Asegúrese de que el servidor de suministro se esté ejecutando antes de instalar o
desinstalar los paquetes de automatización.
Paquetes de automatización personalizados
El proceso de migración mantendrá el registro de base de datos de los paquetes de
automatización que ha creado en la versión 5.1.1.2, pero es posible que los
paquetes de automatización no funcionen en la versión 7.1.1.
Para restaurar los paquetes de automatización personalizados, realice los pasos
siguientes en el servidor de suministro 7.1.1:
1. Instale y configure Automation Packager Developer Environment. Para obtener
los pasos detallados, consulte Instalación y configuración de Automation
Package Developer Environment
Nota: en Windows y Linux, Automation Packager Developer Environment
debe estar instalado en un sistema remoto. No se puede instalar en el mismo
sistema que el servidor de suministro ya que Automation Packager Developer
Environment se debe instalar en sistemas de 32 bits.
2. Restaure los paquetes de automatización de copia de seguridad antes de
realizar la migración a la ubicación TIO_HOME/drivers del servidor de
suministro 7.1.1.
3. Instale cada paquete de automatización ejecutando el mandato siguiente:
v
v
tc-driver-manager.cmd forceInstallDriver | fid
<nombre_paquete>
Windows
UNIX
Linux
./tc-driver-manager.sh forceInstallDriver | fid
<nombre_paquete>
donde nombre_paquete es el nombre del paquete de automatización, sin la
extensión .tcdriver.
Resultados
Después de ejecutar el mandato para cada paquete de automatización, todos los
paquetes de automatización que ha creado en la versión 5.1.1.2 se pueden
gestionar en el servidor de suministro 7.1.1.
Para obtener más información acerca de este mandato, consulte Mandato
tc-driver-manager.
Nota: Algunos flujos de trabajo de suministro 5.1.1.2 no funcionarán debido a que
se ha modificado el modo de evaluar las expresiones Jython en la versión 7.1.1. La
versión Jython se ha actualizado en 7.1.1 como parte del tiempo de ejecución del
motor de despliegue. Es posible que la siguiente expresión Jython falle durante el
tiempo de ejecución si la variable devuelve NULL:
log debug Jython["Test Variable = " + testVariable]
Cambie las líneas en el flujo de suministro personalizado en la línea siguiente:
log debug "Test Variable = " + testVariable
248
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Esto utiliza la depuración del registro en el flujo de trabajo de suministro para
imprimir la salida del archivo de registro. Tendrá la misma salida que Jython, pero
evitará el valor NULL que hará que falle la línea.
Paquetes de automatización 5.1.1.2 en desuso
Algunos paquetes de automatización quedan en desuso cuando se migran a la
versión 7.1.1. Para revisar la lista, consulte Tabla 26 en la página 33.
Algunos paquetes de automatización continúan disponibles en OPAL (Open
Process Automation Library). Si son necesarios estos paquetes de automatización
para las operaciones de suministro, descargue los paquetes e instálelos en la
versión 7.1.1.
1. Abra un navegador web y vaya al sitio web de OPAL: http://www01.ibm.com/software/tivoli/features/opal/.
2. Haga clic en Acceso a IBM Tivoli Open Process Automation Library (OPAL).
3. En el campo Buscar en resultados:, escriba el nombre del paquete de
automatización que desea descargar. Por ejemplo, escriba AIX_FIX.
4. Busque el paquete de automatización en los resultados de la búsqueda y haga
clic en Descargar sitio.
5. Guarde el paquete de automatización en la ubicación TIO_HOME/drivers del
servidor de suministro 7.1.1.
6. Instale cada paquete de automatización ejecutando el mandato siguiente:
v
v
Windows
tc-driver-manager.cmd forceInstallDriver | fid
<nombre_paquete>
UNIX
Linux
./tc-driver-manager.sh forceInstallDriver | fid
<nombre_paquete>
donde nombre_paquete es el nombre del paquete de automatización, sin la
extensión .tcdriver.
Resultados
Realice estos pasos para cada uno de los paquetes de automatización 5.1.1.2 que
utilice en sus operaciones de suministro.
Desinstalación de los paquetes de automatización en desuso
Suprima los paquetes de automatización en desuso que no utilice en sus
operaciones de suministro.
1. Revise la lista para ver los paquetes de automatización que puede suprimir:
Tabla 26 en la página 33.
2. Desinstale cualquier paquete de automatización que no necesite ejecutando el
mandato siguiente:
v
v
Windows
tc-driver-manager.cmd forceUnInstallDriver | fud
<nombre_paquete>
UNIX
Linux
./tc-driver-manager.sh forceUnInstallDriver | fud
<nombre_paquete>
donde nombre_paquete es el nombre del paquete de automatización, sin la
extensión .tcdriver.
Capítulo 5. Tareas posteriores a la migración
249
Resultados
Ejecute este mandato para cualquier paquete de automatización que no sea
necesario, de modo que se elimine de la base de datos de suministro.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Restauración de los repositorios de archivos locales
Vuelva a crear los repositorios de archivos 5.1.1.2 en el servidor de suministro 7.1.1.
Antes de comenzar la migración, ha anotado las vías de acceso de archivo para los
repositorios de archivos locales 5.1.1.2 y ha creado una copia de seguridad de los
archivos de software situados en cada repositorio de archivos. La copia de
seguridad se ha realizado en una ubicación que no estaba en el servidor de
suministro 5.1.1.2. Ahora que se ha completado la migración, vuelva a crear los
repositorios de archivos y restaure los archivos de software.
Para realizar esta tarea, siga estos pasos en el servidor de suministro 7.1.1:
1. Vuelva a crear el repositorio de archivos 5.1.1.2. Para obtener las instrucciones
detalladas, consulte Creación de repositorios de archivos. Cuando especifique la
vía de acceso raíz, si la vía de acceso que anotado en 5.1.1.2 no está disponible
en el servidor de suministro 7.1.1, especifique una vía de acceso diferente.
2. Acceda a los archivos de software 5.1.1.2 de copia de seguridad y añádalos a
los repositorios de archivos que ha vuelto a crear. Para obtener las instrucciones
detalladas, consulte Adición de archivos a repositorios de archivos.
Resultados
Los repositorios de archivos que ha creado para 5.1.1.2 se restaurarán ahora en el
servidor de suministro 7.1.1.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Volver a crear la información de conformidad
Las comprobaciones de conformidad y las exploraciones planificadas relacionadas
se migran a la versión 7.1.1. El estado de conformidad y la información acerca de
la última exploración no se migran.
Después de la migración, ejecute las comprobación de conformidad en los sistemas
de destino, o grupos de sistemas de destinos, para cumplir las recomendaciones y
actualizar el estado de conformidad del servidor de suministro 7.1.1.
Para obtener los pasos detallados sobre las comprobaciones de conformidad en el
servidor de suministro 7.1.1, consulte la guía de aprendizaje en Gestión de
conformidad.
250
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Volver a crear los informes personalizados
El proceso de crear informes personalizados se ha modificado en Tivoli
Provisioning Manager 7.1. Aprenda dónde puede encontrar la documentación de
informes actual y la información acerca de las nuevas vistas de informes.
Nuevo diseñador de informes
Tivoli Provisioning Manager 5.1 utiliza la tecnología Alphablox para el diseño de
informes. En Tivoli Provisioning Manager 7.1, esta tecnología se ha sustituido por
el diseñador BIRT (Business Intelligence and Reporting Tools), la nueva tecnología
de generación de informes utilizada por Tivoli. El motor de informes de BIRT está
incorporado en Tivoli Process Automation Platform. Todos los productos Tivoli
Process Automation Platform comparten una instancia del tiempo de ejecución
BIRT. Los informes de BIRT se crean mediante el diseñador de informes BIRT y
luego se importan a Tivoli Process Automation Platform.
Utilice el diseñador de informes BIRT Versión V2.3.2. Descargue esta versión desde
OPAL (IBM Open Process Automation Library): http://www-01.ibm.com/
software/brandcatalog/portal/opal/details?NavCode=1TW10OT07.
Para obtener la información más reciente acerca de cómo configurar los informes
con BIRT, consulte http://www.ibm.com/support/us/en/. En el campo Search all
of support, escriba 1390372. Los resultados de la búsqueda proporcionan enlaces
con los documentos siguientes:
1. Configuring BIRT Designer 2.3.2 with V7 Products
2. V7 Reporting Feature Guide
Importante: Se ha cambiado el nombre de la tabla de consultas de Tivoli
Provisioning Manager por query5112 durante la migración. Todo el contenido de la
tabla de consultas se ha retenido. Utilice la consulta para crear informes nuevos en
7.1.1.
Nuevas vistas de informes
Las vistas de base de datos predefinidas disponibles para los desarrolladores de
informes personalizados también se han modificado. Consulte el enlace siguiente
para ver la documentación de las nuevas vistas.
v Vistas de informe
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Capítulo 5. Tareas posteriores a la migración
251
Cambios en los informes predefinidos
Se han reorganizado los informes predefinidos. Utilice estas tablas para
comprender cómo se han modificado los informes predefinidos y las alternativas
disponibles para los informes predefinidos anteriores.
Informes eliminados
Este diagrama describe detalladamente los informes que se han eliminado.
También indica donde se pueden encontrar alternativas para ejecutar estos
informes predefinidos.
Tabla 66. Informes eliminados y sus alternativas.
Nombre del informe
Alternativa
Los informes de seguridad los cubre ahora
Audit001 - ¿Quién ha asignado permisos a el informe de Grupo de seguridad Maximo.
Puede encontrar información adicional
grupos de acceso, qué permisos y para
acerca de cómo utilizar y administrar los
qué usuario?
informes Maximo, en la publicación Tivoli
Audit002 - ¿Qué cambios de software se
Common Reporting Guía del usuario.
han realizado y qué usuario los ha
Nota: Si el informe de Grupo de seguridad
realizado?
no proporciona las características necesarias,
Audit003 - ¿Qué cambios de hardware se se puede crear un informe personalizado
han realizado y qué usuario los ha
utilizando las vistas de informe
realizado?
proporcionadas. Consulte la Guía del
desarrollador de informes en el centro de
Audit004 - ¿Qué cambios de flujo de
trabajo se han realizado y qué usuario los información de Tivoli Provisioning Manager
versión 7.1.1 y las Vistas de informes para
ha realizado?
obtener ayuda acerca de cómo crear
Audit005 - ¿A quién se ha notificado un
informes personalizados.
suceso y qué sucesos se han notificado?
Informes de auditoría:
v
v
v
v
v
v Audit006 - ¿Cuándo han iniciado la sesión Audit004 - ¿Qué flujos de trabajo se han
los usuarios?
ejecutado recientemente? se denomina ahora
tp_workflows.rptdesign-¿Qué flujos de
trabajo se han ejecutado recientemente?
Audit005 - ¿A quién se ha notificado un suceso
y qué sucesos se han notificado? se denomina
ahora tp_eventsUserNotifications.rptdesign¿Qué usuarios tienen notificación de cada
suceso?
El informe Audit006 - ¿Cuándo han iniciado la
sesión los usuarios? se ha sustituido por los
siguientes informes de Maximo.
v login_history.rptdesign - Historial de
inicio de sesión
v user_session.rptdesign - Sesión de usuario
Para obtener información acerca de los
registros de seguimiento de inicio de sesión
y de auditoría electrónicos, consulte el tema
Auditoría de cambios.
252
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 66. Informes eliminados y sus alternativas. (continuación)
Nombre del informe
Alternativa
Informes de despliegue:
Las características de estos informes se
pueden encontrar ahora en:
v Deployment002 - ¿Qué software se ha
desplegado correctamente en este sistema? v tp_patchesOnServers.rptdesign - ¿Qué
parches están instalados en cada servidor?
v Deployment003 - ¿Qué despliegue de
software no se ha ejecutado en cada
sistema?
v Deployment004 - ¿Qué despliegue de
software está en ejecución en cada
sistema?
v tp_software.rpt - ¿Qué software está
instalado en cada servidor?
v tp_deploymentSummaryChart.rptdesign ¿Cuál es el estado de todos los
despliegues de software?
v Deployment005 - ¿Qué despliegue de
Para obtener más información acerca de los
software está planificado en cada sistema? informes de despliegue, consulte el tema
Informes de parches.
v Deployment006 - ¿Qué despliegue de
software se ha cancelado en cada sistema?
v Deployment008 - ¿Qué despliegue de
parche se ha ejecutado en sistemas
agrupados por sistema operativo?
Otros informes:
v ¿Cuál es el estado de las tareas en
ejecución o que ya se han ejecutado?
v ¿Qué tareas tienen un estado
determinado?
v ¿Qué destinos están implicados en cada
tarea?
Informes de inventario:
v ¿Qué objetos contiene el centro de datos?
v ¿Qué software contiene el centro de
datos?
v ¿Qué software contiene cada grupo de
software?
Las características de estos informes se
pueden encontrar ahora en:
v tp_taskStatus.rptdesign - ¿Cuál es el
estado de todas las tareas?
v tp_taskSummaryChart.rptdesign ¿Cuántas tareas están en un estado
específico?
Estos informes ya no se proporcionan. Si
requiere estos informes personalizados,
existe una vista de informe. Consulte el
tema Vistas de informes para obtener
información acerca de la vista inventario:
todo.
Migración de las extensiones de inventario
Las extensiones de inventario se utilizan para ejecutar informes de inventario
personalizados. Después de la migración, ejecute un mandato para volver a crear
las definiciones del informe para la versión 7.1.1 e importe los informes en el
servidor de suministro 7.1.1.
1. Vaya a TIO_HOME/tools y ejecute el mandato siguiente:
v
Windows
migrateInvExtension.cmd
v
UNIX
migrateInvExtension.sh
Al ejecutar el mandato se genera el informe asociado a cada extensión de
inventario existente. Se crean las definiciones de informes para la versión 7.1.1.
2. Importe cada informe en el servidor de suministro 7.1.1. Siga las instrucciones
detalladas del tema denominado Configuración del entorno para ejecutar el
informe personalizado en el Centro de información de Tivoli Provisioning Manager
versión 7.1.1.
Capítulo 5. Tareas posteriores a la migración
253
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
Plan de actividades y tareas de puntos finales
Los planes de actividades y las tareas de puntos finales que se han creado en el
editor de planes de actividades de la versión 5.1.1.2 los puede migrar el usuario
MAXADMIN.
A partir de la versión 7.1, los planes de actividades y las tareas de puntos finales
creadas en el editor de planes de actividades se asignan al usuario que las ha
creado. En la versión 5.1.1.2, no se realizaba un seguimiento de la información de
usuarios. Durante la migración a 7.1.1, los planes de actividades y las tareas de
puntos finales se asignarán al usuario que ha ejecutado las tareas en la versión
5.1.1.2. Si el plan de actividades o la tarea de punto final no se ha ejecutado nunca
en la versión 5.1.1.2, se asignará al usuario MAXADMIN. Sólo el usuario MAXADMIN
podrá configurar la tarea en la interfaz web de suministro.
Después de la migración, si los usuarios están buscando un plan de actividades o
una tarea de punto final y no pueden encontrarlo, debe solicitarle al usuario
MAXADMIN que busque la tarea en su lista de Definiciones de tareas y comparta la
tarea.
Para compartir la definición de tarea, el usuario MAXADMIN puede realizar estos
pasos:
1. Haga clic en Ir a → Gestión de tareas → Tareas de suministro → Definiciones de
tarea de suministro.
2. En la lista de tareas de suministro, busque la tarea de suministro que desea
compartir y haga clic en ellas.
3. En el menú Seleccionar acción, haga clic en Compartir tarea de suministro.
4. Haga clic en Nuevo usuario.
5. Especifique un nombre de usuario o selecciónelo haciendo clic en
6. Haga clic en Guardar.
.
Resultados
La definición tarea de suministro la comparten los usuarios especificados. Podrán
ver la definición compartida en la aplicación Definiciones de tarea de suministro,
en su sesión de inicio. Ambos la utilizan y la intercambian.
Qué hacer a continuación
Realice las otras tareas posteriores a la migración, si corresponde. Para obtener más
información, consulte Capítulo 5, “Tareas posteriores a la migración”, en la página
235.
254
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 6. Recuperación de errores de la migración
Si se produce un error durante la migración, utilice la información de este capítulo
para identificar el problema y resolverlo.
Para obtener información adicional sobre resolución de problemas que no esté
contenida en esta guía, consulte la publicación Tivoli Provisioning Manager7.1.1 Guía
de resolución de problemas.
Códigos de retorno
Revise la lista de códigos de retorno para obtener información acerca de cómo
resolver los problemas que se producen durante la migración.
Tabla 67. Lista de códigos de retorno
Código
Descripción
11001
El registro de Common Agent Services no se ha completado. El mandato
’%MIGCMD%’ ha devuelto el código de error ’%ERRLEVEL%’.
11002
La instalación de Common Agent Services no se ha completado. El mandato
’%MIGCMD%’ ha devuelto el código de error ’%ERRLEVEL%’.
12001
Ha fallado el descifrado de la contraseña AMP.
12002
Ha fallado la actualización del archivo de respuestas de entrega de
contenido dinámico.
12003
Ha fallado la actualización de la base de datos de entrega de contenido
dinámico.
Este error se puede producir si está utilizando una base de datos Oracle 10g
para la versión 7.1.1 y ejecuta el script tpm711migrate.
Este es un problema conocido con Oracle 10g, donde SHUTDOWN IMMEDIATE va
seguido de STARTUP MOUNT.
Si esto sucede, ejecute otro SHUTDOWN en la base de datos y luego emita
STARTUP para poder conectarse a la base de datos. Para obtener más
información, consulte http://www.dba-oracle.com y busque en el sitio web
ORA-12528 para ver el tema ORA-12528: sgu TNS: sugerencias del escucha.
Una vez reiniciado el escucha de Oracle, vuelva a ejecutar el script
tpm711migrate.
12004
Ha fallado la instalación de la entrega de contenido dinámico.
12005
Ha fallado la base de datos de entrega de contenido dinámico.
12006
La instalación de la entrega de contenido dinámico no se ha completado. El
mandato ’%MIGCMD%’ ha devuelto el código de error ’%ERRLEVEL%’.
13001
La instalación del servicio del gestor de dispositivos no se ha completado. El
mandato ’%MIGCMD%’ ha devuelto el código de error ’%ERRLEVEL%’.
14000
Se ha producido una excepción inesperada del sistema de migración de
datos. Consulte el archivo TIO_LOGS/logs/migration/dataMigration.log
para obtener más detalles.
14001
Se ha producido una excepción SQL. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
© Copyright IBM Corp. 2009
255
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
14002
No se ha podido recuperar el tipo de base de datos del archivo dcm.xml.
Consulte el archivo TIO_LOGS/logs/getdb.log para obtener más detalles.
14003
No se ha podido recuperar el nombre de base de datos del archivo dcm.xml.
Consulte el archivo TIO_LOGS/logs/getdb.log para obtener más detalles.
14004
No se ha podido recuperar el nombre de usuario de base de datos del
archivo dcm.xml. Consulte el archivo TIO_LOGS/logs/getdb.log para obtener
más detalles.
14005
No es posible conectarse a la base de datos. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
14006
No se ha podido migrar la agrupación de almacenamientos intermedios y
no se han podido crear los espacios de tablas. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
14007
No se han podido crear los espacios de tablas. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
14008
No se han concedido permisos al usuario de la base de datos para utilizar el
espacio de tablas. Consulte el archivo TIO_LOGS/logs/migration/
dataMigration.log para obtener más detalles.
14009
El tipo de base de datos no se ha podido determinar. Asegúrese de que el
tipo de base de datos definido en el archivo TIO_HOME/config/dcm.xml sea
DB2 u Oracle.
14010
Los argumentos de entrada no son válidos. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
14011
No se ha concedido al usuario de base de datos DBADM. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
14012
El permiso de selección de SYSIBM.SYSDUMMY1 no se ha concedido. Consulte
el archivo TIO_LOGS/logs/migration/dataMigration.log para obtener más
detalles.
14013
El archivo de configuración de migración de entrada no es válido. Los
archivos de configuración de migración válidos son tpm5112to711.xml y
tpm71to711.xml.
14014
No se puede instalar el paquete de automatización. Consulte el archivo
TIO_LOGS/logs/tcdrivermanager.log para obtener más detalles.
Es posible que el paquete de automatización personalizado tenga el mismo
nombre que un paquete de automatización predefinido 7.1.1. Los paquetes
de automatización personalizados deben tener nombres exclusivos para
evitar este conflicto de nombres. Realice los pasos siguientes para la
recuperación de este error:
1. Restaure la base de datos desde la copia de seguridad 5.1.1.2.
2. Desinstale el paquete de automatización personalizado.
3. Vuelva a ejecutar el script tpm711migrate.
14015
No se puede desinstalar el paquete de automatización. Consulte el archivo
TIO_LOGS/logs/tcdrivermanager.log para obtener más detalles.
14016
La migración del repositorio de archivos local ha fallado. Compruebe que el
archivo TIO_HOME/config/tcdrivermanager.xml existe y que contiene un
valor de repositorio válido (especificado como la propiedad repository).
14017
No se han importado las firmas de software. Consulte el archivo
TIO_LOGS/importSoftwareSignature.log para obtener más detalles.
14018
No se han importado las firmas de software personalizadas. Consulte el
archivo TIO_LOGS/importSoftwareSignature.log para obtener más detalles.
256
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
14019
La migración de datos de paquetes de automatización ha fallado. Consulte
el archivo TIO_LOGS/run-mastertcdriverupdate.log para obtener más
detalles.
14501
La migración de datos ha finalizado con algunos avisos. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
16000
Se ha producido un error genérico durante el proceso de migración. Para
resolver el problema, consulte los detalles de los pasos.
16001
No se ha suministrado un nombre de script para el seguimiento. Asegúrese
de que todas las llamadas ″TrackBatch″ de ’%LaunchTitle%’ incluyen un
nombre de script y vuelva a intentarlo.
16002
Se debe ejecutar ’%LaunchTitle%’ como el usuario ’%runasuser%’. Finalice la
sesión e inicie la sesión como ’%runasuser%’ y vuelva a ejecutar el script.
16003
El entorno TIO_HOME se debe definir. Consulte el centro de información para
obtener más detalles.
16004
El usuario debe pertenecer al grupo ’%TIOADMIN_GRP%’ para realizar la
instalación. Asigne el usuario al grupo y vuelva a intentarlo.
16005
No se puede encontrar el archivo ’%SETUPCMD%’. Es posible que el
entorno de Tivoli Provisioning Manager esté dañado. Consulte el centro de
información para obtener más detalles.
16006
No se ha podido encontrar la versión del producto para Tivoli Provisioning
Manager en el archivo ’%TIO_HOME%/config/build-version.properties’.
Consulte el centro de información para obtener más detalles.
16007
No se ha podido determinar la versión del producto de Tivoli Provisioning
Manager. Consulte el centro de información para obtener más detalles.
16008
La migración no está soportada en la versión actual ’%VERSION%’. La
versión necesaria es ’%MIGRATE_FROM_VERSION%’.
16009
El entorno TIO_LOGS no está definido, por lo tanto, los registros de migración
se almacenarán en el directorio %TMP%. Ejecute el script como el usuario
tioadmin y vuelva a intentarlo.
16010
El nombre de host del sistema, ’%REAL_HOSTNAME%’, es diferente del
nombre con el que se ha configurado el archivo de respuestas:
’%OPT_711_HOSTNAME_SHORT%’. Consulte el centro de información para
obtener más detalles.
16011
La opción ″%~1″ no es válida. Verifique la sintaxis de uso e inténtelo de
nuevo.
16012
A la opción ″%~1″ le falta un valor. Verifique la sintaxis de uso e inténtelo
de nuevo.
16013
El directorio ’%DEST_DIR%’ no se ha podido creado debido al código
%ERRLEVEL%. Arregle el error y vuelva a intentarlo.
16014
A la opción ’%EXPECTING%’ le falta un valor. Consulte el archivo
’%PropertyFile%’ para ver los valores correctos.
16015
No se ha podido realizar la migración en la versión actual ’%VERSION%’.
La versión necesaria es ’%MIGRATE_TO_VERSION%’.
16016
No se ha podido encontrar el directorio ’%OPT_BK_DIR%’ para los archivos
de copia de seguridad. Consulte la ubicación y vuelva a intentarlo.
16017
No está soportada la migración para esta arquitectura Linux. Consulte el
centro de información para obtener más detalles.
Capítulo 6. Recuperación de errores de la migración
257
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
16018
La migración no está soportada para este sistema operativo. Consulte el
centro de información para obtener más detalles.
16019
No se puede ejecutar el script ’%SETUPCMD%’. Utilice el mandato ’chmod
+x’ para permitir que se ejecute este script.
16020
No se ha instalado una aplicación de compresión de archivos o no se ha
incluido la vía de acceso del ejecutable en la variable PATH. Coloque el
programa de utilidad de compresión de archivos en la variable PATH.
16021
La variable TERM no se ha establecido correctamente. Establézcala en ’ansi’,
’xterm’ o ’vt100’.
16022
El valor ’%TIO_LOG%’ de la variable TIO_LOG se debe definir como un
directorio válido. Consulte el centro de información para obtener más
detalles.
16023
La base de datos ’%BACKUPDB%’ ya existe. Vuelva a catalogar o desactivar
la base de datos en primer lugar para impedir que se pierdan datos y
vuelva a intentarlo.
16024
No se ha podido restaurar la clave para generar valores exclusivos para el
Tivoli GUID. Consulte el centro de información para obtener más detalles.
16025
Existe un tipo de base de datos no soportado ’%DB_TYPE%’. El valor de
’type’ bajo el archivo TIO_HOME/config/dcm.xml se debe establecer en ’db2jcc’
o ’ORACLE’.
16026
El directorio ’%CAS_HOME%’ no es válido para el gestor del agente.
Compruebe si existen errores en la instalación del gestor.
16027
El nombre de usuario de base de datos no se ha podido determinar.
Compruebe el valor de 'username' en el archivo TIO_HOME/config/dcm.xml.
16028
El nombre de base de datos no se ha podido determinar. Compruebe el
valor de name en el archivo TIO_HOME/config/dcm.xml.
16029
El archivo ’%CAS_HOME%/toolkit/tca5112backup.zip’ no se puede mover al
directorio de copia de seguridad. Compruebe los errores del proceso de
copia de seguridad del gestor de agentes y vuelva a intentarlo.
16030
El Tivoli GUID no se ha generado correctamente con el código de retorno
’%ERRLEVEL%’. Compruebe los derechos de acceso del archivo
’%TIVGUID_FILE%’.
16031
No se han podido copiar los archivos de configuración desde el directorio
TIO_HOME/config. Compruebe si se puede acceder a los archivos y a los
directorios.
16032
No se ha podido empaquetar todo el contenido de copia de seguridad de
Tivoli Provisioning Manager. Compruebe el espacio de disco y los derechos
de directorio en el directorio TIO_HOME/migration/backup.
16033
El mandato ’%MIGCMD%’ no se ha podido completar debido al código de
error ’%ERRLEVEL%’.
16034
El usuario ’%OPT_DBADM_USER%’ o la contraseña no son correctos para
acceder a la base de datos ’%DB_NAME%’.
16035
No se ha podido desempaquetar todo el contenido de copia de seguridad de
Tivoli Provisioning Manager. Compruebe que existe el archivo
’TIO_HOME/migartion/backup/tpm5112backup’ y los derechos de acceso al
directorio ’%OPT_BK_DIR%’.
258
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
16036
No se ha instalado un programa de utilidad de compresión de archivos o no
se ha incluido la vía de acceso del ejecutable de compresión en la variable
PATH. Coloque el programa de utilidad de compresión de archivos en la
variable PATH.
16037
El programa de utilidad Tivoli GUID no se ha podido localizar. Consulte el
centro de información para obtener más detalles.
16038
No se ha podido ejecutar ″db2set DB2_WORKLOAD=TPM″ para preparar la
migración de datos. Consulte el centro de información para obtener más
detalles.
16039
No se ha podido encontrar el archivo ’%VPD_FILE%’. Consulte el centro de
información para obtener más detalles.
16040
Error reservado para los mensajes internos acerca de un seguimiento de
scripts no válidos. Compruebe la sintaxis del código si se informa acerca de
este error.
16041
No se ha podido determinar el directorio de usuario para el administrador
de base de datos. Asegúrese de que el administrador de base de datos sea
correcto y se haya configurado como un usuario del sistema operativo.
16042
No se ha podido localizar la clave de base de datos desde el archivo
’%OPT_BK_DIR%/config/crypto.xml’. Compruebe si todos los archivos de
copia de seguridad están disponibles.
16043
El procedimiento de copia de seguridad de Tivoli Provisioning Manager
5.1.1.2 no puede continuar. Es necesaria la copia de seguridad de base de
datos manual.
16044
El procedimiento de restauración de Tivoli Provisioning Manager 7.1.1 no se
puede continuar. Es necesaria la restauración manual de la base de datos.
16045
No se puede localizar el directorio ’%DEST_DIR%’. Compruebe la vía de
acceso del directorio.
16046
No se ha podido cambiar el nombre de host de DB2.
16047
No se ha podido cambiar el nombre de host de la base de datos Oracle.
16048
No se han podido actualizar las propiedades de la base de datos Maximo.
16049
No se ha podido cambiar el nombre de host de WebSphere Application
Server.
16050
No se ha podido actualizar el nombre de host del gestor de agentes.
16051
No se ha podido cambiar el nombre de host de Tivoli Provisioning Manager
para el despliegue del sistema operativo.
16052
Ha fallado el reinicio de Tivoli Provisioning Manager para el despliegue del
sistema operativo.
16053
Un usuario ha seleccionado salir del proceso actual para cambiar los
parámetros de entrada.
16054
No se ha podido encontrar el archivo con la vía de acceso de archivo de
configuración de DB2.
16055
Las opciones de ’%EXPECTING%’ incluyen valores predeterminados entre
llaves. Se deben sustituir por valores reales sin llaves en el archivo
’%PropertyFile%’.
16056
Se ha producido un problema al eliminar los registros de auditoría debido al
código ’%ERRLEVEL%’. Si el tamaño de copia de seguridad de la base de
datos no es un problema, intente ejecutar el script sin la opción
’removeAuditData’.
Capítulo 6. Recuperación de errores de la migración
259
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
16057
No se ha podido actualizar endpoint.properties.
16058
No se ha podido actualizar el archivo user-factory.xml.
16059
No se ha podido actualizar el archivo tpm-cds-authentication.properties.
16060
No se ha podido actualizar el archivo config.csv.
16061
No se ha podido actualizar el archivo dcm.xml.
16062
No se ha podido abrir el archivo de destino.
16063
No se ha podido abrir el archivo temporal.
16064
Faltan los argumentos de entrada de script o no son válidos.
16065
No se ha podido actualizar el archivo tec-event-customer-info.xml.
16066
No se ha podido actualizar el archivo tivoli.send.conf.
16067
No se ha podido actualizar el archivo tivoli.receive.conf.
16068
No se ha podido registrar la entrega de contenido dinámico.
16069
No se ha podido localizar el programa de utilidad de compresión de
archivos predeterminado en la instalación de Tivoli Provisioning Manager.
Establezca el archivo zipBackupFiles en false en el archivo
’%PropertyFile%’. Vuelva a ejecutar el script y luego realice una compresión
manual de los archivos de copia de seguridad.
16070
No se ha podido encontrar el archivo soap_ssl.properties.
16071
No se ha podido encontrar la propiedad com.ibm.ssl.keyStore en el archivo
soap_ssl.properties.
16072
No se ha podido deshacer la configuración de Maximo.
16073
No se ha podido restaurar la conexión de base de datos.
16074
No se han podido forzar las aplicaciones de base de datos.
16075
No se ha podido detener la base de datos.
16076
No se ha podido iniciar la base de datos.
260
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
16077
No se ha podido importar tpmfosdbootserver.xml para crear el objeto de
servidor de arranque de Tivoli Provisioning Manager.
Este error se produce cuando el script tpm711ChangeOtherHost.cmd o
tpm711ChangeOtherHost.sh no puede crear el servidor de despliegue de SO
padre en el servidor de suministro utilizando los datos de
tpmfosdbootserver.xml.
El origen del error puede ser:
v Problemas de conexión con la base de datos
v Datos incorrectos en la base de datos
v Un archivo tpmfosdbootserver.xml no válido.
Para solucionar el error:
1. Verifique que se ha iniciado la base de datos ctginst1.
2. Verifique que el nombre del objeto de servidor de Tivoli Provisioning
Manager en modelo de datos sea el nombre de host corto o el nombre
de dominio completo del servidor de suministro.
3. En tpmfosdbootserver.xml, verifique que el atributo host-server sea el
nombre de host corto o el nombre de dominio completo del servidor de
suministro.
4. Cuando haya realizado todos los pasos anteriores, ejecute
tpm711ChangeOtherHost.cmd o tpm711ChangeOtherHost.sh para
continuar con el proceso de migración.
16078
No se ha podido encontrar el nombre de host completo de Tivoli
Provisioning Manager 5.1.1.2 en el archivo TIO_HOME/lwi/runtime/tpm/
eclipse/plugins/tpm_pmp/properties/maximo.properties. Ha fallado la
comprobación del nombre de host.
16079
No se ha podido encontrar el nombre de host completo de Tivoli
Provisioning Manager 7.1.1 en el archivo TIO_HOME/xml/tpmserver.xml. Ha
fallado la comprobación del nombre de host.
16080
No se ha podido copiar getConfig.py en el directorio CAS_HOME/toolkit/
resources.
16081
El esquema de base de datos es diferente del nombre de usuario en el
archivo dcm.xml.
Durante la instalación de los componentes principales de 7.1.1, ha
especificado el Nombre de usuario del servidor de DB2 y el Nombre de
esquema. Estos dos nombres deben ser iguales.
Para la recuperación de este error, siga estos pasos:
1. Abra el archivo TIO_HOME/config/dcm.xml.
2. Busque las etiquetas schema y username.
3. Edite los valores de modo que coincidan. Por ejemplo, si el valor de
schema es maximo, cambie el valor de username por maximo.
4. Guarde los cambios.
5. Vuelva a ejecutar el script tpm711restore.
16082
El esquema de base de datos no se puede determinar. Compruebe el valor
de ’schema’ bajo el archivo TIO_HOME/config/dcm.xml.
Capítulo 6. Recuperación de errores de la migración
261
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
16083
Falta el archivo instalador de Common Agent Services o tiene una vía de
acceso incorrecta. Compruebe el parámetro -imageDir en el archivo de
propiedades de migración y asegúrese de que los archivos se hayan extraído
correctamente en la ubicación correcta.
16084
Falta el archivo instalador de Dynamic Content Delivery o tiene una vía de
acceso incorrecta. Compruebe el parámetro -imageDir en el archivo de
propiedades de migración y asegúrese de que los archivos se hayan extraído
correctamente en la ubicación correcta.
16085
Falta el archivo instalador del servicio de gestor de dispositivos o tiene una
vía de acceso incorrecta. Compruebe el parámetro -imageDir en el archivo
de propiedades de migración y asegúrese de que los archivos se hayan
extraído correctamente en la ubicación correcta.
17001
Ha fallado el cifrado de la contraseña del gestor de agentes para el servicio
de gestor de dispositivos.
17002
Ha fallado la configuración del perfil de Common Agent Services.
17003
No se ha podido detener el perfil de Common Agent Services.
17004
Ha fallado el mandato was_unixsetup.sh.
17005
No se ha podido iniciar el perfil de Common Agent Services.
17006
Ha fallado la configuración del perfil de ND.
17007
No se ha podido detener MXServer.
17008
No se ha podido detener el Agente de nodo.
17009
No se ha podido detener el Gestor de despliegue.
17010
No se ha podido iniciar el Agente de nodo.
17011
No se ha podido iniciar el Gestor de despliegue.
18001
Falta un parámetro necesario en el mandato. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18002
Falta un valor de parámetro en el mandato. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18003
Se ha pasado un parámetro en el mandato que no está soportado. Consulte
el archivo TIO_LOGS/logs/migration/dataMigration.log para obtener más
detalles.
18004
Se ha encontrado un valor de fábrica de usuarios no válido en
%TIO_HOME%/config/user-factory.xml. El valor se establece durante la
instalación y no se debe modificar.
18005
No se puede leer el directorio de configuración %TIO_HOME%/config. Debe
tener permiso de lectura para acceder al directorio. El directorio debe existir.
18006
No se puede leer el archivo %TIO_HOME%/config/user-factory.xml. Debe
tener permiso de lectura para acceder al archivo. El archivo debe tener el
formato correcto.
18007
El archivo %TIO_HOME%/config/crypto.xml no se puede leer. El archivo no se
puede leer. Debe tener permiso de lectura para acceder al archivo. El
archivo debe tener el formato correcto.
18008
No se ha encontrado el elemento user-factory en el archivo
user-factory.xml. El elemento se establece durante la instalación y no se
debe modificar.
18009
No es válido el elemento user-factory del archivo user-factory.xml. El
elemento se establece durante la instalación y no se debe modificar.
262
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
18010
No se puede acceder al directorio. Consulte el archivo TIO_LOGS/logs/
migration/dataMigration.log para obtener más detalles.
18011
No se ha podido crear el contexto de LDAP. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18012
No se ha podido descifrar la contraseña de LDAP. Compruebe la contraseña
en el archivo user-factory.xml y asegúrese de que se ha cifrado utilizando
la clave del archivo crypto.xml.
18013
No se ha podido crear el objeto JDOM a partir de XML. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18014
No se puede grabar en el archivo. Consulte el archivo TIO_LOGS/logs/
migration/dataMigration.log para obtener más detalles.
18015
No se ha podido encontrar el algoritmo criptográfico Desede. Compruebe el
entorno de la JVM para asegurarse de que el proveedor criptográfico tiene
el algoritmo Desede.
18016
No se ha podido encontrar el algoritmo criptográfico DSA. Compruebe el
entorno de la JVM para asegurarse de que el proveedor criptográfico tiene
el algoritmo Desede.
18017
Se ha producido una excepción de seguridad. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18018
No se han podido descifrar los datos. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18019
No se han podido cerrar las conexiones LDAP.
18020
No se ha podido recuperar el nombre del espacio de nombres desde el
contexto LDAP. Compruebe la configuración de LDAP en el archivo
user-factory.xml y asegúrese de que LDAP esté ejecutándose.
18021
No se ha podido recuperar el entorno desde el contexto LDAP. Compruebe
la configuración de LDAP en el archivo user-factory.xml y asegúrese de
que LDAP esté ejecutándose.
18022
No se ha podido realizar la búsqueda de LDAP. Consulte el archivo
TIO_LOGS/logs/migration/dataMigration.log para obtener más detalles.
18023
El valor de entrada no coincide con los valores esperados. Consulte el
archivo TIO_LOGS/logs/migration/dataMigration.log para obtener más
detalles.
18024
No se ha podido encontrar user dn en LDAP. Consulte el archivo
TIO_LOGS/logs/migration/ldapBackup.log o el archivo TIO_LOGS/logs/
migration/ldapOSQuery.log para obtener más detalles.
23003
No se ha podido crear la base de datos %NEW_DB_NAME% [DB2 Return
Code=%RETURNCODE%][Error Description=%RETURN_MSG%]. Corrija el problema
y vuelva a ejecutar el script.
23004
No se ha podido conectar con la base de datos. Asegúrese de que el nombre
de usuario y la contraseña sean válidos y vuelva a ejecutar el script.
23005
No se ha podido restaurar la base de datos %TC_DB%, [DB2 Return
Code=%RETURNCODE%][Error Description=%RETURN_MSG%]. Corrija el problema
y vuelva a ejecutar el script.
23006
No se ha podido copiar el esquema de base de datos. Asegúrese de que
existe espacio de disco suficiente y corrija los problemas indicados.
23007
No se ha podido desactivar el esquema de base de datos original. Corrija los
problemas indicados y vuelva a ejecutar el script.
Capítulo 6. Recuperación de errores de la migración
263
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
23008
No se ha podido desactivar la tabla temporal de base de datos. Asegúrese
de que ningún otro cliente de base de datos esté accediendo a la base de
datos y vuelva a ejecutar el script.
23009
No se ha podido desactivar la función temporal de base de datos. Asegúrese
de que ningún otro cliente de base de datos esté accediendo a la base de
datos y vuelva a ejecutar el script.
23010
No se ha podido desactivar el procedimiento almacenado temporal de base
de datos. Asegúrese de que ningún otro cliente de base de datos esté
accediendo a la base de datos y vuelva a ejecutar el script.
23011
No se ha podido desactivar el esquema temporal de base de datos.
Asegúrese de que ningún otro cliente de base de datos esté accediendo a la
base de datos y vuelva a ejecutar el script.
23012
No se ha podido realizar la copia de seguridad de base de datos%TC_DB%.
DB2 ha devuelto %RETURNCODE%.. El mensaje de error es: %RETURN_MSG%.
Corrija el problema y asegúrese de que el nombre del directorio de
copia de seguridad sea válida y tenga espacio de disco suficiente.
23013
No se han podido instalar los procedimientos almacenados de
redenominación del esquema de base de datos. Consulte los archivos tmp_
prefixed.log en el directorio tmp o temp para ver los mensajes de error.
23014
No se ha podido realizar la copia de seguridad de base de datos %TC_DB%.
Consulte los problemas indicados y vuelva a ejecutar el script.
23015
REGEDIT no ha podido exportar el registro de DB2 al archivo.
23016
No se ha podido abrir el archivo de registro exportado.
23017
No se ha podido abrir el archivo para importar el registro.
23018
REGEDIT no ha podido importar el registro DB2 desde el archivo.
23019
Faltan los argumentos de entrada de script o no son válidos. Compruebe si
todos los parámetros de entrada son válidos. Si el problema persiste,
póngase en contacto con el servicio de soporte de IBM.
23020
No se ha podido obtener el valor de propiedad desde la tabla MAXPROPVALUE
de base de datos. Valide el usuario de base de datos en el
archivoTIO_HOME/config/dcm.xml y vuelva a ejecutar el script.
23021
No se ha podido actualizar el valor de propiedad en la tabla MAXPROPVALUE
de base de datos. Póngase en contacto con el soporte de IBM.
23022
No se ha podido actualizar la configuración de la base de datos. Póngase en
contacto con el soporte de IBM.
23023
No se ha podido establecer el parámetro de base de datos. Verifique y
corrija la configuración del sistema de base de datos y vuelva a ejecutar el
script.
23024
No se ha podido alterar la agrupación de almacenamientos intermedios de
base de datos. Verifique y corrija la configuración del sistema de base de
datos y vuelva a ejecutar el script.
23025
No se ha podido extraer y guardar la vía de acceso a los archivos de
configuración de base de datos. Asegúrese de que existe espacio de disco
suficiente y corrija los problemas indicados.
23026
No se ha podido detener el servidor del administrador de base de datos.
Verifique y corrija el estado de la base de datos y vuelva a ejecutar el script.
23027
No se ha podido iniciar el servidor del administrador de base de datos.
Verifique y corrija el estado de la base de datos y vuelva a ejecutar el script.
264
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 67. Lista de códigos de retorno (continuación)
Código
Descripción
23028
No se ha podido iniciar el gestor de base de datos. Verifique y corrija el
estado de la base de datos y vuelva a ejecutar el script.
23029
No se ha podido actualizar la configuración del administrador de base de
datos. Verifique y corrija la configuración el problema de base de datos
indicado y vuelva a ejecutar el script.
23030
No se ha podido obtener la configuración del administrador de base de
datos. Verifique y corrija la configuración el problema de base de datos
indicado y vuelva a ejecutar el script.
23031
No se ha podido procesar el esquema de CDB utilizando la restauración de
base de datos. Póngase en contacto con el soporte de IBM.
23032
Los alias de tabla del esquema de CDB no coinciden con la lista esperada.
Póngase en contacto con el soporte de IBM.
23051
ORACLE_HOME no se ha establecido.
23052
El directorio de plantillas de DBCA no existe.
23053
Falta un elemento de copia de seguridad.
23054
El archivo de plantillas existe en el directorio de plantillas de DBCA.
23055
Ha fallado la restauración de DBCA. El código de retorno es
%RETURN_CODE%.
23056
Ha fallado la configuración de la base de datos restaurada.
23057
La ubicación de la copia de seguridad no es válida.
23058
Ha fallado la copia de seguridad de DBCA. El código de retorno es
%RETURN_CODE%.
23059
Ha fallado la consulta de las propiedades %TC_DB% de base de datos.
23060
No existe el archivo ORACLE_HOME/rdbms/admin/utlirp.sql.
23061
Ha fallado el cambio del tamaño de palabras de la base de datos.
Recuperación de errores de la migración
Si se producen problemas cuando se ejecutan los scripts durante el proceso de
migración, utilice esta información detallada y los archivos de registro para la
recuperación de los mismos y continuar.
El proceso de migración intenta almacenar los registros en el directorio
TIO_LOGS/migration. Si el proceso no puede acceder a TIO_LOGS, los registros se
UNIX
/tmp o en el directorio Windows %TMP%.
almacenarán en el directorio
Registros de estado
Cuando se produzca un error, utilice los archivos de registro para identificar el
problema. Después de solucionar el problema, vuelva a ejecutar el script. Los
procesos que se han completado antes de que se produzca el error se marcan como
satisfactorios y se ignoran cuando vuelve a ejecutar el script. Un archivo de
registro de estado, TIO_LOGS/migration/<nombre_script>_status.log hace un
seguimiento de los procesos que se han completado.
Elimine o cambie el nombre de este registro de estado si está ejecutando otra vez el
script en una ventana de mantenimiento diferente. No desea que el script que está
ejecutando ahora lea el estado que se ha creado la última vez que ha ejecutado los
Capítulo 6. Recuperación de errores de la migración
265
scripts e ignore los procesos marcados como DONE.
Detalles de la recuperación de problemas durante la instalación
de 7.1.1
Tabla 68. Recuperación de problemas de instalación
Posibles razones de la anomalía
Pasos de recuperación
Instalación de middleware
1. Arregle manualmente las posibles razones de
la anomalía.
v Se ha producido un error de usuario al
especificar valores incorrectos en el instalador
de middleware
2. Restaure una imagen limpia del sistema
operativo en el sistema 7.1.1.
v El DN base especificado para un servidor
LDAP existente (utilizando la opción de
instalación avanzada del instalador de
middleware) no es válida o no existe en
LDAP.
3. Vuelva a ejecutar la instalación de
middleware.
Instalación de componentes principales
1. Si el middleware no se ha instalado
correctamente, restaure una imagen nueva
del sistema operativo en el sistema y vuelva
a comenzar desde el paso 2.
v El middleware no está instalado o no se ha
instalado correctamente.
v No se cumplen los requisitos mínimos de
hardware.
2. Si no se cumplen con los requisitos mínimos
de hardware, solucione el problema de
hardware y vuelva a ejecutar este paso.
Archivo de registro
Windows
C:\\ibm\tivoli\mwi\workspace\mwi.log
UNIX
/root/ibm/Tivoli/mwi/workspace/mwi.log
Windows
v %TIO_LOGS%\install
v %TIO_LOGS%\install_wrapper
v %TIO_LOGS%\initdb.log
UNIX
v $TIO_LOGS/install
v $TIO_LOGS/install_wrapper
v $TIO_LOGS/initdb.log
Preparación de los archivos binarios del
componente
v La aplicación de compresión de archivos no
está disponible en el sistema.
v Se ha producido un problema de permiso de
archivo en TIO_HOME cuando extraía el
archivo.
1. Instale una aplicación de compresión de
archivos en el sistema.
2. Asegúrese de que no ha iniciado la sesión
como el usuario root antes de extraer los
archivos.
3. Vuelva a completar este paso.
Detalles de la recuperación de problemas generados en el script
de copia de seguridad 5.1.1.2
Tabla 69. Archivos de registro y pasos de recuperación para problemas con el script tpm5112backup
Posibles razones de la anomalía
Pasos de recuperación
Preparación del archivo de exportación LDIF
1. Arregle manualmente las razones posibles de
la anomalía y luego vuelva a ejecutar el
scripttpm5112backup. Por ejemplo:
1. Acceso no válido a la base de datos de
suministro o el sistema de archivos (error de
permiso de archivo).
2. Se ha agotado el espacio de disco en el
servidor de suministro de 5.1.1.2.
3. En el servidor LDAP no está el usuario
LDAP, por ejemplo, installer, scanner o
approver.
v Escriba el nombre de usuario y la
contraseña de base de datos válidos.
v Cambie los permisos de archivo o de
directorio, de modo que se pueda
almacenar el archivo de salida.
v Aumente el espacio de disco donde está
instalado Tivoli Provisioning Manager.
v Si faltan los usuarios LDAP, añádalos
manualmente al servidor LDAP 5.1.1.2.
Por ejemplo, los usuarios installer,
approver y scanner.
Preparación del archivo para la configuración
del gestor de agentes y los certificados.
1. Credenciales de usuario de base de datos no
válidas
2. Permiso no válido para acceder al directorio
en el servidor de suministro 5.1.1.2
1. Arregle manualmente las razones posibles de
la anomalía y luego vuelva a ejecutar el
scripttpm5112backup. Por ejemplo:
v Escriba el nombre de usuario y la
contraseña de base de datos válidos.
v Cambie los permisos de archivo o de
directorio, de modo que se pueda
almacenar el archivo de salida.
Archivo de registro
Windows
TIO_LOGS\migration\ldapOSQuery.log
TIO_LOGS\migration\tpm511Backup.log
TIO_LOGS/ldapBackup.log
UNIX
TIO_LOGS/migration/ldapOSQuery.log
TIO_LOGS/migration/tpm511Backup.log
TIO_LOGS\ldapBackup.log
Windows
C:\Archivos de programa\ibm\Agent
Manager\logs\*Backup.log
UNIX
opt/ibm/Agent Manager/logs/*Backup.log
TIO_LOGS/migration/tpm511Backup.log
266
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 69. Archivos de registro y pasos de recuperación para problemas con el script tpm5112backup (continuación)
Posibles razones de la anomalía
Pasos de recuperación
Archivo de registro
Opcional: Elimine las entradas de la tabla de
auditoría
Windows
TIO_LOGS\migration\
tpm511Backup.log
UNIX
TIO_LOGS/migration/
tpm511Backup.log
Copia de seguridad de la base de datos Oracle
1. Credenciales de usuario de base de datos no
válidas
1. Arregle manualmente las razones posibles de
la anomalía y luego vuelva a ejecutar el
scripttpm5112backup. Por ejemplo:
2. El programa de utilidad DBCA de Oracle no
está instalado.
v Escriba el nombre de usuario y la
contraseña de base de datos válidos.
3. La base de datos no está en pausa.
v Instale el programa de utilidad DBCA de
Oracle.
4. No hay espacio de disco suficiente.
Windows
TIO_LOGS\migration\
tpm511Backup.log
UNIX
TIO_LOGS/migration/
tpm511Backup.log
v Detenga la base de datos y vuelva a
iniciarla.
v Aumente el espacio de tablas de la base
de datos.
v Aumente el espacio de disco del servidor
de bases de datos local.
Copia de seguridad de la base de datos DB2
1. Credenciales de usuario de base de datos no
válidas
2. No hay espacio de disco suficiente.
1. Arregle manualmente las razones posibles de
la anomalía y luego vuelva a ejecutar el
scripttpm5112backup. Por ejemplo:
v Escriba el nombre de usuario y la
contraseña de base de datos válidos.
Windows
TIO_LOGS\migration\
tpm511Backup.log
UNIX
TIO_LOGS/migration/
tpm511Backup.log
v Detenga la base de datos y vuelva a
iniciarla.
v Aumente el espacio de tablas de la base
de datos.
v Aumente el espacio de disco del servidor
de bases de datos local.
Copie todos los archivos de datos y
opcionalmente cree un archivo comprimido
1. La aplicación de compresión de datos no
está disponible en el sistema.
1. Arregle manualmente las razones posibles de
la anomalía y luego vuelva a ejecutar el
scripttpm5112backup. Por ejemplo:
Windows
TIO_LOGS\migration\
tpm511Backup.log
v Instale una aplicación de compresión de
archivos.
UNIX
TIO_LOGS/migration/
tpm511Backup.log
Capítulo 6. Recuperación de errores de la migración
267
Detalles de la recuperación de problemas generados en el script
de restauración
Tabla 70. Archivos de registro y pasos de recuperación para problemas con el script tpm711restore
Posibles razones de la anomalía
Pasos de recuperación
Desconecte la base de datos 7.1.1 local
Si se producen errores durante este paso en el
script:
1. Asegúrese de que se ha iniciado el servidor
de bases de datos.
2. Vuelva a intentar el mandato manualmente.
Archivo de registro
Windows
TIO_LOGS\migration\tpm711Restore.log
UNIX
TIO_LOGS/migration/tpm711Restore.log
v
Como el usuario
SYSADM de DB2 SYSADM (ctginst1 o
tioadmin)
db2 drop db MAXDB71
v
Oracle
2000
Ejecute como el usuario
oracle.
dbca -silent
-deleteDatabase
-sourceDB MAXDB71
-sysDBAPassword
contraseña
donde MAXDB71 y contraseña son los
valores del entorno local.
3. Asegúrese de que está utilizando un usuario
administrativo para desconectar la base de
datos.
Restaure la base de datos DB2 5.1.1.2 local
1. Las credenciales de base de datos de
suministro no son válidas.
2. Existe un nombre de base de datos
duplicado.
3. El nuevo nombre de esquema es incorrecto.
4. Ejecute la vía de acceso de directorio de
copia de seguridad especificada.
5. Falta espacio de disco en el sistema 7.1.1.
Si falla el mandato, se retrotraen los cambios de
base de datos. Arregle los problemas potenciales
y vuelva a ejecutar el script tpm711restore. Por
ejemplo,
1. Escriba las credenciales de base de datos
correctas.
Windows
TIO_LOGS\migration\tpm711Restore.log
UNIX
TIO_LOGS/migration/tpm711Restore.log
2. Ejecute el mandato para desconectar la base
de datos.
3. Aumente el espacio de disco en el sistema.
4. Inicie el servidor de bases de datos.
6. No se ha iniciado el servidor de bases de
datos.
Restaure la base de datos Oracle 5.1.1.2 local
1. Las credenciales de base de datos de
suministro no son válidas.
2. Existe un nombre de base de datos
duplicado.
3. El nuevo nombre de esquema es incorrecto.
4. Ejecute la vía de acceso de directorio de
copia de seguridad especificada.
1. Si falla la restauración de la base de datos,
se retrotraen los cambios de base de datos.
2. Si falla el paso de cambio de nombre del
esquema, restaure la base de datos 7.1.1 y
vuelva a ejecutar el scripttpm711restore.
3. Arregle los problemas potenciales y vuelva a
ejecutar el scripttpm711restore. Por ejemplo,
5. Falta espacio de disco en el sistema 7.1.1.
a. Escriba las credenciales de base de datos
correctas.
6. No se ha iniciado el servidor de bases de
datos.
b. Ejecute el mandato para desconectar la
base de datos.
7. Ha fallado el cambio de nombre del
esquema para que sea igual que en 7.1.1.
c. Aumente el espacio de disco en el
sistema.
Windows
TIO_LOGS\migration\tpm711Restore.log
UNIX
TIO_LOGS/migration/tpm711Restore.log
d. Inicie el servidor de bases de datos.
Restaure el GUID
Arregle el error de permisos de archivo y
vuelva a ejecutar el script tpm711restore.
Error de permisos de archivo.
Windows
TIO_LOGS\migration\tpm711Restore.log
UNIX
TIO_LOGS/migration/tpm711Restore.log
268
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Detalles de la recuperación de problemas generados en el script
de migración
Tabla 71. Archivos de registro y pasos de recuperación para problemas con el script tpm711migrate
Posibles razones de la anomalía
Pasos de recuperación
Migre los datos de suministro el esquema a
7.1.1
1. Arregle los problemas. Por ejemplo,
1. Las credenciales de base de datos no son
válidas.
Archivo de registro
a. Escriba las credenciales de base de datos
correctas.
2. Falta espacio de disco en 7.1.1 o en el
servidor de bases de datos.
b. Aumente el espacio de disco en el
sistema 7.1.1 o en el servidor de bases de
datos.
3. No se ha iniciado el servidor de bases de
datos.
c. Inicie el servidor de bases de datos.
4. Existe un problema de integridad de datos.
Por ejemplo, existen restricciones de base de
datos o hay datos dañados en un
componente específico.
5. Ha fallado la instalación o actualización de
un paquete de automatización.
d. Aumente el espacio de paginación de
base de datos.
Windows
v TIO_LOGS\migration\tpm711Migrate.log
v %TIO_LOGS%\tcdrivermanager.log
UNIX
v TIO_LOGS/migration/tpm711Migrate.log
v $TIO_LOGS/tcdrivermanager.log
2. Restaure la copia de seguridad de base de
datos 7.1.1.
3. Vuelva a ejecutar el script tpm711migrate.
6. La transacción es demasiado grande.
7. El espacio de paginación de base de datos es
demasiado pequeño.
Copia de seguridad de la base de datos
después de la migración
Falta espacio de disco.
Ignore el paso si ha fallado o arregle el
problema de espacio de disco y retrotraiga la
imagen de copia de seguridad de DB2 anterior.
Vuelva a ejecutar el script tpm711migrate.
Windows
TIO_LOGS\migration\tpm711Migrate.log
UNIX
TIO_LOGS/migration/tpm711Migrate.log
Instale y migre Common Agent Services
1. Un problema de configuración de
WebSphere Application Server.
2. Un problema de configuración de base de
datos.
3. Las credenciales de WebSphere Application
Server no son válidas.
Los problemas pueden ser debidos a que no se
Windows
han establecido correctamente los parámetros de
v TIO_LOGS\migration\tpm711Migrate.log
perfil de Common Agent Services definidos en
el archivo de respuestas. Cambie el valor del
v WAS_HOME\AppServer\profiles\casprofile\
archivo de propiedades y vuelva a ejecutar el
logs
script tpm711migrate.
v WAS_HOME\AppServer\logs\
manageProfiles\casprofile_create.log
4. El perfil de Common Agent Services y el
archivo de respuestas de instalación no se
han editado correctamente.
v TIO_LOGS/migration/tpm711Migrate.log
5. El gestor de agentes no se puede iniciar
debido a problemas de configuración.
v WAS_HOME/AppServer/profiles/casprofile/
logs
UNIX
v WAS_HOME/AppServer/logs/
manageProfiles/casprofile_create.log
Capítulo 6. Recuperación de errores de la migración
269
Tabla 71. Archivos de registro y pasos de recuperación para problemas con el script tpm711migrate (continuación)
Posibles razones de la anomalía
Pasos de recuperación
Registre el servidor de suministre en Common
Agent Services
1. Actualice manualmente los permisos para
que se puedan actualizar los archivos. La
contraseña puede ser una de las siguientes
contraseñas:
1. La contraseña del gestor de agentes es
incorrecta.
2. El archivo endpoint.properties no se ha
actualizado.
3. El archivo agentmanager.xml no se ha
actualizado.
4. El archivo de claves del agente no se ha
copiado debido a problemas de permisos.
5. No se puede sondear el agente.
v
Gestor de agentes:
La contraseña del gestor de agentes que se
ha utilizado en la versión 5.1.1.2.
v Registro de agente:
La contraseña del registro del gestor de
agentes que se ha utilizado en la versión
5.1.1.2.
v Gestor de recursos del gestor de agentes:
La contraseña para el nombre de usuario
del gestor de agentes para el gestor de
atentes.
Nota: El instalador de Tivoli Provisioning
Manager 5.1.1.2 crea la contraseña para
este usuario. La contraseña
predeterminada que crea el instalador es
password. Utilice esta contraseña a menos
que haya modificado la contraseña
después de la instalación de 5.1.1.2.
Archivo de registro
Windows
TIO_LOGS\migration\tpm711Migrate.log
WAS_HOME\AppServer\profiles\
casprofile\logs
WAS_HOME\AppServer\logs\
manageProfiles\casprofile_create.log
UNIX
TIO_LOGS/migration/tpm711Migrate.log
WAS_HOME/AppServer/profiles/
casprofile/logs
WAS_HOME/AppServer/logs/
manageProfiles/casprofile_create.log
2. Arregle los parámetros o los valores de los
archivos endpoint.properties o
agentmanager.xml.
3. Si falla el sondeo del gestor de agentes,
asegúrese de que se hayan configurado
correctamente los elementos siguientes:
v En el archivo TIO_HOME/config/
endpoint.properties,
agentManagerQuery.Port = 9513.
v En el archivo AgentManager.properties,
ARS.domainName =
your_company.example.com.
El archivo AgentManager.properties está en
opt/IBM/WebSphere/AppServer/profiles/
casprofile/installedApps/
jnptpmosNode01Cell/AgentManager.ear/
AgentManager.war/WEB-INF/classes/
resources.
4. Vuelva a ejecutar el script tpm711migrate.
Configuración de SSL
1. El certificado no es válido.
2. El usuario administrativo y la contraseña de
WebSphere Administrative Server son
incorrectos.
1. utilice un archivo de certificados correctos de
la copia de seguridad.
2. Utilice las credenciales administrativas de
WebSphere Administrative Server.
3. Vuelva a ejecutar el script tpm711migrate.
Windows
v TIO_LOGS\migration\tpm711Migrate.log
v TIO_LOGS/*.log
UNIX
v TIO_LOGS/migration/tpm711Migrate.log
v TIO_LOGS\*.log
270
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 71. Archivos de registro y pasos de recuperación para problemas con el script tpm711migrate (continuación)
Posibles razones de la anomalía
Pasos de recuperación
Archivo de registro
Instale y actualice Dynamic Content Delivery
1. Arregle los valores incorrectos.
1. Los valores de los parámetros del archivo de
respuestas o las propiedades temporales no
son correctos.
2. Vuelva a ejecutar el script tpm711migrate.
Windows
v TIO_LOGS\migration\tpm711Migrate.log
v TIO_LOGS\MC*.err
v TIO_LOGS\*.out
v TIO_LOGS\trace.log
v TIO_LOGS\trace_cdsmgr.log
v TIO_LOGS\trace_dcdconfig.log
v TIO_LOGS\trace_distribution.log
v TIO_LOGS\trace_manager_install.log
v TIO_LOGS\trace_monitoring.log
UNIX
v TIO_LOGS/migration/tpm711Migrate.log
v TIO_LOGS\MC*.err
v TIO_LOGS\*.out
v TIO_LOGS/trace.log
v TIO_LOGS/trace_cdsmgr.log
v TIO_LOGS/trace_dcdconfig.log
v TIO_LOGS/trace_distribution.log
v TIO_LOGS/trace_manager_install.log
v TIO_LOGS/trace_monitoring.log
Instale el servidor del gestor de dispositivos
1. Problemas relacionados con la base de datos.
Por ejemplo, un nombre de usuario y una
contraseña incorrectos.
1. Arregle los valores del archivo de
propiedades de configuración del servicio
del gestor de dispositivos o la plantilla del
archivo de respuestas.
2. Valores incorrectos en el archivo de
respuestas.
2. Restaure la base de datos a partir de la
versión de copia de seguridad anterior.
3. Propiedades de configuración del servicio
del gestor de dispositivos incorrectas.
3. Vuelva a ejecutar el script tpm711migrate.
Configure WebSphere Application Server para
que se inicie como tioadmin
Si la tarea falle, será necesario un arreglo
manual. Por ejemplo, si se ha configurado
WebSphere Application Server ND para que se
ejecute como tioadmin, pero existe un problema
cuando se cambia el permiso, arréglelo
manualmente y continúe en la acción siguiente.
No vuelva a ejecutar el script.
Mensajes al final de la migración
Aparece el siguiente mensaje:
COPUTL088E La migración ha fallado
durante la conversión del
valor de tamaño correspondiente a la
propiedad {0} para el recurso (id: {1}).
Los valores de las variables son:
{0}
memory.size o disk.size
{1}
El ID de objeto del modelo de datos
de un servidor de plataforma de
host.
Windows
v TIO_LOGS\migration\tpm711Migrate.log
v DMS_HOME\log
UNIX
v TIO_LOGS/migration/tpm711Migrate.log
v DMS_HOME\log
No se ha migrado correctamente un valor de
tamaño de memoria o de disco. Debe actualizar
el modelo de datos manualmente.
Para obtener el valor configurado actualmente:
1.
Windows
Abra una ventana de
mandatos de DB2.
Windows
TIO_LOGS\migration\tpm711Migrate.log
UNIX
TIO_LOGS/migration/tpm711Migrate.log
Windows
TIO_LOGS\migration\dataMigration.log
UNIX
TIO_LOGS/migration/dataMigration.log
2. Ejecute el mandato siguiente para obtener el
valor actual:
db2 select value from properties
donde properties_id={1}
Sustituya {1} por el ID de objeto en el
mensaje de error.
El valor devuelto no debe ser un valor
decimal.
3. Actualice el valor en el tamaño de disco o de
memoria correcto en bytes.
Capítulo 6. Recuperación de errores de la migración
271
Detalles de la recuperación de problemas generados durante las
actualizaciones del nombre de host.
Tabla 72. Archivos de registro y pasos de recuperación para problemas con los cambios de actualización del nombre
de host
Posibles razones de la anomalía
Pasos de recuperación
Cambie el nombre de host de base de datos
Consulte los archivos de registro. Cualquier
problema requiere un arreglo manual.
Archivo de registro
Windows
TIO_LOGS\migration\
tpm711ChangeDBHost.log
UNIX
TIO_LOGS/migration/
tpm711ChangeDBHost.log
Cambie los otros nombres de host
Windows
TIO_LOGS\migration\
tpm711ChangeOtherHost.log
UNIX
TIO_LOGS/migration/
tpm711ChangeOtherHost.log
Detalles de la recuperación de problemas generados en la
estación de trabajo administrativa
Tabla 73. Archivos de registro y pasos de recuperación para instalar servicios básicos y componentes web
Posibles razones de la anomalía
Pasos de recuperación
Archivo de registro
Instale los servicios básicos
Si falla la instalación, vuelva a ejecutar la
instalación de los servicios básicos.
Maximo_HOME\logs\
Instale los componentes Web
Si falla la instalación, vuelva a ejecutar la
instalación de los componentes web.
Maximo_HOME\logs\
Actualice el nombre de host en el archivo
maximo.property.
Si falla la configuración manual, vuelva a
intentarlo.
Detalles de recuperación de la migración de Tivoli Provisioning
Manager for OS Deployment con agentes
Tabla 74. Archivos de registro y pasos de recuperación para los problemas durante la migración de las imágenes de
Tivoli Provisioning Manager for OS Deployment
Posibles razones de la anomalía
Pasos de recuperación
Falla el descubrimiento del servidor de
arranque
Para obtener más información, consulte los
registros de flujo de trabajo de suministro en la
interfaz web de suministro.
Archivo de registro
Windows
%TIO_LOGS%\console.log
UNIX
$TIO_LOGS/console.log
Despliegue las imágenes nuevas
Si no se pueden volver a desplegar las imágenes
de Tivoli Provisioning Manager for OS
Deployment debido a problemas de
configuración, arregle los problemas e intente
volver a desplegar la imagen.
Actualice cada para de almacén y servicio de
gestor de dispositivos federados de 5.1.1.2 a
7.1.1
Siga los pasos de actualización para la
recuperación de cualquier error.
%TIO_LOGS%\console.log
Para obtener más información, consulte los
registros de flujo de trabajo de suministro en la
interfaz web de suministro.
272
Windows
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
UNIX
$TIO_LOGS/console.log
Tabla 74. Archivos de registro y pasos de recuperación para los problemas durante la migración de las imágenes de
Tivoli Provisioning Manager for OS Deployment (continuación)
Posibles razones de la anomalía
Pasos de recuperación
Archivo de registro
Actualice cada conjunto de puntos finales de
5.1.1.2 a 7.1.1
Siga los pasos de actualización para la
recuperación de cualquier error.
Registros de flujo de trabajo de suministro:
TIO_HOME/logs/console.log
Para obtener más información, consulte los
registros de flujo de trabajo de suministro en la
interfaz web de suministro.
Registros de punto final: /ep/logs
Detalles de la recuperación de tareas posteriores a la migración
Tabla 75. Archivos de registro y detalles de recuperación para tareas posteriores a la migración
Posibles razones de la anomalía
Pasos de recuperación
Migración de paquetes de automatización
Si falla este paso, el problema más probable es
que algunos paquetes de automatización no
están disponibles para la migración. Arregle los
problemas de los paquetes de automatización,
restaure la base de datos de suministro y vuelva
a ejecutar el script de actualización
mastertcdriver.
Este paso se activa cuando se inicia el servidor
de suministro por primera vez. Finaliza la
migración de los paquetes de automatización.
Archivo de registro
Windows
%TIO_LOGS%\console.log
UNIX
$TIO_LOGS/console.log
Para obtener más información, consulte los
registros de flujo de trabajo de suministro en la
interfaz web de suministro.
Restaure el contenido de LDAP
1. El archivo LDIF o el formato del archivo no
es válido.
2. El DN base definido no es válido.
3. La contraseña administrativa LDAP es
incorrecta.
Retrotraiga los cambios ejecutando el mandato
de importación de LDAP otra vez y si falla la
importación de LDAP falla debido a cualquiera
de los problemas especificados, arregle el
problema y vuelva a ejecutar el mandato
ldapmodify.cmd.
Migre los grupos de acceso de 5.1.1.2
Llame manualmente al flujo de trabajo de
suministro de TPM711Migration_Security.wrk.
Vuelva a crear los informes de extensión de
inventario de 5.1.1.2
Ejecute manualmente el script
InvExtReportRegenFrom5112
\idsslapd-idsccdmdb\logs
Error de creación de objeto
La coexistencia con Tivoli Configuration Manager no está soportada para la
migración a la versión 7.1.1. Cuando ejecuta el script de restauración durante la
migración, se producirán errores si se encuentran objetos creados para la
coexistencia con Tivoli Configuration Manager.
Síntomas
Cuando ejecuta el script tpm711restore, se produce el error siguiente:
SQL0438N La aplicación ha generado un error o un aviso con el texto de diagnóstico:
"Ha fallado la creación del objeto". SQLSTATE=78000
Causas
Este problema se produce debido a que los datos de copia de seguridad de 5.1.1.2
contienen vistas de base de datos y apodos obsoletos creados para la coexistencia
con Tivoli Configuration Manager.
Entorno
Este error se produce en Tivoli Provisioning Manager for Software o Tivoli
Provisioning Manager, que se ha configurado para la coexistencia de Tivoli
Provisioning Manager y utiliza la base de datos DB2.
Capítulo 6. Recuperación de errores de la migración
273
Resolución del problema
1. Desconéctese de los apodos y vistas de la base de datos DB2. Consulte el tema
“Eliminación de apodos y vistas” en la página 39 para conocer los pasos
detallados.
2. Cuando se desconecten los objetos, vuelva a realizar una copia de seguridad de
los datos 5.1.1.2:
v Base de datos remota: “Copia de seguridad de un servidor de bases de datos
remoto” en la página 179.
v Base de datos local y remota: “Copia de seguridad de Tivoli Provisioning
Manager 5.1.1.2” en la página 180
Recuerde: Dado que anteriormente ha ejecutado el script tpm5112backup,
debe eliminar o cambiar el nombre del archivo TIO_LOGS/migration/
tpm5112backup_status.log. Para obtener más información, consulte la sección
en “Registros de estado ” en la página 265.
3. Vuelva a ejecutar el script tpm711restore: “Restauración y migración de los
datos a 7.1.1” en la página 195
Objetos creados con los avisos de compilación durante la
restauración
La restauración de la base de datos Oracle crea objetos con avisos de compilación y
vistas no válidas.
Síntomas
Cuando se restaura la información de la base de datos Oracle 5.1.1.2 en el entorno
7.1.1, se producen avisos. Por ejemplo:
IMP-00041: Warning: object created with compilation warnings
"CREATE FORCE VIEW "MAXIMO"."SOFTWARE_PATCH_VIEW"
("ID","REBOOT","RESTART","COEXIST","APPROVED") AS "
"SELECT"
"
SOFTWARE_PATCH.software_patch_id,"
"
SOFTWARE_PATCH.reboot,"
"
SOFTWARE_PATCH.restart,"
"
SOFTWARE_PATCH.coexist,"
"
SP_APPROVED(SOFTWARE_PATCH.software_patch_status_id)"
"FROM"
"
SOFTWARE_PATCH"
...
Una vez finalizado el script de restauración de Oracle, algunas vistas del esquema
nuevo se marcan como as INVALID.
Causas
Es posible que existan varias razones por las que estos objetos tienen el aviso:
1. Los objetos no existen en la base de datos o los objetos están en el otro
esquema que existía en la base de datos de exportación pero no existen en la
base de datos de importación.
2. El usuario que está haciendo la restauración no tiene el acceso necesario a los
objetos.
3. Los objetos son dba_ views u otras tablas de diccionarios de datos.
Entorno
Estos problemas se pueden producir cuando se restaura la base de datos Oracle en
una base de datos 7.1.1 local o remota.
274
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Resolución del problema
Los objetos no válidos se deben volver a compilar después de restaurar la base de
datos.
1. Conecte con la base de datos como sysdba con SQLPLUS:
export ORACLE_SID=<NOMBRE_BD>
sqlplus / as sysdba
donde NOMBRE_BD es el nombre de la base de datos.
2. Ejecute la consulta siguiente para mostrar todos los objetos no válidos:
SELECT owner, object_name, object_type
FROM dba_objects
WHERE
status != 'VALID';
3. Recompile los objetos no válidos. Consulte la documentación de la base de
datos Oracle para ver los pasos detallados.
Se proporciona un script de ejemplo para recompilar todos los objetos no
válidos:
SET SERVEROUTPUT ON SIZE 1000000
BEGIN
FOR object IN ( SELECT owner,
object_name,
object_type
FROM
dba_objects
WHERE status != 'VALID')
LOOP
BEGIN
EXECUTE IMMEDIATE 'ALTER ' || object.object_type || ' ' || object.owner || '.' || object.object_name || ' COMPILE';
END;
END LOOP;
END;
/
Error al crear el usuario durante la restauración de Oracle
Se producen errores de usuarios duplicados cuando se restaura una base de datos
Oracle local o remota.
Síntomas
Se muestra un mensaje de error acerca de usuarios duplicados cuando se restaura
la información de la base de datos Oracle de 5.1.1.2 en el entorno 7.1.1.
ORA-01920: El nombre de usuario 'MDSYS' está en conflicto con otro nombre
de usuario o rol
Causas
Al final de la restauración de la base de datos, el script llama a ordinst.sql para
instalar y recompilar los objetos Oracle interMedia y Oracle Spatial. Los cuatro
usuarios que requieren los objetos Oracle interMedia y Oracle Spatial se crean
mediante ordinst.sql. Si estos usuarios existen en la base de datos, se producirá
este error.
Resolución del problema
El error se puede ignorar. Los usuarios ya existen, por lo tanto, los errores no
afectarán a nada.
Capítulo 6. Recuperación de errores de la migración
275
Error de nombre no definido durante la restauración
Cuando se ejecuta el script tpm711restore se genera un error debido a que el
nombre de esquema 5.1.1.2 es incorrecto.
Síntomas
Se producen los errores siguientes cuando se restauran los datos de 5.1.1.2 en el
servidor de suministro 7.1.1:
"Renaming database schema..."
"Copying database schema..."
DB20000I The SQL command completed successfully.
DB20000I
The SQL command completed successfully.
Warning: An exit code of 6 has been detected for the db2 command.
Since this is expected, the error code '23013' is ignored.
Return Status = 0
"Dropping original database schema..."
SQL0204N "DB2INST1" is an undefined name.
SQLSTATE=42704
Failed to drop original database schema
23007
[23007](E) DROP_AND_RESTORE_DB :
--- [tpm711restore.cmd:DROP_AND_RESTORE_DB]
ended with code 23007 at Mon 08/24/2009 12:15:05.93 --**************************************
*** End of [ tpm711restore.cmd ] ***
**************************************
Error in step DROP_AND_RESTORE_DB : [23007]
Causas
El nombre de esquema 5.1.1.2 es incorrecto. El valor del parámetro
dbOldSchemaName del archivo de propiedades no es correcto.
Resolución del problema
Escriba el nombre de esquema correcto en el archivo de propiedades.
1. En el servidor de suministro 7.1.1, vaya al directorio donde ha copiado los
archivos de copia de seguridad de 5.1.1.2.
2. En los archivos de copia de seguridad, abra el archivo TIO_HOME/config/
dcm.xml.
3. Busque la etiqueta <username>. El valor especificado en la etiqueta es el nombre
de esquema 5.1.1.2.
4. Escriba este valor para el parámetro dbOldSchemaName en el archivo de
propiedades.
v
Windows
tpmmigrate_win.properties
UNIX
tpmmigrate_unix.properties
v
5. Vuelva a ejecutar el script tpm711restore.
276
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
La instalación de Common Agent Services falla
Si falla la instalación durante la migración, es posible que el valor del puerto de
base de datos o la contraseña de base de datos sean incorrectos.
Síntomas
Cuando se ejecuta el script tpm711migrate se instala Common Agent Services. Si
falla la instalación y comprueba el archivo TIO_LOGS/migration/tpm711migrate.log,
éste le indicará que consulte el directorio /opt/IBM/AgentManager/logs.
Causas
Uno de los problemas comunes es un error de conexión de base de datos del que
se informa en el archivo AMPreinstallLog.txt. Es posible que vea el error
siguiente: error:
java.sql.SQLException: Excepción de E/S: el nuevo adaptador de red
no ha podido establecer la conexión
Resolución del problema
Compruebe que el valor dbPort del archivo de propiedades sea correcto.
1. Abra el archivo TIO_HOME/migration/scripts/tpm711migrate_unix.properties.
2. Busque el valor de dbPort y asegúrese de que sea correcto. Por ejemplo:
50005
1521
3. Si el valor de dbPort es correcto, es posible que la contraseña del usuario de
base de datos sea incorrecta. Las contraseñas incorrectas pueden generar errores
en otros lugares. Ejecute el script tpm711migrate y asegúrese de que la
contraseña del usuario de base de datos sea correcta.
Oracle
2000
La instalación de los servicios básicos falla
Si surgen problemas durante la instalación de los servicios básicos, consulte los
posibles problemas y pasos para la recuperación, de modo que pueda continuar
con la instalación.
Síntomas
La instalación de los servicios básicos falla.
Resolución del problema
1. Asegúrese de que los parámetros definidos en el archivo C:\ibm\SMP\etc\
install.properties son correctos.
2. Revise la información de resolución de problemas en el tema Problemas
durante la instalación de los servicios básicos en Tivoli Provisioning Manager
versión 7.1.1 Guía de determinación de problemas.
3. Utilice el programa de utilidadtaskrunner para configurar los servicios básicos
y para reanudar la instalación después de resolver los errores. Consulte el tema
denominado “Reanudar la instalación utilizando el programa de utilidad
taskrunner” en la página 278.
4. Si se producen problemas durante la ejecución del programa de utilidad
taskrunner para reanudar la instalación de los servicios básicos, restaure la
Capítulo 6. Recuperación de errores de la migración
277
copia de seguridad de la base de datos y de la aplicación que ha creado
después de migrar los datos. Para ver los pasos de restauración detallados,
consulte el tema Recuperación de problemas durante la instalación de los
servicios básicos en la publicación Tivoli Provisioning Manager Versión 7.1.1 Guía
de resolución de problemas.
Reanudar la instalación utilizando el programa de utilidad
taskrunner
Utilice el programa de utilidadtaskrunner para configurar los servicios básicos y
para iniciar la instalación después de resolver los errores.
Los valores de configuración que especifique se almacenarán en el archivo
Maximo_HOME\applications\maximo\properties\maximo.properties. Si no ha
utilizado el instalador de servicios básicos para realizar la configuración, puede
realizarla fuera del instalador de servicios básicos utilizando el programa de
utilidad taskrunner, situado en el directorio Maximo_HOME\scripts. Ejecute el
programa de utilidad taskrunner en la línea de mandatos y éste utilizará los
valores de configuración almacenados en el archivo maximo.properties para
configurar servicios básicos.
taskrunner CONTINUE <STOPONERROR|NOSTOPONERROR>
Nota:
v Si rearranca el sistema, no podrá utilizar el programa de utilidad taskrunner
para ejecutar los scripts de configuración, porque los almacenes de datos de
taskrunner no son persistentes. Si tiene previsto utilizar el programa de utilidad
taskrunner, no rearranque el sistema.
v Las contraseñas se cifran en maximo.properties durante el proceso de
instalación. Los datos cifrados se almacenan en una sección del archivo después
de la línea mxe.encrypted=true utilizando varios caracteres, incluidos los
símbolos y otros caracteres que no son alfanuméricos. Asegúrese de que no
modifica la sección cifrada del archivo. Una versión del archivo con la
contraseña sin cifrar se almacena en maximo.properties_orig en el mismo
directorio.
Importante: Realice una copia de seguridad del archivo maximo.properties_orig
sin cifrar fuera de la estructura de archivos del sistema. Si cambia la contraseña
del usuario de base de datos, deberá actualizar este archivo con la nueva
contraseña y, a continuación, crear un nuevo archivo maximo.properties cifrado.
Si falla la instalación, puede volver a ejecutar taskrunner después de resolver los
errores si se ha ejecutado con el parámetro STOPONERROR. El programa de
utilidad taskrunner reanudará la instalación en el punto donde se ha registrado la
última tarea completada satisfactoriamente en el intento anterior. Si ejecuta
taskrunner con el parámetro NOSTOPONERROR, taskrunner continuará a pesar
de los errores.
El cambio de los nombres de host falla en AIX con la base de datos
Oracle
Falla la ejecución del script para cambiar los nombres de host del entorno de
suministro.
Síntomas
278
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Se produce un error cuando se ejecuta el mandato tpm711ChangeOtherHost para
actualizar los nombres de host del servidor de directorios, WebSphere Application
Server, la infraestructura de distribución de software y Tivoli Provisioning Manager
for OS Deployment. Este error indica que se ha producido un problema en el paso
REGISTER_CDS.
Causas
Se utiliza WebSphere Application Server 6.1 con Tivoli Provisioning Manager 7.1.1.
Debido a un problema conocido, WebSphere Application Server no puede leer el
controlador JDBC de Oracle en la vía de acceso de Oracle. Si inicia la sesión en la
consola administrativa de WebSphere, verá que el archivo .jar realmente está allí.
Entorno
Este error sólo se produce en un servidor de suministro AIX con una base de datos
Oracle local.
Resolución del problema
Copie el controlador JDBC de Oracle en una ubicación diferente:
1. En el servidor de suministro, copie el archivo .jar desde
ORACLE_JDBC_DRIVER_PATH a un directorio que pueda leer tioadmin, por ejemplo,
la carpeta /tmp.
2. Inicie la sesión en la consola administrativa de WebSphere como wasadmin.
3. Vaya a Recursos → JDBC → Proveedores de JDBC → AgentJDBCProvider.
4. Cambie la Vía de acceso de clase por:
/tmp/ojdbc5.jar
/tmp/classes12.zip
5. Guarde los cambios.
6. Vuelva a ejecutar el mandato tpm711ChangeOtherHost: “Actualización de los
nombres de host restantes” en la página 222
Falta el paquete Solaris necesario
Síntomas
Al ejecutar el script tpm711migrate en una plataforma Solaris se devuelve el
mensaje siguiente:
Update DMS response file
Install DMS
/<user_name>/DMSInstaller/install.sh: /usr/ucb/whoami: not found
You must be root user to run this command.
Return code: 2
Causas
Falta un requisito previo del paquete Solaris denominado SUNWscpu en el servidor
de suministro 7.1.1. El mandato whoami se encuentra en el paquete Solaris.
Resolución del problema
1. Instale el paquete SUNWscpu de Solaris que falta en el servidor de suministro
7.1.1. Para descargar los paquetes de Solaris, consulte http://
pkg.opensolaris.org/release/en/index.shtml.
Capítulo 6. Recuperación de errores de la migración
279
2. Vuelva a ejecutar el script tpm711migrate. El script continuará desde el punto
en que ha fallado en la última ejecución.
Errores de autenticación tras la migración
Si no se configuran correctamente los nombres de usuario y las contraseñas, se
pueden producir errores cuando se ejecutan los flujos de trabajo de suministro y
las tareas de suministro después de la migración.
Síntomas
Los errores de autenticación se producen cuando realiza operaciones de suministro
después de la migración
Causas
Los nombres de usuario y las contraseñas que se utilizaban en el servidor de
suministro y otros sistemas del entorno 5.1.1.2 se deben utilizar en el entorno de
suministro 7.1.1 después de la migración.
Resolución del problema
Cambie los nombres de usuario y las contraseñas de los sistemas del entorno 7.1.1,
de modo que coincidan con el valor que se ha utilizado en el entorno 5.1.1.2.
Vuelva a ejecutar la operación de suministro.
280
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Capítulo 7. Consulta
Este capítulo contiene la información de referencia que puede ayudarle en el
proceso de migración.
Correlación del objeto de modelo de datos y la aplicación
Los objetos de modelo de datos de suministro se asocian a las aplicaciones en la
interfaz web. Utilice esta tabla como una vista rápida para la correlación entre los
objetos de datos y las aplicaciones.
Tabla 76. Aplicaciones para los objetos de modelo de datos asociados
© Copyright IBM Corp. 2009
Objeto de modelo de datos
Nombre de aplicación
Plan de actividades
Definición de tarea de
suministro
TPTASKINV
Instancia del plan de
actividades
Seguimiento de tarea de
suministro
TPTASK
Clústeres
Dominios de clúster
TPCLUSTER
Sistemas
Sistemas de suministro
TPSERVERS
Conmutadores
Conmutadores
TPSWITCHS
Equilibradores de carga
Equilibradores de carga
TPLDBAL
Agrupaciones de recursos
Agrupaciones de recursos
TPRESPOOL
Subredes
Subredes
TPSUBNETS
VLANS
Redes LAN virtuales
TPVLANS
Clientes
Clientes de suministro
TPCUST
Controladores de dispositivo
Controladores de dispositivo
TPDEVMOD
Repositorios de archivos
Repositorios de archivos
TPFILEREP
Unidades de alimentación
Unidades de alimentación
TPPOWERU
Servidores de arranque
Servidores de arranque
TPBOOTSRV
SAN
Redes de área de
almacenamiento
TPSAN
Servidores de terminal
Servidores de terminal
TPTERMSRV
Pilas de software
Pilas de software
TPSTACK
Servidor de administración
Blade
Servidores Blade
TPBLADE
Listas de control de accesos
Listas de control de accesos
TPACL
Parches de software
Parches
TPSWPATCH
Configuraciones de
descubrimiento
Configuraciones de
descubrimiento
TPDISC
Dispositivos IP
(desconocidos)
Recursos desconocidos
TPUNKRSRC
Plantillas de servidor Virtual
Plantillas de servidor virtual
TPVST
Gestores de almacenamiento
(o gestores de volúmenes)
Gestores de almacenamiento
TPSTGMGR
281
Tabla 76. Aplicaciones para los objetos de modelo de datos asociados (continuación)
Objeto de modelo de datos
Nombre de aplicación
Agrupaciones de asignación
de almacenamiento
Agrupaciones de
almacenamiento
TPSTPOOL
Subsistemas de
almacenamiento
Subsistemas de
almacenamiento
TPSTSUBST
Plantillas de sistema
Plantillas de sistema
TPCMPTMPL
Definiciones de software
Productos de software
TPSOFTWARE
Imágenes
Imágenes
TPIMAGE
Dominios de clúster
Dominios de clúster
TPCLSTDMN
Plantillas de almacenamiento Plantillas de almacenamiento TPSTGTMPL
Recursos de software
Signaturas de software
TPSWRES
Instalaciones de software
Productos de software
TPSWRES
Instancias de software
Productos de software
TPSWRES
Configuraciones de software
Productos de software
TPSWRES
Datos de aplicación de
software
Productos de software
TPSWRES
Grupos
Grupos de suministro
TPGROUP
Grupos de sistemas
Grupos de suministro
TPGROUP
Gestión de Dynamic Content Configuración de Dynamic
Content Delivery
Delivery (objetos que
representa)
TPMDCD
Variables de vía de acceso
Esta documentación utiliza las siguientes variables para representar las vías de
acceso de los directorios de instalación. En algunos casos, el nombre de la variable
coincide con una variable de entorno establecida en el sistema operativo. Por
ejemplo, TIO_HOME representa la variable de entorno $TIO_HOME en UNIX y
Linux, y %TIO_HOME% en Windows. En otros casos se utiliza la variable sólo en
la documentación para representar la vía de acceso del directorio.
Tabla 77. Variables de vía de acceso
Variable de vía de acceso
Componente
AM_HOME
El gestor de agentes
APDE_HOME
Automation Package
Developer Environment
DB2_HOME
DB2
Directorio predeterminado
v
Windows
v
UNIX
C:\Archivos de programa\IBM\AgentManager
Linux
/opt/IBM/AgentManager
Definida por el usuario
v
Windows
Unidad_sistema:\Archivos de programa\IBM\SQLLIB
v
AIX
/opt/IBM/db2/V9.5
v
Linux
/opt/ibm/db2/V9.5
v
Linux
en IBM System z: /opt/IBM/db2/V9.5
Unidad_sistema es el disco que contiene los archivos específicos del hardware
utilizados para iniciar Windows. Generalmente, la unidad del sistema es C.
ECLIPSE_HOME
282
Eclipse
Definida por el usuario
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Tabla 77. Variables de vía de acceso (continuación)
Variable de vía de acceso
Componente
Directorio predeterminado
JAVA_HOME
Java Runtime Environment.
Definida por el usuario
ORACLE_HOME
Oracle Database
$ORACLE_BASE/product/versión/db_1
El valor de $ORACLE_BASE es el directorio en el que se ha instalado todo el software de
Oracle Database.
v
UNIX
Linux
/u01/app/oracle/product/10.2.0/db_1 (para Oracle
UNIX
Linux
/u01/app/oracle/product/11.1.0/db_1 (para Oracle
10g)
v
11g)
TCA_HOME
WAS_HOME
agente común
WebSphere Application
Server
v
AIX
/usr/tivoli/ep
v
Linux
/opt/tivoli/ep
v
Windows
C:\Archivos de programa\tivoli\ep
v
Windows
C:\Archivos de programa\IBM\WebSphere\AppServer
v
AIX
Linux
v
HTTP_HOME
IBM HTTP Server
v
Windows
v
AIX
TIO_HOME
Tivoli Directory Server
v
Windows
v
UNIX
v
Windows
v
UNIX
Tivoli Provisioning Manager
/opt/IBM/WebSphere/AppServer
C:\Archivos de programa\IBM\HTTPServer
/usr/IBM/HTTPServer
Linux
v
TDS_HOME
/usr/IBM/WebSphere/AppServer
/opt/IBM/HTTPServer
C:\Archivos de programa\IBM\LDAP\V6.2
Linux
/opt/IBM/ldap/V6.2
C:\Archivos de programa\IBM\tivoli\tpm
Linux
/opt/IBM/tivoli/tpm
Nota: Dynamic Content Delivery y el servicio de gestor de dispositivos también se
instalan en subdirectorios de esta vía de acceso.
TIO_LOGS
Maximo_HOME
%TEMP%
Registros en tiempo de
ejecución de Tivoli
Provisioning Manager
v
Windows
v
UNIX
Linux
v
Windows
C:\ibm\SMP
v
UNIX
Linux
servicios básicos
Directorio de Windows para
los archivos temporales
C:\Archivos de programa\IBM\tivoli\common\COP\logs
/usr/ibm/tivoli/common/COP/logs
/opt/IBM/SMP
Cuando se ha iniciado la sesión como Administrador, C:\Documents and
Settings\Administrador\Configuración local\Temp
Capítulo 7. Consulta
283
284
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Índice
A
actualización del GUID
en Solaris 242
actualizaciones
agente común 26
paquetes de automatización 224
Tivoli Directory Server 30
versión 5.1.1.2 25
agente común
actualización antes de la
migración 26
autenticación del sistema operativo
migración a 7.1.1 20
B
Base de datos de Oracle 110
error durante la restauración de los
datos 274
errores
cambio del nombre de host en
AIX 278
creación de usuarios 275
instalación
cliente en AIX, Linux y
Solaris 109
visión general 106
planificación de la migración 19
Base de datos de Oracle. 111
binarios de software
restauración después de la
migración 250
C
configuración de SSL
con IBM HTTP Server 237
conformidad
migración de las comprobaciones y
exploraciones 250
volver a crear las recomendaciones
posteriores a la migración 250
contraseñas
actualización después de la
migración 229
necesaria para la migración 18
reglas 61
copias de seguridad
base de datos
antes de la instalación de los
servicios básicos 198
posteriores a la migración 231
Configuración de WebSphere
Application Server
antes de la instalación de los
servicios básicos 198
datos 5.1.1.2 181
estación de trabajo
administrativa 235
paquetes de automatización 34
© Copyright IBM Corp. 2009
copias de seguridad (continuación)
repositorios de archivos 37
servidor de bases de datos
remoto 179
servidor de suministro de 5.1.1.2
visión general 175
servidor LDAP 29
H
D
I
DB2
creación de vías de acceso para
7.1.1 191
instalación de los fixpacks 129
instalación de middleware 83
planificación de la migración 19
reutilización para la nueva
instalación 99
directorios
predeterminada 282
E
Error de creación de objeto 273
error de instalación de Common Agent
Services 277
errores
códigos de retorno para la
migración 255
Common Agent Services 250
creación de usuario de la base de
datos Oracle 275
Errores de autenticación durante la
migración 280
esquema de base de datos 276
migración 255
nombre de host para la base de datos
Oracle 278
estación de trabajo administrativa
copia de seguridad 235
topología de varios servidores 11
extensiones de inventario
migración 253
F
FIPS
migración a 7.1.1
15
G
grupos de acceso
migración a 7.1.1
grupos dinámicos
migración 231
GUID de TADDM
migración 246
hardware
requisitos de instalación 55
requisitos de migración 17
herramienta de administración web
instalación 229
imágenes
recapturar 244
informes
Alphablox 251
cambios para 7.1.1 252
exportación de consultas antiguas 36
herramienta de generación de
informes BIRT 251
volver a crear informes
personalizados 251
instalación 73
Cliente de Oracle Database 109
componentes principales
Tivoli Monitoring Agent 144
Tivoli Provisioning Manager for
OS Deployment 144
componentes principales de Tivoli
Provisioning Manager 7.1.1 144
DB2 99
Microsoft Active Directory 116
middleware
para la migración 73
Oracle Database 106
reglas
contraseñas 61
nombres de usuario 61
reiniciar 278
requisitos del sistema operativo 43
requisitos para componentes 53
requisitos para los navegadores 55
requisitos previos
hardware 55
productos de software 83
servicios básicos para la migración de
7.1.1 199
tareas posteriores a la instalación para
la migración 235
topologías soportadas 11
instalación en UNIX y Linux
paquetes necesarios 48
L
230
Launchpad
iniciar 71
listas de comprobación
migración 6
planificación de la migración 4
posteriores a la migración 8
premigración 4
285
M
mapa para la migración 4
Microsoft Active Directory
copia de seguridad antes de la
migración 29
creación de usuarios 117
instalación 116
middleware 73
comprobación del estado para la
migración 184
detener 214
inicio en UNIX y Linux 188
inicio en Windows 186
instalación 83
migración 244
actualización a la versión 5.1.1.2 25
actualizaciones de nombre de host
para 7.1.1 218
archivo de propiedades
valores de parámetros 155
archivos binarios de software 250
códigos de retorno 255
Coexistencia con Tivoli Configuration
Manager 15
Componentes web
instalación 216
conformidad 250
creación de vías de acceso de DB2
para 7.1.1 191
descarga de los archivos de
migración 190
entorno de prueba 24
error de nombre de host para la base
de datos Oracle 278
errores
Base de datos de Oracle 275
esquema de base de datos 276
instalación de servicios
básicos 277
recuperar 255, 265
estación de trabajo administrativa
instalación de servicios
básicos 199
planificar 11
finalización de la validación 225
FIPS 15
grupos dinámicos 231
GUID de TADDM 246
hardware necesario 17
información de consulta 281
informes
cambios en los informes
5.1.1.2 252
exportar consulta 252
herramienta de generación de
informes BIRT 251
volver a crear 251
infraestructura de distribución
escalable
preparación de las imágenes 28
iniciación
acceso a los archivos de
migración 190
herramientas de copia de
seguridad 5.1.1.2 29
instalación de la versión 7.1.1 40
componentes principales 144
286
migración (continuación)
instalación de la versión 7.1.1
(continuación)
imágenes de DVD 27
lista de comprobación del
entorno 64
max71db 142
requisitos de componentes 41
servicios básicos y componentes
web 199
usuario Maximo 142
validación 154
LDAP
actualización de Tivoli Directory
Server 30
autenticación del sistema
operativo 20
casos de ejemplo soportados 15
copia de seguridad 29
local 20
planificar 20
remota 20
Requisitos de configuración de
Tivoli Directory Server 30
restauración de la información de
usuario 226
reutilización de Microsoft Active
Directory 123
reutilización de Tivoli Directory
Server 101
tareas previas a la migración para
Tivoli Directory Server 30
VMMSync 230
listas de comprobación
migración 6
planificar 4
posteriores a la migración 8
premigración 4
Microsoft Active Directory 117
middleware
detener 214
iniciar 184
inicio en UNIX y Linux 188
inicio en Windows 186
nombres de usuario
reglas 61
paquetes de automatización
Automation Package Developer
Environment 15
cambios en 32
copia de seguridad 34
planes de actividades 254
planificar 11
Plataformas soportadas y
compatibilidad 15
tareas previas a la migración 25
posteriores a la migración 235
registros
detalles de errores 265
registro de estado 265
repositorios de archivos
copia de seguridad 37
restaurar 250
requisitos previos
actualizar el agente común 26
cambios en los paquetes de
automatización 32
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
migración (continuación)
requisitos previos (continuación)
completar el archivo de
propiedades 155
inhabilitación de los planes de
actividades y tareas 177
instalación de la versión 7.1.1 40
requisitos previos del agente
común 26
restauración de los datos 5.1.1.2
visión general 183
roles 244
scripts
migrar datos a 7.1.1 195
parámetros para el sistema
7.1.1 165
servidor de suministro de
5.1.1.2 160
tpm711migrate 195
tpm711restore 195
valores de parámetros 155
servidor de bases de datos
actualización del nombre de
host 221
copia de seguridad 5.1.1.2 181
copia de seguridad después de la
migración 231
restaurar la base de datos
local 195
restaurar la base de datos
remota 192
servidor de suministro
detención de 5.1.1.2 en UNIX 178
detención de 5.1.1.2 en
Windows 178
finalización de las tareas de
migración 224
inicio de 7.1.1 224
tareas de migración 5.1.1.2 175
tareas de migración 7.1.1 182
sincronización de usuarios y
grupos 230
Sistemas operativos soportados 15
tareas de puntos finales 254
Tareas posteriores a la
instalación 235
Tivoli Configuration Manager
eliminar apodos y vistas 39
Tivoli Intelligent Orchestrator 15
Tivoli Provisioning Manager for OS
Deployment
imágenes 37
Tivoli Provisioning Manager for
Software 15
visión general 1
cambios entre versiones 3
mapa 4
WebSphere Application Server
restaurar la configuración
5.1.1.2 243
N
nombres de host
migración
componentes 222
servidor de bases de datos
221
nombres de host (continuación)
migración (continuación)
servidor de suministro 218
nombres de usuario
reglas 61
O
objetos de modelo de datos
aplicaciones 281
OPAL
descarga de paquetes de
automatización 248
Oracle Database
instalación 106
instalación del cliente 109
P
paquetes de automatización
actualización después de la
migración 224
Automation Package Developer
Environment 15
copia de seguridad 34
descarga desde OPAL 248
inventario antes de la migración 35
migración 34
restauración y eliminación después de
la migración 248
verificación de las versiones 35
perfil de usuario MAXADMIN
Microsoft Active Directory 117
planes de actividades
migración 254
posteriores a la migración
volver a crear informes
personalizados 251
R
registros
migración 255
repositorios de archivos
copia de seguridad 37
restaurar 250
requisitos de componentes
instalación 53
sistema operativo 43
requisitos de paquetes
para UNIX y Linux 48
requisitos del navegador
instalación 55
requisitos previos
actualización de Tivoli Directory
Server 30
configurar Tivoli Directory Server 30
imágenes de Tivoli Provisioning
Manager for OS Deployment 37
Solaris 279
resolución de problemas
Error de creación de usuario de la
base de datos Oracle 275
errores de autenticación 280
errores de esquema de base de
datos 276
resolución de problemas (continuación)
errores de migración 255
instalación de servicios básicos 277
S
scripts
para destinos Windows 160
para la migración de UNIX 160
servicios básicos
instalación para la migración de
7.1.1 199
servidor de bases de datos
nombres de instancia 61
planificación remota o local 19
topología de varios servidores 11
vías de acceso de DB2 para 7.1.1 191
servidor de suministro
configuración para la integración 243
topología de varios servidores 11
servidor LDAP
migración
contraseñas 229
planificar 20
restauración de la información de
usuario 226
sincronización de usuarios 230
topología de varios servidores 11
Solaris
actualización del GUID 242
paquetes necesarios 279
SSL
configuración con IBM HTTP
Server 237
importación del certificado para
VMware 247
Tivoli Provisioning Manager for Software
migración 15
topologías
soportadas para la instalación 11
U
usuarios
Microsoft Active Directory
117
V
variables de vía de acceso 282
verificación de la instalación 110
VMware
importación del certificado SSL
247
W
WebSphere Application Server
instalación de middleware 83
restauración de la configuración
5.1.1.2 después de la migración
243
T
tareas de puntos finales
migración 254
taskrunner
reiniciar la instalación 278
Tivoli Configuration Manager
eliminar apodos y vistas 39
Tivoli Directory Server
actualización antes de la
migración 30
configurar usuarios para WebSphere
Application Server 6.1 30
contraseñas 229
copia de seguridad antes de la
migración 29
instalación de middleware 83
reutilización para la migración 101
Tivoli Intelligent Orchestrator
migración 15
Tivoli Monitoring Agent
utilización 238
Tivoli Provisioning Manager for OS
Deployment
instalación para la migración 144
migración de imágenes 37
volver a crear las imágenes para la
migración 244
Índice
287
288
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Avisos
Esta información se ha desarrollado para productos y servicios que se ofrecen en
EE.UU., es posible que IBM no ofrezca en otros países los productos, servicios o
características descritos en este documento. Póngase en contacto con el
representante local de IBM para obtener información sobre los productos y
servicios actualmente disponibles en su área. Cualquier referencia a un producto,
programa o servicio de IBM no pretende afirmar ni implicar que sólo se pueda
utilizar dicho producto, programa o servicio de IBM. Se puede utilizar cualquier
producto, programa o servicio equivalente funcionalmente que no infrinja el
derecho de propiedad intelectual de IBM. Sin embargo, es responsabilidad del
cliente evaluar y verificar el funcionamiento de cualquier producto, programa o
servicio que no sea de IBM.
IBM puede tener patentes o solicitudes de patentes pendientes que cubran el tema
principal descrito en este documento. La adquisición de este documento no le
concede ninguna licencia sobre estas patentes. Puede enviar consultas sobre
licencias, por escrito, a:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
EE.UU.
Para consultas sobre licencias relacionadas con información de doble byte (DBCS),
póngase en contacto con el Departamento de propiedad intelectual de IBM de su
país o envíelas por escrito a:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
3-2-12, Roppongi, Minato-ku, Tokio 106-8711
El párrafo siguiente no se aplica al Reino Unido u otros países en los que dichas
provisiones no sean coherentes con la ley local:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA
ESTA PUBLICACIÓN ″TAL CUAL″ SIN NINGÚN TIPO DE GARANTÍA,
EXPLÍCITA NI IMPLÍCITA, INCLUIDAS PERO SIN LIMITARSE A LAS
GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, COMERCIALIZACIÓN O
IDONEIDAD PARA UN PROPÓSITO DETERMINADO.
Algunos estados no permiten la renuncia a las garantías explícitas ni implícitas en
determinadas transacciones por lo que es posible que esta declaración no se
aplique en su caso.
Esta información puede incluir imprecisiones técnicas o errores tipográficos.
Periódicamente se efectúan cambios en la información aquí contenida; estos
cambios se incorporarán en nuevas ediciones de la publicación. IBM puede mejorar
o modificar los productos o programas descritos en esta publicación sin previo
aviso en cualquier momento.
© Copyright IBM Corp. 2009
289
Cualquier referencia a sitios web que no sean de IBM se proporciona únicamente
por comodidad y no actúa de ningún modo como promoción de dichos sitios web.
El material de estos sitios web no forma parte de este producto de IBM, por lo que
usted es responsable de los riesgos del uso de estos sitios web.
IBM puede utilizar o distribuir la información que proporcione el cliente de la
forma que considere conveniente sin incurrir en ninguna obligación con respecto
éste.
Los usuarios bajo licencia de este programa que deseen tener información sobre el
mismo para fines de habilitar: (i) el intercambio de información entre programas
creados independientemente y otros programas (incluido este) y (ii) el uso mutuo
de la información que se ha intercambiado, deben ponerse en contacto con:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758
EE.UU.
Dicha información puede estar disponible, según los términos y condiciones
adecuados, incluido en algunos casos el abono de una cuota.
IBM proporciona el programa bajo licencia descrito en este documento y todo el
material bajo licencia disponible para éste bajo los términos de las Condiciones
generales de IBM, el Acuerdo Internacional de Programas bajo Licencia de IBM o
cualquier acuerdo equivalente entre las partes.
La información sobre los productos que no son de IBM se ha obtenido de los
proveedores de esos productos, los anuncios publicados u otras fuentes disponibles
para el público. IBM no ha probado estos productos y no puede confirmar la
precisión del rendimiento, la compatibilidad u otros aspectos relacionados con los
productos que no son de IBM. Las preguntas sobre las capacidades de los
productos que no son de IBM deben dirigirse a los proveedores de dichos
productos.
Marcas registradas
IBM, el logotipo de IBM e ibm.com son marcas registradas de International
Business Machines Corporation en Estados Unidos o en otros países. Si estos
términos y otros términos que son marcas registradas de IBM están indicados con
un símbolo de marca registrada (® o ™), la primera vez en que aparecen en esta
información, tales símbolos indican marcas comerciales registradas en Estados
Unidos o marcas comerciales bajo derecho consuetudinario propiedad de IBM en el
momento de la publicación de esta información. Dichas marcas registradas también
pueden ser marcas registradas o de uso común en otros países. En la página web
″Copyright and trademark information″ (Información de copyright y marcas
registradas), en la dirección http://www.ibm.com/legal/copytrade.shtml está
disponible la lista actual de marcas registradas de IBM.
Intel® y Pentium® son marcas registradas o marcas comerciales registradas de Intel
Corporation o de sus subsidiarias en Estados Unidos o en otros países.
ITIL® es una marca registrada y una marca comunitaria registrada de la Oficina de
Comercio Gubernamental (Office of Government Commerce) y está registrada en la
Oficina de Patentes y Marcas de EE.UU.
290
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Linux es una marca registrada de Linus Torvalds en Estados Unidos o en otros
países.
UNIX es una marca registrada de The Open Group en Estados Unidos y en otros
países.
Microsoft, Windows y Windows NT® son marcas registradas de Microsoft
Corporation en Estados Unidos o en otros países.
Adobe® es una marca registrada de Adobe Systems Incorporated en Estados
Unidos o en otros países.
Java y todas las marcas registradas basadas en Java son marcas registradas de Sun
Microsystems, Inc. en Estados Unidos o en otros países.
UNIX es una marca registrada de The Open Group en Estados Unidos y en otros
países.
Otros nombres de empresas, productos y servicios son marcas registradas de
terceros.
Avisos
291
292
IBM Tivoli Provisioning Manager Versión 7.1.1 Guía de migración
Impreso en España
