Este post va a intentar ser breve y me parece que es bastante técnico, pero puede serle útil a más de uno.

Resulta que yo tengo una Impresora Multifunción Samsung SCX-4200, que tiene unos drivers (cerrados) para Linux [1]. Estos drivers sirven para imprimir y escanear, y si bien hoy en día Ubuntu se las arregla bárbaro para imprimir con los drivers libres de SpliX (¡instalación y configuración automágica!), queda pendiente aún el tema del escaneo.

Por algún motivo al utilizar el scanner (vía USB) la transferencia se caía, y resultó ser que la comunicación Scanner <-> USB 2.0 no funciona, como ya documenté en este mismo blog hace unos años (con la impresión no hay problemas); y no importa la mother, chip o cosa que haya en el medio (lo probé con diferentes equipos). O es esta printer en particular (mucha mala suerte), o es algo del firmware que me tocó en gracia, o… shit happens.

En fin, en versiones anteriores de Ubuntu anteriores a 9.10, para forzar una comunicación USB 1.1 se solucionaba con un “sudo rmmod ehci_hcd”, porque el módulo USB 2.0 (ehci_hcd) era justamente, un módulo que se cargaba dinámicamente. Pero a partir de Ubuntu 9.10 (¿o antes?) este módulo fue incluido en el kernel (estáticamente), con lo cual a priori no tenía manera sencilla de forzar una comunicación USB 1.1 con algún dispositivo (que no sea cambiar el parámetro correspondiente en el BIOS), ya que no es posible descargar un módulo estático del kernel (más info acá).

Me puse a buscar, y encontré una solución. Para simular la “descarga” el módulo es necesario posicionarse en el directorio /sys/bus/pci/drivers/ehci_hcd y pasarle al archivo “unbind” qué hub USB “unbindear” (¿”desrelacionar”?); los hubs USB se pueden ver con un lsusb -v, y los que van a aparecer en el directorio mencionado son los de “Full Speed”, o sea, los de USB 2.0 [2] .

Si tu PC soporta USB 2.0 (y por ende tenés este problema, je), al menos uno hay, que corresponde al Hub de la motherboard. En mi caso hay dos, pero para no andar especulando (y porque quiero que el scanner funcione sin averiguar a cuál de los dos hub está conectado en particular), “unbindeo”/”desrelaciono”/”desenlazo” (?) ambos hubs:

marcelo@marcelo-laptop:~$ sudo -i
[sudo] password for marcelo:
root@marcelo-laptop:~# cd /sys/bus/pci/drivers/ehci_hcd/
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# ls -l
total 0
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 0000:00:1a.7 -> ../../../../devices/pci0000:00/0000:00:1a.7
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 0000:00:1d.7 -> ../../../../devices/pci0000:00/0000:00:1d.7
--w------- 1 root root 4096 2010-03-19 14:12 bind
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 module -> ../../../../module/ehci_hcd
--w------- 1 root root 4096 2010-03-19 14:12 new_id
--w------- 1 root root 4096 2010-03-19 14:12 remove_id
--w------- 1 root root 4096 2010-03-19 14:12 uevent
--w------- 1 root root 4096 2010-03-19 14:12 unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# echo -n 0000\:00\:1a.7 > unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# echo -n 0000\:00\:1d.7 > unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# ls -l
total 0
--w------- 1 root root 4096 2010-03-19 14:12 bind
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 module -> ../../../../module/ehci_hcd
--w------- 1 root root 4096 2010-03-19 14:12 new_id
--w------- 1 root root 4096 2010-03-19 14:12 remove_id
--w------- 1 root root 4096 2010-03-19 14:12 uevent
--w------- 1 root root 4096 2010-03-19 14:21 unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd#

[...]
[64720.180444] ehci_hcd 0000:00:1a.7: remove, state 4
[64720.180464] usb usb1: USB disconnect, address 1
[64720.184731] ehci_hcd 0000:00:1a.7: USB bus 1 deregistered
[64720.184838] ehci_hcd 0000:00:1a.7: PCI INT C disabled
[64730.610396] ehci_hcd 0000:00:1d.7: remove, state 1
[64730.610417] usb usb2: USB disconnect, address 1
[64730.610422] usb 2-4: USB disconnect, address 3
[64730.684860] ehci_hcd 0000:00:1d.7: USB bus 2 deregistered
[64730.684980] ehci_hcd 0000:00:1d.7: PCI INT A disabled
[64731.070210] usb 6-2: new full speed USB device using uhci_hcd and address 5
[64731.254158] usb 6-2: configuration #1 chosen from 1 choice
[64731.259814] uvcvideo: Found UVC 1.00 device FO13FF-50 PC-CAM (05c8:0100)
[64731.273207] input: FO13FF-50 PC-CAM as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.0/input/input11
[...]

En mi caso no tenía conectada la impresora, pero sirve el ejemplo de todas maneras ver cómo la webcam es reconocida por uhci_hcd (USB 1.1). Para volver atrás, supongo que hay que hacer lo mismo pero con bind (no lo probé, sólo me parece lógico…), aunque yo reinicio la máquina para no complicarme.

Esto es fácil de meter en un script, y espero que le sirva a alguien (me llevó un buen rato encontrarlo).

Saludos

Marcelo

[...]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.31-20-generic ehci_hcd
  iProduct                2 EHCI Host Controller
  iSerial                 1 0000:00:1d.7
  bNumConfigurations      1
[...]

Hace un rato que estoy leyendo sobre virtualización, pero no de CPU, sino de I/O (otro más acá)… muy interesante, me aclaró algunas dudas que tenía, dado que últimamente al configurar este tipo de software se me confundían las cosas

Resulta que a nivel de I/O tenemos algo parecido a la virtualización al nivel de CPU: emulación, paravirtualización y ejecución “directa”, por llamarlo de alguna manera. Sugiero leer el artículo para más detalles, pero sólo quiero agregar que recién estamos en la etapa de paravirtualización, y que (en buena hora) Intel y AMD agregaron unidades IOMMU en sus últimos diseños para poder asignar dispositivos directamente a una (o más, según el caso) VM, evitando el Hypervisor y ahorrando ciclos de CPU. Pero esto parece estar verde aún.

Virtio vendría a ser como una serie de drivers de paravirtualización de I/O. Lo bueno es que no sabía que VirtualBox soportaba para las interfaces de red, algo que al parecer (y de esta manera) intenta ser un estándar  (net y block devices por ahora),  ya que tiene una API de comunicación Host <–> Guest abierta, independiente y en paralelo a la propuesta de KVM como hypervisor.

Luego de ver un poco todo esto, me puse  a configurarlo en una VM con WinXP, le instalé estos drivers y ya estoy usando menos CPU para la parte de red en mi guest

Acá se ve un poco la mejora a nivel de tráfico de red *real* que hay usando I/O paravirtualizado:

http://www.linux-kvm.org/page/Using_VirtIO_NIC

En fin, esperemos que todo esto mejore más aún. KVM ya soporta virtio para dispositivos de almacenamiento, además de los de red (linkeo la instalación de los drivers de Windows porque lógicamente Linux tiene estas baterías ya incluídas, je).

Saludos

Para los que no están enterados, Streaming Replication es la nueva gran característica de PostgreSQL 9.0 (ex-8.5), todavía en desarrollo. Estoy muy contento por la noticia, realmente era algo pendiente ver integrado algo de esto en PostgreSQL mismo (ya que hay productos y/o versiones modificadas para hacer esto, pero no es lo mismo que “el original”, claro está ) y lo hace cada vez más adecuado para evitar (o al menos dejar a uno la opción de) utilizar motores de bases de datos muy buenas pero caras y propietarias (Oracle) o lamentablemente en problemas políticos/de gestión (MySQL).

Básicamente SR permite que exista un proceso “sender”en el master que envíe a procesos “receiver” en el/los nodos secundarios porciones de WAL (Write-Ahead Log), es decir, de transacciones “comiteadas” recientemente. Antes (PostgreSQL 8.4 y anteriores) los WAL se podían archivar a otro nodo una vez se hayan completado 16 MB de transacciones (por defecto), con lo cual si se tenía una BD que “cambie poco”, 16 MB podían representar un lapso de tiempo físico importante. A partir de ahora, el lapso de tiempo se reduce a unos pocos segundos de diferencia en el master y la/las réplicas (dependiendo el enlace, la carga del master, etc.), con lo cual es una mejora substancial en las capacidades y posibilidades de PostgreSQL.

Hay que resaltar que por ahora este proceso es asincrónico, y aunque hay usuarios que pueden necesitar replicación sincrónica, cada esquema tiene sus ventajas y desventajas, y sin lugar a dudas esta primera versión de momento atiende muchísimas necesidades.  Combinado con otra de las novedades de 9.0 que es la posibilidad de usar un nodo secundario (recibiendo WALs mediante SR o el método tradicional) como Sólo Lectura (característica llamada “Hot Standby“), 9.0 da un paso muy adelante con respecto a versiones anteriores.

Para más adelante (y planificado para hacerse, ojo) quedó la opción de Straming Replication sincrónico y obtener más y mejor info del proceso de replicación (lag, estadísticas, etc.). Otro punto flojo, que espero se resuelva mejor (o con un mecanismo estándar), es que uno tiene que scriptear a mano el Failover, es decir, el proceso de recuperación (heartbeat es una herramienta genérica para este tipo de cosas).

Dejo algunos links relacionados con más info y demostraciones:
http://www.depesz.com/index.php/2010/02/01/waiting-for-9-0-streaming-replication/
http://www.depesz.com/index.php/2010/01/08/waiting-for-8-5-hot-standby/

¡Saludos!
Marcelo

No, no me equivoqué de número de versión.

Si bien PostgreSQL 8.4 ya salió y tiene unas cuantas novedades, quisiera hacerme eco de lo que está en la cola de parches a aprobar para integrar la nueva rama de desarrollo de PostgreSQL 8.5. Esta lista está compuesta por cosas como:

• GRANT ON ALL IN schema: Una manera de otorgar permisos a todos los objetos de un esquema.
• Machine-readable explain output v2: Salidas del comando EXPLAIN fácilemente legibles por otro software, es decir, fácilmente parseables para su procesamiento. El comando explain aceptaría como segundo parámetro el formato (además de los actuales) la keyword FORMAT, quedando así: EXPLAIN FORMAT [TEXT | JSON | XML]. Está bueno porque abre la puerta del desarrollo de herramientas de auto-tunning, basado en reglas estilo Sistema Experto.
• SE-PostgreSQL: Security-Enhanced PostgreSQL, una mejora sustancial en la seguridad del SGBD y en el nivel de detalles del sistema de privilegios.
• Replicación Sincrónica: Si algo le faltaba a PostgreSQL es una manera de replicación sincrónica integrada en el gestor. Esperemos que esto sí entre, aunque está bastante discutido el asunto porque es un cambio relativamente “gordo” en los internals del código, pero por lo que leí de estas discusiones parece haber consenso en llevarlo adelante e implementarlo. Por mi parte… ¡lo necesito ya!
• \dL para listas los lenguajes utilizados en psql: Es una nueva característica en psql, la de poder listar los lenguajes instalados en la base de datos (plpythonu, plpgsql, etc.).
• Estadísticas de esperas por bloqueos: La idea es poder tener un historial de los bloqueos sufridos por los clientes en la BD, para poder detectar problemas y saber bien qué pasa en todo momento.

Bueno, de más está decir que no hay ninguna garantía de que todo esto sea finalmente integrado en 8.5, sino que se está evaluando al mejor estilo Software Libre™: peer-review, discusión de estrategias del proyecto, consenso en la comunidad de desarrolladores y posterior aceptación/pedido de mejoras/rechazo. Así que veremos cómo sigue.

Saludos!
Marcelo

Navegando por ahí, me acabo de encontrar con dos herramientas interesantes, que me interesa compartir…

Ninja

La primera llamada Ninja, que viene a ser algo así (traducido de su página web):

Ninja es un sistema de detección y prevención de escaladas de privilegios para GNU/Linux. Mientras está corriendo, monitorea las actividades de los procesos locales por un lado, y de los procesos corriendo como root por el otro. Si un proceso lanza a otro nuevo con UID o GID cero (root), Ninja va a loguear la información necesaria acerca del mismo, y opcionalmente lo puede finalizar si fue creado por un usuario (es decir, un proceso de un usuario) sin autorización.

En mi opinión, si bien hay herramientas más complejas para hacer este tipo de cosas con servicios en producción, parece un buen complemento cuando se necesita algo más sencillo y no tan crítico, como dar acceso de terminal o X  a usuarios finales. Acá hay un post sobre cómo instalarlo en Ubuntu.

KSplice

La otra herramienta, promete algo que sería la salvación para todos los sysadmins: aplicar actualizaciones al núcleo de un SO sin reiniciar el equipo, “al vuelo”, en forma transparente. Esta herramienta de salvación para todos nosotros se llama KSplice, es abierta, y fue tema de investigación y desarrollo por gente del MIT. Si realmente anda bien y funciona, sólo falta que salga en Slashdot (no creo que tarde mucho…).

KSplice funciona creando actualizaciones (aplicables instantáneamente) para el kernel en ejecución. Estas actualizaciones son igual de efectivas que las estándar (supongamos las que provee la distribución que estamos utilizando), con la diferencia de que no hace falta reiniciar para que entren en funcionamiento.

Para esto, necesita el código fuente de la actualización (un parche para el kernel que se está corriendo), más el código fuente del kernel en ejecución. El núcleo no necesita ser modificado por adelantado para que esto funcione (sólo x86 y x86_64).  El proceso de creación y aplicación de un parche es bastante sencillo, y ¡hasta se puede deshacer!

Por el momento sólo funciona con Linux x86, x86_64 y ARM, que su código se puede bajar en forma de fuente, agregar los repositorios GIT, y también descargar una versión binaria para instalar en cualquier distro GNU/Linux.

Las únicas desventajas (si cabe) en cuanto a lo técnico que le veo es que:

• Sólo aplica parches que no cambien la semántica del núcleo (supongo que esto quiere decir que no hacen que cambie su ABI). Sin embargo, ellos mismos afirman que el 88% de los parches de seguridad para núcleo publicados entre Mayo de 2005 y Mayo de 2008 eran aplicables perfectamente con KSplice. Esto hace que sirva en primera instancia para parches de seguridad, y para corrección de fallos en segundo lugar.
• No hay información sobre qué pasa si reinicio el equipo efectivamente con parches aplicados vía KSplice (supongo que todos los cambios se deshacen, ya que esto es al vuelo y no hay modificación sobre la imagen binaria del núcleo en sí mismo).
• Es necesaria la misma versión de compilador (o casi, ya que no hace un chequeo por número estricto de versión, sino que hace un chequeo de posibles conflictos y aborta en caso de detectar uno, afirmando en su web que esto es seguro).

Por otra parte, próximamente van a ofrecer el servicio de actualizaciones, esperemos que cumplan lo que prometen, a mí me cuesta creer que esto sea así de fácil. Sería bueno que todas las distros lo incluyeran e integraran…

Bueno, es todo por ahora.

¡Saludos!

Marcelo