urpmscan y urpmseek: Emulando apt-cache search

No se trata de comandos oficiales, más bien se trata de dos artificios para para realizar búsquedas de paquetes con un comportamiento similar al de apt-cache search de las distribuciones estilo Debian.

urpmscan devuelve una lista sencilla de acuerdo a una cadena de texto contenida en la descripción del paquete.

Para valerse de urpmscan, crear un archivo llamado urpmscan con el siguiente contenido y moverlo a /usr/bin

#! /bin/bash
urpmf -i  --uniq --description "$1"| grep  '^[[:alnum:]].*:$'|sed s/\:// |sort

Luego asignarle permisos de ejecución con:

chmod 755 /usr/bin/urpmscan

Y luego para buscar paquetes relacionados con streaming:

urpmscan streaming

urpmseek busca en el resumen de cada paquete y devuelve el listado con el nombre de los paquetes y su correspondiente sumario.

Si ademas, lo que se desea es en cambio buscar en el resumen del paquete se puede crear un alias llamado urpmseek:

echo alias urpmseek\=\"urpmf -i --summary\" >> /etc/bashrc

Para ponerlo en práctica inmediatamente se debe hacer:

bash

Y luego siguiendo el ejemplo anterior con urpmscan:

urpmseek streaming

Es decir, en Debian, Ubuntu, etc. podemos hacer:

• apt-cache search compiz

o bien

• aptitude search compiz

En Fedora, Red Hat, CentOS, etc, tenemos una opción similar:

• yum search compiz

¿Y en Mandriva?

Hay una manera de hacer algo parecido, aunque está un poco escondida:

• urpmf -i –description compiz

Tal es así que en mi escritorio personal me mudé durante algunos meses a Ubuntu.

Sin embargo, en el escritorio del trabajo seguía usando Mandriva, aunque con bastantes contratiempos debidos al el pobre desempeño en la gestión de paquetes que padecía luego de instalar la 2009.0. Decidí actualizar hace unas semanas directamente por urpmi de 2009 a 2009 Spring, más que nada para probar y luego sí, hacer una instalación limpia. Y el resultado fue ciertamente sorprendente, la actualización pasó prácticamente desapercibida.

Es importante remarcar que la actualización se hizo mientras estaba trabajando, el resultado fue gratamente sorprendente.

Entonces decidí volver en mi escritorio personal a Mandriva. Estaba vez instalando a partir de la versión de One. El resultado fue similar aunque noté un único bug importante que arrastra de versiones anteriores, si se utiliza un directorio personal ya existente,  con muchos archivos con el UID 500, el primer inicio de sesión se demora muchísimo. Esto es porque el sistema busca reemplazar todas las apariciones en los archivos de configuración /home/guest para reemplazarlos por el /home/nombre_de_usuario.

En link citado aquí, hay un workaround, pero ciertamente debería buscarse una solución mucho más elegante y práctica, o al menos avisar al usuario del proceso que se está realizando.

Más allá de eso, debe decirse que Mandriva 2009 Spring parece ser una edición depurada con mucho más minuciosidad y prolijidad que las anteriores, especialmente de la fallida 2009.

Todas las distribuciones tienen fortalezas y debilidades. Si hay algo que me gusta de Mandriva para usarlo como escritorio es la cohesión del entorno y de las herramientas, lo cual hace que sea para mí la distro a elegir cuando la cantidad de bugs y/o desprolijidades no alcanza niveles que amenazan aquellas virtudes.

Una mención especial merece la versión de KDE 4 que parece resolver muchos de los inconvenientes de las ediciones pasadas.

Otra cosa que me gustó fue nuevo diseño artístico de la edición Free, mucho más profesional comparándolas con versiones anteriores.

Hay una detalle tal vez no muy conocido y que no está en los repositorios, me refiero al mandriva-seed.sh. Se trata de un script que se vale de makeself y dd principalmente para volcar un archivo iso a un pendrive

La 2009.1 Spring es una versión ciertamente recomendable para usarla como sistema de escritorio. Es la mejor versión de Mandriva, desde que así se llama la distribución.

Mandriva 2009 Spring

GNOME en Ubuntu 8.10

Durante años fui usuario de KDE (desde la versión 1.x, por lo menos). La versión 3.5.9 fue tal vez el mejor escritorio libre del momento. Luego vino la promesa de KDE 4. Muchos teníamos grandes expectativas en él.

Es de esperar en un cambio en el número de versión significativo, también una serie de modificaciones importantes. Lamentablemente la manera en que se produjo no fue de las mejores.

Las primeras versiones de KDE 4 carecían de importantes problemas de usabilidad. El cambio de paradigmas basado en plasmoides es interesantes, pero supone para el usuario final un escollo difícil superar. Y creo que también lo es para quienes durante mucho tiempo usamos un ya confiable KDE 3.

Lamentablemente Konqui, el dragoncito amigable se tornó en una criatura apática, que al menos por el momento no repara en lanzar bocanadas de fuego hacia los nuevos usuarios que acercan a Linux.

El bache de Vista introducido por Microsoft supuso una oportunidad muy importante para Linux. Pero KDE de manera llamativa la desaprovechó produciendo cambios a primera vista que recuerdan demasiado el obtuso sistema operativo de Microsoft que hoy la empresa de Redmond parece querer borrar de un plumazo.

La documentación de KDE 4 es muy pobre, obsoleta o cuasi inexistente.

Por otro lado el otro entorno principal open source, GNOME, que nunca me terminaba de convencer, terminó por hacerme sentir como en casa. Mucho más cercano al paradigma de escritorio de Mac OS, que muchos usuarios de escritorio no conocen por el monopolio de hecho de Microsoft, proporciona una alternativa amigable, sanamente minimalista y previsible.

Es cierto, Nautilus carece de la tan útil prestación para dividir ventanas, Kate es mejor editor que Gedit, Digikam me gusta más que F-Spot y estoy más acostumbrado a Kontact que Evolution. Pero globabalmente hoy por hoy GNOME es globalmente, un entorno de escritorio más confiable que KDE. Si es cierto, aun no he probado KDE 4.2, después de hacerlo, tal vez tenga que cambiar de opinión.

De todas maneras, no soy el único que opina de este modo, el propio Linus Torvalds que alguna vez desfenestró a GNOME, es usuario de dicho entorno.

El problema que había hasa hace poco con esta placa era que para funcionar necesitaba o bien un driver libre más firmware no libre, o la utilización de un controlador de windows no libre con ndiswrapper.

Eso hacía algo irritante las instalaciones, ya que lo más habitual era tener que contectarlo a una red cableada y desde ahí bajarse, por ejemplo el firmware. Es cierto, uno podía recurrir a ciertas artimañas, tales como tener el firmware en un pendrive previo a la instalación y luego copiarlo. Aun así, no era lo más cómodo. Recientemente Broadcom sacó un nuevo driver que incluye el dichoso firmware. Mandriva agregó en sus repositorios un paquete llamado dkms-broadcom-wl.

Nuevo driver de Broadcom funcionando, con el hermoso JuanSe de fondo

Mientras tanto, Ubuntu Intrepid Ibex ya viene con el driver wl.ko.
La mala noticia: No funciona en primera instancia, ya que pretende usar los drivers  b43 y ssb.

La buena noticia: Esto se puede revertir sin necesidad de bajar ni copiar absolutamente nada. Solamente hay que tocar algunas cosillas del sistema, como muestro a continuación:

1. Agregar en /etc/modprobe.d/blacklist:
   blacklist ssb
   blacklist b43
2. Modificar /etc/rc.local para que quede así:

   # Make sure that the script will "exit 0" on success or any other

   # value on error.

   #

   # In order to enable or disable this script just change the execution

   # bits.

   #

   # By default this script does nothing.

   modprobe -r ssb

   modprobe -r wl

   modprobe wl

   exit 0

Se debe reiniciar el sistema y listo.

Centro de Control de Mandriva

Lamentablemente tiene las históricas desprolijidades de Mandrake/Mandriva, por ejemplo, algunos mirrors que no funcionan, las vueltas que hay que hacer para reproducir una película de un DVD usando compiz. No es que sea difícil, pero es molesto. Algo que no se entiende es: ¿Por qué no se activan por defecto las configuraciones que funcionan seguro con compiz? ¿Por qué esperar a que el usuario tenga que hacerlo? Otra cosa increíble es que se incluyan herramientas propias de la distribución que no funcionan correctamente. ¿No era mejor excluirla o ponerla en los repositorios de testing? Otra cosa irritante es padecer las falencias de una placa wireless Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01). Y la herramienta de Mandriva para configuración de redes que hace fácil lo difícil, pero también complica lo sencillo, ¿por qué a veces es más complicado conectarse a una red inalámbrica abierta?

Y lo peor, puede ser que la distribución no sea la causante, pero ¿porqué luego de instalar Mandriva la unidad de DVD olvide su configuración de la región?

Bueno, aun así el saldo es positivo, por ahora me gusta esta nueva versión. La recomiendo. Los que no saben nada de Linux que quieran usarla como con cualquier otra distribución, les sugiero que busquen algo que tenga el tiempo y la paciencia para ayudarlos. De hecho lo mismo pasa con Windows: los usuarios no técnicos casi siempre tienen alguien cerca que los asiste.

Invito a votar por la solución de los bugs de Mandriva tales como el 44186.

Ah, además ya tengo la primer certificación LPI, en otro orden de cosas…

El archivo  /usr/include/linux/capability.h contiene la descripción definición de las 31 PCaps. Para poder usarlas:

• Verificar que esta soportado por el kernel

• Habilitar KPROBES y compilar si es necesario

• Compilar e instalar las nuevas libreras PCAPS

Se trata de la version 2.x de estas libreras que in

cluyen las herramientas setcap y getcap.

• Compilar e instalar capable_probe

• Cargar el modulo capable_probe

Este módulo es muy importante para comenzar a usar las PCaps e ir aprendiendo como funcionan. De esta manera, podremos ver los mensajes relativas a las PCaps en el archivo /var/log/messages. Hay que tener en cuenta que dicho archivo crecer notablemente, por lo que se recomienda no tener cargado todo el tiempo el módulo capable_probe.

Una de las primeras cosas que se pueden hacer es probar alguna aplicación y ver que capabilities esta usado. Por ejemplo, vemos que el comando at requiere la facultad para realizar diversas tareas administrativas, pasar por el alto el control de acceso discrecional, cambiar propietarios de archivos, manipulación de SUID y SGID bits.

Espero pronto poder escribir algunas cosas ms sobre este apasionante tema.

El tradicional poder de root en Linux se puede prestar, delegar, fragmentar, etc. mediante distintos métodos. El esquema típico de permisos también se puede ampliar…

Prestando el poder: el comando su

El comando su permite que un usuario haga las veces de otro usuario (generalmente root) ingresando la contraseña de este último. Se puede desde correr un único comando hasta correr una sesión completa como root usando todas sus variables de entorno.  Existe un comando similar llamado sg, que sirve para tomar temporalmente las atribuciones de un grupo. Una diferencia importante es que con sg solamente se registran los intentos fallidos. Además, con sg se hace necesario el uso de las casi poco utilizadas contraseñas de grupos.

Jun 28 17:56:11 pulperia sg[7865]:\
Invalid password for group `users' from `sergio'

Delegando el poder: sudo

La página del manual correspondiente a sudo dice que es un programa diseñado para permitir que el administrador conceda privilegios de root limitados a otros usuarios y registrar su actividad. Si bien sudo tiene una buena cantidad de años, casi tres décadas, se hizo popular hace mucho menos tiempo gracias a Ubuntu. Esta distribución usa sudo de manera predeterminada. Cuando se instala la distribución, se crea un usuario que actuará como “power user”: cada vez que se deba realizar una tarea administrativa se deberá ingresar la contraseña de este usuario calificado. El usuario tendrá además un tiempo de gracia para ejecutar comandos administrativos en la misma terminal.

El archivo de configuración es /etc/sudoers, y una línea típica dice algo así:

¿Qué usuario? ¿Dónde? ¿Cómo qué usuarios? ¿Qué comandos?

Además, se pueden definir alias de usuarios, de usuarios ejecutores, de hosts y de comandos.

User_Alias     DBMASTER = sergio

User_Alias      RANGER = sergio

Runas_Alias    DB = mysql,root

root    ALL=(ALL) ALL

DBMASTER pulperia=(DB) /etc/init.d/mysqld,/usr/sbin/mysql*

RANGER pulperia=(ALL) /usr/bin/tail /var/log/messages,/sbin/reboot,\
/sbin/halt,/sbin/poweroff

Repartiendo el poder: ACLs al estilo POSIX

Recordemos que el esquema en Linux tradicional es UGO (user, group, others)

• Cada archivo y cada proceso tiene un único usuario dueño
• Cada archivo y cada proceso tiene un único usuario

Las ACLs al estilo POSIX en Linux se aplican al sistema de archivos y a procesos y permiten extender el enfoque arriba mencionado. De este modo, cada archivo puede contener más de un usuario dueño y/o más de un grupo dueño.

Para sacar provecho de las ACLs es necesario que el sistema de archivos sobre las cuales se quiere aplicar tenga soporte para las mismas.

UUID=831727be-3460-455e-bd1e-200231b2fb84 / \
ext2    relatime,errors=remount-ro,acl,user_xattr 0

Una vez aplicados los cambios, además de los conocidos comandos chmod y chown se pueden usar los comandos setfacl y getfacl.

El comando setfacl permite definir y/o agregar usuarios y permisos.

setfacl -m u:prueba:rw file2

Luego ejecutando ls -l file2 puede informarnos si el archivo tiene acls:

-rw-rwx—+ 1 sergio sergio 0 2008-06-29 18:51 file2

Sin embargo, el comando getfacl es mucho más informativo:

sergio@coldplay:~/testdir$ getfacl file2

# file: file2

# owner: sergio

# group: sergio

user::rw-

user:prueba:rw-

user:burrufini:rwx

group::r-x

group:users:r-x

mask::rwx

other::---

El archivo tiene un dueño (owner) que es sergio, y dos copropietarios (named users) es decir, prueba y burrufini. Asimismo, tiene un grupo dueño que es sergio y un grupo copropietario (named group) que es user. Las máscara (mask) es muy importante ya que pone límite a los permisos de los usuarios copropietarios del grupo propietario y de los grupos copropietarios.

La máscara también se configura con setfacl:

sergio@coldplay:~/testdir$ setfacl -m mask:r-x file2

sergio@coldplay:~/testdir$ getfacl file2

# file: file2

# owner: sergio

# group: sergio

user::rw-

user:prueba:rw-                 #effective:r--

user:burrufini:rwx              #effective:r-x

group::r-x

group:users:r-x

mask::r-x

other::---

Notar lo siguiente:

sergio@coldplay:~/testdir$ chmod g+rw file2

sergio@coldplay:~/testdir$ ls -l file2

-rw-rwx---+ 1 sergio sergio 0 2008-06-29 18:51 file2

sergio@coldplay:~/testdir$ getfacl file2

# file: file2

# owner: sergio

# group: sergio

user::rw-

user:prueba:rw-

user:burrufini:rwx

group::r-x

group:users:r-x

mask::rwx

other::---

Esto quiere decir que al ejecutar chmod para cambiar los permisos del grupo, en realidad se cambiaron los permisos de la máscara. Por lo tanto al usar acls para cambiar o definir los permisos del grupo dueño se debe usar el comando setfacl (setfacl -m group::permisos archivo).

Pero con las acls se puede hacer algo más: se pueden definir que permisos tendrán los archivos creados en un directorio:

sergio@coldplay:~/testdir$ setfacl -m g:users:rw- pepe

# file: pepe

# owner: sergio

# group: sergio

user::rwx

group::r-x

group:users:rw-

mask::rwx

other::---

default:user::rwx

default:group::r-x

default:group:users:r-x

default:mask::r-x

default:other::---

Es importante recordar que en el caso de los archivos (no directorios), no importa que permisos se establezcan por defecto, siempre se aplica el limitante de lectura-escritura como permisos máximos para todos los usuarios, dicho de otra manera, nunca se creará por defecto un archivo con permiso de ejecución habilitado.