MarioDebian, mi devlog

Bitácora de un desarrollador newbie.

Nautilus scripts :: Configuración de Pantalla

No será por tener mucho tiempo libre pero me parecía útil programarlo y más compartirlo:

 

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
#

import nautilus
import subprocess
import os

# put or comment Display configurators here.
# FORMAT
#   [ (string)command  ,        (boolean)need gksu  ]
HELPERS=[
    ["/usr/bin/displayconfig-gtk",              True],
    ["/usr/bin/nvidia-settings",                False],
    ["/usr/bin/gnome-display-properties",       False],
    ["/usr/bin/grandr",                         False],
]

class OpenDisplaySettings(nautilus.MenuProvider):
    def __init__(self):
        pass

    def open_window(self, *args):
        cmd=[]
        for helper in HELPERS:
            if os.path.exists(helper[0]):
                if helper[1]: cmd.append("/usr/bin/gksu")
                cmd.append(helper[0])
                subprocess.Popen(cmd,
                                shell=False,
                                bufsize=0,
                                stdout=subprocess.PIPE,
                                stderr=subprocess.STDOUT,
                                close_fds=True)
                return


    def get_background_items(self, window, _file):
        ICON="/usr/share/icons/gnome/16x16/devices/display.png"
       
        item = nautilus.MenuItem('NautilusPython::open-display-prop',
                                 'Configuración de pantalla',
                                 'Abrir configuración gráfica de pantalla')
        if not os.path.exists(ICON):
            ICON="gtk-dialog-warning"
        item.set_property('icon', ICON)
        item.connect('activate', self.open_window)
        return item,

Guardarlo como "open-display-prop.py" en el directorio ~/.nautilus/python-extensions/ (sino existe se crea)

¿Qué obtenemos?

 


Se pueden añadir más «helpers» o comentar alguno que no nos guste... los «helpers» se buscarán en órden, el segundo parámetro del helper es ver si necesita privilegios de root.

Para que funcione tenemos que tener instalado gksu y python-nautilus.





USBIP ya funciona

Hace un tiempo hablé un poco de refilón sobre USBIP, [USB/IP] un sistema que permite «mover» el punto de conexión de un dispositivo de una máquina a otra (por red) para por ejemplo conectarnos a un scaner, webcam o impresora remota...

Parece que se ha avanzado mucho en el proyecto y de hecho la parte que se ejecuta en el kernel está en el staging (algo como la cuarentena de nuevos drivers que entran al kernel antes de considerarse estables...) tanto es así que incluso las tools están en la cola NEW de Debian. Los paquetes que hice en su día no generaban libusbip así que habrá que tener cuidado cuando entren para no provocar conflictos.

Hoy me he descargado la última versión de las tools (0.1.7) y las fuentes del módulo de un kernel 2.6.28, lo he compilado en un 2.6.26-1-486 y parece que funciona Laughing

Ahora estoy haciendo pruebas con un terminal ligero sobre TCOS (recuerdo que ya teníamos soporte USBIP, aunque desactivado) y he conseguido pasar al servidor tanto una memoria USB (que se ha montado automáticamente Tongue out) como una captura de televisión analógica.

Para que esto sea útil en TCOS me surgen algunos problemas...

  • Tengo que hacer un nuevo interfaz de usuario para ver que dispositivos USB hay en su terminal y conectarlos al servidor...
  • lo que me lleva a modificar tcos-devices-ng o crear un programa nuevo...
  • y lo más complicado, dar permisos exclusivos sólo a ese usuario cuando el dispositivo se conecte al servidor. (jugar con bits SUID y ver que dispositivos /dev se crean al cargar el driver del dispositivo en el servidor)
  • Este nuevo driver puede provocar comportamientos no demasiado buenos en el servidor ¿que pasa si desenchufamos el terminal sin hacer «dettach»?

Para empezar he creado un pequeño parche para que la salida de «bin_driver --list» se pueda leer más facilmente por un script y poderlo mandar por XMLRCP al servidor. No se si mandarselo al upstream para ver si al menos lo tiene en cuenta. Diferencias:

La que viene por defecto

sudo bind_driver --list

List USB devices
- busid 3-3 (04b4:6830)
3-3:1.0 -> usb-storage
- busid 1-2 (147e:2016)
1-2:1.0 -> none
- busid 7-1 (05e3:0608)
7-1:1.0 -> hub
- busid 7-1.2 (04fc:0c15)
7-1.2:1.0 -> usb-storage
- busid 7-1.4 (05e3:0608)
7-1.4:1.0 -> hub
- busid 4-2 (0573:4d28)
4-2:1.0 -> usbvision
- busid 7-1.4.4 (046d:c062)
7-1.4.4:1.0 -> usbhid

La que añade el parche

sudo bind_driver --list2
#busid=3-3#usbid=04b4:6830#3-3:1.0=usb-storage#
#busid=1-2#usbid=147e:2016#1-2:1.0=none#
#busid=7-1#usbid=05e3:0608#7-1:1.0=hub#
#busid=7-1.2#usbid=04fc:0c15#7-1.2:1.0=usb-storage#
#busid=7-1.4#usbid=05e3:0608#7-1.4:1.0=hub#
#busid=4-2#usbid=0573:4d28#4-2:1.0=usbvision#
#busid=7-1.4.4#usbid=046d:c062#7-1.4.4:1.0=usbhid#

De momento no hay mucho más que decir, faltan muchas pruebas para que esto sea funcional.

UPDATE (20090126):

Parche aceptado en el proyecto y posiblemente sea co-mantenedor del paquete en Debian





Mí no entender

Esto es muy curioso:

$ time sha512sum debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af  debian-testing-amd64-netinst.iso

real    0m8.273s
user    0m7.648s
sys    0m0.532s

 

$ time sha512.py debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af debian-testing-amd64-netinst.iso

real    0m1.731s
user    0m1.428s
sys    0m0.292s

 

Este es sha512.py:

#!/usr/bin/env python
import sys
import hashlib
f=open(sys.argv[1], 'rb')
data=f.read()
f.close()
print "%s %s" %(hashlib.sha512(data).hexdigest(), sys.argv[1])

 

No es fruto del cacheado ni el azar,tengo un script que mide varias ejecuciones (en modo alterno) y en python es casi 5 veces más rápido.




Hace un año: Nuevo TcosMonitor2.0

TCOS Brasil

El grupo TCOS BRASIL, se está poniendo las pilas, después del manual que han escrito han hecho una breve reseña en Viva O Linux y ha despertado gran interés entre usuarios de LTSP en Brasil...

Por eso nos hemos puesto a hacer un LTSP5 vs TCOS, y hasta ahora esta es mi contribución:

TCOS es mejor que LTSP5 en:

  • LTSP5 usa NFS como root filesystem (opcionalmente SQUASHFS sobre NBD), TCOS descarga (tftp,http,nfs) la imagen squashfs y no necesita NFS cuando el terminal tiene más de $TCOS_MIN_RAM Mb (por defecto 38) de memoria. Si el servidor se cuelga o pierde la conectividad en LTSP5 todos los terminales sufren un kernel panic, con TCOS sólo hay que esperar a que el servidor se recupere.

  • Para terminales con menos de $TCOS_MIN_RAM TCOS arranca de la misma manera que LTSP5 (usando NFS) pero sin un chroot completo, sólo lo necesario.

  • El sistema de acceso a dispositivos, aunque los dos usan LTSPFS (filesystem sobre Xorg + FUSE) en TCOS se ha mejorado con una aplicación gráfica llamada TcosDevicesNG , en LTSP5 los dispositivos se montan de manera automática y el desmontaje es complicado con TCOS es muy sencillo.

  • LTSP5 usa como punto de montaje "/media" mientras en TCOS se usa el Escritorio del usuario, así nadie puede acceder al contenido del dispositivo (ni siquiera root)

  • LTSP5 sólo soporta disquetes, memorias USB y CDROM datos, TCOS además de esos, soporta particiones de disco duro (incluido NTFS), CDROM-USB, discos Firewire, CDAUDIO, etc...

  • LSTP5 necesita hacer un chroot de un sistema casi completo para el terminal, TCOS sólo copia los binarios y librerías necesarios en la imagen comprimida (consume menos memoria)

  • LTSP5 necesita conexión a internet para hacer la imagen de arranque (o repositorio de paquetes deb local/CDROM/DVD), TCOS usa los binarios del servidor. LTSP5 tarda más de 15 minutos, TCOS 15 segundos.

  • LTSP5 no permite personalizar la imagen de arranque, con TCOS se puede personalizar que queremos que incluya y que no.

  • LTSP5 tiene una herramienta muy simple de administración (Thin Client Manager) , TCOS la mejor (TcosMonitor). TcosMonitor también funciona con equipos instalados (no terminales ligeros) => tcos-standalone

  • LTSP5 tardó 2 años en usar PulseAudio, un sistema mejorado de sonido en red, TCOS lo usó desde el principio, esto significa que se apuesta más y se avanza antes en proyectos pequeños.

  • LTSP5 sólo permite conexiones XMDCP, TCOS, además, permite conexiones rDekstop (Windows Terminal Server), FreeNX, ssh+X y pronto XRDP.

  • TCOS usa XMLRPC entre el servidor y el terminal para intercambiar información, lo que hace muy sencillo programar pequeños programas o plugins para hacer tareas sencillas. Ejemplo: PAM-USB


  • TCOS tiene una pequeña aplicación para controlar el nivel de los canales de audio del terminal (mediante llamadas XMLRPC), en LTSP5 sólo se puede modificar los canales Master y PCM.


LTSP5 es mejor que TCOS:

  • Usa conexión gráfica segura (SSH + Xorg + LDM)
  • Es más conocido ;) 
  • TCOS no tiene demasiada documentación (estamos en ello)

 

Soy bastante objetivo, pero si no lo soy yo, ¿quién lo va a ser?





Mi regalo de reyes, nuevo interfaz de TcosDevicesNG

Hacer que algo simple y poco práctico:

 

 

Pase a ser algo como esto:

 

 

A falta de pulir un poco como se coloca el texto en la columna central creo que el tema ha mejorado bastante...

Disponible desde ya en el SVN.

Tengo que reconocer que me he inspirado gráficamente en Ejecter, aunque sólo en el aspecto, esto es una ventana gtk.Window() en modo popup y con detección de posición cada vez que aparece, de hecho el cambio para hacer que esto funcione sobre tcos-devices-ng.py es una sóla línea, y una nueva clase con los mismos métodos que la vieja.

Felices reyes y sed buenos Laughing




Hace un año: Nueva versión MaX 3.1

TCOS en OpenSuSe

No asustarse, no me he cambiado a lado oscuro...

Estoy subscrito a Linux Magacine desde hace dos años y ayer me dió por probar la nueva OpenSuSe 11.1, aprovechando que tenía el DVD de la 11.0 sólo tuve que instalar y actualizar... ¡Qué dificil es usar otra distribución cuando se está acostumbrado a Debian! 

TCOS nunca se ha portado a otras distribuciones que no sean Debian/Ubuntu o derivadas, por lo que tenía la oportunidad de probar el kernel 2.6.27, las Xorg nuevas 1.5 y un montón de novedades que debido a la próxima salida de Debian lenny todavía no han llegado a Debian.

OpenSuSe, aparentemente tiene un aspecto gráfico muy cuidado, un arranque gráfico donde «no se ven letras» y (con el escritorio KDE 4.1) bastante resultón... pero todo no es tan bonito... su gestor de paquetes «zypper» en modo texto no tiene nada que envidiar a apt, y faltan muchos (muchísimos) paquetes en OpenSuSe para que tenga la mitad que Debian. He aquí un mini HOWTO para instalar TCOS (ya aviso que no funciona del todo aún)

  1. Instalar un montón de paquetes "-devel": xorg, zlib, imlib, libjpej, libpng, giflib...
  2. Descargar y compilar los paquetes: libxmlrpc-c3, python-netifaces, python-dns, python-utmp, tinylogin (a la manera tradicional: ./configure -prefix=/usr; make; sudo make install) Para hacer esto no me he liado mucho, desde el orig.tar.gz de Debian sid se descomprime y se compila.
  3. Convertir initramfs-tools de deb a rpm con alien... (hay que editar /usr/sbin/mkinitramfs y decirle que busybox está en /usr/bin/busybox)
  4. Copiar /bin/busybox de Debian en OpenSuSe ya que este último no tiene ciertos applets que necesita TCOS (tftp, awk, etc..)
  5. Instalar atftp (con zypper) desactivar el cortafuegos o añadir la regla y reiniciar el servicio (sudo /sbin/service atftpd restart)
  6. Descargar el trunk del SVN de TCOS: svn co https://www.tcosproject.org/svn/tcos/trunk
  7. Compilar e instalar initramfs-tools-tcos (hay que instalar syslinux y crear a mano el enlace a pxelinux.0 en /var/lib/tcos/tftp)
  8. Compilar tcosmonitor y ejecutarlo desde el directorio SVN: python tcosmonitor.py --debug
TcosMonitor en OpenSuSe 11.1:

Terminal ligero arrancado kernel de OpenSuSe 2.6.27.7-9-pae:

El kernel carga pero se queda bloqueado en el arranque, sospecho que el udev de OpenSuSe y el de Debian son bastante diferentes como para no cargar de manera correcta, investigaré un poco más...me falta compilar klibc, igual este tiene la culpa.

Los que me conocen se preguntarán por qué enredo con OpenSuSe si no me gusta, pero todo tiene un motivo, con las Xorg 1.5 y ciertos parches es posible arrancar un servicio RDP (Terminal Server) y poder dar así soporte de sesiones que se suspendan sin perder el trabajo, muy recomendable el enlace: Connecting to Linux via RDP

Con algunos parches para saber la IP y nombre de usuario que hace login no sería demasiado dificil añadirlo como modulo en tcosxmlrpc y pam-usb-tcos

Resumiendo, OpenSuSe no está mal pero la encuentro con muchos fallos (sudo no tiene el PATH de root), KDE (knotify4) consume demasiada CPU y memoria, la actualización 11.0 => 11.1 desordenó el panel inferior y no se como mover los elementos sin borrarlos... VirtualBox no se acaba de llevar del todo bien con las guest-utils y el logo de SuSe (branding) se ve en más sitios de lo normal.

Una de las cosas de las que presumen es del servicio Build, pero mira que he leido páginas del wiki y aún no me entero como subir fuentes y compilarlos... los archivos spec tienen menor potencial que devscripts+debian/rules.





EloTouch en MaX 4.0

No suelo poner vídeos de youtube, pero este lo he hecho yo Laughing

Es un EloTouchComputer de 17", en el que he hecho funcionar la pantalla táctil y el lector de huellas en MaX 4.0 (Ubuntu Hardy)