Spiga

Cubieboard, Ubuntu y otras cosas

Hace unos días que os prometo una review de la Cubieboard y no llega, pero todo tiene su explicación. Tras probar algunas distribuciones encontré una bastante completa y que realmente se comportaba como esperaba -ya que me enfadé bastante al comprobar que lo que había no era lo que quería-, se trata de Cubiuntu (a su vez un mod de Cubie de Delectable) y afortunadamente su creador es Español y lector de BeLinux (un saludo desde aquí, Isaac). Me puse encontacto con él para ayudarle con la distro y he acabado con un mano a mano frenético que nos está llevando a una imagen que, aunque suene mal decirlo, pocos competidores como distribución de escritorio va a tener.

He empezado con un plato fuerte añadiendo algo que en las distribuciones que había probado no tenía: un kernel "actualizado". Hemos pasado de una version 3.0 a una 3.4.43 funcional al 100%, con algo de mejor rendimiento, soporte para iptables, aceleración gráfica para la MALI400 integrada y muchas otras cositas en las que estamos trabajando.

Captura de Cubiuntu 0.5, con kernel 3.4.41

De momento, y para los poseedores de una Cubieboard, os dejo con la versión anterior de dicho mod, y os anuncio que en breves días estará la versión 0.5 que es justamente en la que me he involucrado y en la que encontraréis cantidad de mejoras. Una vez acabe con todo el follón para la nueva versión os prometo la review, que sin duda, pasará de un "no es lo que esperaba" a un "estoy muy contento".

Por el momento a descargar y probar la versión previa de Cubiuntu haciendo clic aquí.

Cubieboard, preparando review (Actualizado)

Ayer mismo recibí un paquete, cortesía de SoftActivo -a quienes doy las gracias desde aquí-, con el que voy a disfrutar cacharreando. Se trata de la Cubieboard, que como muchos ya sabrán se trata de otra pequeña placa similar a la Raspberry Pi, con arquitectura ARM pero basada en un procesador Cortex A8 a 1 Ghz.

La principal diferencia es que parte con una memoria nand de 4Gb con sistema Android preinstalado, posibilidad de conectar un disco duro SATA y un puerto IR.

Por el momento os dejo con las especificaciones, el video de unboxing oficial y la foto del paquete. En cuanto pueda os doy mis impresiones del aparatito, que estoy seguro que no va a defraudarme.

Especificaciones:

  • Procesador 1G ARM cortex-A8, NEON, VFPv3, 256KB L2 cache
  • GPU Mali400, OpenGL ES
  • 1GB DDR3 @480MHz
  • Salida HDMI 1080p
  • 10/100M Ethernet
  • 4GB Nand Flash
  • 2 USB Host, 1 micro SD slot, 1 SATA, 1 ir
  • 96 extend pin including I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP..
  • Ejecuta Android, Ubuntu y otras distribuciones

Vídeo del unboxing:


Y aquí el paquetito:


Mientras tanto, para los interesados en ella, podéis encontrar un listado de los vendedores oficiales justo aquí.


Actualización 20/06/2013:

Tras haber probado algunas distribuciones mediante Berryboot para A10, puedo confirmaros que la máquina es bastante más ágil que la Raspberry, pero en su contra -y hasta que me ponga más a fondo- he encontrado una falta de soporte tanto en Android como en Linux.

Inicialmente en la Nand viene Android instalado con XBMC, hasta aquí estupendo. El problema ha sido al querer instalar la aplicación de Youtube, que nada más arrancarla se cierra. Por lo que he estado mirando en foros no soy el único con el problema y, por lo visto, incluso había un usuario que reportaba que, con dos Cubies distintas y misma configuración, en una funcionaba y en la otra tenía el mismo fallo que yo. Un poco caótico, ¿no creéis?

Por otro lado las distribuciones que he probado por el momento han sido:

  • Fedora 18: Al arrancar Yum provoca un fallo inesperado y se cierra, por lo que no he podido ni ver si hay actualizaciones o paquetes nuevos.
  • Ubuntu/Linaro Quantal: Muy rápida moviéndose con LXDE, pero tiene sus fallos (por ejemplo se cierra la pantalla de introducción de password al intentar reiniciar, apagar, etc.) o directamente no tiene todos los paquetes que he querido probar en sus repositorios. La configuración de red es fatal, por lo menos con Berryboot, ya que funciona cuando le apetece, dejando de funcionar tanto la cableada como la pequeña Wireless que le he conectado (mientras que enel menú de Berryboot van genial). Configurando de forma manual funciona la cableada. Tengo que investigarla un poco más.
  • Raspbian: No deja de ser la misma imagen que la de la Raspberry Pi, no aporta nada nuevo que no sepamos los usuarios de Raspi, todo lo contrario, limita la potencia de más que pueda tener Cubie.
Por otro lado me ha parecido una mala jugada la salida del modelo A20 (con doble núcleo) no compatible con el modelo actual, por lo que a la larga ya sabemos que va a pasar con las distribuciones para el modelo A10. En el caso del modelo A o B de Raspberry no tenemos estos problemas, ya que simplemente es un cambio en la cantidad de memoria del sistema.
Tengo pendientes de probar algunas versiones de Ubuntu 12.04 con soporte de aceleración de Mali 400. En cuanto haga más pruebas os cuento y, por supuesto, os hago la review.

Guía Ambilight con Raspberry Pi (Actualizado)

Hace un par de días revisando el blog de misapuntesde.com descubrí que un lector de José Cerrejón (@ulysess10 en Twitter) le había hecho llegar las instrucciones para conseguir un funcional sistema Ambilight casero para Raspberry Pi.

Me gustó tanto la idea que le he pedido permiso para enlazar el post, así que sin enrollarme más os dejo con el enlace, que no tiene desperdicio.

 



Un saludo a Hugo Ruiz (el lector de su blog que le hizo llegar la guía) y al propio José, que ha sido tan amable de darme permiso para poneros el enlace.

Actualización 15/07/2013:
Os dejo también con el enlace para comprar el material necesario en eBay, viendo que la entrada está teniendo bastante éxito.

http://pibob.nadnerb.co.uk/parts.html

Usando servidor X en Windows

Muchas veces os habréis encontrado con el problema de tener que trabajar con Windows por algún motivo (sí, para mi suele ser un problema más que una ventaja) y con la falta de soporte/compatibilidad con muchos aspectos en Linux. Una de las cosas que más suelo extrañar en mis sesiones bajo Windows es el soporte "X" en conexiones SSH a mis máquinas remotas. Vale, que se puede hacer todo -o casi- por terminal, sí, pero cuando quieres trabajar con aplicaciones de GUI que te facilitan la tarea es algo que se agradece muchísimo, y es por eso que me puse a buscar alguna solución a dicho problema. 

Xming, un servidor X para Windows:

El problema de Windows, al hacer conexiones con soporte X11, es que no sabe interpretar lo que le devuelve SSH para redibujarlo en pantalla, por lo que si lanzamos una aplicación con interfaz gráfico vamos a encontrarnos con un fantástico error. Ayer, sin ir más lejos, tenía que lanzar unas descargas y dejarlas corriendo de trasfondo y sí, puedo hacerlo mediante el gestor de descargas que ofrece Webmin, axel o cualquier otra utilidad, pero pesonalmente me gusta uGet (cada uno tiene sus manías) y lamentablemente necesita soporte X11 puesto que es una aplicación con GUI.

Captura de pantalla de uGet desde Ubuntu   





Lo primero que vamos a hacer para añadir soporte X11 a Windows es descargar e instalar Xming, un intérprete de X que funciona a las mil maravillas, es gratuito y open source, como a nosotros nos gusta. Os dejo con el link de descarga aquí.

Opciones de configuración de Xming
La ventaja es que vamos a poder utilizarlo con cualquier distribución, no importa si hablamos de Raspberry Pi con Raspbian o de una PC normal y corriente bajo Linux para arquitecturas x86, o incluso otras, por lo que nadie se piense que esto es exclusivamente para Raspberry Pi.

Una vez instalado y seleccionadas las opciones que deseemos, arrancaremos el servidor (hay un configurador y el servidor, no vayáis a confundir uno con el otro) y observaremos que se ha quedado en la bandeja del sistema, como un pequeño icono de notificación. Ahora ya estamos listos para el siguiente paso.


Configurando PuTTY:

La configuración en PuTTY es extremadamente sencilla, ya que únicamente vamos a tener que marcar una casilla de tipo checkbox. Para ello, y antes de iniciar la sesión SSH, nos vamos a "Connection" - "SSH" - "X11" y marcamos la opción "Enable X11 forwarding" tal y como os he dejado en la captura inferior:

Opción a marcar en PuTTY para soporte X11

Ahora lanzamos cualquier aplicación que necesite X11, en mi caso uGet, y observamos como se nos abre en nuestro Windows. Un consejo para los que quieran dejar la sesión SSH libre para hacer otras cosas mientras seguimos trabajando con la aplicación de X es añadir el carácter "&" detrás del comando de aplicación a lanzar, es decir, si en mi caso lanzo "uget-gtk" sería "uget-gtk &" y así dejo la terminal libre, sin esperar a que acabe la aplicación que acabo de lanzar para hacer otra cosa.

Espero que el pequeño tutorial os sea útil y no olvidéis comentar o mandarme sugerencias, ideas o lo que os apetezca tanto por aquí como por mi cuenta de Twitter @drkbcn, en la que suelo comentar con otros blogueros muchas cosas interesantes. 

Un saludo y hasta pronto.

Asegurando tu servidor Raspbian: cazando rootkits

Todos sabemos que lo más importante en un servidor es la seguridad, de ahí que Linux sea una de las decisiones más acertadas a la hora de montar uno. Por si no lo sabías Linux está prácticamente libre de virus, y en caso de salir alguno poco sentido tendría al trabajar siempre desde una cuenta de usuario que no puede infectar nada del sistema (por no hablar que en horas tendríamos un fantástico parche para él en los repositorios) pero... no estamos tan seguros como pueda parecer. 

Generalmente el mayor peligro de un servidor es un usuario que no lo sabe administrar, esto suele acabar con puertos ofreciendo servicios sin protección adecuada, cuentas sin contraseñas seguras o incluso sistemas no actualizados vulnerables a fallos de seguridad (exploits) por lo que nuestras reglas de oro van a ser las siguientes:

  • No trabajar de forma habitual con cuenta de administrador. Es decir, el usuario root. Es uno de los mayores problemas de la gente que viene de Windows, acostumbrada a tener privilegios en todo el sistema sin necesidad de hacer nada en especial.
  • Tener nuestros paquetes al día mediante apt-get (en Debian -Raspbian en nuestro caso-, que ya me veo a algún lector saltándome al cuello por no especificar).
  • No dejar contraseñas por defecto en nada.
  • No instalar servicios que no necesitamos.
  • De forma regular revisar nuestros ficheros log, en busca de intentos de logueo erróneos (podéis ver un registro de todo en /var/log/auth.log).
  • Utilizar rkhunter.
La ventaja de rkhunter es que tanto es válido en nuestra Raspberry Pi con distribuciones basadas en Debian, en máquinas normales y prácticamente hasta en la tostadora de pan, ya que disponemos del código fuente de la aplicación para poderla compilar en caso de no existir el paquete en nuestros repositorios.

Instalando rkhunter desde repositorios:

Para empezar voy a explicaros qué es rkhunter y para qué sirve. rkhunter es un detector de rootkits, backdoors y similares en nuestro sistema, mostrándonos un completo informe y avisos de posibles "infecciones" o fallos en el sistema. Si no sabéis el significado de dichas palabras os las he enlazado con su correspondiente definición en Wikipedia, que está perfectamente explicado. En pocas palabras, rkhunter va a ser nuestro chivato de aplicaciones no deseadas en nuestro servidor.

Afortunadamente la instalación es sencillísima en Raspbian, ya que contamos con los paquetes de la aplicación en los repositorios por defecto. Para ello abriremos una terminal y escribimos:

sudo apt-get install rkhunter


Analizando el sistema:

Una vez finalizada la instalación lanzaremos un análisis completo de la máquina con:

sudo rkhunter -c


Veremos una pantalla similar a la siguiente:

rkhunter en pleno análisis


Mientras nos salga todo en verde, ya sea con "OK", "Not found", etcétera no deberemos preocuparnos de nada, de hecho incluso algunos "Warning" no deben escandalizaros, ya que simplemente nos avisan de un peligro potencial que, de estar todo bien hecho y configurado, no entrañará ningún riesgo en nuestra máquina.

rkhunter puede analizar la máquina de forma desatendida, es decir, sin que tengáis que ir dando al "Enter" en cada fin de sección e incluso puede analizar de forma independiente lo que nos interese. Si necesitáis más información de lo que puede hacer bastará con que escibáis en una terminal:

man rkhunter


Y consultéis el manual del programa. Cuando finalice de analizar todo os generará un resumen de vuestra máquina en el directorio de logs (recordad: /var/log) con ruta /var/log/rkhunter.log.

Espero que con este tutorial exprés haya conseguido hacer de vuestra máquina un lugar más seguro y libre de indeseables aplicaciones o usuarios.

Nos leemos muy pronto y recordad que me tenéis en Twitter en @drkbcn.