Author: Oriol Rius
Glosari de Telepathy
Reading time: 3 – 4 minutes
Abans que res una petita introducció a: Què és Telepathy?
Es tracta d’un framework que unifica diferents sistemes de comunicació en temps real. Usa DBUS com a interficie de comunicació entre aplicacions.
Avantatges de Telepathy:
- Temps real: suporta sistemes IM (un-a-un i grups), video trucades i trucades de veu.
- Unificat: permet que diferentes aplicacions i de forma simultànea s’aprofitin de les capacitats del sistema i que treballin de forma col·laborativa.
- Framework: disecciona el sistema de comunicacions en petites parts i les fa tan simples com pot perquè al usar-les contjuntament el procés de comuncació sigui el més senzill possible.
El glosari de termes, en poques paraules el que cal tenir en ment i recordar quan parlem de Telepathy.
- MUC (multi user chat): o també anomenat chat room, o canal de xat.
- Mission Control: responsable de la gestió de comptes de missatgeria: creació de connexions i manteniment dels estats de presència dels contactes.
- Glabbe: és un connection manager de Jabber.
- Tapioca: és un framework per VoIP i aplicacions IM. Suporta SIP/XMPP.
- Farsight: idem que el Tapioca, però orientat a videoconferències.
- Stream Engine: exporta les funcions de Farsight a DBUS. i viceversa.
- Tubes: és el mecanisme que usa Telepathy per suportar transferència de dades entre aplicacions remotes, o sigui: remote IPC. La idea que hi ha darrera és “si dues persones connectades a un servei de IM poden parlar, perquè dues aplicacions connectades a un IM no poder intercanviar informació”.
- Stream Tubes: és un mètode de transport usat per Telepathy molt similar al SOCK_STREAM sockets: enviament de paquets ordenat i confiable.
- IB (in-band): quan els ‘Tubes’ usen el servidor de missatgeria per intercanviar dades. Aquest sistema pot ser molt lent per transportar depèn quin tipus d’informacions, per exemple, sessions VNC.
- OOB (out of band): els ‘Tubes’ de dades usen diferents camins fora de la xarxa XMPP, per exemple, connexions directes entre peers via UDP o TCP.
- Empathy: es tracta d’un client d’IM programat usant les llibreries de Telepathy.
- XEP-0095 Stream Initiation: aquesta especificació defineix una extenció d’XMPP que iniciar fluxes de dades entre dos entitats connectades a la xarxa XMPP. El protocol soporta la possibilitat d’incloure metadades sobre el fluxe de dades a intercanviar.
- XEP-0065 SOCKS5 bytestreams abstract: es defineix una extenció d’XMPP per establir connexions OOB entre dos peers, la connexió entre els peers pot ser directe o via un proxy SOCKS5, en principi la idea és usar TCP per aquests tipus d’enllaços malgrat també podria funcionar per UDP.
- XEP-0163 PEP (Personal Eventing Protocol): defineix la semàntica d’un protocol que usant les funcions publish-subscribe d’XMPP dinfon els canvis d’estat i presencia. D’aquesta forma podem fer funcionar l’estat d’una compte com si es tractés d’un servei pubsub; simplificant la possibilitat de sindicar-nos a dades i notificacions associades amb aquella compte. Un exemple, per fer-ho més entendor: podem tenir un servei d’agenda que ens avisa que hem de fer certes coses si és que estem disponibles però si en canvi este ausents no té sentit que ens avisi.
- XEP-0080 User Location: és una extenció per permet enviar informació sobre la posició geogràfica de l’usuari.
Canvi font del editor d’articles del WordPress
Reading time: < 1 minute Després d'una estona fent canvis, per fi ho he aconseguit. Així doncs, per no perdre-ho: Cal modificar el fitxer: YOUR_WP_PATH/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/content.css a la secció body.mceContentBody
XMPP amb BOSH: usant HTTP com a protocol de transport
Reading time: 4 – 7 minutes
La potència de treballar amb BOSH (Bidirectional-streams Over Synchronous HTTP) rau en que malgrat aparentment l’única forma que hi ha d’implementar XMPP sobre HTTP seria mitjançant tècniques de polling, o sigui, que periódicament el client anés connectant-se al servidor per preguntar si hi ha alguna nova informació per ell.
Doncs BOSH aconsegueix millorar aquest algoritme i el que intenta descriure és quelcom així:
- El client fa una connexió ‘HTTP request’ al servidor
- El servidor no envia cap resposta, així doncs, la connexió no es tanca.
- Quan el servidor té una informació (asíncrona) a enviar al client, llavors busca alguna connexió oberta del client i que estigui esperant resposta, o sigui, qu estigui al punt 2. Llavors el que fa és enviar l’informació a través d’aquesta connexió com una ‘request response’. La connexió es tanca.
- Un cop el client rep l’informació inmediatament després de tancar-se l’enllaç, aquest torna a obrir una connexió contra el servidor, o sigui, tornem al punt 1.
Obviament quan el client té alguna cosa a enviar això es fa en el punt 1.
A l’hora de la veritat els servidors de Jabber/XMPP el que tenen per oferir accés via BOSH és un especie de proxy que rep les connexions HTTP i les processa tal com he explica més amunt, per l’altre costat captura els events que rep de cada un dels clients XMPP que esta instanciant i va connectant els fluxes de dades que rep a través d’XMPP als sockets HTTP que té esperant informació.
Servidors BOSH incrustats en servidors XMPP
Obviament això ens porta a pensar, que podem usar un servidor BOSH per un servidor XMPP que no el suporti a mode de proxy. Això es podria programar de forma força senzilla amb twisted, per altre banda, hi ha servidors XMPP que ja suporten de serie el servidor BOSH, alguns exemples són: ejabberd, Tigase, Openfire i Jabber XCP.
Avantatges de tenir el servidor BOSH dins del servidor XMPP:
- Sovint esta més ben testejat que el codi que podem fer-nos o que ha desenvolupat un tercer per fer aquesta tasca.
- A priori hauria de ser més eficient, ja que la part de recepció d’events/senyals es fa a través de l’API nativa i no pas d’un client XMPP. Cosa que permet estalviar recursos i ser més eficient en la seva tasca.
- És més fàcil de configurar, sovint només cal descomentar la línia corresponent del fitxer de configuració i llestos.
Com que no tot podien ser avantatges aquí van els inconvenients:
- Un servidor BOSH que esta incrustat en un servidor XMPP obviament només pot atendre les peticions que van cap aquell servidor, per tant, si volem que això sigui escalable haurem de montar un balencejador de càrrega sobre el port HTTP per anar desviant connexions entre diferents sevidor BOSH.
- El suport del servidor BOSH esta lligat al suport que la comunitat doni al servidor XMPP amb el que va lligat, això no sempre és suficient.
Quan no hem de suportar més d’un servidor XMPP, i a més aquest ja suporti BOSH no hi ha hauran mai problemes. La cosa es complicarà quan haguem d’escalar aquesta infraestructura.
Servidors BOSH dedicats, per tant independents del servidor XMPP
Per exemple: Punjab, Araneo, JabberHTTPBind i rhb. Pel que fa les avantatges i desavantatges d’aquest tipus de servidors BOSH, obviament són les mateixes que les anteriors però invertides.
Nota final
Per si algú encara no ho tenia clar, això és el que usen les llibreries d’XMPP implementades en JavaScript, o sigui, els client de xat (Jabber/XMPP) que via Web. Per exemple, el client que podem usar des de la pàgina web de gmail.
Obviament les aplicacions Jabber/XMPP són infinites i no només com a clients de xat. Per tant, podeu aprofitar aquestes llibreries JS que implementen BOSH per mostrar de forma interactiva a les vostres interficies web qualsevol tipus de contingut que obtingueu a través de la xarxa XMPP.
Tuning d’un servidor MySQL
Reading time: 2 – 2 minutes
Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.
Doncs bé, coses que he aprés que potser ús poden anar bé són:
- Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
- Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
- Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
- Posar els logs en un disc dedicat, diferent del disc que té les dades.
- Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
- Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
- Montar els directori temporal de MySQL sobre una partició RAM.
- Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
- Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
- Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.
Ja som tients, aquí teniu l’Abril i la Bruna
Reading time: < 1 minute 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.
llibre: “La economía Long Tail”
Reading time: 2 – 4 minutes
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.
compilar VMWare Workstation amb una FC11
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-allencara doni errors de compilació, a mi el que m’ha funcionat ha estat descarregar els fitxers:
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..
openssl: certificats autosignats de forma molt simple
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-dhNOTA: 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.
openssl: canvi de clau privada d’un PKCS12
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 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