Instalaremos OEM 12C sobre un nodo que previamente había sido parte de un cluster oracle 10g, intentaremos que funcione sobre un portátil (3Gb, 2 cores) virtualizado con virtualbox.
Reutilización de la ip 192.168.0.115 de antigua instalación de OEM Grid Control, así toda la monitorización estaría funcionando hasta el último momento hasta hacer el switch por la nueva.
Se seguirá la guía:
http://www.oracle-base.com/articles/12c/CloudControl12cR1InstallationOnOracleLinux5And6.php
En la creación dbca de una instancia para oem_12c, aparece el error:
ORA-29702: error occurred in Cluster Group Service operation
Se borró el directorio /u01/app/11.2.0/grid después de lanzar el “deinstall -local (que no terminó correctamente)”
Ver enlace:
http://blog.contractoracle.com/2009/08/ora-29702-error-occurred-in-cluster.html
"
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk rac_off
make -f ins_rdbms.mk ioracle
"
Se intenta en nuestro nodo, pero con el siguiente mensaje:
/usr/bin/ld: /u01/app/oracle/product/11.2.0/dbhome_1/lib//libctx11.a(drud.o): don't know how to handle section `' [0x 100]
/u01/app/oracle/product/11.2.0/dbhome_1/lib//libctx11.a: could not read symbols: File format not recognized
collect2: ld devolvió el estado de salida 1
make: *** [/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/oracle] Error 1
Se intenta una vez mas el 18/12/2011, con usuario oracle, ubicados en el directorio, y todo correcto, se crean los ejecutables oracle en $ORACLE_HOME/bin y el dbca parece que funciona bien.
Ampliación de espacio para dar cabida a instalación oracle_12c, se añade otro disco de 20GB (dinámico) a la máquina virtualbox y se aplican comandos típicos LVM:
vgdisplay --verbose
fdisk /dev/sdb (n, p, 1, intro, intro, t, 8e (partición Linux VM), w)
partprobe /dev/sdb (para crear el dispositivo /dev/sdb1)
pvcreate /dev/sdb1
vgextend VolGroup00 /dev/sdb1
lvextend -L +10G /dev/VolGroup00/LogVol00
resize2fs /dev/VolGroup00/LogVol00
[root@linux2 software]# df -k
S.ficheros Bloques de 1K Usado Dispon Uso% Montado en
/dev/mapper/VolGroup00-LogVol00
27424956 10867584 15141924 42% /
/dev/sda1 101086 19928 75939 21% /boot
tmpfs 764684 0 764684 0% /dev/shm
Nos quedan 15Gb libres (dejamos 10Gb reservados sin asignar al logVol00 para controlar)
Ahora pasamos los ficheros em12_linux64_disk1of2.zip y em12_linux64_disk2of2.zip al directorio /u01/software
Seguimos las instrucciones de http://www.oracle-base.com/articles/12c/CloudControl12cR1InstallationOnOracleLinux5And6.php
Nombre de host, cuidado al cambiar valores en /etc/hosts ya que se debe reiniciar el instalador para que coja la nueva configuración de /etc/hosts:
Debe quedar así:
127.0.0.1 linux2.localdomain linux2
Password administrador: .... (requiere al menos 8 caracteres, siendo 1 numérico)
Datos conexión bbdd: 192.168.0.115 / 1521 / em12c
Revisión instalación, puertos:
Se reciben errores en la parte de configuración que pueden estar relacionados con la lentitud general de la VB, copiamos la VM a otro sistema (Quad-core, 8GB) para ver si conseguimos la instalación completa.
Se cambian las rutas del fichero .vbox para que pueda arrancar correctamente desde otra ubicación.
Se le amplia la memoria de la máquina virtual de 1,5Gb a 4Gb y las cpus de 2 a 4, el almacenamiento ahora es local al servidor y no está montado en un HD USB (antes en el portátil estaba en un HD USB).
Se elimina instalación anterior (directorios y entradas en oraInventory/ContentsXML/inventory.xml) incluida las antiguas entradas de RAC:
Falla el arranque del listener debido a que quiere notificar a CRS (antigua instalación y no existe), se ve en el listener.log:
“Listener completed notification to CRS on start”
Se arranca correctamente metiendo la siguiente linea en el listener.ora:
SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF.
Gestión de Xs remotas a través de Xming , para ello, en el servidor:
export DISPLAY=192.168.0.197:1.0 (192.168.0.197 es el portátil desde el que lanzaremos la instalación, que se realiza sobre el servidor ubuntu)
Se debe borrar también el esquema SYSMAN_MDS:
<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <HostBasedeDatos> <PuertoListener> <SID/NombreServicio> -action dropall -dbUser <UsuarioBD> -dbPassword <Contraseña BD> -dbRole <Rol Usuario BD> -reposName <Nombre Repositorio> -reposPassword <ContraseñaRepositorio> -mwHome <MW HOME> -mwOraHome <MW ORA HOME> -oracleHome <ORACLE_HOME>
No conseguimos borrar con este comando, se borran manualmente los usuarios sysman_*, mgmt_view, los sinónimos publicos que apuntaban a ellos.
Una vez se lanza de nuevo el installer:
Fallo en “MDS Schema Configuration”, el los logs aparece:
RCU-6016:Ya existe el prefijo especificado.
RCU-6091:Fallo de validación de prefijo de esquema/nombre de componente.
para corregirlo, se lanza:
“delete from SCHEMA_VERSION_REGISTRY where COMP_NAME='Metadata Services';”,
según post: https://forums.oracle.com/forums/thread.jspa?threadID=1068831
Con ese delete, el “MDS Schema Configuration” se ejecuta correctamente , tras pulsar “reintentar”
Fallo en “Start Oracle Management Service”, se cambian las entradas del host:
127.0.0.1 localhost
192.168.0.115 linux2.localdomain linux2
Ya que el error aparece en la llamada:
getaddrinfo(localhost , …) failed (Name or service not known)
Fallo en “Start Oracle Management Service”, ahora parece problema de espacio, se amplia volumen 5GB más:
lvextend -L +5G /dev/VolGroup00/LogVol00
resize2fs /dev/VolGroup00/LogVol00
Y se pulsa sobre reintentar.
Fallo de nuevo en “Start Oracle Management Service”, errores relativos a la lectura del Policy Store, se sigue la nota metalink:
oracle.security.jps.JpsRuntimeException: Cannot Read From Policy Store [ID 1330253.1]
No recuperamos la instalación, se borra todo y se inicia de nuevo, con las siguientes entradas en el /etc/hosts:
192.168.0.115 linux2.localdomain linux2
127.0.0.1 localhost.localdomain localhost
(Borrando los esquemas y tablespaces tb de la bbdd y el registro de la tabla SCHEMA_VERSION_REGISTRY)
Ejecución correcta:
Accesos: https://linux2.localdomain:7802/em
https://linux2.localdomain:7102/console
Usuarios: sysman / ... (clave administrador que introdujimos al principio)
weblogic / welcome (usuario administrador consola weblogic)
Al entrar en "...:7802/em" y logarnos aparece el error:
ADFC-0619: Authorization check failed: 'oracle.jbo.uicli.binding.JUFormDef …
Se observa en el fichero de log: /u01/app/oracle/Middleware/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out
[JpsAuth] Check Permission
PolicyContext: [emgc]
Resource/Target: [sdk.core.uifwk.template.templateDefPageDef]
Action: [view]
Permission Class: [oracle.adf.share.security.authorization.RegionPermission]
Result: [FAILED]
For more information on this failure, please set -Djps.auth.debug.verbose=true
Se modifica el fichero jazn-data.xml, situado en : /u01/app/oracle/Middleware/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/tmp/_WL_user/oracle.security.apm_11.1.1.3.0/p1stos/META-INF
las líneas:
<class>oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl</class>
<name>anonymous-role</name>
por:
<class>oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl</class>
<name>Administrators</name>
Ya que el roll anonymous-role no aparece en dicho fichero jazn-data.xml
links:
https://forums.oracle.com/forums/thread.jspa?threadID=2233633
https://forums.oracle.com/forums/thread.jspa?threadID=841951
y bug oracle: Bug 9174870: LOGS INCLUDING A LOT OF ERRORS: [JPSAUTH] CHECK PERMISSION (REGIONPERMISSION)
Se entra en la interfaz de administración (weblogic / welcome)
Se establece la propiedad “-Djps.auth.debug.verbose=true” en los parámetros de arranque de EMGC_OMS1
Se descomenta la parte de jazn-data.xml:
<role-categories>
<role-category>
<name>Administrators</name>
<display-name>Administrators</name>
<description>Administrators Category</description>
<members>
<role-name-ref>APMAdmin</role-name-ref>
</members>
</role-category>
</role-categories>
Sigue apareciendo el mismo error.
Se prueba con https://kr.forums.oracle.com/forums/thread.jspa?threadID=905531
Sin éxito, sigue apareciendo el mismo error.
Se prueba creando usuarios administradores mediante la interfaz de texto emcli, sin éxito.
Pasa otro día, estoy más despejado, ….
Probamos a desabilitar la seguridad ADF según se indica en este post:
https://forums.oracle.com/forums/thread.jspa?threadID=2132032
ENTRAMOS correctamente.
Ficheros modificados:
/u01/app/oracle/Middleware/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/tmp/_WL_user/oracle.security.apm_11.1.1.3.0/p1stos/adf/META-INF/adf-config.xml
/u01/app/oracle/Middleware/oms/sysman/archives/emgc/deployments/GCDomain/emgc.ear/adf/META-INF/adf-config.xml
Entradas antiguas:
authorizationEnforce="true"
authenticationRequire="true"
Por:
authorizationEnforce="false"
authenticationRequire="false"
En los logs se sigue observanto los errores relativos a los permisos ADF, pero en el frontend ya no se muestra el error ADFC-0619.
No hay comentarios:
Publicar un comentario