0

Crear un DVD de Suse usando los CDs

Posted by Jose Luis Manrique on 13:29 in ,
El dia de hoy tuve un gran problema al momento de utilizar una herramienta llamada mmtools de IBM esta me pedía utilizar un DVD que tuviera el instalador del sistema operativo pero yo solo contaba con los CDs. Luego de buscar en google un rato encontré una herramienta llamada makeSUSEdvd que justamente hacia lo que requería. La instalación de esta herramienta es muy simple, se descarga el rpm del site y se procede a ejecutar el siguiente comando:
$sudo rpm -i makeSUSEdvd-0.45.1-1.44.noarch.rpm --nodeps
El parámetro nodeps es para que al momento de la instalación del rpm este no verifique las dependencias. Una vez realizado esto procedemos a ejecutar la herramienta pero en modo interactivo el cual simula un wizard a medida que va avanzando va haciendo preguntas acerca de información posees, para realizar esto usamos el siguiente comando:
$sudo makeSUSEdvd -I
En mi caso ingrese la siguiente información:
  • Requiero crear una carpeta.
  • El directorio de la carpeta sera: /home/jlmanrique/SUSE_DVD.
  • No requiero rpms adicionales.
  • Para la creación estoy usando cds.
  • El punto de montado de los cds sera: /home/jlmanrique/SUSE_CD
Es muy probable que te preguntes como hago para cambiar el punto de montado de mi lectora de cd ya que por lo general estos se configuran solos en /media/XXXX (en mi caso fue en /media/SLES10_00X donde X es el numero de disco), pues para realizar esto deberás primero ubicar el archivo al cual hace referencia tu lectora esto lo revisas usando el comando df. Una vez ejecutado este comando podrás ver otros dispositivos como tus discos duros, en mi caso la lectora se encuentra en la ruta /dev/sr0 . Ya con el dispositivo ubicado se procede a realizar el desmontado y montado de la lectora, esto lo realizamos con los siguientes comandos:
$#Desmontado del dispositivo
$sudo umount /dev/sr0 #cambiar por el dispositivo
$#Montado del dispositivo
$sudo mount /dev/sr0 /home/jlmanrique/SUSE_CD #carpeta indicada antes
Regresando a la creación del DVD una vez ingresada toda la información que pide la herramienta, esta nos requerirá que se ingresen uno a uno los cds para esto debemos de realizar el procedimiento para realizar el desmontado y montado en una carpeta diferente. A medida que vamos ingresando la herramienta unira estos cds en una sola imagen. Para finalizar la creación se deberá presionar cualquier tecla diferente a ENTER y a disfrutar del DVD de instalación de SuSE.

0

Instalación de CVS en SuSE 10 Enterprise Edition

Posted by Jose Luis Manrique on 15:23 in , ,
Hace poco tuve que realizar una instalación de cvs en un servidor que tenia SuSE 10 Enterprise Edition. La configuración de este servicio ya la había realizando antes en Ubuntu así que procedí a realizar los mismos pasos, los cuales son:
  1. Creación del grupo y usuario para la ejecución del servicio.
  2. Creación de las carpetas.
  3. Verificación de los paquetes cvs y xinetd.
  4. Inicialización del repositorio.
  5. Configuración del servicio en xinedt.
Para realizar todas estas actividades requerimos tener acceso al usuario root del servidor, por lo tanto nuestra primera accion sera:
$su root
Una vez ingresada la contraseña, procedemos a la creación del grupo y usuario, para esto utilizamos los comandos "useradd" y "groupadd" los cuales son usados para crear usuarios y grupos respectivamente. Estos comandos los ejecutamos de la siguiente forma:
$groupadd cvs
$useradd -d /home/admincvs -g cvs -m admincvs
Como pueden apreciar en la ultima linea se creó un usuario pero en ningún momento le asignamos una contraseña, para realizar esta tarea utilizamos el comando "passwd" para esto utilizamos la siguientes linea:
$echo {ingresar password} > pw
$cat pw | passwd --stdin admincvs 
Con el usuario listo para ser usado procedemos a crear la carpeta donde vamos a ubicar nuestro repositorio, para esto ejecutamos la siguiente linea:
$mkdir -p /var/repositorios/proyecto
Utilizamos la opción "-p" para que se fuerze a la creación de las carpetas que no estén creadas. Una vez finalizado procedemos a revisar si los paquetes cvs y xinetd se encuentran instalados para eso verificamos en el yast que estos programas se encuentren instalados de no estarlo procedemos a buscarlos e instalarlos. En la figura se muestra una pantalla del yast2 (manejador de paquetes) en la cual se va a agregar el xinetd. El siguiente paso es inicializar nuestro repositorio por lo cual creamos una variable de entorno en la cual vamos a almacenar la ruta de nuestro repositorio (solo para la consola que se esta usando) llamada CVSROOT ejecutando el siguiente comando:
$export CVSROOT=/var/repositorios/proyecto
Seguido de eso ejecutamos el comando de inicialización y cambiamos el usuario de los archivos creados por el proceso anterior:
$cvs init
$chown -R admincvs:cvs /var/repositorios/proyecto
El programa "cvs" tomará la variable CVSROOT y procederá a iniciar el repositorio creando una carpeta con el mismo nombre dentro de la ruta indicada. Dentro de esta carpeta se deberá crear un archivo llamado passwd que contendrá todos los usuarios que usarán en repositorio, estos deben ser ingresados de la siguiente forma {usuario}:{password_encriptado}:{usuario_sistema} donde usuario_sistema es le usuario que creamos anteriormente, todos los archivos que se van a crear en el repositorio serán usando este usuario. Como se puede apreciar el password ingresado debe estar cifrado para realizar la encriptación del mismo se debe de ejecutar el siguiente script (en Perl):
#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";
Este se encargará de cifrar la contraseña para ejecutarlo correctamente el archivo en el cual se almacene debe tener permisos de ejecución y lectura (como mínimo) y pasar como argumento el valor a encriptar. Como último paso de nuestra configuración se deberá configurar el xinetd para que nuestro repositorio pueda ser visible para los demás. Para esto creamos el archivo "cvspserver" en la ruta /etc/xinetd.d/ y le ponemos el siguiente contenido:
#Inicio de configuracion cvspserver
service cvspserver{
       port           = 2401
       socket_type    = stream
       protocol       = tcp
       wait           = no
       user           = admincvs #El usuario que creamos
       passenv        = PATH
       server         = /usr/bin/cvs #Ubicacion del programa
       server_args    = -f --allow-root=/var/repositorios/proyecto pserver
}
#Fin de configuracion cvspserver
Finalmente reiniciamos el servicio del xinetd utilizando el siguiente comando:
$/etc/rc.d/xinetd.d/xinetd reload
Y tenemos listo nuestro repositorio con todo lo necesario para que varios usuario se puedan conectar subir sus versiones y descargar las de los demás.

0

Spring Live Perú - 2009

Posted by Jose Luis Manrique on 5:18 in , ,
Hace unos pocos dias me enteré, gracias a Bruno, que la empresa JoeDayz esta organizando un evento denominado Spring Live Perú 2009, el cual tiene como objetivo el difundir el uso de framework Spring. Ya que Spring es algo que yo veo desde hace ya un año y he usado muchos de sus módulos me animé a participar. Hasta el momento se tienen confirmados los siguientes expositores:
  • Spring Framework (José Díaz - JoeDayz)
  • Domain Driven Design Aplicado (Juan Carlos Vergara - AgileWorks)
  • Desarrollando Aplicaciones con Flex y Spring (Ricardo Avila - BSE)
  • Persistencia con Hibernate (Christian Komiya - JoeDayz)
  • Desarrollo de Aplicaciones Web Enriquecidas con Spring (Susan Inga - JoeDayz)
  • Spring .Net essentials (Christian Palomares Peralta - SSS)
  • Desarrollo de Aplicaciones Web con ExtJs (Mayer Horna - Freelance)
  • Aspect Oriented Programming (Jose Luis Manrique Cabana - Freelance)
El evento tendrá lugar en el Aula Magna de la Facultad de Ing. de Sistemas de la Universidad Nacional Mayor de San Marcos. Los horarios de las exposiciones aun no están confirmados espero no me toque cerrar la conferencia pero de serlo habría que preparar algo mas interesante. Como nota curiosa dentro de los expositores tengo a dos amigos Susan Inga y Christian Palomares, los dos son de mi casa de estudios y he llevado algunos cursos con ellos, desde ya les puedo decir que sus ponencias serán muy buenas. Para tener las ultimas noticias del evento les recomiendo suscribirse a la pagina de JoeDayz: http://www.joedayz.org . Spring Live Perú 2009, here I go!!!!

0

Heretic en Ubuntu

Posted by Jose Luis Manrique on 19:21 in ,
Recordar es volver a vivir y en este caso lo que voy a recordar es un juego que me mantuvo horas de horas entretenido el cual es Heretic. Este esta basado en el motor de juegos de Doom (otro juego genial) y su tematica es sobre una especie de edad media llena de magos, demonios y demás. Originalmente este juego solo estaba disponible para Windows pero luego liberaron las fuentes y ya se pudo tener una versión para Linux. Durante un par de horas estuve viendo cual seria la mejor opción para instalarlo en mi PC, habían dos posibilidades:
  1. Utilizar el instalador en RPM del juego.
  2. Usar un simulador de DOS e instalar el juego desde ahi.
Siendo sinceros probé las dos opciones, en el primer caso como la distribución que uso es Ubuntu tuve que instalar el programa alien de la siguiente forma:
$sudo apt-get install alien
Una vez realizado esto procedí a transformar cada uno de los .rpm a .deb de la siguiente forma:
$sudo alien xxxxx.rpm
Y finalmente instalé todos los rpm, el resultado no me fue el esperado puesto que iniciando nomas se caia el juego y obviamente no podía seguir. Luego de ver como fallaba la primera opción (que se veía mejor) decidí poner en práctica la segunda opción que era utilizar un simulador de DOS, en este caso utilicé el DOSBox el cual ya habia visto hace tiempo y lo use en Windows XP con buenos resultados. Para realizar la instalación se pone el siguiente comando:
$sudo apt-get install dosbox
Ejecutamos el dosbox:
$dosbox
Y montamos una carpeta de nuestro filesystem para que la tome como un driver de Windows (C, D, E, F, etc), para eso ejecutamos lo siguiente:
Z:/mount D /home/jlmanrique/D_dosbox
En esa linea simplemente le indicamos al DOSBox que vamos a montar la ruta de /home/jlmanrique/D_dosbox como el driver D. Luego procedemos a copiar los instaladores y finalmente a ejecutarlos. Tenemos el siguiente resultado: Pantalla de Inicio: Ubicación en los directorios: Pantalla final del juego: Espero les haya gustado y si lo llegan a instalar diviertanse.

0

Portlet Development Best Practices (5/12) - Manejo de la Sesión

Posted by Jose Luis Manrique on 20:13 in , , ,
En la anterior entrega tocamos el tema del manejo de la configuración en el portal ,las estrategias para utilizar efectivamente cada una de las facilidades de los Portlets y los motivos por los cuales usar uno u otro.

En este post trataremos un tema muy delicado el cual es el manejo de la sesión de nuestra aplicación sin mas preámbulos empiezo a detallar cada una de las buenas practicas al respecto.
  • Limitar el uso de la sesión del portlet. La recomendación es muy explicita para este caso no se debe de abusar del uso de la sesión, no cualquier dato debe ser almacenado en esa área. En este punto tenemos dos ejemplos el primero es el almacenar un objeto que es muy costoso en ser construido/obtenido en este caso si recomiendo que sea almacenado en sesión para que no se incurra en el costo de tener que crear un nuevo objeto por cada request (render y/o action) y el segundo caso es de un objeto que puede ser generado en cualquier momento y no implica mucho costo para el sistema (un listado de tipos de documentos) estos no tendrían por que ser almacenados en la sesión puesto que aun se puede asumir el costo de su construcción. Si eres de los que le gusta usar la sesión para todo pues es momento que analices que debe de ir o no dentro de tal forma que evitas los famosos java.lang.OutOfMemoryError.
  • Evitar el uso de la sesión si es que el portlet puede ser accedido por anónimos. Tiene mucho sentido puesto que la sesión debe ser usada justamente cuando el usuario se ha conectado a la aplicación previa validación de usuario y contraseña. Si el portlet esta disponible para cualquier usuario eso quiere decir que la información que se muestra no es sensible por lo tanto algunos datos se podrían manejar usando campos ocultos (inputs hidden dentro del formulario). Por el momento no me ha tocado crear un portlet para usuarios anónimos pero es mas que seguro que tendré en cuenta esta recomendación para futuros desarrollos.
  • Siempre usar PortletRequest.getPortletSession() para obtener una sesión valida. Hasta el momento no se como obtener una nueva sesión que no sea de esa forma pero si la hay no debería usarse puesto que se podría estar obteniendo un valor invalido.
Finalmente podemos llegar a la conclusión que el uso de la sesión debe de realizarse con mucho cuidado y siempre teniendo en cuenta algunas consideraciones previas.

Para la siguiente entrega se tocará el tema de la internacionalización el cual tiene como objetivo mostrarnos algunas sugerencias para hacer que nuestro portlet muestre contenido dependiendo del idioma del cliente.

0

Portlet Development Best Practices (4/12) - Manejo de la configuración

Posted by Jose Luis Manrique on 17:39 in , , ,
En el anterior post tocamos el manejo de los paquetes y utilitarios (falto poner el buen diseño de los Portlets) ahora nos toca hablar del manejo de la configuración en nuestra aplicación de portal.

Para empezar tenemos tres posibles lugares donde podemos almacenar nuestra configuración estos son: la configuración de portlet, los datos del portlet y la configuración del servlet.

A continuación detallaré cada uno de estos y cuando debe ser usado:
  1. Configuración del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet y este no depende del usuario que se encuentra utilizando la aplicación. Este tipo de configuración se realiza por medio del archivo portlet.xml o también usando el modo config del portlet. Ahora cuando usar este tipo, por ejemplo el cambiar el origen de datos de un portlet para una determinada pagina.
  2. Datos del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet pero dependiente del usuario que se encuentra utilizando la aplicación. Esta forma de configuración puede sobreescribir los datos manejados en el primer caso y la forma de administrar estos valores es usando el modo edit del portlet. Un buen ejemplo del uso de este parámetro podría ser la personalización del tamaño de paginación en un listado por parte del usuario.
  3. Configuración del servlet, usamos esta forma de manejo de los parametros cuando queremos incluir valores que sabemos que no van a cambiar durante todo el ciclo de vida de la aplicación dentro del contenedor. El mas claro ejemplo seria utilizar esta forma para almacenar las rutas de donde se leerán los archivos de configuración (properties, xml, imagenes, etc), para esto utilizamos el archivo web.xml .
Como podemos apreciar para configurar nuestra aplicación tenemos tres formas cada una orientada a una situación en particular lo cual podría complicar al desarrollador, claro esta siempre y cuando no se tenga en cuenta cual es el objetivo de cada una de estas formas.
El próximo post tratará sobre el manejo de la sesión este tema deberá de tocarse muy a detalle por que muchos desarrolladores abusan de su uso y al final generan los famosos "Memory Leak".

0

Portlet Development Best Practices (3/12) - Paquetes y Utilitarios

Posted by Jose Luis Manrique on 15:56 in , , ,
En la segunda parte de las buenas practicas para el desarrollo de portlets hablamos sobre las consideraciones a tener en cuenta sobre los jsps en esta entrega trataremos el tema de los paquetes y utilitarios como poder distribuirlos y algunas sugerencias al respecto. Debido a que el articulo solo toca dos puntos no usaré los marcadores.

Empaquetar las funcionalidades comunes a los Portlets. Suena un poco raro al momento de leerlo en ingles pero quizá esta sea una traducción adecuada ya que el objetivo del mismo el de separar las funcionalidades comunes en un jar de tal manera que pueda ser reutilizable. Ahora supongamos que tenemos dos casos (los cuales detallaré) en los que nos podemos encontrar:
  1. Se tiene una aplicación en portal y se tienen componentes de la capa de acceso a datos (en adelante DAO), estos componentes son compartidos por varios portlets dentro de la misma aplicación, la pregunta es ¿Será necesario separar el DAO en un jar aparte? La respuesta es NO, si ten encuentras en esta situación deberías de pensar en el patrón KISS (y no es el grupo) ya que la casuística no posee mucha complejidad y no requiere una separación.
  2. Supongamos que tienes un caso un tanto similar al anterior solo que ese componente es usado por varios Portlets de muchas otras aplicaciones, pues el escenario cambia y en este caso para tener componentes reutilizables se debería crear un jar que posea este bloque de funcionalidades y simplemente durante el desplegado solo se haga referencia al mismo. Pero repetir el jar en todas nuestras aplicaciones con toda la funcionalidad incluida no seria muy útil por que nunca falta alguien que muy hábilmente modifique el jar y lo use inadecuadamente, para este caso el portal como framework nos ofrece la facilidad de exponer servicios propios. En el contenedor de WebSphere se utiliza la interfaz PortletService la cual indica que esa implementación forma parte de un servicio del portal.
La ultima consideración es sobre la reutilización del portlet, la idea gira alrededor de combinar múltiples funcionalidades dentro de un portlet único pero usando diferente configuración. Para comprender mejor la recomendación veamos algunos casos:
  1. Tenemos un portlet que debe realizar una tarea administrativa sobre alguna tabla/archivo maestro esta labor incluye la búsqueda, creación, edición y eliminación de registros. Una solución propuesta para este caso es la de tener un portlet que solo muestre el listado, otro que se encargue de la modificación y creación de los registros, y finalmente un portlet que sirva para eliminar registros; esta solución propuesta se baso en que los permisos para cada una de las acciones van a depender del perfil que posea el usuario. Es muy probable que desarrollando esto aprendamos mucho sobre el manejo de wiring, la paginación de los listados, el ciclo de vida de los portlets, etc pero esta solución no es la mas adecuada ya que se están creando tres Portlets para una funcionalidad que puede ser hecha por uno solo. Ahora como se podría desarrollar, muy simple ya que las funcionalidades se deben mostrar o no dependiendo del perfil por medio del servicio de manejo de usuarios del portal obtenemos el perfil y validamos si es que se le debe o no de mostrar la funcionalidad, en caso se muestre como parte de la navegación del portal mostramos otra página y listo no tuvimos que crear mas Portlets sino que diseñamos bien uno solo que tiene todas las funcionalidades que necesitamos.
  2. Nuestro segundo caso podría ser una aplicación portlet que dependiendo de la página en la que se encuentre muestre información de una fuente de datos determinada y si esta en alguna otra página se vaya a la fuente por defecto. Para este caso podríamos crear un portlet (dentro de la misma aplicación) por cada una de las fuentes de datos , si bien la solución es muy práctica no es la mas adecuada debido a que si aumentan las fuentes de datos tendríamos que crear mas Portlets lo cual nos causaría un mayor costo en cuanto a tiempo y obviamente en dinero. Una posible solución que podríamos ofrecer es la de tener un portlet que implemente el modo config y dentro de este haya un parámetro que indique la fuente de datos de origen con la cual se quiera configurar (por defecto mostrará un valor); este parámetro se va a encontrar como parte de los parámetros del contexto del portal por lo cual cada instancia del portlet puede ser configurada al antojo del administrador del portal.
  3. Otro caso que podríamos encontrar es la de tener una aplicación que se encargue de buscar a los clientes de una empresa y también que muestre la información del mismo, la particularidad de este desarrollo es que la búsqueda sera usada por otras aplicaciones las cuales no necesariamente requieran el mostrar la información del cliente. Para este caso un tanto especial si se podría separar la funcionalidad puesto que la búsqueda debe mantenerse agnóstica de quien la llamo. Otro punto por el cual estas funcionalidades no deben de formar parte del mismo portlet es por que el buscador será utilizado en otro contexto en el cual no necesariamente se requiera mostrar la información del cliente.
Si bien este post contiene pocas buenas prácticas posee varios ejemplos en los cuales se puede aplicar o no la recomendación. El siguiente post tocará el tema del manejo de la configuración en el portal, punto al que hicimos referencia en el tercer ejemplo de la segunda recomendación.

Copyright © 2009 Autumn All rights reserved. Theme by Laptop Geek. | Bloggerized by FalconHive.