Configuración hw de los equipos

HP Proliant DL360 G4
2 Intel Xeon 3.00 GHz (1MB-L2)
1HD 80GB
2GB RAM
4 GigaEthernet

Como tarjeta de vídeo para poder tener 4 monitores con una única tarjeta, podríamos utilizar una NVIDIA Quadro que ya hemos probado satisfactoriamente.

Gestión de sesiones con Hibernate

He encontrado que la gestión de sesiones de Hibernate con el LazyLoading y utilizando Swing como interfaz de usuario puede ser un problema. Me da la impresión de que Hibernate se ha diseñado orientado al desarrollo en entorno web con J2EE.

El problema que me encuentro es el siguiente:

1. Con lazy=false Hibernate me carga todos los objetos en el momento del arranque, ralentizando una barbaridad el arranque porque alguna de las tablas tiene muchas entradas (varios cientos de miles de registros).
2. Con lazy=true tengo el problema de que en el momento de que me pide uno de los objetos solicitados salta una excepción porque la sesión ya se ha cerrado.

En este blog ya se hace un análisis de la situación y de por donde van los tiros, dando información de como se haría el tratamiento con Hibernate+Spring o con Hibernate3. En una página de Hibernate hablan del problema de unir Hibernate y Swing.

Con el nuevo esquema de gestión de sesiones de Hibernate 3.1 se necesita un TransactionManager obligatoriamente, por lo que o se ejecuta la aplicación dentro de una servidor de aplicaciones o añadimos uno externo (JTOM), aunque en este thread del foro de Hibernate (que discute sobre el error que se se produce usando el esquema de DAOs que se usa en la última versión del CaveatEmptor cuando se ejecuta sin JTA) se dice que en una proxima entrega de Hibernate 3.1 ya no será obligatorio la utilización de JTA. El caso es que yo me he bajado la última versión de Hibernate y me sigue saliendo la excepción.

También he leido una página de Hibernate que explica como tratar con sesiones y transacciones.

Otra opción sería analizar el uso de la pre-versión de EJB 3.0 de Hibernate como se describe en este blog, aunque necesitaría informarme de las complicaciones que podría añadir.

Lanzamiendo remoto de aplicación X

De nuevo he tenido que dedicar más tiempo del que era previsible a una tarea que en principio parecía simple.

Estoy acostumbrado a que en otros UNIXes el exportar el display o ejecutar el rsh es algo trivial, y estoy viendo que en Linux nada es tan sencillo. Quizás las medidas de seguridad que toman sean convenientes, pero para mí que no soy un experto me traen por la calle de la amargura.

El último problema con el que me he encontrado ha sido lanzar desde una estación de trabajo una aplicación en un servidor y que el interfaz gráfico de dicha aplicación se mostrarse en la estación de trabajo.

Para ejecutar el rsh, he tenido que:
- añadir el servicio de rsh con /usr/sbin/serviceconf que se encontraba instalado pero inhibido.
- reiniciar el demonio xinetd /sbin/service xintd restart
- incluir la dirección de la estación de trabajo en el fichero /etc/hosts.equiv

Para que al exportar el display me saliera la aplicación en el equipo elegido he tenido que ejecutar en el mismo escritorio desde el cual iba a lanzar la aplicación el comando xhosts +. No vale con hacerlo desde otro escritorio.

Quizás esto deje agujeros de seguridad, pero ahora estamos haciendo solo pruebas de validez del concepto y por ahora nos vale. Antes de pasar al entorno de producción tendremos que volver a analizar la forma de implementarlo.

Arranque de sevidores de ftp y telnet en Red Hat

En la versión que estoy utilizando de Red Hat (RHEL 4.0), el servidor de ftp y el de telnet no están configurados por defecto para arrancar de forma automática. Esto puede ser una buena idea para mantener la seguridad, pero no es a lo que yo estaba acostumbrado por lo que he tenido que buscar, poco, como arrancarlos.

Para arrancar el servidor de ftp hay que ejecutar el siguiente comando:
# service vsftpd start

Si lo que queremos es que el servidor de ftp arranque automáticamente con cada boot, entonces tenemos que ejecutar:
# chkconfig vsftpd on

Para el servidor de telnet hay que editar el fichero de configuración /etc/xinetd.d/telnet y ponerlo como activado (disable = no). Después hay que rearrancar el demonio xinted /sbin/service xinetd restart

Instalación de Nomachine NX Server

Hemos instalado el NX Server de Nomachine en un servidor con Red Hat para acceso remoto desde equipos con Windows. Hemos descargado la versión de evaluación de http://www.nomachine.com/download_product.php?Prod_Id=188 y hemos solicitado una clave de evaluación (evaluation key) desde la misma página. Hemos tenido que descargarnos también el cliente de NX para Red Hat porque es un paquete requerido para poder instalar el servidor.

El fichero recibido con la clave de evaluación lo hemos descomprimido y hemos extraido el fichero server.lic que hemos copiado en el directorio de /usr/NX/etc.

A la hora de intentar conectarnos no nos mostraba ningún error, pero tampoco mostraba ninguna el escritorio de KDE como le habíamos configurado. Hemos añadido un usuario al servidor de NX y hemos intentado poner una password, pero daba un error al intentar definir la password.
# /usr/NX/bin/nxserver --useradd tsad
# /usr/NX/bin/nxserver --passwd tsad
NX> 100 NXSERVER - Version 1.5.0-70 PE (Evaluation)
NX> 113 Changing NX password of user tsad
NX> 500 ERROR: The NX password database is disabled
NX> 500 ERROR: Password for user: tsad not changed
NX> 999 Bye

Hemos mirado en el fichero de configuración de NX Server /usr/NX/etc/node.cfg y hemos modificado una entrada en la que hacía referencia a la base de datos de passwords (ENABLE_PASSWORD_DB = "1").

Después de ese cambio hemos reiniciado el servidor:
# /usr/NX/bin/nxserver --restart

Con ese último paso ya pudimos conectarnos desde el cliente que se estaba ejecutando desde el equipo con Windows.