XMLTV

El segundo proyecto en el que colaboro se llama xmltv

xmltv consiste en un conjunto de "grabbers", que generan un fichero XML.

¿Pero para qué sirven esos ficheros?

Seguramente ya tengáis un aparatito TDT y en el mando habéis visto un botón que pone "EPG" (guía electrónica de programas), donde os muestra que están emitiendo (nombre, duración entre horas y una descripción), y los programas que se emitirán a continuación y sus horarios correspondientes.

Esto es la nueva era digital, poder saber que emitirán, en que horas y poder ponerlo a grabar.

Pero en España realmente se pasan a la torera el actualizar la guía de canales a través de TDT, o algunos canales no lo utilizan, o ponen las horas mal, etc..

XMLTV hace el mismo trabajo que EPG en la TDT, genera un fichero donde contiene información de lo que echa la televisión, por título, horario, descripción e incluso se puede organizar por distintos tipos de canales (deportes, cines, etc). Una vez generado ese fichero se puede utilizar cualquier frontend para visualizar:
- si tienes un media center: MythTV o Freevo (del que he hablado en este mismo blog), podréis acceder a la guía y programar vuestras grabaciones) o
- una aplicacion tipo freeguide

El formato del fichero es bastante simple:

<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE tv SYSTEM "xmltv.dtd">
<tv source-info-url="http://www.miguiatv.com/todos-los-canales.html" source-data-url="http://www.miguiatv.com/todos-los-canales.html" generator-info-name="XMLTV" generator-info-url="http://membled.com/work/apps/xmltv/">
<channel id="CLa-20Sexta.miguiatv.com">
<display-name>La Sexta</display-name>
</channel>

<programme start="20080608071000 +0200" channel="CLa-20Sexta.miguiatv.com">
<title lang="es">Apuesta en 20'</title>
<desc lang="es">Programa presentado por Javier Mart<ED>n.</desc>
<category lang="es">CONCURSO</category>
</programme>
</tv>

No creo que haya que explicar mucho: primero se pone la cabecera indicando de donde se genera los datos e información del generador. Luego van los donde se indica un id y el nombre de cada canal. Luego directamente se establecen los programas con , la fecha de inicio y al canal que corresponda. Dentro de se indica el título, la descripción y opcionalmente la categoría. Es importante saber que un programa acaba cuando empieza el otro. Es decir, no se establece su duración.

En freevo luce tal que así:




La instalación de XMLTV tampoco tiene mucho misterio, en debian:

apt-get install xmltv

Si quereis utilizar el que he creado yo (coge datos de miguiatv)

tv_grab_es_miguiatv --configure

Luego elegís los canales que os interesa, y luego ya cada noche sólo teneis que generar el fichero .xml para poder utilizarlo.

0 0 * * * tv_grab_es_miguiatv > /tmp/TV.xml

Para decirle a FreeVO de dónde coger la gúia de televisión, editamos /etc/freevo/local_conf.py y establecemos:

XMLTV_FILE = '/tmp/TV.xml'

Shorewall

A veces las cosas complejas y difíciles se pueden hacer simples y fáciles. Esa frase es el ejemplo de Shorewall, hace fácil y simple el firewall de Linux.

IPtables sirve para packet filtering y para NAT en linux. El problema es que su sintaxis es bastante engorrosa, y muchas veces en máquinas en producción un cambio puede ocurrer muchos problemas. Un ejemplo para ver la complejidad de iptables:

iptables -t nat -A PREROUTING -p tcp -i eth0--dport 81 -j DNAT --to-destination 192.168.0.10

Por ello nace el frontend del que hablamos hoy, simplifica la creación de packet filtering, de NAT, de control de tráfico y un sinfín de cosas.

Pasemos a la acción:

apt-get install shorewall

La configuración del shorewall se guarda en: /etc/shorewall/, los ficheros principales:

- shorewall.conf -> fichero que configura el frontend, la mayoría de las veces el por defecto nos debería servir
- zones -> Declara tus zonas de internet (fw, net, loc, dmz)
- interfaces -> asocia una zona con un interface (net-> eth0, dmz -> eth1, etc..)
- rules -> fichero de reglas (packet filtering, nat, etc)
- policy -> las políticas a seguir por defecto

Un ejemplo de cada fichero (excepto shorewall.conf seria)

zones:

fw firewall
net ipv4
loc ipv4
tun ipv4

interfaces:

loc lan detect
net eth0 detect dhcp
tun tun+ dtect

rules:

ACCEPT net $FW tcp 21
ACCEPT net $FW tcp 80
ACCEPT net:85.18.14.0 $FW tcp 8080
DNAT net loc:192.168.0.10 tcp 81
DROP all net tcp 4662

policy:

net all DROP info
all all REJECT info

creo que poco más que hay que explicar, el fichero importante el rules

cuyo formato es
(accion: ACCEPT o REJECT o DNAT o DROP o REJECT) (de donde: net, loc) (a donde: $fw, loc) (protocolo: tcp, udp, all) (puerto destino) (puerto origen)

Una vez configurado podemos hacer: shorewall check /etc/shorewall para comprobar que la sintaxis está bien. Una vez que tengamos todo configurado podemos editar /etc/default/shorewall para establecer startup=1 (para que se ejecute shorewall a través de init.d)

Una vez lanzado shorewall, podemos ver su estado con shorewall status:

Shorewall is running
State:Started (Sun Jun 1 00:02:21 CEST 2008)

Si queremos hacer algun cambio, editamos los ficheros de /etc/shorewall/ y podemos hacer "shorewall try /etc/shorewall", yo recomiendo hacer una copia: cp -a /etc/shorewall /etc/shorewall_pruebas, editar los ficheros de /etc/shorewall_pruebas y hacer el shorewall try (si este falla volverá a la configuración, que debería funcionar bien de /etc/shorewall), una vez que el shorewall try compile las reglas y veas que todo funciona, copia de el fichero rules de /etc/shorewall_pruebas a /etc/shorewall y reinicia el shorewall.

Una vez visto más o menos como instalarlo y que ficheros editar, podemos observar que sólo nos debemos preocupar de meter las reglas en el fichero rules, y su síntaxis como indicaba arriba es muy fácil.

Podemos ver las diferencias:
Iptables:

iptables -t nat -A PREROUTING -p tcp -i eth0--dport 81 -j DNAT --to-destination 192.168.0.10

Shorewall:

DNAT net loc:192.168.0.10 tcp 81

Finalmente comentar algunos comandos de utilidad:
- shorewall show connections (muestra el estado de las conexiones activas, los packetes enviados, el origen, destino, etc)
- shorewall reject (rechaza una ip, cuando se reinicie el shorewall no estará bloqueada)
- shorewall drop (bloquea una ip, idem que antes)
(tambien existe logreject, logdrop)
- shorewall allow (permite el acceso a una ip bloqueada/rechazada anteriormente)
- shorewall try [timeout] (compila y prueba las reglas de un directorio, si se establece timeout, pasado ese tiempo si no se reinicia el shorewall, se coge la configuracion de nuevo de /etc/shorewall, util para compilar reglas que te puedan dejar sin conexion)
- shorewall check (comprueba la sintaxis de un directorio sin compilar las reglas)

Además, si establecemos en el policiy o en rules (ejemplo DNAT:info), que se loguee las reglas podemos ver en /var/log/syslog algo asi:


Jun 1 13:11:25 Atlantis kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:e0:7d:cb:b8:af:00:0d:29:ed:3a:37:08:00 SRC=***.211.***.27 DST=83.**.160.** LEN=485 TOS=0x00 PREC=0x00 TTL=42 ID=0 DF PROTO=UDP SPT=4637 DPT=1027 LEN=465


Para finalizar, una regla interesante:

Limit:info:SSHA,3,60 net $FW tcp 22

Esta regla establece 3 conexiones cada 60 segundos al puerto 22, si se realizan más, se bloquea durante un tiempo a la ip que supera ese límite, es muy útil para evitar ataques brute-force de contraseñas.

Hay que tener un fichero Limit dentro de /etc/shorewall (regla cogida de www.shorewall.net)

set -- $(separate_list $TAG)

[ $# -eq 3 ] || fatal_error "Rule must include ,, as the log tag"

run_iptables -A $CHAIN -m recent --name $1 --set

if [ -n "$LEVEL" ]; then
run_iptables -N $CHAIN%
log_rule_limit $LEVEL $CHAIN% $1 DROP "" "" -A
run_iptables -A $CHAIN% -j DROP
run_iptables -A $CHAIN -m recent --name $1 --update --seconds $3 --hitcount $(( $2 + 1 )) -j $CHAIN%
else
run_iptables -A $CHAIN -m recent --update --name $1 --seconds $3 --hitcount $(( $2 + 1 )) -j DROP
fi

run_iptables -A $CHAIN -j ACCEPT


Cuando se intenta 4 conexiones en un periodo menor de 60 segundos podemos ver en el /var/log/syslog algo así:


May 23 18:39:35 Atlantis kernel: Shorewall:SSHA:DROP:IN=eth0 OUT= MAC=00:e0:7d:cb:b8:af:00:0d:29:ed:3a:37:08:00 SRC=202.129.37.66 DST=**.***.***.** LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=24119 DF PROTO=TCP SPT=53578 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0


Enlaces:
Web oficial de shorewall

Google maps

Una de las cosas más divertidas que he hecho en mi trabajo es un "controlador" de obras. La intención era poder "dibujar" el tramo que está en obras con unos datos específicos (nombre, punto kilométrico, incluir ficheros, etc). Además, una vez introducida debería listarse en el mapa con las otras obras, y al hacer click que se abriera una pequeña ventana (dentro de google maps) con un pequeño resumen.


Google maps es muy fácil, sólo necesitas un key para utilizar su API y leer http://code.google.com/apis/maps/, cualquiera puede hacer virguerías con google maps, con un mínimo conocimiento de JavaScript.

Yo tuve que utilizar lo que denominan "polyline" que es algo así como un código (posee encoded polyline y encoded levels) que se genera a través de lo que hay el mapa. Es decir, si dibujas una recta, pues ese código, si lo vuelves a introducir en el mapa en una siguiente sesión, se mostrará tal cual la línea.

Eso es útil para los programadores, sólo tienes que preocuparte de guardar ese encoded polyline y el encoded levels para cuando lo quieras mostrar. Además, en mi caso, guardo el Zoom Level último.

Luego ya sólo queda que al mostrarlo crear un Marker y un evento que al hacer click te muestre los datos que quieres.

function createPointMarker(point, highlighted, idObra2) {
var clr = highlighted ? "yellow" : "blue";

var point_marker = createMarker(point, clr);
point_marker.enableDragging();

GEvent.addListener(point_marker, "drag", function() {
var index = findMarkerIndex(point_marker);

if (index >= 0) {
var nLat = point_marker.getPoint().lat();
var nLng = point_marker.getPoint().lng();

var pLevel = points[index].Level;

var modifiedPoint = {
Latitude: nLat,
Longitude: nLng,
Level: pLevel
};

points[index] = modifiedPoint;
createEncodings(false);
document.getElementById('pointList').options[index]
= new Option('(' + nLat + ',' + nLng + ')', index);
}
});

GEvent.addListener(point_marker, "click", function() {
highlight(findMarkerIndex(point_marker));
if(idObra2) {
GDownloadUrl("wdatos.php?id=" + idObra2, function(data) { point_marker.openInfoWindowHtml(data); });
}
// point_marker.openInfoWindowHtml(result);
});

return point_marker;
}


El resultado: http://www.nightmare.es/ver.php

El crear obra (la parte del mapa, con polyline, etc) es copiado de: http://code.google.com/apis/maps/documentation/polylineutility.html y adaptado para mis fines.

Freevo

Uno de los dos proyectos en los que colaboro es un media center llamado FREEVO.
Está escrito en python, y aunque no tenga muchos conocimientos de este lenguaje he podido colaborar con el proyecto:

- Creando un plugin para ver videos de youtube, ya sea mediante búsqueda o especificando en la configuración el usuario para ver sus videos.
- Creando un plugin para ver imágenes de flickr a través de un id.
- Algunos cambios en la pantalla de introducir texto.
- Algunos cambios para que se pueda reproducir determinados sonidos al entrar en un menú. (Por ejemplo, al entrar en el menú de noticias, que suene un sonido determinado).

http://doc.freevo.org/ImagePlugins
http://doc.freevo.org/MoviePlugins

Freevo, es un media center de código abierto para Linux, tiene soporte para: lirc (para mandos a distancia), reproductores de video (mplayer, xine), reproductores de mp3, reproductor de dvd, rss, televisión, visor de imágenes, el tiempo... Además permite distintos skins, montón de configuraciones, carátulas para audio, búsquedas en imdb, información de duración/resolución de películas y un largo etc.

Recomiendo utilizar la versión de svn:

svn co svn://svn.freevo.org/freevo/branches/rel-1 freevo-1.x
svn export svn://svn.freevo.org/kaa/trunk/base kaa/base

y dentro de cada directorio python setup.py install

luego sólo nos queda configurar /etc/freevo/freevo.conf y /etc/freevo/local_conf.py (opcionalmente para lirc, /etc/freevo/lircrc)

Diferencial GPS (I)

"Tengo una solución", dijo el encargado de informática donde estábamos implementando una solución gps, "ya sé cómo solucionar el error del GPS".

Todo eso con un papel en la mano y una seguridad en lo que decía sorprendente.

"Como tenemos un mapa de nuestra superficie y tenemos un punto fijo que sabemos las coordenadas, ponemos ahí un aparato GPS y con ello sabemos la diferencia".

Quizás no se preguntó, el porqué un sistema de DGPS cuesta más de un millón de pesetas, y quizás más de dos. La contestación fue bastante simple para desmontar su teoría, "¿y qué pasa si un GPS que dices está cogiendo distintos satélites a los que le aplicaremos la corrección??". El tema acabó ahí.

Un sistema DGPS, lo que hace a grandes rasgos, es situarse en un punto con coordenadas conocidas. Luego para cada satélite mide su error.

Hasta ahí todo genial, tenemos un sistema que nos dice que error tiene cada satélite.

¿Y a mí, con mi aparato GPS, cómo me afecta eso? ¿Cómo puedo utilizarlo?

Un sistema DGPS, utiliza un estándar para el uso de correciones. Ese estándar es feo, oscuro y casi imposible de aprender, su nombre es RTCM.

RTCM te envía distintos fragmentos, indicándote que corrección tienes que aplicar para cada satélite, y algo muy importante: la fecha de esa corrección.

¿Por qué es importante la fecha? Imagínate que la corrección fuese de hace 5 segundos, y él, por problemas de red o lo que sea te llega ahora. ¿Qué pasaría? Estarías aplicando una corrección de hace 5 segundos que seguramente ahora sea distinta, y tu GPS hará un llamado "salto".

¿Cómo recogemos las tramas RTCM? Como supongo que no tendrás el GPS conectado al DGPS, habrá que utilizar un protocolo de comunicación entre el DGPS y tu aparato GPS. Ese protocolo de comunicación se llama NTRIP.

Hay tres puntos importantes en NTRIP: NtripServer, NtripCaster y NtripClient.

NtripServer: Es el que recoge las correcciones RTCM desde el DGPS y los trasmite a un NtripCaster.
NtripCaster: Recibe datos de 1 o varios NtripServer, y espera las conexiones de los NtripClients para tramitarles el RTCM.
NtripClient: Ésta es la parte del cliente, se conecta a un NtripCaster y solicita los datos de un punto de montaje, una vez que pida ese punto de montaje, recibirá las tramas RTCM.

Los puntos de montaje son simplemente los NtripServer pero etiquetados de una forma u otra.

El protocolo Ntrip es basado en el protocolo HTTP, es decir, te conectas a un puerto y utilizas la misma sintaxis que en HTTP: "GET / HTTP/1.0" o "GET /puntomontaje HTTP/1.0".

Una vez solicitado recibir tramas RTCM a través de un punto de montaje (si no existe te devolverá el SOURCETABLE que es igual que solicitar /), recibirás un stream que irás recibiendo RTCM hasta que tú cierres la conexión.


Un ejemplo de NtripCaster podemos verlo en: http://catnet-ip.icc.es:8080/

Explicación de una línea:
STR;MATADGPS;MATA (Matar?);RTCM 2.3;23(11), 24(11), 1,31;0;GPS;Catnet;DEU;41.53;2.41;0;0;GPSNet;None;B;N;640;;

Los datos que nos importa de esa línea son:
MATADGPS: es el punto de montaje, si pedimos /MATADGPS Nos devolveŕa todos los datos RTCM para ese DGPS.
RTCM 2.3: La versión de RTCM, yo sólo he visto la 2.3, pero hay la 3.0 en un libro pero no tuve que verlo.
23(11), 24(11), 31: El tipo de corrección y entre parentésis cada cuanto tiempo se envia.
Los demás datos son informativos, en plan si es de pago, las coordenadas donde está, el país, etc.


Y ya se me olvidaba decir que hay distintos tipos de corrección. En la segunda parte os comentaré los que utilicé yo (1, 3, 9 creo recordar) y algunos datos más. E indicaré aplicaciones NtripClient.

Como hablo de un proyecto de hace 7 meses quizás recuerde algunas cosas mal.