Flash y libros digitales de las editoriales

Bueno, mis problemas con Flash han sido debido a los libros digitales que mandan las editoriales, en este caso de la editorial Oxford. Muchas editoriales siguen viviendo de las rentas con contenidos hechos en Flash, como si no se hubiesen enterado de que:

Lo malo del problema no es solo que dependan de una tecnología viejuna cada vez peor soportada como Flash, que lleva el camino de Java. Lo realmente malo es que dependan de una versión concreta del plugin, de tal forma que las nuevas actualizaciones (muchas de ellas de seguridad) del mismo hagan fallar el libro digital y para hacerlo funcionar nos obligue a tener en el sistema un Flash obsoleto.

Mi problema era con el libro "Oxford University Press/Key to Bachillerato iPack": necesita el Flash 11.2.202.394, cuando ahora vamos por la versión 24. Al abrir el libro directamente se quejaba de que no estaba instalado su Flash e invitaba a ponerlo ofreciendo un enlace. Descargar la versión de 32 o 64 bits es sencillo desde este enlace.

Claro que si lo descargamos, cogemos el libflashplayer.so de dentro y lo ponemos en la ruta /usr/lib/mozilla/plugins no habrá problemas: quedamos todo el sistema con un Flash antiguo, pero el Oxford iPack funcionará. Cuando haya alguna actualización no controlada del plugin habrá que volver a meter nuestro libflashplayer.so viejuno y así iremos tirando, pero tendremos páginas web modernas que no se vean o fallen con el Flash antiguo y las consiguientes quejas de los usuarios.

Esto no me satisfacía, así que me puse a investigar. Primeramente, me doy cuenta de que la aplicación de Oxford usa la tecnología de Mozilla llamada XUL, que se usaba para construir plugins para el navegador y, esta faceta no es muy conocida, para crear aplicaciones que son de escritorio pero internamente se basan en tecnologías Web, usando HTML, plugins, DOM, Javascript y una serie de ficheros XML. La idea es correr una aplicación web sin usar el navegador, como aplicación de escritorio.

Bueno, pues me dije: si Oxford iPack usa XULRunner (y efectivamente, en sus directorios se encuentra un libxul.so privado), internamente se basa en Mozilla-Firefox y por tanto buscará los plugins en la misma secuencia en que los busca el navegador. Esto es:

• Directorio indicado por la variable de entorno MOZ_PLUGIN_PATH.
• Directorio ~/.mozilla/plugins.
• /usr/lib/mozilla/plugins, o quizá /usr/lib64/mozilla/plugins.
• [Directorio de Perfil]/plugins, siendo normalmente el directorio de perfil ~/.mozilla/firefox/xxxx.default/.

Entonces, si antes de abrir la aplicación de Oxford hago que MOZ_PLUGIN_PATH apunte a un directorio donde está el libflashplayer.so que necesita para funcionar, esto no interferirá con el plugin instalado a nivel de sistema en /usr/lib/mozilla/plugins. Pues ciertamente es así, mi aplicación de Oxford se abría con esta ruta:

$ /home/compartido/Ingles/Oxford\ University\ Press/Key\ to\ Bachillerato\ iPack\ 1/linux/oup

siendo el ejecutable "oup" el que lanza la aplicacion XUL. Si antes de ejecutarla hago:

$ cp libflasplayer.so /home/compartido/Ingles/Oxford\ University\ Press/Key\ to\ Bachillerato\ iPack\ 1/linux/
$ export MOZ_PLUGIN_PATH=/home/compartido/Ingles/Oxford\ University\ Press/Key\ to\ Bachillerato\ iPack\ 1/linux/
$ /home/compartido/Ingles/Oxford\ University\ Press/Key\ to\ Bachillerato\ iPack\ 1/linux/oup

Ahora la aplicacion de Oxford usará la versión de libflashplayer.so que hemos metido previamente en el mismo directorio (será la 11.2, claro) y dejará tranquila la versión que hay en /urs/lib/mozilla/plugins, que seguirá siendo la 24.

Para hacer esto transparente al usuario simplemente hay que crear un script con las 2 últimas líneas y desde el fichero .desktop del escritorio que lanza el programa invocar a ese script en lugar de a "oup" directamente, modificando su línea "Exec=".

Et voilá, ya tenemos para aguantar una temporada más a Oxford y sus Flash obsoletos.

Nota: es importante que el libflashplayer.so que pongamos coincida en arquitectura con el ejecutable oup que usemos. Ambos deben ser de 32 bits o de 64 bits, no se pueden mezclar. Para saber de que arquitectura son usamos el comando "file *archivo*".

---

Otro problema que me relatan mis compañeros también con Oxford es que hay además libros que si aceptan el Flash 24, pero cuando van a reproducir los vídeos se queda la ventana en blanco. Parece ser que es un problema de permisos de Flash al acceder a directorios locales y se soluciona:

• Buscando en un navegador "panel de control Adobe Flash" y pinchando el primer resultado. Nos llevará seguramente a esta página.
• Pinchamos en "Parámetros de seguridad global".
• Marcamos "Permitir siempre".
• Pinchamos en Editar--> Agregar--> buscar carpeta. Le damos la ruta donde esta instalado el iPack y marcamos la carpeta "Oxford University Press" (En mi caso la ruta es "/home/compartido/Ingles/Oxford\ University\ Press").
• Aceptamos y probamos.

Bueno, creo que con esto se resuelve la casuística que nos ha aparecido. Seguiremos informando.

Aparente bloqueo en el arranque de Ubuntu.

Es increíble, me ha pasado una vez más. Había clonado un equipo con una nueva imagen y en el arranque, tras unos cuantos mensajes, se paraba con la pantalla en negro sin mostrar ni siquiera la pantalla de login. Lo último que veía era:

Unable to determine destination address
Unable to determine destination address
Unable to determine destination address

Y, tonto de mí, otra vez he pensado que esos mensajes estaban relacionados con el "bloqueo". Nada más lejos de la realidad, esos mensajes son lo último que vemos antes de que empiece a fallar, pero la causa es normalmente otra. Como usualmente tenemos habilitado el arranque para que sea en modo gráfico y silencioso nos perdemos toda la ristra de mensajes de inicio, incluidos los que nos informan de los errores que paran el proceso de inicio.

Lo verdaderamente gracioso es que eso lo hacemos para intentar conseguir un arranque mas bonito y agradable para el usuario, con alguna animación o similar, pero la mayoría de las veces el resultado es una pantalla negra interminable hasta que sale de pronto la petición de credenciales de login. Intuyo que esa pantalla negra tiene algo que ver con el intento no conseguido de activar potentes modos gráficos durante el inicio y que el modo VESA 800x600 para mostrar una triste animación de inicio está infravalorado, motivo por el cual sólo vemos una pantalla negra. Como decía mi padre, "por querer alcanzar la gloria nos quedamos sin cielo".

Volvamos al hilo de la cuestión. ¿Cómo mostrar qué está pasando detrás del telón?. Pues editando el GRUB en el arranque:

1) Si vemos el GRUB al inicio, normalmente pulsando ESC se nos muestra.

2) Una vez en el menú, vamos a la opción que carga por defecto (normalmente la primera) y pulsamos "E" para editarla.

3) Nos salen todas las opciones y parámetros, entre los cuales estará seguramente "quiet splash". Esos dos parámetros son los culpables de que no veamos nada. Nos movemos hasta ellos con el cursor y los borramos. Puede que haya algún "vga=XX" que también interfiera, pero no lo tocaremos a no ser que esto funcione.

4) Pulsamos F10 para realizar el arranque con el GRUB modificado. Este cambio no es permanente, solo vale para el arranque actual.

Ahora sí se muestra todo el proceso y podemos ver donde se para. En mi caso era en el montaje de varias particiones que no había clonado bien, con lo cual simplemente reclonando esas particiones se ha solucionado el problema. Los mensajes mencionados antes no tenían nada que ver.

Espero que esto no me vuelva a suceder.

Obtener la versión de un fichero libflashplayer.so

Estos días he estado liado con Flash Player para hacer funcionar un libro digital de Oxford, de esos que necesitan una versión concreta en una ubicación concreta para tirar sin problemas.

Llega un momento en que tienes varios libflashplayer.so de distintos orígenes dando vueltas y no sabes la versión y arquitectura de cada cual. Podemos meterlos uno a uno en el directorio /usr/lib/mozilla/plugins o similar, abrir firefox e irnos a about:plugins para saber la versión, pero es un poco tedioso.

Recordé que en Debian había un script llamado /usr/sbin/update-flashplugin-nonfree, que actualizaba libflashplayer.so si la versión de la web de Adobe era superior a la instalada. Lo he localizado en packages.debian.org y he podido localizar dentro el fragmento de código que extrae la versión de Adobe Flash del fichero .so:

# strings libflashplayer.so 2> /dev/null | grep LNX | cut -d ' ' -f 2 | sed -e "s/,/./g"
24.0.0.194

Sencillo: con "strings" se sacan todos los strings (cadenas ASCII) legibles contenidos en el fichero .so, luego buscamos una línea con el trigrama LNX y detrás está el número de versión de Flash.
Por último, ¿cómo sabemos si es de 64 o 32 bits?. Esta es más sencilla si cabe:

# file libflashplayer.so 
ELF 32-bit LSB.... | ELF 64-bit LSB....

Aprovechando el Grammy a Megadeth pongamos un vídeo suyo para rematar:



Venga, vale, no troleemos al buenazo de Mustaine:

Cerrar sesiones inactivas de usuario en Linux y en Windows.

Un problema frecuente que tenemos con los ordenadores compartidos es el de usuarios que se dejan su sesión abierta al alcance de todo el mundo. Además del evidente problema de seguridad esto lleva a malentendidos de todo tipo, ya que si se sienta otro usuario despistado y se pone a trabajar en la sesión de anterior, manipulando y guardando ficheros, cuando se va al final no sabemos fácilmente en que sesión ha trabajado y la pregunta "¿dónde están mis datos?" irrumpirá en nuestra tranquilidad de sysadmin.

Lo ideal es colocar un temporizador que cierre las sesiones inactivas pasado un tiempo, mitigando en menor o mayor medida el problema descrito. Veremos soluciones para nuestros clientes Windows y Linux.

1. Soluciones para Linux.

A lo largo de los años hemos encontrado varias soluciones al problema de cerrar la sesión cuando ha pasado un tiempo sin actividad. Repasemos algunas de ellas:

• Evanescent: es un software específico para esta tarea. Por desgracia parece abandonado y no sabemos si funcionará ahora. Código para descargar y capturas de pantalla.
  
• Creando un protector de pantalla ad-hoc para salir de sesión, mediante un script y seleccionando dicho salvapantallas en la lista que podemos ver con xscreen-saver-demo o la utilidad que tengamos para seleccionar screensaver. Aquí cuentan como sería. Al ser un protector de pantalla "falso" simplemente hay que configurar el tiempo y cuando le toque saltar lo que hará será cerrar la sesión en lugar de hacer dibujitos en la pantalla.
  
• Usando xprintidle. Es una utilidad que muestra el tiempo que lleva una sesión ociosa, sin interacción del usuario. Combinado con idlekiller tendremos un programa que se ejecuta como un servicio y cierra sesiones que lleven más de cierto tiempo inactivas. Otra opción es usarlo con un script arrancado desde crontab, como muestran aquí o aquí.
  
• Usando xautolock. Este método me lo ha revelado mi compañero Camilo, ¡gracias!. xautolock es una utilidad que se arranca en el inicio de sesión, desde /etc/xdg/autostart/xxxx.desktop y permite configurar un programa a ejecutar cuando la sesión del usuario lleve un tiempo ociosa. En nuestro caso, el programa a ejecutar ser xfce4-session-logout (evidentemente cambiará según el escritorio usado). Este es el fichero .desktop que Camilo usa, que lanza el cierre de sesión a los 55 minutos de inactividad:
  

  # cat /etc/xdg/autostart/xautolock.desktop
  [Desktop Entry]
  Type=Application
  Name=xautolock
  Comment=Lock the screen after a certain time automagically
  Exec=xautolock -time 55 -locker "xfce4-session-logout"
  OnlyShowIn=XFCE;
  NoDisplay=true
  

Y con esto acaban los sistemas en Linux, como vemos hay de sobra donde elegir.

2. Solución para Windows.

En el caso de los Windows la cosa se complica y se hace mas necesaria ya que por motivos diversos tengo habilitado el cambio rápido de usuario. Esto hace que un usuario pueda abrir sesión sin cerrar la del anterior, de tal forma que al final del día hay una pila de sesiones abiertas chupando recursos. Da igual que digas a los usuarios que cierren sesión abierta antes de entrar con la suya. No lo hacen. Por eso es importante cerrarlas de forma forzada si no registran actividad.

La forma mas sencilla de hacerlo que he podido encontrar es usando la utilidad gratuita IdleLogoff. Sencillamente le dices un tiempo en segundos y una acción (logoff, lock o shutdown) y al pasar dentro de las sesión esos segundos inactivos se ejecuta dicha acción.

La segunda parte es meterla en un script que lo lance, por ejemplo a los 1800 segundos. Una vez descargado el ejecutable y puesto en c:\windows creamos también allí el fichero .bat:

c:\> type c:\windows\IdleLogoff.bat
Echo off
start c:\Windows\IdleLogoff.exe 1800 logoff 

La tercera y última parte es la más peliaguda: que se inicie una instancia del IdleLogoff con cada usuario que inicie sesión en la máquina, para poder cerrarlas si se quedan ociosas en primer o segundo plano.

La primera proposición es utilizar GPO (políticas de grupo), como cuentan aquí: se crea una GPO que ejecuta el script IdleLogoff.bat en el inicio de sesión de cada usuario. El problema que tengo con esto es que en nuestras redes no tenemos un Windows Server que nos distribuya las GPO. Desde arriba nos llenaron de Windows pero se les olvidó ese pequeño detalle: mejor tener un administrador informático apretando tuercas Windows a Windows que un servidor que los administre centralizadamente. Ya avisamos de ello.

Otra opción es definir una tarea programada que ejecute el script al inicio de sesión de cada usuario o quizá algo parecido a como se cuenta aquí. El problema que he encontrado con esto es que las tareas programadas asociadas a determinados eventos no van muy bien con Windows 8 y/i Windows 10. Si no fallan por una cosa fallan por otra, por lo que no son viables debido a fallos en su implementación. Con la úĺtima edición de Windows 10, por poner un ejemplo, han dejado de funcionar los eventos vinculados al establecimiento de conexión de la interfaz de red.

¿Qué opción nos queda a los pobres?. Pues la carpeta "Inicio" del Menú de Inicio de Windows de siempre. Ahora esa carpeta está en la ruta:

 C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

antes estaba en c:\documents and settings\all users\... y luego en c:\users\public\..., Microsoft la mueve de vez en cuando para aumentar la entropía del Universo (y es que en Microsoft se lleva la Segunda Ley de la Termodinámica a rajatabla). Allí ponemos nuestro script IdleLogoff.bat para que se ejecute en el inicio de sesión de todos los usuarios. Como el /etc/xdg/autostart de toda la vida de Linux. ¿Funciona?. Si: cuando hay varios usuarios en el sistema hay un idlelogoff.exe por usuario y cuando expira su tiempo de inactividad la sesión desaparece y libera recursos. Misión cumplida.

Bueno, pues he dedicado un post conjunto a Windows y Linux. Para que luego no digáis que los linuxeros tenemos prejuicios cognitivos.

VirtualBoxing Windows (Parte III)

Tras unos meses funcionando con los Windows virtualizados y bien ataditos en corto, he tenido que hacer al igual que en la anterior parte unos cambios en el script de arranque de la máquina virtual.

La causa de ello es que al cerrar la máquina virtual ofrece 3 opciones: Apagar, Enviar Señal de Apagado y Guardar Estado. Si el usuario daba a "Guardar Estado" luego la máquina no podía volver a abrirse a no ser que se descartase ese snapshot creado al Guardar el Estado. Pienso que la causa podría ser que la misma máquina es compartida entre varios usuarios de ldap y puede que el que uno la guarde y otro la abra no está bien visto por VirtualBox.

Da igual. Mis instrucciones son claras: las máquinas se deben apagar, no guardar. Si alguien las guarda, descartaremos lo guardado. Y para ello nada mejor que modificar el script de arranque para que lo haga el solito:

# cat /opt/VirtualBox VMs/run_vbox 
#!/bin/bash

#Poniendo esto  /etc/environment
#export VBOX_USER_HOME="/mnt/VirtualBox VMs/VirtualBox"
#en el arranque lo tendremos para todos los usuarios. Maquinas virtuales en local.

#Si cierran la ventana a lo bruto se hace un shutdown de la máquina. Esto al .vbox de 
#la máquina
#    ExtraDataItem name="GUI/LastCloseAction" value="Shutdown"

machine="Win10"

running=$(VBoxManage list runningvms | grep $machine)
if  [ -n "$running" ]
then
   zenity --error --text "La máquina $machine ya está funcionando"  
else

  #Verificamos si está en estado "saved" y si es asi, lo descartamos. No se puede arrancar desde aqui si está en dicho estado.
  (VBoxManage showvminfo $machine | grep -e '^State.*saved.*'  2>&1 > /dev/null) &&  VBoxManage discardstate $machine
  #Si cierran la ventana a lo bruto se hace un shutdown de la máquina. Esto al .vbox de la máquina
  #    ExtraDataItem name="GUI/LastCloseAction" value="Shutdown"
  #o bien VBoxManage...
  VBoxManage setextradata $machine "GUI/LastCloseAction" "Shutdown"
  VBoxManage sharedfolder remove "$machine" --name "compartido"
  VBoxManage sharedfolder add "$machine" --name "compartido" --hostpath "$HOME" --automount
  VirtualBox --startvm $machine
fi

En negrita está la parte divertida, con:

(VBoxManage showvminfo $machine | grep -e '^State.*saved.*'  2>&1 > /dev/null)

Miramos el estado de la máquina y vemos si corresponde a "Saved". Si es así, con:

VBoxManage discardstate $machine

descartamos el guardado previo y ya se puede arrancar a continuación la máquina.

Y con esto ya tenemos otro obstáculo saltado. Sigo teniendo problemas con la distribución a toda pastilla de imágenes VDI con udpcast, pero todo se andará y podré contar como va.

Android en el PC de sobremesa (Parte II)

Tras la instalación exitosa de Remix OS en una partición Linux está semana me ha tocado hacer las pruebas con particiones de Windows 10. La verdad es que con la herramienta que trae el propio Remix OS basta con decirle la ISO y la partición y el resto lo hace él sin problema. La única petición extraña que hace es que desactivemos Secure Boot en la BIOS, pero eso es algo bueno en sí mismo. Después de la instalación hace el arranque largo para crear el disco virtual y ya lo tenemos listo.

También he probado el Remix OS Player, que crea una máquina virtual basada en qemu para no tener que arrancar desde cero el sistema Android. No esta mál para probar que tal funciona y para cosas sencillas, pero como no me funcionaba la webcam dentro de la máquina virtual lo he dejado de lado. En principio solo está disponible para Windows, pero no creo que sea díficil portar, una vez creada, la máquina virtual qemu a Linux.

El único traspié que he tenido está relacionado con el grub que se instala en la partición Boot de Windows para darnos a elegir entre Windows 10 y Remix OS en el arranque. Por algún motivo quedaba seleccionado como sistema por defecto "Remix OS" y no habia manera de modificarlo cambiando en el arranque a Windows para que este sea el sistema por defecto siempre. Como en estos PC que estoy preparando el arranque por defecto debe ser Windows, he tenido que encontrar el grub.cfg y cambiarlo a mano. Como me ha costado un poco debido a lo puñetero de uefi y a que hay varios grub.cfg tanto en la partición de sistema como en la partición de boot, lo documento para la próxima vez. Una vez sabes lo que hay que hacer, los pasos son triviales. Desde la consola de comandos MS-DOS ejecutaríamos:

mountvol b: /s
notepad b:\boot\grub\grub.cfg
mountvol b: /d

El primer comando monta la partición de boot UEFI en la unidad b: (jaja, me descojono al andar a estas alturas con las unidades de disco con el formato letra+:, una herencia maldita de CP/M que arrastrá Windows hasta el Ragnarök), luego editamos el grub.cfg con el bloc de notas, guardamos y por último desmontamos la partición.

Al editar grub.cfg he hecho dos cosas:

• Poner "set default=0" para que el arranque prederminado sea el de Windows.
• Cambiar la etiqueta de "Remix OS" a "Android Remix OS" para que los usuarios entiendan bien las dos opciones de arranque.

Reiniciamos y ya veremos el grub con la opción correcta seleccionada.

Bueno, pues nos vemos más adelante mientras Trump y Putin nos dejen. Dicen que va a mandar el carajo el TTIP, que pena me da, voy a llorar....

Cambio de correo desde @edu.juntaex.es a @educarex.es

Llevamos varios días en que nuestra lista de correo con cuentas @edu.juntaex.es no funciona bien y la empresa responsable de ello no acaba de arreglarlo. Como tenemos además cuentas @educarex.es, que son realmente cuentas de Google Mail, se ha decidido que usemos para la lista de correo esas cuentas nuevas, que son gestionadas fuera del servidor Exchange oficial de la Junta.

Vamos a ver como mantener comunicadas ambas cuentas para no tener que consultarlas continuamente. Primero veremos como reenviar todos los correos que lleguen a la cuenta @edu.juntaex.es a la cuenta @educarex.es:

Creamos una regla de bandeja de entrada:

Damos a "Nuevo":

Y creamos la regla "Reenvía a educarex.es":

La regla se aplica a todos los mensajes que entren y consiste en Redirigir el mensaje hacia nuestra cuenta @educarex.es y despues eliminarlo. Le damos a guardar y ya podemos estar seguros de que cualquier mensaje enviado a nuestra cuenta @edu.juntaex.es llegará a los pocos minutos a la cuenta @educarex.es.

La otra parte que nos puede resultar útil es habilitar nuestra cuenta @educarex.es para enviar correos en nombre de @edu.juntaex.es, que a fin de cuentas es la dirección oficial. Para ello vamos a Gmail con nuestra cuenta @educarex.es y una vez allí le damos a la rueda de la derecha y elegimos "Configuración":

Despues elegimos la pestaña "Cuentas" y "Añadir otra dirección de correo electrónico" dentro de la sección "Enviar correo como..":

En la ventana que se abre elegimos un nombre para la cuenta, la dirección de correo electrónico sera adminies.talytal@edu.juntaex.es y marcamos "Tratarlo como alias". Le damos a siguiente:

Ponemos servidor SMTP "correo.juntaex.es", puerto 25, usuario "adminiesXXX", la contraseña que sea y conexión TLS. Le damos a Guardar Cambios:

Para validar esa cuenta recien añadida seguramente nos envien un correo con un código de validación y tengamos que rellenar luego un formulario con ese mismo código.

Una vez hecho esto dejamos como cuenta de "Envío de correo predeterminada" a @educarex.es (en Configuración->Cuentas->Enviar correo como y seleccionando esta cuenta como "Predeterminada" en el enlace de la derecha), pero a la hora de enviar un nuevo mensaje siempre podremos abrir el desplegable y elegir como remitente entre esa cuenta y la de @edu.juntaex.es, en la casilla "De ":

Y bueno, con esto creo que tenemos total disponibilidad de la nueva cuenta sin renunciar a la antigua.

Listado jerárquico de dispositivos PCI

Ultimamente los infolabs me han dado mucha guerra, tras los problemas con la tarjeta nvidia y el Secure Boot, la última ha sido que la tarjeta de red de la placa (identificada como 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM - rev 31, con id 8086:15b7) no servía para hacer NAT a los 15 PC de los alumnos: tan pronto como había un poco de tráfico la conexión se iba al carajo y se bloqueaba el PC del profesor y los escritorios de los alumnos.

Al final he optado por ignorarla (el contrato de infolabs dice que la empresa adjudicataria debe asegurar compatibilidad del hardware durante 5 años, pero no lo voy ni a intentar) y pinchar otra tarjeta para hacer NAT. Bueno, pues ya parecía que la cosa estaba estable cuando veo que me estaba saliendo compulsivamente este error en el syslog:

Jan  9 10:29:52 A07-PRO kernel: [  140.353087] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0

Seguramente ya salía antes, pero con los errores de la tarjeta de red me pasaban desapercibidos. El error aparece en el dispositivo 0000:00:1c.0, ¿que es eso?. Veamos:

# lspci | grep 1c.0
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1)

Bueno, es un conector PCI Express, pero no creo que el bus esté dando problemas en si mismo. El problema lo dará el dispositivo que está enchufado a dicho puerto PCI. ¿Se puede averiguar que hay conectado ahí desde terminal?... pues claro:

# lspci -vt
-[0000:00]-+-00.0  Intel Corporation Sky Lake Host Bridge/DRAM Registers
           +-01.0-[01]----00.0  NVIDIA Corporation GK208 [GeForce GT 730]
           +-02.0  Intel Corporation Sky Lake Integrated Graphics
           +-14.0  Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
           +-14.2  Intel Corporation Sunrise Point-H Thermal subsystem
           +-16.0  Intel Corporation Sunrise Point-H CSME HECI #1
           +-16.3  Intel Corporation Sunrise Point-H KT Redirection
           +-17.0  Intel Corporation Sunrise Point-H SATA controller [AHCI mode]
           +-1c.0-[02]----00.0  Intel Corporation Wireless 7265
           +-1c.6-[03]----00.0  Intel Corporation 82574L Gigabit Network Connection
           +-1d.0-[04]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           +-1f.0  Intel Corporation Sunrise Point-H LPC Controller
           +-1f.2  Intel Corporation Sunrise Point-H PMC
           +-1f.3  Intel Corporation Sunrise Point-H HD Audio
           +-1f.4  Intel Corporation Sunrise Point-H SMBus
           \-1f.6  Intel Corporation Ethernet Connection (2) I219-LM

Como podemos ver, este comando "lspci -vt" nos da un punto de vista jerárquico de los dispositivos y así podemos ver que en dicho puerto está conectado "Intel Corporation Wireless 7265", una tarjeta inalámbrica PCI que traen los infolab y que no vale para un carajo. Si hacemos un lspci normal vemos el bus de esa tarjeta, el 02.00:

02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 61)

Buscando en Internet no he encontrado una causa clara del error, así que he optado por anular la tarjeta de tal forma que el kernel deje de detectarla. Para ello metemos en /etc/rc.local la línea:

echo 1 > "/sys/bus/pci/devices/0000:02:00.0/remove"

Antes del exit final. Esto hace que lo que hay el bus PCI 02.00 desaparezca de la lista de dispositivos en el arranque, de tal forma que la tarjeta Wifi se vuelve invisible (ni siquiera aparece el dispositivo wlan0 ni se carga módulo) y el error en el syslog desaparece. Es el equivalente lógico a abrir el PC y arrancarle la tarjeta de sus malditas entrañas.

No tenía mucho sentido tener ese error metiendo ruido en el syslog producido por algo que no voy a usar jamás, así que otro problema resuelto y a otra cosa, mariposa.

Android en el PC de sobremesa (Parte I)

Debido a que cada vez es mas fácil encontrar aplicaciones interesantes educativas para la ESO y los Ciclos Formativos que solo corren en dispositivos Android (por ejemplo, aplicaciones de maquillaje para los Ciclos de Peluquería y Estética), he estado intentando hacer funcionar, con vistas a probar luego en portátiles e infolabs, el sistema Android en los PC de sobremesa con prometedores resultados.

Para las pruebas he usado un PC clónico con procesador Dual-Core E5200-2.50GHz y 4Gb de RAM y con Mint 18 instalado. El sistema usado para la instalación es una maravilla llamada Remix OS, una mejora de Android-x86, el port de Android (que normalmente corre sobre ARM) a dispositivos x86.

Los pasos son:

1. Empezamos por descargar el fichero de instalación. Como mi hardware es un poco obsoleto, me descargo la versión de 32bits.
2. La descarga es un archivo .zip que descomprimimos dando lugar, entre otras cosas, a un fichero .iso que también procederemos a descomprimir con:
   

   # 7z x Remix_OS_for_PC_Android_M_32bit_B2016101201.iso 
   

.
3. Ahora creamos un directorio donde poner todo y copiamos los ficheros necesarios:
   

   # mkdir /remix
   # cp initrd.img kernel ramdisk.img system.sfs /remix
   # mkdir /remix/data
   

4. Añadimos una entrada para arrancar Remix al Grub y lo regeneramos:
   

   # cat /etc/grub.d/40_custom 
   #!/bin/sh
   exec tail -n +3 $0
   # This file provides an easy way to add custom menu entries.  Simply type the
   # menu entries you want to add after this comment.  Be careful not to change
   # the 'exec tail' line above.
   
   menuentry "Remix OS" --class android-x86 {
      insmod gzio
      insmod part_msdos
      insmod ext2
      search --file --no-floppy --set=root /remix/system.sfs
      linux /remix/kernel root=/dev/ram0 androidboot.hardware=remix_x86 androidboot.selinux=permissive nouveau.modeset=1 i915.modeset=0 SRC=/remix DATA= CREATE_DATA_IMG=1 
      initrd /remix/initrd.img
   }
   # update-grub2
   

Y con esto reiniciamos y en el Grub debe aparecer la opción "Remix OS".

Si lo seleccionamos y está todo bien configurado, con un poco de paciencia viendo la pantalla:

Tras una espera inicial un poco desesperante y quizá algún reinicio tendremos el Android en nuestro PC, pero vamos a comentar y aclarar varias cosas antes:

• En mi 40_custom he puesto "androidboot.hardware=remix_x86" porque tengo la versión de 32 bits, si fuera la versión de 64 bit pondria remix_x86_64.
• Podemos descomprimir otra versión en otra ruta, por ejemplo /remix_test/ y cambiando los directorios en el fichero de Grub jugar con varias versiones de Android.
• He tenido problemas con la tarjeta gráfica. En mi caso tenia una Intel G33 en placa y una Nvidia GeForce 210 en PCI express. Al arrancar me salía una extraña splash screen con trozos de Minecraft pixelados (prueba de que en la memoria siempre algo queda después de que mi muchachada eche unas partidas) y, perfectamente visible, la grafía "Friki". No me lo tomaré como algo personal.
• La solución encontrada ha sido desactivar la tarjeta Intel de la placa en la BIOS y poner los parámetros "nouveau.modeset=1 i915.modeset=0" para quedar claro que driver carga y configura la pantalla.
• Los primeros arranques son muuuuuy lentos, ya que tiene que crear un sistema de ficheros loop en /remix y hacer varias inicializaciones y configuraciones, pero al final aparece el escritorio.

• La conexión wifi puede funcionar o no en función de si la tarjeta está soportada. Mi USB-Wifi Realtek RTL8192SU no lo está, pero poniendo una TP-Link TL-WN821N no he tenido problema. La conexión cableada si ha funcionado.
• Si queremos poder usar Google Play (no es mi caso, quiero descargar e instalar las aplicaciones de forma controlada) nada mas entrar es conveniente dar al icono "Play Activator" del escritorio o del menú de inicio, dejar que actúe e inmediatamente después reiniciar el sistema. Tras un nuevo arranque se supone que Play está operativo (Nota: la app Roblox no viene por defecto, la he instalado a petición de mis zagales y para probar una aplicación con 3D)

• En mi caso, tras el primer arranque completo y conexión a red ha detectado una actualización del sistema (vamos, una OTA). La he descargado y dicho que actualice y, tras otro largo rato de espera, ha acabado bien.

Y nada más. En principio, con copiar /remix y /etc/grub.d/40_custom a otra máquina será suficiente para poder lanzar allí Android, realizando pequeños ajustes en función del hardware que nos toque.

Seguiremos informando de los avances.

Más Kodi, por favor

En estos días libres me he puesto a configurar el Kodi que tengo en el AndroidBox que me agencié en Aliexpress, ya que quería comprobar si el visionado en streaming funciona tan bien como dicen en los foros. Hasta ahora lo usaba para ver cosas descargadas en el servidor DLNA de casa con mldonkey (es un viejo router con OpenWrt y un disco externo que gasta menos que un mechero) pero nunca lo usaba para nada online. Esta entrada la dejo a modo de recordatorio por si tuviera que hacerlo de nuevo.

Antes de nada, recomendar Kodi. Es una prueba en vivo de que se puede hacer software libre, gratuito y de calidad insuperable. Si alguna vez os piden un ejemplo de todo lo anterior, decid "Kodi" y se acabó la discusión.

Bueno. Lo primero es instalar los plugins que permiten ver contenido online. En mi caso ya venían instalados en el AndroidBox. Los plugins de vídeo son:

• Exodus: para contenidos preferentemente en inglés. Tiene un buscador muy potente que te da acceso a decenas de servidores con los contenidos, en resoluciones tanto de 1080 como de 720. Se instala según estos pasos.
  
• Pelisalacarta: para contenidos en español. No tiene tanto como Exodus y muchas veces los servidores están caídos o dan fallos de conexión, pero luego comentamos un servidor que a mi normalmente me funciona y no da problemas. Estas son las instrucciones de instalación. Ojo: aparecen 2 plugins de pelisalacarta, uno con el nombre "pelisalacarta UI". Este último es un skin del original con un interface mas bonito.
  

Una vez descargados e instalados vemos que Exodus funciona a la primera, pero tenemos el problema de que al tener casi todo el contenido en inglés y si tienes, como tengo yo, nulo oído para el idioma de la Pérfida Albión no queda otra que poner los subtítulos. Para ello instalamos los siguientes plugins:

• Opensubtitles: es posiblemente el repositorio mas grande de la red. Aquí tenemos como hacerlo y como configurar correctamente los idiomas de búsqueda de subtítulos (yo pongo primero Español y como secundario Inglés). Tambien es impepinable darnos de alta en su página y configurar las credenciales (usuario/contraseña) en la ventana de configuración del plugin.
  
• Argenteam: un clásico de los subtítulos en español. Se configura con estas instrucciones.
  
• Subtitles.es: otra opción. Instrucciones.
  
• Subdivx: está la usé mucho en el pasado, cuando descargábamos cosas con el emule o el Ares. No está mal configurarla y tenerla como reseva.
  

Realmente con OpenSubtitles tenemos casi todo resuelto, ya que además suele tener mucha variedad del mismo subtítulo con distintas temporizaciones, pero mejor que haya varias opciones de búsqueda donde elegir.

Otra cosa interesante es que al abrir un contenido se nos lance la búsqueda de sus subtítulos de forma automática. Eso viene muy bien si usamos preferentemente Exodus porque nos gusta ver cosas en su idioma original. Esa búsqueda automatizada se hace con el plugin Automatic Subtitles.

Por último, sobre pelisalacarta. Tiene infinidad de canales que funcionan regular, pero recomiendo usar el canal "pordede" por su fiabilidad. Primero debemos darnos de alta en su página y con esas credenciales configurar el canal en cuestión. Luego, en la búsqueda dentro de pelisalacarta no usaremos la búsqueda general (tarda mucho y nos da enlaces que en su mayoría fallan). Lo haremos por canales, seleccionando el canal pordede y realizando la búsqueda allí. Éxito garantizado.

Y puedo confirmar que todo va de maravilla, rápido y sin cortes. Entre esto y el Amazon Prime Video, gratuito para los yonkis de Amazon Premium como yo, vaya tupa de ver cosas atrasadas me estoy dando. Si Aute escribiese ahora la canción sería "Más Kodi, por favor".

Siguiente reto: usar el plugin popcorntime.

Hasta pronto, prometo que volveré con cosas serias.