Archivo del sitio

Xen 4 y Debian: corrigiendo algunos detalles

Instalar Xen 4.x en Debian GNU/Linux es bastante sencillo (el metapaquete xen-linux-system), ahora bien, configurar para hacer funcionar otras cosas es otra tarea distinta; por ejemplo, encontrarán que 6 cosas no  funcionan “a la primera” en Debian y deberá corregirlas para disfrutar al máximo de Xen 4.x:

1.- Habilitando XenAPI y accediendo con virt-manager

Virt-manager es la herramienta gráfica para libvirt (librería para acceso a servicios de virtualización, integra KVM, Qemu, Xen, LXC, openVZ y hasta VMWare) diseñada por la gente de Red Hat y que raya en lo infantil por su facilidad de uso para gestionar sistemas virtualizados, sin embargo, notaremos que luego de instalarlo, no podremos acceder a nuestro sistema Xen.

Para acceder con virt-manager (luego de instalado virt-manager y libvirt-bin) es activar el acceso por la API de Xen:

Editamos:

archivo: /etc/xen/xend-config.sxp

Y habilitamos http-server (en el puerto 8000, es el que usa libvirt), descomentamos (y ponemos en “yes”):

(xend-http-server yes)

Nota: si desean acceder desde cualquier equipo con libvirt (y no solo desde localhost), agregan esta línea:

(xend-address ”)

Posteriormente, debemos agregar al usuario con el que vamos a acceder al dominio Xen al grupo libvirt (ojo: esto como medida de seguridad para no acceder con el usuario root):

adduser jesuslara libvirt

E instalamos los paquetes necesarios para virt-manager y para que este nos interrogue por nuestra contraseña:

aptitude install virt-goodies ssh-askpass ssh-askpass-gnome

Listo!, ya podremos conectarnos a nuestro Xen vía un tunel remoto SSH (accedemos a “Archivo > Nueva Conexión  y seleccionamos Xen y modo “Tunel SSh Remoto”), usando nuestro usuario y nuestra contraseña.

2.- Creando VMs, configurando virt-manager

Una cosa que debemos configurar antes de empezar a crear máquinas con virt-manager, es indicarle en qué forma creamos los discos de las máquinas virtuales, esto se hace en el menú “Detalles” de la conexión al servidor Xen:

En esta ventana hay una pestaña que dice “almacenamiento”, donde podrán indicar si se crean volúmenes LVM, archivos de imagen en disco, etc

He creado 3 tipos de almacenamiento, un grupo de volúmenes LVM (para las máquinas virtuales), un espacio en disco (en /srv/xen) para aquellas máquinas que crearé usando archivos .img (imágenes qcow exportables) y una carpeta especial, donde he copiado los ISO de todos los sistemas operativos que utilizaré, así los podré usar rápidamente cada vez que quiera crear una nueva VM.

Ya con esto (Y la red), podrán crear máquinas virtuales.

3.- Creando VMs con HVM (virtualización completa) en virt-manager

Cuando intentan crear una VM HVM (que requiera virtualización completa, ejemplo, un Windows) con virt-manager, este emitirá un error de que no encuentra qemu-dm, esto es debido a que Xen utiliza una forma modificada de KVM y el ejecutable (aunque instalado, se llama “xen-qemu-dm-4.0”) no se encuentra en el lugar que espera virt-manager, esto se resuelve fácilmente con un enlace simbólico:

ln -s /usr/lib64/xen-4.0 /usr/lib64/xen

Y listo!, ya pueden crear máquinas usando HVM, fijense en este equipo freeBSD:

4.- virt-manager y “xm new” no funciona

“xm create” es la forma “usual” como creamos VMs en Xen, sin embargo, esto tiene un inconveniente, la VM es “creada” cada vez que se inicia y “destruida” (léase mejor, retirada de la lista de dominios administrados) del gestor de dominios Xen cada vez que se apaga, debido a esto, la VM no puede ser gestionada vía la XenAPI o vía gestores externos basados en libvirt (como virt-manager).

Este es un error heredado de Xen 3.x, cuando ejecutamos “xm new” aparece el siguiente error:

xm new -f test.cfg

Unexpected error: <type ‘exceptions.ImportError’>
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File “/usr/lib/xen-4.0/bin/xm”, line 8, in <module>
main.main(sys.argv)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3620, in main
_, rc = _run_cmd(cmd, cmd_name, args)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3644, in _run_cmd
return True, cmd(args)
File “<string>”, line 1, in <lambda>
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 1449, in xm_importcommand
cmd = __import__(command, globals(), locals(), ‘xen.xm’)
File “/usr/lib/xen-4.0/lib/python/xen/xm/new.py”, line 26, in <module>
from xen.xm.xenapi_create import *
File “/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py”, line 22, in <module>
from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc

Esto es debido a la ausencia del módulo xmlproc de python, sin embargo, cuando intentamos instalarlo ocurre esto:

apt-get install python-xml
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
El paquete python-xml no está disponible, pero algún otro paquete hace referencia
a él. Esto puede significar que el paquete falta, está obsoleto o sólo se
encuentra disponible desde alguna otra fuente
E: El paquete «python-xml» no tiene un candidato para la instalación

El paquete ya no existe (porque fué reemplazado por python-lxml) y porque xmlproc ya no está en esa librería, sin embargo, como XMLproc es utilizado simplemente para validar el DTD de los archivos XML generados por xenAPI (y eso no es un “error fatal” que afecte la creación de la VM administrada) entonces;  para hacerlo funcionar, simplemente abrimos el archivo:

archivo : /usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py

Y editamos la línea 22, comentándola:

#from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd

Cuando ejecutamos:

xm new -f test.cfg 
Using config file "./test.cfg".

Ahora veremos que la VM test está incorporada al administrador Xen permanentemente (permitiendo ser gestionada por la API vía xenapi o vía libvirt):

xm list
Name        ID  Mem    VCPUs    State Time(s)
Domain-0    0   2752   2        r----- 90.2
freebsd         512    1               0.0
test            256    1               0.0
winxp           1250   2               1358.4

Nótese que las VMs gestionadas por XenAPI no tienen ID si están apagadas, para encenderlas indicamos:

xm start test

Y veremos que la VM “test” se inicia, incluso podemos gestionarla vía libvirt (ej: virt-manager):

Nota: ¿y cómo editamos un domU administrado?, si contamos con el archivo cfg, entonces simplemente eliminamos el dominio:

xm delete test

Y lo volvemos a incorporar con xm new.

Si no contamos con el archivo cfg (porque tal vez lo creó otra herramienta) entonces debemos editar el dominio en “/var/lib/xend/domains/”, recuerde, sin embargo, que este archivo tiene la forma “SXP” (un parser a XML hecho en perl para sablotron, que permite persistencia de objetos en un pseudo-lenguaje de marcado), como esta:

(domain
(domid 3)
(vcpus_params ((cap 0) (weight 256)))
(PV_args ‘root=/dev/xvda2 ro ip=:127.0.255.255::::eth0:dhcp ‘)
(PV_bootloader )
(cpus (()))
(memory_sharing 0)
(superpages 0)
(VCPUs_live 1)
(actions_after_crash restart)
(uuid 6257207b-6831-ddcd-a21d-010a5fb77070)
(PV_ramdisk /boot/initrd.img-3.2.0-0.bpo.2-amd64)

5.- Mi VM Windows es lenta, ¿cómo hago?

Una de las razones por las cuáles la gente usa VMWare, es qué, como toda herramienta privativa, accede a información confidencial a la cual no acceden empresas dedicadas al software libre, esto es, VMWare “inyecta” drivers Windows WHQL para que el acceso a red, disco y video de la máquina virtual sea más rápido, sin embargo, desde 2011 eso es posible en Xen también!, ya que un joven hizo “ingeniería inversa” de los drivers Microsoft Windows para Hyper-V y existe una versión “libre” de los drivers para Windows, se llaman los Xen PV Drivers y al instalarlos en la VM con Windows, modificarán el acceso al “disco virtual” y a la “red virtual” de manera notable.

Para instalarlo, descargue la versión necesaria para la versión de Windows que instaló acá:

http://www.meadowcourt.org/downloads/

Antes de instalar, la tarjeta de red se ejecuta a 100Mbps, el acceso a disco en modo “IDE” y la tarjeta de video era cirrus;

Instale a la VM Windows, verá al instalar:

 

5.- Quiero cambiar de CDROM en virt-manager

Una de las cosas más frustrantes que te puedes encontrar, es que si intentas cambiar el CDROM (expulsar->desconectar en virt-manager) este te pedirá que reinicies la VM, esto debido a que el CDROM es tratado como “un disco más”, sin embargo, es posible cambiar de CDROM en una VM encendida; para ello:

1.- Expulsamos el CDROM en el sistema operativo

2.- Cambiamos a la cónsola de virt-manager (CTRL+ALT+2 en la ventana de la máquina virtual)

3.- Expulsamos (desconectamos) el CDROM en Virt-manager:

(qemu) eject hdc

4.- Montamos el nuevo disco, si es una imagen ISO, escribimos:

(qemu) change hdc /path/to/file.iso

Si es un CD en una unidad de CD-ROM, la ruta física a la unidad

(qemu) change hdc /dev/sr0

5.- Volvemos al sistema operativo y montamos la unidad de CDROM

Conclusiones

Espero que estos trucos les sirvan, a mí me han salvado un mundo en trabajo con virtualización Xen y como siempre, los publico acá por si alguien más los necesita.

Happy Hacking!

[Linux] formateos accidentales en discos ¿cómo recuperarse?

Anoche hice algo que te arrepientes por mucho tiempo, tomé un disco de la mesa y “mentalmente” seguro era el correcto lo puse en el portátil y reinicié, salí a tomarme un café para encontrarme con que tomé el disco de recuperación de la portátil (ni idea de por qué estaba allí sobre la mesa), borrando todo y apareciendo un gracioso logo de Windows Vista donde antes había Linux Debian.

¿Horror?, si, hubo mucho pavor en ese momento (era mi instalación Linux de trabajo), así que me tocó echar mano de las herramientas de recuperación para poder ganarle una al Windows.

Estado Inicial

Luego de la instalación automática y desasistida del equipo, terminé con dos particiones NTFS que ocupaban la totalidad del disco, como la primera había ocupado más de 10Gb, asumí que los datos de las primeras particiones (/boot, /root) estaría sumamente corrompidos, pero me preocupaba /HOME, que estaba en un volumen LVM, así tomé mis herramientas:

  • gpart
  • testdisk
  • lvm-tools

Y manos a la obra!.

Inicio: obteniendo información de las particiones perdidas

Lo más importante, es saber toda la información de las particiones perdidas, entre esa información hay una muy importante, TESTDISK requiere saber con exactitud la geometría correcta del disco; sino, se las verá muy mal a la hora de recuperar el disco.

Para esta información viene al rescate gpart (que no gparted, gpart!).

cuando ejecutamos:

gpart /dev/sdb

Donde /dev/sdb es el disco duro que deseamos escanear, este devolverá información acerca de todas las particiones presentes en el disco.

Primary partition(1)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 507mb #s(1038976) s(144224640-145263615)
   chs:  (1023/254/63)-(1023/254/63)d (8977/145/1)-(9042/61/43)r

Como ven, el disco fué formateado con una geometría de 254 heads (cabezales) y 63 sectores (números resaltados), anoten esto para utilizarlo con parted (modo rescue) o en mi caso, testdisk.

Segunda parte: ejecutando testdisk

Lo segundo que deben hacer es ejecutar testdisk, si no lo tienen pueden instalarlo (se llama: testdisk y está en los repositorios de Debian, Ubuntu y Fedora).

al ejecutar testdisk aparece esta ventana:

Nos pregunta si deseamos crear un log (llamado testdisk.log) de todas nuestras actividades, por seguridad, indiquen que sí.

De segundo, nos mostrará los discos a revisar, en mi caso:

Select a media (use Arrow keys, then press Enter):
Disk /dev/sda - 160 GB / 149 GiB - ATA SAMSUNG HM160HI
Disk /dev/sdb - 160 GB / 149 GiB - Generic External

Ya que el disco de 160Gb es un ATA Seagate que lo conecté por USB storage.

Seleccionamos el disco (flecha abajo), presionamos la tecla ENTER (INTRO, ustedes entienden ;).

Luego pregunta el tipo de partición:

Please select the partition table type, press Enter when done.
[Intel  ]  Intel/PC partition
[EFI GPT]  EFI GPT partition map (Mac i386, some x86_64…)
[Mac    ]  Apple partition map
[None   ]  Non partitioned media
[Sun    ]  Sun Solaris partition
[XBox   ]  XBox partition
[Return ]  Return to disk selection

Escojan “Intel” (no usé GPT en este disco).

En las opciones que salen, es donde vienen los cambios, escojan “[Geometry]”.

Luego, verán una pantalla como esta:

Acá es donde en [ Heads ] colocaremos los valores que recuperamos con gpart (en mi caso: Heads: 254 y Sectors: 63).

Presionen [OK] al terminar y ahora vamos al escaneo.

Presionen “Analyze”, luego de analizar (Quick Scan) ejecuten un “Deeper Scan” para revisar toda la superficie del disco.

Al terminar verán que encontró nuestra partición:

5 L Linux LVM             1862  42 31 19291 137 19  278904832

Presionen flecha derecha para cambiar los modos:

Modo “*” = Primaria, boot

Modo “P” = partición primaria

Modo “D” = partición borrada (útil si consigue una partición nueva que solapa una vieja)

Modo “L” = partición lógica

En algunos casos, testdisk no puede entender que es un Linux LVM, para ello podemos presionar la letra T (Change Type) y escogen el modo Linux LVM.

Nota mental: una partición linux clásica tiene un modo 0x83.

Esta partición que iba a recuperar era un grupo de volúmenes LVM, era lógica, verifico los datos con gpart (heads, sectors, sector de inicio y sector final, tamaño, etc).

Si todos los datos concuerdan, presiono ENTER y luego escojo “[ WRITE ]” para escribir los cambios al disco, deberán reiniciar (si es un disco atachado al computador) o desconectarlo (si es un USB storage) para que reconozca los cambios.

ya respiramos un poco más aliviados, ahora a recuperar el grupo de volúmenes.

Paso 3: Recuperar el grupo de volúmenes

Obviamente para este paso tu computador debe reconocer grupos de volúmenes (tener instalado el paquete lvm2), al volver a conectar el disco duro, ejecutamos el comando:

pvscan

Este buscará todos los grupos de volúmenes en todos los discos, encontrando este:

pvscan
  PV /dev/sdb5   VG VgCANTV   lvm2 [132,99 GiB / 57,96 GiB free]
  Total: 1 [132,99 GiB] / in use: 1 [132,99 GiB] / in no VG: 0 [0   ]

Entonces lo chequeamos (para verificar consistencia):

pvck -a /dev/sdb5 
  Found label on /dev/sdb5, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512

Lo vemos con pvdisplay:

pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sdb5
  VG Name               VgCANTV
  PV Size               132,99 GiB / not usable 4,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              34045
  Free PE               14837
  Allocated PE          19208
  PV UUID               A3m31N-wy5p-0zMl-0T3q-Nx45-jQR3-1Rjc4Q

Y lo activamos:

vgchange -a y VgCANTV
  49 logical volume(s) in volume group "VgCANTV" now active

Wow! 49 volúmenes (es donde tengo mis VMs de Xen de mi trabajo).

Luego de activado el volumen, vgdisplay nos retornará información:

vgdisplay 
  --- Volume group ---
  VG Name               VgCANTV
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  83
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                49
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               132,99 GiB
  PE Size               4,00 MiB
  Total PE              34045
  Alloc PE / Size       19208 / 75,03 GiB
  Free  PE / Size       14837 / 57,96 GiB
  VG UUID               PhZqJE-44xs-F0tP-XAXr-s2jZ-LlON-5LBL0t

Al tener su propio UUID el grupo de volúmenes (y sus particiones) ya pueden ser accedidas de manera usual.

Paso 4: montando y chequeando

Uno de los peligros de usar XFS es la corrupción de los descriptores, en mi caso no hubo problemas, antes de montar ejecutamos:

xfs_check /dev/mapper/VgCANTV-volHOME

Y chequeará cualquier detalle del Filesystem, en caso de necesitar reparación, ejecutamos:

xfs_repair /dev/mapper/VgCANTV-volHOME

Si acaso hubo una pérdida de los logs de descriptores, pueden hacer que repare el sistema haciendo caso omiso de los logs y buscando los descriptores directamente del FS:

xfs_repair -L /dev/mapper/VgCANTV-volHOME

Por seguridad, le generamos un nuevo UUID a la partición XFS:

xfs_admin -U generate /dev/mapper/VgCANTV-volHOME

Y por último ya podemos montarla:

mount -t xfs /dev/mapper/VgCANTV-volHOME /media/respaldo/home

Respaldamos nuestros datos y ¡listo!, ya nos recuperamos!.

Lo bueno de herramientas como Testdisk o Gpart es que vienen incluídas en varias distribuciones LiveCD para recuperación de datos, como por ejemplo SystemRescueCD (del cual hice un artículo acá). Por desgracia no contaba ni con unidad de CD ni con mi SystemRescueUSB, pero testdisk y gpart son herramientas bastante pequeñas y se instalan en cualquier linux muy rápidamente.

 

[Hacking Canaimita] Incorporando Bluetooth externo

Bluetooth es una forma muy práctica de compartir archivos entre dispositivos, sobre todo entre teléfonos y equipos portátiles, aunque la Canaimita cuenta con tarjeta inalámbrica, no cuenta con bluetooth.

Bluetooth es una red de corta distancia.

Los dongle bluetooth son extremadamente baratos, se los puede encontrar hasta por 2US$ en ebay o amazon:

Adquirí uno muy pequeño que sirve de manera muy eficiente.

Nota: pueden encontrarlo en Mercadolibre por menos de 40 Bs. cada uno:

http://listado.mercadolibre.com.ve/bluetooth-dongle

Instalación de Bluetooth en Canaima GNU/Linux

Proceda a conectar el dongle bluetooth en algún puerto disponible USB del equipo, luego, instalaremos las aplicaciones.

Los paquetes referentes a bluetooth en GNU/Linux Debian/Canaima se conocen como los Bluez, una búsqueda en synaptic los muestra:

Los paquetes más importantes a incorporar son:

  • bluetooth
  • bluez
  • bluez-utils
  • bluez-firmware
  • blueman

Con esto, se instalarán el resto de dependencias.

Utilizando bluetooth

Lo primero que debemos hacer es levantar el servicio de bluetooth, para ello agregamos a la lista de aplicaciones al arranque:

Sistema > Preferencias > Aplicaciones al inicio

Y agregamos una nueva entrada con el comando:

bluetoothd

Esto permitirá que el servicio levante con la sesión del usuario.

Cerramos sesión y volvemos a entrar.

Aparecerá un ícono de bluetooth en la barra de sistema:

Entonces, podemos ir a “Sistema > Preferencias > Administrador Bluetooth” y poder administrar los dispositivos conectados:

Y ya podemos usarlo sin problemas!

Haciendo pairing (enlazado) de equipos con Bluetooth

Una de las cosas más prácticas es enlazar dos equipos para que transmitan información, en el Administrador bluetooth presionamos “buscar” y este comenzará a buscar equipos:

Cuando encuentren un dispositivo:

Este pedirá una clave de pairing (enlazado) así:

Cuando han terminado de enlazar, ya pueden comenzar a enviarse archivos.

Cuando por ejemplo, desde un teléfono deseen enviar un archivo a la Canaimita, verán aparecer un cuadro como este en el área de notificación:

Y en la carpeta “PUBLICO” podrán encontrar todo lo que han enviado desde el teléfono u otro dispositivo.

Tips:

  • El equipo siempre va a pedir una contraseña y autorización de transmisión, si desean “confiar” en él, entonces en el administrador bluetooth le dan botón derecho sobre el dispositivo y le dicen “Confianza” esto permitirá que transmita sin necesidad de contraseña o autorización
  • El dispositivo bluetooth es como cualquier otro dispositivo USB, deben primero apagarlo (botón derecho sobre el ícono de bluetooth > Desactivar bluetooth) si desean desconectarlo, por medidas de seguridad
  • Blueman es una aplicación que funciona como un applet en Gnome y permite gestionar dispositivos bluetooth.
  • Para usar bluetooth desde la consola tienen el comando “hcitool”
  • Para que el equipo sea visible por otros equipos, presionen botón derecho sobre el ícono de bluetooth, preferencias y ahí colocarán el nombre del dispositivo y que sea visible por defecto al encender el bluetooth.

Espero les sirva de ayuda!.

En la próxima entrega, la instalación de un modem 3G y lo necesario para navegar vía 3G.

Happy Hacking Canaimita!

[Proyecto] Hacking Canaimita! <3

“Hacking Canaimita” será de ahora en adelante una serie de artículos acerca de modificaciones, tunning y mejoras que podemos realizar a nuestro equipo Canaima (del proyecto Canaima-Educativo).

Conocemos como “Canaimita” al equipo Intel Classmate Magallanes que el Estado Venezolano distribuye con el proyecto Canaima-Educativo:

Canaima Magallanes

Su configuración:

  • 1 Gb de RAM
  • Microprocesador (CPU) intel Atom (desde N270 hasta N465)
  • Disco duro de 160 Gb
  • Tarjeta de red alámbrica e Inalámbrica

Advertencia: Algunas modificaciones requieren amplios conocimientos de GNU/Linux y/o de desarmado y ensamblaje de hardware, este blog no se hace responsable si por impericia o no seguir las instrucciones adecuadamente, termina dañando el equipo.

El tiraje de artículos acerca de “Hacking Canaimita” girará en torno a todas las posibilidades de ampliación, tunning, accesorios y otras mejoras que podrán realizar los padres (o sus hijos, como aprendizaje, siempre con la supervisión de sus padres y/o representantes) a las computadoras del proyecto Canaima-Educativo.

Y claro, este tipo de artículos solo es posible por la colaboración y el compartir que existe gracias al conocimiento libre; si deseas colaborar para que siga contribuyendo puedes dar una donación a través de paypal, mis experimentos te lo agradecerán.

Espero que todos aprovechen y “Happy Hacking Canaimita!” …

… Y el perro se echó la miada …

“… y que hay que espantar el perro, antes que se eche la miada” …
Abre-brecha – Alí Primera

Me ha asombrado la política de adquisiciones de equipos y tecnología del Estado Venezolano, en un típico arranque de genialidad se les ocurre ahora hacer “misiones apresuradas y riesgosas” y comprar el primer hardware que cualquier empresa (transnacional, eso ya es obvio) cotice, con una única condición (claro que tácita), no debe funcionar en software libre …

En un proceso de legitimación semejante a solicitar a los traficantes de drogas que le logren sacar todos los alcaloides y sustancias nocivas a la cocaína para poderla distribuir al público en general; es después que el hardware ha sido adquirido, que las instituciones del Estado le solicitan a entes como el CNTI, CANTV o a personas de la comunidad del Software Libre en Venezuela que los hagan funcionar en software libre …

¿Por qué no lo solicitan antes?, ¿durante el pliegue de requerimientos?, ¿piden asesoría a las comunidades de SL que hacen vida en el país o a expertos internacionales (si quieren) al respecto? … no, piden ayuda ya después que el mal (y la compra) están hechos …

Simplemente patético … pero veamos algunos ejemplos …

La huella privativa …

 Los sistemas de identificación Biométrica no son algo (como muchos especulan) que no funcionan en GNU/Linux, al contrario, hay varios proyectos como libfprint o BioPod; el único problema es que este mercado siempre se ha regido por el “secreto industrial” y cada empresa estaba acostumbrada a hacer el cómputo de minutiae como le daba la gana; gracias a movimientos como la estandarización de las reglas alrededor de la bioAPI, muchas cosas que han normalizado y pues mucho del hardware puede ya funcionar perfectamente bajo Linux, salvo ciertas excepciones.

De todo el hardware (incluso los de precisión forense >512dpi como los fabricados por APC o Authentec) que existe en el planeta, ¿cuál compró el CNE?, pues ¿no es obvio?, compró el equipo Crossmatch Verifier 300 LC2, el único del fabricante que no funcionaba en GNU/Linux utilizando las APIs de BioAPI o de Verifinger, ¿entonces?

Lo más triste de todo el caso es que después de una millonaria compra de equipos, para “legitimar” su intención de usar SL, hacen uso de instituciones como el CENIT para “pedirles el favor” de hacer funcionar este equipo en Software Libre … y luego que lo hagamos funcionar, vendrá el CNE y nos dirá “ya no es necesario, hemos gastado 45 millones de dólares en unas NUEVAS captahuellas con RFID que tampoco funcionan en SL, o de funcionar, no nos toca a nosotros averiguarlo” …

y el perro se vuelve a echar la meada …

La ubicación privativa …

La gente de Agencia Bolivariana de Noticias muestra las fotos de los equipos GPS utilizados para el registro de la misión Vivienda:

Son equipos Intermec CN3, con un flamante Windows Mobile 6 en su interior.

Luego, la discusión se centra alrededor de “bueno, hubo una licitación de emergencia, 2 meses nada más para hacer la requisición y este equipo cumplía con todos los requisitos”, es decir, tuvieron 2 meses para decidir y el único GPS “rugged” (diseño industrial resistente a golpes) que tuviera GSM y corriera un navegador, era, según el Ministerio de Habitat y el MCTI, estos Intermec CN3 con Windows …

Sin embargo, en una búsqueda de apenas 30 segundos con las palabras claves en Google “+GPS +rugged +handheld +GSM “Linux | Android” ” me devolvió una lista con cientos de equipos industriales que corren Android, maemo o alguna otra versión de Linux adentro, la mayoría de ellos comparte características con el Intermec CN3 (que a final de cuentas es un computador de bolsillo con Wifi, GSM y/o CDMA y un navegador); me llamó la atención mucho el Getac, muy semejante al Intermec CN3, que aunque corre Windows Mobile, su CPU strong ARM le permite ejecutar Linux Maemo perfectamente (y hay guías de como hacerlo en Internet); también está el Bluebird Pidion que corre Android 2.1 y tiene lector de código de barras y RFID con Wifi abgn y Bluetooth, GPS y cámara de 2 MP …

Deberían echar un vistazo acá > http://www.sdgsystems.com/index.php?option=com_content&view=article&id=149&Itemid=73

Claro, me imagino que no es negocio para nadie comprar un equipo con Android 2.1 que cuesta unos 1000 US$ menos que la adquisión hecha por el Ministerio de Ciencia y Tecnología …

Y es más que obvio, para “legitimar ante la ley y el decreto 3390” la compra, buscarán a personas de la comunidad de Software libre para hacer funcionar los Intermec CN3 en Software Libre …

Como siempre, después que el perro se echó la meada …

La identificación privativa …

El SAIME ha indicado que para finales de este año estaremos utilizando la nueva cédula electrónica; esta cédula comparte las mismas características de tarjetas bancarias de Chip como las del Banco Mercantil, utilizan una tecnología diseñada por la empresa Holandesa GEMALTO pero con despliegue de ALBET S.A de Cuba (¿no había venezolanos que supieran crear una cédula con chips de 72K?, ¿acaso ya los cubanos tienen cédulas electrónicas?), en este caso Venezuela le pagó a ALBET para que ALBET de intermediaria le pagara a GEMALTO y aunque la tecnología de Gemalto ofrece APIs de desarrollo en varios lenguajes y terminales económicos incluso corriendo GNU/Linux, ALBET ha escogido (como no hacerlo) Microsoft .NET como base de desarrollo, Oracle como backend de datos y terminales que corren Windows Mobile …

No conformes con el hecho que no somos soberanos tecnológicamente con este desarrollo, pues ni somos garantes de la tecnología y GEMALTO no ha hecho transferencia alguna (GEMALTO fué la empresa que demandó a HTC, Google y Samsung por violación de patentes, léase, es un Patent-Troll, léase de otro modo, no podremos “hackear” la tecnología para apropiarnos de ella, nos demandarán por violación de patentes), este proyecto lleva retrasado desde el 2008; y ya sin pena cambian la fecha de emisión nacional cada vez que quieren, o cada vez que los cubanos se retrasan (sírvase a hacer revisión a través de aporrea, vea como se dijo que tendríamos cédula electrónica para el primer trimestre del 2008, luego para finales del 2008, para enero de 2009, para inicios de 2010, para marzo de 2010, para Junio de 2010, para noviembre de 2010, para enero de 2011, para el primer trimestre del 2011, para el segundo trimestre del 2011 y como ya este terminó, ahora juran que estará lista *al menos* para las elecciones del 2012).

Si hubieramos mandado a unos venezolanos a un post-grado de 3 años sobre criptografía y técnicas de chip smart-cards seguros en el extranjero (ejemplo: open Smart card project, proyecto libre de tecnologías de chips smart-card seguros) no hubieramos esperado 5 años para tener una cédula electrónica …

Y no estaríamos meados de perro …

La  x … privativa …

Yo ya poco a poco y tristemente me voy desligando de estas luchas políticas en contra de una estructura burocrática llena de compras ilícitas, comisiones, gastos de representación, transnacionales y muchísimo software privativo, inicialmente parecía que le hacíamos un bien a la nación al intentar hacer funcionar en software libre algo que el gobierno había adquirido, pero entonces siempre les serviremos como parte del juego, compran algo que es ilegítimo y viola nuestros decretos y leyes nacionales, y vienen los “tontos útiles” de la comunidad de software libre a tratar de enmendar el error y remendar capote tratando con las uñas de hacer funcionar dichos equipos (ah!, porque además de eso, a ninguno nos pagan por esas investigaciones nocturnas alrededor de miles de foros y código fuente para hacer funcionar esos aparatos) …

Parecía chévere al momento de ver un capta-huellas CrossMatch y como unos locos tratando de hacer que libfprint + SANE pudieran encender el aparato y hacerlo funcionar, podría parecer chévere agarrar un Intermec CN3 y montarle Maemo y hacer correr la aplicación de captura de datos de la Misión Vivienda desde allí, pero ¿qué estaríamos haciendo?, legitimando esas compras subterfugias, camufladas alrededor de convenios internacionales con empresas como ALBET que ganan 245 millones de dólares al año (presentenme una EPS Venezolana que gane lo mismo teniendo como único cliente al Estado Venezolano), estaríamos “poniendo de lado y en segundo plano” el requisito de que cuando el Estado Venezolano adquiera algo, funcione en software libre, porque dirán “no importa si no funciona, hay una pila de geeks fanáticos que si les das uno, lo harán funcionar, cumplimos con la ley, y todos acá nos llevamos una buena tajada de comisiones” …

Que otro sirva de “tonto útil”,  yo ya no lo seré más … allá quien quiera andar *meado* de perro …

Canaima/Trisquel vs. Debian: Distribuciones para usuario final

Estan son ideas aisladas que logré hilvanar luego de mi participación en el “Dia Debian Barquisimeto” y es una reflexión sobre hacia donde debemos llevar a los nuevos usuarios y a la distribución nacional Canaima …

Puede que hiera algunas susceptibilidades, pero considero que es discusión necesaria …

Mi concepto de usuario final …

¿A quién considero yo un “usuario final”?, es aquella persona que utiliza el computador como una herramienta, lo ayuda en sus quehaceres y le permite navegar en Internet, conectarse a redes sociales y por qué no, jugar a la granjita …

Un usuario final usa la computadora como quien usa un celular, un microondas o un vehículo, el 80% de las personas que conducen no tienen por qué saber mecánica para poder manejar … hay quien te dirá que “es necesario saber al menos lo básico”, pero todos sabemos que no lo es …

Bueno, claro, te quedarás varado en espera de una grua si no sabes siquiera lo más básico, pero comprendamos que esto no será la mayor parte del tiempo …

Por el contrario, nosotros vivimos de esto (al menos yo) y pues es lógico que necesitamos saber muchisimo más que el resto de los usuarios de computadoras …

¿Qué es GNU/Linux Debian?

Debian es una meta-distribución, como tal, es genérica y trae todo lo que necesitas para convertirla en TODO lo que necesitas, desde servidores a dispositivos imbuidos, pasando por teléfonos y como no, estaciones de trabajo y escritorio …

¿Puede ser Debian (o una distribución basada nativamente en Debian sin personalizaciones) una distribución apta para el usuario final nombrado líneas más arriba? …

Y mi respuesta es … NO!

¿Qué diferencias hay?

Notemos algunas diferencias que a la primera se daría cuenta cualquier persona:

  • Ubuntu ya trae todo el firmware privativo instalado para *casi* cualquier dispositivo, activar tu inalámbrica pasa por simplemente poner en *on* el switch de la misma.
  • En Trisquel no vendrán esos binarios, así que cierto hardware no funcionará, pero en su defecto, trae un kernel libre mucho más ligero (hay menos mutexes y paradas del kernel esperando la inicialización de binarios externos) que además, trae el parche (por defecto) de Ingo Molnar para respuesta “realtime” preemptiva, esto nos da una sensación de uso más “suave” del equipo y una mejor respuesta ante aplicaciones críticas de usuario (edición de audio o de video, 3D, blender y otras aplicaciones).
  • Ubuntu *por defecto* tarda unos 15 a 25 segundos en iniciar, un Debian Squeeze *por defecto* tarda unos 25 a 30 segundos en iniciar (en mi hardware, sin tunning), Trisquel tarda unos increíbles 12 segundos en iniciar.
  • Debian trae un kernel compilado para arquitectura i386 (si usan amd64, al menos podrán contar con un kernel x86_64) con una velocidad de reloj de latencia de 300Mhz, una respuesta pre-emptiva de 250Mhz, con la mayoría del tiempo de proceso dedicado a los servicios y no al espacio de usuario.
  • Ubuntu trae un kernel “personalizado” con respuesta de 700Mhz y una latencia pre-emptiva de 1000Mhz.
  • Trisquel trae un kernel “dietético” sin binarios privativos que deban ser inicializados y ralentizando el kernel, con una velocidad de 1000Mhz y tickless (respuesta pre-emptiva en tiempo real, menor a 100 ms).

¿Por qué basar una distro en Debian?

Una distribución de GNU/Linux debería estar basada en Debian siempre y cuando se vayan a tener varios “targets” o destinatarios y tipos de usuarios, la gente de gNewSense cambió de Ubuntu a Debian porque entre otras cosas sugirieron en la lista de discusión la “posibilidad” de crear proyectos como *servidores libres* (gNewSense con configuración óptima para servidores pero usando un kernel GNU Linux-Libre).

Sin embargo, basar una distro en Debian cuando su destino final es “el usuario final” (como Canaima Linux) tiene como consecuencia un trabajo “mayor” de los organizadores pues estos tendrán que poner a punto las configuraciones de distintos paquetes de software (para que el usuario no tenga que unir *a mano* el PulseAudio con el Jack o tenga que configurar a *al pelo* su tarjeta de video).

Si al final, tomamos los paquetes y el núcleo de Debian y le hacemos un “maquillaje estético” a la distribución, le estaremos instalando un Servidor de archivos (y no una estación de trabajo óptimizada) al usuario, con las consecuencias de lentitud, nivel de respuesta y adaptación del usuario …

Y ni hablar cuando esa distribución se base en la versión *estable* de GNU/Linux Debian.

Pero, ¿Por qué no puede configurarla a su gusto el usuario?

Si, yo uso Debian, anteriormente usaba en el mismo entorno y partición una versión “desktop” con kernel personalizado (vanilla-flavor) para “navegar y jugar” y en esa misma partición, montaba Xen-Linux-System y toda mi plataforma para trabajar (VMs con postgreSQL, mySQL y MariaDB, Samba, etc); solo diferenciados por el arranque del GRUB, ahora las configuraciones de tunning y *performance* para una *óptima* versión escritorio y una *óptima* versión de servidor son tan distintas que llegué a la conclusión que tener 2 entornos completamente separados, un Debian para trabajar y un GNU Trisquel para jugar, navegar y transmitir por RadioGNU era algo necesario.

Claro, yo en mi GNU/Linux Debian tengo aún esa “versión optimizada para escritorio” donde a pelo y configurando “a lo agrícola y artesanal” he modificado:

  • Modificado el GRUB para una larga lista de opciones de optimización
  • Fijar los fallos de asignación MTRR para una mejor respuesta del video
  • Cambios para usar nativamente la GPU y aceleración openGL en todo el entorno de escritorio y video
  • Modificaciones en los parámetros de HDPARM, para sacarle el máximo provecho a mi disco SATA-2
  • Apagar la acústica del disco duro, no me importa que suene, pero va más rápido
  • Modificado las variables de sysctl para que gestione mejor la memoria de userspace.
  • Uso y configuración de preload en Debian para una carga optimizada de aplicaciones (preload y prefetch vienen ya configurados por defecto en Ubuntu y Trisquel)
  • He cambiado el comportamiento en sysctl del “swappiness” ya que con 4Gb de RAM en un entorno de escritorio, es innecesario que Linux use Swap.
  • He desactivado cosas que no uso (como IPv6) para mejorar la velocidad en general de la red.
  • Re-optimización de módulos del kernel (como mi inalámbrica, para que soporte 150Mbps, ya que tengo un Access Point Wireless-N).
  • He recompilado algunas aplicaciones usando directivas de pre-compilación para mi arquitectura específica (-march=nonona, la arquitectura de 64-bits de Intel, si quieres 32-bits usas prescott) y muchas las compilo con “-O3” (máximo performance).
  • Uso de aceleración GL y no *por software* en las aplicaciones de video (que lo soportan), esto ahorra CPU una barbaridad.
  • Uso de un kernel RT (realtime), he parcheado (Ingo Molnar patch) un kernel vainilla 2.6.33-7 y he obtenido rendimiento realtime, con respuestas menores a 100 ms en las actividades directamente dedicadas al Kernel, incluso he podido iniciar IDJC en modo “real time” sin obtener XRUNS, claro, eso en Trisquel ya viene “por defecto” y no tuve que parchear ni compilar Kernel.

La conclusión a esta larga lista de cambios, es que mi estación de trabajo (donde programo, etc) GNU/Linux Debian es tanto o más eficiente que un Ubuntu o Trisquel corriendo en esta misma PC.

Claro, la cantidad de cambios y personalizaciones que tuve que hacer para llegar al *punto óptimo* de ejecución de mi portátil raya en las personalizaciones de sistemas como Linux Arch o Gentoo Linux.

A la vista del “eye-candy”

Mucho del escritorio GNU/Linux, sobre todo KDE4+plasma o Gnome+Compiz, vende *gracias* a su capacidad de asombrar con el “eye-candy”; pero como afirmo allá arriba, no es lo mismo mi escritorio, donde con varios “tweaks” he hecho que el sistema de video use la GPU y la aceleración por hardware del video (y no el “indirect-rendering” que usa emulación de aceleración 3D por software) al de un usuario con un “Canaima básico” usando intel-vesa con framebuffer por software que pensará que su computador es un “pote” inútil o que Linux es “dificil” porque para lograr esos *tweaks* requiere conocer de física nuclear y matemáticas avanzadas y que por tanto “esa cosa difícil del Linux” no es para él.

¿Y eso tiene algo de malo?

Para un usuario final si lo tiene, no podemos pretender que todo el mundo sepa mecánica para evitar las congestiones por gruas, tampoco podemos pretender que la gente monte un GNU/Linux Debian (o un Canaima: Debian Lenny Edition) y se la pase *paseando* todos los días por foros o listas de correo de soporte preguntando una y otra vez como se configura el modem 3G de movistar para conectarse a Internet en Canaima Linux.

Es injusto (por partida doble) que la gente no cuente (son simples scripts que se pueden correr en conjunto con los scripts *laptop-detect* que permitirían personalizar el hardware de manera automática) con equipos “óptimos” para su día a día; pero que además, tengan que enfrentar listas de correo de soporte para responder a sus problemas, una y otra y otra vez, para llenar egos inflados de Debianitas Pro-Canaima que quieren siempre responder a esas preguntas para “demostrar que saben” …

Al final de cuentas, una persona ve un GNU/Linux Debian como el mio y lo compara con su Canaima y siempre terminan llenos de frustración por la imposibilidad de “enchufar su modem 3G” y hacerlo funcionar con un simple “asistente gráfico” y en vez de recibir esas mejoras (o scripts automáticos que lo ayuden en su personalización) recibe respuestas en listas de correo donde le piden que abra una consola y utilice el comando wvdial.

Un usuario final, ni siquiera sabrá para qué le sirve una consola.

A %d blogueros les gusta esto: