A moltes persones els costa entendre a quin mercat esta orientat movilpoint, doncs bé, aquest setembre i per primer cop a aquest país es farà una fira a Madrid sobre Digital Signage, mercat en el qual treballa l’empresa on treballo com CTO. Doncs bé, a la web de la fira: www.total-media.es he trobat el video que penjo a continuació i que explica diria jo que molt bé de què tracta el mercat del digital signage.

No oblideu el motto de movilpoint: kiosks and digital signage technologies

Avui he arribat de les mini-vacances per no parlar d’un cap de setmana llarg. De fet, qui no esta content és perquè no vol. La qüestió és que divendres hem vaig agafar el dia de festa i Estefania i jo varem sortir disparats com coets cap al Hotel Balneario Vilas del Turbón. Aquest lloc perdut de la mà de deu a terres d’Osca el varem coneixer no fa ni dues setmanes gràcies a que el Xavi i la Sabina i varen ser amb uns amics. Doncs bé, com a nota li posariem un cinquillo no massa més tot i que si fem una relació qualitat preu potser hauriem de pujar a un sis o un set. Ja que realment per ser temporada alta i per totes les terapies que ens han fet el preu era més que reaonable. Potser on la cosa coixejava una mica és en la qualitat dels mateixo però no pas pels recurso materials o per le instal·lacions en si mateixes sinó per la qualitat del personal. Potser és que jo sóc molt exigent ja que com diu la Neus a mi m’han fet tractaments i massatges a molts països diferents, de fet, té raó i això li he d’agraïr a la Daphne. De fet, un gran secret a crits és que sempre he volgut montar una blog sobre aquesta temàtica, o sigui, massatges balnearis i d’altres similars.

Tornant a Vilas del Turbón, de fet, el nom bé d’un petit poble de 38 habitants en el que trobem el balneari. El lloc sense cap luxe però molt net, pulit i acollidor disposa d’una gastronomia casolana que et deixa sempre satisfet i malgrat ser molt estrictes amb els horaris les taules i les formes de demanar el que menjarem al dia següent no tinc cap queixa del servei al contrari. Pel que fa a les terapies doncs el que ja deia abans, les instal·lacions estan molt bé… lluny dels gran hotels de luxe orientas o americans on he anat algunes vegades però malgrat això tot és molt nou i xulo a la part del Balneari. Llàsitma que el personal no disposava de l’experiència i l’energia necessaris per fer-nos disfrutar del paquet de tractaments que varem contractar. Tot i amb això varem saber treure-li el suc al tema.

Per concloure el resum, comentar com a cosa positiva que el lloc esta molt aïllat i per tant, no hi ha cobertura. Requisit indispensable per una bona desconnexió de món. L’entorn és genial i es troba a 1.500m d’altura aproximadament, o sigui, que de calor ben poca malgrat he vingut ben vermell de prendre el solet. Però això és un luxe que només pots prendret en les hores centrals del dia després fa una fresqueta molt agradable i més si tenim en compte que estem al mes d’agost. Des de Torelavit (el meu poble) el lloc es troba a unes dues hores llargues de camí, així doncs, en bona companyia i bona música no es fa llarg arribar-hi. Perquè ús en feu una idea es troba a l’altura de la Pobla de Segur, però a la zona aragonesa. Si no recordo malament la zona rep el nom del riu més famós que passa per allà: Ribagorzana. Concretament entre Benasque i Benabarre.

Aquesta tarda he estat provant el Huawei E960 de Voafone, després de l’experiència llarga i dur amb els Linksys WRT54G3G avui tocava descobrir el nou producte de Vodafone. Doncs bé, dir que venint dels Linksys que tants i tants problemes m’han donat, penseu que en tenim ara mateix instal·lats més de 200 i s’espera tenir-ne molts més en els propers mesos i la cosa esta lluny de funcionar bé. Per un costat els problemes de cobertura de l’operadora sobre els que no s’hi poden fer res i per l’altre el fet de que les targetes PCMCIA no acaben de funcionar massa bé ni soles ni amb el router Linksys com a host.

Els problemes típics han estat connexions que el router no informava correctament amb els leds, problemes de bloqueix de SIM per excés de reintents després de que la configuració es guardés malament, molts problemes d’accés a l’interficie web per la configuració i moltes connexions en falç fetes pel propi router. O sigui, connexions no demanades, connexions demanades i no detectades, etc. Per no parlar de la pobre configuració del linux que porta el Linksys dintre que fan que el rendiment del petit switch que incorpora l’aparell funcioni prou malament amb d’altres linux connectats a ell.

Bé doncs, al que toca. El nou router de Vodafone no és pas la ‘panacea‘ ni la solució a tots els malts de caps, però de moment sembla molt més estable i el que ja salta a la vista és que aquest mateix article l’estic escribint connectat des de casa meva a 2.6Mbps que malgrat estar lluny de ser reals donen un bon servei. Així doncs, això pot ser una gran notícia per alguns torrelavidencs que no disposen d’ADSL per manca de qualitat en les seves línies.

Pros a favor del modem/router:

• Pots connectar-hi un telèfon analògic i usar el router per trucar com si es tractés d’un fix
• 4 ports ethernet, que sembla que funcionen millor que en el Linksys
• CD d’instal·lació com a dispositiu Mass Storage USB dins el propi router
• Alimentació amb connector USB tipus B, via port USB o via transformador
• Suporta molts mètodes d’autenticació wi-fi, lluny de ser professional però destaca el suport d’WPA2
• Molt compacte
• No usa PCMCIA, per tant, disposa d’un compartiment especial per la SIM
• Sembla estable, de moment
• Bones orelles, o sigui, deu tenir una bona antena per aconseguir treure connexions HDSPA des del meu poble
• Fàcil usar-lo en mode DMZ o redirigit conta un servidor/firewall

Contres:

• No hem funciona com a modem USB a la primera al connectar-lo a un WinXP amb SP2, no he intentat arreglar el problema
• Interficie web de configuració molt pobre i lletja, malgrat això sembla que funciona ràpid i bé
• Firewall intern molt lamentable, lleig i limitat. Poc intuitiu el tema del NAT
• No suporta DynDNS (o similars), el Linksys si que ho suportava

En poques paraules aquest és el meu anàlisis del dispositiu. Com ja deia no és per tirar coets però sembla que algo de millora si que és sobre el Linksys.

UPDATE: ahir estava una mica espès i no se’m va acudir enganxar el test de velocitat que vaig fer amb el dispositiu, aquí teniu el test fet des de casa meva al mig de la muntanya

GatV2 es un servidor de correo para hacer smart-relay o para que se entienda mejor el concepto para usar como frontend del servidor de correo de la empresa o del ISP (backend). GatV2 nos filtra todo el correo UCE y nos ofrece una herramienta de gestión del SPAM.

El siguiente esquema ofrece una idea de donde estaría el GatV2:

A través del podcast podreis seguir cual es el proceso que sigue un correo para pasar através del GatV2. Obviamente no es sencillo entender a la primera todo lo que hace pero a través de este gráfico (pinchar encima para zoom), de la explicación y de la documentación de la web del proyecto espero que podais comprender mejor el proceso.

Para ver las capturas de pantalla a las que se habla durante el podcast pasarós por la documentación del proyeco GatV2.

Finalmente el podcast:

El podcast dur alrededor de 1h, así pues Jorge me ha ayudado a hacer una tabla de contenidos del mismo así pues, podeis ir directamente al minuto que os interesa del podcast gracias a la siguiente información:

• Presentación: 0-1m44s
• Historia: 1m44s - 3m
• En que consiste: 3m - 8m15s
• Los componentes: 8m15s - 24m20s
• Como funciona: 24m20s - 42m49s
• WebUI del DSPAM: 42m49 - 55m55s
• Despedida y cierre: 55m55s - 56m56s

En los próximos dias publicaremos (Jorge y yo) el podcast dividido en pequeños MP3 en l página del proyecto GatV2 para mayor comodidad de los interesados en el proyecto.

Tal dia com avui a la bonica vila de Vinaròs (Castelló) vaig començar a escriure el meu blog, tranquils no tornaré a explicar la història que he explicat mil vegades sobre els inicis del mateix. Això si referenciaré el podcast 1×01 on explico els inicis del mateix per si algú encara no ho sap. Per altre banda, fa uns mesos no recordo qui hem va comentar la possibilitat de fer una gran festa per celebrar el 10è aniversari del blog i crec que agafaré la idea i des de ja començaré a pensar alguna forma ben original, i com sempre ben acompanyat dels mussols, per celebrar aquest fet tan insòlit. No tothom té la paciència d’aguantar tan de temps online

Bé doncs aprofito aquest post que no ve a dir res d’interessant més enllà de l’efemèride per posar-vos una mica al dia de la meva vida i del perquè aquest mes he postejat tan poc, a més d’engaxar unes quantes fotos que tenia perdudes pel mòbil i que sota el meu punt de vista són dignes de comentar.

El primer i principal motiu del meu silenci és el que ja explico al podcast 1×11 i a l’article del ‘desafio networking‘, o sigui, el problema amb el ditxós dispositiu que m’ha portat pel camí de l’amargura alguns mesos fins que la situació ha estat insostenible i m’he hagut de buscar la vida buscant una solució urgent abans el mal no fos major. La resta de motius són de caire més personal, així doncs aprofito per comentar-vos en primícia que a partir del dimarts que ve ja no viuré sol. O sigui, que obro un nou cercle en la meva vida acompanyat de l’Estefania. Com a soferts lectors del meu blog haureu d’aguantar els comentaris que sovint es derivaran de la meva vida personal al costat d’aquesta persona tan especial per mi, ho sento per vosaltres però me n’alegro molt per mi

Un cop fet aquest petit update a la meva vida i al meu silenci, una foto ben distesa d’una raqueta i una pilota de tenis gegants que hem vaig trobar pel carrer sortint d’un dinar familiar. Pels que no estigueu al corrent el tenis és un dels pocs hobbies no relacionats amb la tecnologia que hi ha a la meva vida i he de dir que malgrat sóc un paquet m’encanta jugar i ho passo genial.

Anant a temes més tècnics comentar que he hagut de canviar els dos estractors d’aire que tinc al petit-CPD de casa ja que s’havien fet malbé els motors que porten de tan donar voltes. N’he instal·lat un parell de nous i ara els he posat uns simples i ecònomics termostats de calefacció però en mode NC, d’aquesta manera malgrat són termostats de calefacció puc usar-los just amb la funció inversa. És a dir, mentre la temperatura ambient no baixa de una temperatura prefixada els estractors tenen corrent per funcionar, quan la temperatura baixa el termostat activa el relé i el que fa és tallar la corrent parant els motors. Comento això perquè fins ara jo només coneixia termostats que funcionaben en mode NO, o sigui, just alrevés del que he comentat. Però gràcies al Magí ara tinc aquest parell de termostats que funcionen la mar de bé, llàstima que hagin d’anar alimentats amb 2 piles AAA.

Comentar també que ahir vaig ser a l’oficina fins ben tard acompanyat de tres bons geeks: el Pof, l’Esteve i en Marc. Realment va ser una sessió molt constructiva sobre temes de cross-compiling per ARM9 una informació molt valuosa i que gràcies a l’Alfredo ben aviat serà una solució al problema que he tingut aquests mesos i que unes ratlles més amunt comentava.

Abans d’acabar no podia deixar de comentar que també vaig tenir l’oportunitat de jugar amb la HTC Diamondd que tan l’Esteve com en Pof ja tenen des d’ahir. Realment ha millorat molt aquesta HTC i ja es perfila com un ferma candidata a la meva pobre HTC Artemis que esta patint les més dures proves per ser el meu mòbil personal. No només vaig poder comprovar que el Diamond soluciona molt bé els problemes de velocitat que tenen els dispositius amb Windows Mobile sinó que l’accelerometre que incorpora és genial. En Pof també em va fer una demostració de tots els hacks que li ha fet la HTC Shift, a la que ja li ha canviat la ROM del Windows Mobile que incorpora i ha substituit el Windows Vista per una Ubuntu 8.04 que va com una seda, tota una delicia de dispositiu. La seva mida com a ultra-mobile PC esta molt bé,  i si no fos pels inconvenients de no fer de telèfon malgrat tenir funcions de HDSPA i similars es consolidaria com un ferm candidat a substituir l’HTC Kaiser que em té aborrit amb la seva lentitut. Si la comparem amb un mòbil és molt gran, però és realment útil per treballar i que en el futur algún germanet seu espero que acabi sent la meva eina de treball de capçalera si no fos pel tema de no poder fer de telèfon ja ho seria aquesta però hauré d’esperar.

Hablando sobre el problema del articulo sobre el desafio de networking. También aprovecho para enlazar una buena referencia sobre como comprender los problemas de secuencias TCP:

• TCP Analyze Sequence Numbers
• Silly Window Syndrome
• Window scale option

Espero haberme explicado bien y haber podido describir el problema algo mejor que en el articulo anterior, ya que no es sencillo describir un problema tan inusual.

Escenario

Se dispone de un dispositivo de hardware con un linux embedded al que no se puede acceder ya que el fabricante no lo facilita, se ha intentado acceder pero no hemos sido capaces de acceder ni con nuestros medios ni con los de una importante empresa de electrónica. Creemos que el kernel es un 2.4.X por lo que observamos. El dispositivo tiene una pantalla y su finlidad es mediante un protocolo propietario y un protocolo de transporte de ficheros (FTP) descargar una playlist para reproducir en la pantalla.

A través de red se conecta al servidor del fabricante de donde recoje una playlist y unos contenidos multimedia. Escencialmente usa los puertos:

• TCP/8889 (protocolo de control del fabricante) va en ‘plain text’ ya le hemos hecho la ingenieria inversa.

• FTP en modo pasivo

Con el servidor del fabricante descarga el 99% de la veces correctamente y sin problemas. En el fichero adjunto ‘korea-ok.cap’ si lo examinais podreis ver que todo se desarrolla perfectamente. La IP privada que podeis ver es del dispositivo en la LAN y a través de una LMDS se conecta a Korea a la IP: 210.114.220.180, si os fijais el fabricante usa como servidor FTP un ‘Serv-U’ para Windows.

Problema

Se ha implementado el protocolo propietario del fabricante con Python y funciona perfectamente, el problema es al hacer la descarga por FTP. El dispositivo se conecta a nuestro servidor FTP y de forma completamente aleatoria cierra la transmisión sin motivo aparente y se reinicia el dispositivo. Esto siempre pasa mientras se esta haciendo una conexión FTP-control (21/tcp) o FTP-data (puerto aleatorio del ftp pasivo/tcp).

En el fichero ‘cwd-fail.cap’ se puede ver uno de los típicos fallos que tiene el dispositivo al intentar descargar a un servidor FTP local (en este caso un proftpd en una Gentoo). Concrectamente al mandar el comando FTP ‘CWD’ el dispositivo decide cerrar la conexión y no seguir con la descarga. Después de varios intentos se reinicia. Para no perderos con los paquetes he dejado en la captura sólo el socket que tiene el problema.

Para no despistar recordar que esto no tiene porqué pasar en el canal de FTP-control puede pasar también en un FTP-data, puede pasar al 1% de descarga del fichero, al 30%, 50%, 98%… es completamente aleatorio.

Para tener más ejemplos de errores se adjunta el fichero ‘local-fail.cap’ donde se puede ver como se da un error igual al anterior pero ahora en el canal de datos de FTP. Concretamente podeis ver como se cierra el socket en el paquete 916 sin motivo apararente. Comentar que los errores de checksum de TCP no son relevantes ya que son debidos a que la tarjeta de red no estaba como sigue:

# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: off

En otras pruebas se han hecho con los parametros comentados y el error es el mismo. A pesar de que ya no aparecen las alertas por ‘checksum error’. Si se cree vital tener una captura sin los errores de checksum no hay problema en hacerla. Pero después de meses de pruebas esta claro que esto no es relevante.

Para demostrar que el comportamiento es aleatorio a continuación se adjunta un fichero ‘local-ok.cap’ con la captura de una sesión en el serividor FTP local que ha funcionado perfectamente. Se puede observar en el paquete: 18975 que se descarga bien el contenido de un fichero, concretamente un fichero .mpg, con este fichero finaliza todo el traspaso de datos correctamente.

Hardware y soft probado

Se han hecho infinidad de pruebas y de combinaciones:

5 servidores distintos:

• 1 debian con kernel 2.6.24.5-grsec-xxxx-grs-ipv4-64 en el proveedor ovh.es (100Mpbs simétricos sin restricciones), servidor FTP proftpd puerto 2090/tcp

• 1 debian con kernel 2.6.18-5-686 proveedor jazztel sin fw, ni restricción de ningún tipo 100Mbps simétricos contra internet y servidores FTP en el puerto 21 pure-ftpd y en el puerto 2090 proftpd.

• 1 ubuntu con kernel 2.6.24-16-server proveedor jazztel con fortinet como fw en modo transparente, proftpd en puerto 2090.

• 1 gentoo con kernel 2.6.25-gentoo-r5 en red local con proftpd en puerto 2090.

• 1 windows xp virtualizado con vmware workstation 6 sobre gentoo con un servidor FTP Serv-U, la tarjeta de red virtual en modo bridget con la del sistema operativo host.

el comportamiento es el mismo con todas la combinaciones

Intuición de solución

Jugando con los parámetros del kernel de TCP (/proc/sys/net/ipv4) se consiguen hacer cambios de comportamiento en el error. Por ejemplo, se han hecho pruebas con:

tcp_adv_win_sacle = 0,1,2 tcp_allowed_congestion_control = cubic, bic, reno, etc. tcp_base_mss = 512, 1024, 1500 tcp_dsack = 0,1 tcp_ecn = 0,1 tcp_fack = 0,1 tcp_sack = 0,1 tcp_syncookies = 0,1 tcp_timestamps = 0,1 tcp_workaround_signed_windows = 0,1 tcp_window_scaling = 0,1

infinidad de valores y combinaciones probadas en:

tcp_mem tcp_moderate_rcvbuf tcp_mtu_probing tcp_rmem tcp_tso_win_divisor tcp_wmem

También se han hecho pruebas limitando el ancho de banda, y con algunos otros parámetros de kernel que ahora no recuerdo. Se ha probado de opimitzar los servers para rendir al máximo, al mínimo, por defecto… etc.

Lo que se consigue con todo esto es conseguir que algunas veces se haga la descarga, pero no se consigue afianzar patrones de forma feaciente, es decir, a menudo se sigue cerrando la conexión TCP.

FAQ de obviedades

1. Es obvio que el firmware del dispositivo esta mal hecho, pero esto no se puede tocar.
2. El dispositivo se puede configurar via una compact flash, donde se guarda un fichero de configuración, un fichero binario compilado para ARM y el contenido multimedia que se va descargando.
3. Se ha intentado hablar mil veces con el fabricante pero es como hablar con una pared, a parte los técnicos no hablan inglés, sólo coreano. Increible, no?
4. El problema lo tiene el stack TCP del dispositivo o algún otro elemento similar. Este es el que cierra la conexión!!! no se puede mantener la conexión abierta des del servidor cuando el dispositivo la ha cerrado, lo único que se puede hacer es evitar que el cliente la cierre. El problema es como.
5. Si! el server del fabricante descarga bien via FTP en el 99% de los casos. Este es el gran probleam, parece tonta la pregunta pero me la han hecho como 20 veces, así que merecia estar aquí.

Ficheros

Los ficheros de los que se habla en este correo de pueden descargar de:

• http://oriolrius.cat/downloads/korea-ok.cap
• http://oriolrius.cat/downloads/cwd-fail.cap
• http://oriolrius.cat/downloads/local-fail.cap
• http://oriolrius.cat/downloads/local-ok.cap

Desafio

El entorno de laboratorio lo tengo montado en la oficina, esta abierta 24×7 para quedar conmigo para hacer pruebas in-situ. Obviamente responderé todo lo que sea online y orientaré con lo que pueda y más.

Este problema lo arrastro desde hace unos 4 meses y llevo casi 4 dias sin vida, sólo obsesionado buscando la solución pero no hay manera de ver la luz.

No dispongo de muchos recursos, debido a que ya he perdido muchísmo dinero buscando la solución durante todo este tiempo, pero bajo resultados se recompensará tanto como sea posible a la mente privilegiada que consiga dar con la solución.

Ya tengo solución

Después de darle vueltas al tema de momento no contaré las varias soluciones que a dia de hoy ya he enontrado al problemón. Así pue aprovecharé el problema para lanzar el podcast 1×11 describiendo con todo detalle el problema y dando algunas pistas de como llegar a la solución. Quizá a nadie le pique tanto la curiosidad como para seguir la solución con este detalle pero de esta forma mantengo un poco la intriga y si alguien realmente necesita saber la solución sin seguir el culebrón sólo tiene que mandarme un correo privado y se lo contaré. Para hacer boca deciros que la intuición de solución que tenia no era mala.

Per fi he trobat un plugin de highlighting que m'agrada, l'he trobat avui a través del blog del François Zaninotto. Llàstima que el plugin és força antic, no hi ha actualitzacions des de l'any 2006. Quan l'he instal·lat al Wordpress 2.5.1 m'ha donat un problema amb els permisos malgrat estava com a administrador. Així doncs en un moment li he fet un workaround, o sigui, com que el blog només l'uso jo ara mateix i no uso els usuaris m'he saltat la validació que fa de si tinc permisos. D'aquesta manera l'he pogut configurar com pertoca.

Per si algú vol fer el mateix, al fitxer syntax_hilite.php li he comentat les línies que podem veure a continuació:

PLAIN TEXT

268. //function for the Admin GUI
269. function igSynHilite_GUI() {
270.         global $user_level, $igWpVersion;
271.         get_currentuserinfo();
272.         //if user is not an admin equalling/above level 8, then don't give any GUI
273.         /*
274.         if ($user_level <8) {
275. ?><div class="wrap">
276.         <h2>iG:Syntax Hiliter(v<?php print(IG_VERSION); ?>) Configuration</h2>
277.         <br /><?php _e("<div style="color:#770000;">You are not a <strong>LEVEL 8</strong> or above USER &amp;
278. hence you cannot configure <strong>iG:Syntax Hiliter</strong>. If you are a <strong>LEVEL 8</strong> or above USER,
279. then please Logout &amp; Login again.</div>"); ?><br />
280. </div><?php
281.                 return;
282.         }
283.         */
284.         if(!empty($_POST['igsh_plainTxt'])) {

A més, els directoris que crea el fitxer .zip de la pàgina del plugin no són compatibles amb el WordPress 2.5.1. O sigui, que adjunto un .tar.gz amb els fitxers que he posat a BLOG_HOME/wp-content/plugins.

• Fitxer .tar.gz amb el plugin.
• Web del plugin.

Per cert, el look'&'feel del plugin és el que podeu veure en el codi que hi ha aquí dalt.

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:

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.

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

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

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:

La veritat és que he tingut molta sort

Perseguint el paradigme de la SSO dins de l'empesa avui intentaré explicar el següent esquema:

Disclaimer: si alguna cosa és incoherent o no funciona hem sap greu, he fet el que he pogut.

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

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.

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

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

• nova versió del devilspie
• Devilspie: obrir programes sempre a un workspace a les X's

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

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.

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.

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 1x07.

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:

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:

Els enllaços relacionats amb el podcast:

• CAS
• Kafelog

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

Aquest inici de setmana l'he passat moltes i moltes hores llegint documentació del Postfix per tal de solucionar un problema a un client que tenia una cua de correu inmensa i que no hi havia manera de servir perquè el servidor no donava coll. Doncs bé, degut a això m'he hagut de llegir molts documents i volia referenciar-los per no perdre'ls de vista ja que molts d'ells són interessentíssims. Realment cada dia que passa estic més convensut que Postfix és la millor opció com a MTA, diria que he passat moltes hores i molts anys provant sendmail, exim i qmail. Però l'experiència sempre m'ha dit que Postfix era el que em solucionava les problemàtiques més inversemblants i així ha estat aquest cop també.

• Postfix Bottleneck Analysis: aquest document és una introducció a l'eina qshape la qual ens permet veure quin és l'estat de les diferents cues que té postfix, no només om a totals sinó també destriat en dominis i amb una distribució temporal del temps que fa que el correu és a la cua. Realment molt i molt útil per saber on tenim realment acumulat el correu i quines mesures hem de prendre.
• postsuper - Postfix superintendent: aquesta comanda ens permet fer tasques de manteniment a les cues de postfix. Malgrat la comanda postqueue també permet fer tasques d'aquest tipus aquestes tasques són molt més limitades i orientades a usuaris que no pas a administradors del sistema. Perquè entengueu la potència del postsuper algunes de les seves funcions són: borrar missatges d'una cua concreta a través del seu ID, posar missatges en estat hold així aquests missatges no s'intenten enviar i els tenim retinguts fins que ens interessi, es poden re-encuar missatges que ja han estat encuats així podem tornar a aplicar-los filtres que s'havien aplicat malament, etc.
• Postfix built-in content inspection: bàsicament es tracta d'un conjunt d'ordres del fitxer main.cf que permeten filtrar els correus en funció d'expressions regulars aplicades a la capçalera del correu (header_checks), cos del correu (body_checks), adjunts mime (mime_header_checks) o caçalers dels correus adjunts als correus (nested_header_checks).
• Postfix After-Queue Content Filter: aquest document explica com filtrar els correus de formés molt més avançades, per exemple, s'explica la base que tenen de funcionar aplicacions com l'amavisd-new quan s'integren amb postfix. Al que refereixo és a tenir un postfix escoltant el port 25, quan entra un correu aquest s'envia a un port de localhost, allà es processa el correu i es generen d'altres correus amb informes d'spam si fa falta i després es re-injecta a un altre port localhost en aquest cas publicat pel postfix i finalment aquest correu es serveix. Doncs això que sembla senzill de montar té les seves pecualiritats que cal tenir en compte i en aquest document s'expliquen molt i molt bé, a més ens referencia a eines que comento a continuació per crear els nostres propis SMTP proxies on podem aplicar els filtres que ens interessin. Un exemple d'aplicació, a part dels típics filtres anti-spam, seria montar serveis de comandes via SMTP o sigui, que enviant un correu amb un format concret aquest fes una serie d'accions i el resultat tornés al seu origen via email. En la meva època del packet radio usabem això per fer smtp2ftp, per exemple.
• smtpprox - simple efficient SMTP proxy in perl: amb aquesta eina és trivial montar les nostres aplicacions a mida per fer filtres de correu tal com comentava en el punt anterior, a més des de la pròpia pàgina es referència a moltíssims patches per tal de fer funcions espcífiques amb aquesta eina. Alguns exemples: podem fer el mateix que fa amavisd-new però amb un codi molt més simple, podem fer de proxy d'autenticació per un SMTP que no té autenticació montada, tenir una llista de blacklist en MySQL, etc.Bàsicament l'SMTP proxy només fa de servidor SMTP per un costat i client SMTP per l'altre, al mig nosaltres podem processar el correu segons la seva informacó: capaçalera, adjuns, contingut del correu, etc.

Volia comentar de forma explícita una de les solucions ineressants que es presenta al primer document, el que parla sobre qshape. La idea és que a través d'aquesta utilitat podem trobar un domini sobrel el que s'hi encuen molts correus i per tant la cua de sortida de correus es veu perjudicada perquè aquest destí monopolitza gran part de la cua. Doncs bé, es tracta de construir una cua de sortida de correu només per aquest destí i fer que els correus que vagin cap allà es processin a part.

Per montar això cal:

• Modificar el fitxer master.cf i afegir un "smtp" transport per la destinació en concret. Això es faria així:
/etc/postfix/master.cf: # service type private unpriv chroot wakeup maxproc command fragile unix - - n - 20 smtp
• Fixeu-vos que fixem el número de processos a un màxim de 20, això vol dir que com a molt hi podran haver 20 instàncies simultanees del procés "smtp" per servir correus d'aquesta cua de sortida.
• Al main.cf configurem els límits de la cua que s'usarà pel transport "fragile" que hem configurat.
/etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport fragile_destination_concurrency_failed_cohort_limit = 100 fragile_destination_concurrency_limit = 20
• Ara toca crear el fitxer de transport on indicarem que els correus per aquest domini es serveixen per una cua particular, al costat del nom de la cua si es vol es pot indicar un host i un port cap a on es farà relay:
/etc/postfix/transport: example.com fragile:
• Recordeu que després de crear el fixer transport cal fer un postmap transport.
• Per veure quin és l'estat de la nova cua, només cal fer qshape fragile.

Espero que si no coneixieu postfix aquest petit post hagi servit per veure fins a quin punt és simple i dinàmic de configurar, no pretenia fer cap introducció només una pura referència de documentació que crec que a partir d'ara intentaré tenir aprop.

gSOAP, després de perdre-li la pista durant molt de temps aquesta llibreria de C i C++ crec que és la millor de codi obert i GPL que he trobat. Així doncs, ús la vull recomenar. El nom ve de "SOAP generator" i el va fer un professor, la versió 1.0 va sortir l'any 1999, per tant, podriem dir que l'eina esta més que provada si tenim en compte que va per la versió 2.7.1 que va sortir al gener del 2008.

Per entendre una mica que ofereix aquest toolkit esta molt bé fixar-se en aquest parell de gràfics que donen una visió de l'eina quan l'usem com a servidor SOAP:

i com a client SOAP:

Si haguessim de fer una llista de funcionalitats més detallada i tècnica em quedaria amb la que ofereix la pàgina de l'aplicació:

• All-in-one package. Independence from third-party tools and libraries ensures successful builds and reliable runtime execution.
• Open source with several license options.
• gSOAP supports both pure ANSI C application development and mixed C/C++ application development.
• gSOAP is the only toolkit that supports XML-to-C/C++ mapping for native C and C++ data types, which means that you can serialize your application data directly instead of having to use wrappers or SOAP/XML-specific data types. Any C or C++ data type can be serialized when it can be specified in a C/C++ header file (except unions). The toolkit automatically serializes pointer-based data structure graphs, including cyclic graphs and pointers to derived class instances to support polymorphism.
• The toolkit follows the WS-I Basic Profile 1.0a compliance recommendations. It warns about potential interoperability issues before building a new Web service application, so you don't have to go through another development cycle to make your services compliant. In addition, a report is available to check compliance.
• Complete support for industry-standard Web services protocols SOAP 1.1/1.2 (RPC and doc/lit), WSDL 1.1, and UDDI v2. Supports XML schema with primitive XSD types, simpleTypes, complexTypes, extension, restriction, elements, attributes, groups, attributeGroups, and arrays (including polymorphic data types and SOAP 1.1 encoding of multi-dimensional sparse arrays). Extensive interoperability testing with other SOAP toolkits resulted in a toolkit release that has proven to be stable, robust, and reliable.
• Supports SOAP-over-UDP, MIME (SwA), DIME (streaming), MTOM (streaming), HTTP1.0/1.1, IPv4, IPv6, RSS, XML-RPC, WS-Addressing, WS-Enumeration, and many other WS-* protocols.
• Supports WS-Security: authentication, tokens, digital signatures (XML encryption will be added in the near future).
• gSOAP is the only toolkit that implements streaming techniques for DIME and MTOM binary attachment transfers. It also supports SOAP with Attachements (SwA) Multipart/related MIME attachments.
• Fast and efficient because gSOAP uses streaming XML parsing techniques. Typical round-trip SOAP service invocation latencies are below 1ms. Shown to be the fastest SOAP1.1/1.2 compliant C/C++ implementation available (wrt. most common uses we tested).
• Very portable: Windows, Linux, Unix, Mac OS X, Solaris, HP-UX, AIX, FreeBSD, TRU64, Irix, QNX, VxWorks, MS-DOS. Also portable to handheld devices such as WinCE (Pocket PC), Palm OS, Symbian, and embedded Linux. Clients and server applications can be created that are under 100K with a total memory footprint under 150K.
• The gSOAP WSDL parser automates server and client application development. gSOAP also generates WSDL documens to publish your services.
• gSOAP Web Services and clients are just as easy to program as C# and JavaRMI, see How To section below.
• Serialization of native C and C++ data types allows you also to store and retrieve application data from XML repositories.
• Includes stand-alone HTTP/1.1 and HTTPS secure Web Server.
• Offers Apache_mod, IIS, WinInet, CGI, and FastCGI interfaces.
• Supports HTTP/1.1 POST/GET SOAP/XML messaging with compression, chunking, keep-alive, logging, and SSL encryption.
• The gSOAP compiler can be conveniently integrated in an IDE. For example, MSVC++ 6.0 project examples with gSOAP integrated in MSVC++ are included in the gSOAP distribution for Windows.
• Security: supports HTTPS and WS-Security. In addition, the source codes have been carefully written to avoid security holes such as buffer overruns. Also, gSOAP is open source which means that the gSOAP implementation can be verified.
• gSOAP's memory management uses garbage collection so (deserialized) data can be cleaned up without a hassle.
• Company backup for support, licensing, and consulting.
• Extensive documentation.