Como la mayoría sabéis, los repositorios oficiales de RHEL, CentOS, Scientific Linux, etc traen versiones de aplicaciones bastante retrasadas respecto las oficiales que podemos encontrar a través de los propietarios del software, por ejemplo Apache, PHP, MySQL, etc. En el caso de postgreSQL existe un repositorio mantenido por ellos mismos a través del cual podemos instalar y mantener actualizado nuestro postgreSQL con la última versión estable.

Podéis encontrar la descarga de otros repositorios, arquitecturas, etc en el sitio web www.postgresql.org.es. Lo que vamos a hacer es primero bajarnos el rpm que instalará el repositorio en el sistema:

# curl -O http://yum.postgresql.org/9.1/redhat/rhel-6-x86_64/pgdg-redhat91-9.1-5.noarch.rpm

Lo instalamos, básicamente crea el fichero .repo correspondiente:

# rpm -ivh pgdg-redhat91-9.1-5.noarch.rpm

Importante, en el caso de RedHat Enterprise Linux tenemos que deshabilitar todo lo referente a postgresql en el repositorio oficial, lo mismo tendríamos que hacer en otras distribuciones y en cualquier repositorio adicional que haya en el sistema:

# vi /etc/yum/pluginconf.d/rhnplugin.conf

exclude=postgresql*

Ahora ya podemos consultar las versiones de postgreSQL disponibles en el nuevo repositorio instalado. En este caso instalamos la 9.1 para 64 bits:

# yum install postgresql91-server.x86_64

Iniciamos la base de datos/instancia:

# /etc/init.d/postgresql-9.1 initdb

Arrancamos el servicio:

/etc/init.d/postgresql-9.1 start

Y lo primero cambiamos la clave del usuario postgresql desde la shell de psql, que por defecto está vacía:

ALTER ROLE postgres WITH PASSWORD 'XXXXXX';

A partir de aquí ya podemos trabajar con el servidor.

suEXEC por seguridad trae los siguientes parámetros compilados y sin posibilidad de ser modificados:

# suexec -V
 -D AP_DOC_ROOT="/var/www"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_EXEC="/var/log/httpd/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=500
 -D AP_USERDIR_SUFFIX="public_html"

Si lo hemos instalado compilando a través de las sources, no hay problema, se recompila y ya está. Pero si lo hemos instalado por RPM requiere un trabajo distinto. Es necesario bajar las sources del RPM y editarlas con los parámetros que queramos, luego se compila el nuevo RPM y ya podemos instalarlo.

En este caso se trata un Apache con suEXEC en RHEL 6 e instalado por RPM así que nos bajamos las sources de Apache correspondientes:

# curl -O ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/httpd-2.2.15-15.el6_2.1.src.rpm

Desempaquetamos el RPM, Si el usuario mockbuild no existe veréis un montón de avisos y las sources se guardarán en la home de root en lugar de en src:

# rpm -Uvh httpd-2.2.15-15.el6_2.1.src.rpm

Ahora tenemos que editar el fichero httpd.spec:

# vi /root/rpmbuild/SPECS/httpd.spec

En nuestro caso queremos cambiar el AP_DOC_ROOT o contentdir, que es la ruta raíz en la que vamos a alojar el contenido de los websites:

%define contentdir /var/www

Modificamos a la ruta correcta:

%define contentdir /www

Para que al hacer el upgrade no nos diga que la versión ya está instalada, también podemos cambiar el número de versión:

Release: 15%{?dist}.3

Es necesario para volver a compilar el rpm el paquete rpm-build, también necesitaréis las sources de ciertas dependencias, lo veréis según vayáis haciendo el trabajo:

# yum install rpm-build
# yum install libselinux-devel openssl-devel

Recompilamos el RPM:

# rpmbuild -bb /root/rpmbuild/SPECS/httpd.spec

Una vez terminado ya tenemos los RPM listos para instalar en /root/rpmbuild/RPMS/x86_64:

-rw-r--r--. 1 root root 3229796 Feb 21 06:26 httpd-2.2.15-15.el6.1.x86_64.rpm
-rw-r--r--. 1 root root  156508 Feb 21 06:26 httpd-devel-2.2.15-15.el6.1.x86_64.rpm
-rw-r--r--. 1 root root  128945 Feb 21 06:26 httpd-tools-2.2.15-15.el6.1.x86_64.rpm
-rw-r--r--. 1 root root  403246 Feb 21 06:26 mod_ssl-2.2.15-15.el6.1.x86_64.rpm

# rpm -Uvh *rpm

Reiniciamos apache y:

# suexec -V
 -D AP_DOC_ROOT="/www"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_EXEC="/var/log/httpd/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=500
 -D AP_USERDIR_SUFFIX="public_html"

Por supuesto podéis cambiar el resto de valores del mismo modo si fuera necesario.

RPM nos ofrece una utilidad muy valiosa que nos permite verificar la integridad y seguridad de todos los paquetes y aplicaciones instaladas en el sistema (con yum o rpm). Básicamente, lo que vamos a hacer es verificar todos los ficheros de todos los paquetes instalados en el sistema. La verificación consiste en comprobar la información de estos ficheros con la que hay almacenada en la base de datos rpm. Vamos a verificar el MD5 checksum, los permisos, el propietario y grupo, tamaño del fichero, etc. Para ello utilizaremos los parámetros –verify o -V.

De primeras podemos descartar los ficheros de configuración, ya que lo más normal es que su contenido cambie, aunque todavía podríamos revisar su configuración de permisos, propietario, etc.

Si queremos hacer una revisión de todos los ficheros del sistema, algo que lógicamente puede tardar bastante tiempo, utilizaremos el siguiente comando. Hay que tener en cuenta que en caso de no haber salida todo es correcto:

# rpm -Va

Si queremos hacer la revisión de un único paquete lo indicamos y quitamos el parámetro “a”:

# rpm -V telnet

Y si quisiéramos revisar un único fichero:

# rpm --verify --file /usr/bin/chcon

¿Y qué sucede si se detecta algún problema? Vamos a verlo. Voy a hacer un backup del binario /usr/sbin/apachectl y a reescribirlo:

# mv /usr/sbin/apachectl /usr/sbin/apachectl.BAK
# touch /usr/sbin/apachectl
# rpm -V --file /usr/sbin/apachectl
S.5....T.  c /etc/httpd/conf/httpd.conf
S.5....T.    /etc/rc.d/init.d/httpd
S.5....T.  c /etc/sysconfig/httpd
SM5....T.    /usr/sbin/apachectl

Como véis ahora sí que hay salida. Tenemos 8 puntos que se pueden convertir en otros caracteres cuando hay algo que no cuadra:

• 5: fallo en el checksum MD5
• S: discrepancia en el tamaño del fichero
• T: fecha de modificación distinta al original
• L: enlace simbólico
• D: dispositivo
• U: usuario
• G: grupo
• M: permisos

Así pues, en el ejemplo anterior vemos como el binario apachectl tiene un checksum MD5 distinto, distinto tamaño, fecha de modificación y de permisos. La “c” es de fichero de configuración.

Si queremos comprobar de una tacada la integridad de todos los binarios de /usr/sbin, es tan sencillo como:

# rpm -Va | grep "/usr/sbin"
S.5....T.    /usr/sbin/apachectl

Podemos añadir un mayor nivel de debug con el parámetro “v”, “vv” más debug aún:

# rpm -Vv --file /usr/sbin/apachectl
# rpm -Vvv --file /usr/sbin/apachectl

Como veis, esta es una buena y sencilla forma de asegurarnos que los binarios del sistema no han sido alterados y también de tener un control del estado de los ficheros de configuración, etc.

Para una primera toma de contacto con Yum os aconsejo leer el artículo que publiqúe hace ya un tiempo: Gestión de paquetes en Linux con Yum, posteriormente estos trucos os pueden ser de utilidad.

En qué paquete se encuentra un determinado fichero

A través del parámetro whatprovides podemos consultar en la base de datos de yum qué paquete contiene un determinado fichero. Esto es realmente útil por ejemplo si necesitamos saber en qué paquete se encuentra una determinada librería que necesitamos por dependencias, un fichero de configuración, etc.

Aquí por ejemplo necesitamos saber el paquete que contiene la librería libssl3.so, gracias a whatprovides vemos que se trata de nss-3.12.8-4.el5_6:

# yum whatprovides libssl3.so
46 packages excluded due to repository priority protections

Other       : libssl3.so

nss-3.12.8-4.el5_6.i386 : Network Security Services
Repo        : updates
Matched from:
Other       : libssl3.so

Instalar únicamente actualizaciones de seguridad

Instalando (a través de yum por supuesto) el paquete yum-security activamos en nuestro sistema la posibilidad de instalar únicamente aquellas actualizaciones relacionadas con la seguridad. Primero lo instalamos:

# yum install yum-security

Una vez instalado podemos lanzar una consulta para examinar las actualizaciones de seguridad pendientes en el sistema:

# yum list-security

Y finalmente para instalarlas:

# yum update --security

Hacer downgrade de un paquete instalado

Para poder bajar de versión un paquete instalado por yum también tendremos que instalar un plugin extra ya que por defecto no está permitido. El paquete es yum-allowdowngrade. Procedemos a instalarlo:

# yum install yum-allowdowngrade

Una vez instalado podemos hacer downgrade de la versión del paquete que queramos del siguiente modo:

# yum --allow-downgrade install mysql

También podemos verificar antes las versiones disponibles para instalar/downgrade:

# yum --allow-downgrade info mysql

Ver las dependencias de un paquete

A través de la opción deplist podemos verificar las dependencias que se instalarán junto con el paquete que queremos instalar.

# yum deplist httpd

package: httpd.i386 2.2.3-45.el5.centos.1
dependency: libz.so.1
provider: zlib.i386 1.2.3-3
dependency: /bin/mv
provider: coreutils.i386 5.97-23.el5_4.2
provider: coreutils.i386 5.97-23.el5_6.4
provider: coreutils.i386 5.97-23.el5_6.3
dependency: liblber-2.3.so.0
provider: openldap.i386 2.3.43-12.el5_5.3
provider: openldap.i386 2.3.43-12.el5_6.7
provider: openldap.i386 2.3.43-12.el5_6.5
...
...

Instalar un RPM y que yum instale las dependencias

Mediante la opción localinstall podemos instalar un paquete rpm local de modo que si fuera necesaria la instalación de otro paquete por dependencias sería yum quien revisara en sus repositorios si existen y en casi afirmativo los instalaría.

# yum localinstall /home/alex/xxxxxxxxxx.rpm

Actualizar un paquete instalado por yum mediante un RPM

Muy similar a localinstall, pero en este caso la opción localupdate nos permite actualizar un paquete que hemos instalado previamente con yum a través de un rpm local. Al igual que en la anterior opción, si es necesario, yum resolverá las dependencias.

# yum localupdate /home/alex/xxxxxxxxxx.rpm

La respuesta es: depende…

A raíz del anterior artículo en el que explico cómo compilar Apache y PHP en Linux me ha apetecido escribir esta entrada en la que definir los pros y contras de compilar frente a usar gestores de paquetes precompilados tipo yum (rpm) o apt (.deb).

Es mejor compilar si…

• Necesitamos tener instalada una versión reciente de la aplicación, y tener la opción de actualizarla en el momento que una nueva versión o parche de seguridad aparezca.
• Necesitamos poder personalizar al 100% la aplicación. Compilando puedes definir una gran cantidad de parámetros, configuraciones y módulos. Esta flexibilidad te permite adaptar la aplicación a tus requerimientos. Los paquetes utilizados por los gestores de descargas añaden el mayor número de extras posibles para una mayor aceptación general.
• No nos importa perder un poco de tiempo al principio (durante la instalación), ya que se requiere más tiempo que la instalación de un paquete precompilado (escasos segundos).
• Probablemente lograremos un mejor rendimiento ya que adaptamos la aplicación a nuestros requerimientos.

Es mejor usar yum, rpm, apt, deb si…

• Necesitamos hacer la instalación de forma rápida y sencilla. Los paquetes precompilados .rpm, .deb, etc se instalan en escasos segundos y automáticamente buscan las dependencias de cada paquete para evitar tener que instalarlas de forma manual como pasaría con la compilación.
• No es crítico disponer de la última versión de la aplicación. Los repositorios por lo general no se actualizan a la misma velocidad que salen nuevas versiones (ni por asomo), por ejemplo RHEL y CentOS actualmente tienen en su repositorio la versión 5.1.6 de PHP y la estable es la 5.3.6.
• Instalar el paquete precompilado no te permitirá personalizar la instalación del mismo como puedes hacerlo compilando. Normalmente se peca de exceso y se añaden módulos y extras en las aplicaciones que probablemente no necesites.
• Siguiendo con el punto anterior, ese exceso de extras puede provocar peor rendimiento que el que te da la instalación por compilación ya que no has podido reducir el peso de la instalación o adecuarlo a tus necesidades.

Estos son, en mi humilde opinión, los pros y contras de cada una de estas formas de instalación en Linux (y en Unix en general).

RPM Package Manager (o RPM, originalmente llamado Red Hat Package Manager) es una herramienta de administración de paquetes pensada básicamente para Linux. Es capaz de instalar, actualizar, desinstalar, verificar y solicitar programas. RPM es el formato de paquete de partida del Linux Standard Base. Wikipedia

Originalmente desarrollado por Red Hat para Red Hat Linux, en la actualidad muchas distribuciones GNU/Linux lo usan, dentro de las cuales las más destacadas son Fedora Linux, MandrivaLinux, SuSE Linux y Conectiva Linux. También se ha portado a otros sistemas operativos.

A continuación explico los comandos básicos para la gestion de paquetería RPM, instalar, desinstalar, actualizar, buscar, etc.

Instalación de paquetes RPM

# rpm -ivh foo-2.0-4.i386.rpm
# rpm -i ftp://ftp.redhat.com/pub/redhat/RPMS/foo-1.0-1.i386.rpm
# rpm -i http://oss.oracle.com/projects/firewire/dist/files/kernel-2.4.20-18.10.1.i686.rpm

Como podéis observar, podemos instalar paquetes RPM descargardos en el propio sistema además de hacerlo directamente vía ftp o http. En cuanto a los parámetros, -i es de install, -v de verbose y -h de hash, podéis verlo en la ayuda del propio comando (–help o man)

Desinstalar paquetes RPM

# rpm -e foo

Actualizar paquetes RPM

# rpm -Uvh foo-1.0-2.i386.rpm
# rpm -Uvh ftp://ftp.redhat.com/pub/redhat/RPMS/foo-1.0-1.i386.rpm
# rpm -Uvh http://oss.oracle.com/projects/firewire/dist/files/kernel-2.4.20-18.10.1.i686.rpm

Lo que hacemos al actualizar de este modo vía rpm es desinstalar el paquete antiguo e instalar el nuevo, también soporta el protocolo ftp y http.

Listar todos los paquetes RPM instalados en el sistema

# rpm -qa

Esta orden listará todos los paquetes instalados en el sistema.

Listar determinados paquetes RPM

# rpm -q foo

De este modo listamos la información de un determinado paquete, su nombre, versión, etc.

Listar información de un paquete RPM

# rpm -qi foo

Listar ficheros de un paquete RPM instalado

# rpm -ql foo

Verificar firma de un paquete RPM

# rpm --checksig foo

Por supuesto, “foo” es un ejemplo de paquete… ;)

Traducido y adaptado de RPM Commands.

El otro día ya hablé de un problema relacionado con la visualización de gráficos en cacti, que estaba relacionado con una mala configuración de las rutas a las fuentes de rrdtool.

El problema ha vuelto a reproducirse en el sistema de monitorización Cacti que monté hace poco, y trasteando un poco encontré que existe un bug en la versión 1.2.28 de RRDtool que impide que se muestren los textos y leyenda en un gráfico.

La solución que a mi me ha funcionado, ha sido desinstalar la versión 1.2.28 que instalé via YUM (CentOS):

yum remove rrdtool.i386

Y bajar a la versión 1.2.27, con la cual el problema queda solucionado. Podéis instalar esta versión vía RPM, yo me bajé el paquete de aquí, una vez descargado lo instaláis vía RPM:

rpm -i rrdtool-1.2.27-2.i586.rpm

Y los gráficos vuelven a visualizarse correctamente ;)