publikaccion @publikaccion

martes, mayo 29, 2007

.: LDAP tilde/s, eñe/s Latin-1 (ISO-8859-1), UTF-8 y Base 64

Estos días el LDAP me ha estado dando la lata con el tema de las tildes, las eñes y otras hierbas del Latin-1 (ISO-8859-1) que es el estándar que reconoce nuestros caracteres acentuados, eñes y cedillas, y demás símbolos latinos escritos.

Necesitaremos:

- OpenLDAP
- OpenSSL

No entro en detalle de cómo se instala ninguno de estos 2 productos, ya que considero que hay suficiente información en sus respectivas webs para que cada uno sea el que se encargue de dichas instalaciones en sus máquinas y sistemas operativos correspondientes.

El caso es que intentando introducir una nueva entrada o NODO en un OpenLDAP, me encontraba con que cada vez que introducía un CN (Common Name) con acento através del formato LDIF de datos paa LDAP, el slapd me devolvía un error indicando que el DN estaba mañ formato (DN que por supuesto tenía tilde), sin embargo cuando daba de alta el mismo de DN mediante una herramienta visual como es JXplorer, el campeón se tragaba los acentos sin ningún tipo de queja, y eso me llevó a mosquearme, ya que el formato texto de LDIF no me dejaba.

En el ejemplo (ficticio para más información), tenía un caso del tipo:

dn: cn=Javier Gómez García,ou=people,dc=dominio,dc=es
objectClass: top
objectClass: usuario
cn: Javier Gómez García
uid: jgomezg
userName: jgomezg


al final encontré el por qué no podemos hacer una exportación en limpio desde línea de comandos con un LDIF que generemos nosootros.

La explicación viene por el siguiente motivo, principalmente el LDAP funciona con codificación de caracteres UTF-8, no en Latin-1 que es la iso-8859-1 que reconoce los caracteres españoles como tildes, diéresis, eñes o cedillas, de modo que intentar meter desde un LDIF un acento en un campo que tenga reconocimiento específico de caracteres (algunos atributos permiten introducir acentos sin problemas), causa que nos dé un error de sintaxis en el DN, en el CN, o en donde se encuentre las tildes codificados en Latin-1 o ISO-8859-1 (en español-castellano para entendernos).

Ahora surge la duda de cómo es que sí que nos deja el JXplorer hacerlo sin ningún tipo de problema. La explicación es que JXplorer así como otros muchos navegadores/administradores de LDAP, implementa el codificado automático del ISO correspondiente al idioma a codificación UTF-8, de modo que lo que está haciendo el cliente de administración de LDAP es codificar automáticamente a UTF-8, independientemente de que nosotros queramos o no.

Además de codificar en formato UTF-8, todas las entradas que contengan caracteres raros para LDAP (aquellos que no sean los caracteres estándar exployendo caracteres del tipo áéíóúäëïöüñç), deben además ir codificadas en Base64 (otro algoritmo de codificación), de modo que lo que son caracteres extraños para el LDAP que son los que genera UTF-8 (áéíóúäëïöüñç) cuando empleamos ISO 8859-1, deben ser transformados a Base64 de modo que JXplorer hace este tipo de transformación de Latin-1 (ISO-8859-1 -> UTF-8 -> Base64 por nosotros, y así, cuando exportamos una entrada que vemos que tiene acentos o eñes en el LDAP del MAP, vemos que las entradas son del tipo de un churro de caracteres raros... del tipo:

dn:: ZG46IGNuPUphdmllciBHw7NtZXogR2FyY8OtYSxvdT1wZW9wbGUsZGM9ZG9taW5p
 byxkYz1lcw==


que es el formato Base64 de un DN (los :: nos indican que está codificado en Base64) para la entrada:

dn: cn=Javier Gómez García,ou=people,dc=dominio,dc=es

que es a su vez el formato UTF-8 de un DN que corresponde con:

dn: cn=Javier Gómez García,ou=people,dc=dominio,dc=es

en formato ISO 8859-1 o Latin-1 (que tal y como comento es la ISO que identifica a nuestro idioma, el español).

Las codificaciones de Latin-1 a UTF-8 se pueden hacer o bien mirando unas tablas de UTF-8 o bien como hice yo con un sencillo javascript que traduce todo tipo de carácter raro para LDAP de modo que nos da la codificación sin mayor problema.


<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>

<script>
function encode_utf8(s){
return unescape(encodeURIComponent(s));
}

function decode_utf8(s){
return decodeURIComponent(escape(s));
}
</script>

</head>
<body>

<form name="formulario">
Texto a codificar en en formato<br />Latin-1 (ISO-8859-1) -> UTF-8<br />
<input type="text" name="entrada" value=""><br />
<input type="button" value="codificar"
onclick="document.formulario.resultado.value=(
encode_utf8(document.formulario.entrada.value));
document.formulario.salida.value=document.formulario.resultado.value"> <br /><br />

Texto a decodificar en formato<br />UTF-8 -> Latin-1 (ISO-8859-1)<br />
<input type="text" name="salida" value=""><br />
<input type="button" value="decodificar"
onclick="document.formulario.resultado.value=(
decode_utf8(document.formulario.salida.value));"><br /><br /><br />

Resultado<br />
<input type="text" name="resultado" value=""><br />

</form>

</body>
</html>


Una vez realizada la codificación a UTF-8 el mismo OpenSSL tiene una utilidad de línea de comandos que permite codificar y decodificar en Base64, con lo que quedaría el chorro de caracteres raros listos para introducir dentro del LDIF en el DN correspondiente.

Yo creo 3 archivos:

- plain.txt es el archivo con el texto plano en formato UTF-8
- coded.txt es el archivo con el texto UTF-8 codificado en Base64
- decoded.txt es el archivo con el texto en UTF-8 decodificado de Base64 (por motivo de comprobación más que nada)

de modo que tecleando desde consola

type plain.txt|openssl base64 -e > coded.txt

Codifica plain.txt en UTF-8 a coded.txt en Base64, y

type coded.txt|openssl base64 -d > decoded.txt

Codifica coded.txt en base64 a decoded.txt en UTF-8 comprobando que el plain.txt y el decoded.txt deben coincidir.

Probando de esta manera no hay problema en dar de alta desde línea de comandos preparando el archivo LDIF a las entradas que queramos asignar al nuevo árbol, siendo lo más engorroso quizás el tema de codificado con los diferentes algoritmos, pero que a fin de cuentas es la explicación que se tiene a por qué el JXplorer sí que daba de alta con acentos y eñes sin despeinarse...

De este modo tendríamos:

Latin-1 o ISO-8859-1 (1)


dn: cn=Begoña Gómez García,ou=people,dc=dominio,dc=es
objectClass: top
objectClass: usuario
cn: Begoña Gómez García
uid: bgomezg
userName: bgomezg


UTF-8 (2)


dn: cn=Begoña Gómez García,ou=people,dc=dominio,dc=es
objectClass: top
objectClass: usuario
cn: Begoña Gómez García
uid: bgomezg
userName: bgomezg


Base64 (3)


dn:: Y249QmVnb8OxYSBHw7NtZXogR2FyY8OtYSxvdT1wZW9wbGUsZGM9ZG9taW5pbyxk
 Yz1lcw==
objectClass: top
objectClass: usuario
cn:: QmVnb8OxYSBHw7NtZXogR2FyY8OtYQ==
uid: bgomezg
userName: bgomezg


Algunas notas a este tipo de codificaciones.

Cuando en el punto (2) tenemos el DN (dn: cn=Begoña Gómez García,ou=people,dc=dominio,dc=es), es el conjunto de DN el que tenemos que poner en el archivo plaint.txt para codificarlo en Base64, que si nos fijamos en (3), se codifica la entrada al completo (incluyendo los OU y DC de la entrada, pero NO dn:), de modo que estamos codificando realmente el texto:

cn=Begoña Gómez García,ou=people,dc=dominio,dc=es

Otro dato más es que cuando codificamos dicho DN completo a Base64, el texto plano que nos queda en el coded.txt es un texto del tipo:

Y249QmVnb8OxYSBHw7NtZXogR2FyY8OtYSxvdT1wZW9wbGUsZGM9ZG9taW5pbyxk
Yz1lcw==


Es decir, en 2 líneas, y tal y como sabemos (o deberíamos de saber), cuando tenemos 2 líneas y queremos introducirlas en un archivo LDIF, se comienza la segunda línea con un sólo espacio en blanco y a continuación el texto correspondiente a la segunda línea, de modo que esto indica al LDIF, que la línea con un sólo espacio en blanco es continuación de la línea anterior.

De modo que quedaría del modo:

Y249QmVnb8OxYSBHw7NtZXogR2FyY8OtYSxvdT1wZW9wbGUsZGM9ZG9taW5pbyxk
 Yz1lcw==


Importante recordar que la codificación en Base64 debe ir con :: para indicar este tipo de codificación al archivo LDIF.

Asimismo en la entrada correspondiente al CN de (2) (es decir, la línea cn: Begoña Gómez García), codificaríamos sólo en texto correspondiente al nombre de la persona (Begoña Gómez García) si el cn:, y del mismo modo podríamos los :: para indicar que es una entrada en Base64.

Confío en que más de uno solucione sus problemas con la codificación en ISO-8859-1 (Latin-1) para LDAP con esta pequeña entrada ;o)

technoratiquetas | | | |

lunes, mayo 28, 2007

.: Asunto: Crónica de una marcha anunciada

A esto lo llamo yo dejar las cosas claras sin dar nombres XD un 10 para esta persona, que matiza cada punto sin dar nombres, esos que todos conocen ya XD...

¡Lo dejo! Me imagino que la gran mayoría de la gente que recibáis este mail ya sabríais que estaba preparando oposiciones de bombero, pero por si alguno no lo sabia, ahora ya lo sabe. Y el resultado ha sido satisfactorio. El mes que viene me incorporo a la academia. El miércoles será mi último día en XXXX.

Me imagino que la gente pensara que es un cambio bastante grande y no se equivoca. Así que se acabo el darle a las teclas, por lo menos a nivel profesional.

Me retiro del mundo de la informática, pero sobre todo del mundo de la contratación/subcontratación.

Me retiro de llegar a fin de año con la incertidumbre de saber si renovaran mi contrata.

Me retiro de que mi subida de sueldo no dependa de lo bueno o malo que sea en mi trabajo, sino de si la empresa contratante pague mas ese año por el servicio.

Me retiro de no poder buscar un cambio de empleo en cualquier otra empresa porque hay una especie de "pacto entre caballeros" que consiste en no quitarse uno al otro los peones. Eso si, hasta el día que les interese realmente. Ese día el pacto se puede romper…

Me retiro de ver como hay gente que piensa que la jerarquía profesional le otorga también jerarquía social.

En el fondo agradezco a los responsables de todo esto que se hayan comportado así. De esta manera he podido ver clarísimo que el futuro estaba muy negro.

Espero que algún día cambie el funcionamiento de este sector. Que no se juegue con los trabajadores, con los que realmente sacan adelante el trabajo, como si fuesen fichas de parchis.

Pero a los que realmente os doy las gracias es a los que me habéis apoyado en esto. A los que realmente os alegráis de mi marcha. A todos los que habéis estado pendientes de mis pruebas y exámenes y os alegrabais tanto como yo cuando aprobaba.

No voy a caer en el tópico de "han sido unos años maravillosos", porque estaría mintiendo, ha habido momentos jodidos. Lo que si puedo decir es que me marcho con un grupo de buenos amigos en el bolsillo. Y solo por eso ya ha merecido la pena.

Muchas Gracias a todos vosotros.


technoratiquetas | |

domingo, mayo 27, 2007

.: Guerra de Dados

Este juego es la caña, y engancha más de lo que parece una vez se sabe jugar...

Dice Wars


http://www.gamedesign.jp/flash/dice/dice.swf

Si no te gusta, mejor no profundices... :oP

technoratiquetas | | |

.: La cita

nota de DZPM

"Free software only dies when the last copy of the source code is erased."

"El software libre sólo muere cuando la última copia del código fuente se borre."

– Henrik Nordstrom, desarrollador de Squid


http://meneame.net/notame/DZPM/11045

technoratiquetas | | | |

jueves, mayo 24, 2007

.: La más larga

La palabra más larga en Inglés...

Ahí es nada... (1854 caracteres)

Methionylglutaminylarginytyrosylglutamylserylleucylphenylalanylalanylglut-
aminylleucyllysylglutamylarginyllysylglutamylglycylalanylphenylalanyvalyl-
prolylphenylalanylvalythreonylleucylglycylaspartylprolyglycylisoleucylglut-
amylglutaminylserylleucyllysylisoleucylaspartylthreonylleucylisoleucylglut-
amylalanylglycylalanylaspartylalanylleucylglutamylleucylglycylglycylisoleu-
cylprolylphenylalanylserylaspartylprolylleucelalanylaspartyglycylprolythreo-
nylisoleucylglutamiylasparaginylalanylthreonylleucylarginylalanylphenylalan-
ylalanylglycylvalyltheonylprolylalanylglutaminylcysteinylphenylalanygllutam-
ylmethionylleucyalanylleucylisoleucylarginylglutaminyllysylhistidylprolylthre-
onylisoleucylpriIylisoleucylglycylleucylleucylmethionyltyrosylalanylasparag-
inylleucylvalyphenylalanylasparaginyllysylgyycylisoleucylaspartylglutamylph-
enylalanyltyrosylalanylgutaminyllcysteinylglutamyllysylvalylglycylavlylaspart-
ylserylvalylleucylvalylalanylaspartylvalyprolylvalylglutaminylglutamyllserylal-
anyprolyphenylalanylarginylglutaminylalanylalanylleucylarginylhistidylaspara-
ginylvaylalanylprolylisoleucylphenylalanylisoleucylcysteinylprolylprolylaspart-
ylalanylaspartylaspartylaspartylleucylleucylarginyglutaminylisoleucylalanyyls-
eryltyrosylglycylarginylglycyltyrosylthreonyltyrosylleucylleucylserylarginylal-
anylglycylvalythreonylglycylalanylglutamylasparaginylarginylanylalanylleucyl-
prolylleucylaspaaginylhistidylleucylvaylalanyllysylleucyllysylglutamyltyrosyla-
saraginylglycylphenylalanylglycylisoleucylalanylprolylaspartylglutaminylvalyl-
lysylalanylalanylisoleucylaspartylalanylalanyglycylalanylalanyglycylalanylisol-
eucylserylglycyserylalanylisoleucylbalyllsylisoleucylisoleucylglutamyyylgluta-
minylhistidylasparaginylisoleucylglutamylprolyglutamyllysylmethionylleucyla-
lanylalanylleucyllysylvalylphenylalabylvalylglutaminlylprolylmethionyllysylala-
nylalanylthreonylarginylserine


Miedo me da esta palabra en un examen del First Certificate... XD

http://www.healthbolt.net/2007/05/24/the-longest-word-in-the-english-language/

technoratiquetas | |

miércoles, mayo 23, 2007

.: Ponte el cinturón... oficial

La versión friki de Factor X, de la cadena Cuatro...



http://www.youtube.com/watch?v=4kjZ-sJaEmo

La versión oficial de Cuatro con videoclip incluido... XD



http://www.youtube.com/watch?v=xdZHeGhZgl8

Esta es la televisión que nos venden en Egpaña XD

technoratiquetas |

martes, mayo 22, 2007

.: Otra Leyenda Urbana más

Leyendo en menéame la siguiente entrada, confirmo mis sospechas sobre la entrada del cartón de leche que puse ayer, quedando demostradas mis sospechas de que era una Leyenda Urbana total, de esas que parecen ciertas, pero que acaban siendo mentira...

technoratiquetas |

lunes, mayo 21, 2007

.: Saber qué comemos

OJO al dato que es importante saberlo...

La leche en cartón al no ser vendida dentro de determinado plazo, regresa para la fábrica para que sea repasteurizada de nuevo.

Esto puede ocurrir hasta 5 veces, lo que termina dejando la leche con un sabor diferente, aumentando la posibilidad de cuajar reduciendo significativamente su calidad, hasta su valor nutricional disminuye.

Cuando la leche vuelve para la venta al consumidor final, el pequeño numero que está marcado en la figura arriba con un círculo rojo es modificado.

Ese número varia de 1 a 5 lo ideal es comprar hasta el número 3, números superiores, significa que la calidad de la lecha será dudosa.

Ese pequeño número queda localizado en el fondo del cartón, si compras una caja cerrada, basta verificar apenas uno de los paquetes, todas las demás tendrán la misma numeración.

Por ejemplo, si un paquete tiene el número 1, significa que es la primera vez que sale de la fábrica y llega al supermercado para la venta final, pero si tiene el número 4, significa que ya fue repasteuridado 4 veces y luego volvió para el supermercado para tratar de ser vendido y así sucesivamente...

Cartón de leche


Aquí el número que tenemos que verificar.

technoratiquetas | | |

sábado, mayo 19, 2007

.: Correos me niega el derecho a voto (y van 2)

Correos no garantiza del derecho a voto al que nos ampara la constitución cuando nos encontramos desplazados de la Comunidad donde estamos empadronados. Estoy tan seguro que es denunciable que estoy en trámites para hacerlo por segunda vez.

La primera fue en las anteriores elecciones a los Gobiernos Regionales. La estafeta donde me tocaba ir a cagarme en su puta madre a votar sólo abría por la mañana de Lunes a Viernes no por la tarde, negándome la igualdad de derechos con el resto de españoles que sí podían hacerlo en su estafeta porque sí que abrían por la tarde. Les metí una denuncia a la Mesa Electoral de Coruña y a la puta empresa de Correos, y OH SORPRESA, desde aquel día abren de Lunes a Viernes mañana y tarde y los Sábados por la mañana.

Pero esta vez lo que más indignante, es que tras haber hecho mi solicitud hará cosa de 2 semanas con previsión de evitar a los inútiles hijos de puta funcionarios de Correos, hoy he recibido una carta de mi Mesa electoral en Coruña, informándome que no pueden efectuar la emisión de solicitud de voto por correo desde Coruña, porque a un amable funcionario de Correos HIJO DE LA GRAN PUTA de la estafeta donde realicé la solicitud se le olvidó poner el tampón con el sello de la fecha de mi solicitud.

Así de fácil, así de rápido, así de simple. Sin derecho a nada más que comerte la rabia que supone no poder ejercer el derecho a voto por segunda vez, porque la otra solución sería liarme a oxtias con el cabrón que ni si quiera tenía hojas de reclamaciones de la Comunidad de Madriz y que ni si quiera se ha sabido disculpar, eso que tanto cuesta en esta puta ciudad. Otra denuncia más que va a tardar en ser respondida cerca de un mes.

Cada día tengo más claro que en esta ciudad que dicen ser la capital del reino, hay gente que no sabe hacer la puta mierda de trabajo por el que le pagan, y que los que tenemos que jodernos con las consecuencias somos una vez más los gilipollas que vamos andando por la calle sin poder hacer otra cosa que JODERNOS.

technoratiquetas | | | | |

jueves, mayo 17, 2007

.: Sin logo web 2.0 no eres nadie

Si no tienes un logo 2.0 no eres nadie ;o). Aquí tenemos algunos logotivos muy conocidos de grandes compañías por todos nosotros vistos desde la perspectiva web 2.0 tan de moda en nuestros tiempos. Algunos son realmente simpáticos, e incluso dotan a la marca de cierta amigabilidad respecto al logotipo corporativo tradicional. Basten como ejemplos el de Audi, el de PlayBoy, el de Levi's, el de MasterCard o el de Nike, por citar algunos de los que me han resultado más curiosos ;o)

Audi 2.0


Y como ejemplo, un botón...

technoratiquetas | |

.: Conversión entre formatos de Certificados

La conversión de formatos de Certificados es muy sencillo con las herramientas que provee OpenSSL. Aquí se muestra una chuleta para dichas conversiones:

Convertir a PKCS#12 (Netscape, IE etc) desde PEM

openssl pkcs12 -export -in pem-certificate-and-key-file -out pkcs-12-certificate-and-key-file
openssl pkcs12 -export -in pem-certificate-file -inkey pem-key-file -out pkcs-12-certificate-and-key-file


Desde PKCS#12 a PEM

openssl pkcs12 -in pkcs-12-certificate-file -out pem-certificate-file
openssl pkcs12 -in pkcs-12-certificate-and-key-file -out pem-certificate-and-key-file


Desde PEM/DER a DER/PEM - DSA Keys

openssl dsa -inform PEM|DER -outform DER|PEM -in pem-file|der-file -out der-file|pem-file

Desde PEM/DER a DER/PEM - RSA Keys

openssl rsa -inform PEM|DER -outform DER|PEM -in pem-file|der-file -out der-file|pem-file

Así de fácil ;o)

technoratiquetas | | |

.: Campaña de la DGT

No podemos Conducir Por Ti


joslagraputa...

technoratiquetas | | |

.: Tipos de formatos de Certificados

Los certificados de firmas digitales se basan en los algoritmos de firma DSA y en el algoritmo RSA para criptografía de clave pública según los algoritmos PKCS. El formato del certificado depende de la aplicación, ya que no hay unanimidad en los estándars de los formatos. Se suele disponer de claves privadas cuando nos referimos a los formatos PEM y DER. El formato por defecto para la aplicación OpenSSL es PEM. Para aplicaciones Java el formato DER suele encajar mejor con las necesidades de la aplicación en cuanto a la importación de claves privadas y certificados.

De modo genérico, los formatos PEM se suelen emplear en el mundo Unix/Linux, PKCS12 en el mundo Microsoft y el formato DER en el mundo Java.

Los archivos de certificado son objetos codificados en formato ASN-1 según el estándar DES (Data Encryption Standard). Los archivos también se pueden encriptar empleando un algoritmo CIPHER simétrico como 3 DES.

Un archivo de certificado PEM si encriptar tiene este aspecto

-----BEGIN CERTIFICATE-----
MB4CGQDUoLoCULb9LsYm5+/WN992xxbiLQlEuIsCAQM=
-----END CERTIFICATE-----


La cadena que comienza por MB4C es el objeto codificado en Base 64 y en ASN-1.

Un archivo encriptado tendrá cabeceras que describen el tipo de encriptación empleada, así como el vector de inicialización.

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C814158661DC1449
AFAZFbnQNrGjZJ/ZemdVSoZa3HWujxZuvBHzHNoesxeyqqidFvnydA==
-----END RSA PRIVATE KEY-----


Las 2 cabeceras Proc-Type y DEK-Info declaran el tipo de encriptado, y la cadena que comienza por AFAZ es el objeto codificado en Base 64, encriptado y codificado en ASN-1.

Debido a que los navegadores hacen uso de aplicaciones Java, exportan o importan los certificados en formato de archivo PKCS12 (que son archivos que empaquetan las claves privadas y públicas en un sólo archivo empleando el algoritmo PKCS#12). Otras aplicaciones emplean el formato PEM de modo que las claves privadas y públicas deben estar desempaquetadas, de modo que el usuario debe recordar el formato de archivo para cada aplicación y debe proceder a la conversión entre formatos según sus necesidades.

PEM

Puede contener todas las claves privadas (RSA y DSA), las claves públicas (RSA y DSA) y los certificados (x509). Este es el formato por defecto de OpenSSL. Almacena los datos en formato DER codificado Base64, entre cabeceras ascii, de modo que es apropiado para transferencias en modo texto entre sistemas. Su extensión suele ser .pem.

DER

Puede contener todas las claves privadas, las claves públicas y los certificados. Se almacena según el formato DER ASN1. No posee cabecera - PEM es el envoltorio del texto de la cabecera de DER. Es el formato por defecto de la mayoría de navegadores web. Su extensión suele ser .der.

PKCS#12

También conocido como archivos PFX (Personal Information Exchange format). Puede contener todas las claves privadas, las claves públicas y los certificados. Se almacena en formato binario. Este formato habilita la transferencia de certificados y sus claves privadas correspondientes de un ordenador a otro o de un ordenador a un medio externo (removable media). El PKCS#12 (o Public Key Cryptography Standard #12) es un formato que es apropiado para llevar de un sitio a otro o almacenar y restaurar dicho certificado y sus claves privadas asociadas. Esto se puede hacer entre productos del mismo proveedor o incluso de proveedores distintos. Su extensión suele ser .p12.

PKCS#7

El PKCS#7 (o Public Key Cryptography Standard #7) habilita la transferencia de un certificado y todas las rutas de los certificados y sus certificaciones de un ordenador a otro, o de un ordenador a un medio externo (removable media). Los archivos PKCS#7 poseen la extensión .p7b, y son compatibles con el estándar ITU-T X.509. Este formato permite atributos como countersignatures estén asociadas con las firmas y que atributos como signing time pueden ser autentificados con contenido de mensaje.

technoratiquetas | | | | |

martes, mayo 15, 2007

.: De compras por Madrid en San Isidro

Esta tarde Piruleta y yo nos hemos ido dando un paseo desde Plaza Castilla hasta Cibeles, y nos encontramos con la Feria del Libro Antiguo y de Ocasión y curioseando, Piruleta se compró un libro orientado a la empresa, y el menda lerenda se acaba de comprar 4 libros de Java que están totalmente vigentes por unos 20 eurillos de nada... Así da gusto salir de compras por Madrid, aunque sea de segunda mano :-P

technoratiquetas | | | |

viernes, mayo 11, 2007

.: Solidaridad Internacional

Es un correo que me envía un amigo, sobre la niña que ha desaparecido en Portugal. Seguro que habréis visto la noticia en los periódicos o telediarios.
Esperemos que pronto puedan encontrarla.

Desde aquí os agradecería que enviárias este correo a vuestros contactos internacionales para que tenga la mayor difusión posible

Un saludo.

------------------------------------------------------------

Maddie McCann's desapareceu.
Com apenas 3 anos de idade, desapareceu do seu quarto na Praia da Luz - Algarve, Portugal.

Por favor, ajuda a distribuir as fotos da pequena Maddie. Passa ao maior numero de pessoas possível, para que todos decorem a cara da menina.
Se possível envia este email para outros países da Europa para que, com sorte alguém consiga reconhecer esta linda menina e leva-la para onde ela deve estar, junto dos seus pais.

POR FAVOR AJUDA. Imagina se fosse a tua irmã ou a tua filha.

*****************************************************

MADDIE McCann's has disappeared.

With only 3 years of age, MADDIE disappeared from her room in the Praia da Luz - Algarve. Please, help by distributing the photos of Maddie. Forward this email to the greater number of people as possible, so that all can remember the face of this three-year-old girl.

If possible forward this message to other European countries. With luck somebody can recognize this lovely girl and bring her back to where she must be, next to her parents.

PLEASE HELP. Imagine if it was your daughter or your sister.

*****************************************************

MADDIE McCann ha desaparecido.

Con solamente 3 años de edad, MADDIE desapareció de su habitación en Praia da Luz, Algarve, Portugal. Por favor, ayuda distribuyendo las fotos de Maddie. Remite este email al mayor número de personas posible, de modo que todos puedan recordar la cara de esta niña de 3 años. Si puedes envía este mensaje a otros países europeos. Con suerte alguien podará reconocer a esta niña encantadora y traerla de nuevo a donde ella debe estar, al lado de sus padres.

POR FAVOR AYUDA. Imagina si fuese tu hija o tu hermana.

*****************************************************

MADDIE McCann a disparu.

Avec seulement 3 ans, MADDIE a disparu de sa chambre dans la Praia Luz ? Algarbe, Portugal. S'il te plait, aide en distribuant les photos de Maddie.

Envoi cet email au plus grand nombre de personnes que possible, de façon à ce que tous puissent se rappeler la visage de cette fille de 3 ans. Si possible renvoie ce message à d'autres pays européens. Avec la chance quelqu'un pouvra identifier cette belle fille et l'apporter de nouveau là où elle doit être, à côté de ses parents.

S'il te plait AIDE. Imagine si c'était ta fille out a s?ur.

*****************************************************













technoratiquetas | | | |