Instalar paquetes con PackageKit desde CLI

Tradicionalmente, cada distribución Linux ha usado un gestor de paquetes:

  • Debian con apt-get.
  • RHEL/CentOS con yum.
  • Fedora ahora con dnf.
  • Arch con pacman
  • Etc.

Por ello, hace unos años surgió la iniciativa de PackageKit, un framework de gestión de paquetes que proporciona una capa de estandarización sobre ellos.

Continúa leyendo Instalar paquetes con PackageKit desde CLI

Anuncios

Ver emojis en Linux

Los emojis son la evolución de los emoticonos. Mientras que tradicionalmente los emoticonos eran combinaciones de caracteres básicos, como :-) o ¬_¬', los emojis son cada cual un carácter Unicode (la codificación de caracteres internacional estándar) concreto.

Los móviles iOS y Android los muestran por defecto, cada cual en su estilo particular, pero si alguien con un móvil de esos nos manda un e-mail, probablemente no veamos esos iconos correctamente en nuestro ordenador Linux.

Continúa leyendo Ver emojis en Linux

Web descentralizada para todos

Ya estuvimos hablando de la descentralización de la mensajería instantánea con XMPP. Hoy me alegro de poder decir que cada vez es más fácil tener tu propio rincón privado de Internet. Os presento 3 distribuciones a tener en cuenta:

Continúa leyendo Web descentralizada para todos

Ficheros encriptados en Linux

Hoy vamos a ver cómo se puede configurar Debian y Ubuntu para tener una carpeta encriptada. Usaremos la utilidad llamada ecryptfs, y seguiremos los pasos descritos en la ayuda de Ubuntu.
Primero se instala.

# aptitude install ecryptfs-utils

Ahora vamos a configurarlo.

$ ecryptfs-setup-private

Primero nos pide nuestra contraseña de acceso, y luego pide una contraseña de encriptación. Se usará la primera para desencriptar la segunda, y la segunda para desencriptar los ficheros. Esto funciona así para que se monte automáticamente la carpeta al abrir la cuenta sin correr peligro de que root pudiera cambiarnos la contraseña y acceder a los datos. Así es, con esta encriptación ni root puede ver nuestros datos.
Por ello, se recomienda que la contraseña de encriptación (la 2ª) se almacene en algún sitio, por si más a delante nos toca recuperar los datos. Eso y que sea la contraseña más paranoica que hayas puesto en tu vida, ya que total sólo la vas a necesitar en esos casos.
Cuando hayas terminado esto, se habrán creado 3 directorios:

  1. ~/.Private: Datos encriptados.
  2. ~/Private: Punto de montaje automático. Es el que se usará en el día a día. Cuando no esté montado, veremos dentro un par de ficheros que nos lo advertirán.
  3. ~/.ecryptfs: Configuración. Podemos eliminar o renombrar los ficheros auto-mount y auto-umount para que no se monte o desmonte automáticamente al iniciar sesión, respectivamente.

Ahora puedes cerrar y volver a abrir la sesión, o escribir:

$ ecryptfs-mount-private

Con eso tendrás lista la carpeta ~/Private para guardar todas las cosas que quieras almacenar encriptadas. Una forma sencilla es mover ahí la configuración de cosas que quieras y crear symlinks donde estaban antes. Por ejemplo:

$ cd ~
$ mv .cache Private/
$ mv .mozilla Private/
$ mv .rednotebook Private/
$ mv .evolution Private/
$ mv .ssh Private/
$ mv .local/share/Empathy/logs Private/.empathy-logs
$ ln --symbolic Private/.cache
$ ln --symbolic Private/.mozilla
$ ln --symbolic Private/.rednotebook
$ ln --symbolic Private/.evolution
$ ln --symbolic Private/.ssh
$ cd .local/share/Empathy
$ ln --symbolic ../../../Private/.empathy-logs/ logs

Por supuesto, mientras movemos todos estos archivos de configuración, los programas que los usan deberían estar cerrados.

Cambiar el indicador de bash (bash prompt)

Una de las cosas que me desesperan cuando escribo en la consola de Linux es que a veces cuesta bastante diferenciar lo que he escrito yo de lo que me ha respondido el sistema.

Para solventar este problema, podemos modificar la variable del usuario llamada $PS1. Esta variable almacena el formato que guarda el bash prompt, que viene a ser lo que aparece cuando Linux quiere que le escribamos algo en la consola. Normalmente en Debian sale así por defecto, todo en blanco:

usuario@sistema:/ruta/en/la/que/estas$

 Si por curiosidad queremos ver cómo le hemos dicho a Linux que nos muestre eso, no hay más que escribir:

$ echo $PS1

Esto nos devolverá algo parecido a lo siguiente:

${debian_chroot:+($debian_chroot)}\u@\h:\w\$

Normalmente Debian y derivadas nos ponen automáticamente un archivo en nuestro $HOME que establece estas cosas al iniciar sesión. Lo hallamos en ~/.bashrc.
Una forma fácil de colorear el prompt es editar dicho archivo y descomentar (quitar el # que lleva delante) la línea que pone force_color_prompt=yes. Para editarlo usaremos:

$ nano ~/.bashrc

Abre una nueva terminal y verás el cambio. ¿A que mejora? Pero aún puede mejorar más…
Intentemos entender cómo va esto. Nos olvidamos por un momento de la parte del principio (${debian_chroot:+($debian_chroot)}), que representa el chroot, pero eso son otras historias. Lo dejamos ahí, que no molesta.

El resto son variables que queremos que nos muestre, por ejemplo:

  • \u es el nombre del usuario.
  • \h es el nombre de la máquina.
  • \w es la ruta completa en la que estamos trabajando
  • \$ nos pone un $ si somos un usuario normal, y un # si somos root (ahora entenderás por qué lo pongo siempre delante cuando pongo código en el blog).

Pero estas no son las únicas disponibles, hay muchas otras muy prácticas:

  • \t – Hora.
  • \d – Fecha.
  • \n – Nueva línea.
  • \s – Nombre del shell.
  • \W – Nombre de la carpeta en la que estamos trabajando (sin la ruta completa)
  • \# – Número de comando introducido
  • \! – Número de historia del comando introducido

Además de esto podemos poner colores, negrita, subrayado, color de fondo, etc., tan sólo con poner indicadores de formato teniendo en cuenta que todo el texto que siga al indicador de formato cambiará a ese formato hasta que se encuentre el siguiente indicador.
Los indicadores de formato empiezan por \e[ y terminan por m, y normalmente se envuelven en corchetes ([]) para indicar que son caracteres que no deben mostrarse.
En la wiki de Arch Linux he encontrado una lista bastante exhaustiva de colores y modificaciones, a parte de una explicación mucho más detallada de todo lo que os estoy poniendo aquí, pero todo en inglés, como siempre.
Con toda esta información ya podemos hacer todas las pruebas que queramos y ponernos el prompt que nos apetezca. El mío ahora mismo es así:

\[\e]0;\u@\h: \w\a\]\n\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\e[1;33m\]\t \[\e[1;32m\]\u\[\e[0;33m\]@\[\e[0;32m\]\h\[\e[00m\] \[\e[01;34m\]\w\n\[\e[1;33m\]\$ \[\e[00m\]

Para probarlo no tienes más que escribir:

$ PS1='\[\e]0;\u@\h: \w\a\]\n\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\e[1;33m\]\t \[\e[1;32m\]\u\[\e[0;33m\]@\[\e[0;32m\]\h\[\e[00m\] \[\e[01;34m\]\w\n\[\e[1;33m\]\$ \[\e[00m\]'

Además aquí tenemos un tutorial exhaustivo de cómo manejar el bash prompt en inglés.

Problemas de sonido en Debian

Con mi iniciación en Debian, me he topado con un problema bastante fastidioso: no conseguía grabar sonido.
Investigando descubrí otros 2 problemas relacionados con el sonido: que al grabar con la webcam usando Cheese grababa como a 2 FPS, y que no podía tener varias aplicaciones usando sonido simultáneamente.
Bueno, tras mucho googlear y pelear con el ordenador, he encontrado la solución. Parece ser que es un problema con ALSA, el sistema de sonido que suele usar Linux (algo más nuevo que el antiguo OSS, aunque éste aún está en uso).
La solución es usar el servidor de sonido PulseAudio, que si no me equivoco, se encarga de gestionar las conexiones con ALSA. No sé si esto es cierto al 100%, pero desde luego ahora funciona.
Para instalarlo:

# aptitude install pulseaudio paprefs

Pulseaudio es el metapaquete, paprefs es la interfaz en GTK. Ahora os explicaré cómo configurarlo en Gnome.
Una vez instalados los paquetes, iremos a configurar los dispositivos de entrada en Sistema > Preferencias > Selector de sistemas multimedia, o por consola:

gstreamer-properties

Aquí elegiremos como complementos de salida y entrada de audio PulseAudio Sound Server.
Cerremos todas las aplicaciones que estén usando audio, y las abrimos de nuevo. Bueno, no sé si esto es estrictamente necesario, pero bueno. Por si acaso, si lo prefieres, cierra la sesión y ábrela de nuevo. Todos los problemas anteriormente mencionados se arreglarán.
Queda la salvedad de Cheese, que probablemente siga grabándote lento. Ya explicaré esto otro día.
Edito: Aquí va un artículo muy interesante hablando sobre la instalación de PulseAudio.

¿Cómo me libro de escribir la contraseña de gnome-keyring cada vez sin perder demasiado en seguridad?

Bueno, ya que es mi primera entrada, os pongo en antecedentes: Soy programador, me encanta Linux, odio a Windows, odio muuucho a Internet Explorer, llevo cosa de 1 año usando casi exclusivamente Ubuntu en casa, y recientemente me he propuesto el reto de pasarme a Debian.

¿Por qué Debian?

  • Para aprender más de Linux
  • Para poder colaborar con la distribución en un futuro (espero), y que dichas colaboraciones beneficien a todas las distros basadas en Debian, entre ellas Ubuntu
  • Porque me convence más su filosofía
  • Porque prefiero tener más control sobre qué instalo en mi ordenador
  • Porque soy un friki
La ventaja de haber estado usando tanto tiempo Ubuntu es que ya sabes de qué es capaz Linux, con lo cual luego llegas a Debian y no tienes ni la mitad de cosas que tienes con Ubuntu al instalar, pero al menos ya sabes que si no van, es por algo.

Debí haber puesto aquí unas cuantas cosas más de las que me han pasado… Si recuerdo alguna la iré poniendo, pero de momento voy a exponer lo que me ha pasado hoy.

Problema: Configuro las cuentas con Empathy y ahora resulta que cada vez que inicio sesión, gnome-keyring me pide la contraseña para desbloquear el depósito default, en el que están esas claves. Y esto cansa, porque para iniciar la sesión metes la contraseña, y luego tienes que volver a meterla… ¡¡ARRGH!!

Hay 3 opciones:
  1. Ajo y agua… no me convencía.
  2. Quitar la contraseña al depósito de claves. Esto no me convencía porque perdía la seguridad que proporciona gnome-keyring.
  3. Configurarlo para que cree un depósito de claves que se abra automáticamente con mi misma contraseña de sesión. Esto pinta mejor…
    Solución: Instalar el paquete libpam-gnome-keyring, que básicamente crea un depósito de claves llamado login el cual abre automáticamente con tu clave de usuario al iniciar la sesión en Gnome. También tienes una descripción más detallada en su página de Gnome.

    # aptitude install libpam-gnome-keyring


    Problema: Mis claves están en el depósito default, no en login, así que sigue pidiéndome la clave al entrar.
    Solución: Borra ~/.gnome2/keyrings/, cierra la sesión, ábrela de nuevo, y vuelve a crear tus claves (espero que no tengas muchas). Desde terminal:

    $ rm --recursive ~/.gnome2/keyrings/



    Listo. Nuestras claves seguirán cifradas con nuestro querido gnome-keyring sin necesidad de tener que poner la contraseña de descifrado cada vez.

    Administrando el sistema: su vs. sudo

    Lo bonito de GNU/Linux es que tienes control absoluto sobre tu sistema, pero evidentemente este control no lo tienen todos los usuarios, sino solo los que tengan que tenerlo. Históricamente dicho usuario ha sido siempre root (“raíz” en inglés).

    Sin embargo, tener que cerrar tu sesión y abrir una nueva para administrar el sistema es una pesadez, para lo cual existen herramientas que te permiten adquirir temporalmente sus privilegios.

    Las 2 principales herramientas que conozco para esto son su y sudo, herramientas que pueden usarse conjuntamente, aunque recomiendo decidirse por una y quitar la otra, según los gustos del administrador.

    ¿En qué se diferencian?

    Básicamente, al usar su, debes introducir la contraseña de root, y dicho usuario debe estar activado, mientras que al usar sudo, debes introducir tu contraseña de siempre, debes estar autorizado a usarlo en el fichero /etc/sudoers, y no es necesario que exista un usuario activado llamado root.

    Otra diferencia importante es que su te pide la contraseña para cada vez que lo utilizas, mientras que sudo no te vuelve a pedir la contraseña hasta pasado un tiempo desde que lo usaste por primera vez.

    Hay otras diferencias respecto al comportamiento estándar de cada herramienta, pero no son diferencias tan importantes. Me refiero a:

    • Cuando ejecutas su, pasas a usar un shell de root en el que escribes los comandos que quieres realizar, mientras que sudo suele utilizarse como prefijo a otro comando, que es ejecutado con permisos de root.
    • Al usar sudo, conservas las variables de entorno del usuario que lo usa, mientras que su adquiere las variables de root.

    He dicho que no son diferencias importantes porque cada herramienta proporciona métodos para comportarse más o menos como la otra. Veámoslos.

    Comportamiento estándar de su:

    yo@pc:~$ su
    root@pc:/home/yo# echo $HOME
    /root
    root@pc:/home/yo# exit

    Vemos cómo primero nos pide la contraseña de root, y luego abre una shell de root, y la variable $HOME (directorio de usuario) es la de root también. Ahora veamos el comportamiento estándar de sudo:

    yo@pc:~$ sudo echo $HOME
    /home/yo

    En este caso sudo es un prefijo que ejecuta solo un comando, y preserva las variables de entorno. Además la contraseña que nos pedirá es la nuestra. Ahora vamos a emular el comportamiento de sudo con su:

    yo@pc:~$ su --preserve-environment --command="echo \$HOME"
    /home/yo

    Notaréis que en este caso hay que pasar el comando como una cadena de caracteres, por eso he escapado el símbolo del dólar poniendo una barra invertida delante. Ahora emularemos el comportamiento de su con sudo.

    yo@pc:~$ sudo -i # Si quieres iniciar la shell pero preservar las variables, usa sudo -s
    root@pc:/home/yo# echo $HOME
    /root
    root@pc:/home/yo# exit

    Como vemos son herramientas muy versátiles.

    ¿Por cuál debería decidirme?

    Es una cuestión de gustos. Personalmente prefiero sudo, ya que no es necesario crear un usuario administrador y otro para uso normal, sino que es el mismo para ambas tareas, y permite que existan varios administradores en el mismo sistema sin necesidad de que ambos sepan la contraseña de root.

    Precauciones a la hora de cambiar de su a sudo y viceversa
    Antes de desinstalar la herramienta que no vayas a usar, asegúrate de que la nueva funciona a la perfección, ya que de otro modo podrías perder el acceso root y te quedarías sin poder administrar tu sistema.

    En caso de decantarte por sudo, es interesante desactivar la cuenta de root, ya que ya no es necesaria. Para ello:

    $ sudo passwd --lock root

    Para reactivarla, si te hiciera falta más adelante:

    $ sudo passwd --unlock root

    Si decides cambiar el método, puedes encontrar problemas

    Quizá os interese saber que Ubuntu usa por defecto sudo, mientras que Debian usa su, aunque ambas distribuciones permiten cambiarlo luego como prefieras.

    Siendo así, es posible que experimentes problemas de configuración si cambias de herramienta. Por ejemplo, si usas aptitude en modo interactivo, al usar la opción de obtener privilegios de administrador en Debian, tratará de usar su aunque no esté instalado, y saltará un error. Para ello deberás configurarlo para que utilice sudo:

    $ echo 'aptitude::Get-Root-Command "sudo:/usr/bin/sudo";' >> ~/.aptitude/config

    Tambiéntendrías que configurar gksu, la herramienta que se usa en Gnome para otorgar los privilegios, para que use el sistema que hayas elegido. En el mismo supuesto de antes sería:

    $ gconftool-2 --type bool --set /apps/gksu/sudo-mode true