El mundo en bits: red hat

Mostrando entradas con la etiqueta red hat. Mostrar todas las entradas

Mostrando entradas con la etiqueta red hat. Mostrar todas las entradas

Red Hat, instalar versión de un paquete

Hoy toca enseñar un pequeño truco acerca de cómo instalar una versión concreta de un paquete en sistemas Red Hat. En la mayoría de los repositorios, los mantenedores van sacando nuevas versiones y aunque puede resultar muy útil tener siempre la última versión instalada (seguridad, estabilidad, etc.) puede darse el caso de que necesites una versión concreta de un paquete para una determinada prueba. En este caso, la forma de instalarlo ya no es la de siempre,

shell> yum install openssh-server

Sino que hay que saber qué versión del paquete necesitas instalar y pasársela al instalador.

Para empezar, vamos a ver el listado de paquetes disponibles en el repositorio y con su correspondiente versión.

shell> yum --showduplicates list openssh-server
Paquetes disponibles
openssh-server.x86_64   5.3p1-104.el6       base
openssh-server.x86_64   5.3p1-104.el6_6.1   updates

Y de ahí, podemos optar por instalar el paquete que deseemos, tal que así

shell> yum install package-version

Que traducido a un caso concreto, quedaría,

shell> yum install openssh-server-5.3p1-104.el6

Espero que os haya sido de ayuda.

/var/spool/cron, bailing out

Hoy tuve uno de esos fallo extraños que suceden algunos días cuando estás probando cosas nuevas. Concretamente estaba ejecutando el comando crontab para poder listar aquellas tareas que el usuario apache tenía dispuestas. Por ponernos en antecedentes, estaba bajo un sistema Red Hat, lo cual es un poco diferente de lo habitual, Debian. El comando se llamaba desde una página PHP con la sintaxis típica,

...
$output = shell_exec('crontab -l');
...

El resultado devolvía el code status 1 y por lo tanto no tenía salida ninguna. Si ejecutaba el comando empleando sudo, se podía ver perfectamente el listado de comandos de cron para éste usuario.

shell> sudo -u apache crontab -l
  */30 * * * *  python /usr/local/bin/test.py
  */15 * * * *  python /usr/local/bin/test2.py

Llegados a este punto, lo más lógico es pensar que algo está fallando, así que tocó hacer una revisión de los logs, en el cual aparecía la siguiente línea,

'/var/spool/cron' is not a directory, bailing out.

Una línea bastante descriptiva y en la que se nos dice, básicamente que SELINUX, ese gran sistema de control de permisos de Red Hat, estaba impidiendo el acceso a dicho directorio. Puesto que tenía prisa, lo más rápido fue editar el fichero /etc/selinux/config y deshabilitar SELINUX,

SELINUX=disabled

Con lo que el comando comenzó ya a devolver los datos esperados.

Cambio de hostname en RedHat/CentOS

Recientemente tuve que cambiarle el nombre FQDN (Fully Qualified Domain Name) a un servidor Red Hat y descubrí que es "un poco" lioso hacerlo, sobre todo si es la primera vez. Para recordar cómo se hace y por si le sirve de ayuda a alguien, opté por escribir esta entrada y dejar así constancia de los pasos a realizar. Por suerte, esta técnica sirve para sistemas Red Hat, Centos e imagino que Federa, aunque no lo probé en este último.

Lo primero de todo es crear el fichero, en caso de que no exista /etc/hostname con el contenido del fqdn que deseemos. En mi caso,

compile.server.loc

A continuación, debemos de cargar el nuevo nombre en el sistema, para ello,

shell> hostname -F /etc/hostname

Tranquilos, ya estamos llegando al final. Ahora debemos de editar el fichero de configuración de red, /etc/sysconfig/network y cambiar en él el HOSTNAME del equipo.

NETWORKING=yes
HOSTNAME=compile.server.loc

Y reiniciar la red del equipo para que pille los nuevos parámetros,

shell> service network restart

Y ahora ya deberíamos de tener el hostname completo,

shell> hostname --fqdn
compile.server.loc

En caso de que tengamos el siguiente error al ejecutar el comando hostname - -fqdn

hostname: `Host' desconocido

debemos de editar el fichero /etc/hosts y añadir el nuevo FQND con la IP del servidor.

Postfix: Permission denied

El otro día estaba intentando enviar mails desde una aplicación web, corriendo en un Apache con un servidor con Red Hat y, qué raro, los correos no se enviaban y la función siempre daba fallo. El código PHP sabía que estaba correcto y con Postfix también correctamente configurado, tuve que investigar un poco más el motivo.

Tras ver un poco por los logs, concretamente en el fichero relacionado con el sistema de correo (/var/log/maillog), vi que se estaba llenando de líneas como las que siguen:

postfix/sendmail[8500]: fatal: chdir /var/spool/postfix: Permission denied
postfix/sendmail[9316]: fatal: chdir /var/spool/postfix: Permission denied
postfix/sendmail[9764]: fatal: chdir /var/spool/postfix: Permission denied

Tras un poco más de investigación me acordé de que Red Hat trae SELinux y que probablemente me estuviese molestando un poco. Lo primero que hice fue comprobarlo para estar seguro y nada mejor para ello que el comando getsebool.

shell> getsebool -a | grep mail
   allow_postfix_local_write_mail_spool --> on
   httpd_can_sendmail                   --> off
   logging_syslogd_can_sendmail         --> off

Bien, efectivamente aquí tenemos el problema. La variable httpd_can_sendmail está a off, con lo cual deshabilita|bloquea|prohibe cualquier posibilidad de envío de correos desde el servidor. Así que vamos a habilitarla.

shell> setsebool httpd_can_sendmail 1

Tras este sencillo comando, comprobamos que el nuevo valor se estableció correctamente,

shell> getsebool -a | grep httpd_can_sendmail
   httpd_can_sendmail --> on

Y ahora desde la aplicación web ya me permite enviar correos de forma satisfactoria.

Instalación de paquetes en GNU/Linux

Por suerte, desde hace ya muchos años instalar o desinstalar paquetes en los diferentes sistemas operativos de base Linux se hizo mucho más sencillo. Al principio de los tiempos, instalar algo era casi para "nativos del código fuente". Aun recuerdo la época en la que había que compilar los binarios con todas sus dependencias. Conseguías más rendimiento, puede ser, si sabías lo que hacías, pero actualizar un paquete era casi misión imposible. El trabajo casi nunca compensaba el esfuerzo.

Por suerte, el mundo Linux avanzó y las principales distribuciones tienen desde hace mucho tiempo repositorios en los que ofrecen software ya compilado y empaquetado. Así, instalar o actualizar un paquete es una tarea muy sencilla. Pero por supuesto, cada distribución, optó por un método diferente y para nada homogéneo, ni de paquetes ni de instrucciones para la instalación.

A continuación os dejo aquí una tabla comparativa de los comandos que cada distribución tiene para hacer la misma tarea. En todos los casos, los paquetes a instalar vienen de los repositorios que estén configurados en cada uno de los sistemas.

Linux OS	search	install	update	remove
Debian Ubuntu Linux Mint	apt-cache search [pkg]	apt-get install [pkg]	apt-get upgrade	apt-get remove [pkg]
Fedora Red Hat CentOS	yum search [pkg]	yum install [pkg]	yum update	yum remove [pkg]
Mandriva Mageia	urpmi -y [pkg]	urpmi [pkg]	urpmi-auto-select	urpme [pkg]
OpenSuse	zypper search [pkg]	zypper install [pkg]	zypper update	zypper remove [pkg]
Arch	pacman -Ss [pkg]	pacman -S [pkg]	pacman -Syu	pacman -R [pkg]
Gentoo	emerge -s [pkg]	emerge [pkg]	emerge -uD [pkg]	emerge -C [pkg]

Es muy recomendable tener presente esta chuleta de ayuda siempre que tengáis que manejar más de un sistema de base Linux de una familia diferente.

Levantar red en inicio del sistema CentOS

Hoy Susi me preguntó por qué una máquina virtual con CentOS no levantaba automáticamente la red como el resto, máquinas Ubuntu. Lo cierto es que a mi esto mismo también me pasó en alguna instalación de CentOS sobre VirtualBox. No se por qué, pero durante la instalación el sistema decide que es mejor que el interfaz de red no se levante cuando la máquina arranca. Pero puesto que trabajando con máquinas virtuales para ofrecer servicios tener levantada la red es algo esencial, vamos a ver qué hacer para que el interfaz de red se levante cuando la máquina arranca.

CentOS tiene la configuración de las tarjetas de red por defecto bajo /etc/sysconfig/network-scripts y ahí, en un fichero de configuración ifcfg-iface, donde iface es el nombre dela tarjeta de red, por eejmplo eth0. Cuando instalas el sistema, si este detecta una tarjeta y se configuró, crea un fichero ifcfg-eth0, por ejemplo, con el siguiente contenido.

DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="XX:XX:XX:XX:XX:XX"
NM_CONTROLLED="yes"
ONBOOT="no"
TYPE="Ethernet"
UUID="465985d0-ab5b-..."

El problema de que tras el reinicio del sistema el equipo no levante el interfaz de red radica en este fichero y concretamente en la variable

...
ONBOOT="no"
...

que como podemos observar indica que el interfaz no se levante por defecto en el arranque del sistema. Para solucionarlo, simplemente cambiamos el valor de la variable a yes,

...
ONBOOT="yes"
...

Y en el próximo reinicio ya no deberíamos de tener problemas.

Puesto que me parece algo interesante, mejor compartirlo con todos, pues no creo que nos pase únicamente a nosotros.

Comprobando fallos de seguridad con yum

Prácticamente todas las distribuciones actuales de GNU/Linux tiene un método de control para informar sobre los fallos de seguridad y poder aplicar los parches correspondientes que salen. Hoy vamos a ver cómo realizar esta tarea en Red Hat, apoyándonos en yum, su gestor de paquetes. Este truco es aplicable tanto para Red Hat como para Fedora, no así para CentOS, que cambia un poco la forma de emplearlo y el nombre de los paquetes.

Desde yum podremos obtener información acerca de los fallos de seguridad más recientes que hay, así como datos adicionales de los mismos. De la misma forma, también podremos lanzar una actualización que sólo afecte a aquellos paquetes con problemas de seguridad, que son los más urgentes. Para realizar todas estas tareas, vamos a emplear el paquete yum-plugin-security, que no es más que un plugin que se encarga de tratar desde yum los temas de seguridad. Lo primero, instalarlo.

shell> yum install yum-plugin-security

Una vez instalado, podremos ya pedirle al sistema que nos enumere aquellos fallos de seguridad que están presentes en nuestro sistema, es decir, aquellos a los que todavía no se les aplicó un parche. Por ejemplo, la salida de un servidor con Red Hat 6,

shell> yum updateinfo list security

RHSA-2014:0328 Important/Sec. kernel-2.6.32-431.11.2.el6.x86_64
RHSA-2014:0328 Important/Sec. kernel-firmware-2.6.32-431.11.2.el6.noarch
RHSA-2014:0328 Important/Sec. kernel-headers-2.6.32-431.11.2.el6.x86_64
RHSA-2014:0330 Moderate/Sec.  libsmbclient-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-common-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-winbind-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-winbind-clients-3.6.9-168.el6_5.x86_64

Una vez tengamos el listado de fallos de seguridad, podremos obtener más información acerca de cualquiera de ellos.

shell> yum updateinfo "RHSA-2014:0328"

====================================================================
Important : kernel security and bug fix update
====================================================================
Update ID : RHSA-2014:0328
  Release : 
     Type : security
   Status : final
   Issued : 2014-03-25 00:00:00
     Bugs : 921970 - CVE-2013-1860 kernel: usb: cdc-wdm buffer overflow ...
          : 1062577 - CVE-2014-0055 kernel: vhost-net: insufficient ...
          : 1064253 - CVE-2014-0069 kernel: cifs: incorrect handling of...
          : 1070705 - CVE-2014-0101 kernel: net: sctp: null pointer ...
     CVEs : CVE-2013-1860
          : CVE-2014-0101
          : CVE-2014-0055
          : CVE-2014-0069
 Descript : The kernel packages contain the Linux kernel, the core of any
          : Linux operating system.
          : 
          : * A flaw was found in the way the get_rx_bufs()
          :   function in the vhost_net implementation in the
          :   Linux kernel handled error conditions reported
          :   by the vhost_get_vq_desc() function. A
          :   privileged guest user could use this flaw to
          :   crash the host. (CVE-2014-0055, Important)
          ...

 Severity : Important

Es importante aquí destacar la información que el primero comando nos da, pudiendo diferenciar rápidamente los tipos de vulnerabilidades por su criticidad (Important, Moderate, bugfix, etc.).

Por supuesto, una vez obtenemos este listado, actualizar el paquete en cuestión es muy sencillo, aunque ir paquete a paquete no es lo más eficiente. Para actualizar todos aquellos paquetes con un bug de seguridad, simplemente,

shell> yum --security update-minimal

Ya no hay excusas para no estar informado de aquellos problemas de seguridad y cómo afectan a nuestros sistemas, ni por supuesto, tener los sistemas sin el adecuado parche. Una de las mejoras cosas que tiene GNU/Linux es que los parches de seguridad salen casi tan rápido como los fallos se publican.

Restaurar permisos originales de un fichero

¿A quién no lo pasó alguna vez que cambió los permisos de un fichero o directorio completo sin querer y luego no sabía volver a los preestablecidos por el desarrollador?

Supongo que alguna vez ésto nos pasó a todos y no es una buena experiencia. Así que para intentar subsanar este tipo de fallos, hoy os presento un truco muy simple, para sistemas Red Hat y derivados, que permite restablecer los valores originales de forma muy sencilla. Ya bien sea para un fichero concreto o para todo un directorio, gracias a rpm --setperms volver a poner los permisos originales nunca fue tan sencillo.
Vamos a ver el comando en funcionamiento, que es la mejor forma de entender de lo que hablamos.

Partimos de estos permisos originales de un fichero cualquiera.

shell> ls -l /etc/ssh/ssh_config
  -rw-r--r--. 1 root root 2047 may 15  2012 /etc/ssh/ssh_config

y se los cambiamos por estos otros,

shell> chmod 777 /etc/ssh/ssh_config
shell> ls -l /etc/ssh/ssh_config
  -rwxrwxrwx. 1 root root   2047 may 15  2012 /etc/ssh/ssh_config

Como vemos, una equivocación no muy común, pero que en ese fichero puede traer consecuencias inesperadas. Aunque en el ejemplo es muy sencillo volver a los permisos originales, entre otras cosas por que sabemos a que volver, imagina que esto mismo se hiciera recursivo y afectase a todo /etc.
Lo que nos interesa es ver cómo volver a los valores originales del paquete sin tener que hacerlo manualmente. Para ello,

shell> rpm --setperms openssh-clients-5.3p1-81.el6.x86_64
shell> ls -l /etc/ssh/ssh_config
  -rw-r--r--. 1 root root   2047 may 15  2012 /etc/ssh/ssh_config

Y lo único que necesitas saber es el nombre del paquete que contiene el fichero o ficheros que has modificado, para lo cual,

shell> rpm -qf /etc/ssh/ssh_config
  openssh-clients-5.3p1-81.el6.x86_64

La entrada Restaurar permisos originales de un fichero la puedes leer el El mundo en bits.

GPG key Error con yum

Aunque este error fue algo esporádico, la verdad es que tiene su lógica y probablemente a vosotros también os haya pasado si habéis creado el fichero de acceso a EPEL directamente y no instalasteis el paquete del repositorio.

Por defecto, el fichero que emplea yum para acceder al repositorio EPEL es /etc/yum.repos.d/epel.repo, el cual contiene una línea similar a la que sigue, que hace referencia a un fichero de clave GPG.

...
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

Si dicho fichero no existe, no se puede verificar la autenticidad de los paquetes, por lo que el siguiente fallo aparecerá al intentar descargar e instalar algún paquete desde dicho repositorio.

shell> yum update
...
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

La solución más sencilla es instalar el fichero del repositorio con el paquete epel-release, que se encargará de crear el fichero del repositorio, localizado bajo /etc/yum.repos.d/ y también el fichero con la clave GPG.

shell> yum install epel-release.noarch

Tras la instalación de dicho paquete, ya no se debería de volver a tener dicho error. Al intentar instalar algo por primera vez desde el repositorio EPEL, nos saldrá el siguiente aviso de empleo de clave GPG.

shell> yum update
...
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Importing GPG key 0x0608B895:
 Userid : EPEL (6) 
 Package: epel-release-6-8.noarch (@epel)
 From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Is this ok [y/N]: y
Running rpm_check_debug
...

Tras aceptarlo, ya se podrá trabajar con el repositorio EPEL de forma permanente y certificando la autenticidad de los paquetes.

Yum, Metadata file does not match checksum

Hoy tuve una mala experiencia con yum. Necesitaba instalar unos paquetes y como siempre, en el peor momento, el mejor error. El detalle vino al intentar actualizar el listado de paquetes disponibles que tenía el servidor remoto (en este caso epel). Tras descargar la base de datos, al hacer la comparación daba un error de checksum: Los datos no coinciden!.

shell> yum install php-pdo.x86_64
...
epel/pkgtags                                       | 996 kB     00:01
http://...: [Errno -1] Metadata file does not match checksum
Trying other mirror.                               | 997 kB     00:00
epel-testing/pkgtags                               | 996 kB     00:01
http://...: [Errno -1] Metadata file does not match checksum

Este fallo se produce en numerosas ocasiones en sistemas RedHat, CentOS y Fedora, principales distribuciones basadas en RPM. El error que obtenemos, nos indica que la versión del fichero que tenemos cacheada no coincide con la versión que estamos descargando. Existen por lo tanto dos soluciones: La primera, esperar a que se caduque la caché local, lo que hará el purgado automático de dicho fichero. La segunda, forzar la limpieza de la caché con,

shell> yum clean all

Y tras ello ejecutar nuevamente el comando. Descargará todos los ficheros completos, lo que puede llevarle un tiempo si tenemos muchos repositorios, pero habremos solucionado el problema.

shell> yum install php-pdo.x86_64
...
epel/metalink                                      |  23 kB     00:00
epel                                               | 4.2 kB     00:00
epel/primary_db                                    | 6.0 MB     00:00
epel-testing/metalink                              |  23 kB     00:00
epel-testing                                       | 4.2 kB     00:00
epel-testing/primary_db                            | 405 kB     00:00
Setting up Update Process
Resolving Dependencies
...

La entrada Yum, Metadata file does not match checksum la puedes leer en El mundo en bits.

Deshabilitar IPv6 en RedHat

¿Estás en una red con IPv6?

Si la respuesta es NO, entonces para qué sigues teniendo habilitado el soporte para IPv6.
La forma de deshabilitar dicho soporte en RedHat/Centos es tan simple como editar el fichero /etc/sysctl.conf y establecer a 1 las siguientes variables,

shell> vi /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

En caso de que éstas no existan, las creamos.
Una vez tengamos el fichero guardado, obligamos al sistema a volver a leer dicha configuración,

shell> sysctl -p

Con esto ya tenemos deshabilitado el soporte IPv6. Sencillo e rápido.
Los cambios son permanentes al reinicio, por lo que si vuelves a querer tener soporte IPv6, acuérdate de lo que tienes que tocar.

La entrada Deshabilitar IPv6 en RedHat la puedes leer en El mundo en bits.

Deshabilitar SELinux en RedHat

Este truco sirve para cualquier sistema de la familia RedHat, como CentOS y Fedora. SELinux (Security-Enhanced Linux) es un módulo de seguridad para el kernel Linux que proporciona el mecanismo para soportar políticas de seguridad para el control de acceso ^wikipedia. Aunque suele ser muy útil y puede darte un extra de seguridad en tu sistemas, puede que prefieras deshabilitarlo. En caso de que eso sea así, es muy sencillo.

shell> vi /etc/selinux/config
SELINUX=disabled

Con el cambio a disabled de la variable SELINUX, ya tenemos todo listo.

La entrada Deshabilitar SELinux en RedHat la puedes leer en El mundo en bits.

Cambiar hostname en RedHat/CentOS

Hoy os voy a dejar un pequeño truco para aquellos que todavía no sepan cómo hacerlo y es cómo cambiar el nombre del equipos en sistemas RedHat/CentOS y derivados.

En sistemas basados en Debian, existe el fichero /etc/hostname, que es prácticamente el que controla el nombre del equipos. Sin embargo, en sistemas RedHat, este fichero no existe. Así que cambiar el nombre del equipo, ya no es únicamente cuestión de editar ese fichero. Los pasos a seguir para hacerlo son:

Cambiar el fichero de red
El nombre del equipo se almacena en el fichero /etc/sysconfig/network y es ahí dónde debemos de cambiarlo, tal como se muestra a continuación.
```
shell> cat /etc/sysconfig/network
HOSTNAME=tu_hostname.local.net
NETWORKING=yes
GATEWAY=192.168.0.1
```
Cambiar el fichero de hosts
Otro de los ficheros importantes a cambiar es /etc/hosts, ya que necesitará saber el nuevo nombre del equipo. Para ello,
```
shell> cat /etc/hosts
127.0.0.1 tu_hostname localhost.localdomain localhost
::1  localhost6.localdomain6 localhost6
```
Cambiar el hostname
Una vez ya tenemos los pasos anteriores, vamos a cambiar el hostname en tiempo real. Para ello empleamos el comando hostname, pasándole como argumente el nuevo nombre del host.
```
shell> hostname tu_hostname
shell> hostname
tu_hostname
```
Cambiar la configuración de correo
En caso de que empleéis postfix, puede ser necesario revisar la configuración del mismo y cambiar aquellos lugares donde esté el nombre del equipo, para evitar problemas de correo rechazado. Así que, si es el caso, revisar vuestra configuración (/etc/postfix/main.cf) y cambiarla
```
shell> vi /etc/postfix/main.cf
...
myhostname = tu_hostname.local.net
...
mydestination = localhost, tu_hostname.local.net
...
```
Reiniciar la red o el equipo
Finalizado todo lo anterior, es hora de aplicar el cambio. Hay dos opciones, la primera y más sencilla sin meterte en problemas, reiniciar el equipo,
```
shell> reboot
```
Y la segunda, que también es simple, reiniciar la red, salir de la sesión y volver a entrar.
```
shell> service network restart
shell> logout
```

Espero que os haya ayudado.

La entrada Cambiar hostname en RedHat/CentOS la puedes leer en El mundo en bits.

Firmar paquete RPM local

Muy estrechamente relacionado con el tema de crear repositorios locales para RedHat/CentOS, está la necesidad de autenticar dichos repositorios y el contenido de los mismo. Está claro que si el repositorio se sirve vía http, podemos emplear https con un certificado válido para nuestra empresa y así ya tener autenticación de origen de datos, sin embargo no tenemos ninguna garantía de que los paquetes que vamos a instalar estén realmente firmados como es debido. Para ello, cada vez que creemos un paquete que se vaya a subir al repositorio, antes de hacerlo, deberíamos de firmarlo. En este post, vamos a ver cómo conseguirlo.

Primero comenzamos creando una clave gpg para el firmado. Obviamente esta clave es generada localmente, por lo que el certificado no estará aceptado por autoridades externas.

shell> gpg --gen-key
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Por favor seleccione tipo de clave deseado:
  (1) RSA and RSA (default)
  (2) DSA and Elgamal
  (3) DSA (sólo firmar)
  (4) RSA (sólo firmar)
Su elección: 1
las claves RSA pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (2048)
El tamaño requerido es de 2048 bits
Por favor, especifique el período de validez de la clave.
  0 = la clave nunca caduca
    = la clave caduca en n días
  w = la clave caduca en n semanas
  m = la clave caduca en n meses
  y = la clave caduca en n años
¿Validez de la clave (0)? 0
La clave nunca caduca
¿Es correcto? (s/n) s
Necesita un identificador de usuario para identificar su clave. El programa
construye el identificador a partir del Nombre Real, Comentario y Dirección
de Correo Electrónico de esta forma:
    "Heinrich Heine (Der Dichter) "
Nombre y apellidos: Javier Terceiro
Dirección de correo electrónico: javier@miempresa.com
Comentario:
Ha seleccionado este ID de usuario:
    "Javier Terceiro "
¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V
Necesita una frase contraseña para proteger su clave secreta.

Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
..+++++......++++++++++
gpg: clave 1C5D59BF marcada como de confianza absoluta
claves pública y secreta creadas y firmadas.

gpg: comprobando base de datos de confianza
gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias,
modelo de confianza PGP
gpg: nivel: 0  validez: 1  firmada: 0  confianza: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/1C5D59BF 2012-05-21
  Huella de clave = 2493 D660 1A83 12F5 0A50  2E71 8A82 1165 1C5D 59BF
uid                  Javier Terceiro 
sub   2048R/25A1D82A 2012-05-21

Una vez tengamos la firma creada, ya estamos preparados para firmar todos los paquetes que vayamos creando. Para ello, vamos a crear el fichero .rpmmacros en la home del usuario que los vaya a firmar. Dicho fichero tendrá el siguiente contenido.

%_signature gpg
%_gpg_name Repository Owner

Y ahora para firmar un paquete nuevo, únicamente hay que ejecutar,

shell> rpm --resign zabbix-server-1.8.12.src.rpm
Enter pass phrase:
Pass phrase is good.
zabbix-server-1.8.12.src.rpm

Y si ahora interesa saber si el fichero está correctamente firmado, simplemente,

shell> rpm -K zabbix-server-1.8.12.src.rpm
zabbix-server-1.8.12.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#1C5D59BF)

Como podéis ver algo muy simple de hacer y que te aporta ese extra de seguridad a los paquetes que tú mismo crees y que evitará que ante un ataque se sustituyan por otros infectados.

Centos/Red Hat multipath config

multipath es una metodología de acceso a disco que propone tener varios caminos diferentes para el acceso a disco. Esta nueva implementación surgió con la llegada de las cabinas SCSI, que permiten tener varios accesos, bien sean redundantes, o bien sean de reparto de carga. multipath es un concepto muy similar al bounding, el primero aplicado a almacenamiento y el segundo a red.

En este post vamos a ver qué software instalar y también cómo configurar el acceso multipath desde un sistema Red Hat, para evitar caídas de una cabina y por lo tanto, de disponibilidad de servicio.

Instalación del servicio
Se instala el software necesario para poder hacer uso del multipath.
```
shell> yum install device-mapper-multipath
```
Inicio automático
Usaremos el comando chkconfig, que ya vimos en post anteriores.
```
shell> chkconfig multipathd on
```
Ejemplo de configuración

mpathconf
Permite realizar una primera configuración del servicio, creando el fichero de configuración, ya sea con los valores por defecto o especificando unas directivas concretas, que se nos preguntarán o podremos pasar en línea de comandos.

Para crear una configuración estándar y arrancar,
```
shell> mpathconf --enable
```
mpathconf failover
Este otro ejemplo arrancaría dm-multipath con una configuración de failover,
```
shell> mpathconf --enable --with_multipathd
```

Revisad la página man de mpathconf para más información.

Arrancar el servicio

Podemos arrancar ahora el servicio tal como sigue y observar que el demonio está corriendo.

shell> service multipathd start
shell> ps aux | grep multipath
root  1284  1.0  0.0  567  1467  ?  SLl  05:02  0:00  /sbin/multipathd

Nota final

Algo muy importante a tener en cuenta es la necesidad de incluir en la blacklist de la configuración, todos los discos locales para evitar que formen parte del multipath.

Por ejemplo, si los discos locales son reconocidos como sdaX, es importante incluirlos en la blacklist para evitar que el servicio busque una ruta redundante para ellos. Para hacerlo, habría que añadirlos, tal como sigue.

blacklist {
  wwid 26353900f02796769
  devnode "^(loop|fd|scd|sda)[0-9]*"
  devnode "^hd[a-z]"
}

RedHat, limpiar paquetes descargados

Una de las cosas que siempre suele suceder al instalar y actualizar paquetes en nuestras distribuciones es que estos terminan ocupando más espacio del que deberían. Por defecto, al actualizar un paquetes, éste suele ocupar un poco más de espacio que el anterior, por nuevas funcionalidades o librerías nuevas que incluya, pero a mayores, ocupa todo el espacio del propio paquete que se descargar. Este paquete queda en la caché de nuestro gestor de paquetes y por lo tanto en disco, aunque no sea estrictamente necesario.

En sistemas debian, para hacer un purgado de dichos ficheros nos llega con hacer,

shell> apt-get clean

En sistemas Redat/CentOS, que emplean yum, también podemos hacer algo similar que ayuda al purgado de dichos paquetes,

shell> du -sh /var/cache/yum
48M   /var/cache/yum
shell> yum clean all
Loaded plugins: fastestmirror
Cleaning up Everything
Cleaning up list of fastest mirrors
shell> du -sh /var/cache/yum
84K   /var/cache/yum

Como se puede observar, tras el purgado el espacio fue liberado. En el fichero de configuración, /etc/yum.conf, está definido el directorio cachedir.

rpm rollback package

El sistema de paquetería RPM no deja de sorprenderme y cada día más. Hoy descubrí un pequeño gran truco. Nada más ni nada menos que el rollback de los paquetes. Esto quiere decir, la marcha atrás de una actualización o instalación de algún paquete, por si el resultado no es el esperado. Tenerlo habilitado, lógicamente consume más espacio es disco, pero los amplios beneficios que ofrece, creo que compensan con creces el espacio extra.

Según lo que dice la documentación oficial, hay que decir que el rollback dejó de estar soportado "oficialmente" desde la versión RHEL 5, aunque internamente sigue funcionando. Así que vamos a ver cómo configurarla y emplearla.

Editamos el fichero /etc/yum.conf y agregamos la línea
```
tsflags=repackage
```
Con ello conseguimos indicarle a yum que debe guardar la información necesaria para poder realizar rollback de los paquetes.
Editamos el fichero /etc/rpm/macros y agregamos la línea
```
%_repackage_all_erasures 1
```
Esta configuración le indica al sistema rpm lo mismo que la anterior.

A partir de este punto el sistema está ya preparado para regresar a un estado anterior si fuera necesario. La forma de poder conseguirlo no es otros que indicándole a rpm la fecha a la que queremos que regrese con la opción rollback,

shell> rpm -Uvh -rollback '1 day ago'

RPM, fecha de instalación de un paquete

Aunque no es algo habitual, quizás en algún momento nos interesa saber en qué día y a qué hora se instaló un paquete en nuestro sistema Red Hat/CentOS, así que la mejor forma de saberlo es preguntárselo a rpm. Este comando nos puede dar un listado de todos los paquetes instalados con la fecha exacta de su instalación. Si el sistema está recién instalado, lo más normal es que todos tengan la misma hora, pero a partir de ahí, según posteriores actualizaciones y nuevas instalaciones, se podrá ver cómo estos van cambiando poco a poco su fecha. Para poder obtener la fecha, únicamente hay que emplear la opción --last.

shell> rpm -qa --last
sudo-1.7.2p1-14.el5_8.3                       Thu Aug 16 13:07:28 2012
nss-tools-3.13.5-4.el5_8                      Tue Aug  7 09:11:48 2012
nscd-2.5-81.el5_8.4                           Tue Aug  7 09:11:48 2012
tzdata-2012c-3.el5                            Tue Aug  7 09:10:41 2012
libtiff-3.8.2-15.el5_8                        Mon Jul  9 09:08:25 2012
e2fsprogs-libs-1.39-34.el5_8.1                Thu Jun 28 11:02:23 2012
perl-Date-Calc-5.4-1.2.2.1                    Wed Jun 20 10:49:01 2012
perl-Bit-Vector-6.4-2.2.2.1                   Wed Jun 20 10:49:01 2012
...

O aplicándolo a un sólo paquetes,

shell> rpm -qa --last sudo
sudo-1.7.2p1-14.el5_8.3                       Thu Aug 16 13:07:28 2012

Este comando a mayores de indicarnos la fecha nos permite obtener un listado de los paquetes que se han instalado juntos (coinciden en fecha), lo que puede ayudar a diagnosticar un problema en el sistema en caso de que algo falle tras la instalación de algún software.

Notificación de actualizaciones en RedHat/CentOS

En sistemas Debian/Ubuntu tenemos software ya especializado en buscar actualizaciones, que podemos hacer que se ejecute diariamente y así tener un informe diario de si hay o no hay actualizaciones pendientes para el sistema. En CentOS/RedHat ésto también es posible y sin necesidad de instalar ningún paquete adicional, sino que el propio gestor de paquetes, yum, trae una opción para hacer tal tarea. Vamos a ver cómo funciona y cómo poder configurarla.

Para empezar, necesitaremos editar el fichero /etc/yum/yum-updatesd.conf y dejarlo tal que así

[main]
# how often to check for new updates (in seconds)
run_interval = 86400
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = email
email_to = admin@tu_empresa.com
email_from = root@tu_empresa.com
# should we listen via dbus to give out update information/check for
# new updates
dbus_listener = yes

# automatically install updates
do_update = no
# automatically download updates
do_download = no
# automatically download deps of updates
do_download_deps = no

Las opciones importantes, las marcadas en negrita, significan:

run_interval
Es el intervalo de frecuencia de búsqueda de actualizaciones. Por defecto viene establecido a una hora (3600 segundos) y lo vamos a poner diario (86400 segundos).
emit_via
Es la forma de notificación de alertas de upgrades. Pueden ser vía email o vía syslog. Como nos interesa tener notificaciones vía mail, seleccionamos email.
email_to
A quién va destinado el correo.
email_from
De quién va a venir el correo.

Una vez tengamos todo listo, sólo queda reiniciar el servicio. Para ello,

shell> /etc/init.d/yum-updatesd restart
   Deteniendo yum-updatesd:                                   [  OK  ]
   Iniciando yum-updatesd:                                    [  OK  ]

Y el correo que tendrá un contenido similar al siguiente,

Hi,
This is the automatic update system on servidorLinux.dominio.com

There are 8 package updates available. Please run the system updater.

Packages available for update:
    portmap
    bind-libs
    man-pages-es
    libselinux-ruby
    rkhunter

CentOS forzar desinstalación de paquetes

Por defecto y desde hace ya algunas versiones Red Hat y por lo tanto CentOS han implantado yum como herramienta para la gestión de paquetes. Sin embargo todavía queda presente el comando rpm que sigue plenamente funcional y que en determinadas ocasiones nos puede ayudar a solucionar problemas.
Como vimos en un post anterior, para desinstalar paquetes desde yum, se emplea la opción erase. En caso de que alguna dependencia falle y no se permita desinstalar el software, el comando no seguirá, por lo que si necesitamos desinstalar dicho paquete, habrá que recurrir al uso de rpm.
Por lo tanto, si interesa desinstalar un paquete, pero no todas las dependencias que éste desinstalará, lo podremos lograr así,

shell> rpm -e --nodeps PACKAGE

En caso de que el número de dependencias sea excesivo y pueda hacer algo que no interesa, se puede forzar la desinstalación de un paquete tal que así, evitando todas las dependencias.

shell> rpm -e --justdb --nodeps PACKAGE

Suscribirse a: Entradas ( Atom )