KVM y libvirt en Slackware

KVM (Kernel-based Virtual Machine) es una de las mejores soluciones para virtualización dentro del kernel de Linux, junto a libvirt, que no es mas que un conjunto de herramientas para administrar KVM, juntos son una poderosa combinación para poder trabajar en entornos de desarrollo o en producción.

KVM ya se encuentra habilitado en los kernels entregados por Slackware, por lo que solamente hay que corroborar que nuestra máquina tenga soporte para virtualización, como Intel-VT o AMD-V, aunque actualmente la mayoría de procesadores para PC de escritorio o laptops tienen éste soporte, pero podemos verificar las CPU flags de la siguiente manera:

Para procesadores AMD:

$ grep --color svm /proc/cpuinfo

Para procesadores Intel:

$ grep --color vmx /proc/cpuinfo

La salida de éstos comandos debe darnos información con las flags del CPU que tenemos disponibles, de lo contrario sabremos que no contamos con un procesador adecuado para virtualizar.

Instalación de un entorno libvirt

Para instalar libvirt en Slackware es necesario instalar previamente varias dependencias, lo que puede resultar tedioso si no tuviésemos a la mano el repositorio de SlackBuilds.org (SBo).

La instalación es simple, podemos descargar los slackbuilds o bien utilizar sbopkg, seguir las listas de dependencias e instalarlo, siempre recordando leer los README para evaluar la instalación de paquetes opcionales, en especial con el paquete netcat-openbsd que suele tener problemas con otros paquetes.

Es importante tomar en cuenta que el slackbuild de libvirt viene por defecto para usar el grupo users del sistema, pero yo recomiendo tener otro grupo específico para poder aislar a otros usuarios del uso y administración de libvirt y las máquinas virtuales. La mejor forma es crear un grupo y luego añadir a los usuarios que necesiten virtualizar a éste grupo:

# groupadd libvirt
# gpasswd -a nombre-usuario libvirt

El comando gpasswd agregará a el usuario que necesitemos al grupo libvirt, o bien podemos modificar el archivo /etc/group y agregarlo manualmente. Los usuarios deberán reiniciar su sesión para poder cargar los permisos.

Es recomendable instalar otras herramientas como virt-manager, que no es mas que un administrador gráfico para libvirt, pero necesita muchas otras dependencias de gnome.

Qemu se debe instalar para poder crear las máquinas virtuales o bien utilizar la alternativa de Xen, pero ésta ultima tiene la desventaja de que solamente se podrá instalar en sistemas de 64 bits. Es importante agregar qemu al mismo grupo de virtualización al momento de compilarlo (KVMGROUP=libvirt).

Algunas herramientas extras son openvswitch y usbredir, que pueden agregar muchas mas funcionalidades a la creación y uso de nuestras maquinas virtuales.

Cambiando la carpeta de almacenamiento de libvirt

Libvirt por defecto utilizará la carpeta /var/lib/libvirt/images como la carpeta para crear las imágenes de los discos de nuestras máquinas virtuales, pero algunas veces necesitamos que las imágenes las tengamos en una unidad aparte, o una partición con mucho mas espacio.

Lo primero es asegurarnos de crear la carpeta donde queremos almacenar las imágenes de los discos de las máquinas virtuales:

# mkdir /nueva/carpeta/para/imagenes

Los permisos de acceso son importantes a ésta carpeta, solamente root debe poder accederlas:

# chown root:root /nueva/carpeta/para/imagenes
# chmod 755 /nueva/carpeta/para/imagenes

Para cambiar el pool de almacenamiento principal de libvirt a otra localidad podemos hacer uso de la herramienta virsh:

# virsh pool-destroy default
# virsh pool-undefine default
# virsh pool-define-as --name default --type dir --target /nueva/carpeta/para/imagenes
# virsh pool-autostart default
# virsh pool-build default
# virsh pool-start default

Los comandos anteriores primero realizan una destrucción de la información del pool default, luego lo eliminan de las definiciones para las máquinas virtuales, para luego crear una nueva definición, con el mismo nombre «default»; luego coloca de nuevo el pool «default» para que se habilite automáticamente al iniciar el servicio de libvirt; el comando pool-build se encarga de crear la información de la nueva carpeta, colocando información de tamaño y permisos, importante para que el sistema pueda saber cuanto espacio tiene disponible para las máquinas virtuales; y por último se inicia el pool «default» para que pueda ser utilizado.

Ahora solo resta divertirse con la virtualización.

Plasmoid Simple Monitor

He trabajado bastante con Qt, casi desde su versión 3, cuando aún KDE era bastante liviano que lo utilizaban en varias distribuciones que usaban LiveCD, por lo que cuando comenzó a aparecer QtQuick, me dispuse a entender cómo funcionaba, aunque al inicio no fue muy simple, puesto que era una aplicación que utilizaba C++ y luego se cargaban objetos con QML.

Al evolucionar la tecnología de QtQuick, se hizo mas fácil crear aplicaciones, ya no hubo necesidad de mezclar lenguajes, si no simplemente utilizar QML y quizá combinarlo con algo de Javascript; mucho de ésto se ve reflejado en el sistema de plasmoids para KDE 4, que ha madurado bastante.

Mientras buscaba una forma de reemplazar mi viejo monitor de sistema gkrellm, el cual por cierto no lo he llegado a sustituir por completo, busqué entre la lista de aplicaciones disponibles en KDE-look.org y no encontré algo que me llamara mucho la atención, claro, era de esperarse, es una tecnología nueva, pocos la saben utilizar y habremos pocos que sepamos realmente crear interfaces visualmente atractivas, por lo que pocos suben sus aplicaciones a este sitio.

Tenía otra alternativa, que me pareció factible, utilizar conky, el cual es otra aplicación bastante buena para monitorear el sistema y bastante personalizable, pero no se lleva muy bien con KDE. También estaba superkaramba, pero muchos de los elementos que usa suelen ser llamadas a aplicaciones de terminal que al final no era lo que yo necesitaba, aunado a que superkaramba debe estar funcionando para que sus plasmoids funcionasen.

Así que decidí crear mi propio plasmoid, el cual nombré plasma-simpleMonitor, aunque de plasma aún no tiene mucho, pero el objetivo es vincularlo completamente al sistema de temas de KDE.

Había dos opciones, crear uno escrito en C++, lo que me ayudaría a realizarlo de manera mas simple, puesto que manejo a un nivel aceptable el lenguaje, pero tendría el inconveniente de cualquier otra persona que deseara probar el plasmoid tuviese que compilarlo, instalarlo, etc. Y no cualquier persona está dispuesta ha realizar ésto. Así que la decisión estaba tomada, el plasmoid sería hecho con QML y Javascript, de ésta manera, se puede descargar de la página y probarlo, incluso integrarse fácilmente con el instalador de plasmoids de KDE.

Las características mas importantes que tenía en mente para comenzar su desarrollo eran:

• Capacidad de verificar el trabajo de los núcleos (cores) de mi CPU
• Verificar la temperatura; se vuelve importante cuando se pone a trabajar a la máquina
• Verificar el estado de la memoria y la swap
• Un lugar para mantener la hora y fecha del sistema, de una manera mas vistosa
• Verificar el tiempo que se ha mantenido encendida la máquina (uptime)

La idea comenzó con un boceto hecho en Inkscape, obviamente no podía comenzar a programar sin saber qué era lo que quería obtener como resultado.

plasma-simpleMonitor, Diseño inicial

Así que luego procedí a trabajar, en un par de días tuve la primera versión, pero obviamente no era muy atractiva visualmente, a lo que me puse a trabajar un poco mas en cómo se debería ver y al final llegué a tener una versión decente, la cual fue colocada en sitio KDE-look.org.

Luego de unos cuantos días de estar colocada en el sitio de KDE-Look, comenzó a tener aprobaciones como desacuerdos, como debe  ser, pero al final la experiencia ha sido buena, he tenido la oportunidad de ver cómo va poco a poco llegando a ser la herramienta que quería que fuera, aunque aún le falta camino por recorrer.

El código fuente se encuentra en GitHub: https://github.com/dhabyx/plasma-simpleMonitor liberado bajo una licencia GPL v3

Cambio de etiquetas para pendrives desde línea de comandos

Al momento de comprar una pendrive (nueva memoria USB) siempre tenía el incoveniente de cambiarle la etiqueta, ésto no es tan fácil ya que Linux por defecto no usa sistemas de archivos FAT, por lo que no funciona un simple click derecho.

En cambio es mas fácil desde línea de comandos en un solo paso pero hay que configurar una aplicación:

Lo primero es tener instalado el paquete floppy, que en el caso de slackware viene por defecto en una instalación completa, y si por alguna razón no lo han instalado lo mejor será ir a la carpeta a/ del disco de instalación e instalar el paquete floppy.

Una vez instalado solo resta configurarlo adecuadamente, el archivo /etc/mtools.conf trae ya unos datos de ejemplo, lo que debemos agregar al final del archivo es una línea como la siguiente (editando como superusuario «root»):

drive p: file="/dev/sdb1"

donde «p» es el nombre de una unidad como en DOS, por ello va acompañado de «:» y puedes escoger el nombre de letra que desees; luego el argumento de file debe ser la dirección hacia el dispositivo que deseamos administrar con ésta herramienta, que para ejemplo he colocado /dev/sdb1, ya que actualmente los discos son numerados con la nomenclatura /dev/sdX#, siendo X una letra, comenzando por «a» según el disco físico y # el número de partición, por lo que hay que tener cuidado en conocer realmente que nomenclatura ha sido asignada a nuestra pendrive.

Una vez configurado el archivo, puede ser usado para cualquier otro dispositivo que sea reconocido con ésta nomenclatura.

Para finalizar debemos crear un archivo en nuestra carpeta de usuario (no root):

$ cd ~
$ echo "mtools_skip_check=1" >> .mtoolsrc

y ahora es tiempo de cambiar etiquetas a nuestras pendrives:

$ mlabel p:NombreUSB

donde «p:» es la unidad que configuramos previamiente y lo que sigue a continuación es el nombre de la pendrive, que no debe pasar de 11 caracteres.

Si deseamos ver los cambios solo debemos verificar con:

$ mlabel -s p:

KDE, cómo cargar scripts de usuario

KDE tiene tres carpetas esenciales para la carga de scripts:

• Scripts que se cargan al inicio de KDE:  .kde/Autostart
• Scripts que se pueden cargar antes de que todo KDE sea cargado, en especial si queremos que variables de entorno funcionen en todas las aplicaciones de KDE: .kde/env
• Scripts que se carguen cuando cerremos la sesión: .kde/shutdown

Todos los scripts que coloquemos en éstas carpetas se ejecutarán en su debido momento, pero debemos tener el cuidado de que tengan permiso de ejecución pero que cumplan con los requisitos para que sean ejecutados sin indicar qué aplicación los interpretará.

Otros lugares interesantes por tener en cuenta en éste enlace de Linux From Scratch

GPG integrado con KDE en Slackware

Inicié a controlar mis gastos e ingresos por medio de KMyMoney, una herramienta que me la habían recomendado mucho, pero antes me encontré con muchas otras herramientas, como GnuCash, eqonomize, etc. pero lo primero que busqué fue que tuviera soporte para encriptar los datos.

Mi opción, conociendo sus características, fue KMyMoney, ya que se integra bastante bien con KDE, que es el escritorio que siempre me ha gustado utilizar en Slackware y utiliza GPG para encriptar los archivos.

El problema comienza con la configuración para que pueda abrir archivos encriptados, ya que GPG por defecto no se integra lo suficiente con los escritorios gráficos, es mas una herramienta de línea de comandos.

Para integrar correctamente cualquier aplicación que haga uso de GPG en un ambiente gráfico como KDE debe poder acceder a un agente que se encarga de intercambiar información entre la aplicación y el archivo cifrado por GPG.

Primero debe de asegurarse de tener configurado adecuadamente GPG, para ello vamos primero por el archivo de configuración de GPG ~/.gnupg/gpg.conf, el cual puede ser abierto con nano o vim:

$ cd ~
$ nano .gnupg/gpg.conf

y luego buscar si se tiene habilitada la opción use-agent

Ahora nos falta configurar el agente encargado de gestionar la información, en este caso pinentry que ya viene con slackware, para ello tenemos que crear o modificar el archivo ~/.gnupg/gpg-agent.conf verificando al menos tres líneas importantes:

pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 300

La opción pintetry-program indica que programa utilizar, para kde es pinetry-qt4, existen para gtk y demás.
La opción no-grab para evitar que pinetry capture teclado y mouse, (no es algo que nos proteja de los keyloguers y demas)
La opción default-cache-ttl es el tiempo en segundos para mantener activa la contraseña.

Con ésto arreglado se puede proceder a realizar una prueba, para evaluar que todo vaya bien; en la línea de comandos ejecutamos lo siguiente:

$ gpg-agent --daemon

Nos debe devolver que se ha iniciado y nos dará unas variables para que los programas los utilicen, algo como:

GPG_AGENT_INFO=/tmp/....:7711:1

luego podemos matar el proceso con un simple killall

killall gpg-agent

Ahora es tiempo de configurar KDE

Solo resta agregar dos scripts, uno que se cargue antes de iniciar KDE para cargar las variables dadas por gpg-agent y otro para cerrar gpg-agent al terminar nuestra sesión. Los scripts se pueden crear en cualquier lado y con cualquier nombre, solo deben tener permiso de ejecución, y cargarlos desde el administrador de KDE en la sección Arranque y apagado.

Script de inicio, debe ser colocado con la opción Ejecutar en: Prenicio de KDE.

#!/bin/sh
# Inicio de gpg-agent para todo KDE

eval "$(gpg-agent --daemon)"

Script del final, se debe cargar con la opción Ejecutar en: Apagar

#!/bin/sh
# cierra toda instancia de gpg-agent que haya sido cargada con la sesión.

if [ -n "${GPG_AGENT_INFO}" ]; then
    kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) >/dev/null 2>&1
fi

Ahora solo falta salir de la sesión y reingresar.

Experiencias actualizando 13.37 a Slackware-current (14.0 beta)

Luego de iniciar mi recorrido por slackware y un buen tiempo sin actualizar mi slackware-current, he tenido que hacer una buena limpieza de paquetes; tenía paquetes demasiado obsoletos compilados desde slackbuilds y otros desde un gnomeslackbuild, pero esto me traería problemas tarde o temprano, así que decidi eliminar todos los paquetes que no eran los que vienen por defecto con slackware.

El primer paso es actualizar nuestra lista de paquetes, recordando previamente haber configurado adecuadamente slackpkg, en especial en tener en cuenta el kernel y otros paquetes importantes, antes que nada siempre es mejor leer el archivo UPGRADE.txt donde se explica que paquetes hay que actualizar antes y efectuar los comandos ahí mencionados, luego podemos usar slackpkg:

# slackpkg update

Con la lista de paquetes nuevos en el repositorio es hora de borrar paquetes no oficiales:

# slackpkg clean-system

Esta acción nos desplegara una lista de los paquetes que estan instalados en el sistema y que no estan en la lista oficial, siendo posible no eliminar algunos paquetes que sabemos que no tendran conflictos, y en mi caso eran libreoffice, java y sbopkg.

Luego se actualizan los paquetes:

# slackpkg upgrade-all

Al finalizar la actualización, hay que recordar verificar si los paquetes han tenido grandes cambios de versiones donde los archivos de configuración no sean compatibles con viejas versiones, como por ejemplo: apache, kde, etc.

Una vez actualizados los paquetes, podemos instalar los nuevos paquetes:

# slackpkg install-new

Una vez instalados podemos proceder a instalar el kernel manualmente con un simple installpkg y el paquete de kernel que se prefiera.

Siempre hay que recordar borrar la configuración del home de KDE para que la nueva versión no tenga problemas.

Y solo nos resta disfrutar de la beta y prepararse para recibir Slackware 14.0   …..   😀

Slackbuilds.org creciendo!!

Para los que no conocían SlackBuilds.org, éste proyecto es un repositorio de Scripts de Bash, empaquetados con otros archivos, que generan paquetes binarios para Slackware, basándose en los scripts que Patrick Volkerding usa para crear la distribución; éstos scripts aparecieron por primera vez en la versión 3.1 de Slackware y que fue liberada en Octubre de 1996, según los Changelogs que aún se encuentran disponibles (Aunque puede que me equivoque).

El proyecto SlackBuilds comenzó el 6 de julio de 2006, con al rededor de 32 SlackBuilds ordenados en 10 categorías (información obtenida del Changelog), donde se podía encontrar SlackBuilds para OpenOffice, octave, wine, entre otros. todos ellos para la versión de Slackware 11, que no duró mucho tiempo para luego pasar a la versión 12.0.

Configuración de modem tigo

Después de un tiempo sin colocar un post, me decidí a escribir un post sobre como configurar un modem tigo HUAWEI  para Guatemala utilizando wvdial, probado con varios modems en especial para el modelo E160.

Para ello se necesita instalar dos paquetes, disponibles desde slackbuilds.org wvstreams y wvdial y ejecutar luego como root

# wvdialconf

y luego de que nos genere la configuración para nuestro modem podemos configurarlo como el siguiente ejemplo, ya sea añadiendo o modificando las líneas del archivo de configuración.

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,»»,»broadband.tigo.gt»
Modem Type = Analog Modem
Phone = *99#
Modem = /dev/ttyUSB0
Username = tigo
Password = tigo
Baud = 460800

dependiendo de la velocidad del modem habrá que ajustarlo.

Para terminar solo deben ejecutar

# wvdial

Si les funciona la configuración para otros tipos de modem pueden dejar su comentario para ir incrementando la lista de modems que funcionan con estos datos.

Tuneando el XFCE

Después de andar por mucho tiempo en KDE me decidí a migrar a XFCE, además de que las ultimas actualizaciones de KDE 4.2.1 en Slackware-Current han estado dándome problemas.

Así que me puse la tarea de poner bonito mi XFCE, pero vi cierta dificultad al instalar temas obscuros donde las fuentes del menú de XFCE simplemente desaparecían en el fondo Blanco de éste, por lo que me decidí a encontrarle solución.

ccache en Slackware

Cuando un usuario de Slackware añade software a su sistema normalmente debe compilarlo, o bajar paquetes de algún lugar; siempre es mejor administrar lo que se instala por medio de la paquetería de slackware para que podamos desinstalar y actualizar fácilmente y sin problemas.

El problema viene cuando no disponemos de un Slackbuild, ya sea para la versión que necesitamos o por que simplemente no existe un paquete para el software; una solucion es hacer el paquete mediante makepkg; la mas recomendable es hacer nuestro propio Slackbuild y solo modificarlo para cada versión del software que instalemos.

Esto trae siempre otros problemas, ya que si por algún motivo no pusimos algún parámetro al configure o no configuramos adecuadamente el paquete, la recompilación del mismo nos lleva mucho tiempo, con lo cual hacer Slackbuilds de programas muy grandes suele ser tedioso.

La mejor solución es utilizar ccache, que es un programa que nos guardará una cache de lo que compilemos; con esto aceleraremos la compilación de programas, ya que si el codigo a compilar es identico a lo que ccache ya tiene, simplemente será reemplazado y solamente compilara lo nuevo.

Ccache no solo nos ayudará en la compilación de paquetes de software que descarguemos de internet; si trabajamos en el área de desarrollo de software basado en lenguaje C o C++ tendremos a la mano un buen programa que nos ahorrará mucho tiempo en la compilación, mas a la hora de eliminar bugs en programas grandes.

Configurando ccache

Lo primero es darle una lectura a la página de manuales de ccache, luego podemos proceder a gener lo que necesitamos.

Normalmente podemos tener ccache