Author: Oriol Rius

podcast 1×10: La solució als problemes de Twitter

Reading time: 1 – 2 minutes

Aquest podcast és un experiment entre el Pau Freixes i jo mateix parlant sobre com es podria solucionar els grans problemes de disponibilitat de twitter. Fa molt de temps que dono voltes en com es podria solucionar tota la problemàtica de twitter via un backend de jabber i xmpp. Aquest esquema descriu una mica la idea que s’explica al blog:

twitter schema solution

[display_podcast]

NOTA: a partir d’ara ja no posaré més música de fons als podcast i intentaré no fer gens o quasi gens de post-producció al que gravo. Ja que ni se’m dona bé ni tinc ganes d’invertir el temps en fer coses qu no m’aporten ni em motiven. Crec que el que intento transmetre ja queda clar.

spacewalk – el RedHat Network Satellite alliberat

Reading time: 4 – 6 minutes

spacewalk logoNo sóc un gran coneixedor dels productes de RH, ni tampoc de Fedora ni CentOS. Malgrat això per temes de Kerberos, LDAP i d’altres similars m’estic endinsant força en aquest món. Doncs bé, el dia 20 de juny la gent de RH van alliberar el codi del RedHat Network Satellite al project l’han anomenat spacewalk. Després d’una bona estona llegint la seva documentació volia comentar que la idea que proposen i el nivell d’integració que té l’eina és molt bona, malgrat això he de dir que no hem serveix de gran cosa degut a que esta massa orientat a distribucions amb sistemes de paquets .rpm, o sigui, la propia RH i Fedora sobretot, de CentOS i la resta en parla ben poc.

Cal dir però que les funcionalitats que ofereix són relment una font d’inspiració per d’altres productes que algún dia algú haurà de dissenya per distribucions basades en .deb, o sigui, debian i ubuntu bàsicament.

Llistat de funcionaltats de l’spacewalk:

  • Inventory your systems (hardware and software information)
  • Install and update software on your systems
  • Collect and distribute your custom software packages into manageable groups
  • Provision (kickstart) your systems
  • Manage and deploy configuration files to your systems
  • Monitor your systems
  • Provision and start/stop/configure virtual guests
  • Distribute content across multiple geographical sites in an efficient manner.

A continució ús dono una petita llista d’eines que malgrat no estar tan ben integrades com l’spacewalk i sovint no disposar de bones interficies poden ser un bon punt per començar a solucionar alguns problemes:

  • puppet: basada en un llenguatge ruby com a llenguatge d’scripting per llençar funcions remotament contra sistemes remots, l’eina és realment potent però la veig poc integrada amb el sistema operatiu i es basa molt en funcions com expect per capturar les sortides de les comandes de sistema executades remotament. A més considero que no té un bon sistema d’informes per saber com ha anat el deploy.
  • capistrano: molt semblant a puppet, tan és així que usa també ruby com a llenguatge d’scripting i tots els problemes comentats antiriorment els hi veig també a aquest. Té una mica més ben resolt el tema del feedback dels deploys però sota el meu punt de vista no acaba de ser suficient.
  • func: projecte que també ve de RH i que té el codi alliberat, actualment en fan el manteniment la gent de Fedora. Es basa en Python com a llenguatge d’scripting i ofereix tota una API per la gestió de comandes remotes, ben pensat per xarxes grans ja que permet llençar comandes de forma asícrona. Disposa d’una molt bona integració amb el sistema operatiu gràcies a la gran quantitat de bindings que te Python. Per exemple, com que és un producte de fedora només disposa de binding genèric de yum per instal·lar paquets remotament,  però gràcies a que el llenguatge d’scripting és Python és molt senzill crear un mòdul de func que enllaci amb python-apt i permetre instal·lar paquets a una ubuntu. Aquesta bona integració permet controlar els feedbacks d’una forma molt eficients malgrat no disposa d’eines d’informes pròpies.
  • fai: és una eina pensada per fer instal·lacions automàtiques de distribucions linux o de sistemes de clusters, ja siguin virtualitzats o amb màquines reals. El projecte té uns grans avals i porta moltíssims anys online i actiu. Per tant, dona moltíssima confiança. El dolent és que no sembla trivial d’usar i malgrat té una eina per monitoritzar l’estat del deploy és basa moltíssim en CLI. No he vist cap GUI que en faciliti l’ús excepte GOSA, el qual és un projecte molt ampli d’LDAP bàsicament usat per la migració a Linux de l’ajuntament de Berlin.
  • cobbler: una eina molt semblant a fai, però de la gent de RH i amb el codi alliberat. Té molt bona pinta i a més s’integra amb func. No l’he estudiat a fons encara per saber on té els punts febles, ja que com sempre el que més por fa és la dependència de paquets .rpm; malgrat això disposa d’una interficie web per la gestió, línia de comandes i API en python per extendre les seves funcionalitats i sempre es podria lligar una instal·lació cobbler amb func perquè fos compatible amb ubuntu tal com havia comentat abans.

rinetd – un altre bouncer per TCP

Reading time: 2 – 2 minutes

L’abril del 2007 ja vaig parlar sobre tcpxd el qual permetia fer el mateix que rinetd. Obviament tenen algunes diferencies funcionals, sota el meu punt de vista rinetd és més professional ja que integra a partir d’un fitxer de coniguració la possibilitat de redireccionar un port TCP en qualsevol de les IPs que estem publicant en el host on es llenci el servei. A més el fitxer de configuració ja diu tot el que cal saber de com funiona:

# bindadress    bindport  connectaddress  connectport
1.2.3.4         80        4.3.2.1         80
1.2.3.4         443       4.3.2.1         443

Algunes altres funconalitats que m’han agradat molt és la possibilitat de fer una llista ACL de rangs d’IPs permesos i no permesos. Per si això fos poc suporta logging. A més el podem trobar com a paquet de les distribucions de linux: gentoo, ubuntu i debian. Potser hi ha altres distribucions que el tenen però la veritat és que no les uso. També aprofitor per recordar-vos que si necessiteu fer coses d’aquest estil amb windows podeu llegir aquest article: Redirigir ports amb Windows (Port Forwarding, DNAT, NAPT).

Si esteu familiaritzats amb iptables i voleu fer una redirecció poseu-hi una mica d’enginy i podreu fer-ho amb relges tan simples com aquesta:

YourIP=1.2.3.4
YourPort=80
TargetIP=2.3.4.5
TargetPort=22

iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT --to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT --to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT --to-destination $TargetIP:$TargetPort

Microfon intern del Dell XPS m1330 funciona amb Linux

Reading time: < 1 minute No m'havia posat a provar mai el microfon intern del portàtil ja que sempre havia llegit que no funcionava. Però ahir vaig actualitzar el kernel a la verisó 2.6.25-gentoo-r5 i hem vaig decidir a provar a veure què tal. Doncs bé la veritat és que oli en un llum. Ja que només he hagut de canviar la font d’entrada de gravacions i ha funcionat a la primera així és com l’he de deixar:

gnome volume manager

La veritat és que he tingut molta sort 😉

Penedesfera: 1ers jornades

Reading time: 2 – 4 minutes

logo penedesferaDivendres passat i per casualitats de la vida em vaig enterar de que es celebraven a Gelida les primeres jornades de la Penedesfera. Doncs bé, la casualitat va ser gràcies a un twit del marcvidal que vaig començar a estirar del tema fins a descobrir que també hi havia convocada la gent de guifi.net per parlar del seu projecte. Doncs com que fa temps que els tinc molt abandonats a la colla de guifi.net li vaig fer un toc a en Ramon em va dir que si que hi seria i vaig agafar el cotxe i cap a Gelida.

1era jornada de la Penedesfera

Allà vaig retrobar-me amb una bona colla de guiferos i bloguers, a més de poder coneixer en persona al Marc Vidal que és un dels molts contactes que tinc a twitter i que no tenia el plaer de coneixer en persona. Llàstima no poder quedar-me fins al final de la sessió i encara menys no poder assistir a les jornades del dissabte. El que més em va agradar és veure el viva que esta la comunitat. Amb gent que té ganes de fer coses i el millor és veure com cada cop les barreres tecnològiques són un problema menys per sumar esforços.

De fet, jo mai m’he considerat un bon divulgador de tecnologia pel ‘poble’, de fet, tampoc ho he pretès això si he intentat posar el meu granet d’arena en la part més tecnòloga profunda que és on realment crec que aporto algo de valor. Diria que hi ha d’haver gent per tot per fer de ‘professors’, investigadors, desenvolupadors, analísties, etc. tampoc sabria on posar-me jo de totes aquestes etiquetes però de divulgador de temes iniciàtics segur que no.

Bé doncs, a veure si hi ha sort i tot això continua amb tanta o més força. A més ja m’he donat d’alta a la web de penedesfera i m’he posat el logo per donar-hi suport a la part dreta del blog. Com hi va la gent de les meves comarques, eh!?

Actualització: si voleu accedir a material  de les jornades esta disponible a l’arxiu de les jornades de la Penedesfera.

Reddit open source: aplicacions que destaco…

Reading time: 4 – 6 minutes

reddit logoAquest matí l’Alfredo m’ha informat que reddit ha obert el seu codi. Doncs bé després de mirar-me cada un dels components que ha explicat que esta usant m’ha faltat temps per passar-me per cada una de les pàgines web de les aplicacions per mirar-me a veure què tal. A continuació ús faig una llista del que més destaco, obviament són les aplicacions més inusuals i menys conegudes.

  • HAProxy: és un aplicatiu molt semblant al Pound, la seva finalitat es balacejar les peticions HTTP entre diferents servidors. Malgrat són aplicacions similars Pound i HAProxy poden treballar de forma combinada. Diguem que HAProxy esta molt més orientat a grans infraestructures i Pound és per entorns de carrega mitjana. El bo és que podem usar HAProxy i darrera usar Pound per fer redireccions més refinades en funció da la URL o certs paràmetres de les HTTP headers. També és diferencien bàsicament amb el tractament que fan dels paquets HTTPs, la qual també convida a treballar amb les dues eines a la vegada. Ja que podriem montar un sistema per escalar peticions HTTPs de forma segura i simple.
  • Slony-l:és un sistema de replicació master-slave que suporta treballar en cascada i amb failover. A més esta pensat per treballar amb bases de dades grans. Bàsicament usat pel PostgreSQL que usa reddit, això els permet tenir molts servidors de bases de dades de lectura que són les peticions que bàsicament tenen a la base de dades.
  • Pylons: es tracta d’un framework MVC que usa Python, és realment lleuger i combina idees del món Ruby, Python i Perl. Potser una de les coses que més sobte és que els projectes de Pylons no requereixe servidor web sinó es vol, ja que ells mateixos ja n’implementen un amb Python, a més de tenir un instal·lador del projecte que creem només pel sol fet de crear el projecte. Si ja controleu algún tipus d’MVC i esteu una mica familiaritzats amb la sintaxis de Python podeu veure l’screencast: Special Edition Screencast: Pylons with Tesla. Amb aquest screencast ús podreu fer una molt bona idea de com funciona aquest MVC i de la seva potència. S’ha de reconeixer que promet molt no ús perdeu el sistema de debug, realment m’ha agradat moltíssim pensava que el debug de Symfony era bo, però aquest encara el supera.
  • Slor: es tracta d’un servidor d’indexació d’informació web implementat sobre Tomcat i que ofereix serveis de consulta via JSON i d’altres sistemes webservice que simplifiquen moltíssim la seva integració amb d’altres arquitectures. A més disposa d’una llista de funcionalitats molt atractives.
  • Daemontools: una eina realment senzilla i potent, bàsicament només serveix per llençar processos com a dimonis o directament dimonis en si mateixos. El bo és que controla aquests dimonis per si aquests cauen tornar-los a aixecar. La veritat és que malgrat ser una mica més gran diria que és millor monit. Tot i que s’ha de dir que es triga molt mé  montar monit que no pas daemontools i com que la gent de reddit ja usen Ganglia com a sistema de monitorització no s’han complicat amb el monit.

S’ha de reconeixer que han fet molt bones eleccions aquesta colla, a més s’ha demostrat que són realment escalables i que la seva disponibilitat és envejable. Un bon exemple de com fer les coses bé i senzilles des del principi. La gent de twitter en podrien prendre bona nota. Si ús fa il·lusió un dia d’aquests ús explicaré les meves idees de com fer que twitter sigui molt escalable i no s’enfosi amb els 2M d’usuaris que té diariament, la qual cosa no em sembla cap exageració amb un bon disseny darrera segur que en Pau pateix molt més amb els seus milions de megues a indexar diarimant.

gDevilspie: entorn GTK per configurar el devilspie

Reading time: 2 – 2 minutes

Aquest ja és el tercer article que escric parlant de devilspie, així doncs no tornaré a explicar el perquè serveix si ho voleu saber:

Però la veritat és que feia uns mesos que l’havia deixat d’usar però hi he hagut de tornar. Des de fa força temps treballo amb dues pantalles, la del portàtil i una de 22″ tan a l’oficina com a casa. Doncs bé, fins ara ho feia amb Xinerama però degut als problemes que vaig tenir amb la NVidia i el Xinerama m’he passat a TwinView així puc usar el Compiz i uso les X’s al més pur estil Mac. De fet, jo diria al més pur estil Oriol 😉

screenshot of my laptop desktop

Doncs bé, tornant al que volia comentar el gDevilspie és un projecte que afeix una interficie gràfica que malgrat limita les amplies funcions de configuració que té el devilspie serveix per la majoria de configuracions i simplifica infinitament l’obtenció de propietats d’una finestra i a partir d’aquí generar les configuracions amb quatre clicks. Realment fa molt més agradable la tasca de configurar el devilspie que és per on coixeja més sota el meu punt de vista.

tcpflow: mirant streams tcp en un moment

Reading time: 1 – 2 minutes

Fins ara per poder seguir un protocol dins del enllaç TCP, o sigui els missatges de la capa 5, sempre acabava capturant-lo amb el wireshark o en el seu defecte amb el tcpdump generava un fitxer .cap que després obria al wireshark i a través d’una funció tan simple com el Follow TCP stream em montava la sessió de capa d’aplciació que podia seguir de forma ben còmode. El gran descobriment que vaig fer l’altre dia és el tcpflow una eina la mar de simple i lleugera que com no podia ser d’altre forma usa les llibreries libpcap, le mateixes que el tcpdump i el wireshark per mostrar-nos de forma completament visual i simple a través de la consola o contra un fitxer el contingut de la sessió TCP. Espero que li tregueu tan profit com jo a l’eina.

podcast 1×08: CAS, Central Authentication Server

Reading time: 3 – 4 minutes

L’objectiu d’aquest podcast és donar una visió conceptual del funcionament de CAS 2.0, un servidor d’autenticacions SSO (Single Sign On). Bàsicament esta orientat a usuaris d’aplicacions amb interficie Web. A movilpoint l’estem usant tal com vaig comentar al podcast 1×07.

La diferència entre 1.0 i 2.0 és que la versió 1.0 només podia autenticar usuaris contra aplicacions web i aquests serveis no podien autenticar-se a la seva vegada contra altres serveis (serveis backend).

Amb l’esquema que hi ha a continuació i la previa lectura de les entitats d’un sistema CAS podreu seguir el podcast:


CAS - Central Authentication Server (schema)

A continuació descric les entitats que intervenen en un sistema CAS.

  • Service Ticket (ST): és una cadena de text que usa el client com a credencial per obtenir accés a un servei. Aquest tiquet s’obté del servidor CAS. La forma d’obtenir-lo és a través d’una cookie que es guarda al navegador.
  • Ticket Granting Cookie (TGC): cookie que s’envia al CAS quan un browser ja ha estat autenticat previament per aquest CAS, llavors aquest reconeix la cookie i li dona al browser un Service Ticket (ST) sense haver de passar el procés d’autenticació manual. Caduca en unes 8h aproximadament.
  • NetID: identifica a un ususari, el que coneixem habitualment com username.
  • ServiceID: identificador d’un servei, normalment en format URL.
  • Proxy Ticket (PT): és una altre cadena de text que usa un servei com a credencial per obtenir accés a un servei de backend. O sigui, que el primer servei per tal de desenvolupar la seva activitat li fa falta accedir a un altre servei (servei de backend), per tal d’obtenir accés a aquest darrer servei el primer usarà un proxy ticket. Aquest tiquets s’obtenen al CAS quan el servei que vol l’accés presenta un PGT (Proxy-Granting Ticket) i un identificador de servei que es refereix al servei de backend.
  • Proxy-Granting Ticket (PGT o PGTID): es tracta d’una altre cadena de text que com hem vist al punt anterior l’usa el servei per aconseguir un Proxy Ticket (PT) que li doni accés a un backend service l’accés a aquest servei serà amb les mateixes credencials que l’usuari original, o sigui, el que s’ha autenticat al primer servei.
  • Proxy-Granting Ticket IOU (PGTIOU): com no podia ser d’altre manera és una cadena de text que es passa com a resposta del serviceValidate i del proxyValidate usada per correlacionar un Service Ticket o una validació de Proxy Ticket amb un Proxy-Granting Ticket (PGT) particular.

Ara només queda escoltar el podcast:

[display_podcast]

Els enllaços relacionats amb el podcast:

NOTA: donar les gràcies al Marc Torres per la seva feina, gràcies nano.

Scroll to Top