oriolrius.cat

Des del 2000 compartiendo sobre…

Category: Mussol

Prey – rastrejar el portàtil i el lladre

2010/10/12 No Comments

Reading time: 2 – 4 minutes

prey logoQuan ens roben el portàtil l’únic que ens queda fer és resar perquè siguem realistes, és molt poc provable que la policia el trobi. Així doncs, el que preten fer prey és enviar-nos tota la informació possible del portàtil després de que ens l’hagin robat.

El seu funcionament és força simple, però al mateix temps s’ha de dir que la idea sembla força eficient. En la versió per linux es tracta d’un script fet amb perl que es col·loca al crontab, de forma que cada x’s minuts es connecta a una URL del servidor de prey o del nostre propi servidor. Aquest URL sovint respon dient que tot va bé, és a dir, que el portàtil no ha estat marcat com a robat. En cas contrari, el servidor respon via HTTP dient que el dispositiu ha estat robat. En aquest moment és quan l’script es posa a treballar i es posa a recollir tot tipus d’informació per reportar-la a la pàgina web:

  • geolocalització per GPS o Wifi, si no disposem de GPS. He provat la localització per wifi i va força bé.
  • fa fotos amb la webcam del portàtil i captures de pantalla
  • reporta tota la informació que pot sobre processos que hi ha corrent al sistema, rutes, informació de les wifis veïnes, etc.
  • també podem fer sonar alarmes, borrar informació remotament, que ens enviï alguns arxius abans de ser borrats,etc.
  • a més els reports que es van reben queden arxivats en una interficie força amigable i molt senzilla d’usar
  • a més el software d’auto-actualitza

La compte gratuïta que ofereix la pàgina web permet tracejar fins a 3 dispositius, obviament si usem el nostre propi servidor HTTP podrem tracejar tots els dispositius que volem. Si volem usar més dispositius haurem d’adquirir una compte professional que tampoc sembla massa cara: per exemple, la més econòmica és la de 12€/mes que permet controlar fins a 10 dispositius amb un màxim de 25 informes per cada dispositiu.

Jo he provat la versió de Windows i la de Linux i ambdues m’han funcionat força bé a la primera, però pel que posa a la web també tenen la versió de Mac i la d’Android. Aquest última diria que és molt nova. Malgrat això en els meus dos Androids no uso prey sinó que uso WaveSecure. Pensat especialment per a dispostius mòbils, ja que tenen versions per: Blackberry, Symbian, Windows phone, Java i Android, és clar.

Autenticació PAM/OTP via Apache

2010/09/17 No Comments
Reading time: 27 – 44 minutes

L’autenticació d’Apache coneguda com a AuthBasic malgrat la seva inseguretat és una de les més usades, ja que ens permet de forma senzilla i ràpida protegir un directori o simplement un fitxer. La protecció d’aquest tipus d’autenticació és molt relativa perquè el password viatge en clar a través de la xarxa, a més, al viatjar a les capçaleres HTTP o fins hi tot en la propia URL de la pàgina pot arribar a ser indexat per un navegador.

Seguint la línia dels anteriors articles:

Ara el que toca és afegir a l’Apache aquest tipus d’autenticació de forma que podem donar les credencials d’accés a un directori/fitxer a algú però aquestes caducaran al cap del temps (uns 3 minuts) i els buscadors o d’altres agents amb més mala idea no podran accedir al recurs passat aquest temps. Com sempre la idea és la d’aprofitar-se del PAM/OTP.

En primera instància per aconseguir això ho he intentat amb el mòdul libapache2-mod-auth-pam però no n’he tret l’entrellat i he estat incapaç de completar la configuració. Així doncs, el que he fet és provar amb el mòdul libapache2-mod-authnz-external ambdós disponibles en l’Ubuntu 8.04 (Hardy). Aquest segon mòdul l’he combinat amb el checkpassword-pam.

Així doncs, la idea és ben senzilla configurem l’Apache perquè usi el libapache2-mod-authnz-external, en escència el que fa aquest mòdul és recolzar-se en agents externs per fer l’autenticació. Aquest agent extern és el checkpassword-pam que comentava i que com diu el seu nom el que fa és validar el password contra PAM, així doncs, malgrat no és una solució massa eficient a nivell de recursos ja que ha de carregar un segon programa per validar cada usuari considero que és una solució suficienment bona pel meu cas.

La configuració

Instal·lem el mòdul d’apache i l’activem:

apt-get install libapache2-mod-authnz-external
a2enmod authnz_external
/etc/init.d/apache2 restart

Instal·lació del checkpassword-pam

cd /var/tmp
wget "http://downloads.sourceforge.net/project/checkpasswd-pam/checkpasswd-pam/0.99/checkpassword-pam-0.99.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcheckpasswd-pam%2F&ts=1284649515&use_mirror=ignum"
tar xvfz checkpassword-pam-0.99.tar.gz
cd checkpassword-pam-0.99
./configure
make
mkdir -p /opt/checkpassword-pam
cp checkpassword-pam /opt/checkpassword-pam

Fitxer de configuració pel servei apache2 del PAM, /etc/pam.d/apache2:

auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/
account  required       pam_script.so onerr=fail dir=/etc/pam-script.d/

Si us hi fixeu aquest fitxer és igual al que vaig usar per fer l’autenticació en l’article de PHP i PAM/OTP.

Ara anem a un dels fitxers de configuració d’Apache per un virtualhost i afegim el següent codi per protegir un directori servit per aquest virtualhost:

<Directory /var/www/virtualhost/directori_a_protegir>
  AuthType Basic
  AuthName "Restricted area for My Server"
  require user nom_usuari
  AuthBasicProvider external
  AuthExternal autenticador
</Directory>
AddExternalAuth autenticador "/opt/checkpassword-pam/checkpassword-pam -H --noenv -s php -- /bin/true"
SetExternalAuthMethod autenticador checkpassword

Coses importants a destacar en aquest configuració, fixeu-vos que em cal afegir ‘require user nom_usuari’, això és perquè no disposo de cap fitxer d’usuaris on Apache pugui validar quins són els meus usuaris vàlids i la directiva ‘require valid-users’ no funcionaria, així doncs, hem d’especificar quins usuaris podran fer login a través d’aquesta comanda, o bé, afegir una altre directiva que li permiti a Apache trobar un llistat d’usuaris en algún lloc.

Un altre detall important són els paràmetres que he d’usar al checkpasswords-pam perquè aquest funcioni bé:

  • -H no intenta fer un ‘chdir-home’ ja que potser l’usuari no disposa d’aquest ‘home directory’.
  • –noenv el checkpassword-pam busca certes variables d’entorn per funcionar, amb aquest paràmetre no les busca i agafa el que li cal del stdin.
  • -s apache2 especifica el nom del servei que buscarà dins de /etc/pam.d/apache2
  • — /bin/true simplement serveix perquè el checkpassword-pam no faci res després de validar un usuari, ja que podriem executar algún programa si volguessim després de fer la validació.

Referències

A tenir en compte en un projecte de digital signage

2010/09/08 2 Comments

Reading time: 2 – 3 minutes

Tot ordenant .txt he trobat quatre notes que havia fet fa temps extretes de l’experiència i de documents de relacionats amb digital signage que havia anat llegint, per tal de no perdre-les les anoto a continuació:

Entorn:

  • Audiència: estàtica o en moviment?
  • Predisposició a aturar-se de l’audiència? (area de pas, passeig, etc)
  • Cal posar audio? o no dona cap valor afegit.

Audiència:

  • Qui mirarà el contingut?
  • És una necessitat comuna?
  • S’esta buscant algún tipus d’interactivitat, o simplement captació pel missatge emès?
  • Què trobarà interessant l’audiència o com a míninm digne de mirar?
  • Cuantes vegades un individu veurà el missatge?
  • Perquè l’audiència li hauria de donar un segon cop d’ull?

El missatge:

  • Venem producte, o un nou estil de vida?
  • Creem una atmosfera, o fem marca?
  • Cal enumerar els beneficis o podem deixar que les imatges parlin soles?
  • Estem informant, instruint, venent o que…?
  • És un missatge aïllat o part d’una campanya que usa altres tipus de media?
  • Podrien millorar l’experiència enllaços a altres sistemes?

Tips and tricks:

  • Intentar crear un sentit de propietat comuna del projecte entre tots els players del negoci
  • Audiència en moviment, missatge estàtic. Audiència estàtica, missatge en moviment.
  • Monitorització constant de les reaccions de l’audiència.
  • S’ha de considerar que l’audiència només donarà una ullada a la pantalla.
  • Buscar consistència en els estils i colors del missatge.
  • Les tipografies i mides de la lletra han de ser prou clares per llegir-se a certa distància.
  • No cal esperar que la publicitat millori de forma espectacular les ventes d’un producte. Només és un complement que ajuda a donar a coneixer el producte.
  • Cal assegurar-se que el contingut té una part d’entreteniment i una part d’informació.
  • Cal pensar que al montar una pantalla on la gent esta en moviment aquesta ha d’estar en un punt on es pugui seguir movent-se i llegint el missatge.
  • Compte amb l’audio, sovint no és una bona idea.
  • És important tenir el contingut ben actualitzat i no mostrar informacions obsoletes, això fa perdre credibilitat al medi.
  • És important saber l’experiència que té l’audiència sobre el medi.

Entenent els frames I, P i B

2010/08/23 No Comments
Reading time: 9 – 14 minutes

Al sentir parlar de formats de video, codecs, DivX, MPEG4, etc. sovint surten a la conversa termes com ara els I-frame, P-frame i B-frame. Cansat de que em soni a xinès he decidit fer-me un petit resum de què és tot plegat, sempre des del punt de vista d’algú que en sap ben poc d’aquests temes.

Podem dividir els ‘frames’ de video en 3 tipus:

  • I-Frame: també anomenat keyframe. No té cap frame de referència i pot ser decodificat per si mateix. Podem pensar que és algo semblant a un JPEG.
  • P-Frame: El contingut del mateix és dedueix d’un frame previ de tipus I o P, és impossible decodificar-lo sense mirar aquesta referència.
  • B-Frame: per decodificar-los cal mirar els frames anteriors i següents de tipus I i P.

Aquest últim tipus de frames són interessant per dues raons:

  • Són fàcils de predir
  • No impacten en la qualitat dels frames següents

Degut a que els B-frames depenen del passat i el futur, llavors el decodificador li calen frames I-P del passat i el futur per poder decodificar el frame B. Això ens porta als conceptes PTS/DTS.

  • PTS Presentation Time Stamp: també podem entendre’l com una forma de saber el número de frame, ordre en que es poden veure els frames decodificats.
  • DTS Decoder Time Stamp: ordre en que es processen els frames per ser decodificats.

Un exemple, per entendre-ho millor:

  • Suposem que això és un petit video: I-0 B-1 B-2 P-3
  • L’ordre DTS seria: I-0 P-3 B-1 B-2

Per tal de simplificar les coses el video s’enmagatzema en l’ordre DTS.

El problema

Arribat en aquest punt podeu imaginar-vos el problema que suposa mostrar un video en ordre, ja que el decodificador ha d’anar composant els frames per mostrar-los am és d’inserir frames on no n’hi han per mostrar el frame que toca.

DIVX (i Xvid)

Aquests famosos codecs per tal de d’atacar aquest problema fan servir un petit truc. La idea seria usar una variant dels frames PB i empaqueten diversos frames en un. Això fa que les aplicacions es pensin que només hi ha un frame i el codec oculta la resta.

Per exemple, si tenim un fitxer que te empaquetat el següent:

In (0 3 1 2) - - - ...

el codec haurà de treure això:

Out 0 1 2 3 ...

El codec posa frames de tipus ‘null’ en el lloc on hi haurien d’haver els frames que no té pel fet de tenir-los empaquetats en un frame. Els codecs ja saben que quan reben un frame null han de descartar-los.

Des del punt de vista del codificador, és important fixar-nos que no s’introdueix un delay corresponent als frames nulls. En un fitxer AVI no hi ha cap relació entre el PTS/DTS guardada enlloc per tal d’informar al decoder quan aquest ha de reproduir.

Album de fotos de Costa Rica

2010/08/18 No Comments

Reading time: 3 – 5 minutes

Dijous passat aterrarem a Barcelona després del viatge que hem fet per Costa Rica, així doncs, malgrat ja fa uns dies que treballo he pogut pujar les fotografies del viatge a l’àlbum de fotografies. Com sempre el teniu a:

Les fotografies estan protegies amb password que com sempre els que em coneixeu el sabreu en un moment i els que no, envieu-me un email i ús l’enviaré. Aprofito per recordar que el tinc protegit perquè hi ha algunes fotos que a vegades no és bo que estiguin a l’abast de tothom.

Pel que fa a la web del viatge malgrat ja l’he començat a fer encara li queda força feina per estar acabada, tan aviat com ho tingui ja avisaré. Pels que no voleu entrar a l’àlbum de fotografies i mentre la web no esta acabada podeu anar fent boca amb aquestes quatre notes i imatges que ús deixo a continuació.

Platja privada del parc natural de Manuel Antonio:

Costa Rica > P.N. Manuel Antonio

“Conopy Extrem” a Monteverde:

Costa Rica > Monteverde > Conopy Extrem

Volcà Arenal, foto feta des de l’hotel “Linda Vista del Norte”:

Costa Rica > Arenal > Volcà

Termes “Baldi” a La Fortuna (Arenal) on ens trobarem amb el Joan i la Patri: (esq-drt: Glòria, Torsten, Patri, Joan, Estefania i Oriol)

Costa Rica > Arenal > Termes Baldi

Posta de sol des del jardí de l’hotel Miss Junie a Tortuguero:

Costa Rica > Tortuguero

Caimà dels canals de Tortuguero:

Costa Rica > Tortuguero

Tour en canoa pels canals de Tortuguero amb el senyor Billy, un caçador de jaguars de Nicaragua que amb 84 anys tenia més força per remar que tots quatre junts:

Costa Rica > Tortuguero

Piscines naturals a les platges de Puerto Viejo, on visitarem al Josep Maria i la Carme:

Costa Rica > Puerto Viejo de Talamanca

Esmorzant a la ‘terrassa’ de l’apartament del Josep Maria i la Carme a Puerto Viejo:

Costa Rica > Puerto Viejo de Talamanca

Cocodril d’uns 2’5m que teniem a tocar al dinar del tour del cacao que ens va fer el Sr.Felipe prop de Hone Creek (zona sur Carib de Costa Rica):

Costa Rica > Hone Creek

Dinar al tour del cacao amb la Glòria i el Torsten els nostres companys de viatge:

Costa Rica > Hone Creek

Si en voleu més, ja ho sabeu: album de fotos > viatges > Costa Rica

Avui el blog fa 10 anys!!!

2010/07/31 2 Comments

Reading time: 3 – 4 minutes

Doncs si tal dia com avui vaig començar a escriure el blog, així doncs, faré una cosa que faig poc sovint i és autofelicitar-me per la constància, si ja sé que no podriem dir que últimament escrigui cada dia però crec que aguantar 10 anys amb certa constància és algo, no?

Bé doncs sempre passa en aquestes ocasions farem una petita llista de bons proposits per aquesta nova etapa de maduresa del blog:

  1. continuar-lo usant com a bloc de notes tècnic
  2. continuar usant-lo per referenciar events de caire més personal o no-professional
  3. començar de forma oficial el ‘screencast‘ sobre el que ja he fet les primeres proves
  4. agrupar aquesta part més multimedia ‘podcast‘ i ‘screencast‘ en una pestanya dedicada per accedir-hi ràpidament
  5. redissenyar-lo completament però aquest cop si tot va bé, fer-ho a través d’una empresa que li doni un bon acabat
  6. re-editar els posts antics perquè adquireixin formats més unificats, suport de tags, centrat i mida d’imtges, repassar enllaços trencats, etc.
  7. més protagonisme als posts antics (this week last years)
  8. integrar uwish
  9. integrar lifestream a la pantalla principal en forma d’stick item a més de sindicar més feeds en aquesta llista: twitter, my shared items del google reader, etc.
  10. seguir fent del blog algo que m’enganxa i que trobo a faltar quan no faig

També vull fer un comentari sobre la línia que té el blog aquests últims anys, en que el nombre de posts ha baixat força però la qualitat i densitat tècnica han augmentat molt. Malgrat això em fa baixar en nombre de lectors és més fidel a la meva persona i el converteix en una eina encara més útil per mi.

Finalment hi ha una llista d’articles pendents de publicar que conte coses com:

  • iPython
  • ESI – Edge Side Includes
  • LVM
  • SSTP
  • SVG amb long polling
  • array vs CouchDB
  • scribe
  • DNSCurve
  • Google Talk chatback badge
  • MyProxy – credential management service
  • SSL i TLS a fons
  • Desktop notify system with python
  • oProfile
  • etc

Però sobretot el que estic impassient per començar a document en forma de post, d’screencast i del que faci falta és el tema del AMQP, porto mesos treballant amb un borrador que cada cop és més extens i que de ben segur hauré de dividir en diversos trossos perquè les seves dimensions ja fan por, però realment estic disfrutant com mai amb aquest tema.

Doncs res, agraïr-vos també a tots els que em llegiu que ho continueu fent malgrat el pesat que em faig en alguns moments. Demanar-vos que no tingueu por en presentar-vos perquè a les jornades tècniques on em deixo caure acostumo a trobar gent que ha passat pel meu blog alguna vegada i això sempre fa moltíssima il·lusió.

Bé doncs gràcies a tots i ens veiem quan torni de Costa Rica, on estic passant les meves vacances en aquests moments.

Podcast 2×06: Com funciona Kerberos? autenticació i autorització (AA)

2010/07/27 No Comments

Reading time: 4 – 6 minutes

El podcast

[display_podcast]

Notes

Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:

  • autenticació mutua
  • temps de connexió ràpids (session tickets)
  • delegació (autenticació recursiva entre serveis)

Esquemes

Simplifiació del funcionament

Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:

  • AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
    • KRB_AS_REP
      • Client principal name.
      • Timestamp.
      • Kerberos target principle name (realm).
      • Requested lifetime.
    • KRB_AS_REP
      • La primera part va xifrada usant la clau d’usuari, conté:
        • User-TGS key (generated by the KDC).
        • Kerberos target principle name (realm).
        • Ticket lifetime.
      • La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
        • Client IP address (taken from the initial KRB_AS_REQ).
  • TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
    • KRB_TGS_REQ
      • Service principal name.
      • Requested lifetime.
      • TGT (still encrypted with the TGS key).
      • Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
    • KRB_TGS_REP
      • La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
        • Service principal name.
        • Ticket lifetime.
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
      • Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • Client IP address.
  • Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
    • KRB_AP_REQ
      • ST xifrat amb la clau TGS del servei
      • Authenticator – encrypted with the user service key
    • KRB_AP_REP

Característiques

  • ‘Realm‘ es defineix com un domini d’aministració
  • Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
  • Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
  • La “user key” es genera a partir del “logon password”
  • La “host key” es genera quan el “host” s’uneix al ‘Realm’
  • Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
  • Important recordar que:
  • només el KDC pot llegir el TGT
  • només el servei pot llegir el ST

Glossari d’acrònims

  • KDC: Key Distribution Center
  • AS: Authentication Service
  • TGS: Ticket Granting Service
  • SS: Service Server

Referències:

Error coneguts

  • Degut a un error el podcast 2×05 no exiteix. Sento l’error!

CouchDB: fixar el límit màxim de revisions per document

2010/07/13 No Comments
Reading time: 8 – 12 minutes
couchdb logo


Per defecte i fins que no es fa una compactació de la base de dades CouchDB permet fins a 1000 revisions d’un document, cosa que sovint no acostuma a ser necessari. Així doncs, si volem canviar aquesta paràmetre finalment a la versió 0.11 ja el podem canviar.

Set _revs_limit of a particular database:

curl -X PUT -d "1500" http://localhost:5984/test/_revs_limit
#=> {"ok":true}

Read _revs_limit of a particular database:

curl -X GET http://localhost:5984/test/_revs_limit
#=> 1500

informació original de: accessing database specific options.

Agraiments: gràcies @marcos 😉

Formats gràfics CIF

2010/07/09 No Comments

Reading time: 2 – 3 minutes

CIF (Common Intermediate Format), també conegut com FCIF (Full Common Intermediate Format), és un format usat per estandaritzar les resolucions horitzontals i verticals en pixels de les senyals de video (seqüències YCbCr), aquest nomenclatura es va proposar a l’estàndard H.261.

CIF es va dissenyar per convertir de forma senzilla els estàndards PAL o NTSC. CIF defineix una seqüència de video amb una resolució de 352×288 com PAL, amb un framerate de 30000/1001 (uns 29.97fps) frames com NTSC, amb un codi de color YCbCr 4:2:0.

SQCIF 128 × 96 SubQuarterCIF (subQCIF)
QCIF 176×144 in PAL
176×120 in NTSC		 Quarter CIF, la meitat de la resolució H i V,
o sigui, 1/4 de la imatge original
SIF(525) NTSC 352×288 PAL
352×240 NTSC		 Source Input Format
CIF/SIF(625) 352×288 in PAL
352×240 in NTSC
D1/4SIF(525) 704×576 (TV PAL)
704×480 (TV NTSC)
720×576 (DVD-Video PAL)
720×480 (DVD-Video NTSC)		 Full size, estàndard NTSC i PAL
2CIF 704×288 in PAL
704×240 in NTSC		 2 Common Intermediate Format
DCIF 528×384 in PAL
528×320 in NTSC		 Double CIF, té un aspect ratio molt proper al 4:3,
millor quailtat que 2CIF i CIF amb el mateix bitrate
4CIF/4SIF(625) 704×576 in PAL
704×480 in NTSC
16CIF 1408 × 1152

Les resolucions xCIF no són quadrades, tenen un ratio de ~1.222:1. O sigui, que una televisió analògica té un ratió de 1.2:1 segons defineix l’estàndard de sistemes de 525 linies (CCIR 601). En les pantalles d’ordinador o de televisió digital es treballa amb blocs de pixels quadrats, o sigui, que les trames xCIF ha de ser re-escalades horitzontalment un ~109% per aconseguir un ratio de 4:3, o sigui, el que equivaldria a 384×288 pixels quadrats.

Les mides d’imatges CIF han estat especialment escollides per ser multiples del que s’anomenen macroblocs (corresponent a 16x16pixels). Per exemple, una imatge CIF de mida 352×288 correspon a 22×18 macroblocs.

Informació extreta de la Wikipedia i de diversos forums dispersos per internet.

Video del meu 30è aniversari, potser una mica tard?

2010/07/08 No Comments

Reading time: 2 – 2 minutes

Dilluns i dimarts he estat per Vinaròs després de molt de temps de no estar per la zona. Desrpés de 3 anys d’esperar va ser el moment perquè m’entreguessin el video que em van fer per felicitar-me el 30è aniversari, o sigui, el que correspon a l’any 2007. Com que el video s’ho val el penjo a Youtube perquè el pogueu veure.

Part 1:

Part 2:

Per cert, aquesta part del video és només de la gent de Vinaròs, els altres videos que m’han comentat que m’havien fet altres persones encara no els he vist, cosa que ja té delicte 😉

Scroll to Top