Demà ja faran una setmaneta i ja les tenim a casa, perdó ja les tenen. No ús confongueu que no són filles nostres. Només arribem al mèrit de tiets “ficticis”.  O sigui, que són les filles del Xavi i la Sabina dues preciositats que van neixer el dia 27/6/2009 a Sant Joan de Deu (Barcelona).

De fet, tinc moltes altres fotos que ahir varem intercanviar amb el Xavi, però encara no l’he pogut organitzar i encara menys pujar al servidor d’internet. Així que pels ‘mussols’ que les volgueu veure en foto haureu d’esperar una miqueta.

Almenys fa tres setmanes que tinc pendent escriure una ressenya sobre aquest llibre “La econmía Long Tail: De los mercados de masas al triunfo de lo minoritario” (ISBN: 978-84-934642-6-4) escrit per Chris Anderson (editor de la revista Wired). Per cert, el llibre me’l va recomanar el Jordi, així doncs li he d’agraïr que ho fes perquè desconeixia totalment el concepte ‘long tail’ i ara el veig a tots els racons.

Pels que com jo tampoc ús soni el terme, una bona forma d’intrudir-se és a partir de l’article de la wikipedia sobre el conepte. De fet, hi ha ben pocs conceptes que donin tan de si i que es poguin explicar amb algo tan senzill com aquesta gràfica:

El concepte ‘long tail’ faria referència a la part dreta de la gràfica, o sigui, on la gràfica tendeix a zero però mai arriba a ser-ho per molt a la dreta que anem. Aquí és on rau el valor de la teoria. Posaré un exemple, perquè s’entengui millor.

Imagineu que la gràfica aplica al index de ventes de DVDs; doncs bé, a l’esquerra tindriem els ‘top’, el que més es ven. A la dreta, tota la ‘long tail’ amb milions i milions de DVDs que pertanyen a infinitat de nitxols de mercat que són més o menys grossos, però que sovint si ens n’anéssim a la posició 100.000 d’aquest llistat de ventes de DVD trobariem que aquest DVD es continua venent encara que sigui en molt poques unitats, igualment segueix passant a la posició 500.000 o 1.000.000. El que preten demostrar la teoria del ‘long tail’ és que hi ha empreses com pot ser Netflix, Rhapsody, iTunes o d’altres similars que sovint acaben fent tants o més diners per la suma de ventes a la ‘long tail’ que no pas en els productes ‘top’.

Més enllà del concepte, la valoració que faig del llibre és bona. Diguem que li poso un 7 sobre 10. Aconsegueix mantenir-te força enganxat malgrat com ja em va comentar el Jordi si haguessin fet un treball de síntesis amb 15 pàgines es podia explicar tot el que ve a dir el llibre. Però l’assaig demostra la teoria i explica com s’ha arribat a poder afirmar això, contrastant-ho en diversos aspectes de l’economia actual i del comerç electrònic. A més, cal destacar l’important treball de camp que fa l’autor per contrastar la teoria. Així doncs, si penseu fer algún tipus de pla de negoci que toqui internet ni que sigui de passada, és una bona lectura a fer.

Nota tècnica, per assegurar-se que tenim tot el que fa falta per compilar VMWare Workstation en una Fedora Core 11, executar com a root:

yum install kernel-devel kernel-headers gcc yum groupinstall "Development Tools" "Development Libraries"

En cas de que al fer un:

vmware-modconfig --console --install-all

encara doni errors de compilació, a mi el que m’ha funcionat ha estat descarregar els fitxers:

• vmware-6.5.2-modules-2.6.30-fix.patch
  (original)
• vmware-6.5.2-modules-2.6.30-fix.sh (original)

després he executat altre cop el ‘vmware-modconfig’ i ja ha compilat, malgrat dona força warning tot ha funcionat bé.

Això ho he fet amb les versions:

• kernel: 2.6.29.5-191.fc11.i586
• VMware Workstation v6.5.1.126130

La solució l’he trobat al thread:[VMware] Compile kernel problem..

div class=event-nodeapi div class=event-start dtstart title=2009-07-04T08:30:00ZlabelStart: /label 04/07/2009 09:30 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div div class=event-nodeapi div class=event-start dtstart title=2009-07-04T08:30:00ZlabelStart: /label 04/07/2009 09:30 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div pa href=http://www.guifi.net/jpl2009 title=http://www.guifi.net/jpl2009http://www.guifi.net/jpl2009/a/p

pEsta mañana hemos estado probando (Toni Conde, Jose Talón y yo) una posible ubicación de nodo de cobertura en el edificio de la Caja Rural en la Plaza Mayor de Vila-real. La vista es muy interesante.br / La conexión con la UJI tenía una señal un poco débil. Por un lado caía casi detrás del campanario. Por otro igual estamos ya en el extremo de la sectorial uji-bibl1. No nos ha dejado asociarnos; no sé por qué. El enlace con la UJI se podría estudiar y mejorar. Está a unos 7km. Seguramente sería conveniente un enlace punto a punto./p pa href=http://castello.guifi.net/content/prueba-en-vila-real-plaza-mayor-edificio-de-la-caja-rural target=_blankleer más/a/p

div class=event-nodeapi div class=event-start dtstart title=2009-06-30T09:30:00ZlabelStart: /label 30/06/2009 10:30 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div div class=event-nodeapi div class=event-start dtstart title=2009-06-30T09:30:00ZlabelStart: /label 30/06/2009 10:30 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div p Después de haber instalado el nodo (por el momento a medio gas) en el IES Miquel Peris del Grao de Castellón, se ha organizado una breve charla para el claustro para explicar qué es guifi.net, cómo participa el instituto en la red, cómo pueden conectarse desde sus casa, qué servicios se pueden ofrecer, .../p pbAsitentes previstos/b: Miguel Pérez y Pablo Boronat/p

div class=event-nodeapi div class=event-start dtstart title=2009-07-13T21:00:00ZlabelStart: /label 13/07/2009 22:00 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div div class=event-nodeapi div class=event-start dtstart title=2009-07-13T21:00:00ZlabelStart: /label 13/07/2009 22:00 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div pLugar: Les Palmeretes (playa de Almassora) a href=http://maps.google.es/maps?q=39.927062,-0.00257amp;t=hamp;sll=39.94385,-0.062923amp;sspn=0.068453,0.128059amp;ie=UTF8amp;ll=39.927029,-0.002465amp;spn=0.000757,0.001195amp;z=20 Ver en google-maps/a/p pATENCIÓN: Se ha retrasado de 20 a 22h porque será al aire libre y hace falta que haya menos luz para poder usar el proyector./p pOrganizado por el Bloc d'Almassora./p pAsistentes previstos: Fernando Ochera y Julio Pacheco/p

pbLugar:/b Les Palmeretes (playa de Almassora) a href=http://maps.google.es/maps?q=39.927062,-0.00257amp;t=hamp;sll=39.94385,-0.062923amp;sspn=0.068453,0.128059amp;ie=UTF8amp;ll=39.927029,-0.002465amp;spn=0.000757,0.001195amp;z=20Ver en google-maps/abr / bHora:/b 22h del 13 de julio de 2009/p pSe ha retrasado de 20 a 22h porque será al aire libre./p pOrganizado por el Bloc d'Almassora./p pEn principio la charla la daré yo, aunque si alguien tiene interés por ello no habría problema ;-), y estáis invitados./p

pa href=http://www.publico.es/ciencias/234036/duenos/propia/red title=http://www.publico.es/ciencias/234036/duenos/propia/redhttp://www.publico.es/ciencias/234036/duenos/propia/red/a/p p¡Hay que leerlo!br / Hoy todo son buenas noticias./p

pEl dilluns dia 22 al matí s'obre el procés d'inscripció a les a href=http://jornadespl.org/VIII Jornades de Programari Lliure/a. Enguany són del dia 1 al 4 de Juliol, a plaça Universitat de Barcelona (és a dir, al costat de Plaça Catalunya)./ppJa hi ha el programa disponible i el podeu a href=http://www.jornadespl.org/biblioteca/viii-jornades/papereria/programa-a4.pdfaccedir aquí. /a/ppEl programa és molt divers i recull diversos temes, així que penso que cadascú pot fer la tria del qué li agrada més :-)/ppRecordeu que per estar sempre informats us podeu apuntar a la a href=http://llistes.cpl.upc.edu/listinfo/jpl-infollista informativa/a de les Jornades. /p

pEl otro día me pillé una Nanostation 5Ghz Loco con la intención de montar mi propio supernodo en casa, y ya de paso testear el rendimiento de estas antenas, muy similares en características a las Nanostation 5Ghz normales pero con un precio inferior./p pPor las especificaciones que podemos encontrar en el fabricante (a href=http://www.ubnt.com/downloads/loco5_datasheet.pdfLoco/a/a href=http://www.ubnt.com/downloads/ns5_datasheet.pdfNano/a) las diferencias entre ambos aparatos son:/p ul /ulpa href=http://castello.guifi.net/content/comparativa-de-nanostation-5ghz-con-nanostation-loco-5ghz target=_blankleer más/a/p

pHe leido hoy una noticia en el Mediterraneo sobre la prohibición de antenas en ciertos edifícios, no se hasta que punto nos puede afectar esto al instalar las antenas. Lo que no entiendo es que pone mástiles o elementos soporte, y las antenas parabólicas, no deben ser escalables no lo entiendo./p pEspero que no tengamos ningun problema para continuar ceciendo. Os dejo el link de la noticia y si alguien tiene contacto con el ayuntamiendo que se informe./p pa href=http://www.elperiodicomediterraneo.com/noticias/noticia.asp?pkid=471508 title=http://www.elperiodicomediterraneo.com/noticias/noticia.asp?pkid=471508http://www.elperiodicomediterraneo.com/noticias/noticia.asp?pkid=471508/a/p pSaludos/p

pEsto de el guifinet, está muy bien.br / Esto crece ¿Ánimo?/p

Fins aquest matí cada vegada que necessitava crear-me certificats auto-signats (self-signed certificates) usava llarguíssimes llistes d’opcions amb l’openssl, però avui he descobert (digueu-me lent) que si descarregues el paquet d’OpenSSL i el desempaquetes dins del codi font hi ha un directori que es diu: easy-rsa.

Com es pot observar el nom ja dona moltes pistes, doncs bé, dintre d’aquest hi trobem encara un altre directori anomenat 2.0. Aquí dintre, hi ha un munt d’scripts que ens simplificaran moltíssim la vida a l’hora de crear certificats, com sempre en faig un resum en forma de cookbook.

• Editar el fitxer vars. Cal modificar el valor de les variables:
export KEY_COUNTRY="yourContry" export KEY_PROVINCE="yourProvince" export KEY_CITY="yourCity" export KEY_ORG="myOwnOrg" export KEY_EMAIL="user@domain.tld"
• Després netegem el directori de claus perquè no hi hagi restes d’exemples:
./clean-all
• Carreguem variables d’entorn del fitxer vars:
source ./vars
• Creem una CA (Certificate Authority):
./pkitool --initca
• Crear el certificat per un servidor:
# ./pkitool --server # penseu que a vegades el common_name ha de ser el url_host del servidor, per exemple, en servidors https ./pkitool --server nom_servidor
• Certificats per un client:
# ./pkitool ./pkitool nom_client
• Certificat per un client enpaquetat amb PKCS12:
# ./pkitool --pkcs12 ./pkitool --pkcs12 nom_client
• Generar un fitxer DH (Diffie-Hellman)
./pkitool --build-dh

NOTA: en cas de volgueu protegir les claus privades amb una clau simètrica per evitar que siguin usades per tercers persones podeu fer-ho afegint el paràmetre ‘–pass‘ a les comandes anteriors.

Les claus generades les podeu trobar al directori ‘easy-rsa/2.0/keys‘.

Pels que no tingueu massa per la mà el tema dels certificats posaré quatre notes sobre els fitxers creats:

• *.csr: Certificate Signing Request, petició de certificat que s’envia a una CA perquè ens el torni signat.
• *.crt: Certificat signat per una CA
• *.key: Clau privada del certificat, sovint s’acostuma a protegir amb una clau simètrica
• ca.crt: Certificat de la CA
• ca.key: clau privada del certificat de la CA.

Senzill, oi? diria que ja no teniu excusa per gestionar-vos vosaltres mateixos les claus SSL. Si ús calen d’altres funcions al directori esmentat hi ha molts altres scripts i el propi ‘pkitool‘, té força altres opcions molt interessants i igual de simples d’usar.

Pels que ús soni de res el PKCS12 la wikipedia és un bon lloc per coneixer de que va, una definició xapussera de què conté un PKCS12 seria:

• Cert de la CA (Certificate Authority)
• Cert del client
• Clau privada del client

Això permet poder configurar ràpidament clients que han d’usar certificats ja que només tenim un fitxer que posar a la configuració.

A continuació enganxo un petit cookbook que explica com canviar o treure la clau simètrica que protegeix la clau privada del certificat client:

#extreiem private key d'un p12 openssl.exe pkcs12 -in client.p12 -nocerts -out client_private_key.pem #extreiem client certificate d'una p12 openssl pkcs12 -in client.p12 -clcerts -nokeys -out client_cert.pem #extreiem CA d'una p12 openssl pkcs12 -in client.p12 -cacerts -nokeys -out ca_cert.pem #treiem password d'una clau openssl rsa -in client_private_key.pem -out client_private_key.nopass.pem #canvi pass d'una clau openssl rsa -in client_private_key.pem -des3 -out client_private_key.novaclau.pem #creem una p12 a partir dels seus fitxers arrel openssl pkcs12 -export -out client.nou.p12 -in client_cert.pem -inkey client_private_key.novaclau.pem -certfile ca_cert.pem -name "nova clau" -out client.nou.p12

div class=event-nodeapi div class=event-start dtstart title=2009-06-16T07:00:00ZlabelStart: /label 16/06/2009 08:00 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div div class=event-nodeapi div class=event-start dtstart title=2009-06-16T07:00:00ZlabelStart: /label 16/06/2009 08:00 /div /div div class=event-nodeapi div class=event-tzlabelTimezone: /labelEurope/Madrid /div /div pPrueba práctica en Jérica. Intentaremos hacer un despliegue que se vea desde gran parte de la población y lo conectaremos a un ADSL. Si hay tiempo se puede probar una conexión entre Jérica y Castellnovo./p pSi alguien se quiere apuntar, que avise./p pDe momento vamos Miguel y yo. Seguramente quedaremos a las 8:00 de la mañana./p pUn saludo,br / Pablo/p

Per tal d’entendre com funciona ICE el millor és explicar-lo conjuntament amb un altre protocol; ja que com es va comentar a la introducció del NAT traversal el protol ICE usa una combinació del protocol TURN i STUN en funció del cas, això és molt senzill d’entendre si parlem d’un cas pràctic d’ús. O sigui, quan s’intenta que per exmple, SIP travessi un firewall/gateway/router per fer arribar una trucada a un telefon IP.

Què són els candidats?

El Caller envia un missatge de SIP INVITE amb informació SDP que descriu per quina IP i per quins PORTS l’aplicació pot rebre audio i/o video. Aquestes adreces i ports es coneixen com candidates. Aquests candidates s’obtenen del servidor ICE (sovint es troba dins el firewall/router/gateway).

Podriem descriure un candidate com una IP i un port a través dels quals un peer pot rebre dades d’un altre peer. Hi ha tres tipus de candidates:

• Local candidate: IP local del client.
• Reflexive or STUN candidates: una adreça IP pública del servidor NAT.
• Relay o TURN candidate: una adreça o un relay server que ha estat reservat pel client.

El tràfic sempre es podrà enviar amb èxit a través dels relay candidates, a menys que un firewall bloquegi l’enllaç, aleshores no hi ha tècnica possible de NAT traversal a aplicar. El problema d’usar relay candidates és que requereix usar recursos d’un servidor, això fa que el tràfic que arriba al peer tingui retards, perdues i problemes de jitter.

Procés d’establiment d’una trucada SIP via ICE 1. Caller aconsegueix els seus candidates

En el següent gràfic es pot veure com el Caller determinada els reflexive i relay candidates per una connexió. El client envia una petició d’ALLOCATE al servidor, llavors el servidor localitza un parell IP/port (el relay candidate). Aquesta informació s’envia altre cop al Caller (reflexive candidate), aquest missatge conté la IP pública que usarà el Caller quan emeti un missatge a internet, sovint això és la IP a través de la qual s’aplicarà el NAT.

2. Caller envia un SIP INVINTE

El Caller construeix un missatge SIP INVITE usant la informació dels candidates que ha obtingut del seu servidor ICE, després l’envia al seu destí.

3. Callee aconsegueix els candidates

Quan es rep el missatge SIP INVITE, el Callee aconsegueix els candidates de la mateixa manera que ho ha fet el Caller en el punt (1).

4. El Callee envia una resposta 1xx

Seguint amb el protocol SIP, el Callee ha de generar un missatge de resposta al SIP INVITE, per exemple, un SIP 183 (Session Progress). Quan es construeixi aquest missatge dins de l’informació SDP el Callee també hi encapsularà els seus candidates. Fins que aquest missatge no s’hagi rebut i confirmat per part del Caller (200 OK) no es considerarà exitosa la negociació.

5. ICE connectivity checks

Arribats en aquest punt tan el Caller com el Calle saben mutuament els candidates que tenen cadascún i és el moment d’usar el que s’anomena ICE connectivity checks. Això es fa enviant un missatge STUN des del local candidate cap al remote candidate, això es pot fer per tants candidates com hi hagin des del que té més prioritat fins al que en té menys. Això ho faran ambdós costats de l’enllaç si és que tots dos es troven darrera un gateway amb ICE. Quan s’hagi determinat quin dels candidates és el millor per establir cada un dels canals llavors s’escollirà aquest candidate per començar a enviar i rebre media a través seu.

A continuació es poden veure tres exemples de com es fan aquestes proves dels candidates. El primer esquema seria el cas en que ambdós hosts són enrutables directament perquè, per exmple, estan a la mateixa LAN. El segon esquema s’aconseguiria l’enllaç via la metologia STUN i en el tercer via la metodologia TURN.

6. Callee envia SIP 180 (ringing)

En aquest punt el Callee envia el missatge SIP 180 (ringing) al Caller per informar-lo de que el teléfon del Callee esta sonant. Al haver negociat previament el canal de dades a través d’ICE quan el Callee despengi el teléfon ja podrà parlar sense retards, si això es negocies després hi hauria un efecte de retard desagradable pels peers.

7. Accepta la trucada i parlen

Així doncs, quan el Callee despengi s’enviarà un missatge 200 OK i via RTP (per exemple) i usant els canals negociats via ICE el fluxe de dades multimedia (en aquest cas audio) començarà travessant de forma transparent els dos gateways que donen accés a internet als dos peers.

Unes notes per aclarir el tema

En aquest exemple es preten demostrar que podem establir un enllaç RTP a través de dos peers que es troben darrera de NAT gràcies al protocol ICE. Com a protocol per controlar la sessió RTP s’usa SIP, això fa que ambdós peers necessitin una redirecció DNAT al seu gateway cap als ports TCP/UPD 5060. En cas de voler evitar això el que s’hauria d’usar és un altre protocol de senyalització diferent de SIP. Per exemple, si no volem/podem redirigir cap port al gateway es podria usar XMPP.

Glosari

• Caller: qui fa la trucada
• Calee: qui rep la trucada
• SDP: Session Description Protocol
• SIP: Session Initiation Protocol
• Peer: un extrem de la connexió

Referències

• Nat Traversal for IP Communications - White Paper

smalla href=/node/Ninguno/a Estado: Open, until Vie, 04/09/2009 - 23:00, 1 elemento, Total 560,00€/small div class=budgets_bardiv class=bar div class=foreground style=width: 7%;/div/div div class=total7% (40,0 of 560,0€)/div/div

p /ppAvui a Catux el Pinux ha vingut amb un dubte de com posar música a un seguit de diapositives consecutives. Ho hem estat a href=http://answers.yahoo.com/question/index?qid=20080527003902AAYuk1Nmirant/a i es fa de la següent manera:/pp /ppTenim una presentació de tres diapositives. Volem que la música soni a les diapositives 1 i 2, però s'aturi a l'entrar a la diapositiva 3./pp /ppA la primera diapositiva busquem al menú «Presentació de dipositives» - «Transició entre diapositives».  A l'apartat «So» escollim «Un altre so»/pp /pdiv style=text-align: centerimg src=images/stories/Diapo%201.png border=0 width=246 height=210 //divp /ppEns obre una finestra on podem escollir el fitxer de so que volem que reprodueixi. /pp /ppA la segona diapositiva no toquem res, perquè volem que segueixi sonant la música. Ho deixem «sense so»/pp /pdiv style=text-align: centerimg src=images/stories/Diapo%202.png border=0 width=246 height=244 //divp /pp /ppA la tercera volem que s'aturi el so, així que a la transició hi posem «Atura so anterior»/pp /pp /pdiv style=text-align: centerimg src=images/stories/Diapo%203.png border=0 width=246 //divp /pp /pp /p

El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.

Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.

Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.

Diagrama de fluxe del protocol:

Click for (+) Zoom