Spiga

Cubieez 1.0 para A20 con aceleración gráfica

Tras varias semanas de inactividad (por sobrecarga de trabajo, ya se sabe que la vuelta de vacaciones es dura :P) os traigo una nueva versión de Cubieez. Como mejora principal, a parte de una mayor velocidad y rendimiento, incluye el esperado soporte para aceleración gráfica, tanto 3D mediante MALI, como 2D por G2D y de vídeo con CedarX.

Volvemos a tener el mismo reducido tamaño, ampliable posteriormente con "cubie-config", de 2GB como requisito de espacio en una microSD. De esta manera sigue siendo una de las distribuciones más completas para Cubieboard (y dispositivos A20) con un reducido tamaño.

Las novedades son:
  • Nuevo Kernel 3.4.43 en modo rendimiento (performance)
  • I/O Scheduler en NOOP que consigue mejor rendimiento en dispositivos flash
  • Nuevo cubie-config script, arreglando algunos fallos anteriores
  • Soporte para MALI + G2D + CedarX (aceleración gráfica completa, aunque en pruebas)
  • Arranque en modo "verbose"
  • MAC estática (uEnv.txt)
  • Iceweasel actualizado
Por el momento la versión para A10 no ha sufrido cambios relevantes para necesitar una actualización, así que no os preocupéis por no tener esta versión para vuestro dispositivo.

Puedes encontrar toda la información en el siguiente hilo en los foros oficiales de Cubieboard pulsando AQUÍ.

Cubieboard (A20) ya está aquí

Hola de nuevo a todos, soy David Rodríguez, @NeoDaVe,. Muchos de vosotros no me conoceréis ya que hace mucho que no aparezco por aquí. Soy aquel  que hace ya más de 6 años empezó a escribir sobre GNU/Linux en este blog, un blog que ha vuelto a revivir con más fuerza que nunca gracias al gran Manel Alonso, @drkbcn.


(Contenido de CubieBoard A20)

Con este artículo quiero volver a retomar la rutina de publicar en el blog y nada mejor que hacerlo que con un nuevo cacharrito con el que experimentar. Se trata de un Cubieboard (A20), un embedded system, que cuenta con las siguientes opciones:

Características a destacar del Cubieboard (A20) :
  •     Procesador: Dual core ARM cortex-A7, NEON, VFPv4, 256KB L2 cache
  •     GPU (Procesador gráfico) : Mali400mp2, OpenGL ES GPU
  •     Memoria : 1GB DDR3 a 960MHz
  •     Salida de vídeo : HDMI 1080p
  •     Salida de audio: 3.5mm jack, HDMI
  •     Ethernet: 10/100M RJ45
  •     Memoria: NAND Flash 4Gb
  •     2 puertos USB, 1 puerto micro SD, 1  puerto SATA, 1 puerto de infrarrojos
  •     I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP.
  •     Dimensiones: 10cm x 6cm x 2cm

Fotos:



 

Poco más me queda decir por ahora. En próximos artículos tratare sobre configuraciones e instalación de Cubieez, la distro para Cubieboard que esta desarrollando Manel Alonso.

Cubieez RC2 lista para descarga

Seguimos en racha. Tras las buenas opiniones recibidas en el foro y con un poquito de trabajo he liberado la segunda candidata de Cubieez. Trae bastantes novedades respecto la primera versión que harán las delicidas de los que buscan poder vídeos en Youtube y webs similares así como de los no tan experimentados en configuración del sistema desde bash.

He intentado seguir en la línea anterior, sin sobrepasar el requisito de una tarjeta de 2Gb y dejando unos 400 Mb libres de espacio, pudiéndose adaptar a tamaños superiores si es necesario gracias a la inclusión de una herramienta automática de redimensionado de particiones.

Algunas de las mejoras son:

  • Youtube, Dailymotion, Crackle y otras web con flash soportadas con Gnome Mplayer plugin (de momento únicamente en la cuenta de root, a ver si alguien me sabe decir la base del problema :P)
  • Cubie-config script, modificado de Raspbian para actualizar locales, timezone, SSH, hostname, expandir el rootfs y alguna cosa más.
  • Completado de comandos bash
  • Nuevas herramientas gráficas de Gnome (sin todas sus dependencias "basura")
  • Conversores HDMI/VGA soportados (gracias a Raspipc.es por enviarme uno para testeo)  
  • Ctrl + Alt + t lanza Terminal
  • sunxi-tools compilado y ficheros fex para dispositivos A10 para generar tu propio script.bin (@ /root)
  • Algunos fallos arreglados y mejora de rendimiento
Espero poder solventar el problema de los vídeos en las cuentas de usuario normal, ya que la navegación y el uso de la cuenta de root, como todos sabemos, está totalmente desaconsejado.

Ya podéis descargarla del foro oficial de Cubieboard (A10) AQUÍ.

Actualización 21/07/2013:

Ya tenemos versión para Cubieboard 2 (A20) AQUÍ.

Convirtiendo HDMI a VGA en Raspberry Pi / Cubieboard

Buenas a todos! Ayer trasteando la web de Raspipc.es encontré un conversor activo de HDMI a VGA (dejaros de esos cables que venden en eBay que no van a funcionar de ninguna de las maneras). Para los que no disponemos de conector HDMI en el monitor es un imprescindible, porque más de una bronca me he ganado ya por estar todo el día ocupando el televisor del salón para hacer mis pruebas.

Mi idea era probarla con Cubieboard, ya que todos sabemos que con Raspberry Pi funciona a las mil maravillas, así que les pregunté si habían probado la compatibilidad. Amablemente me han hecho llegar el conversor, podríamos decir que casi volando, ya que estaba en casa en poco más de 12 horas (pocas tiendas pueden alardear de ser tan eficientes) para que lo pruebe por todos vosotros. He estado haciendo varios test e inicialmente pensaba que no iba a funcionar ya que había leído casos en la red con cables similares y Cubieboard que no habían tenido un feliz desenlace. Las primeras pruebas en Linux no acabaron demasiado bien: imagen desplazada y sin opción de poderla escalar a la proporción del monitor, pero tras darme cuenta que en Android funcionaba a las mil maravillas se me encendió la bombilla. Me puse a investigar las causas, puesto que si el hardware es el mismo no puede haber otro culpable más que el software, y di con el culpable.

Conversor HDMI a VGA de los chicos de Raspipc
Si lo vais a usar en Raspberry no hay ningún problema, ya que acepta sin problemas cualquier resolución que vuestro monitor soporte, en cambio en Cubieboard deberéis aseguraros que el monitor va a soportar una de las siguientes resoluciones y que vuestro Kernel está compilado para tal:

0:480i
1:576i
2:480p
3:576p
4:720p50
5:720p60
6:1080i50
7:1080i60
8:1080p24
9:1080p50
10:1080p60
11:pal
14:ntsc

Siendo el primer número el ajuste necesario en vuestro script.bin (generado a través del fex para Cubieboard A10) y aplicando como válidos aquellos que están en negrita (los que funcionan a 60Hz, a 50Hz la imagen queda deformada). Vale, más de uno estará pensando que se le escapa de las manos toda esta configuración y la manera de aplicarla, así que os he preparado una agradable sorpresa:

Cubieez en su versión RC2 viene totalmente preparada para enchufar y listo. He modificado los ficheros de configuración y arranque para que si alguno se decide a comprar el cable pueda usarlo de forma directa sin ningún problema. Así que ya sabéis, tenemos ya un cable 100% confirmado en funcionalidad y una distribución lista para usarlo sin problema (y si alguno quiere usar otra ya sabe que puede recurrir el script.bin de Cubieez RC2)

Link al producto en Raspipc.es: Pi-View.
Link a Cubieez RC2: Release en las próximas 24 horas en Cubieez.com

Espero poder despejar las dudas de todos los usuarios del "mono" que no se atreven a comprar un conversor y acabar de animar a los de la "frambuesa" a hacerse con este fantástico cable comercializado por los chicos de Raspipc, que desde ya forma parte de mis imprescindibles.

Un saludo y nos leemos muy pronto con la salida de la segunda versión de Cubieez.



Redimensionando particiones

Hoy vamos a poner un tutorial que me ha hecho llegar Isaac Chavarría (ikeeki en Cubieforums) sobre el redimensionado de particiones. Muchas veces te habrás encontrado que al bajar un fichero "img" para Raspberry o Cubieboard está preparado para una SD mayor a lo que tenías pensado utilizar, por lo que únicamente tenías la opción de comprar una tarjeta de tal capacidad... hasta ahora.

El tutorial es una traducción del original posteado aquí, pero no va a haber problemas contando que Isaac es español y que la traducción la ha hecho él mismo ;)

Sin más os dejo con el "howto".

REQUISITOS GENERALES: 
  • Una máquina con Linux.
  • Realizar una copia de seguridad de la SD a reducir/aumentar. 
  • Tener GParted instalado.
Primero realizaremos la copia de seguridad de nuestra tarjeta. Para ello utilizaremos dd y el formato "img". Escribimos lo siguiente en terminal (requiere permisos de root):


dd if=/dev/unidad of=/destino/nombredelbackup.img bs=1M


Por ejemplo, suponiendo que mi unidad fuese "sdb" y el destino mi carpeta de usuario:


dd if=/dev/sdb of=/destino/nombredelbackup.img bs=1M


EXPANDIENDO PARTICIÓN:

La parte fácil. La microSD con el S.O. debe estar conectada mediante un lector a la PC. Normalmente y tratándose de Raspberry Pi o Cubieboard, el sustema nombrará a sus particiones como sdb1 y sdb2 si no tienemos más unidades conectadas que la propia donde ejecutamos nuestro sistema operativo (nuestro disco duro).

Si no estás seguro puedes ver un listado de particiones ejecutando el siguiente comando:

Abre GParted, ve a botón redimensionar/eliminar, arrastra lo que quieras la barra hacia tu derecha aplica cambios y ya está hecho.

También puedes hacer uso del siguiente script de consola.

ENCOGIENDO PARTICIÓN:

Lo primero que tenemos que tener en cuenta para hacer un "shrink" de la partición es que haya menos datos ocupados en dicha partición que el tamaño de la nueva que vamos a realizar. Obvio, un litro de agua no cabe en una taza de té (al menos en España). Procura dejar un margen de unos 100 MiB extra, por si acaso.

Primero ejecutaremos en consola lo siguiente:

df -h 

Así nos haremos una idea de los espacios ocupados. Suponiendo que rootfs está montado en sdb2 (como siempre), usamos en terminal con permisos de administrador:
umount /dev/sdb1 /dev/sdb2

Que desmontará las particiones en uso del sistema. Ahora pasamos a redimensionar sdb2 con resize2fs:

fsck -f /dev/sdb2
resize2fs /dev/sdb2 3800M


Uso 3800M como ejemplo, como si quisieras encoger el contenido (3,5GB) de una SD de 8GB para que lo puedas copiar en una SD de 4GB y te ahorres la de 8GB para las fotos de la boda de tu primo.

¡¡¡ATENCIÓN!!! las tarjetas SD son normalmente más pequeñas que lo que dice el fabricante, por ejemplo:

Kingston sdcard: 3904 MB, 3904897024 bytes
Trascend sdcard: 3963 MB, 3963617280 bytes

Ahora desmonta todos los dispositivos y abre de nuevo GParted. Al principio solo te permitirá reducir el tamaño de la partición (botón redimensionar/eliminar) más de unos pocos megas, pero hazlo de todas formas.

Captura de pantalla de GParted


Cierra GParted y reábrelo o simplemente refresca dispositivos. ¡Sorpresa! Ahora puedes reducirlo hasta lo que tenías planeado. Acuérdate de dejar al menos 100 MiB libres. Fíjate que tienes un montón de espacio muerto "unallocated" en la parte derecha de la barra, una no tocada (sdb1) y una reducida (sdb2) en medio que debería caber en la nueva SD.

Para finalizar apunta los bloques en información de sdb2, que nos servirá para saber cuanto ocupan. También puedes ir a terminal y escribir:

fdisk -l


Y anotar los bloques utilizados. Por ejemplo mi salida ha sido:

Disco /dev/sdb: 7882 MB, 7882145792 bytes
243 cabezas, 62 sectores/pista, 1021 cilindros, 15394816 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador del disco: 0x00062524

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1            2048       30719       14336    c  W95 FAT32 (LBA)
/dev/sdb2           30720     7567359     3768320   83  Linux
root@ikeeki-Extensa-5635Z:/home/ikeeki#

Usa 3768320 bloques.

Nos vamos a quedar con la cantidad de bloques, en este caso 3768320. Ahora haz una imagen o flashea la nueva (y más pequeña SD) con los bloques de uno de los métodos anteriores.

Para hacer la imagen, y siguiendo ejemplo anterior:

dd if=/dev/sdb of=/home/ikeeki/Escritorio/cubiuntu4.0b.img bs=1k count=3768320
 

Para flashear una nueva SD, llamada sdc (recuerda que puedes ver nombre con fdisk -l)


dd if=/dev/sdb of=/dev/sdc  bs=1k count=3768320


Y con esto ya tendríamos solucionada la papelete. Por último recuerda tener mucho cuidado con los dispositivos que escribes, puesto que un desliz puede dejarte sin información en un disco duro.


Y hasta aquí con el tutorial cedido por Isaac, al que aprovecho una vez más a darle las gracias por su colaboración y buen rollo que estamos teniendo en el desarrollo tanto de Cubiuntu como Cubieez.

Cubieez, Debian para Cubieboard A10 (actualizado)

Hace justo unos días os decía que estaba colaborando con el creador de una de las distribuciones de escritorio más usadas en Cubieboard: Cubiuntu. Tras compilar el último Kernel estable me aventuré a dar un paso más y tras varios días de trabajo tengo casi finalizada mi propia distribución que, junto con Isaac (ikeeki en cubieforums), estoy en fase de testeo.

Por el momento el rendimiento es bastante bueno, mucho mejor que la mayoría de las distribuciones que se encuentran para descarga actualmente (ya que suelen basarse en imagenes hechas para otros dispositivos con Allwinner A10).

Las características son las siguientes:
  • Kernel 3.4.43 de linux-sunxi, compilado con soporte ARMHF
  • Basado en Debian 7.1 Wheezy, creado el rootfs desde cero.
  • Soporte para iptables
  • Soporte para la mayoría de Wi-Fi USB
  • Reloj sincronizado con Internet (casi ninguna distro lo lleva)
  • Soporte aceleración 3D con MALI 400, aceleración 2D con G2D
  • Compilado propio de drivers y útiles
  • Repositorios armhf de Debian 7.1
  • Escritorio LXDE base, con consumo aproximado de 70 MB de RAM (un 10% del total)
  • Soporte de audio completo, salida por HDMI y jack (sun4i codec)
  • Soporte para de actividad microSD con LEDs de placa
  • X11VNC, SSH, Mplayer y otras utilidades instaladas
  • 1,5GB totales instalados. Descargable en comprimido menor a 600MB (microSD 2GB)
Cubieez en su versión de testeo

Si algún bloguero, poseedor de Cubieboard A10, se anima a probar la versión de testeo que me lo comunique vía Twitter y le paso el enlace de descarga. Por el momento os puedo decir que va francamente bien y que, con toda probabilidad, estará esta misma semana en los foros oficiales para descarga.

Como veis he estado trabajando duro en estos últimos días y BeLinux estrena distro propia.

ACTUALIZADO:

Descarga de Cubieez

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.

Liberando espacio en tu Raspberry Pi

Uno de los problemas que nos encontramos con nuestras pequeñas es el escaso espacio que nos dejan las tarjetas SD. En caso que quieras ganar espacio en el sistema de ficheros (rootfs, del Inglés Root File System) puedes seguir el tutorial de "Arrancando la Raspberry Pi desde un disco duro" que ya vimos hace un tiempo. Si por el contrario lo tuyo no es liarte con configuraciones puedes probar con lo que hoy vamos a explicar.

En nuestro rootfs tenemos infinidad de carpetas que, con el uso del sistema, van aumentando de tamaño. Una de estas carpetas la encontramos en "/var/cache/apt/archives/", pero... ¿qué contiene dicha carpeta? 

Respuesta: Todos los ficheros .deb que hemos ido descargando para instalar con apt o aptitude

En principio es una ventaja, porque si eliminamos mediante remove o purge un paquete del que posteriormente nos arrepentimos de haber desinstalado, podemos volver a instalarlo sin tener que descargarlo de nuevo, ahorrando así el uso de recursos y tiempo en el sistema. Todo muy bonito, sí, pero muchos partimos con una SD de apenas 4 GB y no estamos para ir gastando espacio en "por si me lo vuelvo a descargar".

Limpiando el directorio de caché de APT

Para limpiar toda la cache de apt tenemos que lanzar un simple comando:

sudo apt-get clean

Eso sí, pensad que si volvéis a pedir un paquete que ya habíais descargado, os tocará volverlo a descargar de nuevo. Creo que merece la pena por rascar un poquito de espacio, ¿no?

Existen más maneras de liberar espacio en nuestro disco, como por ejemplo eliminando los paquetes huérfanos del sistema, que son aquellos que han quedado sin uso después de haber borrado el programa o programas del que eran dependencias. Para ello vamos a utilizar una herramienta de uso muy simple y que paso a explicaros a continuación.

Instalando Deborphan y borrando paquetes huérfanos

Para instalar deborphan simplemente escribiremos en nuestra terminal lo siguiente:

sudo apt-get install deborphan

Deborphan puede listarnos todos los paquetes huérfanos y desde ahí vamos diciéndole a APT que los elimine o purgue del sistema, aunque podemos utilizar una herramienta "gráfica" para terminal que se incluye en Deborphan: orphaner.

Para ejecutar orphaner bastará con poner en nuestra terminal:

sudo orphaner


Captura de pantalla de orphaner

Marcamos mediante la barra de espacio aquellos que deseamos eliminar y para finalizar pulsamos en "OK". Existen otras maneras de eliminar todo sin hacer uso de orphaner, como por ejemplo:

sudo apt-get purge $(deborphan)

Que le mandará la salida de "deborphan" a "sudo apt-get purge", es decir, eliminará cada uno de los paquetes huérfanos listados.

Y por último camos comprobar el espacio que nos ha quedado libre en disco mediante el uso del comando:

df

Espero que os haya sido de utilidad. ¡Nos vemos en el próximo tutorial!

Controlando la Raspberry Pi (Raspbmc) por IR

¡Buenas de nuevo! Después de otro tiempo de inactividad volvemos a la carga con un tutorial para novatos que hará las delicias de muchos.

Hace apenas un mes recibí un correo de un seguidor del blog que me pedía si podía hacer un tutorial sobre control por IR (infrared). Como me pareció una propuesta interesante pedí el componente necesario para hacerlo, que es tan sencillo y simple como un TSOP 4838.

Para los que no sean entendidos en el tema, que me incluyo, el TSOP 4838 es un receptor de infrarrojo que funciona de 2,5 a 5,5v según su datasheet, aunque nosotros lo vamos a hacer funcionar a los 3,3v que nos dan de salida los pines de GPIO de la Raspberry Pi. No os preocupéis porque funciona de maravilla.

Imagen ampliada de un TSOP 4838


El precio es de risa, y es que podemos adquirirlo en Farnell / element14 por menos de 1€. Os dejo con el enlace para los que queráis comprarlo:

Comprar TSOP 4838 en la web de Farnell España

Las ventajas son muchas si trabajamos con una distribución como Raspbmc, ya que nos va a permitir controlar XBMC con cualquier mando que tengamos en casa, sin necesidad de vernos limitados a la función CEC que implemente nuestra TV con el mando (contando que contemos con una TV con dicha característica, claro). Sin ir más lejos yo he reaprovechado un mando multimedia que tenía abandonado de mi Xbox y le he dado un nuevo uso.

Lo primero que vamos a hacer es preparar el receptor. Para ello he utilizado lo siguiente:

  • Receptor IR TSOP 4838
  • Tubo (macarrón) termoretráctil para evitar hacer soldaduras o dejarlas al aire
  • Tres cables del panel frontal (FPANEL) de un PC viejo, para no soldar a los pines GPIO
Lo que he hecho ha sido pelar los extremos de los cables del panel frontal, si mal no recuerdo el del reset y el del power, aunque da lo mismo los que uséis ya que el objetivo es aprovechar los conectores para los pines de la Raspberry. Un vez pelados he insertado en ellos el tubo termoretráctil y lo he calentado con un mechero para que haga la "soldadura" (vale, no lo hace, pero esto va a ir genial para aquellos que no tengan un soldador en casa o directamente no tengan los conocimientos para hacerlo). Os dejo con una foto del momento justo anterior a calentar dicho tubo con un mechero:

TSOP4838 con termoretráctil listo para "calentar"

El resultado final debería ser algo parecido a lo siguiente:

Una vez calentado el tubo para que hagan contacto las patas del TSOP con el cable


Ahora vamos a conectar directamente a la Raspberry. Para ello me he guiado de una excelente representación de los pines que tenemos en los foros de Stmlabs (Raspbmc). Os dejo con la imagen en cuestión para que sepáis como hay que conectar el TSOP.

Esquema de conexión a GPIO


En resumidas cuentas y para que no tengáis que comeros la cabeza: el pin 1 del TSOP al 18 de la Raspberry (DATA), el pin 2 del TSOP al 6 de la Raspberry (GROUND) y por úlitmo el pin 3 del TSOP al pin 1 de la Raspberry (3,3v).

Una vez conectado, y si no la hemos hecho nada mal a la hora de calentar el tubo termoretráctil. ya tendremos nuestro receptor funcional. La parte que viene a continuación ya es de software y vamos a necesitar Raspbmc, del que ya os he dado el enlace anteriormente. La ventaja de su última versión es que ya viene con LIRC instalado y preconfigurado, por lo que vamos a tener que hacer poquita cosa para poder ponerlo todo en marcha. De nuevo, para los que no sepan qué es os puedo decir que LIRC es un software que permite leer las entradas que hacemos por IR y, dependiendo de lo que queramos, tomar control de programas multimedia o ejecutar comandos mediante el uso del fichero lircrc (ver sección "The .lircrc file format").

Como os decía antes en Raspbmc -en su última versión estable- ya viene todo instalado y listo para que procedamos a la configuración, por lo que lo primero que debéis hacer es saber si vuestro mando se encuentra entre los ya configurados por los usuarios. Si tienes la gran suerte de tener uno de ellos puedes copiar el fichero en tu directorio personal con el nombre "lircd.conf". En mi caso no ha sido así y me he hecho mi propia configuración, ya de paso he subido el fichero y espero que vosotros aportéis el vuestro.

Paso 1:
Vamos a detener el servicio de LIRC para comprobar si nuestro receptor esta funcionando correctamente. Para ello entraremos por SSH y escribiremos lo siguiente:

sudo service lirc stop

Deberá responderos con:

pi@raspbmc:~$ sudo service lirc stop
[ ok ] Stopping remote control daemon(s): LIRC:.

Ahora probaremos a ejecutar mode2 con:

mode2 -d /dev/lirc0

Paso 2:
Si presionamos cualquier tecla de nuestro mando deberían salir un montón de letras en pantalla, de lo contrario revisa las conexiones del receptor y comprueba que esté conectado en los pines correctos (o eso o el receptor está muerto :P) Suponiendo que todo haya ido correctamente listaremos todas las posibles teclas a las que podemos asignar una función, para ello escribimos:

irrecord --list-namespace

Anotad todas aquellas que os puedan servir en Raspbmc, como por ejemplo KEY_STOP, KEY_PLAY, etc. Podéis ver el listado de las que he mapeado yo aquí, ya que me están funcionando todas sin problemas.

Paso 3:
Ahora pasaremos a crear nuestro fichero de configuración y asignaremos las teclas al mando. Para ello volvemos a escribir en la shell:

irrecord -d /dev/lirc0 ~/lircd.conf

Os pedirá que presioneis tantos botones del mando como sea posible hasta rellenar dos líneas de puntos en pantalla, es importante seguir las instrucciones que os va dando, porque de lo contrario no funcionará de forma posterior. Llegará un momento que os pedirá el nombre del botón que queréis asignar, y es entonces cuando debéis escribir los nombres que hemos obtenido en el paso 2 y presionar el botón al que queréis asignar dicha función.

Cuando hayáis terminado con todas las teclas deseadas pusláis "Intro" y debería haberos guardado un fichero de nombre lircd.conf en vuestro directorio personal en /home/pi. Con esto tenemos toda la faena hecha, por lo que volvemos a iniciar LIRC con:

sudo service lirc start

Paso 4:
Ahora falta decirle a Raspbmc que vamos a usar control remoto por IR, para ello nos vamos al configurador que tenéis en "Programas" dentro del propio XBMC, a la pestaña de "IR Remote" y allí marcad la opción "Enable GPIO TSOP IR Receiver" y "GPIO IR Remote Profile" seleccionad "Custom", que irá a cargar el fichero lircd.conf de nuestro directorio home.

Ahora os pedirá reiniciar para aceptar la nueva configuración y... ¡listo! Ya tenéis vuestro mando funcionando en Raspbmc.

Os dejo con un vídeo del mío funcionando para que os hagáis una idea.

Un saludo y espero haber sido de utilidad.