Instalación/Actualización de Geogebra

Un compañero me preguntaba cómo mantengo actualizado GeoGebra. Lo publico aquí en el blog y así queda para todos los que me siguen.

Para mantenerlo actualizado simplemente uso los repositorios oficiales de GeoGebra. 

# cat /etc/apt/sources.list.d/geogebra.list 
deb http://www.geogebra.net/linux/ stable main

Si queréis utilizar estos repositorios, debéis añadir la clave también:

# wget -q http://www.geogebra.net/linux/office@geogebra.org.gpg.key  -O- | apt-key add -

Publicado por primera vez en http://enavas.blogspot.com.es

Modificando las configuraciones de un usuario con dconf en Gnome 3.4

La verdad es que a veces es una auténtica pesadilla ser informático porque cuando ya controlas una cosa, te la cambian y tienes que volver a empezar aprendiendo algo nuevo desde cero porque lo que sabías, ya nos sirve para nada. Para colmo, en muchas ocasiones, la falta de documentación te hace perder el tiempo de una forma impresionante.

dconf, como dice el sitio oficial de Gnome, es un sistema de configuración de bajo nivel basado en claves. La base de datos de dconf tiene una estructura en forma de árbol en la que hay claves y cada clave tiene su valor.

En un post anterior, os mostré como establecer ajustes predeterminados y bloquear ajustes para todos los usuarios. Hoy os voy a explicar cómo modificar los ajustes de un usuario de una manera sencilla desde la línea de comandos, que es lo que a los administradores nos interesa. Para realizar ajustes desde el entorno gráfico, ya tenemos dconf-editor.

Por si no lo sabéis, los ajustes de dconf de un usuario se almacenan en el siguiente archivo: ~/.config/dconf/user. No tratéis de editarlo porque es un archivo binario.

Para obtener dichos ajustes, nos logueamos con el usuario cuyos ajustes queramos modificar y utilizamos el comando dconf de la siguiente manera:

$ dconf dump / > ajustesusuario.dconf

¿Qué es lo que estamos haciendo? Le estamos diciendo a dconf que nos vuelque la base de datos dconf del usuario desde la rama principal (/), es decir, todas las claves, en un archivo ajustesusuario.dconf.

Si quisiéramos vocar sólo una rama, la especificamos y sólo se volcarán los ajustes a partir de ahí. Por ejemplo, si queremos obtener los ajustes de la rama /org:

$ dconf dump /org/ > ajustesusuario.dconf

Lo que obtenemos es un fichero de texto con todas las claves que haya en la rama indicada. Este fichero podemos modificarlo fácilmente con cualquier editor de textos.

Una vez modificado, podemos volcar a la base de datos dconf del usuario los ajustes establecidos de la siguiente manera:

$ dconf load / < ajustesusuario.dconf

También podríamos coger la base de datos modificada y copiarla al directorio /etc/skel para que, cada vez que se cree un usuario, éste tenga los mismos ajustes:

# cp /home/USUARIO/.config/dconf/user /etc/skel/.config/dconf/user

O podríamos examinar los ajustes para aplicarlos por defecto a todos los usuarios, siguiendo las instrucciones del post http://enavas.blogspot.com.es/2014/05/establecer-ajustes-predeterminados-y.html

Posibilidades... todas las que se os ocurran.

Publicado por primera vez en http://enavas.blogspot.com.es

Permitir al usuario actualizar el software instalado en el sistema con gnome-packagekit

El sistema de los portátiles se pensó de tal manera que un usuario tuviera que conectar el ordenador a la red del centro para que se realizara la actualización del software y se establecieran todas las configuraciones necesarias.

Ahora bien, si los usuarios sacan habitualmente el ordenador del centro, sería conveniente que el mismo usuario pudiera realizar las actualizaciones del software instalado en el equipo. Para ello, podemos usar gnome-packagekit combinándolo com polkit, de tal manera que se le permita actualizar los paquetes instalados, pero no realizar instalaciones o desinstalaciones de software.

Así que lo primero que haremos será instalar gnome-packagekit:

# apt-get install gnome-packagekit

Si ejecutamos pkgaction y filtramos la salida buscando la palabra packagekit, obtendremos una lista de políticas que podemos aplicar a packagekit:

# pkaction | grep packagekit
org.freedesktop.packagekit.cancel-foreign
org.freedesktop.packagekit.device-rebind
org.freedesktop.packagekit.package-eula-accept
org.freedesktop.packagekit.package-install
org.freedesktop.packagekit.package-install-untrusted
org.freedesktop.packagekit.package-remove
org.freedesktop.packagekit.repair-system
org.freedesktop.packagekit.system-change-install-root
org.freedesktop.packagekit.system-network-proxy-configure
org.freedesktop.packagekit.system-rollback
org.freedesktop.packagekit.system-sources-configure
org.freedesktop.packagekit.system-sources-refresh
org.freedesktop.packagekit.system-trust-signing-key
org.freedesktop.packagekit.system-update
org.freedesktop.packagekit.upgrade-system

Para permitir que el usuario pueda actualizar el sistema usaremos dos de ellas:

org.freedesktop.packagekit.system-update
org.freedesktop.packagekit.upgrade-system

Para definir las políticas que permitan a un usuario sin permisos de administración actualizar el sistema, crearemos un fichero: /etc/polkit-1/localauthority/50-local.d/20-org.freedesktop.packagekit.pkla con el contenido que os muestro a continuación:

# cat /etc/polkit-1/localauthority/50-local.d/20-org.freedesktop.packagekit.pkla

[org.freedesktop.packagekit.system-update]
Identity=unix-user:*
Action=org.freedesktop.packagekit.system-update
ResultAny=no
ResultInactive=no
ResultActive=auth_self_keep

[org.freedesktop.packagekit.upgrade-system]
Identity=unix-user:*
Action=org.freedesktop.packagekit.upgrade-sytem
ResultAny=no
ResultInactive=no
ResultActive=auth_self_keep

Si os dáis cuenta, estamos permitiendo que el usuario actualice el sistema, para lo que tendrá que introducir su password al menos la primera vez durante la sesión (ResultActive=auth_self_keep).

También podríamos permitirle que actualice el sistema sin tener que introducir su password (ResultActive=yes).

Publicado por primera vez en http://enavas.blogspot.com.es

killer: Un script perl para hacer limpieza de procesos

killer es un script perl que se ejecuta cada hora como una tarea cron para eliminar procesos que pertenecen a usuarios que no se encuentran "logueados" en el sistema.

Instalarlo en Debian es muy sencillo, puesto que se encuentra como paquete en los repositorios:

# apt-get install killer

El script se llama /usr/sbin/killer y la tarea cron que lo dispara: /etc/cron.daily/killer.

Este script puede ser tremendamente útil en un entorno donde inician sesión diferentes usuarios.

Publicado por primera vez en http://enavas.blogspot.com.es

Script musthave-build: Construir una lista de los paquetes instalados intencionadamente en el sistema

Como ya comenté anteriormente, en Debian Squeeze creábamos una lista de paquetes en /etc/pkgsync/musthave con los nombres de los paquetes instalados intencionadamente en el sistema para mantener una uniformidad en el software instalado en un conjunto de máquinas. Para generar la lista de paquetes en Debian Wheezy, que es multiarch, he tenido que hacer una pequeña modificación que incluya, además del nombre del paquete instalado, su arquitectura.

He preparado un script al que he llamado musthave-build que detecta el codename del sistema operativo (squeeze o wheezy) realiza la generación del fichero musthave en función del mismo.

Aquí podéis ver el código:

Publicado por primera vez en http://enavas.blogspot.com.es

El shell de linux: Construir una lista de los paquetes expresamente instalados en el sistema para pkgsync en Debian Wheezy

En un post anterior, vimos cómo obtener una lista de los paquetes instalados en el sistema. Este script lo utilizamos básicamente para construir el musthave de pkgsync y mantener uniforme el software de los equipos. 

El caso es que, por alguna razón, en Debian Wheezy, pkgsync no se comportaba como debía, instalando en unas ocasiones paquetes y desinstalándolos en otras. Yo lo he achacado a que Wheezy es multiarch, y, por lo tanto, puede instalar paquetes de diferentes arquitecturas. 

Por este motivo, gracias a las pruebas de Ismael, que lo ha detectado, he modificado el script para crear la lista de paquetes de manera que se incluya la arquitectura:

# aptitude show "?installed ?not(?priority(required)) ?not(?essential) ?not(?automatic)" | grep -e '^Package:' -e '^Paquete:' -e '^Arquitectura:' -e '^Architecture:' | sed '$!N;s/\n/ /' | awk '{print $2,$4}' | tr ' ' ':' | sort > /etc/pkgsync/musthave 

Publicado por primera vez en http://enavas.blogspot.com.es