Todos los días de trabajo tengo una necesidad nueva, esta vez mi problema gira entorno a armar una imagen (.iso) para un DVD/CD este lo voy a montar en el file system y luego a ejecutarlo. Para realizar esta tarea voy a utilizar el comando mkisofs (el nombre suena como "make iso from file system" el nombre correcto creo yo) y ya que el objetivo es muy puntual solo queda ejecutar el siguiente comando:

$mkisofs -D -o miarchivo.iso /home/jlmanrique/DVD

Donde -D es para decir que se va a incluir directorios largos, -o indica que se va a ingresar el nombre del archivo, miarchivo.iso es el nombre del archivo a generar y /home/jlmanrique/DVD es la raíz desde donde se copiaran todos los archivos. Tener en cuenta que para un .iso podemos agregar mas rutas simplemente las tenemos que separar por un espacio. Finalmente esperamos unos momentos y tenemos nuestro archivo iso. Espero les sea de utilidad tanto como a mi.

Segundo domingo de mayo, las calles llenas, las tiendas con muchas ofertas y por donde vaya encontraré muchos "Feliz Día Mamá". Las personas compran cosas para sus abuelas, madres, esposas, hermanas, hijas, etc, buscan el mejor peluche, un buen perfume, ropa elegante, casual, sport cualquier cosa que le pueda ser útil o simplemente que en algún momento lo pueda usar. Lo cierto es que muchos recapacitamos este día acerca de la persona que tenemos (o tuvieron) a nuestro lado, recordamos las veces que le hicimos pasar una mala noche esperando a que lleguemos a casa o cuando se preocupa por que no llevamos comida o cuando en el trabajo nos quedamos hasta tarde. Los motivos para preocuparse sobran algunas lo hacen notar otras no pero siempre hay ese sentimiento. A todo esto aprovecho el momento para decir lo siguiente:

"Mamá no seré el mejor hijo del mundo, te hice (y seguiré) renegar muchas veces se que también no siempre compartimos las mismas opiniones pero a pesar de todo te quiero mucho y no cambiaría por nada todos los momentos que vivimos. Muchas gracias por todo."

La foto es de la graduación de primaria de mi hermana menor

La verdad es que a primera vista parece que eso no fuera cierto y para los usuarios de M$ Window$ hacer esto quiza requiera el uso de algún programa extra (si el propio SO lo tiene haganmelo saber) pero en un Unix común y corriente que posee el programa mount se puede hacer esta tarea.
La primera acción que debemos realizar es la creación de una carpeta donde iniciara el punto de montado eso lo hacemos ejecutando el siguiente comando:

$mkdir /home/jlmanrique/ISO_DVD

Seguido procedemos a realizar el respectivo montado, para eso ejecutamos el siguiente comando:

$sudo mount -o loop {nombre de imagen}.iso /home/jlmanrique/ISO_DVD

Para verificar que hemos realizado exitosamente el montado verificamos con un ls el contenido de la carpeta /home/jlmanrique/ISO_DVD . De esa forma realizamos el montado de un .iso en nuestro filesystem, ahora para que podría ser útil:

• Se te acabaron los cds y requieres levantar una imagen.
• Requieres copiar algunos archivos de una imagen (o todo el contenido).
• O como en mi caso, requieras hacer un appliance, descargaste el instalador (.iso) y como tu lectora de dvd no es quemadora se tu puede aguar la fiesta ya que requieres usar todos los archivos de la imagen.
• Simple gusto.

Si encuentras otro uso no dudes en dármelo a conocer.

Cuando uno ve la estructura de directorios de un Unix por primera vez puede apreciar que existe una raíz y a diferencia de M$ Window$ que tiene varias unidades y al comienzo pueden confundirlo a uno pero la verdad es que detras de todo esto hay una idea muy simple pero muy potente.
A fin de que tengan una pequeña idea de cuales son las carpetas que debemos de tener en cuenta al momento de ver un Unix les dejo el siguiente enlace el cual describe cada una de las carpetas mas importantes en un entorno de las X. En lo personal me sirvió mucho y quiza encuentren algunas diferencias sobre el tipo de Unix que estén usando pero la idea se mantiene, espero el enlace les sea de utilidad tanto como lo fue para mi.

Casi al finalizar el día de trabajo se presento una pregunta muy peculiar entre uno de mis compañeros de trabajo esta era sobre el uso del log4j en una aplicación. Para comentar un poco los hechos esto fue lo que realmente paso:

1. Me encontraba muy tranquilamente esperando a que el SuSE 10 en una máquina virtual y vi a un compañero programar unas cuantas lineas usando el system.out.println(), cuando lo revise le dije que seria mejor que use el logger para que pueda revisar lo que imprime su aplicación al momento de arrojar errores.
2. Lo siguiente fue una duda por como configurar esto a lo cual simplemente el dije que habia que agregar un nuevo appender (org.apache.log4j.ConsoleAppender) que se encargara de imprimir en la consola, una vez realizado esto procedimos cambiar el código para que utilizara el logger en modo ERROR ya que se pintaba un Exception (en este caso un java.lang.NullPointerException).
3. Luego de mostrarle algunos tips para utilizar el logger (el clasico logger.isDebugEnable y logger.isInfoEnable) le dije que utilizar el system.out.println() era para "Salvajes" haciendo referencia a que esa era una practica muy antigua (casi de la época de las cavernas).
4. Seguido de esto otra persona me dijo por que decía eso de utilizar el sysout ya que ambos cumplían con el mismo objetivo y que le parecía mas fácil el uso del sysout. Mi respuesta fue como diría un amigo "muy hábil" puesto que en ese momento se me ocurrió decir que era por una cuestión de performance.
5. Si esta persona se sentó creyendo que esta era una respuesta adecuada (al menos eso parecía) no tarde en darme cuenta de la tremenda tontería que había dicho (por lo cual pido las disculpas del caso) ya que la verdad es que al ser log4j un framework este agrega un determinado tiempo de llamada a los métodos para el pintado en un archivo, consola, etc y el formateo de los mismos dependiendo del patrón que estemos escogiendo. Todo este tiempo claro esta no es generado por el sysout y por ende a este lo hace "mas veloz" si se trata de escribir claro esta en el sysout.

Por un momento esto nos lleva a pensar cuales podrían ser los motivos que nos llevan a usar un framework para el manejo de logs y si realmente valen la pena usarlos ya que tendríamos mas tiempo de procesamiento para pintar en las diferentes salidas que necesitemos. La verdad es que a pesar de consumir mas tiempo del procesador si es muy necesario el uso de un framework para esta funcionalidad por eso voy a listar los motivos por los cuales uso el log4j para manejar mis archivos de log.

1. Todo framework tiene como objetivo el facilitarnos las tareas de algún campo en especifico y log4j no es la excepción a la regla puesto que su principal objetivo es ayudarnos con el manejo de los logs de nuestra aplicación ofreciéndonos una gran variedad de configuraciones que nos permitirán concentrarnos en nuestro problema real: Desarrollar una aplicación y no en desarrollar un buen manejo de logs.
2. Para realizar una buena configuración de log4j no se requiere tener conocimientos extremos de como abrir y cerrar un flujo y si lo estamos haciendo de la forma correcta o no, simplemente tenemos que utilizar los appenders que estan definidos como parte del framework dentro de los cuales tenemos el ConsoleAppender para escribir en la salida estándar, el DayliRollingFileAppender si deseamos que se cree un archivo de log cada dia que pasa, el RollingFileAppender el cual escribe de manera circular cada vez que el archivo llega a un determinado tamaño, el AsyncAppender para escribir de manera asíncrona en el archivo entre otros. En caso ninguno sea de nuestro agrado se puede extender (tomarlo como heredar de la clase o basarse en ella) cualquiera de estos a fin de obtener el manejo esperado.
3. Otra de las funcionalidades que tenemos es el formateo del mensaje a escribir esto lo hacemos usando plantillas que se llaman Layout, cada uno de estos describe el formato en el cual se escribirán nuestros mensajes, dentro de estos tenemos al HTMLLayout el cual ingresa cada uno de los logs como una linea de una tabla, el PatternLayout (el que mas uso) el cual escribe el log en base a un patrón ingresado en el archivo de configuración, el SimpleLayout el cual solamente describe el nivel del log y el mensaje, entre otros. Al igual que los Appender si ningún Layout es de nuestro agrado podemos crear el propio que cumpla con nuestro requerimiento, personalmente no he tenido la oportunidad de realizar dicha tarea puesto que con el PatternLayout realizo todas mis tareas.
4. Otra de las características que me agrada de este framework es el manejo de varios niveles del mensaje los cuales son: TRACE, DEBUG, INFO, WARN, ERROR y FATAL. El como manejarlos puede depender de cada uno, mi sugerencia es manejar cada mensaje informativo entre el TRACE, DEBUG e INFO el uso de cada uno deberá ser en el grado de importancia que se desee tener, para el caso de los mensajes en WARN lo utilizo para mostrar algún evento en el sistema que no es un error pero que si seria bueno documentarlo a fin de mostrar una advertencia en el log, el uso del ERROR es para mostrar errores del sistema y el FATAL es cuando queremos pintar algún mensaje antes de detener el servicio totalmente. Esta es la "formula" que hasta el momento me ha servido para manejar los niveles de mis mensajes.
5. El manejo de diferentes fuentes de impresión del log dependerá de la cantidad de Appenders que nosotros registremos en nuestra configuración, para el programador el escribir en una fuente o en cinco es transparente el solo tiene que decir que tipo de mensaje quiere imprimir y el framework se encargará de realizar las impresiones necesarias. En el caso de utilizar el sysout uno debe de indicar manualmente donde realiza la impresión y si se quiere quitar una fuente se deberla de volver a compilar la aplicación a fin de efectuar el cambio.
6. Regresando a los niveles de log el utilizar un nivel u otro y mostrar o algunos mensajes o no es tan trivial como modificar un archivo de configuración (properties o xml) el desarrollador no tiene que modificar código fuente para realizar el cambio y mucho menos tiene que recompilar la aplicación para realizar estos cambios, lo cual lo pone un paso adelante del manejo del sysout.
7. Finalmente la mejor opción por la cual usuaria el log4j en vez del sysout es por que si realizo un buen uso de los niveles de mensajes en el código no requiero iniciar la aplicación en modo debug lo cual nos ahorra tiempo al momento de depurar errores puesto que todos estos se encuentran debidamente documentados en un archivo, consola, base de datos, etc.

Si a pesar de todo esto aun no quieres usar el log4j o algún otro framework pues solo me queda decirte que mas adelante tendrás muchos problemas o acabarás creando tu propio framework para pintar tus eventos. Para que reinventar la rueda si esta funciona y muy bien, espero este post sea de su agrado.

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.

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.