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.

El siguiente documento es una recopilación en un archivo único de los apuntes que di a lo largo de todo el curso pasado a mis alumnos del módulo de Redes de Área Local (Ciclo Formativo de Sistemas Microinformáticos y Redes) sobre configuración y administración de routers y switches de CISCO usando el Command Line Interface o CLI. Abarca desde una configuración básica de los mismos hasta configuración de protocolos de rutado dinámico, creación de VLANs y algunas nociones muy básicas de seguridad. Ahí queda por si a alguien le viene bien:

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

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.

Existen muchas ocasiones en las que nos interesa obtener un volcado de la pantalla de nuestros Linux desde la línea de comandos y si has llegado hasta aquí haciendo una búsqueda es que tienes alguna de ellas en la cabeza. La mejor forma de hacerlo es usar el comando xwd:

xwd -root | convert xwd:- pantallazo.png

Si quisiéramos realizar un volcado automático a intervalos regulares podríamos, de forma burda, (nunca he sido muy elegante haciendo scripts, para que engañarnos) hacer algo como esto:

#!/bin/sh
number=$(ls pantallazo* | wc -l)
file=pantallazo_$number.png
xwd -root | convert xwd:- $file

Y ya está. Ahora sólo tendríamos que programar la ejecución de este scritpt mediante cron con la regularidad que deseemos.

NOTA: La salida de xwd la convertimos a formato png mediante el comando convert perteneciente a las librerías de ImageMagick que, por tanto, deberían de estar instaladas en nuestro sistema.

Mi servicio de hosting me proporciona casi 1000 Gbytes de espacio en disco (750 de base más algunos extras por referencias) de los que estoy usando unos 800 Mbytes y cerca de 120 GBytes de transferencia diaria de la que apenas aprovecho un par ¿Por qué no usar estos recursos extra para hacer backups incrementales de mis datos locales? Yo uso para este fin un sencillo script que usa rdiff-backup el cual me permite conexión con una máquina remota a través de ssh, pero no de ftp. Y mi hosting no me da conexión por ssh. Una solución sencilla a esto podría ser montar mi servidor ftp sobre un directorio local usando FUSE y, a partir de ahí, usar mi script de la forma habitual.

Para seguir esta chuletilla necesitas tener instalado curlftpfs, una utilidad que permite el uso de curl sobre FUSE disponible entre los paquetes estables tanto de Fedora como de Ubuntu y de Debian. Una vez instalado, sólo debes de ejecutar lo siguiente con privilegios de root:

# curlftpfs -o allow_other ftp://user:pass@ftp.server.com /mnt/ftp

Donde user y pass son los datos de tu cuenta de ftp, ftp.server.com el nombre de tu servidor ftp y /mnt/ftp el directorio local donde quieres montarlo. Fácil ¿verdad? Bueno, vamos a mejorarlo un poco…

Si queremos que el montaje se realice de forma más cómoda, sólo tenemos que incluir esta línea en nuestro fichero /etc/fstab:

curlftpfs#user:pass@ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

El directorio no se montará de forma automática en el arranque del sistema como el resto de las unidades (gracias al parámetro noauto) pero a partir de ahora montarlo y desmontarlo será tan fácil como ejecutar mount /mnt/ftp o umount /mnt/ftp respectivamente.

Por último, si nos preocupa que el usuario y la contraseña de nuestra cuenta de ftp sea visible dentro de un archivo legible por todos los usuarios del sistema (o, también, visualizando la lista de procesos en ejecución) podemos guardar estos datos en un fichero llamado .netrc dentro del directorio del usuario root. El formato del fichero sería este:

machine ftp.server.com
login user
password pass

Y ahora la línea en nuestro fichero fstab quedaría así

curlftpfs#ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

Dos apuntes finales. Recuerda que tus datos viajarán en claro a través de la red, así que si guardas información especialmente sensible procura cifrarla antes y trata de usar en todo momento la línea de comandos para acceder a esta nueva unidad. La utilidades gráficas no son eficientes para este tipo de accesos.

El problema de las dependencias circulares en las distribuciones basadas en rpm es un verdadero coñazo que, por desgracia, se presenta bastante a menudo. Ocurre cuando la desinstalación de la versión antigua de una librería no es posible y bloquea la instalación de una nueva versión y, por tanto, la instalación de los paquetes que la requieren como imprescindible. El último caso que se me ha presentado, y que me ha hecho recordar esto, ha sido con las pruebas de la versión alpha de fedora 11 y concretamente con las liberías glibc. La versión glibc-common-2.9.90-2.i386 me bloqueaba la instalación de glibc-common-2.9.90-8.1.i586 y no me dejaba instalar el compilador gcc que dependía de esta última.

La solución es tan sencilla como instalar el paquete manualmente usando la opción --nodeps. Los paquetes rpm de Fedora están disponibles para su descarga directa y ordenados según la versión de la distribución en estas páginas. En el caso que os cuento, las glibc-common-2.9.90-8.1.i586 están aquí. Una vez descargadas se instalan así:

[root@localhost downloads]# rpm -Uhv glibc-common-2.9.90-8.1.i586 --nodeps

Y listo. Ya puedo seguir con la instalación del gcc para, luego, volver a tener disponible VirtualBox. Pero esto es ya una historia que merece ser contada en otra ocasión

Imagino que a estas alturas ya lo sabe todo el mundo pero, por si acaso, insisto: Todos los certificados y parejas de claves generados durante los dos últimos años desde una distribución Debian o derivada (Ubuntu, Xandros, Mepis, Mint, etc.) y que se usen para cifrar una comunicación segura por https, para dar acceso a un servidor por ssh, etc., han de ser revocadas y vueltas a crear desde una distribución actualizada lo antes posible. Quién quiera algo más de información de lo que ha pasado con esto y de las posibles consecuencias puede leerse este post de Hispasec o, en inglés, este otro de Metasploit.

Generar una pareja de claves nueva para acceder por ssh a un servidor es tan fácil como esto:

josemaria@penique:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/josemaria/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/josemaria
.ssh/id_rsa.
Your public key has been saved in /home/josemaria/.ssh/id_rsa.pub.
The key fingerprint is:
8a:75:13:c9:95:f6:c0:89:e0:4c:97:5e:7a:13:f7:63

La clave pública se guarda en el fichero id_rsa.pub dentro de un directorio oculto llamado .ssh que se encuentra en nuestro $HOME. La clave privada, que no debe de salir de ahí salvo para hacer copias de seguridad, se encuentra en ese mismo directorio.

El comando para cambiar la contraseña de una pareja de claves es este (pero, ojo, esto no sustituye la clave débil por otra y, por tanto, no corrige este problema):

josemaria@penique:~$ ssh-keygen -p

ACTUALIZACIÓN: Mercè Molist publica hoy a través de su blog una nota informativa sobre este error y una entrevista con Jordi Mallach, desarrollador de Debian.

Abrimos la sección técnica post-veraniega con un problemilla y su solución. Estoy estrenando portatil en mi nuevo trabajo (¿qué no sabíais que me cambiaba de trabajo? Bueno, ya os contaré más cosas en unos días) y mi Linux no es capaz de manejar correctamente la conexión inalámbrica. Reconoce el dispositivo como Broadcom Corporation Dell Wireless 1390 pero no es capaz siquiera de mostrarme las redes disponibles. El portatil en cuestión es un HP Compaq nx7300, un modelo baratito pero bastante resultón y con una buena relación calidad/precio.

Bien, lo primero que vamos a hacer, más por culturilla que por otra cosa, es aprender algunos comandos que nos resultaran útiles para recoger información de lo que está pasando:

josemaria@penique:/etc/modprobe.d$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 IEEE 802.11b/g ESSID:"" Nickname:"Broadcom 4311"
Mode:Managed Access Point: Invalid
RTS thr:off Fragment thr:off
Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

vmnet8 no wireless extensions.

vmnet1 no wireless extensions.
josemaria@penique:/etc/modprobe.d$ lspci -nn | grep Broadcom
02:0e.0 Ethernet controller [0200]: Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c] (rev 02)
10:00.0 Network controller [0280]: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card [14e4:4311] (rev 01)

Gracias a Google nos enteramos, además de que mucha gente tiene problemas con este dispositivo, que el módulo que carga el kernel de Linux para su gestión se llama bcm43xx. En la web de berlios nos dicen además que el driver se ha desarrollado mediante ingeniería inversa porque Broadcom no da detalle alguno de sus chips (ya sabeis chicos: si la decisión de compra es vuestra y teneis alternativas nada de comprar productos de Broadcom). Vamos a comprobar que, efectivamente, estemos cargando ese módulo:

josemaria@penique:/etc/modprobe.d$ lsmod | grep bcm43xx
bcm43xx 126824 0
ieee80211softmac 31360 1 bcm43xx
ieee80211 34760 2 bcm43xx,ieee80211softmac

Vamos bien. Ahora descargamos el módulo y comprobamos que ya no está en uso:

josemaria@penique:/etc/modprobe.d$ sudo modprobe -r bcm43xx
Password:
josemaria@penique:/etc/modprobe.d$ lsmod | grep bcm43xx
josemaria@penique:/etc/modprobe.d$

Para evitar que este módulo se carge en sucesivos arranques de nuestro sistema tenemos que ir al directorio /etc/modprobe.d y allí editar el fichero blacklist y añadir al final esta línea:

# deshabilita la carga de bcm43xx
blacklist bcm43xx

Ahora necesitamos los drivers para windows del dispositivo. Para esto no debería de haber ningún problema: yo me los he bajado de la web de soporte de hp. Lo único que debemos de tener en cuenta es que deben de estar descomprimidos. Si los tenemos en un .zip, o un .exe debemos de extraerlos antes y guardarlos así en un directorio de nuestra máquina. A continuación instalamos ndiswrapper y, si estamos aburridos por hoy de la línea de comandos, ndisgtk (una interfaz gráfica para este).

Ejecutamos ndisgtk (en los menús suele situarse como “Windows Wireless Driver”), pulsamos el botón de “Install new driver” y navegamos hasta el directorio dónde hemos dejado los drivers windows del dispositivo. Debemos de seleccionar el archivo .inf que acompaña a los mismos (en mi caso bcmwl5.inf).

Como veis aparece que el hardware no está presente… no tengo ni idea de porqué pero el caso es que funciona. Si queremos hacerlo desde la línea de comandos:

josemaria@penique:/opt/driverswifi.d$ sudo ndiswrapper -i bcmwl5.inf
installing bcmwl5 ...
josemaria@penique:/opt/driverswifi.d$ ndiswrapper -l
bcmwl5 : driver installed
device (14E4:4311) present (alternate driver: bcm43xx)
josemaria@penique:/opt/driverswifi.d$ sudo ndiswrapper -m
adding "alias wlan0 ndiswrapper" to /etc/modprobe.d/ndiswrapper ...

Y ya. No olvidemos activar el wifi desde el portatil (si posee algún botón o interruptor para ello como es el caso de este modelo) y, si usamos kde y knetworkmanager, veremos que ya nos está localizando las redes próximas y que podemos conectarnos a ellas.

Sin lugar a dudas se trata del tema para wordpress más friky que he visto jamás. Si no fuese porque seguro que mi madre no sabría que hacer con el lo instalaría de inmediato… (Qué excusa más tonta… Mi madre no sabe siquiera que esto existe). Disponible en dos versiones: la 1 en el tradicional fósforo verde de toda la vida y la 2 (aún en beta) en un lila bastante menos agresivo para la vista (“clickear” sobre las imágenes para acceder a ellos).

Visto en TuxHuellas.