Author: Oriol Rius

Gentoo: portage 2.1 funció elog

2006/08/24 No Comments

Reading time: 4 – 6 minutes

La versió 2.1 del portage de Gentoo que va entrar en mode estable fa uns mesos realment és un salt important en la gestió de paquets d’aquesta metadistribució. Així que si encara no us heu mirat les millores que incorpora us ho recomano moltíssim. La gent de linux.com han escrit un article que parla del ‘secrets’ d’aquesta nova versió del portage (local). De fet, la majora ja en sóc un asidu usuari, per exemple l’esearch o l’eix. Però hi ha una novetat que m’ha agradat moltíssim i que no coneixia. La podeu també trobada en l’article anterior. Però us en faré 5 centims.

Bàsciament es tracta de dues variables que es defineixen a make.conf. Amb aquestes variables podem definir quin és nivell de log que ens ha de mostrar la comanda emerge mentre compila un paquet i a més podem definir si volem que la sortida de missatges es guardi en un fitxer a /var/log/elog així quan compilem més d’un paquet de forma consecutiva podem veure si aquest ha tingut algún problema. De fet, on jo li veig més utilitat és en el típic paquet que dona problemes després d’instal·lar-se correctament. Doncs bé, podem comprobar si ha fallat alguna de les seves parts al compilar.

Les variables que s’han de definir al make.conf:

# This sets what to log
PORTAGE_ELOG_CLASSES="warn error log"
# And this is how to do it
PORTAGE_ELOG_SYSTEM="save"

winmail.dat – aprofundint una mica en el tema

2006/08/22 No Comments

Reading time: 2 – 2 minutes

Quan enviem un email amb el MS Exchange com a proveedor de correu d’internet si aquest email conté un missatge amb format de texte enriquit (rich-text message) llavors el missatge estarà enmarcat entre una capçalera de descripció MIME per tal de poder informar al MUA destí quin format té la informació que conté el cos del missatge. Però si no li diem res al client de correu de MS aquest enviarà l’email dintre d’un fitxer adjunt anomenat winmail.dat. Aquest fitxer es codificarà en format uuencoded. (informació fonamentada en XCLN: Sending Messages In Rich-Text Format)

Obviament el que ens interessa als no-usuaris d’aquests serveis de MS és que això s’envii d’una forma molt més estàndard. Per tal de poder informar als usuaris de MS de com han de configurar el seu MUA es pot consultar l’article How to Prevent the Winmail.dat File from Being Sent to Internet Users.

Article 138053 de suport MS:

This article describes how either an Exchange Server administrator or end users can prevent the Winmail.dat attachment from being sent to Internet users when using the Microsoft Exchange Internet Mail Connector (IMC).

En poques paraules el que ve a dir l’article és que s’ha de buscar on posa Always Send To This Recipient In Microsoft Exchange Rich-Text Format en el menú de configuració del MS Exchange (en cas de que siguem admins), o del Outlook (en cas de ser users) i desmarcar la checkbox.

mini-cookbook: ssh passwordless

2006/08/22 No Comments

Reading time: < 1 minute

Sense ajudes, descripcions ni notes… només per refrescar el tema amb 1s:

client ssh:

ssh-keygen -t dsa
id_dsa.pub el copiem al servidor

servidor ssh:

afegim contingut id_dsa.pub al ~/.ssh/authorized_keys
borrem id_dsa.pub

Vaig a parlar malament de bloglines.com

2006/08/21 No Comments

Reading time: 2 – 4 minutes

Sóc un gran usuari del servei de lectura de feeds que presta de forma gratuita bloglines. Tot i les seves deficiències en algunes tonteries és el sistema que més s’ajusta a les meves necessitats per tal de llegir els ja més de 180 blogs (feeds en rss) cada dia. Sempre he defensat el servei perquè realment crec en l’empresa. Com dic, sempre salvant els inconvenints propis d’una aplicació ASP i sense possibilitat de poder-la tenir instal·lada en el meu servidor.

Però el problema me’l vaig trobar dissabte quan em vaig posar a llegir el meu blog d’enllaços que vaig guardant a diari (servei gratuit de bloglines també) per tal de consultar a posteriori en més temps les noticies/enllaços que hi he guardat. El problema esta en que vaig decidir posar-me al dia des del gener d’aquest any fins a dia d’avui repassant tots els enllaços que hi tinc. Amb l’objectiu d’organitzar-me millor la informació (escriure nous posts, posar nous enllaços al sitebar, etc). Així realment li extrec al màxim possible al temps que hi dedico cada dia repassar i filtrar tanta informació.

Doncs bé, quan vaig arribar al març (anava enrera, des d’avui fins a gener) moltíssims enllaços s’havien perdut. I no parlo d’enllaços cap a internet, sinó enllaços dintre del propi servei de bloglines. O sigui, que els enllaços de moltes notícies antigues dintre del servidor de bloglines havien deixat d’existir no poden així llegir la notícies que vaig referenciar des del seu propi servei. Per mi això és molt trist, ja que és normal que els enllaços que fem cap a webs de tercers deixin de funcionar (no podem garantir al 100% la integritat referencial en enllaços externs). Però cap al nostre propi site jo crec que és vital intentar fer-ho i més una empresa tan important com aquesta.

Així doncs, formalment ja puc dir que bloglines m’ha fet perdre moltíssima informació que tenia guardada en el seu servidor, entre els mes de gener i març. De moment no he decidit prendre cap més mesura que la de usar una altre política a l’hora d’escollir que guardo al blog d’enllaços que hi tinc. Però esta clar que no hi podeu confiar com ho he fet jo fins ara.

Qt SOAP – provant els webservices

2006/08/19 No Comments

Reading time: 1 – 2 minutes

A l’article Client SOAP genèric ja vaig parlar d’una pàgina web que a partir de la URL del WSDL ja podiem atacar el webservice d’una forma molt senzilla. El problema que té això és que quan estem dintre de la xarxa de l’empresa potser no tenim el webservice publicat a l’exterior d’internet. Doncs amb aquesta simple eina programada en Qt podem tenir una eina similar a la oferida per la pàgina web.

De moment encara no l’he provada però de ben segur ho hauré de fer aviat, així doncs si hi trobo algún inconvenient o avantatge descatbles, amplicaré aquest article sobre el Qt SOAP. Una cosa que ja he vist i que té molt bona pinta és que ens permet veure les HTTP headers de la petició i la respostes SOAP. A més podem definir el content-type de la petició cosa realment útil.

Whatisthatfile.com – què és aquest fitxer?

2006/08/19 No Comments

Reading time: < 1 minute

Sovint en trobem fitxers, sobretot en windows que no sabem ni d’on han sortit i que no ens atrevim a borrar per si les mosques, així que si voleu saber a quí preguntar: “què és aquest fitxer?” cada vegada que ús passi això whatisthatfile.com.

Generant RSS de les revisions de Subversion

2006/08/18 No Comments

Reading time: 2 – 2 minutes

Quan treballes en un projecte on hi ha més d’una persona treballant contra un repositori de codi és molt bona idea poder-se sindicar via RSS a les noves revisions que es van publicant del codi i als comentaris associats a aquestes revisions. De fet, aconseguir això amb subversion no és gens difícil. Jo fins ara ho he fet amb el WebSVN (port del ViewCVS. A més gràcies al trac també podem obtenir aquests RSS i moltes més funcionalitats. Però tot això ja us ho he explicat. En alguns casos però ens pot interessar publicar aquests RSS sense haver de tenir programes orientats a altres funcionalitats sinó únicament aprofitar les extencions WebDAV/DAV_SVN per publicar els RSS. Això és el que ens expliquen a l’article HOWTO: Adding an RSS feed to a Subversion Server (local).

De fet, el que planteja aquest article és força senzill. Simplement usa un generador d’RSS a partir de les revisions de l’SVN, l’script esta fet en python i després li diem al subversion que després de cada commit que es fassi al repositori es genir un nou fitxer RSS. Així doncs el tema no té cap misteri però va bé tenir-ho en un howto per si mai fa falta.

Phalanger: the PHP Language Compiler for .NET Framework

2006/08/18 No Comments

Reading time: 2 – 2 minutes

Ja coneixia aquesta solució però mai recordava el nom que tenia, de fet, encara no l’he pogut provar mai però pel que he vist a la web en principi qualsevol dels nostres codis fets en PHP hauria de poder-se compilar en bytecode perquè pogués correr en un servidor web ASP.NET.

Penseu el senzill que serà doncs, usar codi des de .NET que haguem fet amb PHP o alrevés, si ja disposem de classes implementades en C# O VB.NET les podrem usar tranquilament des de PHP.

Llàstima que no m’hagi posat mai ni en .NET ni mono ni res de res. A més dubto que ho fassi perquè no és la meva feina, però per alguns codis que tinc fets a la feina en PHP em seria una gran avantatge poder-los fer corre directament sobre infraestructures complemtament windows, així no hauria de portar els codis de PHP a llenguatges més complexos per tal de fer-los corre en servidors 2000 o 2003 amb ISS i .NET.

Per ampliar més informació us recomano la web de Phalanger és força completa i té molta documentació si algú proba mai el compilador que m’avisi ja que hi estic molt interessant però em suposaria molta feina provar-lo amb la infraestructura que tinc montada ara mateix. A més no tinc ni idea de .NET.

Capçaleres IPv6

2006/08/18 No Comments

Reading time: 9 – 14 minutes

Basant-me en un parell d’articles de Network Systems Design Line vaig escriure l’article IPv6: repassant les novetats tècniques, doncs bé s’han publicat les parts 3 i 4 que continuen amplicant la introducció feta a les parts 1 i 2 que vaig repassar en el meu article. La part número 3 parla específicament de les característiques de les capçaleres IPv6. Part realment important i interessant en aquesta nova versió IP. Així doncs dedicaré aquest article a resumir la part 3 de l’article de Networki System Design Line que parla sobre les capçaleres IPv6.

IPv6 vs IPv4 formats de capçalera

Per entendre quines són les motivacions que han provat els canvis en la capçalera IPv6 cal tenir clar quins eren els camps de la capçalera IPv4.

Version (4bits) obviament conté la versió del protocol en aquest cas fixarem la versió a 4.
Header Length (4bits) llargada en octets de la capçalera.
Type of Service (ToS) identificador usat en QoS per tal de poder classificar els paquets segons la prioritat que li volem donar.
Total length (16bits) llargada en octets del paquet sencer, capçalera més dades. La llargada màxima serà 65.535 octets, que és el màxim que podem definir amb 16 bits.
Identification (16bits) Flags (3bits) Fragment Offset (13bits) a través d’aquests tres camps IPv4 implementa el suport de la fragmentació de paquets.
Time to Live (TTL) (8bits) número màxim de salts que pot fer un paquet abans d’arribar al seu destí. Amb aquest camp s’evita que si hi ha un problema d’enrutament els paquets saltin infinitament en cercle, sense arribar mai al destí. En cada salt que fa el paquet es decrementa el valor del camp i si aquest arriba a 0 es descarta el paquet.
Protocol Number (8bits) indica el codi del protocol que encapsula IP en la capa superior, o sigui, la capa 4. Els números que identifiquen aquests protocols (TCP, UDP, ICMP, etc) els defineix la IANA.
Header Checksum (16bits) serveix per comprobar la integritat de les dades de la capçalera.
Source IPv4 address (32bits) adreça IP origen.
Destination IPv4 Address (32 bits) adreça IP destí.
Options (mida variable) s’acostuma a guardar-hi informació necessària per interpretar les dades que transporta el paquet.
Padding (mida variable) aquest camp s’usa per ajustar la mida del camp Options a 32 bits totals.

La nova capçalera IPv6 intenta millor els principals problemes de la IPv4 a través de:

Mida fixa de la capçalera. Sempre de 40bytes, això afavoreix el poder processar-la de forma més ràpida perquè els routers poden buscar les direccions origen i destí de forma més eficient. Les funcionalitats que tenia IPv4 a través del camp de mida variable, Options ara la obtindrem a través de les extensions de la capçalera, concepte del que es parlarà després.
La fragmentació deixa de tenir sentit ja que a través del PMTU discovery els routers ajusten la mida de les trames per tal de que no hi hagi fragmentació en els paquets. Així els camps de Identification, Flags, i Fragment Offset deixen de tenir sentit.
Les comprobacions de la capçalera (header checksums) s’eliminen. Aquesta tasca ara és deixa per les capes superiors.

Així doncs, les capçaleres d’IPv6 es defineixen al RFC 2460 i queden com segueix:

Version (4bits) versió del protocol IP, sempre fixe a 6.
Traffic Class (8bits) fa el mateix que el ToS del IPv4.
Flow Label (20bits) a través d’aquest camp identifiquem un fluxe de paquets informant al router que els següents ‘n’ paquets seràn iguals a aquest i per tant, no cal que els processi. Aquesta idea es desenvolupa al RFC 3697. Aquesta informació es fixa en l’origen del paquet i no la poden modificar els routers.
Payload Lengh (16bits) com que la capçalera sempre té 40bytes amb 16bits en tenim prou per delimitar la mida de les dades. És important recordar que les extensions de la capçalera es consideren part de les dades.
Next Header (8bits) definim quin tipus de extensió de la capçalera segueix a la capçalera bàsica.
Hop Limit (8bits) és l’equivalent al TTL. Només se li ha canviat el nom perquè sigui més descriptiu del funcionament del camp.
Adreça origen IPv6 (128bits)
Adreça destí IPv6 (128bits)

Extensions de capçalera IPv6

Bàsicament les extensions de capçalera són una segona capçalera, opcional, que s’usa per donar les funcions que es donava en IPv4 a través del camp, de mida variable i màxim de 40bytes, Otpions. En IPv6 podem fer aquestes extensions de capçalera tran grans com ens interessin, sempre que respectem la mida màxima del paquet.

A continuació podem veure un exemple d’una capçalera bàsica, i d’una capçalera amb uan extensió de capçalera.

A l’RFC 2460 podem trobar les definicions de les extencions de capçalera. Podem trobar-hi, una descripció, el format i la funcionalitat.

Hop-by-Hop Options Header

La capçalera Hop-by-Hop és una extenció de la capçalera bàsica, es defineix en el camp Next Header, de la capçalera bàsica, amb el codi 0. És la única extenció de capçalera que s’ha de processar per tots els nodes del camí entre l’origen i el destí del paquet. S’úsa per exemple per facilitar la expedició de dels Jumbograms (després s’explica què és això), o també facilita que els routers es passin informacions d’expedició (forwarding).

Les opcions que transporta aquesta extenció de capçalera es codifiquen en un format que es diu TLV, a continuació es pot veure un diagrama del format.

Tots els nodes que hi ha en el camí rebran aquesta capçalera i la processaran. Si algún dels nodes no entengues les opcions que conté la capçalera i que ha de processar generaria un paquet de tipus ICMP. Tot i que no totes les opcions han de generar forçosament aquest missatge ICMP, amb això s’eviten problemes d’atacs de denegació de serveig per inundació de paquets ICMP.

És important tenir en compte l’impacte en el rendiment que té el fet de processar les capçaleres hop-by-hop en cada un dels routers. Una de les funcionalitats que té és el fet de suportar paquets molt grans. La capçalera bàsica només permet una mida que es pugui definir en 16bits, o sigui, de com a molt 65.536 octets.

Les extensions hop-by-hop contenen un camp de 32 bits de llargada que pot representar paquets molt grans, anomenats Jumbograms. Quan volguem usar el camp de 32bits de la capçalera hop-by-hop el camp Payload length de la capçalera bàsica el posarem a 0, amb això s’idenfica un paquet Jumbogram.

A través de l’RFC 2711 es defineix l’opció Router Alert que a través de la caçalera hop-by-hop permet enviar intruccions d’expedició (forwarding instructions). Per exemple, per fer reserves d’amplada de banda amb RSVP. O per alertar als routers que han de processar paquets multicast, això es fa a través dels paquets Multicast Listener Discovery.

Destination Options Header

Com el propi nom indica, aquesta extenció de la capçalera bàsica es refereix nomes a les Option de la direcció de destí. Per exemple s’usen amb MIPv6. El codi usat en el camp Next Header a la capçalera bàsica és el 60.

Routing Header

Identificada amb el codi 43, al camp Next Header. S’usa per reforçar el camí a seguir per alguns paquets. El camí el defineix l’origen, i podria no coincidir amb el camí calculat pels routers intermitjos.

La capçalera routing header conté un camp de tipus (type) que permet saber amb exactitut a funcionlitat d’aquesta capçalera. En aquest moment hi ha dos tipus de funcionalitats definides:

Type 0 (RFC 2460) especifica tots els salts que ha de fer el paquet per viatjar fins al seu destí. El que faràn els routers intermitjos és anar canviant la direcció destí de la capçalera bàsica en funció de la capçalera extesa per forçar el salt cap al següent node, si haguessin de fer algún salt no contemplat aquest no modificaria la direcció destí d’aquell moment ni apareixeria ni s’afegiria a la capçalera extesa. Per tant, aquests salts no contemplats serien transparents al procés.
Type 2 (RFC 3775) usat amb MIPv6. Conté una única adreça unicast, l’adreça del home, i habilita al node corresponent perquè re-envii el tràfic directament a un node mòbil.

Fragment Header

La fragmentació requereix molt de procés en els nodes. Per tal d’evitar les necessitats de sobrecarregar els processadors dels nodes a IPv6 no s’admet la fragmentació de paquets. Abans d’enviar un paquet, l’origen ha de passar per un procés de descobriment de PMTU. Això determinarà quina és la màxima mida que pot tenir un paquet per aquell camí sense que es fragmentin els paquets. Malgrat els routers ja no han de controlar el problema de la fragmentació els nodes destí si que han de saber recomposar un paquet fragmentat. Per tal de poder-ho fer, s’usen les extensions de capçalera Fragment Option Header.

Authentication Header

Aquesta capçalera s’assembla a la capçalera IPSec AH (RFC 2402) usada en IPv4. Aquest sistema autentica l’origen d’una transmissió i assegura la integritat del paquet. El camp Next Header l’identifica amb el codi 51.

Encapsulating Security Payload Header

S’assembla a la idea implmentada en IPSec ESP (RFC 2406) en IPv4. Identificat amb el codi 50 al camp next header.

Mobility Header

Definit a l’RFC 3775 i usat en les comunicacions entre nodes mòbils, nodis corresponents (correspondent nodes) i amb agents domèstics (home agents) en l’establiment i el control de bindings. Identificat amb el codi 135 al next header field.

Acabant…

Amb aquest article n’hi ha prou per veure que el tema de la capçalera s’ha cuidat moltíssim i que hi ha infinitat de combinacions que permeten extendre la capçalera bàsica per gaire bé qualsevol necessitat que se’ns ocurreixi. A més si ens cal fins hi tot podem crear noves extencions per les nostres necessitats. Sota el meu punt de vista aquest és un dels avantatges més potents en IPv6.

Diferents formes de lligar-se els cordons de les sabates

2006/08/14 No Comments

Reading time: 1 – 2 minutes

Recordo que quan tenia 16 anys li vaig explicar a algú que a internet hi havia uns foros on la gent tenia converses absolutament de qualsevol tema, fins hi tot hi havia discusions de com s’havia de col·locar el paper de wc: penjant pel cantó de la paret, o per l’altre cantó. Doncs als més populars del delicious m’he trobat un web on es parla d’una cosa gairebé tan rebuscada com la que us he comentat, o sigui, podeu veure una recopilació de desenes de formes diferents de cordar-se les sabates amb les seves avantatges i desavantatges. Realment hi ha gent per tot, fins hi tot gent per referenciar fets així.

Si com jo no podeu evitar perdre-hi 10min llegint totes les formes com uns autistes: 31 Different Ways To Lace Shoes (local).