El podcast



Notes

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.
• Important recordar que:
• només el KDC pot llegir el TGT
• només el servei pot llegir el ST

Glossari d’acrònims

• KDC: Key Distribution Center
• AS: Authentication Service
• TGS: Ticket Granting Service
• SS: Service Server

Referències:

• Kerberos for the Busy Admin
• Kerberos authentication explained
• Understanding Kerberos Double Hop

Error coneguts

• Degut a un error el podcast 2×05 no exiteix. Sento l’error!

Resum de notes interessants que acabo de descobrir sobre: munin, crontab i locales. Tot plegat corrent amb Ubuntu.

• crontab, té diversos fitxers de configuració a /etc/cron.d la sintaxis d’aquests és la mateixa que /etc/crontab
• els fitxers que hi ha a /etc/cron.d sovint pertanyen a serveis que necessiten executar ordres periódicament
• al llençar munin des de dintre d’aquest directori es generaben correus d’error del crontab, queixant-se de problemes amb les locales
• dins el fitxer /etc/cron.d/munin podem declarar les locales i així no se’ns tornarà a donar el problema
• si volem sobrecarregar on s’han d’enviar els correu d’error de cron en un dels fitxers que hi ha /etc/cron.d podem declarar la variable MAILTO=user@domain.tld dins el propi fitxer

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.

Set _revs_limit of a particular database:

curl -X PUT -d "1500" http://localhost:5984/test/_revs_limit
#=> {"ok":true}

Read _revs_limit of a particular database:

curl -X GET http://localhost:5984/test/_revs_limit
#=> 1500

informació original de: accessing database specific options.

Agraiments: gràcies @marcos

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.

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 16×16pixels). 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.

Com deia a l’anterior article, el dilluns i dimarts vaig ser per la zona de Castelló per assistir amb el Benja a les jornades de Symfony organitzades per la Universitat de Jaume I de Castelló. Doncs bé, comentar que les jornades em van sorprendre molt positivament, realment hi havia gent amb força o fins hi tot molt nivell en la materia i això sempre és d’agraïr en aquest tipus d’events.

El programa de les xerrades era molt interessant i tret d’algunes xerrades puntuals totes eren del màxim interés per mi. Com molts esteu cansats de sentir jo no sóc programador, però en aquesta vida he picat força codi i concretament amb Symfony vaig començar-ho a fer en la versió 0.6.4, o sigui, molt abans que fos estable. Però de la mà de l’Oriol M. varem fer un projecte amb uns quants megues de codi font per fer recàrregues de mòbil a una cadena de botigues de fotografia, un dels codis dels que estic més orgullós.

Tornant a les jornades, volia destacar el meu ranking particular de ponents, es tracta d’un petit TOP 3 que des de la meva més extrema modèstia preten classificar en base a uns criteris totalment subjectius les persones que van saber transmetre els valors més importants que jo busco en una xerrada:

• Javier Eguíluz (Symfony 2) – a destacar la gran capacitat d’enfocar la conferència cap als items més importants a resaltar, sense oblidar els detalls rellevants en cada moment, tot això sense perdre un fil conductor clar en tota la xarrada. També s’ha de dir que el tema li donava molt de joc per fer embadalir a l’audiència; però va saber com treure-li el suc i tenir-nos a tots ben enganxats malgrat estar molt cansats després de dos dies de conferències sense parar, aquesta va ser l’última conferència.
• José Antonio Pío (Vistas y sfForm) – cal deixar-ho clar, una màquina té tota la pinta de ser un programador com la copa d’un pi i els típics defectes i virtuts de ser un professor (ho és?). Malgrat sembla que és molt bo i sap explicar-se la densitat del seu contingut i complexitat del mateix, feien complex seguir-lo tota l’estona ja que exigia molt a la concentració. Cosa gens senzilla en una marató de conferències com el que ens ocupa.
• Jordi Llonch (Plugins) – aquest representant de les nostres terres diria que també ha fet una molt bona feina explicant-nos la potència dels plug-ins de Symfony, potser a nivell personal no m’ha aportat tan com les altres dues xerrades però la qualitat de les transparències, l’oratòria i la bona organització dels continguts diria que l’han convertit en una referència de com fer les coses, sota el meu punt de vista, és clar.

Comentar que la resta de ponències també han estat molt bé, obviament algunes amb més qualitat que d’altres i amb temes que per mi tenien un major interés que altres. Però en conjunt dono una nota altíssima al contingut de les xerrades. Pel que fa a la organització i les instal·lacions un 9, més que res per donar-los marge a millorar. Impresionant el complexe universitari, res a envejar a d’altres que he vist.

Abans de tancar aquest article tan poc ortodoxe per descriure les jornades comentar en forma de punts algunes notes mentals que me n’he emportat:

• Hauria de posar-me amb Doctrine, però al coneixer Propel mai trobo el moment.
• Mirar-me a fons referències sobre integració continua amb PHP i eines de gestió de projectes
• Dona gust adonar-se que moltes pràctiques que has adoptat unilateralment també es comparteixen en la comunitat: temes d’sfForm, vistes, pugins, web escalables, cloud computing, etc.
• Pel que fa al tema de la web escalable, m’agradaria agafar els ’slides’ del ponent Asier Marqués i fer el meu propi screencast del tema, comparteixo quasi tot el que va dir a la conferència però em quedo amb les ganes d’aportar-hi el meu granet de sorra.
• Mirar-me el tema d’ESI que ja l’havia oblidat.
• MongoDB, com dic cada dia… una passada! i si a sobre es soporta a Doctrine això ja no té preu. Interessant el tema de Mondongo.
• i l’estrella de tot plegat!!!! Symofny2… estic impacient!!!!

UPDATE: presentacions de les jornades.

Dilluns i dimarts he estat per Vinaròs després de molt de temps de no estar per la zona. Desrpés de 3 anys d’esperar va ser el moment perquè m’entreguessin el video que em van fer per felicitar-me el 30è aniversari, o sigui, el que correspon a l’any 2007. Com que el video s’ho val el penjo a Youtube perquè el pogueu veure.

Part 1:

Part 2:

Per cert, aquesta part del video és només de la gent de Vinaròs, els altres videos que m’han comentat que m’havien fet altres persones encara no els he vist, cosa que ja té delicte

Feia massa temps que no jugava amb DBUS i les he passat una mica negres aquesta tarda intentant recordar com funcionava tot plegat. La qüestió de base és molt senzilla, com que el codi parla per si mateix. Simplement adjuntaré els dos codis.

Receptor de senyals DBUS, rep la senyal amb format ’string’ i la mostra:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
entra en un loop esperant senyals emeses a:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
quan es rep la senyal la mostrem
"""
import gobject
import dbus
import dbus.mainloop.glib

def mostra(m):
    print m

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_signal_receiver(
                 mostra,
                 path="/cat/oriolrius/prova/senyal",
                 dbus_interface="cat.oriolrius.prova",
                 signal_name = "estat"
                )
loop = gobject.MainLoop()
loop.run()

Emisor de senyals DBUS, envia una senyal de tipus ’string’ amb el contingut ‘hola’:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
Emet una senyal a dbus, al bus 'session' amb destí:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
"""
import gobject
import dbus
from dbus.service import signal,Object
import dbus.mainloop.glib

class EmetSenyal(Object):
    def __init__(self, conn, object_path='/'):
        Object.__init__(self, conn, object_path)

    @signal('cat.oriolrius.prova')
    def estat(self,m):
        global loop
        print("senyal emesa: %s" % m)
        gobject.timeout_add(2000, loop.quit)

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
loop = gobject.MainLoop()
bus = dbus.SessionBus()
o = EmetSenyal(bus,object_path='/cat/oriolrius/prova/senyal')
o.estat('hola')
loop.run()

Usant el ‘dbus-monitor’ es pot veure la traça del missatge:

signal sender=:1.634 -> dest=(null destination) serial=2 path=/cat/oriolrius/prova/senyal; interface=cat.oriolrius.prova; member=estat
   string "hola"

Un article ‘fast-n-dirty’ sobre potser la millor llibreria que he trobat per treballar amb templates i python: Cheetah. Es tracta de poder generar fitxers de texte de forma senzilla: fitxers de configuració, pàgines web, emails, etc. a partir de plantilles. Realment útil en molts entorns.

Les funcionalitats (copy-paste de la web):

• is supported by every major Python web framework.
• is fully documented and is supported by an active user community.
• can output/generate any text-based format.
• compiles templates into optimized, yet readable, Python code.
• blends the power and flexibility of Python with a simple template language that non-programmers can understand.
• gives template authors full access to any Python data structure, module, function, object, or method in their templates. Meanwhile, it provides a way for administrators to selectively restrict access to Python when needed.
• makes code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it. Cheetah templates can be subclasses of any Python class and vice-versa.
• provides a simple, yet powerful, caching mechanism that can dramatically improve the performance of a dynamic website.
• encourages clean separation of content, graphic design, and program code. This leads to highly modular, flexible, and reusable site architectures, shorter development time, and HTML and program code that is easier to understand and maintain. It is particularly well suited for team efforts.
• can be used to generate static html via its command-line tool.

a qui va orientat (copy-paste de la web):

• for programmers to create reusable components and functions that are accessible and understandable to designers.
• for designers to mark out placeholders for content and dynamic components in their templates.
• for designers to soft-code aspects of their design that are either repeated in several places or are subject to change.
• for designers to reuse and extend existing templates and thus minimize duplication of effort and code.
• and, of course, for content writers to use the templates that designers have created.

Aquest és el meu entorn de treball a dia d’avui, de fet, he volgut mostrar-lo perquè volia provar de fer una petita integració entre jquery-notes i wordpress. Ja que jo diria que malgrat aquesta funcionalitat és típica de flickr quan s’exporten imatges des d’aquest sistema al nostre blog les notes de la imatge es perden. Així doncs, he pensat que era una bona idea tenir el meu propi sistema de posar notes a les imatges.
La cosa ha estat senzilla només:

• he creat un directori al servidor del blog on he posat el jquery-notes, jquery-ui i jquery he posat els permisos corresponents als directoris.
• he modificat les headers del wordpress perquè incloguin el codi de jquery-notes, jquery-ui i jquery. A més del CSS propi del jquery-notes i un petit script per declarar el comportament de jquery sobre la classe “jquery-note”.
• després al crear un article amb la imatge i afegir-li la classe “jquery-note” automàticament s’afegeixen les notes que li he posat a la imatge.
• per posar-li notes a les imatges calen els paràmetres corresponents al script afegit a les headers del wordpress.

UPDATE: casualment avui al blog: freelance switch han pubilcat un article amb diversos workspaces.

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

• hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
• htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

• suportar autenticació Digest i NTLM.
• permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
• poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
• suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.