Archive

Archivo de Autor

Solventar problemas de Oracle WebLogic con IPv6

Un error común en instalaciones de Oracle WebLogic, en sistemas operativos con IPv6 habilitado, es que al arrancar tras la instalación en los logs aparece un error similar a:

javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://[2001:0:5ef5:79fd:34ba:276a:f5fe:fecb]:7001: Destination unreachable; nested exception is:
java.net.NoRouteToHostException: No route to host: connect; No available router to destination]

Este error de resolución aparece en equipos con IPv6 habilitado pero sin configurar, incluso teniendo los DNS y el fichero de hosts bien configurados. Este error es muy común en entornos Windows (nunca he visto este error en otros sistemas operativos).

Existen dos posibles soluciones para este problema:

  • Arrancar Weblogic con el flag -Djava.net.preferIPv4Stack=true

Ejecutar regedit.exe

Buscar la siguiente subclave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

Hacer doble clic en DisabledComponents.

Si la entrada DisabledComponents no está disponible, debe crearse:

  1. En el menú Edición , seleccione Nuevo y, a continuación, haga clic en valor DWORD (32 bits).
  2. Escriba DisabledComponents y, a continuación, presione ENTRAR.
  3. Haga doble clic en DisabledComponents.

Escribir 0xFF para deshabilitar todos los componentes de IPv6 salvo la interfaz de bucle invertido de IPv6. Este valor también configura Windows para que utilice preferentemente IPv4 sobre IPv6, cambiando las entradas de la tabla de directivas de prefijo.

Una vez modificado el registro y reiniciado el sistema, tanto AdminServer como todos sus managed servers arrancarán sin problemas

Categorías:WebLogic Etiquetas: , ,

Para poder ejecutar Oracle Forms tras actualizar a Chrome 42

abril 22, 2015 2 comentarios

java

Si sois usuarios de Google Chrome, al actualizarse a la versión 42, notaréis que dejan de funcionar todas las aplicaciones que usen el applet de Java.

Al tratar de ejecutar cualquier aplicación, por ejemplo Oracle Forms, el mensaje de error que obtenemos es el siguiente:

Forms Services

La causa no es otra que el fin del soporte por parte de Chrome de los plug-in basados en la arquitectura NPAPI (Netscape Plugin Application Programming Interface).

Para volver a habilitar los plug-ins, se debe lanzar la siguiente URL en la barra de direcciones: chrome://flags/#enable-npapi y habilitar la opción que por defecto viene deshabilitada.

enable-npapi

Una vez habilitada, sólo hay que reiniciar Chrome y ya podremos volver a ejecutar nuestras aplicaciones basadas en Forms.

La pregunta es: ¿hasta cuándo? La postura de Oracle es clara:

We strongly recommend Java users consider alternatives to Chrome as soon as possible. Instead, we recommend Firefox, Internet Explorer and Safari as longer-term options.

Por el momento mi opción será la de seguir usando Chrome…

Categorías:Forms & Reports Etiquetas: ,

Hard Partitioning con Oracle VM x86 (pinnear vCPU’s)

diciembre 30, 2014 Deja un comentario

Oracle-VM

En este otro post tratábamos el licenciamiento de productos Oracle sobre entornos virtualizados. En esta nueva entrada vamos a entrar en detalle sobre cómo configurar Oracle VM 3.X sobre plataforma x86 para cumplir correctamente con los requisitos de licenciamiento.

Para realizar esta tarea, hay que descargar de My Oracle Support el parche Patch 13602094: ORACLE VM 3.0 UTILS RELEASE 1.0.2 que contiene el paquete de utilidades Oracle VM Utilities. Este conjunto de utilidades se suele instalar y ejecutar en el OVM Manager.

Una vez instalado procedemos a asignar (o pinnear) las CPU’s. Primero verificamos que la máquina virtual tenga asignadas las vCPU’s necesarias.

processors

 

Una vez revisado,  procedemos a lanzar el comando que habilita el hard partitioning:

[root@avtovmm1 ovm_utils]# ./ovm_vmcontrol -u admin -p <password> -h localhost -v avtvmdb01 -c vcpuset -s 0-3
Oracle VM VM Control utility 1.0.1.
Connected.
Command : vcpuset
Pinning virtual CPUs
Pinning of virtual CPUs to physical threads '0-3' 'avtvmdb01' completed.

Una vez ejecutado, esta máquina virtual sólo podrá hacer uso de 4 vCPU’s  y estaremos cumpliendo con un licenciamiento de 2 Processors Oracle.

Veamos el mismo ejemplo sobre un servidor con hyperthreading habilitado:

xm info
host : AVTOVM01.AVANTTIC.LOCAL
release : 2.6.39-300.32.6.el5uek
version : #1 SMP Fri Oct 11 22:05:27 PDT 2013
machine : x86_64
nr_cpus : 24
nr_nodes : 2
cores_per_socket : 6
threads_per_core : 2
cpu_mhz : 2933

Se trata de un servidor con 2 procesadores hexacore con hyperthreading habilitado, por lo que en el campo nr_cpus muestra 24, que son las vCPU’s disponibles para ser usadas por OVM.

El factor de corrección Oracle no tiene en cuenta el hyperthreading a la hora de licenciar los procesadores x86, sólo se fija en los cores, como explicábamos en este post.

Así que, en el servidor descrito se tendrían que asignar 8 vCPU’s para aprovechar el licenciamiento de 2 Processors Oracle:

2 Processors Oracle >> 4 Cores x86 >> 8 threads x86 >> 8 vCPU’s OVM

Licenciamiento productos Oracle en entornos virtualizados

noviembre 24, 2014 Deja un comentario

intel

La evolución de los procesadores hace que cada vez dispongamos de más núcleos (cores) en cada CPU.

Dado que ya casi no se encuentran en el mercado CPUs con 4 cores o menos, esto hace que al renovar los servidores, pasando por ejemplo de un servidor con CPUs DualCore a HexaCore, se deban adquirir mas licencias Oracle de tipo “processor” para no incurrir en un mal licenciamiento.

No se debe entender “processor” por su traducción literal “procesador” (CPU) ya que Oracle calcula los “processors” necesarios aplicando un factor de conversión al numero de cores del servidor. El factor de conversión depende del modelo de CPU: x86, UltraSparc VII, Power 5, PA-RISC, etc. Podéis encontrar la tabla de factores de conversión en este link y una explicación de cómo se calculan los “processors” necesarios en este post de nuestro blog. Por ejemplo, el factor de conversión para las CPUs Intel multicore x86 es de 0.5, lo que significa que para una CPU de 6 cores debemos tener licenciados 3 “processors” Oracle.

Este sobrecoste por tener que adquirir más licencias hace que muchos clientes se decanten por soluciones de virtualización, asignando sólo el número de cores licenciados a cada máquina virtual. Pero no sirve cualquier solución de virtualización: para poder limitar el número de licencias necesario, debe tratarse de una solución Hard Partitioning reconocida por Oracle, tal y como se explica en este documento.

En este momento las virtualizaciones reconocidas como Hard Partitioning son:

  • Solaris Zones (also known as Solaris Containers, capped Zones/Containers only)
  • IBM LPAR (adds DLPAR with AIX 5.2)
  • IBM Micro-Partitions (capped partitions only)
  • HP vPar
  • HP nPar
  • HP Integrity Virtual Machine (capped partitions only),
  • HP Secure Resource Partitions (capped partitions only),
  • Fujitsu’s PPAR
  • Oracle VM x86
  • Oracle VM SPARC

No sirven por tanto, para limitar el número de licencias, soluciones de virtualización tales como:

  • Xen
  • VMware
  • Microsoft hyper-v

Para conocer a fondo la política de licenciamiento de Oracle recomendamos leer este documento.

Evitar alertas de seguridad en JRE 1.7 en Oracle Forms

Con las últimas actualizaciones de seguridad de la JRE, muchos habréis detectado la proliferación de mensajes de error o alertas al entrar en las aplicaciones. Estas alertas son bastante molestas ya que aparecen cada vez que se ejecuta la aplicación, en algunos casos incluso pueden impedir la ejecución de Forms:alert

El motivo de estas alertas son los cambios en la política de seguridad de Java, que solo permite la ejecución del applet de Java con JAR’s que hayan sido firmados con un certificado emitido por una CA. La siguiente matríz proporcionada por Oracle muestra los casos en los que podremos ejecutar Forms dependiendo de si nuestros JAR’s estan firmados o no:

forms

La solución pasa por solicitar a una CA un certificado de firma de código. Las mas conocidas son:

http://es.godaddy.com/ssl/code-signing-certificate.aspx?ci=87235

http://www.symantec.com/es/es/products-solutions/families/?fid=code-signing

http://www.thawte.com/code-signing/

Los pasos para firmar nuestros JAR’s serían:


-- generamos el keystore
keytool -genkey -alias codesigncert -keypass miclave -keyalg RSA -keysize 2048 -dname "CN=NOMBRE EMPRESA,C=ES,ST=Barcelona,L=Barcelona" -keystore codesignstore.jks -storepass miclave

-- generamos el CSR
keytool -certreq -v -alias codesigncert -file fichero.cer -keystore codesignstore.jks keytool -import -trustcacerts -keystore codesignstore.jks -storepass miclave -alias codesigncert -file ficherocertificado.pem 

-- creamos el JAR con nuestros iconos
jar -cfvm iconos.jar manifest.txt ./iconos/* 

-- Firmamos el JAR
jarsigner -verbose -keystore codesignstore.jks -storepass miclave -keypass miclave iconos.jar codesigncert 

Una vez firmados los JAR’s se deben copiar en la instalación de Forms y las alertas se convierten en un mensaje de aviso que hay que aceptar en el primer acceso a Forms.

Categorías:Forms & Reports Etiquetas: , ,

Problemas al arrancar OEM12c si comparte nodo con Oracle RAC

febrero 21, 2014 Deja un comentario

En estos tiempos es habitual aprovechar al máximo la capacidad de los servidores. Esto hace que, aunque sea poco recomendable, sea común por ejemplo instalar otros productos en los mismos servidores donde corre la BBDD.

Esto, en el caso de Oracle RAC, puede ocasionar algunos problemas en Linux: Oracle RAC no empieza a arrancar sus daemons hasta que finaliza por completo la secuencia de Init, haciendo que arranque antes cualquier servicio dependiente que la propia BBDD, provocando errores en el arranque de OEM, quedando inaccesible y obligando a su reinicio.

En el caso del OEM, la solución pasa por modificar los scripts que proporciona la instalación y crear unos propios.

Primero comentamos las entradas del fichero de arranque de OEM:

/etc/oragchomelist

#/u01/oem/oem12c/oms
#/u01/oem/Agent12c/core/12.1.0.3.0:/u01/oem/Agent12c/agent_inst

y después creamos un script de arranque propio, que llamaremos startOEM.sh y ubicaremos en S99 de rc3 y rc5:

export AGENT_HOME=/u01/oem/Agent12c/agent_inst
export ORACLE_HOME=/u01/oem/oem12c/oms
sleep 180
$ORACLE_HOME/bin/emctl start om
$AGENT_HOME/bin/emctl start agent

Con esto conseguiremos que la instalación de OEM arranque después de la BBDD (a la que atacan sus datasources) y arrancará sin problema.

Categorías:Sistemas Etiquetas: , ,

Permitir acceso a un sistema Linux mediante scp/sftp denegando acceso mediante ssh

diciembre 19, 2012 Deja un comentario

En sistemas Linux es habitual disponer de usuarios que permiten el acceso y el intercambio de ficheros mediante FTP.

La norma habitual es que estos usuarios FTP no nos interesa que puedan abrir una shell en el sistema, y por tanto acceder via SSH.

Es para ello que al crear usuarios FTP habitualmente se crean con la shell /sbin/nologin:

testftp:x:501:48::/var/ftp/testftp:/sbin/nologin

El tema se complica cuando es necesario que el intercambio de ficheros sea de forma segura mediante scp/sftp, ya que no se permite que un usuario con la shell /sbin/nologin conecte via scp/scp.

Es por ello que existe el paquete  rssh. Para ello procedemos a descargarlo e instalarlo en nuestro O.S., un Oracle Enterprise Linux Server release 5.6:

wget http://pkgs.repoforge.org/rssh/rssh-2.3.3-1.el5.rf.x86_64.rpm
Saving to: 'rssh-2.3.3-1.el5.rf.x86_64.rpm'
100%[================================================>] 61,019 281K/s in 0.2s

Y procedemos a instalar el paquete:

[root@server1~]# rpm -iv rssh-2.3.3-1.el5.rf.x86_64.rpm

Una vez instalado procedemos a configurar la nueva shell editando el fichero /etc/rssh.conf, en nuestro caso solamente habilitamos los accesos via sftp y scp:

[root@server1~]# cat /etc/rssh.conf
# This is the default rssh config file
# set the log facility. "LOG_USER" and "user" are equivalent.
logfacility = LOG_USER
# Leave these all commented out to make the default action for rssh to lock
# users out completely...
allowscp
allowsftp
#allowcvs
#allowrdist
#allowrsync
...

Finalmente se modifica el usuario:

usermod -s /usr/bin/rssh testftp

A partir de este momento el usuario testftp solamente podrá acceder al sistema mediante sftp y scp, impidiendo el acceso via ssh, ftp, etc.

Categorías:Seguridad Etiquetas: , ,