Categoría: Software Libre

Yum: resolver el error «rpmdb open failed»

Tras intentar hacer alguna operación con yum en consola nos encontramos con el error «rpmdb open failed».

Este error indica que las bases de datos que se encuentran bajo el directorio /var/lib/rpm( están dañadas. Su formato de nombre de fichero es del tipo «_db*», así que para deshacernos de este problema nada más sencillo que borrarlas y volver a crearlas.

Como root ejecutamos el borrado de las bases de datos, las regeneramos, limpiamos la cache y la volvemos a crear.

$
$ rm -f /var/lib/rpm/_db*
$ rpm -vv --rebuilddb 
$ yum clean all
$ yum makecache 
$

Disponible PHP 5.5.9

El grupo de desarrolladores de PHP han anunciado la liberación de la versión 5.5.9, que corrige algunos bugs detectados en la versión 5.5.8 (lista de cambios), se recomienda a todos los usuarios que estén utilizando la versión 5.5 actualizar a la nueva versión.

También está disponible la versión 5.6.0alpha2, donde se incluyen nuevas características y se corrigen errores. A todos los que estén interesados en probar esta nueva versión se les recuerda que es una versión en desarrollo y no se debe usar en producción.

Puesta a punto de Fedora 16

Es es un pequeño resumen de utilidades y configuraciones que deberíamos hacer para tener nuestro Fedora 16 a punto para poder sacarle en mejor rendimiento a este fantástico sistema operativo.

Plugins de yum

Una de las primeras cosas que debemos hacer es mejorar el rendimiento de YUM, puesto que lo necesitamos para el resto de tareas. Dos plugins fundamentales fastetstmirror (sirve para localizar el servidor más rápido para la descarga de paquetes) y presto que descarga sólo los paquetes nuevos de un determinado programa.

$
$ yum install yum-plugin-fastestmirror
$ yum install yum-presto
$

Instalar repositorios extras

Algunos paquetes interesantes, por uno u otro motivo, no se encuentran en los repositorios oficiales de Fedora, así que mejor tener preparados los repositorios extra para cuanto se necesiten.

$
$ yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
$

Instalar flash plugin en Fedora 16

El plugin de flash, una de esas cosa que una vez instalado no te volverás a preocupar, pero que cuando no lo tienes y accedes a una web que lo usa provoca bastante frustración.

yum install flash-plugin

Instalar java y su famoso plugin

Otra de esas cosas, que a menos que uses programas en java no echas de menos hasta que llegas a una web que requiere su famoso plugin para poder acceder a alguna utilidad. Si eres fan de la Fórmula 1 y quieres seguir la tabla de tiempos a través de la web oficial necesitas el plugin (OJO: algunos navegadores necesitan configuración adicional).

yum install java-1.6.0-openjdk
yum install java-1.6.0-openjdk-plugin

Instalar codecs de audio y video

Cuando intentes usar Rhythmbox para escuchar música te darás cuenta de su necesidad.

yum install gstreamer-plugins-bad gstreamer-plugins-bad-nonfree gstreamer-plugins-ugly gstreamer-ffmpeg

Visualización y herramientas

Completado el apartado de entrañas, toca una revisión a la parte visual. Fedora 16 viene con la Shell de Gnome 3 y tenemos una herramienta estupenda para configurar sus opciones gnome-tweak-tool

yum install gnome-tweak-tool

Algunas utilidades que en algún momento vais a necesitar si usáis Fedora como sistema de escritorio: paquete ofimático, editor de gráficos, gestor de documentos (si usas Google Docs, debes activar las cuentas en línea) y el VLC.

yum install libreoffice
yum install gimp gimp-data-extras gimp-fourier-plugin gimp-lqr-plugin gimp-resynthesizer gimpfx-foundry
yum install gnome-documents
yum install vlc-extras

Y eso es todo, excuso decir que para todas estas operaciones tenéis que tener permisos de administración sobre el sistema.

Proteger el acceso por SSH

SSH (Secure SHell) es a un tiempo el nombre del protocolo y el programa que nos permite acceder a maquinas remotas de forma segura y gestionarlas por completo mediante un intérprete de comandos.

Hechas las presentaciones, vaya por delante lo de siempre: un servidor completamente seguro es el que está encerrado entre muros de hormigón sin ningún tipo de conexión. Obviamente, así no sirve para nada, entonces tendremos que buscar el correcto equilibrio entre conectividad y seguridad. Como me toca acabar el año configurando nuevos servidores, os dejo una pequeña guía para asegurar el acceso por SSH.

Lo primero, modificar el fichero de configuración de SSH que encontrareis en /etc/ssh/sshd_config y agregamos las siguientes líneas (en muchos casos las encontrareis comentadas).

Protocol 2
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers pepito

La primera línea le indica que unicamente se puede hacer uso de la versión 2 del protocolo de comunicación. La primera versión tiene algunas vulnerabilidades conocidas y está obsoleta por lo que lo recomendable es no usarla si no se necesita.

El LoginGraceTime hace referencia al tiempo en segundos que la pantalla de login permanecerá abierta, en el ejemplo hemos dejado 20 segundos, un tiempo más que suficiente para indicar usuario y contraseña.

Con PermitRootLogin establecido a no evitaremos que el usuario root pueda autenticarse a través de SSH para acceder al servidor. El problema es que los sistemas Linux y Unix crean al usuario root, lo que garantiza a un atacante que ya conoce el usuario, sólo queda la contraseña. De esta forma será mucho más complicado, obviamente no uses nombres conocidos o estarás en el mismo caso.

Otro de los límites que podemos imponer es definir la cantidad de veces que podemos fallar al autenticarnos. Con MaxAuthTries definimos el número de intentos, con 1 sería más que suficiente, pero a los que nos toca andar con varios servidores a la larga terminas equivocándote la primera vez de ahí que lo defina con 2 intentos. Lo que ocurrirá después del segundo fallo es que se cerrará la conexión.

Con MaxStartups se indican la cantidad de conexiones simultaneas que se permiten, en este caso hemos optado por 3, un número razonable para aquellos servidores a los que se accede por SSH únicamente para su administración. Con esto evitaremos que un ataque por fuerza bruta pueda realizar miles de conexiones simultaneas para atacar.

Y por último, pero no menos importante, AllowUsers. Con esta directiva le indicamos al SSH que usuarios exclusivamente se pueden identificar en el sistema. También podemos aumentar la seguridad definiendo desde que redes puede acceder un determinado usuario. Basta con poner los nombres de los usuarios separados por espacios, si se quiere indicar un host podemos hacerlo poniendo el usuario seguido del símbolo @ y el host (Ej: pepito@127.0.0.1).

Con esto ya tenemos nuestro SSH un poco más seguro. Guardamos el fichero y reiniciamos el servicio.

Lo segundo que haremos para evitar que nos ataquen será instalar Fail2ban, un programa controla los logs y que nos permite vetar todas aquellas IP’s que fallan un determinado número de veces. El baneo se realizará usando el firewall, así que lo que hace realmente Fail2ban es crear y borrar reglas en función de la información que se registra en los logs.

El requisito para instalar Fail2ban es tener Python, tenéis disponibles paquetes compilados para instalar o podeis tirar de repositorios. Una vez instalado tan solo es necesario configurar las reglas que queremos tener activas, tenéis bastante información en su web y un archivo de configuración de prueba en /etc/fail2ban/jail.conf

Proteger acceso por SSH con certificados

Configurar Subversion para controlar las versiones del código

Para los que nos dedicamos al desarrollo de software es de vital importancia poder hacer un seguimiento de todos los cambios que realizamos en una aplicación, sobre todo cuando se trata de trabajar en equipo con distintos programadores realizando distintas tareas, e incluso llevar un control de los cambios que realizan distintos equipos dentro de un mismo software.

Cuando el proyecto está bajo el paraguas del software libre, herramientas como las proporcionadas por www.sourceforge.net son de mucha ayuda. Entre ellas se encuentra el uso de Subversion o CSV para la gestión de versiones. Personalmente prefiero subversion.

Este es un pequeño HOWTO de como configurar subversion corriendo bajo Apache, se presupone que se tiene instalado Apache, Subversion, el módulo DAV para Apache y las herramientas de administración de Subversion.

Lo primero que debemos hacer es crear un directorio para nuestro repositorio. Nuestro directorio principal para guardar nuestro control de versiones sobre subversion será /var/subversion/, dentro crearemos un subdirectorio donde se almacenarán los datos con subversion:

# mkdir /var/subversion/repositorio

Ahora debemos crear la estructura de subversion para almacenar las versiones y asignarle permisos para poder acceder:

# svnadmin create /var/subversion/repositorio/
# chmod 777 -R /var/subversion/repositorio/

Con esto ya tenemos listo el repositorio, ahora debemos generar el acceso a través de URL, para ello usaremos el módulo de Apache WebDav. Editaremos el fichero de módulo DAV de Apache (en Devian lo encontraremos en /etc/apache2/mods-available/dav_svn.conf), al final del fichero incluiremos las siguientes líneas:

# Acceso repositorio SVN

DAV svn
AuthType Basic
AuthName «Servidor Subversion»
SVNPATH /var/subversion/repositorio

En «Location» debemos poner la URL por la que queremos acceder al repositorio y en SVNPATH debemos colocar la ruta absoluta hacia el directorio que contendrá los ficheros de nuestro repositorio. Con esto ya debería estar funcionando nuestro repositorio con Subversion, basta con enlazarlo desde cualquier IDE que soporte control de versiones y comenzar a guardar las versiones de vuestros proyectos.

Como subversion no es sólo lo que he comentado, existe un estupendo manual donde podéis encontrar todas las funciones que ofrece este gestor de versiones.

Gestionar la cola de correo con Qmail

Qmail no ofrece un modo de revisar y gestionar la cola de correo, por lo que es necesario disponer de un programa como qmHandle. Este pequeño script escrito en perl permite manejar la cola de correo de Qmail a través de la línea de comandos.

Para su instalación bastará con obtener la última versión del script desde el repositorio de Sourceforge y copiarlo a /usr/bin.

#wget http://downloads.sourceforge.net/project/qmhandle/qmhandle-1.3/qmhandle-1.3.2/qmhandle-1.3.2.tar.gz
#tar xzvf  qmhandle-1.3.2.tar.gz
#cp /qmhandle-1.3.2/qmHandle /usr/bin/

A partir de aquí podremos manejar la cola de Qmail a través de qmHandle, estas son las opciones con las que contamos (qmHandle –help):

#qmHandle –help

qmHandle v1.3.2
 Copyright 1998-2003 Michele Beltrame

Available parameters:
 -a : try to send queued messages now (qmail must be running)
 -l : list message queues
 -L : list local message queue
 -R : list remote message queue
 -s : show some statistics
 -mN : display message number N
 -dN : delete message number N
 -fsender : delete message from sender
 -f’re’ : delete message from senders matching regular expression re
 -Stext : delete all messages that have/contain text as Subject
 -h’re’ : delete all messages with headers matching regular expression re (case insensitive)
 -b’re’ : delete all messages with body matching regular expression re (case insensitive)
 -H’re’ : delete all messages with headers matching regular expression re (case sensitive)
 -B’re’ : delete all messages with body matching regular expression re (case sensitive)
 -t’re’ : flag messages with recipients in regular expression ‘re’ for earlier retry (note: this lengthens the time message can stay in queue)
 -D : delete all messages in the queue (local and remote)
 -V : print program version

Additional (optional) parameters:
 -c : display colored output
 -N : list message numbers only
 (to be used either with -l, -L or -R)

You can view/delete multiple message i.e. -d123 -v456 -d567

Para revisar la cola de correo debemos ejecutar qmHandle -l, que nos devolverá una salida parecida a esta:

#qmHandle -l

Total messages: 0 –> Recuento del total de mensajes en cola
Messages with local recipients: 0 –> Correos locales en cola
Messages with remote recipients: 0 –> Correos remotos en cola
Messages with bounces: 0 –> Correos rebotados
Messages in preprocess: 0 –> Correos preprocesados

Frameworks PHP: Zend vs Symfony

Cuando uno se plantea por primera vez el uso de un framework en PHP comienza a darle vueltas a las posibilidades que ofrecen unos y otros. Aunque la curva de aprendizaje en el uso de un framework es dura, todo el tiempo que le dediquemos a conocer a fondo aquel por el que nos decidamos será el tiempo mejor invertido en formarnos como desarrolladores.

En este caso quiero plantear una comparación entre dos de los frameworks más extendidos Zend y Symfony.

Documentación y aprendizaje. Com he dicho la curva de aprendizaje para poder usar correctamente y con soltura un framework necesita de un esfuerzo, mucho más si llevamos años programando sin usarlo. Symfony dispone de guias y manuales en abundancia, y además cuenta con numerosos foros en varios idiomas donde la comundad va resolviendo dudas. En el caso de Zend, a pesar de ser el framework de la empresa que está detrás de PHP, la comunidad es algo escasa, por tanto su documentación también.

Pruebas unitarias. Symfony dispone de tareas por linea de comandos para realizar testing, y además genera una clase vacia con cada nuevo controdalor desde el que poder realizar las pruebas. Zend no dispone de esta funcionalidad, algo que me parece muy importante a la hora de lanzar una aplicación a un entorno de producción.

Plantillas y plugins. Al sistema de plantillas de Zend le queda todavía un largo camino que recorer, mientras que en Symfony el sistema está ya muy avanzado, con la posibilidad de agragar módulos. Y otro tanto ocurre con los plugins, en Symfony es posible aumentar sus funcionalidades a base de plugins, mientras que Zend carece de esta característica.

Bases de datos. El trabajo con base de datos en Zend se limita a usar ActiveRecord (que no digo que esté mal), pero en Symfony tienes la posibilidad de usar el motor de base de datos que quieras, incluyendo el propio Zend_Db, algo que aporta una enorme flexibilidad al desarrollador que puede elegir en cada proyecto cual es la mejor opción.

Como conclusión a lo dicho quiero añadir, para todos aquellos que quieran dar el salto a hacer desarrollos basados en un framework, que a pesar de que al principio pueda resultar un poco engorroso con el tiempo os ayudará a mantener una limpieza de código y un mantenimiento de aplicaciones mucho más sencillo.