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.
Aquest mes he publicat articles una mica densos i pesats de seguir, així doncs per relaxar una mica l’ambient abans de seguir els que tinc preparats que no són menys durs ús deixo amb tres referències que trobo molt interessants:
Descripció: servei molt simple, que permet que la gent ens pregunti coses, nosaltres podem contestar i queda un registre de les preguntes i respostes. Això ens permet elaborar un FAQ sense gairebé cap esforç, a més de contestar les preguntes que realment interessen a la gent i no només les que se’ns acudeixen a nosaltres. Si per casualitat em voleu preguntar alguna cosa: http://www.formspring.me/oriolrius
Descripció: alguna vegada ja l’havia usat però mai me l’havia mirat amb calma, és una eina genial per quan has de prendre una decisió entre un grup de gent. La decisió pot ser sobre una pregnuta o sobre una data. A més també es poden organitzar votacions per un tema, o crear llistes perquè la gent s’afegeixi i els usuaris es pronunciïn sobre la qüestió. Alguns exemples: quina data quedem per sopar amb la gent de l’escola? quin disseny ús agrada més? qui vindrà a esquiar aquest cap de setmana?
Descripció: le descobert per casualitat llegint un blog, que ni recordo quin era. El servei permet tenir la nostre ‘wish list‘ publicada perquè tothom sapigue què desitgem tenir. Malgrat ser una versió molt inicial, la socialització de la idea la trobo molt interessant i útil. Realment una idea i implementació boníssimes. Si voleu veure la meva wish list: http://uwi.sh/oriolrius. Trànquils no aspiro a que ningú hem regali res, però m’agrada tenir referenciades les coses que m’agradaria comprar-me.
Degut a un requeriment que teniem a la feina he montat un entorn d’integració continua. En escència el que es busca és el següent:
Llençar de forma automàtica tests sobre els commits que es fan al codi (buildbot)
Tenir un repositori dels resultats dels tests fàcil de consultar (web) (buildbot)
Suportar tests sobre rendiment (profiling) automàtics (guppy-pe + resource)
Poder comprovar quina és l’evolució d’aquests tests de rendiment amb una eina visual (codespeed)
Per tal d’aconseguir aquests objectius s’ha usat:
buildbot: que permet automatitzar l’entorn de compilació i testeix dels commits que es van fent al repositori. (esta programat en python). Per entendre millor buildbot, ús recomano llegir l’apartat: system architecure del seu manual.
codespeed: és una eina feta amb python+django+mysql a través d’una interficie HTTP+JSON pot injectar informació a la BBDD i a través de la GUI ens mostra:
overview: a través d’una taula mostra les tendències dels resultats dels benchmark associats a un executable.
timeline: mostra en una gràfica l’evolució dels resultats arxivats sobre un benchmark concret fets sobre un host.
guppy-pe: ens permet extreure dades referents als recursos de sistema que esta consumint una part del codi: classe, funció, variable, etc.
resource: és un módul de python que permet saber (resource.getrusage(PID)) quins recursos esta consumint un PID en un moment donat.
Com que la documentació que he fet per la feina l’he hagut de filtrar per no revelar informació interna, la documentació que publico esta en format OpenOffice i PDF perquè sigui senzill per tothom llegir-la i modificar-la si vol.
A vegades cal fer algún invent extrany amb el python, com per exemple, el haver de tenir dues versions instal·lades. Sovint la nostre distribució ja portarà una versió del mateix i a més moltes eines de les distribucions acostumen a anar lligades a aquesta versió que millor no malmetre.
Cookbook d’ordres per instal·lar un python 2.6.5 a més del 2.4.3 que ja portava el host:
Porto mesos somiant amb fer la prova de concepte que explico en aquest article, intentaré descriure en que consisteix però ja aviso que la cosa és un pèl complicadilla.
Funcionalitats requerides:
long polling: l’objectiu és rebre els canvis d’una base de dades de couchdb en temps real sense haver d’anar preguntant si hi ha canvis, sinó que aquest s’envien cada vegada que es donen de forma automàtica.
A través de jQuery el que vull és actualitzar una pàgina web de forma asíncrona, de forma que els nous resultats que vagin entrant a la BBDD es vagin mostrant en temps real a la pantalla.
JSONP, és una tècnica que ens permet rebre la sortida JSON de CouchDB i després cridar una funció de callback de JavaScript. El problema és que la funció jQuery.getJSON() original de jQuery té algunes mancances que gràcies a el plugin jQuery-JSONP podem solucionar, aquestes són: (copy/paste de la web del plugin)
error recovery in case of network failure or ill-formed JSON responses,
precise control over callback naming and how it is transmitted in the URL,
multiple requests with the same callback name running concurrently,
two caching mechanisms (browser-based and page based),
the possibility to manually abort the request just like any other AJAX request,
a timeout mechanism.
CouchDB és una base de dades NoSQL basada en documents que és capaç d’emetre una senyal (trigger) cada vegada que el contingut d’una base de dades canvia. Per més informació sobre el tema es pot consultar a: CouchDB: The Definitive Guide al capítol Change Notifications.
Cross-domain: quan es llença una petició XmlHttpRequest (la base del AJAX) amb JavaScript tenim la limitació de només poder-ho fer sobre el domini que serveix la pàgina web, cap altre port ni subdomini. Obviament tampoc un altre host. Per saltar-se aquesta restricción és quan cal recorrer a JSONP.
La prova de concepte ha estat crear una base de dades anomenada: notifcations on es guarden documents que són notificacions a mostrar a la pàgina web.
El codi és força simple de seguir, primer de tot es carreguen les llibreries: jQuery 1.4.2 i jquery-jsonp 1.1.4, ambdues necessaries per cridar el métode $.jsonp que és el que realment farà la feina.
A continuació es declara la funció longpoll que té com a paràmetre el númeral que indica quin ha estat el últim canvi a la base de dades. Aquest s’utiliza per construir la petició que es fa a CouchDB:
incloent els documents que han canviat (include_docs=true)
tracta la petició com a long polling (feed=longpoll)
mostra els canvis des de la versió X (since=X)
quan enviis els canvis fes una crida a la funció de callback definida aquí (callback=?)
‘?’ és substituit per jquery-jsonp per la funció anomenada ‘C’, aquest nom es pot canviar usant paràmetres en la declaració de $.jsonp() que ve a continuació
Els missatges de l’estil ‘console.log()‘ són per tenir un seguiment del que va passant a la consola de javascript del navegador.
$.jsonp() té força paràmetres possibles definits a la API, però en aquesta prova de concepte només uso ‘url’, ‘success’ i ‘error’. El primer esta clar que és, els altres dos són les funcions a cridar quan l’acció va bé o malament respectivament. Dins de la funció posem el codi referent a les accions que volem fer, per exemple, actualitzar la pàgina actual. Com que això només és una prova de concepte el que faig és mostrar missatges per consola i llestos. La part més important és fixar-se que quan la cosa ha anat bé es fa una crida a ella mateix de forma que la cosa no acabi mai. De fet quan hi ha un error es podria també fer una crida a si mateix perquè no pares de provar de llençar la petició un i altre cop, però el que he fet per provar eś que es notifiqui a la consola de javascript i prou.
Fora de la funció longpoll el que es fa és una petició JSONP per saber quina és l’últim número de seqüència de la base de dades, paràmetre necessari per entrar per primera vegada a la funció recursiva de longpoll.
Conclusions
Pot semblar tot una mica enravassat però diria que he simplificat el problema moltíssim, ja que fins ara havia estat teoritzant moltíssim sobre el tema. Fins que ahir i abans d’ahir vaig haver de posar-me a provar-ho a la pràctica per saber exactament com es podia implementar. Sota el meu punt de vista ha quedat tot força net i entenedor.
Pels que sou programadors de webs habitualment haureu tingut necessitats semblants així doncs espero que ús pugui ser tan útil com a mi, de fet, fa unes setmanes que estic treballant amb Tiny Core Linux montant un Quiet PC sobre una DOM de 512MB per usar-la de sistema de monitorització de les meves xarxes i les d’alguns clients, espero que d’aquí uns mesos pugui donar-vos més informació del projecte.
Una altre d’aquelles eines que malgrat ser petitones i rares poden servir per fer mil i una coses. Per exemple, connectar a un servidor DNS a través d’un port TCP en una xarxa on el tràfic UDP estigui tancat.
UDPTunnel és una eina molt simple d’usar i la seva sintaxis és molt autoexplicativa:
és interessant fixar-se que el mateix executable pot ser usat com a servidor o com a client, així doncs ideal per construir els dos costats de l’enllaç de forma simple. A més si ho combinem amb httptunnel podem passar per sobre de proxies de forma senzilla.
-L: connecta per SSH a un HOST Un cop allà obre una connexió TCP a un altre HOST:PORT i obre un port TCP local que al connectar-hi ens envia al HOST:PORT anteriors, o sigui, portforwarding.
-L [bind_address:]port:host:hostport]
-W: connecta per SSH a un HOST un cop allà obre una connexió TCP a un altre HOST:PORT i ens retorna a la stdin/stdout el contingut d’aquest darrer enllaç TCP
-W host:hostport
-R publicar un port: connecta per SSH a un host i un cop allà publica un port TCP, quan un client es connecta a aquest port TCP accedeix per SSH a la màquina que ha llença l’enllaç SSH i obre un altre enllaç TCP a una altre IP:PORT.
-R[bind_address:]port:host:hostport
-D socks5: connecta per SSH a un HOST i després publica un port SOCKS5/TCP, és a dir, que podem connectar a aquest port local i sortir a internet a través de la IP del HOST on hem connectat per SSH
-D [bind_address:]port
-w tunel: connecta per SSH a un HOST i el socket que s’ha usat per fer l’enllaç SSH es connecta a dues interficies de tipus TUN, una a cada extrem del socket. Així doncs, si configurem les corresponents IPs a les interficies TUN tenim un tunel/VPN montada entre els extrems.
-w local_tun[:remote_tun]
HPN-SSH
La web de: HPN-SSH -> especialment interessant: Dynamic Windows and None Cipher
treballa amb mida de finestra dinàmica
treballa sense xifrat quan un enllaç no té terminal associat, sovint usat per pas de fitxers
Les proves:
Openssh 5.3p1 + hpn-13 (només el patch: Dynamic Windows and None Cipher)
després d’aplicar el patch: openssh5.3-dynwindow_noneswitch.diff.gz
modifiquem el fitxer: sshconnect2.c
<br><pre>linia: 366<br>- if (!tty_flag) /* no null on tty sessions */<br>+ if (1) /* no null on tty sessions */</pre><br>
així podem fer SSH sense xifrar només després d’haver fet el login.
exemple ampla de banada d’un SSH amb xifrat aes128-ctr, usant finestra dinàmica:
Finalment l’última entrega de la trilogia de podcasts sobre SOCKS. Com indica el títol i podeu veure amb els links aquest parla d’eines per montar servidors SOCKS i wrappers per montar clients SOCKS5.
El podcast:
[display_podcast]
Referències:
Apunts per fer el podcast: fitxer .txt amb les meves notes per fer el podcast, mig en català i anglès.
La idea es força simple es tracta de transportar un fluxe TCP sobre d’una connexió HTTP convencional, fiexeu-vos que en aquest cas no estem parlant de proxies ni similars. Sinó de paquets TCP+HTTP que en la part de dades del HTTP tornen a implementar TCP, si fessim un petit esquema seria algo així:
+----+----+------+------+-----+------+
|... | IP | TCP | HTTP | TCP | DATA |
+----+----+------+------+-----+------+
Si realment teniu aquest interés montar reDuh és realment senzill, de fet, suporta servidors amb JSP, PHP i ASP. En escència l’únic que fa és usar aquests protocols per re-obrir una connexió TCP. Així doncs, al servidor on montem aquesta eina hem de tenir certs privilegis per poder obrir sockets des d’un script.
L’eina no és massa recomanable si pensem tenir fluxes de dades molt intensos, per exemple, senssions VNC. Però funciona prou bé si el que volem és transportar una sessió SSH o similar.
