Mar 08

Getting help to configure spamassassin.conf

Reading time: < 1 minute Configure spamassassin is never easy to do. But when you look for information in Google usually you will be mad . The most common help method in linux is use 'man command' but it doesn't work or information is not enough usually. After a lucky search I found this command to get an extended information about how to configure spamassassin.conf file.

perldoc Mail::SpamAssassin::Conf
Jun 16

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’.

Dec 23

Perl: Template::Extract, Template::Generate i WWW:Mechanize

Reading time: 2 – 4 minutes

perl.png

Normalment no parlo mai de llibreries de Perl, tot i que fa una bona colla d’anys vaig estar usant-lo força. Obviament encara hi havia el PHP3 i el Python no era ni un somni. De fet, no li puc negar la súper potència al Perl simplement el problema que li trobo és que té una sintaxi tan confusa, complexe o espessa, diguem-ho com volguem que si el deixes una temporada després no recordes gairebé res. Però no volia comentar les difícultats que tinc per recordar el que sabia de Perl en aquest article.

Simplement volia aprofitar per referenciar un parell d’articles d’en BrainStorm que parlen d’unes eines que em canviaran la vida la propera vegada que hagi de programar una eina de web spidering. De fet, jo fins ara els anomenava robots, bàsicament eren eines que servien per construir-me bases de dades a partir de webs que disposaben d’informacions molt completes. Per exemple, webs amb reculls de característiques de milers de mòbils.

Les referències als articles:

Les llibreries de les que ens parla en BrainStorm:

  • Template::Extract construïm un template a al aplicar-lo sobre un document HTML ens permet obtenir-ne les dades, sense les etiquetes. De fet, si volem podem fins hi tot escollir quina informació en volem extreure, no tenim perquè extreure-ho tot. Concretament els templates es contrueixen segons la sintaxi que s’anomena TT2.
  • Template::Generate construeix templates estàndars a partir d’un HTML que li passem. Així després només ens cal modificar el template per tal d’ajustar-lo a les necessitats que poguem tenir.
  • WWW::Mechanize podem navegar a través d’una pagina web des de dintre d’un objecte de perl. És genial perquè ens permet arribar a les dades que ens interessa aconseguir de forma completmant transparent. Per exemple, connectem a una web, ens registrem, anem a la zona restringida cliquem a una secció de la web i obtenim la documentació que voliem dintre de l’objecte de perl. Ara si volem li podem aplicar un Template::Extract, per exemple.

Jo diria que es tracta de la trilogia perfecte per generar eines que ens permeten extreure informació de documents HTML. Una altre aplicació que és la que s’ens comenta al segon artícle que he referenciat la creació de resums RSS de pàgines que no disposen d’aquesta funcionalitat.