Lejos han quedado ya los tiempos en que se usaba la expresión “infierno de las dependencias” o que había que ir por ahí buscando herramientas de terceros o recurrir a rebuscados trucos para gestionar instalaciones y actualizaciones en una distribución Linux con paquetes rpm. Hoy en día la combinación rpm/yum de Fedora, Red Hat, CentOS y otras derivadas tiene poco (o nada) que envidiarle a la pareja dpkg/apt-get de Debian & co. En esta entradilla vamos a dar un pequeño repaso a las opciones más comunes y a alguna de las más útiles.

Para empezar, los comandos usados más frecuentemente son estos:

En un gran porcentaje de casos esto es todo lo que debemos conocer de ambos y lo que tendremos que usar de forma habitual. Pero existen muchas otras opciones útiles y/o interesantes:

Cuando queremos instalar un equipo con exactamente los mismos paquetes que otro dado, tenemos la posibilidad de crear una lista de paquetes instalados con el siguiente comando:

1

rpm -qa lista_paquetes.txt

Para luego instalarlos en la segunda máquina de esta forma que nos cuentan en Unixcraft:

1

sudo yum -y install $(cat paquetes.txt)

Para otras posibilidades, tienes buenas referencias aquí para yum y aquí y aquí para rpm (pero con cuidado, que he visto algunos ejemplos que usan opciones que ya no están disponibles, como --repackage) o, por supuesto, en las páginas del manual de cada una de ellas.

Además, yum cuenta con un amplio repertorio de plugins que le permiten mejorar u optimizar su trabajo. Puedes ver la lista de la que dispones en tus repositorios con alguno de los comandos que acabas de aprender (yum list yum-plugin* o yum search yum-plugin funcionarían). Aparte de los que vienen cargados con Fedora por defecto, estos son los que considero imprescindibles:

• yum-plugin-fastestmirror elige el repositorio óptimo de entre una lista de mirrors.
• yum-plugin-remove-with-leaves elimina también los paquetes de dependencias huérfanos cuando se borra un paquete
• yum-plugin-downloadonly añade la posibilidad de poder descargar un paquete de los repositorios sin realizar su instalación

Y nos falta aún por ver la forma de indicarle al sistema donde están los repositorios de software, o sea, el equivalente al archivo /etc/apt/sources.list de los Debian. Esto se hace en archivos con extensión .repo que deben de crearse en el directorio /etc/yum.repos.d. Lo normal es crear un archivo por cada repositorio o familia de estos. Aquí tenemos también diferentes opciones de personalización. Veamos un ejemplo:

1
2
3
4
5
6
7
8

[kde-testing]
name=kde-testing
# baseurl=http://ftp.heanet.ie/pub/kde-redhat/fedora/$releasever/$basearch/testing
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-testing
enabled=1
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
gpgcheck=1
skip_if_unavailable=1

En las páginas del manual de yum.conf (el archivo de configuración de esta herramienta) tienes explicadas estas opciones y otras muchas bajo el epígrafe de repository options.

Y para el que prefiera una utilidad gráfica y, como a mi, no le entusiasme KPackagekit (apper desde fedora 16), puede echarle un vistazo a yumex (mi favorito) o a smart.

A partir de la anterior Fedora 15 se introdujo systemd como system y session manager. El cambio fue tan “transparente” que yo ni me enteré de ello. Sin embargo desde el momento en que instalé la beta de Fedora 16, hace ya algo más de un mes, empecé a notar que pasaban cosas raras en mi equipo… Había servicios que no me aparecían activos en el arranque y que no respondían igual a los comandos y herramientas que vimos en una chuletilla anterior.

Los nuevos servicios de Fedora ya no se encuentran en /etc/init.d (aunque alguno queda aún ahí imagino que por compatibilidad) sino que están en el directorio /lib/systemd/system y para interactuar con ellos en línea de comando ya no usamos el comando service, sino systemctl.

systemctl es un comando mucho más rico en opciones y posibilidades que su predeceror, pero como guía de inicio y emergencia, te conviene ir anotando las siguientes.

Para iniciar un servicio, por ejemplo sendmail:

1

$ sudo systemctl start sendmail.service

Los servicios ahora parecen tener todos ese formato terminado en “.service”. Aparte de start tenemos las opciones clásicas: stop, restart, reload y status. La opción status da mucha más información de lo que teníamos anteriormente:

1
2
3
4
5
6
7
8

$ sudo systemctl status vboxdrv.service
 
          vboxdrv.service - LSB: VirtualBox Linux kernel module
          Loaded: loaded (/etc/rc.d/init.d/vboxdrv)
          Active: active (exited) since Mon, 07 Nov 2011 18:45:22 +0100; 3s ago
         Process: 5550 ExecStop=/etc/rc.d/init.d/vboxdrv stop (code=exited, status=0/SUCCESS)
         Process: 5572 ExecStart=/etc/rc.d/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/vboxdrv.service

Por último, para habilitar el inicio automático de un servicio en el arranque o para deshabilitarlo, respectivamente, tenemos las opciones enable y disable:

1
2
3
4
5

$ sudo systemctl enable cups.service
 
ln -s '/lib/systemd/system/cups.service' '/etc/systemd/system/printer.target.wants/cups.service'
ln -s '/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket'
ln -s '/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'

1
2
3
4
5

$ sudo systemctl disable cups.service
 
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'
rm '/etc/systemd/system/multi-user.target.wants/cups.path'

Quién quiera saber algo más de las novedades y mejoras que aporta systemd, puede empezar por esta serie de cuatro artículos que Diego Calleja ha escrito durante el último año:

1. systemd, otro reemplazo de init
2. Novedades en systemd
3. Novedades en systemd, II
4. Novedades en systemd, III

Y quien quiera experimentar con más opciones de systemctl, ya sabe: man systemctl

Fedora 15 lleva ya unos días disponible para descarga (en su versión oficial con Gnome o en la de cualquiera de sus Spin) y, como siempre, aporta muchas y arriesgadas novedades.

Si ya trabajas con Fedora y quieres actualizar a la nueva versión tal vez la forma más sencilla sea usar preupgrade, un asistente gráfico que te permitirá saltar a las nuevas versiones disponibles tanto estables como beta o alpha, si las hubiera en este momento. El asistente se instala simplemente con ejecutar yum install preupgrade (o instalar el programa preupgrade desde tu gestor de paquetes favorito), ejecutar el comando preupgrade con privilegios de root desde la línea de comandos o cualquier lanzador, y seguir las sencillas instrucciones.

Y, para los que quieren ir un paso por delante, ya hay Roadmap para Fedora 16.

OpenVAS es un scanner de vulnerabilidades de red de código abierto creado a partir de un fork de la versión 2 de Nessus que se convirtió en código propietario en su versión 3, allá por el año 2005. Si queremos instalar la última versión de OpenVAS, la 4, disponible en fase beta desde diciembre de 2010, tenemos que hacerlo manualmente. Existen indicaciones de como hacerlo para diferentes distribuciones en esta dirección pero, a mi parecer, son difíciles de seguir para quién no está bien familiarizado con la arquitectura que usa esta herramienta, he detectado algunos errores y no explican, por ejemplo, algo tan básico como la forma de realizar una instalación distribuida cliente-servidor que es uno de los puntos fuertes de la herramienta. Así que vamos allá.

ACTUALIZACIÓN: Desde el día 17 de marzo la versión 4 es ya definitiva (ya es casualidad que lo tuviera escrito desde una semana antes y que no mirara la lista de correo hasta días después ¿eh?). El procedimiento de instalación aquí descrito sigue siendo válido y si lo has seguido usando los repositorios se te habrán actualizado los últimos cambios de forma automática.

Para disponer de los paquetes necesarios podemos hacer dos cosas, descargarlos manualmente (de esta dirección si usas arquitectura de 64 bits o de esta otra si usas arquitectura i386) e instalarlos con rpm (o yum con la opción --localinstall) o, mucho más recomendable, añadir un nuevo repositorio a tu máquina para recibir las futuras actualizaciones. En este segundo caso debes de crear un nuevo archivo .repo (por ejemplo openvas.repo) en tu directorio /etc/yum.repos.d y copiar en él lo siguiente (o bajártelo diréctamente desde aquí):

1
2
3
4
5
6
7

[security_OpenVAS_STABLE_v4]
name=security:OpenVAS:STABLE:v4 (Fedora_14)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/repodata/repomd.xml.key
enabled=1

Lo siguiente que tenemos que hacer es decidir que instalar. Cómo decíamos antes, OpenVas tiene una estructura cliente servidor de forma que la parte del programa que realiza el escaneo propiamente dicho puede instalarse en una máquina diferente a aquella desde la que se lanza y monitoriza el análisis o, incluso, distribuirlo entre varias para aliviar la carga. Tenemos, así, la posibilidad de instalar servidores en diferentes puntos estratégicos de nuestra red y usar siempre el cliente desde nuestro ordenador de trabajo. Existe una detallada descripción de la arquitectura que se usa en esta dirección pero si no te interesa meterte en tantos detalles, échale al menos un vistazo a esta imagen para comprender lo que sigue:

El servidor de OpenVAS está formado por tres módulos (scanner, manager y administrator) y disponemos de tres posibles clientes para explotarlos: uno en línea de comando (openvas CLI), otro con una aplicación clásica de escritorio que usa las librerías qt4 (greenbone security desktop o gsd) y una tercera posibilidad que es acceder directamente a través de un navegador usando, para ello, el módulo denominado greenbone security assistant.

Y vamos a instalar. Si queremos hacer una instalación completa (cliente y servidor) en la misma máquina y estamos usando el repositorio que hemos puesto anteriormente, tenemos que instalar (recordad, como usuario root) los siguientes paquetes:

1

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant gsd openvas-cli

Si lo que queremos es hacer una instalación sólo con la parte de servidor y, además, tener la posibilidad de conectarnos usando un navegador como cliente, instalaríamos lo siguiente:

1

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant

Si queremos instalar sólo el cliente en línea de comandos:

1

sudo yum install libopenvas4 openvas-cli

Y, por último, si sólo quisieramos instalar la aplicación cliente de escritorio:

1

sudo yum install libopenvas4 gsd

Instalación completada. Ahora hay que poner esto en marcha. Si hemos realizado una instalación distribuida (servidor en una máquina y cliente en otra) lo primero que tenemos que hacer es unos cambios en la configuración del servidor ya que este, por defecto, arranca los servicios usado el parámetro --listen=127.0.0.1 de forma que no admite conexiones que no vengan de la propia máquina. Para corregir esto procedemos de la siguiente forma:

Si lo que queremos es poder conectarnos al servidor a través de un navegador web desde otra máquina, debemos de editar el fichero /etc/sysconfig/greenbone-security-assistant y localizar las siguientes líneas:

1
2
3
4
5

GSA_ADDRESS=127.0.0.1
...
ADMINISTRATOR_ADDRESS=127.0.0.1
...
MANAGER_ADDRESS=127.0.0.1

En el fichero original no aparecen todas así una debajo de otra ¿eh? Bien, pues lo único que tenemos que hacer es sustituir el 127.0.0.1 por la ip real de la máquina que actúa como servidor.

Si lo que queremos es usar el cliente de escritorio gsd desde otra máquina, el fichero que debemos de editar es /etc/sysconfig/openvas-manager. Localizamos ahora la siguiente línea y hacemos la misma operación que hemos descrito antes:

1

MANAGER_ADDRESS=127.0.0.1

¿Continuamos? Lo siguiente (aún en el servidor) sería añadir un primer usuario con privilegio de administrador (cualquiera de los clientes nos pedirá autenticación antes de darnos acceso). El siguiente comando nos creará un usuario llamado josemaria y nos pedirá de forma interactiva la contraseña para este:

1

sudo openvasad -c add_user -n josemaria -r Admin

A continuación generamos los certificados que también usaremos en la autenticación:

1

sudo openvas-mkcert -q<br/>sudo openvas-mkcert-client -n om -i

Y ya casi estamos. Para quién no lo conozca, un programa como este que analiza vulnerabilidades se parece en algunos aspectos a un antivirus: alguien tiene que actualizar de forma permanente que nuevas vulnerabilidades existen y de que forma reconocerlas. Al igual que actualizamos las “firmas” de nuestro antivirus necesitamos actualizar estos patrones de reconocimiento que en OpenVAS reciben el nombre de NVT’s Es por lo tanto necesaria una sincronización periódica. El siguiente script podría servirnos para ello. Además de la sincronización realiza la activación de servicios en el orden correcto de forma que deberíamos de usarlo antes de la primera conexión y después de cada reinicio de la máquina con el servidor:

1
2
3
4
5
6
7
8
9
10
11
12

sudo openvas-nvt-sync
sudo service openvas-manager stop
sudo service openvas-scanner stop
sudo openvassd
sudo openvasmd --migrate
sudo openvasmd --rebuild
sudo service openvas-administrator stop
sudo service openvas-manager stop
sudo service openvas-scanner restart
sudo service openvas-manager start
sudo service openvas-administrator start
sudo /etc/init.d/greenbone-security-assistant restart

Y con esto está todo. Si queremos asegurarnos o posteriormente cuando lancemos un cliente tenemos algún problema, existe un pequeño script que podemos descargar desde aquí y que, ejecutado con privilegios de root, nos permite verificar si nuestra instalación está correcta o, por el contrario, nos alertaría acerca de que es lo que nos falta. Si lo ejecutamos con el parámetro --server obviaría en esta comprobación todo lo referente a la instalación del cliente.

Ahora ya podemos empezar a auditar la red. El cliente de escritorio no crea entrada en ningún menú, así que lo tenemos que ejecutar a mano (pulsando Alt+F2 o directamente desde un terminal) con el comando gsd. En las siguientes ilustraciones se ve la pantalla de conexión y la principal del programa

Si preferimos usar el cliente web (mucho más ligero, la verdad) “apuntamos” con nuestro navegador al puerto 9392 de la máquina donde hemos instalado el servidor usando protocolo seguro https (por ejemplo https://192.168.1.217:9392 o https://localhost:9392 en caso de que lo tengamos todo en la misma máquina). A continuación tienes también los pantallazos de la ventana de login y la principal del cliente:

ACTUALIZACIÓN: En systenadmin nos cuentan como instalarlo en una Cent.OS además de algunas notas útiles sobre el escalado de eventos y la sobreescritura de alertas para evitar falsos positivos recurrentes.

ACTUALIZACIÓN (y II): y si prefieres instalarlo en Ubuntu échale un vistazo a estas notas adicionales.

Los daemons (o servicios según la terminología más popular acuñada por los entornos windows) son aquellos programas que se ejecutan en nuestro ordenador en segundo plano y, habitualmente, desde el arranque del mismo, permaneciendo a la espera de prestar algún servicio. Normalmente nos incomoda tener que ejecutarlos manualmente cuando no están activos, pero una mala elección de los servicios que se ejecutan en el arranque de la máquina ocasiona que nuestro ordenador consuma unos recursos que no precisa o que tenga un arranque más lento de lo que nos gusta.

Hoy vamos a ver la forma de gestionar los daemons en Fedora y, sin que sirva de precedente, vamos a empezar por los métodos gráficos para que los más comodones no tengan que leer el texto hasta el final. En el menú de administración tenemos un programita denominado Administración de Servicios (ejecutable también con la orden system-config-services).

La pantalla es bastante intuitiva. Los dos iconos delante del nombre de cada servicio nos indican si está habilitado su arranque de forma automático al inicio y si está ejecutándose en estos momentos. Podemos manipular estos parámetros con los botones Enable/Disable y Start/Stop respectivamente. Mediante el botón Customize podemos ajustar los niveles de ejecución (o runlevels) particulares para los que queremos que el servicio se inicie. En la mayoría de los casos nos basta saber que el terminal gráfico con el que trabajamos habitualmente se corresponde con el nivel 5 y el modo de texto multiusuario con soporte de red corresponde con el nivel 3 (el nivel 5 se define en realidad como el nivel 3 con las X).

ntsysv es una pequeña aplicación que nos permite hacer lo mismo desde la línea de comandos pero con la comodidad de usar un rudimentario interfaz gráfico construido con las ncurses.

Se ejecuta con privilegios de root y por defecto nos muestra y permite modificar los servicios que se inician en el arranque del nivel de ejecución en el que nos encontramos cuando usamos la herramienta. Si quisiéramos consultar o modificar el inicio en otro runlevel lo indicaremos con el parámetro --level (ntsysv --level 5, por ejemplo). Los servicios se marcan y desmarcan usando la barra de espacios. Si seleccionamos un servicio este se iniciará inmediatamente y, además, lo hará a partir de este momento en cada arranque. Si lo deseleccionamos y estaba activo se parará también de forma instantánea.

chkconfig es, tal vez, la herramienta más versátil para esta tarea. Además de darnos información y permitirnos modificar el arranque y parada de los servicios en sus diferentes runlevels, nos permite añadir o eliminar servicios. Algunas ejemplos útiles son los siguientes:

• chkconfig --list nos muestra una matriz de servicios y de runlevels indicando en el inicio de cuales de los niveles de ejecución se ejecuta cada uno.
• chkconfig --level 35 sshd on habilita la ejecución del daemon del servidor ssh al inicio de los runlevels 3 y 5.
• chkconfig wine on habilita la ejecución del servicio de wine al inicio de los runlevels 2, 3 4 y 5.
• chkconfig --level 3 vmware off deshabilita la ejecución del servicio vmware al inicio del nivel de ejecución 3.

Mediante los parámetros --add y --del podemos incluir nuevos servicios o eliminar los existentes, pero piensa al añadir uno nuevo que no puedes hacerlo con cualquier programa. Si este no cumple con los requisitos indispensables chkconfig te devolverá un error.

El comando service es el último que vamos a ver. Este nos permite detener o iniciar cualquiera de los servicios y, en algunos casos, reiniciarlos o ver su estado. Cualquiera de nuestros servicios debería de responder correctamente, al menos, a los siguientes comandos:

• service crond start
• service mysqld stop

Habitualmente pueden responder, además, a alguna de las órdenes siguientes:

• service NetworkManager status
• service ntop restart
• service apache2 reload

NOTA: Los usuarios de Ubuntu tienen disponible chkconfig (aunque no viene instalado por defecto con la distribución) y service.

Skype sólo ofrece binarios compilados a 64 bits para Ubuntu. Y, por supuesto, no hay fuentes disponibles para que lo compiles por ti mismo… Si quieres usar este programa con otras distribuciones pero en este formato tendrás que usar algún truco.

En Fedora 14, hay que empezar por instalar el programa a partir de los binarios de 32 bits, bien descargándotelos desde su web o bien a partir de un nuevo repositorio que podemos definir con el siguiente contenido:

[skype]
name=Skype Repository
baseurl=http://download.skype.com/linux/repos/fedora/updates/i586/
enabled=1
gpgkey=http://www.skype.com/products/skype/linux/rpm-public-key.asc
gpgcheck=0

Una vez instalado, tendrás que añadir las dependencias que skype precisa pero especificando que la arquitectura que usaremos será la de 32 bits y no la de 64 que nuestra distribución usa como base:

sudo yum install libXScrnSaver.i686 qt-x11.i686

Si el soporte para webcam te da problemas (a mi me ocurre en el sobremesa con mi logitech, pero no en el portatil con su webcam integrada) esta solución sigue siendo válida.

Para quien sienta curiosidad por probar desde Fedora la futura versión 2.8 de GIMP (nombrada como versión 2.7 mientras se encuentra en desarrollo) y no quiera pelearse con los fuentes, existen repositorios no oficiales para Fedora 14 tanto para arquitecturas i386 como de 64 bits Basta con que te bajes los paquetes gimp y gimp-libs para tu arquitectura y los instales normalmente con rpm, yum, PackageKit o con tu gestor favorito acostumbrado.

La nueva versión arranca por defecto con el interfaz tradicional de ventanas flotantes. Si quieres cambiar al modelo de ventana única con solapas que tanto está dando que hablar (tal y como se ve aquí abajo), entra en la opción Window del menú principal y marca la opción etiquetada como Single-Window Mode.

Tras el lanzamiento de Fedora 14 he decidido volver a trabajar con una distribución compilada para procesadores de 64 bits. Hace un par de años lo desestimé porque los binarios de este tipo eran aún infrecuentes y había que pasarse media vida compilando. Y, por supuesto, olvidarse de las aplicaciones sin código disponible. En estas dos semanas me ha quedado claro que el panorama ha cambiado radicalmente y hoy el único ejecutable que aún no tengo disponible es el de Skype. Y apenas he tenido que tocar el gcc.

Uno de los binarios indispensables y que no se ofrece en los repositorios oficiales es el plugin de flash. Para instalarlo en Fedora (de forma nativa y sin usar el nspluginwrapper) tenemos dos alternativas:

1. Descargar la versión beta del plugin directamente de Adobe. Sólo tenemos que descomprimirlo y copiar la librería al directorio /usr/lib64/mozilla/plugins/. El problema de este método es que quedamos fuera de cualquier programa de actualizaciones y tendremos que estar pendiente de hacer estas por nosotros mismos.

2. Y mucho más recomendable: usar el repositorio que un miembro de la comunidad de Fedora mantiene. Para ello basta con crear un archivo llamado, por ejemplo, flash.repo dentro del directorio /etc/yum.repos.d y copiar en él lo siguiente:

[flash]
name=flash
baseurl=http://dl.dropbox.com/u/6907158
/flashplayer.x86_64enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-leigh123linux

A continuación instalamos el paquete como hacíamos habitualmente hasta ahora (yum install flash-plugin) y listo.

NOTA: Si, como yo, alternas entre firefox y minefield, tendrás que hacer un enlace al directorio de plugins (/usr/lib64/mozilla/plugins) dentro del árbol de directorio donde hayas desempaquetado minefield para que el plugin esté disponible para este.

En las páginas de kde.org no hay aún ningún anuncio oficial, pero después de la actualización de ayer domingo la versión de kde aparece ya como 4.4.00 y no como 4.3.9x, así que imagino que se acabaron las “release candidates” y ya tenemos una versión final.

El que quiera probarla desde Fedora y aún no se haya atrevido, puede echarle un vistazo a esto.

ACTUALIZACIÓN: kde.org ya ha hecho el anuncio con un resumen de las novedades de esta versión.

La Release Candidate 1 de KDE 4.4 está disponible para Fedora 12 desde casi el mismo momento de su anuncio oficial a través de los repositorios del KDE-RedHat Packaging Project o los oficiales de Rawhide. En ambos aparecen etiquetados como versión 4.3.90. Os cuento en unas líneas como podéis ir probándolos a partir del primero de estos:

• Lo primero, descargar el fichero kde.repo donde se encuentra la definición de los repositorios y copiarlo en el directorio /etc/yum.repos.d/
• En segundo lugar editar dicho fichero y habilitar los repositorios de testing y unstable que vienen desactivados por defecto. Para ambos la última línea debe de quedar así:
  enabled=1
• En tercer y último lugar actualizamos nuestro sistema con los nuevos repositorios indicando a yum que ignore los paquetes con problemas de resolución de dependencias y que excluya k3b de la actualización. Algo así:
  yum update --skip-broken --exclude=k3b*

Listo. Disfrutadlo. Ah, y feliz año

ACTUALIZACIÓN: Echadle un vistacillo a la nueva funcionalidad que permite agrupar mediante pestañas cualquier tipo de aplicaciones.

ACTUALIZACIÓN (y II): Ya tenemos la versión final y no hay dependencias incumplidas de ningún tipo, así que podéis prescindir de los parámetros --skip-broken --exclude=k3b* al hacer el update.