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

• Instalación y configuración de MySQL y phpMyAdmin
  

Fuentes

• https://github.com/teambox/teambox/wiki/Installing-locally
• https://github.com/teambox/teambox/wiki/Installing-on-Ubuntu
• http://wiki.mediatemple.net/w/(ve):Install_Teambox
• http://www.stephenierodiaconou.com/blog_Installing_Teambox_-_A_Full_Guide_For_Debian

Enlaces Externos

• Teambox
• Github

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:

• VirtualBox

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

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

• http://tldp.org/HOWTO/Printing-HOWTO/kernel.html

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.

El contenido del correo va a continuación,  saludos..

–

Los duendes de estadísticas de WordPress.com han analizado el desempeño de este blog en 2010 y te presentan un resumen de alto nivel de la salud de tu blog:

El Blog-Health-o-Meter™ indica: Wow.

Números crujientes

Alrededor de 3 millones de personas visitan el Taj Mahal cada año. Este blog fue visto cerca de 30,000 veces en 2010. Si el blog fuera el Taj Mahal, se necesitarían alrededor de 4 días para visitarlo.

En 2010, publicaste 11 entradas nueva, haciendo crecer el arquivo para 40 entradas. Subiste 58 imágenes, ocupando un total de 8mb. Eso son alrededor de 1 imágenes por semana.

The busiest day of the year was 25 de noviembre with 165 views. The most popular post that day was Manual para configurar un Servidor FTP con Vsftpd en openSUSE.

¿De dónde vienen?

Los sitios de referencia más populares en 2010 fueran search.conduit.com, google.com.mx, google.es, google.com.co y google.com.pe.

Algunos visitantes buscan tu blog, sobre todo por linux para usb, piren, mexanime.org, openvas y servidor ftp suse.

Lugares de interés en 2010

Estas son las entradas y páginas con más visitas en 2010.

Manual para configurar un Servidor FTP con Vsftpd en openSUSE marzo, 2008
78 comentários

Seleccion de Fuentes y Estilos para Impresoras Matriciales marzo, 2008
69 comentários

Configuración del servicio VNC en RedHat EL agosto, 2008
24 comentários

Manual para configurar Subversion + Apache + SSL en openSUSE mayo, 2008
17 comentários

Distribución GNU/Linux para crear un Live USB abril, 2008
10 comentários

Algunas de tus entradas más populares fueran publicadas antes de 2010. ¡Tus escritos permanecen! Considera escribir sobre eses temas de nuevo.

El PDF pesa unos 2,24 Mb y posee solo 8 páginas, las imágenes fueron escaneadas con una muy buena calidad para que sea bien legible, espero que les sea de ayuda y que sirva para todos aquellos que tengan que trabajar con este tipo de impresoras.

PDF - Comandos ESC/POS Epson LX-300

Artículos Relacionados:

• Seleccion de Fuentes y Estilos para Impresoras Matriciales

Scripts:

• Prometheus QoS.
• Wondershaper
• RShaper
  

Programas:

• Mastershaper
  

Manuales y Tutoriales Online:

• Linux Advanced Routing & Traffic Control (Versión en Español)
• How To Accelerate Your Internet
• http://www.etxea.net/docu/qos/qos.html
• Rshaper: http://blografia.net/vicm3/docs/nucleo.html

Distribuciónes Linux Especializadas:

• IPCop

• Que equipos están traficando.
• De donde y hacia donde van los paquetes.
• La cantidad de paquetes y sus respectivos tamaños.
• Total de paquetes TCP, UDP y otros.
• Lo enviado y lo recibido.
• Los tipos de servicio utilizados.
• Los puertos a los cuales se ha conectado una u otra máquina.
• etc.

Para mayor información sobre la misma pueden visitar este artículo en Wikipedia.

Requisitos e Instalación de Ntop

Necesitamos tener añadido el repositorio OSS a nuestro gestor de paquetes, si no lo tenemos añadido lo podemos hacer con el siguiente comando, en este caso para la versión 11.3 de openSUSE:

fireserver:~ # zypper ar -c -n ‘OSS – Open Source Software Repo’ http://download.opensuse.org/distribution/11.3/repo/oss/ OSS

Para instalar la herramienta Ntop en openSUSE lo podemos hacer con el siguiente comando:

fireserver:~ # zypper install ntop

Configuración de la Herramienta Ntop

Si bien las configuraciones que trae la herramienta por defecto luego de instalarla permiten realizar análisis básicos, es importante realizar ciertos ajustes en sus archivos de configuración y conocer algunas funcionalidades extras para que no tengamos problemas a la hora de analizar la información resultante.

Mi experiencia con la herramienta fue frustrante durante el principio, cuando trataba de comparar la información recabada de la herramienta con las pruebas de tráfico que había preparado para analizar si la misma realmente funcionaba correctamente encontré muchas inconsistencias que no comprendía hasta el punto de querer reemplazar la herramienta por otra, sin embargo, el problema no se encontraba en la herramienta, si no en su configuración.

Como esta herramienta era indispensable para recolectar la información para mi proyecto de Tesis, encontrar las configuraciones correctas llevó buen tiempo de investigación, afectando en parte al cumplimiento de los plazos establecidos, cuota de fracaso que aportó para la cancelación del proyecto, ahora me arrepiento de no haber leído el man de la herramienta jeje.

A continuación se citarán los pasos para configurar la herramienta Ntop:

1. Para comenzar necesitamos dirigirnos al directorio /etc/sysconfig y editar el archivo ntop:
   

   fireserver:~ # cd /etc/sysconfig/
   fireserver:/etc/sysconfig # vi ntop

2. Una vez editado el archivo buscamos la directiva NTOPD_IFACE para configurar el nombre de la interfaz por la cual se estarán capturando los paquetes, si nuestro equipo cuenta con varias interfaces de red podemos destinar una exclusivamente para la captura de tráfico de red y destinar otra para la gestión remota y acceso a los servicios de nuestra red local, todo depende de las necesidades y de lo que tratamos de analizar, en mi caso la directiva quedó configurada como sigue:
   

   NTOPD_IFACE=”eth1“

3. La siguiente directiva a configurar es NTOPD_PORT y permite limitar el acceso remoto como así también especificar el puerto para acceder a la interfaz web de la herramienta Ntop a través de nuestro navegador preferido, por defecto la configuración es 127.0.0.1:3000 pero la misma limita a que solo se pueda acceder a la interfaz web desde el equipo donde se encuentra instalada la herramienta y no remotamente, si tenemos un servidor dedicado para estas tareas en una sala aparte y, por comodidad y otros temas, deseamos tener acceso remoto a través del protocolo http (protocolo sin encriptación), podemos configurar la directiva especificando solamente el puerto y nada más como se muestra a continuación:
   

   NTOPD_PORT=”3000“

4. Pasamos a la directiva NTOPD_SSL_PORT, que al igual que la directiva NTOPD_PORT permite limitar el acceso remoto como especificar el puerto para el acceso a la interfaz web de la herramienta Ntop pero específicamente para el protocolo de navegación segura https, mi configuración para esta directiva fue la siguiente:
   

   NTOPD_SSL_PORT=”3001“

5. La directiva NTOP_USER permite definir con que usuario del sistema operativo se va a ejecutar el servicio Ntop, por defecto en las nuevas versiones de openSUSE se encuentra configurado el usuario de sistema ntop, en versiones anteriores el usuario que aparecía por defecto era el usuario de sistema wwwrun, que como saben es el usuario encargado de la ejecución del servicio Apache, yo recomiendo dejar la configuración por defecto:
   

   NTOP_USER=”ntop“

6. La directiva final que recomiendo configurar es NTOP_ARGS, la misma permite agregar una serie de funcionalidades a la herramienta Ntop mediante la especificación de varios argumentos consecutivos separados por espacios a la directiva. Los argumentos son todos opcionales y la lista de argumentos válidos está disponible en el man de la herramienta Ntop, son los mismos argumentos que se puede pasar a la herramienta Ntop si la queremos ejecutar manualmente desde la linea de comandos. En mi caso está directiva la tengo configurado de la siguiente forma:
   

   NTOP_ARGS=”-o -c -r 300 -p /etc/ntop/protocol_list.txt -m 192.168.2.0/24“

   
   Aclaración de Argumentos:

   Como habrán visto más arriba son varios los argumentos que he especificados a la directiva NTOP_ARGS, la funcionalidad y el motivo por el cual cada argumento fue incluido se expone a continuación:

   • -o: Ntop es una herramienta híbrida que permite analizar redes de capa 2 y 3 del modelo TCP/IP, que son la capa de Enlace de Datos (Acceso al Medio) y la capa de Red respectivamente, si queremos realizar un seguimiento individual al tráfico de los equipos que se encuentran en sub-redes corporativas (red segmentada) o de redes externas, es recomendable incluir este argumento para que tráfico sea agrupado por las direcciones IP, ya que de forma contraria agruparía todo el tráfico de los equipos de las sub-redes en base a las direcciones MAC del equipo ruteador y no por las direcciones MAC de la interfaz de red de los equipos físicos remotos que queremos analizar. A continuación la descripción del parámetro según el man:
     

     -o | –no-mac
     ntop is a hybrid layer 2/3 network monitor. That is, it uses both the lower level, physical device address – the MAC (Media Access Control) address – and the higher level, logical, tcp/ip address (the familiar www.ntop.org or 131.114.21.9 address). This allows ntop to link the logical addresses to a physical machine with multiple addresses (This occurs with virtual hosts or additional addresses assigned to the interface, etc.) to present consolidated reporting.

   • -c: Cuando se instala la herramienta desde los repositorios, varios parámetros se encuentran configurados por defecto, este es el caso del parámetro PARM_HOST_PURGE_MINIMUM_IDLE que por defecto se encuentra definido a solo 10 minutos (según mi conocimiento en openSUSE), este parámetro configura el tiempo de inactividad que se requiere de un equipo para purgar toda su información. Según el man tenemos la siguiente definición para el argumento -c:
     

     -c | –sticky-hosts
     Use this parameter to prevent idle hosts from being purged from memory.

     By default idle hosts are periodically purged from memory. An idle host is identified when no packets from or to that host have been monitored for the period of time defined by the value of PARM_HOST_PURGE_MINIMUM_IDLE in globals-defines.h.

     Les recomiendo configurar este parámetro como argumento para que durante el arranque de la herramienta ya se cargue la configuración, les comento que he tenido mala experiencia tratando de configurar este parámetro desde la interfaz WEB.

   • -r 300: Este argumento configura la interfaz Web de la herramienta para que cada 5 minutos actualice el contenido de la misma, la definición para este argumento en el man es el siguiente:
     

     -r | –refresh-time
     Specifies the delay (in seconds) between automatic screen updates for those generated HTML pages which support them. This parameter allows you to leave your browser window open and have it always displaying nearly real-time data from ntop.

     The default is 3 seconds. Please note that if the delay is very short (1 second for instance), ntop might not be able to process all of the network traffic.

   • -p /etc/ntop/protocol_list.txt: Como sabemos, la herramienta Ntop agrupa por cada equipo el tráfico que han generado, pero a la vez por cada equipo podemos saber que tipo de tráfico ha generado, si fue tráfico http, ftp, etc., por defecto la herramienta identifica un grupo limitado de tipos de tráfico y el resto es agrupado como Otros, sin embargo, esta lista puede ser ampliada con este parámetro con el cual especificamos la ruta hacia un archivo de texto plano en donde podemos personalizar los tipos de servicios que nos interesan mediante una nomenclatura determinada. El contenido del archivo /etc/ntop/protocol_list.txt será abarcado más adelante en este mismo tutorial. Nuevamente la información del man:
     

     -p | –protocols
     This parameter is used to specify the TCP/UDP protocols that ntop will monitor. The format is <label>=<protocol  list>  [,  <label>=<protocol list>],  where  label  is  used to symbolically identify the <protocol list>. The format of <protocol list> is <protocol>[|<protocol>], where <protocol>  is  either a valid protocol specified inside the /etc/services file or a numeric port range (e.g. 80, or 6000-6500).

   • -m 192.168.2.0/24: Si por ejemplo nuestro servidor de monitoreo Ntop se encuentra en la red 192.168.1.0/24, por defecto, todos los equipos de esa red que hayan generado algún tráfico y que haya sido detectado por la herramienta serán agrupados como tráfico LOCAL, demás tráficos será interpretado como tráfico REMOTO y será agrupado en otro sector.
     Si aparte de la red 192.168.1.0/24 tuvieramos una red 192.168.2.0/24 que corresponde a otro sector o a una sucursal de nuestra empresa y a la cual nos conectados mediante un ruteador, si queremos incluir a los equipos de esta red en la sección LOCAL de la herramienta tenemos que especificar manualmente la red que queremos agregar con el parámetro -m, en este caso se ha agregado la red 192.168.2.0/24, si deseamos agregar más redes lo podemos hacer especificando las redes separadas por comas: Ej: -m 192.168.2.0/24,192.168.3.0/24,192.168.4.0/24. 

     -m | –local-subnets
     ntop determines the ip addresses and netmasks for each active interface.  Any traffic on those networks is considered local.  This parameter allows the  user  to  define
     additional networks and subnetworks whose traffic is also considered local in ntop reports. All other hosts are considered remote.

7. Luego de las configuraciones anteriores, en mi caso el archivo /etc/sysconfig/ntop quedó como se muestra a continuación:
   

   ## Path: Network/Monitors/Ntop
   ## Description: ntop startup parameters
   ## Type: string(eth0)
   ## Default: eth0
   ## Config:
   ## ServiceRestart: ntop
   #
   # Specifies the network interface used by ntop
   #
   NTOPD_IFACE=”eth1“

   ## Type: ip
   ## Default: 127.0.0.1:3000
   #
   # Supposing to start ntop at the port 3000,
   # the URL to access is http://hostname:3000/
   #
   # Please note that an HTTP server is NOT needed in
   # order to use the program in interactive mode.
   #
   NTOPD_PORT=”3000“

   ## Type: integer(0:65535)
   ## Default:
   #
   # define SSL port. Please note, that you have to generate
   # a certificate to run run ntop with this option.
   # This may be done with the commands:
   # openssl req -new -x509 -sha1 -extensions v3_ca -nodes -days 365 -out cert.pem
   # cat privkey.pem cert.pem > /etc/ntop/ntop-cert.pem
   # /bin/rm -f privkey.pem cert.pem
   #
   # NTOPD_SSL_PORT=”3001″
   #
   NTOPD_SSL_PORT=”3001“

   ## Type: string
   ## Default: “wwwrun”
   #
   # define the user to run ntop. This should not be root!
   #
   NTOP_USER=”wwwrun“

   ## Type: string
   ## Default: “”
   ## ServiceRestart: ntop
   #
   # Additional arguments when starting ntop with the init script
   # /etc/init.d/ntop or rcntop.
   #
   # See man 8 ntop for all available commandline options.
   #
   NTOP_ARGS=”-o -c -r 300 -p /etc/ntop/protocol_list.txt -m 192.168.18.0/24,192.168.16.0/24“

8. Ampliación de Puertos conocidos: El siguiente paso consiste en crear el archivo protocol_list.txt en el directorio /etc/ntop según lo especificado como argumento en el archivo /etc/sysconfig/ntop. En este archivo podemos agregar una lista personalizada de tipos de tráfico que queremos separar en la herramienta Ntop para su posterior análisis, en mi caso la lista quedó como sigue:
   

   HTTP=http|www|https
HTTP_SQUID=3128
HTTP_ISA=8080|8081
ORA_HTTP=7778
CamSegur=1001
Microsoft-DS=445
FTP=ftp|ftp-data
DNS=name|domain
Telnet=telnet|login
NBios-IP=netbios-ns|netbios-dgm|netbios-ssn
Mail=pop-2|pop-3|pop3|kpop|smtp|imap|imap2
DHCP-BOOTP=67-68
SNMP=snmp|snmp-trap
NNTP=nntp
NFS=mount|pcnfs|bwnfs|nfsd|nfsd-status
X11=6000-6010
SSH=22
Gnutella=6346|6347|6348
Kazaa=1214
WinMX=6699|7730
DirectConnect=0
eDonkey=4661-4665
Messenger=1863|5000|5190-5193
IM=12890
Iperf=5001
Norton=8014
VNC=5900
Ntop=3000|3001
RemoteShell=514

   Para especificar un servicio personalizado primero colocamos un alias, por ejemplo HTTP_ISA, seguido va el signo igual “=” y luego el puerto o los puertos que deseamos incluir, en este caso los puertos son 8080 y 8081, los mismos van separados por el carácter “|”, en vez de los puestos numéricos también se pueden utilizar sus respectivos alias especificados en el archivo /etc/services.

9. Terminada la configuración específica de la herramienta pasamos a ajustar los niveles de ejecución para el arranque automático de la herramienta Ntop:
   

   fireserver:~ # chkconfig -level 35 ntop on

10. Seteamos la contraseña del usuario admin de la herramienta Ntop por primera vez:
    

    fireserver:~ # ntop -A -u wwwrun
    Sat Jun 13 11:24:08 2009  NOTE: Interface merge enabled by default
    Sat Jun 13 11:24:08 2009  Initializing gdbm databases

    ntop startup – waiting for user response!

    Please enter the password for the admin user:
    Please enter the password again:
    Sat Jun 13 11:24:24 2009  Admin user password has been set
    fireserver:~ #

11. Abrimos los puertos en el firewall para permitir el acceso a la interfaz Web de la herramienta, para ello editamos el archivo SuSEfirewall2 del directorio /etc/sysconfig, buscamos la directiva FW_SERVICES_EXT_TCP a la que le agregamos los dos puertos separados por un espacio, luego se guardan los cambios y se reinicia el servicio del firewall, los pasos quedan como sigue:
    

    fireserver:~ # vi +255 /etc/sysconfig/SuSEfirewall2

    FW_SERVICES_EXT_TCP=”3000 3001″

    fireserver:~ # rcSuSEfirewall2 restart

12. Por último solo resta iniciar el servicio ntop:
    

    fireserver:~ # service ntop start
    Starting service ntop done
    fireserver:~ #

13. En este punto ya podemos acceder a la herramienta a través de su interfaz web mediante las siguientes URL:
    

    http://ip_o_nombre_servidor:3000
    https://ip_o_nombre_servidor:3001

Configuración de Switch para permitir Packet Sniffing

Cuando un switch recibe un paquete que tiene como destinatario a un equipo conectado al puerto 1 del mismo, el equipo solo enviará a ese puerto el paquete de datos, haciendo que sea imposible que ese mismo paquete sea visible desde otro equipo que está conectado al mismo switch en otro puerto, a menos que….

Si, a menos que el switch en cuestión sea administrable y que nosotros tengamos acceso a él para configurar un puerto de mirroring al cual debe estar conectado el equipo de monitoreo (con herramientas para sniffing al estilo Ntop, Wireshark, tcpdump, etc), a este puerto le podemos enviar una copia de todo el tráfico recibido en el puerto que queremos monitorear, con esto estaríamos haciendo traffic mirroring.

Traffic Mirroring

Traffic mirroring consiste en reflejar todo el tráfico recibido y enviado por varios puertos hacia un puerto especial para permitir a los administradores de red poder analizar los paquetes mediante técnicas de sniffing.

Leyendo un artículo que ya no está online encontré un fragmento de texto relacionado con el tema y que me pareció bastante interesante:

Algunos switches permiten configurar uno de sus puertos como monitor o spanning port, para que se copie el trafico que va a traves del switch (normalmente solo el de uno de sus puertos) a ese puerto, funcionando como un Hub. Esto le sirve al administrador de la red para poder examinar problemas que ocurran. No siempre se puede enviar el 100% del trafico al puerto monitor, depende sobre todo de la carga de la red.

Limpieza Forzada de Datos y Gráficos estadísticos de Ntop

1. Se para el servicio Ntop:

   fireserver:~ # service ntop stop

2. Se procede a eliminar las carpetas en donde se encuentra almacenada la información relacionada a los monitoreos anteriores.

   fireserver:/var/lib/ntop # cd

   fireserver:~ # cd /var/lib/ntop/

   fireserver:/var/lib/ntop # ls

   LsWatch.db  addressQueue.db  dnsCache.db  fingerprint.db  interfaces  macPrefix.db  ntop_pw.db  prefsCache.db  rrd

   fireserver:/var/lib/ntop # rm -Rf interfaces/

   fireserver:/var/lib/ntop # rm -Rf rrd/

3. Se restablece el servicio Ntop.

   fireserver:~ # service ntop start

y con eso ya está, hemos eliminado toda la información de los monitoreos anteriores.

Capturas de Pantalla

Observaciones

• La instalación de la herramienta Ntop y las configuraciones presentadas en esta guía fueron realizadas con el sistema operativo openSUSE Linux en su versión 11.3 y con la arquitectura x86.

Enlaces Externos

Ntop en Wikipedia
Sitio Oficial Ntop
Port Mirroring

Con este artículo lo que se busca es definir los pasos a seguir para instalar la herramienta open source Cacti en la distribución Linux openSUSE, quedando a cargo de los lectores investigar la manera de utilizar y sacar el mayor provecho a esta herramienta.

Requisitos

1. Se necesitan tener instalados los siguientes paquetes:
   

   apache2
   apache2-mod_php5
   php5
   php5-mysql
   php5-snmp
   mysql-community-server
   net-snmp

2. Para instalar los paquetes con zypper tenemos que ejecutar el siguiente comando:
   

   fireserver:~ # zypper in apache2 apache2-mod_php5 php5 php5-mysql php5-snmp mysql-community-server net-snmp

OBS: Para instalar y configurar el motor de base de datos MySQL pueden seguir el manual MySQL y phpMyAdmin en openSUSE.

Instalación de la Herramienta Cacti

Los pasos que se siguieron para instalar esta herramienta de monitoreo son los siguientes:

1. Para comenzar les recomiendo buscar el paquete de instalación del software para su respectiva versión y arquitectura de openSUSE en el sitio oficial http://software.opensuse.org para luego instalarlo mediante el método One-Click Install. Es recomendable siempre instalar los paquetes de los repositorios oficiales que los pertenecientes a las contribuciones, principalmente porque el software de estos repositorios suelen ser en su gran mayoría muy estables.
2. El siguiente paso consiste en crear en el motor de base de datos MySQL una nueva base de datos para la herramienta Cacti.
   

   fireserver:~ # mysqladmin -u root -pcontraseña_de_root create cacti

3. Importamos una base de datos por defecto para la herramienta Cacti:
   

   fireserver:~ # mysql -u root -pcontraseña_de_root cacti < /usr/share/cacti/cacti.sql

4. Nos conectamos a la base de datos mysql con el usuario root para crear un nuevo usuario y otorgarle los permisos correspondientes para poder acceder y modificar el contenido de la base de datos cacti creada en el punto 2.
   

   fireserver:~ # mysql -u root -pcontraseña_de_root mysql

   Welcome to the MySQL monitor. Commands end with ; or \g.
   Your MySQL connection id is 295
   Server version: 5.1.46-log SUSE MySQL RPM

   Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
   This software comes with ABSOLUTELY NO WARRANTY. This is free software,
   and you are welcome to modify and redistribute it under the GPL v2 license

   Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

   mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY ‘contraseña_para_cactiuser’;
   Query OK, 0 rows affected (0.00 sec)

   mysql> flush privileges;
   Query OK, 0 rows affected (0.00 sec)

   mysql> exit
   Bye

5. Editamos el archivo config.php ubicado en el directorio y especificamos el tipo de base de datos, la base de datos por defecto a ser utilizada por la herramienta, el nombre del host en la cual se encuentra la base de datos y la definición del nombre del usuario y su respectiva contraseña con el cual Cacti se conectará a su base de datos, por otro lado, en el caso de que hayamos modificado el número de puerto por defecto en el que el motor de base de datos MySQL atiende las peticiones de conexión, ese mismo puerto lo tendremos que especificar en el archivo config.php.
   

   fireserver:~ # vi /usr/share/cacti/include/config.php

   $database_type = “mysql”;
   $database_default = “cacti”;
   $database_hostname = “localhost”;
   $database_username = “cactiuser”;
   $database_password = “contraseña_de_cactiuser”;
   $database_port = “3306″;

   Guardamos los cambios y cerramos el archivo config.php para pasar al siguiente punto de configuración.

6. En este paso tenemos que crear en el directorio /usr/share/cacti la carpeta log, luego que aplicar los permisos apropiados para los directorios rra y log, como la herramienta será ejecutada a través del servicio apache, debemos asignar a los directorios el usuario/grupo wwwrun/www respectivamente de forma recursiva para que el servicio pueda leer y escribir en dichos directorios.
   

   fireserver:~ # mkdir /usr/share/cacti/log
   fireserver:~ # chown -Rf wwwrun:www /usr/share/cacti/rra
   fireserver:~ # chown -Rf wwwrun:www /usr/share/cacti/log

7. Agregamos al servicio Cron (servicio de tareas programadas en entornos Unix-Like) del usuario root una directiva que tiene como objetivo realizar la limpieza del pool de la herramienta Cacti, es importante destacar que si bien la tarea programada es registrada por el usuario root, la ejecución de dicha directiva se ejecutará con el usuario especificado wwwrun:
   

   fireserver:~ # crontab -e

   # Ejecución de la graficación de Cacti cada 5 minutos.
   */5 * * * * wwwrun php /var/www/html/cacti/poller.php > /dev/null 2>&1

   Guardamos los cambios y salimos del editor de tareas programadas con el comando :wq del editor Vim y reiniciamos el servicio cron.

   fireserver:~ # service cron restart

8. Luego debemos comentar las lineas correspondientes a Deny/Allow en el archivo /etc/apache2/conf.d/cacti.conf para que nos permita acceder remotamente, debería quedar como se muestra a continuación:
   

   fireserver:~ # vi /etc/apache2/conf.d/cacti.conf

   #deny from all
   #allow from 127.0.0.1

9. Reiniciamos el servicio apache.
   

   fireserver:~ # service apache2 restart

10. En este punto ya podemos acceder a la interfaz web de la herramienta Cacti colocando en la barra de direcciones de nuestro navegador favorito la URL http://your-server/cacti/, sin embargo, aún nos falta trabajo por hacer, debemos seguir con las instrucciones que nos muestra la interfaz web para culminar la instalación y configuración de la herramienta. En la primera pantalla nos informará sobre lo que es la herramienta en sí y el tipo de licencia que utiliza, presionamos en el botón Next para continuar.
    
11. En la siguiente pantalla nos solicitará seleccionar que tipo de instalación es la que se está realizando, si es una instalación o una actualización, en mi caso es de tipo instalación nueva (New Install).
    
12. En la tercera pantalla la herramienta desplegará un formulario en las que se muestran las rutas hacia los distintos directorios y librerías requeridos por la aplicación, como se podrá ver más abajo en la imagen, el propio sistema informa si las rutas a los directorios son correctas, en mi caso no fue necesario realizar ninguna modificación, concluí con la instalación haciendo clic en el botón Finish.
    
13. Del paso anterior la herramienta directamente nos re-dirigirá a la interfaz de logueo, para acceder por primero vez ingresamos el usuario admin en el campo User Name y en el campo Password ingresamos la palabra admin nuevamente, luego nos conectamos presionando el botón Login como se muestra en la siguiente captura de pantalla.
    
14. Luego de conectarnos por primera vez a la herramienta Cacti con el usuario admin automáticamente nos solicitará el cambio de la contraseña del mencionado usuario, esto se debe a que la contraseña por defecto es muy simple y vulnerable, así que como medida de seguridad se obliga al operador a cambiarla.
    
15. Y con esto hemos concluido, luego de cambiar la contraseña por defecto del usuario admin pasamos a la interfaz de gestión de la herramienta Cacti, como dije al principio queda a cargo de ustedes aprender a utilizar esta potente herramienta, a continuación les dejo con una captura de la pantalla de gestión de la misma:

Observaciones

• La instalación fue probada en el sistema operativo openSUSE Linux en su versión 11.3 y con la arquitectura x86.
• Para crear el usuario de Cacti en MySQL y ejecutar el script de creación de tablas iniciales podemos utilizar las otras herramientas, como son las herramientas GUI para mysql o el mismo phpMyAdmin.
• El directorio en donde se encuentra instalado Cacti en openSUSE x86 y openSUSE x86_64 es /usr/share/cacti/ a diferencia del directorio /var/www/html/cacti/ especificado en la documentación oficial de la herramienta.

Enlaces Externos

• Manual de instalación para sistemas Unix-Linux
• Sitio oficial de Cacti
• Sitio oficial de RRDtool

Con esto se busca desechar muchos pasos de los artículos anteriores cuya información era engorrosa y complicada de interpretar. También con este nueva guía se trata de lograr una mejor integración entre todas las herramientas, ya que en los artículos anteriores, por ejemplo en el caso de Subversion + Apache + SSL y ViewVC, ambos estaban mas o menos relacionados entre si con la creación de repositorios manuales de Subversion y la posterior configuración de ViewVC para conectarse a los mismos, sin embargo, buena parte de las configuraciones de los tutoriales de Subversion + Apache + SSL y ViewVC pierden su enfoque con la entrada de la herramienta USVN, ya que con esta última se gestionan los usuarios, grupos, repositorios, etc. para proyectos svn.

Quiero aclarar que varios puntos serán similares al contenido de los artículos anteriores, quiero evitar reescribir las partes que estaban claras, por otro lado, he decidido no abarcar en este tutorial a la herramienta ViewVC ya que he encontrado en la herramienta WebSVN lo que finalmente necesitaba, aunque la primera no deja de ser una buena elección.

Instalación de Paquetes

1. Los paquetes que deberán verificar que se encuentren instalados (o instalarlos si no lo están) son los que se citan a continuación:
   

   apache2
   apache2-prefork
   php5
   apache2-mod_php5
   libapr1
   libapr-util1
   neon
   subversion
   subversion-doc
   subversion-server
   sqlite3

   Todos los paquetes mencionados se encuentran disponibles en los repositorios oficiales de openSUSE (y también en el CD o DVD de instalación, aunque posiblemente algo desactualizados).

2. Para instalarlos mediante zypper lo podemos hacer con el siguiente comando:
   

   fireserver:~ # zypper in apache2 apache2-prefork php5 apache2-mod_php5 libapr1 libapr-util1 neon subversion subversion-doc subversion-server sqlite3

Configuración de Apache

1. La forma más recomendable de utilizar subversion es publicando los repositorios a través del servicio http que ofrece Apache sobre el protocolo de red WebDAV/DeltaV y esto es posible gracias a los módulos que permiten su integración (que son instalados con el paquete subversion-server), así que lo primero que debemos hacer es dirigirnos al directorio /etc/sysconfig y editar el archivo apache2 para agregar los módulos correspondientes, una vez en el archivo nos dirigimos a la sección APACHE_MODULES para agregar al final el módulo dav y dav_svn:
   

   fireserver:~ # vi /etc/sysconfig/apache2

   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 perl dav dav_svn“

2. Conexiones seguras mediante APACHE+SSL: Subversion puede aprovechar los beneficios que ofrece Apache y uno de ellos es el acceso seguro mediante el protocolo https que implementa SSL para establecer las conexiones. Lo primero que tendremos que hacer es dirigirnos nuevamente al directorio /etc/sysconfig y abrir el archivo “apache2”, donde tendremos que verificar que el módulo “ssl” esté definido en la directiva APACHE_MODULES:
   

   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 perl dav dav_svn”

   También, en el mismo archivo tenemos que verificar que la directiva APACHE_SERVER_FLAGS sea igual a “SSL” como se muestra a continuación:

   APACHE_SERVER_FLAGS=”SSL“

3. Tenemos que verificar que Apache esté correctamente configurado para que escuche en los puertos indicados, tanto en el puerto por defecto que es el 80 como así también para las conexiones seguras que normalmente es el 443, para ello nos vamos al directorio /etc/apache2/ y ahí abrimos el archivo llamado listen.conf que debería tener el siguiente contenido:
   

   fireserver:~ # vi /etc/apache2/listen.conf

   Listen 80
   
   <IfDefine SSL>
       <IfDefine !NOSSL>
           <IfModule mod_ssl.c>
               Listen 443
           </IfModule>
       </IfDefine>
   </IfDefine>

4. Generación del Certificado: Varias formas existen para generar un certificado, una de ellas y el método más simple es generar un certificado automáticamente sin información adicional, para ello hay que ejecutar el siguiente comando:
   

   fireserver:~ # gensslcert

   Este comando sobre escribirá los siguientes archivos:

   /etc/apache2/ssl.crt/ca.crt
   /etc/apache2/ssl.key/server.key
   /etc/apache2/ssl.crt/server.crt
   /etc/apache2/ssl.csr/server.csr

   También creará un nuevo archivo CA.crt en el directorio /srv/www/htdocs/ para ser descargado por los clientes que se conectan bajo el protocolo https.

5. Generación de Certificado Personalizado: Si queremos generar un certificado con información personalizada de nuestra organización podemos indicarle al comando “gensslcert” varios argumentos para enriquecer el contenido del certificado como se muestra a continuación:
   

   fireserver:~ # gensslcert -C “labitacoradegabriel” -N “Este es un Certificado de Ejemplo” -c PY -s Itapúa -l BV -o “Gabriel-Corp.” -u “Unidad Informatica” -n “labitacoradegabriel.wordpress.com” -e “labitacoradegabriel@gmail.com” -y 60

   Al ejecutar el comando se crearán una serie de archivos inicialmente llamados con el nombre labitacoradegabriel en los siguientes directorios:

   /etc/apache2/ssl.crt/labitacoradegabriel-ca.crt
   /etc/apache2/ssl.crt/labitacoradegabriel-server.crt
   /etc/apache2/ssl.csr/labitacoradegabriel-server.csr
   /etc/apache2/ssl.key/labitacoradegabriel-ca.key
   /etc/apache2/ssl.key/labitacoradegabriel-server.key
   /srv/www/htdocs/LABITACORADEGABRIEL-CA.crt

6. Luego hay que crear una copiar del archivo /etc/apache2/vhosts.d/vhost-ssl.template y renombrarlo a vhost-ssl.conf.
   

   fireserver:~ # cd /etc/apache2/vhosts.d
   fireserver:/etc/apache2/vhosts.d # cp vhost-ssl.template vhost-ssl.conf

   Si hemos creado un certificado personalizado como en el punto Nº 6 y queremos que éste sea el certificado utilizado para la autenticación tendremos que editar el archivo vhost-ssl.conf en el directorio /etc/apache2/vhosts.d/ y modificar las directivas que se citan a continuación con los nombres de los archivos generados anteriormente:

   fireserver:~ # vi /etc/apache2/vhosts.d/vhost-ssl.conf

   SSLCertificateFile /etc/apache2/ssl.crt/labitacoradegabriel-server.crt
   SSLCertificateKeyFile /etc/apache2/ssl.key/labitacoradegabriel-server.key

   Con esto hemos creado un host virtual exclusivo para las conexiones seguras, lo siguiente que resta es reiniciar el servicio apache y verificar que la configuración para conexiones seguras funcione correctamente:

   fireserver:~ # service apache2 restart
   Syntax OK
   Shutting down httpd2 (waiting for all children to terminate)   done
   Starting httpd2 (prefork)                                                                        done
   fireserver:~ # httpd2 -S -DSSL
   VirtualHost configuration:
   wildcard NameVirtualHosts and _default_ servers:
   _default_:443          fireserver.selfip.net (/etc/apache2/vhosts.d/vhost-ssl.conf:37)
   Syntax OK
   fireserver:~ #

7. El siguiente paso consiste en abrir el puerto HTTP (80) y HTTPS (443) en el firewall del servidor, para ello editamos el archivo SuSEfirewall2 del directorio /etc/sysconfig y le asignamos los servicios apache2 y apache2-ssl a la directiva FW_CONFIGURATIONS_EXT como se muestra a continuación:
   

   fireserver:~ # vi /etc/sysconfig/SuSEfirewall2

   FW_CONFIGURATIONS_EXT=”apache2 apache2-ssl mysql netbios-server samba-server sshd vsftpd xorg-x11-server”

   Luego reiniciamos el cortafuegos para que la nueva configuración tome efecto y lo podemos hacer con el siguiente comando:

   fireserver:~ # rcSuSEfirewall2 restart

8. Ahora ya nos podemos conectar desde un equipo remoto a nuestro servidor apache con nuestro navegador preferido, si probamos el protocolo seguro https, el servidor apache que hemos configurado recientemente emitirá el certificado con la información que hemos definido.
   

Subversion

El único paso que tenemos que llevar a cabo teniendo instalados los paquetes de subversion es agregar al sistema operativo un nuevo grupo y usuario de sistema para la aplicación, ambos llamados svn. El usuario svn es necesario para ejecutar el software por primera vez y lamentablemente no se crea automáticamente durante la instalación del paquete. Lo podemos agregar mediante los siguientes comandos:

fireserver:~ # groupadd -r svn
fireserver:~ # useradd -r -g svn svn

USVN

USVN (UserFriendly SVN) es una herramienta que permite gestionar proyectos de Subversion. El sitio web del proyecto es http://www.usvn.info de donde se puede descargar esta herramienta y encontrar información acerca de la misma, los pasos detallados para instalar la herramienta se citan a continuación:

1. El primer paso de esta sección consiste en dirigirnos al directorio raíz del Apache que como sabrán en openSUSE es el directorio /srv/www/htdocs, descargamos del sitio oficial de USVN la última versión de la herramienta y realizamos algunos ajustes, los comandos se detallan a continuación:
   

   fireserver:~ # cd /srv/www/htdocs/
   fireserver:/srv/www/htdocs # wget http://www.usvn.info/download/get/1.0.1+Boo/tgz.dl
   –2010-09-03 21:58:04– http://www.usvn.info/download/get/1.0.1+Boo/tgz.dl
   Resolviendo www.usvn.info… 163.5.84.230
   …
   …
   Petición HTTP enviada, esperando respuesta… 200 OK
   Longitud: 3478368 (3,3M) [application/x-tar]
   Saving to: `usvn-1.0.1.tgz’

   100%[==========================>] 3.478.368 5,60K/s in 6m 38s

   2010-09-03 22:04:47 (8,54 KB/s) – `usvn-1.0.1.tgz’ saved [3478368/3478368]

   fireserver:/srv/www/htdocs # tar -xzf usvn-1.0.1.tgz
   fireserver:/srv/www/htdocs # mv usvn-1.0 usvn
   fireserver:/srv/www/htdocs # mkdir usvn/files
   fireserver:/srv/www/htdocs # chown -Rf wwwrun:www usvn
   fireserver:/srv/www/htdocs # rm usvn-1.0.1.tgz
   fireserver:/srv/www/htdocs #

   OBS: Con el comando mkdir usvn/files se crea el directorio files dentro del directorio usvn y que servirá para albergar los archivos de los proyectos SVN.

2. Lo siguiente que tenemos que agregar a la directiva APACHE_MODULES del archivo /etc/sysconfig/apache2 los módulos authz_svn y rewrite como se muestra a continuación:
   

   fireserver:~ # vi /etc/sysconfig/apache2

   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 perl dav dav_svn authz_svn rewrite“

3. Luego debemos crear en el directorio conf de Apache un archivo de configuración con unas directivas básicas para arrancar por primera vez la herramienta USVN:
   

   fireserver:~ # cd /etc/apache2/conf.d/
   fireserver:/etc/apache2/conf.d # touch usvn.conf
   fireserver:/etc/apache2/conf.d # vi usvn.conf

   Alias /usvn /srv/www/htdocs/usvn/public
   <Directory /srv/www/htdocs/usvn/public>
           Options +SymLinksIfOwnerMatch
           AllowOverride All
           Order allow,deny
           Allow from all
   </Directory>

4. Para que los pasos anteriores tomen efecto necesitamos reiniciar el servicio Apache:
   

   fireserver:~ # service apache2 restart

5. Ahora si ya podemos acceder a la herramienta colocando en la barra de direcciones del navegador de nuestra preferencia la URL: http://fireserver/usvn/install.php, lo que hará desplegar un asistente de configuración cuyos pasos se muestran a continuación:
   1. Accedemos a la siguiente URL para iniciar la instalación de la herramienta USVN:
      

      http://ip_o_nombre_del_servidor/usvn/install.php

   2. Página de Bienvenida, Verificaciones Previas y Selección de Idioma:

      

   3. Licencia y Configuración de Título y Directorios: En el paso 3 nos muestras la licencia de uso del software donde tenemos que ir hasta el final para aceptarla, ya en el paso 4 podemos definir un título y los directorios en donde se almacenarán las distintas configuraciones, yo lo deje con la configuración por defecto:

      

   4. Creación de Base de Datos y Administrador de USVN: En el paso 5 nos toca configurar la base de datos que vamos a utilizar, como mi demanda de usuarios no va a ser muy grande utilicé el soporte para sqlite, sin embargo, también es posible utilizar MySQL, otra cosa, no nos tenemos que olvidar de tener instalado el motor de base de datos que seleccionamos. En el paso 6 ingresamos los datos de quien será el administrador de USVN:

      

   5. Chequeo de Nuevas Versiones y Finalización de la Instalación: En el paso 7 consulta si deseamos que nos avise si existe una nueva versión para descargar, al final de esa página hay 2 botones que nos permiten seleccionar nuestra opción de preferencia.

      

      La configuración propuesta a partir de la configuración previa que aparece en la captura 09 para la herramienta USVN (Paso 8) se nos indica que hay unas líneas que hay que agregar al archivo httpd.conf del Apache, sin embargo, para que quede más ordenado, yo agregué esas líneas al final del archivo /etc/apache2/conf.d/usvn.conf donde funciona igual:

      fireserver:~ # vi /etc/apache2/conf.d/usvn.conf

      <Location /svn/>
              ErrorDocument 404 default
              DAV svn
              Require valid-user
              SVNParentPath /srv/www/htdocs/usvn/files/svn
              SVNListParentPath off
              AuthType Basic
              AuthName "Fireserver USVN"
              AuthUserFile /srv/www/htdocs/usvn/files/htpasswd
              AuthzSVNAccessFile /srv/www/htdocs/usvn/files/authz
      </Location>

6. Para que la nueva configuración de la herramienta USVN tome efecto necesitamos reiniciar el servicio Apache:
   

   fireserver:~ # service apache2 restart

7. Ahora ya vamos a poder acceder a la herramienta USVN desde nuestro navegador preferido sin problemas colocando la URL http://nombre_o_ip_servidor/usvn.



8. Una vez adentro tenemos todas las opciones para administrar nuestros proyectos, entre ellos podemos destacar la creación de usuarios y su asociación a Grupos, Creación de varios proyectos, asignación de permisos de lectura/escritura a carpetas por grupos definidos, etc etc.

WebSVN

Como ya dije durante la introducción, la herramienta WebSVN es una excelente opción a ViewVC, cumple con la misma función y desde mi punto de vista posee una interfaz muy interesante que define perfectamente la estructura de directorios que forman parte de nuestro repositorio SVN, al menos en su tema por defecto llamado calm, también es importante destacar su soporte multi-lenguaje.

1. Como primer paso para instalar la herramienta WebSVN tenemos que dirigirnos al repositorio /srv/www/htdocs, descargar en dicho repositorio la última versión estable de la herramienta WebSVN directamente desde su sitio web, descomprimirlo, renombrar el nombre de la carpeta, aplicarle el dueño/grupo y los permisos adecuados:
   

   fireserverr:~ # cd /srv/www/htdocs/
   fireserverr:/srv/www/htdocs # wget http://websvn.tigris.org/files/documents/1380/47525/websvn-2.3.1.tar.gz
   –2010-09-24 11:32:01– http://websvn.tigris.org/files/documents/1380/47525/websvn-2.3.1.tar.gz
   Connecting to 192.168.10.246:3128… connected.
   Proxy request sent, awaiting response… 302 Moved Temporarily
   Location: http://websvn.tigris.org/servlets/ProjectDocumentDownload?documentID=47525 [following]
   –2010-09-24 11:32:01– http://websvn.tigris.org/servlets/ProjectDocumentDownload?documentID=47525
   Connecting to 192.168.10.246:3128… connected.
   Proxy request sent, awaiting response… 302 Moved Temporarily
   Location: http://www.tigris.org/files/documents/1380/47525/websvn-2.3.1.tar.gz [following]
   –2010-09-24 11:32:01– http://www.tigris.org/files/documents/1380/47525/websvn-2.3.1.tar.gz
   Connecting to 192.168.10.246:3128… connected.
   Proxy request sent, awaiting response… 200 OK
   Length: 792363 (774K) [application/x-gzip]
   Saving to: `websvn-2.3.1.tar.gz’

   100%[===========================================================>] 792,363 141K/s in 5.8s

   2010-09-24 11:32:08 (133 KB/s) – `websvn-2.3.1.tar.gz’ saved [792363/792363]

   fireserver:/srv/www/htdocs # tar -xzf websvn-2.3.1.tar.gz
   fireserver:/srv/www/htdocs # mv websvn-2.3.1 websvn
   fireserver:/srv/www/htdocs # chown -Rf wwwrun:www websvn
   fireserver:/srv/www/htdocs # rm websvn-2.3.1.tar.gz
   fireserver:/srv/www/htdocs #

2. Pasamos al directorio /srv/www/htdocs/websvn/include y creamos una copia del archivo distconfig.php con el nombre config.php, el archivo debe llevar el nombre config.php porque es este el nombre del archivo de configuración que la herramienta WebSVN busca por defecto al arrancar.
   

   fireserver:~ # cd /srv/www/htdocs/websvn/include
   fireserver:/srv/www/htdocs/websvn/include # cp distconfig.php config.php

3. El siguiente paso consiste en editar el nuevo archivo config.php y en la sección REPOSITORY SETUP del mismo configuramos todos nuestros repositorios que tengamos, en este ejemplo voy a agregar un repositorio local llamado docs creado y administrado con la herramienta usvn:
   

   fireserver:~ # vi /srv/www/htdocs/websvn/include/config.php

   $config->addRepository(‘Documentos‘, ‘file:///srv/www/htdocs/usvn/files/svn/docs/‘);

   En el mismo archivo pero en la sección ACCESS RIGHTS configuramos la directiva useAuthenticationFile con la ruta completa hacia el archivo authz generado por nuestro gestor web de repositorios subversion que es USVN, la definición debería quedar como sigue:

   $config->useAuthenticationFile(‘/srv/www/htdocs/usvn/files/authz‘);

   Salimos del archivo de configuración guardando la configuración para pasar al siguiente punto.

4. Necesitamos crear un archivo de configuración para la herramienta WebSVN en Apache para definir el mecanismo de autenticación que se va a utilizar, así que necesitamos dirigirnos al directorio /etc/apache2/conf.d y crear un archivo de texto llamado websvn.conf.
   

   fireserver:~ # cd /etc/apache2/conf.d/
   fireserver:/etc/apache2/conf.d # touch websvn.conf

5. Editamos el archivo creado en el paso anterior y agregamos las siguientes lineas.
   

   fireserver:/etc/apache2/conf.d # vi websvn.conf

   <Location /websvn/>
           ErrorDocument 404 default
           Require valid-user
           AuthType Basic
           AuthName "WebSVN"
           AuthUserFile /srv/www/htdocs/usvn/files/htpasswd
   </Location>

   Como verán el archivo htpasswd especificado en la directiva AuthUserFile corresponde al archivo generado por la herramienta USVN, agregado el texto anterior guardamos y salimos del archivo websvn.conf.

6. Reiniciamos el servicio apache:
   

   fireserver:~ # service apache2 restart

7. Por último accedemos a la herramienta colocando en nuestro navegador preferido la URL http://ip_o_nombre_servidor/websvn, donde para acceder tendremos que colocar un usuario y su respectiva contraseña para finalmente poder visualizar el repositorio, a continuación les dejo con una captura de pantalla de dicha herramienta.

Una aclaración importante es que aparte de validar el acceso a la herramienta WebSVN en base a los usuarios registrados con la herramienta USVN, también limita el acceso a los repositorios según los permisos de accesos otorgados a cada usuario también mediante la herramienta USVN, esto nos facilita el trabajo ya que la gestión de usuarios, grupos y permisos a repositorios se centraliza en una sola herramienta que en este caso es USVN.

Observaciones

Cuando se trata de acceder a un repositorio de subversion a través de un servidor proxy es posible que se presenten inconvenientes, esto es a causa de que los servidores proxy no suelen interpretar o soportar todos los métodos que ofrece WebDAV, sobre este caso, en la página oficial de subversion tratan este tema en el siguiente enlace: http://subversion.tigris.org/faq.html#proxy

Clientes Gráficos Recomendados

• TortoiseSVN para Windows (muy bueno)
• Kdesvn, excelente gestor recomendado para los usuarios de KDE 4, la funcionalidades de esta herramienta se integra completamente al escritorio (similar a TortoiseSVN)
• Otros para openSUSE o tu distro favorita: qsvn y eSvn.

Artículos relacionados en este Blog

• Manual para configurar Subversion + Apache + SSL en openSUSE
• Comandos básicos para trabajar con subversion desde consola
• ViewVC, un navegador de repositorios para Subversion
• USVN, una herramienta web para gestionar proyectos de Subversion

Enlaces Externos

Los sitios oficiales de las herramientas mencionadas en este tutorial son los siguientes.