Instalación de Teambox en openSUSE

mayo 4, 2011 6 comentarios

En mi búsqueda de una herramienta web que permitiese gestionar nuestros objetivos, actividades, inversión de horas de trabajo, etc. he encontrado y probado Teambox.

Esta es una excelente herramienta para la gestión de proyectos de desarrollo colaborativo, cuenta con una interfaz simple orientado a redes sociales, su principal función es la administración de tareas entre los miembros del equipo de trabajo, mantener registro de la duración de tiempo de las actividades, permite crear wiki’s, compartir archivos, realizar comentarios, entre otras funcionalidades muy útiles. Para conocer más información sobre la misma pueden visitar este enlace.

Requisitos de Instalación

  1. Debemos tener instalados una serie de paquetes que son fundamentales para poder ejecutar la aplicación web, entre ellos se destacan los paquetes relacionados con el lenguaje de programación Ruby, su sistema de gestión de dependencias y el módulo para Apache. El comando de instalación es el siguiente: 
    fireserver:~ # zypper install libxml2 libxml2-devel libxslt libxslt-devel mysql-community-server libmysqld-devel sqlite3 sqlite3-devel postgresql-devel apache2 apache2-devel apache2-prefork libcurl-devel ImageMagick ImageMagick-devel git gcc gcc-c++ ruby rubygems rubygem-passenger rubygem-passenger-apache2 rubygem-passenger-nginx
  2. Teambox soporta múltiples bases de datos, sin embargo, para este ejemplo he utilizado MySQL instalado en el mismo servidor. La guía de pasos de instalación y configuración de MySQL para openSUSE se encuentra documentada en este artículo.

Instalación y Configuración de la Herramienta Teambox

  1. Para este ejemplo la instalación de la herramienta web Teambox se va a llevar a cabo en el directorio /opt, para ello nos debemos ubicar en dicho directorio. 
    fireserver:~ # cd /opt/
fireserver:/opt #
  2. Obtenemos el código fuente y las dependencias clonando el proyecto a partir de Github. 
    fireserver:/opt # git clone git://github.com/teambox/teambox.git
  3. Una vez concluida la descarga accedemos al directorio teambox creado en el paso anterior. 
    fireserver:/opt # cd teambox/
fireserver:/opt/teambox #
  4. Dentro del directorio teambox debemos elegir la rama de desarrollo que queremos instalar, ya que el código fuente dispone dos opciones, una rama estable llamada master ideal para entornos de producción y otra rama más inestable en estado de desarrollo pero con las últimas funcionalidades llamada dev. En esta guía voy a utilizar la rama master que es la que mejor se adecua a nuestras necesidades laborales, a nuestro entorno de producción: 
    fireserver:/opt/teambox # git checkout master
  5. Necesitamos instalamos la aplicación bundler mediante el gestor de paquetes de Ruby llamado gem: 
    fireserver:/opt/teambox # gem install bundler
  6. Pasamos a instalar todas las gemas ruby que requiere la herramienta Teambox para su funcionamiento (dependiencias), esto lo realizamos ejecutando el siguiente comando: 
    fireserver:/opt/teambox # bundle install --deployment
  7. El siguiente paso es dirigirnos al directorio /opt/teambox/config y crear el archivo con las especificaciones necesarias para la configuración de la base de datos llamado database.yml a partir del archivo plantilla llamado database.example.yml. 
    fireserver:~ # cd /opt/teambox/config/
fireserver:/opt/teambox/config # cp database.example.yml database.yml
  8. Luego procedemos a editar el nuevo archivo database.yml: 
    fireserver:/opt/teambox/config # vi database.yml

    y configuramos la directiva password para la sección production, debería quedar similar a lo que sigue:

    production:
 adapter: mysql
 host: localhost
 username: root
 password: contraseña_usuario_root
 database: teambox2_production
  9. Ahora procedemos a crear la base de datos y sus respectivas tablas para la herramienta Teambox en MySQL (que debe estar ejecutándose, lista para usarse), esto lo hacemos ejecutando el siguiente comando en el directorio /opt/teambox. 
    fireserver:~ # cd /opt/teambox
fireserver:/opt/teambox # bundle exec rake db:create db:schema:load RAILS_ENV=production
  10. Luego pasamos a configurar la propia herramienta Teambox mediante su archivo de configuración teambox.yml ubicado en el directorio /opt/teambox/config. Primero editamos el archivo de configuración: 
    fireserver:~ # vi /opt/teambox/config/teambox.yml

    Una vez dentro del archivo configuramos las siguientes directivas:

    app_domain: teambox.mi_dominio.local
time_zone: Georgetown
default_locale: :es
smtp_settings:
 :domain: gmail.com
 :address: smtp.gmail.com
 :port: 587
 :authentication: :plain
 :user_name: nombre_usuario@gmail.com
 :password: contraseña_usuario
 :enable_starttls_auto: true

    Entre las configuraciones más importantes se destacan la directiva app_domain y las configuraciones de las subdirectivas smtp_settings, esta últimas permiten definir el servidor smtp mediante el cual la herramienta enviará las notificaciones por correo electrónico. Finalmente guardamos los cambios y salimos del archivo de configuración con lo cual culminamos con la configuración de la herramienta Teambox.

Configuración de Apache

  1. Lo primero que debemos hacer es habilitar el módulo passenger de Ruby para que Apache pueda ejecutar la herramienta web Teambox, para ello editamos el archivo /etc/sysconfig/apache2: 
    fireserver:~ # vi /etc/sysconfig/apache2
  2. Una vez en el archivo de configuración buscamos la directiva APACHE_MODULES  y al final de la lista le agregamos el módulo passenger, debería quedar similar a lo que sigue: 
    APACHE_MODULES="actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl userdir php5 passenger"

Acceso mediante hosts virtuales

Si deseamos que Apache sirva el sitio web de Teambox a través de un nombre de dominio totalmente cualificado (FQDN: Fully Qualified Domain Name) resuelto a través de servidores de nombres (DNS) internos o externos podemos configurar un host virtual para dicho fin. Para ello podemos seguir los siguientes pasos:

  1. Nos dirigimos al directorio /etc/apache2/vhosts.d y creamos un nuevo archivo llamado vhost.conf: 
    fireserver:~ # cd /etc/apache2/vhosts.d
fireserver:/etc/apache2/vhosts.d # touch vhost.conf
  2. Editamos el archivo con nuestro editor de texto preferido.. 
    fireserver:/etc/apache2/vhosts.d # vi vhost.conf

    Y luego agregamos las siguientes directivas:

    # -- ES NECESARIO DEFINIR LA DIRECTIVA NameVirtualHost CUANDO
# SE CONFIGURAN HOSTS VIRTUALES BASADOS EN NOMBRES.
NameVirtualHost *:80

# -- CONFIGURACION DEL HOST VIRTUAL POR DEFECTO, QUE APUNTA
# A LA RUTA TRADICIONAL.
<VirtualHost *:80>
    ServerName fireserver
    ServerAlias fireserver *.fireserver
    DocumentRoot /srv/www/htdocs
</VirtualHost>

# -- CONFIGURACION DEL VIRTUAL HOST PARA TEAMBOX
<VirtualHost *:80>
    Options +Indexes
    ServerAdmin nombre_usuario@gmail.com
    ServerName teambox
    ServerAlias teambox.mi_dominio.local *.teambox.mi_dominio.local teambox *.teambox
    DocumentRoot /opt/teambox/public
    RailsEnv production

    <Directory "/opt/teambox/public">
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
        Options -MultiViews
    </Directory>
</VirtualHost>
  3. Con esto ya tenemos el servidor web configurado con soporte virtual host.

Acceso mediante subdirectorio

Una opción alternativa a la configuración de host virtual de Apache para desplegar Teambox es utilizar una configuración más tradicional definiendo el acceso a dicha herramienta a través de un subdirectorio posterior al dominio o dirección IP de nuestro servidor web.

  1. Como primer paso, nos dirigimos al directorio /etc/apache2/conf.d y creamos un nuevo archivo llamado teambox.conf: 
    fireserver:~ # cd /etc/apache2/conf.d
fireserver:/etc/apache2/conf.d # touch teambox.conf
  2. Editamos el archivo teambox.conf: 
    fireserver:/etc/apache2/conf.d # vi teambox.conf

    Y le agregamos la siguiente configuración:

    # -- ALIAS DEL SUBDIRECTORIO APUNTANDO A LA RUTA REAL DE
# LA HERRAMIENTA TEAMBOX.
Alias /teambox /opt/teambox/public

# -- DEFINICION DEL ENTORNO RAILS.
RailsEnv production
RailsBaseURI /teambox

# -- CONFIGURACIONES DEL DIRECTORIO DE TRABAJO.
<Directory "/opt/teambox/public">
    Options -MultiViews +FollowSymLinks +SymLinksIfOwnerMatch
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
  3. Creamos un enlace simbólico del directorio /opt/teambox/public al directorio /srv/www/htdocs: 
    fireserver:/etc/apache2/conf.d # ln -s /opt/teambox/public/ /srv/www/htdocs/teambox
  4. Para utilizar este método debemos ajustar la configuración de la herramienta web Teambox, específicamente la directiva app_domain del archivo /opt/teambox/config/teambox.yml deberá ser configurada con el dominio basado en subdirectorios. Para ello editamos nuevamente el archivo /opt/teambox/config/teambox.yml: 
    fireserver:/etc/apache2/conf.d # vi /opt/teambox/config/teambox.yml

    y configuramos la directiva app_domain de forma parecida a lo que se muestra a continuación:

    app_domain: ip_o_nombre_dominio_servidor/teambox/

    Guardamos los cambios y salimos del archivo para continuar con otras configuraciones.

Configuración de los niveles de ejecución y arranque del servicio web Apache:

  1. Activamos los niveles de ejecución para el servicio apache2 de la siguiente manera: 
    fireserver:~ # chkconfig --add apache2
  2. Luego procedemos a iniciar (o reiniciar si ya se estaba ejecutando) el servicio apache2 con el siguiente comando: 
    fireserver:~ # service apache2 start

Configuración del Cortafuegos

  1. Para que podamos acceder a la herramienta desde otro equipo remoto necesitamos abrir los puertos HTTP (80) y HTTPS (443) en el firewall del servidor, para ello editamos el archivo SuSEfirewall2 del directorio /etc/sysconfig: 
    fireserver:~ # vi /etc/sysconfig/SuSEfirewall2

    y le asignamos los servicios apache2 y apache2-ssl a la directiva FW_CONFIGURATIONS_EXT como se muestra a continuación:

    FW_CONFIGURATIONS_EXT="sshd apache2 apache2-ssl"
  2. Luego reiniciamos el cortafuegos para que la nueva configuración tome efecto, lo realizamos con el siguiente comando: 
    fireserver:~ # rcSuSEfirewall2 restart

Acceso a Teambox

  1. Si para acceder a la herramienta Teambox hemos configurado el servicio Apache con virtual hosts, debemos utilizar el nombre de dominio totalmente cualificado que hemos definido y que debe ser correctamente resueltos por algún servidor DNS o mediante alguna entrada al archivo /etc/hosts en la máquina cliente que se trata de conectar a la herramienta. Como ejemplo podríamos tener la siguiente URL: 
    http://teambox.mi_dominio.local
  2. Si en el caso contrario hemos configurado el acceso a la herramienta Teambox mediante un subdirectorio en Apache, la URL deberá ser similar a la siguiente: 
    http://ip_o_nombre_dominio_servidor/teambox
  3. A continuación les dejo con una captura de pantalla de la herramienta Teambox en plena ejecución:

Artículos Relacionados

Fuentes

Enlaces Externos

Archivado en Informática Etiquetado con , , , , ,

Problemas con el arranque de un openSUSE virtualizado

abril 29, 2011 Dejar un comentario

Les comento brevemente como viene la mano con este caso, estos días estuve preparando en el trabajo una instalación estándar de openSUSE 11.4 en VirtualBox para pruebas de configuración. La idea fue crear una copia de seguridad de esa instalación básica antes de jugar con ella para que en el momento en que necesite una instalación limpia para realizar otras configuraciones que requieran un entorno nuevo pudiera generar rápidamente a partir de ella una nueva máquina virtual sin realizar todo el tedioso trabajo de instalar desde cero el sistema operativo.

Para crear la copia de seguridad utilicé el asistente Exportar servicio virtualizado de VirtualBox cuyo proceso finalizó correctamente, el problema surgió durante el arranque del sistema operativo luego de haberlo importado a partir de la copia de seguridad con el asistente Importar servicio virtualizado de VirtualBox, tarea que por cierto trascurrió sin problemas.

El problema lo podrán apreciar en la siguiente captura:

Identificación del Problema

Por alguna extraña razón el proceso de arranque del sistema operativo fue incapaz de ubicar las particiones del sistema operativo para continuar con el arranque normal, por lo cual me puse a investigar el origen de dicho problema. Luego de indagar “des-organizadamente” por la web y de realizar múltiples pruebas con el asistente de recuperación y con un LiveCD de la propia distribución pude llegar a la conclusión (muy personal por cierto, que quede claro) que durante el proceso de importación, la herramienta VirtualBox creó el disco duro virtual con un ID totalmente distinto al de la instalación original, con lo cual las referencias que utilizaba el sistema operativo quedaron inválidas, ya que apuntaban a un dispositivo que había cambiado de nombre.

En mi caso, el ID del disco duro virtual de la instalación original en VirtualBox era ata-VBOX_HARDDISK_VB4fbf3510-08771d94 haciéndose referencia al mismo en los archivos menu.lst del grub y fstab. Sin embargo, en la instalación importada desde la copia de seguridad el ID del disco duro virtual cambió a ata-VBOX_HARDDISK_VBd2522280-a69b1bab, con lo cual las referencias de los archivos menu.lst y fstab ya no servían para nada, dando como resultado el error que ya apreciaron en la imagen superior.

Solución del Problema

Los pasos para solucionar este problema fueron elaborados íntegramente por mí como resultado de la intensa investigación y la gran pérdida de tiempo que supuso encontrarla jaja, así que no esperen demasiados fundamentos elaborados que justifiquen que este es el mejor método para solucionar el inconveniente. Otra cosa que quisiera dejar en claro es que para la reparación de este problema he utilizado la herramienta de rescate que viene con el DVD de instalación de openSUSE, también puede funcionar utilizando un LiveCD, los pasos son los mismos.

Hechas las aclaraciones correspondientes comenzamos con la secuencia de pasos para arreglar este problema:

  1. Lo primero que tenemos que hacer es tratar de arrancar la máquina virtual con el DVD de instalación de la distribución, en mi caso openSUSE 11.4 i586. Esto lo hacemos agregando el ISO del DVD en el apartado Almacenamiento de las configuraciones de la máquina virtual afectada o colocando el DVD físico en la lectora del host anfitrión y configurando ésta como origen para la lectora virtual.
  2. Luego debemos verificar que en el orden de arranque de la lectora virtual esté en primer lugar, esto se configura en el apartado Sistema de la ventana de configuraciones:
  3. Procedemos a arrancar la máquina virtual y en el cargador de arranque del DVD de instalación seleccionamos la opción Sistema de Rescate.
  4. Una vez iniciado el modo rescate nos conectamos con el usuario root: 
    Rescue login: root
Rescue:~ #
  5. Luego procedemos a montar las particiones del disco duro virtual que tienen los directorios /boot y /etc. En mi caso tenía solo dos particiones en el disco duro virtual, una para la partición swap y otra para el / (root), con lo cual la instancia del asistente de rescate identificó dos unidades del dispositivo sda, la partición sda1 correspondiente a swap y la partición sda2 correspondiente a la raíz. 
    Rescue:~ # ls /dev/sda*
/dev/sda   /dev/sda1   /dev/sda2
Rescue:~ #

    Para este caso solo necesité montar la partición sda2, ya que en la misma se encuentran los directorios y archivos que se necesitan modificar.

    Rescue:~ # mount /dev/sda2 /mnt

    Como se podrá apreciar la partición sda2 fue montada en el directorio /mnt del sistema de archivos del asistente de rescate.
    OBS: En el caso de que tengan particiones específicas para el directorio /boot y / deberán montar ambas particiones para realizar los ajustes.

  6. Una vez montada la partición, editamos el archivo de configuración fstab para realizar las correcciones: 
    Rescue:~ # vi /mnt/etc/fstab

    Al editarlo por primera vez su configuración fue la siguiente:

    /dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 swap                 swap       defaults              0 0 
/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 /                    ext4       acl,user_xattr        1 1 
proc                 /proc                proc       defaults              0 0 
sysfs                /sys                 sysfs      noauto                0 0 
debugfs              /sys/kernel/debug    debugfs    noauto                0 0 
usbfs                /proc/bus/usb        usbfs      noauto                0 0 
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

    Como se observa, los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 en el directorio /dev/disk/by-id son las particiones correspondientes a las unidades swap y / respectivamente, si los tratamos de buscar en el directorio /mnt/dev/disk/by-id nos daremos cuenta que ni siquiera se encuentra accesible la carpeta disk, al menos desde el asistente de rescate.

    En realidad lo que sucede es que los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 del directorio /dev/disk/by-id son meros enlaces a los dispositivos /dev/sda1 y /dev/sda2 (esto lo veremos más adelante) respectivamente, por lo cual podemos reemplazar ambas referencias en el archivo fstab con las referencias a los dispositivos sda1 y sda2, quedando la configuración similar a lo que sigue:

    /dev/sda1            swap                 swap       defaults              0 0
/dev/sda2            /                    ext4       acl,user_xattr        1 1
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

    Con esto ya tenemos corregido este archivo, guardamos los cambios y volvemos al promp para continuar con las demás correcciones.

  7. El siguiente paso consiste en realizar los mismos cambios en el archivo de configuración menu.lst del gestor de arranque grub, para ello editamos el archivo menu.lst ubicado en el directorio /mnt/boot/grub: 
    Rescue:~ # vi /mnt/boot/grub/menu.lst

    La configuración que tenía en mi caso fue la siguiente:

    # Modified by YaST2. Last modification on lun abr 25 17:32:14 PYT 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0 timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 resume=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 splash=silent quiet showopts vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Disquete rootnoverify (fd0) chainloader +1

    Al igual que en el archivo fstab debemos reemplazar las referencias de los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 por los dispositivos sda1 y sda2 respectivamente, el archivo corregido quedó como se muestra a continuación:

    # Modified by YaST2. Last modification on lun abr 25 17:32:14 PYT 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0 timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/sda2 resume=/dev/sda1 splash=silent quiet showopts vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/sda2 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Disquete rootnoverify (fd0) chainloader +1

    Corregidos los dispositivos podemos salir del archivo guardando previamente los cambios.

  8. Por último solo resta reiniciar la máquina virtual para salir del modo rescate. 
    Rescue:~ # reboot

Con estos pasos el problema debería quedar solucionado y al iniciar nuevamente la máquina virtual el sistema operativo debería arrancar con total normalidad.

Una vez iniciado el sistema operativo podremos verificar que los ID’s de las particiones del disco duro virtual ya no son los mismos que los ID’s de la instalación original. Esto lo podemos hacer listando el contenido del directorio /dev/disk/by-id (que ahora si ya estará disponible) y compararlos con los ID originales como se muestra a continuación:

fireserver:~ # ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root  9 Apr 29 08:18 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0
lrwxrwxrwx 1 root root  9 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part2 -> ../../sda2
lrwxrwxrwx 1 root root  9 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab-part2 -> ../../sda2
fireserver:~ #

Como se puede observar arriba, estas unidades son enlaces a los dispositivos sda, sda1 y sda2. Comparando los nombres de los dispositivos que se encontraban en los archivos menu.lst y fstab previa modificación y los nombres reales de los dispositivos del directorio /dev/disk/by-id tenemos las siguientes claras diferencias que dieron origen a todo este problema.

En menu.lst y fstab: ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1
En /dev/disk/by-id/: ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part1

En menu.lst y fstab: ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2
En /dev/disk/by-id/: ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part2

En fin, esto se volvió a hacer largo, será hasta la próxima..

Datos de los programas utilizados:

  • VirtualBox v4.0.4 r70112
  • openSUSE 11.4 i586

Enlaces Externos:

Archivado en Informática Etiquetado con , , , ,

Problemas en openSUSE con Impresoras USB Epson LX-300

marzo 16, 2011 Dejar un comentario

En realidad no es solo un problema de openSUSE, sino de la librería libusb y del backend usb de cups ubicado en el directorio /usr/lib/cups/backend. El problema consiste en que al conectar dos impresoras similares, en este caso impresoras de la marca Epson con puertos USB (en mi caso LX 300+II),  se genera un conflicto asociado a la dirección a donde apuntan ambas impresoras al configurarlas con el asistente de Yast, ambas impresoras quedan asociadas al mismo recurso.

Si configuramos ambas impresoras por Yast y luego verificamos el archivo /etc/cups/printers.conf nos daremos cuenta que la directiva DeviceURI para ambas impresoras será la mismo, algo similar a lo que sigue:

DeviceURI usb://EPSON/LX-300+

Esto se debe a que el backend usb de cups es incapaz de obtener el ID de cada dispositivo, o mejor dicho, de cada hardware o impresora para definir cual es el dispositivo físico que se encuentra asociado al dispositivo lógico configurado en cups.

Si ejecutamos el backend de cups “usb” directamente en la consola nos aparecerá la siguiente respuesta:

linux:~ # cd /usr/lib/cups/backend/
linux:/usr/lib/cups/backend # ./usb
direct usb://EPSON/LX-300+ "EPSON LX-300+" "EPSON LX-300+" "MFG:EPSON;CMD:ESCP9,PRPII9,BDC,D4;MDL:LX-300+;CLS:PRINTER;DES:EPSON LX-300+;" ""
direct usb://EPSON/LX-300+ "EPSON LX-300+" "EPSON LX-300+"  "MFG:EPSON;CMD:ESCP9,PRPII9,BDC,D4;MDL:LX-300+;CLS:PRINTER;DES:EPSON  LX-300+;" ""
linux:/usr/lib/cups/backend #

El motivo del que no permite identificar adecuadamente entre las dos impresoras se explica en el punto 4.4.3 de este artículo, pero lo podríamos resumir que para obtener el ID del hardware el fabricante utiliza métodos propietarios y no mediante métodos estándares que son los utilizados por el backend de cups.

Solución del Problema

La mejor forma de solucionar este problema sería que en vez de conectar ambas impresoras con cables USB, conectemos una de las impresoras con un cable paralelo y la otra con un cable USB, lo que no generaría ningún problema en la identificación de ambas impresora.

Sin embargo, si lo mencionado anteriormente no es posible y solo disponemos de cables USB o placas madres sin puerto paralelo, podemos solucionarlo de una forma algo menos convencional y no muy recomendable siguiendo los pasos que van a continuación:

  1. Enchufar ambas impresoras en los puertos USB disponibles y encenderlas.
  2. Configurar las impresoras con YAST.
  3. Reiniciar la PC para que la secuencia de arranque se encargue de asignar a las impresoras su identificador de dispositivo lógico en el directorio /dev, esto lo recomiendo porque los puertos USB se encuentran enumerados y se van detectando en forma secuencial. Por ejemplo, si nuestra placa madre tiene 6 puertos USB los mismos van enumerados (según tengo entendido) del 0 (cero) al 5, si conectamos la primera impresora “A” al puerto USB2 y la otra impresora “B” al puerto USB3 y dejamos que la secuencia de arranque del sistema operativo detecte los dispositivos, sabremos perfectamente que en el directorio /dev la unidad lógica usblp0 corresponderá a la impresora “A” y que la unidad usblp1 corresponderá a la impresora “B” porque durante el arranque el sistema operativo habrá verificado primero el puerto USB2 y luego el puerto USB3.
  4. Ahora sabiendo perfectamente en que unidades lógicas se encuentra cada impresora, en el archivo /etc/cups/printers.conf debemos modificar la directiva DeviceURI de ambas impresoras y asignarles las URI que corresponden a sus unidades lógicas ubicadas en el directorio /dev mencionadas en el punto anterior. Primero editamos el archivo: 
    linux:~ # vi /etc/cups/printers.conf

    Modificamos su contenido y debería quedar similar a lo que sigue (la directiva DeviceURI se encuentra resaltada en rojo):

    # Printer configuration file for CUPS v1.4.4
# Written by cupsd on 2010-12-13 14:33
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
# Printer configuration file for CUPS v1.4.4
# Written by cupsd on 2010-12-13 14:33
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
# Printer configuration file for CUPS v1.4.4
# Written by cupsd on 2010-12-13 14:33
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<Printer epson0>
Info ONE EPSON LX-300+
Location linux
MakeModel IBM ProPrinterII Foomatic/ibmpro (recommended)
DeviceURI file:///dev/usblp0
State Idle
StateTime 1292251254
Type 8388612
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

<Printer epson1>
Info TWO EPSON LX-300
Location linux
MakeModel IBM ProPrinterII Foomatic/ibmpro (recommended)
DeviceURI file:///dev/usblp1
State Idle
StateTime 1292248513
Type 8388612
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
  5. Si queremos o necesitamos compartir las impresoras (como sucedió en mi caso), configuramos el servicio Samba para que levante todas las impresoras y definimos que la directiva printcap name = cups (si se utiliza /etc/printcap no va a funcionar). 
    linux:~ # vi /etc/samba/smb.conf
    # smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
# Date: 2010-07-05
[global]
        workgroup = informatica
        passdb backend = tdbsam
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        include = /etc/samba/dhcp.conf
        logon path = \\%L\profiles\.msprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = P:
        usershare allow guests = Yes
        add machine script = /usr/sbin/useradd  -c Machine -d /var/lib/nobody -s /bin/false %m$
        domain logons = No
        domain master = No
        netbios name = linux
        security = user
        usershare max shares = 100
        wins support = No

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = Yes
        guest ok = Yes
  6. Activamos los niveles de ejecución para los servicios Cups y Samba si aún no lo hemos hecho: 
    linux:~ # chkconfig --add cups
linux:~ # chkconfig --add smb
  7. Y por último reiniciamos ambos servicio para que se carguen las nuevas configuraciones y con eso ya debería quedar funcionando todo. 
    linux:~ # service cups restart
linux:~ # service smb restart

    8. Observaciones:

    Quisiera aclarar algo muy importante, tienen que tener en cuenta que si desconectan una impresora y la enchufan en otro puerto una vez iniciada la PC, o que hayan apagado ambas impresoras y luego las volvieron a encender en una secuencia incorrecta, es probable que el orden en que el sistema operativo monte las impresoras sea incorrecto. Esto se debe a que cuando el sistema operativo (ya arrancado) detecta la primera impresora que se enchufa la va a montar en la unidad lógica usblp0 sin importar en que puerto USB haya sido.

    Nuevamente pasamos a un ejemplo para aclarar esta situación: Si arrancamos el sistema operativo y desenchufamos ambas impresoras de los puertos USB nos daremos cuenta que en el directorio /dev no existirán unidades lógicas de las impresoras. Ahora si enchufamos el cable USB de la impresora “B” en el mismo puerto USB3 que mencionamos antes, nos daremos cuenta que el OS creará una unidad lógica en el directorio /dev, pero en vez de que el nombre de la unidad sea usblp1 será usblp0 porque es la primera impresora que se conecta. Luego si conectamos el cable USB de la impresora “A” al mismo puerto anterior USB2 tendremos que se montará la unidad lógica en el directorio /dev como usblp1 al ser la segunda impresora que se ha conectado. Lo interesante es que con esto logramos que todas las impresiones que antes enviamos a la impresora “A” a través de la unidad lógica /dev/usblp0 ahora lo estaremos enviando la impresora “B” y viceversa.

    Podemos comprender como el orden de conexión de los cables va a afectar la creación de las unidades, y como es muy tedioso andar configurando el DeviceURI cada vez que sucede esto, es fundamental prestarle mucha atención al orden de la secuencia de conexión o mejor dejar siempre que durante el arranque del sistema operativo detecte y monte las unidades lógicas de las impresoras con la secuencia correspondiente como se había sugerido en el tercer punto de los pasos antes mencionados.

Enlaces Externos

Archivado en Guías, Informática Etiquetado con , , ,

Gráficos para Interfaces Web

enero 4, 2011 Dejar un comentario

Con la necesidad de realizar gráficos que necesiten ser actualizados constantemente, surgió la idea de buscar aplicaciones ya construidas para generar gráficos y con la condición de que los mismos sean para una interfaz web, buscando me encontré con este sitio que resumía 10 librerías para generación de tráfico mediante php, probé varias pero la que más me ha gustado por su simplicidad de instalación, configuración, uso y menor cantidad de restricciones es la librería amCharts

Permite generar gráficos en flash muy interesantes y de diversos tipos, la datos estadísticos para generar los gráficos se suele guardar en archivos de texto plano o archivos xml bajo una estructura definida desde donde son interpretados por la aplicación flash.

Si bien esta librería permite generar gráficos muy potentes en Flash, tengo que decir que según mi experiencia no conviene crear gráficos que tengan un archivo de entrada muy extenso, ya que esto hace que el gráfico sea muy pesado y que la experiencia del usuario utilizando estos gráficos sea bastante mala.

Archivado en Informática Etiquetado con , , , ,

← Entradas más antiguas

Seguir

Get every new post delivered to your Inbox.