27 nov 16 Receptor GPS GlobalSat BU-353-S4 en Debian
Hace un rato he recibido en casa un receptor GPS modelo GlobalSat BU-353-S4 que he comprado para un proyecto que tengo en mente.
GlobalSat-BU-353-S4
Este receptor está soportado perfectamente en linux (algo clave para mi proyecto). De momento, he podido comprobar que funciona perfectamente con gpsd y cgps:
Captura de pantalla de cgps
En apenas unos segundos ha localizado mi ubicación actual.
En cuanto al proyecto en sí, no adelantemos acontecimientos. Pero incluye una Raspberry Pi y un emisor OBD-II por bluetooth (sí, todo es mejor con Bluetooth). 
Etiquetas: debian, globalsat bu-353-s4, gpsd, odb-ii
12 oct 13 Cómo instalar una tarjeta TP-Link TL-WN725N v2 en raspbian
…o en xbian, o en cualquier otro sistema operativo linux para Raspberry Pi. Uno de los problemas que estoy viendo que son más habituales a la hora de manejarse con la RPi es que las tarjetas de red inalámbricas por USB no suelen disponer de drivers adecuados para funcionar.
TP-Link TL-WN725N v2
O al menos, las dos que yo he comprado, adolecían de este problema. ^_^ En el caso concreto de la TP-Link TL-WN725N, existen, al parecer, dos versiones: la v1 hace uso del chipset RealTek RTL8188CUS (que sí cuenta con soporte nativo en la RPi), la v2 utiliza el chipset RTL8188EUS, que no lo tiene, por lo que es preciso andar compilando, algo que en la RPi suele ser un tanto doloroso. Pero que, dado que se cuenta con fuentes adecuadas, tampoco es excesivamente complicado.
Lo que sí hay que tener en cuenta, según he podido descubrir, es que el driver, compilado directamente de las fuentes, tiene dos problemas tal y como viene de fábrica: el led de estado no funciona, y vuelca demasiada información de debug en los logs de sistema. Esto último, en el caso de la RPi, que hace uso de tarjetas microSD para albergar el sistema operativo, puede ser bastante grave, tanto por problemas de rendimiento como por desgaste del dispositivo. Por suerte, se puede modificar la fuente del código para solventar este problema antes de la instalación. Los pasos a seguir son los siguientes:
Obtener el código necesario para compilar el driver
git clone https://github.com/liwei/rpi-rtl8188eu.git
git clone –depth 1 git://github.com/raspberrypi/linux.git rpi-linux
git clone –depth 1 git://github.com/raspberrypi/firmware.git rpi-firmware
Modificar el fichero rpi-rtl8188eu/include/autoconf.h
Es preciso modificar dos aspectos: descomentar la línea #define CONFIG_LED, y comentar la línea #define CONFIG_DEBUG_RTL819X. En el siguiente diff puede verse de manera más clara:
diff -Nauw ~/src/pi_plus/linux/drivers/net/wireless/rtl8188eu/include/autoconf.h include/autoconf.h
— /home/pi/src/pi_plus/linux/drivers/net/wireless/rtl8188eu/include/autoconf.h 2013-05-02 19:39:42.177227144 +0100
+++ include/autoconf.h 2013-05-03 00:22:52.383030986 +0100
@@ -156,7 +156,7 @@#define CONFIG_SKB_COPY 1//for amsdu
-//#define CONFIG_LED
+#define CONFIG_LED
#ifdef CONFIG_LED
#define CONFIG_SW_LED
#ifdef CONFIG_SW_LED
@@ -328,7 +328,7 @@
//#define CONFIG_DEBUG_RTL871X#define DBG 1
-#define CONFIG_DEBUG_RTL819X
+//#define CONFIG_DEBUG_RTL819X#define CONFIG_PROC_DEBUG 1
Compilar e instalar el driver
Seguimos con la receta anterior:
cd rpi-linux
make mrproper
zcat /proc/config.gz > .config
make modules_prepare
cp ../rpi-firmware/extra/Module.symvers .
cd ../rpi-rtl8188eu
CONFIG_RTL8188EU=m make -C ../rpi-linux M=`pwd`
sudo rmmod 8188eu
sudo install -p -m 644 8188eu.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless
sudo depmod -a
sudo modprobe 8188eu
Con todo ello, quedará correctamente instalado el driver para poder utilizar esta tarjeta.
Las fuentes de este artículo son las siguientes:
- http://tech.enekochan.com/2013/05/29/compile-and-install-driver-for-tp-link-tl-wn725n-version-2-in-raspbian/?lang=es
- http://www.raspberrypi.org/phpBB3/viewtopic.php?p=342405#p342405
Bonus extra
En la raspbian pelada y mondada, tal y como viene de fábrica, no se disponen de los elementos necesarios para compilar drivers, ni para hacer funcionar una tarjeta wifi. Es necesario, al menos, instalar lo siguiente:
- build-essentials para poder compilar
- git para descargar los respositorios
- wireless-tools, usbutils y wpa-supplicant para poder conectar correctamente a una red wifi con cifrado WPA/WPA2
Para realizar la instalación de lo anterior, lo de siempre en sistemas de la familia Debian:
apt-get install build-essentials git wireless-tools usbutils wpa-supplicant
Etiquetas: debian, raspberry pi, raspbian, rpi, tl-wn725n, tp-link
05 feb 11 Modificaciones en el servidor: fachada nginx
Estas semanas, cuando el trabajo y la salud me lo han permitido, he estado realizando algunos cambios en el servidor. Como comenté anteriormente, el más importante ha sido el cambio de su ubicación: ha pasado de ser un servidor virtual VMWare ubicado en Córdoba a ser un servidor físico emplazado en Sevilla. Y ya que estaba de cambios, me decidí a probar un servidor web del que llevaba tiempo escuchando hablar: nginx.
nginx es un servidor web/proxy inverso ligero de alto rendimiento y un proxy para protocolos de correo electrónico (IMAP/POP3). Es software libre y de código abierto, licenciado bajo la Licencia BSD simplificada. Es multiplataforma, por lo que corre en sistemas tipo Unix (GNU/Linux, BSD, Solaris, Mac OS X, etc.) y Windows.
El sistema es empleado en una larga lista de sitios web conocidos, como: WordPress, Hulu, GitHub, Ohloh, SourceForge y TorrentReactor. Originalmente, nginx fue desarrollado para satisfacer las necesidades de varios sitios web de Rambler que recibían unas 500 millones de peticiones al día en septiembre de 2008.
De acuerdo con el estudio de Netcraft, Netcraft’s May 2010 Web Server Survey, nginx fue el tercer servidor web más usado en todos los dominios (6.55% de los sitios estudiados) y el cuarto servidor web más usado en los sitios activos (8.77% de los sitios estudiados).
Sus características básicas son las siguientes:
- Servidor de archivos estáticos, índices y autoindexado
- Habilitado para soportar más de 10.000 conexiones simultáneas
- Proxy inverso con opciones de caché
- Balance de carga
- Tolerancia a fallos
- Soporte de HTTP sobre SSL
- Soporte para FastCGI con opciones de caché
- Servidores virtuales basados en nombre y/o en dirección IP
- Streaming de archivos FLV y MP4
- Soporte para autenticación
- Compresión gzip
- Capacidad de reescritura de URLs
- Sistema de log personalizable
- Soporte WebDAV
La arquitectura interna de nginx le permite servir más peticiones por segundo con menos recursos que sus principales alternativas. Ésta consiste en un proceso maestro que delega el trabajo en uno o varios procesos “worker”. Cada worker gestiona múltiples peticiones de modo basado en eventos, o bien asíncrono, haciendo uso de funcionalidades especiales del kernel Linux (epoll/select/poll). Esto permite a nginx gestionar un gran número de peticiones concurrentes de una manera rápida y con muy poca sobrecarga. Por ejemplo, un servidor Apache puede ser configurado para procesar las bien una petición por proceso (pre-fork) o bien una petición por cada hilo (worker). Aunque el modo basado en hilos de Apache tiene un rendimiento mucho mejor que el basado en procesos, sigue haciendo uso de mucha más memoria y CPU que la arquitectura basada en eventos de nginx.
En mi caso concreto, mi servidor web contiene las siguientes aplicaciones:
- Una bitácora. La que estás leyendo, que utiliza WordPress. Necesita PHP y una base de datos MySQL
- Un sistema de almacenamiento de fotografías. Utiliza Gallery2. También necesita PHP, MySQL, y una serie de molestas reescrituras
- Una serie de aplicaciones menores de mantenimiento y de gestión de logs. Por lo general, usan PHP, CGI, y alguna de ellas MySQL
Mi objetivo primordial era realizar un reemplazo completo del servidor Apache, motivado por las siguientes razones: el cambio del servidor me ha dejado con menos recursos hardware (en concreto, con menos RAM y con un procesador menos potente), y sobre todo, comprobar si nginx es tan bueno como lo vende.
A la hora de realizar el cambio, pude comprobar algo que es bastante importante: nginx es un servidor web de ficheros estáticos. Esto quiere decir que si estás pensando en sacar a través de él páginas web dinámicas tienes un problema. Por suerte es un problema fácilmente abordable, ya que al estar pensado desde el principio como un servidor proxy inverso, tienes la capacidad de delegar funcionalidades no soportadas en otros servidores adicionales. En mi caso, instalé en mi servidor Debian un servidor PHP externo, spawn-fcgi, que escucha peticiones por el puerto 9000.
La migración de WordPress no supuso mayor problema, una vez solucionado el tema anterior. Sin embargo, la de Gallery2 sí me ha planteado más dificultades, debido a una serie de reescrituras un tanto especiales que necesita para mantener funcionando el sistema. Tras varios días de pruebas, y viendo que no alcanzaba a migrar completamente esta aplicación, decidí darle un cambio de perspectiva: mantener el servidor Apache como un servidor web subordinado, y emplear nginx como servidor de fachada, con caché de contenido. No hay mal que por bien no venga, ya que me ha supuesto la oportunidad de realizar pruebas de esta funcionalidad, de cara a una línea de trabajo que estoy desarrollando para mi empresa.
Como consecuencia de lo anterior, decidí mover los puertos de servicio del servidor Apache al 81 (conexión http) y 444 (conexión https), que son sólo alcanzables desde la red interna de mi casa. Mediante una serie de reescrituras, las peticiones efectuadas al sistema Gallery2 son dirigidas al servidor Apache, procesadas por éste, y reenviadas por nginx al cliente, además de ser cacheadas para ganar en tiempo de respuesta. El resto de peticiones (WordPress, otras aplicaciones…) son servidas directamente por el servidor nginx. Un diagrama básico de lo expuesto hasta el momento sería el siguiente:
Diagrama de arquitectura
El resultado desde el punto de vista funcional es bastante bueno: las aplicaciones siguen siendo servidas de manera correcta, se ha ganado algo en tiempo de respuesta (por desgracia, la poca potencia del servidor y las limitaciones de la línea de datos no permiten grandes alegrías), y ha disminuido el consumo de memoria: pese a no haber eliminado el servidor Apache, se ha pasado de consumir unos 900 MB de RAM a unos 780, y con un comportamiento mucho más estable. Cada proceso nginx consume un máximo de 3 MB, mientras que cada proceso Apache ronda los 50 MB, con una gran fluctuación de memoria consumida. A esto hay que sumar los dos procesos configurados para spawn-fcgi, que también rondan los 50 MBs. La bajada en el consumo ha venido de haber podido reducir el número de procesos Apache que se mantienen en ejecución: he podido pasar de un mínimo de 10 procesos concurrentes a tan sólo 2.
En resumen: estoy bastante contento con el cambio. Estoy aprendiendo a gestionar servidores web de alto rendimiento, y creo que voy a poder sacarle bastante partido a este servidor nginx en el ámbito laboral. Esperemos que así sea.
25 ago 10 Corrección de error en mostrado panorámicas con WordPress y Gallery2
El sistema que utilizo para publicar este sitio web es el siguiente: se utiliza como base el gestor de contenidos WordPress, complementado con algunas soluciones periféricas. La principal de ellas es la integración con el sistema de gestión de galerías fotográficas Gallery2, que se realiza mediante un plugin diseñado al efecto: WPG2.
No todas las fotografías que publico son gestionadas mediante Gallery2. Para fotografías sueltas utilizo el propio sistema de WordPress, pero cuando inserto referencias a una serie fotográfica (correspondiente a algún viaje o evento concreto) sí que suelo utilizar Gallery2. El sistema es bastante simple: una vez subidas las fotografías a Gallery2 y catalogadas por éste, desde WordPress sólo es necesario hacer referencia al identificador de la imagen mediante la etiqueta <wpg2id> para insertar la imagen en la entrada. Con esta referencia, el artículo muestra una versión reducida de la imagen, y un enlace a la imagen original dentro de la estructura de la galería de imágenes, adaptada para su visualización en WordPress,
Por lo general, el sistema funciona bastante bien. Sin embargo, desde hacía tiempo había observado un problema con las imágenes panorámicas, en las que existe una gran diferencia entre el ancho y el alto de la imagen: cuando insertaba una imagen mediante el sistema explicado anteriormente, en el caso de las fotografías panorámicas no se mostraba la miniatura de la imagen, sino la imagen completa, pero escalada al tamaño de la miniatura definida. Los problemas que esto provoca, especialmente en tiempo de carga, eran significativos, ya que algunas de las panorámicas pueden alcanzar tamaños de más de 10000×2000 píxels, y pesos superiores a los 10 MB, mientras que las miniaturas asociadas tienen unas dimensiones máximas de 400 píxels en su lado más grande, y pesos inferiores a los 30 KB.
Tras un tiempo de investigación, he conseguido dar con una solución al problema, en los foros de Gallery: <wpg2> tags use always full-size versions En una de las entradas, uno de los usuarios informa de que el problema se debe al método en el que el sistema estudia si ha de escoger mostrar una miniatura o la versión completa de la imagen, aunque escalada. Para determinar esto el sistema compara el ancho y el alto de la imagen. Esta comparación, si bien resulta adecuada para la mayoría de las imágenes, produce problemas en aquellas con importantes diferencias entre ancho y alto, como es el caso de las panorámicas. Ante ello, el usuario propone hacer uso sólo del ancho. Para ello, es necesario realizar modificaciones en el archivo ImageBlockHelper.class, ubicada en el directorio /modules/imageblock/classes de Gallery2 (en mi caso, al usar el paquete Debian, su ruta completa es /usr/share/gallery2/modules/imageblock/classes). En concreto, es necesario realizar unas modificaciones a partir de la línea 424 del archivo:
/* Get the list of resizes */
$resizes = array();
list ($ret, $ok) = GalleryCoreApi::hasItemPermission(
$derivativeParentId, 'core.viewResizes', $userId);
if ($ret) {
return array($ret, null);
}
if ($ok) {
list ($ret, $resizes) =
GalleryCoreApi::fetchResizesByItemIds(array($derivativeParentId));
if ($ret) {
return array($ret, null);
}
$resizes = isset($resizes[$derivativeParentId]) ? $resizes[$derivativeParentId]
: array();
}
if (isset($thumbnail)) {
$resizes[] = $thumbnail;
}
foreach ($resizes as $imageObject) {
/*Primera modificacion*/
/* $rawDifferential = ($imageObject->getHeight() - $maxSize)
+ ($imageObject->getWidth() - $maxSize);*/
$rawDifferential = ($imageObject->getWidth() - $maxSize);
if ($biggerOnly && $rawDifferential < 0) {
continue;
}
$resizeDifferential = abs($rawDifferential);
/*Segunda modificacion*/
/* $resizeSize = $imageObject->getHeight() * $imageObject->getWidth();*/
$resizeSize = $imageObject->getWidth();
/*
* If this differential is smaller than the last, update the image target and
* the comparison value.
* If two differentials are equidistant, use the larger based on image size.
*/
if ($resizeDifferential < $imageDifferential
|| $resizeDifferential == $imageDifferential
&& $resizeSize > $imageSize) {
$image = $imageObject;
$imageDifferential = $resizeDifferential;
$imageSize = $resizeSize;
}
}
}
Una vez hecho esto, en WordPress se empezarán a mostrar correctamente las miniaturas de las imágenes en vez de las versiones escaladas de las imágenes completas, en el caso de las panorámicas.
Etiquetas: debian, gallery2, panorámica, wordpress, wpg2
08 mar 10 Cómo solucionar problemas de funcionamiento de aplicaciones Java en Debian Squeeze y SID
Desde hace algunas semanas vengo observando en varias máquinas Debian SID con las que trabajo que presentan problemas de funcionamiento en comunicación con redes (tanto internet como redes locales) de las aplicaciones Java, ya fuera para aplicaciones Java en sí como aquellas que dependen del plugin para los navegadores instalados en el sistema. En concreto, he notado problemas con The Grinder, JXPlorer, y aquellas aplicaciones web que hacen uso del plugin de Java para los navegadores IceWeasel, Firefox, Chrome y Opera.
He encontrado en LinuxQuestions información relativa al problema para Squeeze.
Al parecer el problema está relacionado con estos dos bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560238
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056
La solución provisional al problema, mientras los bugs no sean corregidos, es la siguiente: editar el fichero /etc/sysctl.d/bindv6only.conf y cambiar el valor de la variable net.ipv6.bindv6only a 0. Una vez hecho esto, es necesario reiniciar procfs mediante el siguiente comando:
# invoke-rc.d procps restart
P.D.: Esta es la entrada 1000 de esta página. He tardado algo menos de 5 años en lograrlo. 
Medidor de entropía
