TCP bouncer amb failover
Al projecte GATv2 fa un parell de dies que hi he publicat un subprojecte que anomeno tcp-fwd. Es tracta d’un petit i simple aplicatiu programat amb Python i Twisted. La funcionalitat és molt senzilla es tracta d’un bouncer TCP que en cas de no poder connectar amb el primer destí on re-enviar el tràfic TCP ho prova amb el segon, sinó el tercer i així fins a tants servidors com s’hagin definit. Si no es pot acabar establint la connexió es desconnecta l’enllaç TCP cap al bouncer. O sigui, el comportament és transparent pel client original. Pels que no estigueu familiaritzats amb la funcionalitat d’un bouncer la intentaré explicar. Es tracta d’un socket TCP que escolta en un port i actua com un reverse proxy. O sigui, quan rep una connexió acte seguis s’obre una altre connexió cap al servidor i si aquesta es pot establir llavors connecta la primera connexió amb la segona.
L’inconvenient més gran que veig en aquesta idea és que la connexió que arriba al servidor final no té com a origien la IP del client, sinó la IP del servidor que fa de bouncer això fa que el fitxer de logs del servidor final no tingui la informació IP del client que realment s’ha connectat. Malgrat axiò hi ha escenaris en que aquesta eina és molt útil, ja que no sempre el més important són aquests logs sinó que el client acaba obtenint el servei que volia de forma trasparent i el sistema de failover que uso sempre segueix la mateixa seqüència de prova i error per cada socket que s’obre, així doncs, el sistema de failover és instantani i no perd ni una sola crida.
Una de les aplicacions per les que l’estic usant és per fer l’entrega de correu a un postfix. Es tracta d’un servidor de correu que només fa filtratge de correu i els correus que passen els filtres s’entreguen al servidor de correu real de l’empresa, doncs bé, per saber quin és el servidor de l’empresa uso el fitxer de configuració /etc/postfix/transport on s’indica segons el domini el servidor on entregar el correu. Però no he sabut veure com dir-li més d’un servidor de correu on fer l’entrega. Així doncs, el que faig és posar com a IP i port de transport una IP localhost i un port al atzar, llavors el postfix entrega el correu al bouncer situat en aquesta IP localhost i és el bouncer que intenta connectar aquest socket amb algún dels servidors de correu interns. Per tant, el tema és completament transparent pel postfix i els servidors que reben el correu tenen la mateixa IP origen que si ho haguessin rebut directament del postfix.
Suposo que la idea ha quedat ben definida, sinó ja sabeu que podeu fer-me les preguntes que calguin. El codi del projecte el teniu a: tcp-fwd.
ssldump depuració de tràfic xifrat
Tothom coneix el TCPdump i fins hi tot hi ha gent com jo que l’usem a diari, de fet, no fa massa temps vaig re-descobrir el TCPflow (ja l’havia descobert abans, però vaig cometre el gran error d’oblidar-lo). Doncs bé, el problema d’aquestes eines és que són molt útils per tràfic sense xifrar però quan es tracta de tràfic xifrat amb SSL/TLS com ara HTTPs o d’altres protocols que viatgen xifrats i volem saber perquè no funcionen hem de recorrer a eines com el ssldump.
SSLdump permet seguir el fluxe de les conexions TCP xifrades amb SSLv3/TLS. Obviament per aconseguir desxifrar el contingut de l’enllaç hem de facilitar-li els certificats corresponents a l’eina. Però no només ens permet depurar a nivell de dades que corren per TCP sinó que també ens dona informació del propi protocol de xifrat descrita de forma humana. O sigui, que podem saber si el problema de l’enllaç és produeix durant el procés de handshake, ChangeCipherSpec o dins del protocol.
El que jo feia fins ara per poder analitzar el contingut d’un protocol que viatge xifrat és ajudar-me de l’eina sslproxy. La qual feia de bouncer al servidor de protocol o al client, així doncs obtenia un tram de la conexió que no anava xifrat i a través del tcpflow o el tcpdump podia obtenir el tràfic en clar. La tècnica és enginyosa i útil però ferragosa en comparació al ssldump.
webcam del Dell m1330 en linux
La webcam del portàtil és una Omnivision amb resolució VGA, concretametn el model usa el idProduct: 0x7670. Doncs bé, gairebé mai uso la webcam així doncs un dia la vaig configurar i després se’m va oblidar com ho havia fet, avui actualitzant la Gentoo ho he recordat i vaig a posar les quatre notes aquí per si poden ajudar a algú i així ho usaré de recordatori per mi mateix.
En Gentoo la gràcia esta en tenir instal·lat el paquet: media-video/linux-uvc, aquest paquet genera un mòdul del kernel anomenat uvcvideo.ko que podem carregar amb un simple modprobe. Després, per exemple, amb el paquet media-video/luvcview podem llençar un simple aplicatiu anomenat: luvcview que ens permetrar fer captures de pantalla i de video a través de la webcam.
Com podeu veure ben senzill de configurar i d’usar, ara només cal que no feu com jo que no l’he usat mai més que per fer proves.
Symfony+Propel: usar múltiples schemas en un sol projecte
La idea que es persegueix al usar múltiples esquemes en un sol projecte és la de poder usar múltiples bases de dades en un sol projecte. La idea sembla molt senzilla, però a través de la documentació oficial del projecte Symfony la veritat és que no he sabut trobar la solució. En l’explicació per portar a terme aquesta funcionalitat hem referiré tota l’estona als fitxers .yml i no als .xml equivalents, però suposo que la idea és totalment exportable.
Es tracta de deixar d’usar el fitxer schemal.yml i passar a usar diferents fitxers anomentats nomarbitrari_schema.yml, si encomptes d’un nom voleu usar un número tampoc hi ha problemes per fer-ho, per exemple, 1_schema.yml i successius.
Pel que fa al contingut d’aquests fitxers és el de sempre, tot i que jo ús recomanaria usar petites ajudes com aquesta:
nombasededades:
_attributes:
package: lib.model.nombasededades
Aquest nombasededades l’usarem després per especificar les dades de connexió al fitxer databases.yml, però potser el més interessant és fixar-se en el paràmetre package que ens permet que tot el model de dades quedi guardat dins de lib/model/nombasedades. O sigui, que tot queda molt més ben organitzat i fàcil d’accedir.
Cal que vigileu si dues bases de dades tenen dues taules que s’anomenen igual, ja que si això passa llavors hi haurà un conflicte en els models de dades que es generen, perquè aquestes tindran el mateix nom. Això és fàcilment solucionable simplement a l’schema heu de dir-li que el nom de la classe que representa les dades d’aquella taula de la base de dades és un nom diferent al de la taula, o sigui, el nom escollit per defecte.
Pel que fa al fitxer databases.yml el seu contingut és el de sempre, simplement cal que penseu que cal descriure la connexió de cada una de les bases de dades que heu anat declarant als diferents fitxers d’schema.yml, un exemple:
all:
nombasededades1:
class: sfPropelDatabase
param:
...
nombasededades2:
class: sfPropelDatabase
param:
...
Un cop ben configurat tot això ja podem fer un típic symfony propel-build-model i llestos.
Setmanes intenses
Tinc pendents d’escriure alguns articles sobre temes tècnics interessants de coses que he fet aquestes setmanes, de fet, més d’un és quasi obligatori escriurel. Per exemple, la solució del desafio de networking. Però en aquest article faré un petit resum de coses que he estat fent aquests dies i que no he pogut reportar de forma puntual.
Primer de tot destacar la festassa que varem organitzar els amics del Manel i el Xavi, brutal la coordinació entre la Vane, Glòria, Sabina, Estefania i jo amb l’ajuda improvisada a l’últim moment de la gent de Torrelavit i d’altres que coneixia menys. Doncs bé, realment diria que va sortir una festa rodona. A part de convidar-vos a veure les fotos que ben aviat espero tenir online, comentar que el lloc estava súper bé. El recomano: la Marinada. Una casa de colònies a Cambrils ben aprop del mar i amb tot el que fa falta per passar un aniversari inoblidable.
Com a detall comentar que al Manel li varem fer un regal d’una empresa que vaig sentir per la radio: muchomasqueunregalo.com, realment el tema és molt original perquè es tracta de regalar experiències o sensacions. O sigui, que teniu tot un catàleg de coses ben originals per regalar. Alguns exemples: conduir un F1, volar en un avió dels que fan piruetes, saltar en paracaigudes, fer puenting, fer una excursió en trineu, bany amb xocolata, teràpies relaxans, etc. Des de 30€ fins al que ús volgue gastar teniu tot tipus de regals ben originals. A més ús envien una caixa de color vermell molt ben presentada amb una targeta i una xapa de propaganda de l’empresa, o sigui, que no heu de donar el típic paper d’impresora ‘cutre’ que sembla que hagueu escollit el regal els últims minuts.
Sobre el tema de la caixa roja, doncs la qüestió és que vaig tenir una incidència i hem va arribar xafada, així doncs els vaig escriure un email queixant-me i en poques hores vaig rebre una trucada telefónica demanant-me disculpes i oferint-me enviar-me’n una altre o podia passar-ne a recollir una a Barcelona. Com que això no era possible hem van dir que els 20€ de ports urgents que havia demanat me’ls descomptarien. Per tant, he de dir que el servei de l’empresa impecable. Tot i que de moment encara no he pogut comprovar que m’hagin tornat els diners. Però no siguem dolents i confiem en que ben aviat ho pugui veure reflexat al meu compte corrent.
Potser l’única nota negativa de l’event és que de forma molt extranya i sospitosa va desapareixer el meu mòbil. Concretament l’HTC Artemis, si aquella que li havia canviat la pantalla fa uns mesos després de que hem caigués a terra. Doncs bé, ja m’he quedat sense Artemis. Així doncs, m’ha tocat buscar-me la vida i aconseguir una nova HTC per ser el meu mòbil personal, concretament ara tinc una HTC Cruise (aka Polaris). Escencialment és idèntica a l’Artemis però amb més CPU, 3G y 3MPixels de càmara. La carcasa pràcticament és igual i la pantalla, radio FM, GPS, microSD, càmara VGA frontal i d’altres són clavats. Però he de dir que sobretot el tema de la CPU es nota moltíssim. Així doncs, no hay mal que por bien no venga.
Una altre anècdota interessant que m’ha passat aquests dies va ser la nit del 10 de setembre a les celebracions de la dia nacional de Catalunya del dia 11 que es varen fer a Vilafranca. Aquest dia varem anar a sopar a casa el Xavi i la Sabina, junt amb la Glòria i la Daphne. Com que viuen ben aprop del centre i feien castellers a la plaça de la vila varem anar a fer-hi una ullada. Com sempre i malgrat hi havia poca gent els castells et posen la pell de gallina i et fan un nus al coll. Però l’anècdota va ser quan al tercer castell de la nit un 2 de 9, els faltava gent per fer pinya i el cap de colla se’ns va acostar i ens va demanar al Xavi i a mi que ens posessim a la pinya. Al Xavi ràpidament el vaig perdre de vista entre tanta gent, però jo vaig acabar estan ben aprop del centre i em vaig emportar més d’una trepitjada als ombros, malgrat això he de dir que l’experiència va ser impressionant i inoblidable. Realment s’ha de reconeixer que potser és una de les tradicions que més valoro del nostre país.
Una altre curiositat d’aquests dies de silènci al blog i tornant al meu caràcter geek innat és que vaig passar unes quantes hores amb el Manel recuperant uns fitxers borrats d’un XFS d’un NAS amb 4 discos de 250Gb en RAID 10. O sigui, tot un lio arribar fins als 70Gb de fitxers borrats per un error i una mala política de permisos. Però el que ara volia comentar és que el Manel em va ensenya un disc dur petitíssim, realment espectacular no recordo quantes gigues tenia però unes quantes. Pel que es veu el disc té 3 anys i en aquell moment era el més petit del món realment espectacular:
Pels que no estigueu enterats el Manel s’ha montat una empresa de recuperació de dades: Info Rescate i acaba d’arribar de l’India on ha anat a fer-hi un curs de dues setmanes sobre aquest tema. De fet, li va anar ben just arribar de l’India i anar a la seva festa d’aniversari. Però seguint amb el tema de l’India, què passa amb aquest país? és realment espectacular la quantitat de gent que coneixo que ha anat a aquest país els últims mesos potser en podria dir uns 10 ara mateix. Potser el cas més espectacular el del Carles que hi ha passat uns 6 mesos i fins hi tot ha fet un blog de la seva experiència: Nomada la gana.
Per si tota aquesta gent que ha anat a l’india no fossin pocs ahir a la nit varem ser al sopar de comiat del meu germà, que aquest dimecres que ve se’n va a Nepal i l’India durant dos mesos i mig. O sigui, que realment esta passant algo per aquelles contrades que atrau a la gent com imans. De totes formes he de dir que personalment a mi no hem crida gens el tema. He de dir que assia m’agrada molt i hi ha molts països que vull anar a visitar per allà, a part dels que ja he vist, però de ben segur que l’India no és dels que més hem criden. Qui sap potser per les festes de nadal ens podem escapar a Vietnam, Singapur o Malaïsia… esperem que la butxaca hi arribi.
Problemes de rendiment OpenFiler amb VMWare Server [solucionat]
Després de molts mesos amb un greu problema de rendiment al servidor SAN/NAS de casa que tinc montat en una màqina virtual d’VMWare Server sobre Ubuntu 8.04 LTS, per fi m’he decidit a arreglar el problema. En algún altre post havia comentat el problema, la qüestió és que el rendiment dels 1.5Tb que tinc al servidor des del sistema operatiu de Host és d’uns 70MB/s però les mateixes proves des dels discos gestionats per la màquina Guest, o sigui l’OpenFiler, donaven uns patetis 3, 4 o com a molt 5MB/s. O sigui, que quan s’accedia per NFS o SMB als recursos compartits el rendiment era insuficient i d’altres servidors o màquines que usen aquests recursos se’n veien repercutits.
Finalment després de buscar una mica vaig veure que el problema venia de les interrupcions del sistema que es perdien degut a que el clock rate del servidor Host no era capaç de processar tantes interrupcions. Així doncs, investigant sobre el tema vaig veure que el que cal fer és donar suport HPET, en el meu cas perquè això funcioni ho he hagut d’activar també a la BIOS del HP ML110 que uso com a servidor físic. Amb aquests canvis els tests de velocitat de la màquina virtual amb OpenFiler m’han millorat substancialment i ara mateix donen resultats al voltant de 50MB/s. Obviament, encara estic lluny d’un rendiment òptim però ja no sé si això és tema de configuració o si el problema és més profund i ja depèn de la propia gestió interna que fa l’VMWare amb els mòduls que fan d’interficies entre el hardware real i el virtual.
Si voleu saber si teniu el HPET activat o no al kernel és tan senzill com mirar al dmesg:
root@vm0:~# dmesg |grep hpe
[ 120.210408] hpet clockevent registered
[ 120.210412] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 120.210416] hpet0: 3 64-bit timers, 14318180 HzEn cas de no tenir-lo activat, cal que activeu el següent al fitxer .config del kernel:
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC=y
A part d’això hi ha d’altres opcions per tal d’acotar aquest tipus de problemes, algunes que permeten estabilitzar les màquines virtuals malgrat no les expremem al màxim ens poden permetre funcionar millor si el rendiment no és el màxim dels nostres problemes i no saturem el Host. Per exemple, es pot afegir al fitxer .vmx de la màquina virtual la següent opció:
host.useFastClock = FALSE
Per cert, si voleu identificar el problema el kernel de la màquina Host dona errors de l’estil:
Aug 21 12:56:11 dey kernel: rtc: lost some interrupts at 2048Hz.
o també coses així:
select() to /dev/rtc to wait for clock tick timed out.
Com sempre a google podeu trobar moltíssima informació de com ajustar el vostre Linux perquè rendeixi al màxim amb VMWare. Per la meva part, ara hem queda posar en marxa mil i una coses que depenien d’aquest servidor de fitxers que mica en mica anava obligant-me a parar serveis per manca de rendiment. Espero que properament ja pugui posar en marxa funcions com l’album de fotografies i d’altres similars.