Per fi tenim feta la web del viatge a Costa Rica, aquest cop ha costat força però ja veureu que hi ha molta lletra i això no és fàcil de gestionar. A més d’un munt de fotografies recopilades de l’àlbum de fotos.
Quan ens roben el portàtil l’únic que ens queda fer és resar perquè siguem realistes, és molt poc provable que la policia el trobi. Així doncs, el que preten fer prey és enviar-nos tota la informació possible del portàtil després de que ens l’hagin robat.
El seu funcionament és força simple, però al mateix temps s’ha de dir que la idea sembla força eficient. En la versió per linux es tracta d’un script fet amb perl que es col·loca al crontab, de forma que cada x’s minuts es connecta a una URL del servidor de prey o del nostre propi servidor. Aquest URL sovint respon dient que tot va bé, és a dir, que el portàtil no ha estat marcat com a robat. En cas contrari, el servidor respon via HTTP dient que el dispositiu ha estat robat. En aquest moment és quan l’script es posa a treballar i es posa a recollir tot tipus d’informació per reportar-la a la pàgina web:
geolocalització per GPS o Wifi, si no disposem de GPS. He provat la localització per wifi i va força bé.
fa fotos amb la webcam del portàtil i captures de pantalla
reporta tota la informació que pot sobre processos que hi ha corrent al sistema, rutes, informació de les wifis veïnes, etc.
també podem fer sonar alarmes, borrar informació remotament, que ens enviï alguns arxius abans de ser borrats,etc.
a més els reports que es van reben queden arxivats en una interficie força amigable i molt senzilla d’usar
a més el software d’auto-actualitza
La compte gratuïta que ofereix la pàgina web permet tracejar fins a 3 dispositius, obviament si usem el nostre propi servidor HTTP podrem tracejar tots els dispositius que volem. Si volem usar més dispositius haurem d’adquirir una compte professional que tampoc sembla massa cara: per exemple, la més econòmica és la de 12€/mes que permet controlar fins a 10 dispositius amb un màxim de 25 informes per cada dispositiu.
Jo he provat la versió de Windows i la de Linux i ambdues m’han funcionat força bé a la primera, però pel que posa a la web també tenen la versió de Mac i la d’Android. Aquest última diria que és molt nova. Malgrat això en els meus dos Androids no uso prey sinó que uso WaveSecure. Pensat especialment per a dispostius mòbils, ja que tenen versions per: Blackberry, Symbian, Windows phone, Java i Android, és clar.
L’autenticació d’Apache coneguda com a AuthBasic malgrat la seva inseguretat és una de les més usades, ja que ens permet de forma senzilla i ràpida protegir un directori o simplement un fitxer. La protecció d’aquest tipus d’autenticació és molt relativa perquè el password viatge en clar a través de la xarxa, a més, al viatjar a les capçaleres HTTP o fins hi tot en la propia URL de la pàgina pot arribar a ser indexat per un navegador.
Ara el que toca és afegir a l’Apache aquest tipus d’autenticació de forma que podem donar les credencials d’accés a un directori/fitxer a algú però aquestes caducaran al cap del temps (uns 3 minuts) i els buscadors o d’altres agents amb més mala idea no podran accedir al recurs passat aquest temps. Com sempre la idea és la d’aprofitar-se del PAM/OTP.
En primera instància per aconseguir això ho he intentat amb el mòdul libapache2-mod-auth-pam però no n’he tret l’entrellat i he estat incapaç de completar la configuració. Així doncs, el que he fet és provar amb el mòdul libapache2-mod-authnz-external ambdós disponibles en l’Ubuntu 8.04 (Hardy). Aquest segon mòdul l’he combinat amb el checkpassword-pam.
Així doncs, la idea és ben senzilla configurem l’Apache perquè usi el libapache2-mod-authnz-external, en escència el que fa aquest mòdul és recolzar-se en agents externs per fer l’autenticació. Aquest agent extern és el checkpassword-pam que comentava i que com diu el seu nom el que fa és validar el password contra PAM, així doncs, malgrat no és una solució massa eficient a nivell de recursos ja que ha de carregar un segon programa per validar cada usuari considero que és una solució suficienment bona pel meu cas.
Si us hi fixeu aquest fitxer és igual al que vaig usar per fer l’autenticació en l’article de PHP i PAM/OTP.
Ara anem a un dels fitxers de configuració d’Apache per un virtualhost i afegim el següent codi per protegir un directori servit per aquest virtualhost:
<Directory/var/www/virtualhost/directori_a_protegir>AuthTypeBasicAuthName"Restricted area for My Server"requireusernom_usuariAuthBasicProviderexternalAuthExternalautenticador</Directory>AddExternalAuthautenticador"/opt/checkpassword-pam/checkpassword-pam -H --noenv -s php -- /bin/true"SetExternalAuthMethodautenticadorcheckpassword
Coses importants a destacar en aquest configuració, fixeu-vos que em cal afegir ‘require user nom_usuari’, això és perquè no disposo de cap fitxer d’usuaris on Apache pugui validar quins són els meus usuaris vàlids i la directiva ‘require valid-users’ no funcionaria, així doncs, hem d’especificar quins usuaris podran fer login a través d’aquesta comanda, o bé, afegir una altre directiva que li permiti a Apache trobar un llistat d’usuaris en algún lloc.
Un altre detall important són els paràmetres que he d’usar al checkpasswords-pam perquè aquest funcioni bé:
-H no intenta fer un ‘chdir-home’ ja que potser l’usuari no disposa d’aquest ‘home directory’.
–noenv el checkpassword-pam busca certes variables d’entorn per funcionar, amb aquest paràmetre no les busca i agafa el que li cal del stdin.
-s apache2 especifica el nom del servei que buscarà dins de /etc/pam.d/apache2
— /bin/true simplement serveix perquè el checkpassword-pam no faci res després de validar un usuari, ja que podriem executar algún programa si volguessim després de fer la validació.
Tot ordenant .txt he trobat quatre notes que havia fet fa temps extretes de l’experiència i de documents de relacionats amb digital signage que havia anat llegint, per tal de no perdre-les les anoto a continuació:
Entorn:
Audiència: estàtica o en moviment?
Predisposició a aturar-se de l’audiència? (area de pas, passeig, etc)
Cal posar audio? o no dona cap valor afegit.
Audiència:
Qui mirarà el contingut?
És una necessitat comuna?
S’esta buscant algún tipus d’interactivitat, o simplement captació pel missatge emès?
Què trobarà interessant l’audiència o com a míninm digne de mirar?
Cuantes vegades un individu veurà el missatge?
Perquè l’audiència li hauria de donar un segon cop d’ull?
El missatge:
Venem producte, o un nou estil de vida?
Creem una atmosfera, o fem marca?
Cal enumerar els beneficis o podem deixar que les imatges parlin soles?
Estem informant, instruint, venent o que…?
És un missatge aïllat o part d’una campanya que usa altres tipus de media?
Podrien millorar l’experiència enllaços a altres sistemes?
Tips and tricks:
Intentar crear un sentit de propietat comuna del projecte entre tots els players del negoci
Audiència en moviment, missatge estàtic. Audiència estàtica, missatge en moviment.
Monitorització constant de les reaccions de l’audiència.
S’ha de considerar que l’audiència només donarà una ullada a la pantalla.
Buscar consistència en els estils i colors del missatge.
Les tipografies i mides de la lletra han de ser prou clares per llegir-se a certa distància.
No cal esperar que la publicitat millori de forma espectacular les ventes d’un producte. Només és un complement que ajuda a donar a coneixer el producte.
Cal assegurar-se que el contingut té una part d’entreteniment i una part d’informació.
Cal pensar que al montar una pantalla on la gent esta en moviment aquesta ha d’estar en un punt on es pugui seguir movent-se i llegint el missatge.
Compte amb l’audio, sovint no és una bona idea.
És important tenir el contingut ben actualitzat i no mostrar informacions obsoletes, això fa perdre credibilitat al medi.
És important saber l’experiència que té l’audiència sobre el medi.
Al sentir parlar de formats de video, codecs, DivX, MPEG4, etc. sovint surten a la conversa termes com ara els I-frame, P-frame i B-frame. Cansat de que em soni a xinès he decidit fer-me un petit resum de què és tot plegat, sempre des del punt de vista d’algú que en sap ben poc d’aquests temes.
Podem dividir els ‘frames’ de video en 3 tipus:
I-Frame: també anomenat keyframe. No té cap frame de referència i pot ser decodificat per si mateix. Podem pensar que és algo semblant a un JPEG.
P-Frame: El contingut del mateix és dedueix d’un frame previ de tipus I o P, és impossible decodificar-lo sense mirar aquesta referència.
B-Frame: per decodificar-los cal mirar els frames anteriors i següents de tipus I i P.
Aquest últim tipus de frames són interessant per dues raons:
Són fàcils de predir
No impacten en la qualitat dels frames següents
Degut a que els B-frames depenen del passat i el futur, llavors el decodificador li calen frames I-P del passat i el futur per poder decodificar el frame B. Això ens porta als conceptes PTS/DTS.
PTS Presentation Time Stamp: també podem entendre’l com una forma de saber el número de frame, ordre en que es poden veure els frames decodificats.
DTS Decoder Time Stamp: ordre en que es processen els frames per ser decodificats.
Un exemple, per entendre-ho millor:
Suposem que això és un petit video: I-0 B-1 B-2 P-3
L’ordre DTS seria: I-0 P-3 B-1 B-2
Per tal de simplificar les coses el video s’enmagatzema en l’ordre DTS.
El problema
Arribat en aquest punt podeu imaginar-vos el problema que suposa mostrar un video en ordre, ja que el decodificador ha d’anar composant els frames per mostrar-los am és d’inserir frames on no n’hi han per mostrar el frame que toca.
DIVX (i Xvid)
Aquests famosos codecs per tal de d’atacar aquest problema fan servir un petit truc. La idea seria usar una variant dels frames PB i empaqueten diversos frames en un. Això fa que les aplicacions es pensin que només hi ha un frame i el codec oculta la resta.
Per exemple, si tenim un fitxer que te empaquetat el següent:
In (0312) ---...
el codec haurà de treure això:
Out0123...
El codec posa frames de tipus ‘null’ en el lloc on hi haurien d’haver els frames que no té pel fet de tenir-los empaquetats en un frame. Els codecs ja saben que quan reben un frame null han de descartar-los.
Des del punt de vista del codificador, és important fixar-nos que no s’introdueix un delay corresponent als frames nulls. En un fitxer AVI no hi ha cap relació entre el PTS/DTS guardada enlloc per tal d’informar al decoder quan aquest ha de reproduir.
Dijous passat aterrarem a Barcelona després del viatge que hem fet per Costa Rica, així doncs, malgrat ja fa uns dies que treballo he pogut pujar les fotografies del viatge a l’àlbum de fotografies. Com sempre el teniu a:
Les fotografies estan protegies amb password que com sempre els que em coneixeu el sabreu en un moment i els que no, envieu-me un email i ús l’enviaré. Aprofito per recordar que el tinc protegit perquè hi ha algunes fotos que a vegades no és bo que estiguin a l’abast de tothom.
Pel que fa a la web del viatge malgrat ja l’he començat a fer encara li queda força feina per estar acabada, tan aviat com ho tingui ja avisaré. Pels que no voleu entrar a l’àlbum de fotografies i mentre la web no esta acabada podeu anar fent boca amb aquestes quatre notes i imatges que ús deixo a continuació.
Platja privada del parc natural de Manuel Antonio:
“Conopy Extrem” a Monteverde:
Volcà Arenal, foto feta des de l’hotel “Linda Vista del Norte”:
Termes “Baldi” a La Fortuna (Arenal) on ens trobarem amb el Joan i la Patri: (esq-drt: Glòria, Torsten, Patri, Joan, Estefania i Oriol)
Posta de sol des del jardí de l’hotel Miss Junie a Tortuguero:
Caimà dels canals de Tortuguero:
Tour en canoa pels canals de Tortuguero amb el senyor Billy, un caçador de jaguars de Nicaragua que amb 84 anys tenia més força per remar que tots quatre junts:
Piscines naturals a les platges de Puerto Viejo, on visitarem al Josep Maria i la Carme:
Esmorzant a la ‘terrassa’ de l’apartament del Josep Maria i la Carme a Puerto Viejo:
Cocodril d’uns 2’5m que teniem a tocar al dinar del tour del cacao que ens va fer el Sr.Felipe prop de Hone Creek (zona sur Carib de Costa Rica):
Dinar al tour del cacao amb la Glòria i el Torsten els nostres companys de viatge:
Doncs si tal dia com avui vaig començar a escriure el blog, així doncs, faré una cosa que faig poc sovint i és autofelicitar-me per la constància, si ja sé que no podriem dir que últimament escrigui cada dia però crec que aguantar 10 anys amb certa constància és algo, no?
Bé doncs sempre passa en aquestes ocasions farem una petita llista de bons proposits per aquesta nova etapa de maduresa del blog:
continuar-lo usant com a bloc de notes tècnic
continuar usant-lo per referenciar events de caire més personal o no-professional
començar de forma oficial el ‘screencast‘ sobre el que ja he fet les primeres proves
agrupar aquesta part més multimedia ‘podcast‘ i ‘screencast‘ en una pestanya dedicada per accedir-hi ràpidament
redissenyar-lo completament però aquest cop si tot va bé, fer-ho a través d’una empresa que li doni un bon acabat
re-editar els posts antics perquè adquireixin formats més unificats, suport de tags, centrat i mida d’imtges, repassar enllaços trencats, etc.
més protagonisme als posts antics (this week last years)
integrar uwish
integrar lifestream a la pantalla principal en forma d’stick item a més de sindicar més feeds en aquesta llista: twitter, my shared items del google reader, etc.
seguir fent del blog algo que m’enganxa i que trobo a faltar quan no faig
També vull fer un comentari sobre la línia que té el blog aquests últims anys, en que el nombre de posts ha baixat força però la qualitat i densitat tècnica han augmentat molt. Malgrat això em fa baixar en nombre de lectors és més fidel a la meva persona i el converteix en una eina encara més útil per mi.
Finalment hi ha una llista d’articles pendents de publicar que conte coses com:
iPython
ESI – Edge Side Includes
LVM
SSTP
SVG amb long polling
array vs CouchDB
scribe
DNSCurve
Google Talk chatback badge
MyProxy – credential management service
SSL i TLS a fons
Desktop notify system with python
oProfile
etc
Però sobretot el que estic impassient per començar a document en forma de post, d’screencast i del que faci falta és el tema del AMQP, porto mesos treballant amb un borrador que cada cop és més extens i que de ben segur hauré de dividir en diversos trossos perquè les seves dimensions ja fan por, però realment estic disfrutant com mai amb aquest tema.
Doncs res, agraïr-vos també a tots els que em llegiu que ho continueu fent malgrat el pesat que em faig en alguns moments. Demanar-vos que no tingueu por en presentar-vos perquè a les jornades tècniques on em deixo caure acostumo a trobar gent que ha passat pel meu blog alguna vegada i això sempre fa moltíssima il·lusió.
Bé doncs gràcies a tots i ens veiem quan torni de Costa Rica, on estic passant les meves vacances en aquests moments.
Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:
autenticació mutua
temps de connexió ràpids (session tickets)
delegació (autenticació recursiva entre serveis)
Esquemes
Simplifiació del funcionament
Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:
AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
KRB_AS_REP
Client principal name.
Timestamp.
Kerberos target principle name (realm).
Requested lifetime.
KRB_AS_REP
La primera part va xifrada usant la clau d’usuari, conté:
User-TGS key (generated by the KDC).
Kerberos target principle name (realm).
Ticket lifetime.
La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
Client principal name.
Ticket lifetime.
KDC timestamp.
User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
Client IP address (taken from the initial KRB_AS_REQ).
TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
KRB_TGS_REQ
Service principal name.
Requested lifetime.
TGT (still encrypted with the TGS key).
Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
KRB_TGS_REP
La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
Service principal name.
Ticket lifetime.
User service key (encrypted with a user-TGS session key, generated by the KDC).
Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
User service key (encrypted with a user-TGS session key, generated by the KDC).
Client principal name.
Ticket lifetime.
KDC timestamp.
Client IP address.
Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
KRB_AP_REQ
ST xifrat amb la clau TGS del servei
Authenticator – encrypted with the user service key
KRB_AP_REP
Característiques
‘Realm‘ es defineix com un domini d’aministració
Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
La “user key” es genera a partir del “logon password”
La “host key” es genera quan el “host” s’uneix al ‘Realm’
Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
Per defecte i fins que no es fa una compactació de la base de dades CouchDB permet fins a 1000 revisions d’un document, cosa que sovint no acostuma a ser necessari. Així doncs, si volem canviar aquesta paràmetre finalment a la versió 0.11 ja el podem canviar.
CIF (Common Intermediate Format), també conegut com FCIF (Full Common Intermediate Format), és un format usat per estandaritzar les resolucions horitzontals i verticals en pixels de les senyals de video (seqüències YCbCr), aquest nomenclatura es va proposar a l’estàndard H.261.
CIF es va dissenyar per convertir de forma senzilla els estàndards PAL o NTSC. CIF defineix una seqüència de video amb una resolució de 352×288 com PAL, amb un framerate de 30000/1001 (uns 29.97fps) frames com NTSC, amb un codi de color YCbCr 4:2:0.
SQCIF
128 × 96
SubQuarterCIF (subQCIF)
QCIF
176×144 in PAL
176×120 in NTSC
Quarter CIF, la meitat de la resolució H i V,
o sigui, 1/4 de la imatge original
Double CIF, té un aspect ratio molt proper al 4:3,
millor quailtat que 2CIF i CIF amb el mateix bitrate
4CIF/4SIF(625)
704×576 in PAL
704×480 in NTSC
16CIF
1408 × 1152
Les resolucions xCIF no són quadrades, tenen un ratio de ~1.222:1. O sigui, que una televisió analògica té un ratió de 1.2:1 segons defineix l’estàndard de sistemes de 525 linies (CCIR 601). En les pantalles d’ordinador o de televisió digital es treballa amb blocs de pixels quadrats, o sigui, que les trames xCIF ha de ser re-escalades horitzontalment un ~109% per aconseguir un ratio de 4:3, o sigui, el que equivaldria a 384×288 pixels quadrats.
Les mides d’imatges CIF han estat especialment escollides per ser multiples del que s’anomenen macroblocs (corresponent a 16x16pixels). Per exemple, una imatge CIF de mida 352×288 correspon a 22×18 macroblocs.
Informació extreta de la Wikipedia i de diversos forums dispersos per internet.