Col·laboració en els projectes TIC de la UPC

Avui el personal TIC de la UPC estàvem convidats a participar en un seminari sobre eines col·laboratives durant el qual ens han fet una enquesta amb diverses preguntes per copsar fins a quin punt fem difusió de la nostra tasca tant a dins com a fora de la universitat.

A la pregunta s’havia de repondre la periodicitat amb què difonem la nostra tasca a la nostra unitat, a d’altres unitats de la UPC i a fora de la UPC. Quan hem analitzat les respostes de l’enquesta, aquesta pregunta ha generat un petit debat sobre si s’havia acabat d’entendre bé i què s’entenia per difusió. Sense entrar en detalls, el resultat de l’enquesta mostrava que fem difusió a les nostres unitats força sovint, una mica menys a la resta d’unitats i molta menys a fora de la UPC. El debat s’ha centrat en aquesta darrera observació: la majoria de les persones diuen que gairebé mai fan difusió de les seves tasques a fora de la UPC. Doncs bé, jo he estat una d’aquestes persones.

Fa temps que vaig encetar aquest blog amb la intenció de compartir les meves experiències sobretot a la feina. Però escriure demana temps i constància i ràpidament ho vaig abandonar. De fet, gairebé feia un any que no escrivia res. La pregunta que em faig és per què passa això? A banda del temps per escriure, quins altres factors fan que compartir el que faig a la UPC sigui difícil o faci mandra? Potser és la frustració d’haver intentat col·laborar molts cops sense gaire èxit.

La UPC és molt gran, fins al punt que hi treballem uns quants centenars de TIC. Molts ens coneixem perquè hem treballat junts, perquè hem estat companys d’estudis, perquè hem coincidit en els cursos de formació, perquè hem lluitat plegats per defensar els nostres drets a la UPC, etc. Per tot això, els TIC de la UPC estem força units per un sentiment de pertinença que ens defineix com un grup amb un gran potencial dins de la comunitat UPC. Però curiosament aquest sentiment no es tradueix en projectes de col·laboració entre les diferents unitats on estem treballant. Fins i tot la comunicació entre nosaltres és pobra en el sentit que no sabem què fan els nostres companys d’altres unitats, tret que hàgim coincidit en alguna banda i els ho preguntem directament.

Aleshores què és el que cal perquè es produeixi aquesta col·laboració entre nosaltres? Jo tinc la sensació que molts dels TIC tenim ganes de col·laborar perquè hem vist en altres comunitats que és bo a llarg termini per a tothom. Avui durant el seminari ens han presentat algunes eines que poden engrescar-nos una mica, però en el fons el problema no són les eines. Per dur a terme projectes cal destinar-hi recursos. Això vol dir que, en el context actual d’escassetat, aquests recursos no es podran destinar a altres coses i per tant cal establir prioritats. Aquesta feina és responsabilitat de les persones que dirigeixen els equips i les unitats de la universitat perquè són els que coneixen què aporta més valor a la docència i la recerca. Què falla doncs?

Des del meu humil punt de vista, tot i que la comunitat UPC està formada diversos col·lectius de persones, no compartim la mateixa visió del que és la universitat. Fins a un cert punt, suposo que és comprensible tenint en compte que els col·lectius són realment diversos (en tipologia i mida): els estudiants, el personal docent i investigador i el personal d’administració i serveis. Però aquest problema de visió no compartida fins i tot passa dins dels mateixos col·lectius i aquí és on comencem a ensopegar amb els impediments. Com es resol això?

La solució és molt simple de dir però difícil de dur a terme: cal incentivar i facilitar la col·laboració a tots els nivells dins la UPC. El que no hauria de passar és que hi hagi gent amb l’empenta i l’esperit de fer projectes que aportin valor a la universitat, col·laborant amb els companys d’altres unitats i que la manca d’una visió compartida freni aquesta iniciativa. Perquè la gent col·labori només cal que en tinguin ganes i els ho posin fàcil. Un altre dia en seguiré parlant.

El futur del correu a la UPC

A la UPC ja fa uns anys que s’està estudiant la migració del servei de correu electrònic al núvol. Arran d’un fil sobre el tema a la llista de l’assemblea de la Càtedra de Programari Lliure, he fet una reflexió sobre el tema que també vull compartir des del blog. Us recomano que llegiu tot el fil i especialment el document que ha preparat en Sebas Vila amb les seves valoracions.


El tema del correu com a comodity és un aspecte interessant a tenir en compte, hi estic d’acord. Però no és pas l’únic i no crec que sigui el principal en la situació actual de la UPC. Davant de la greu situació econòmica de la UPC, el primer que cal posar damunt la taula és una anàlisi econòmica del cost actual del servei de correu distribuït en unitats, el cost que tindria si es centralitzés en 1 sol punt dins la UPC i finalment el que costaria externalitzar-lo, tenint en compte el cost de migració del que no es parla en cap moment, i de tornar-lo cap a casa si canviessin les circumstàncies. Amb l’anàlisi econòmica i tècnica, junt amb l’anàlisi de riscos es podria determinar si cal fer el pas i si cal fer-lo ara.

Un altre aspecte important a tenir en compte és l’opinió que tenen els usuaris del servei actual. Tal com apunta en Sebas, potser ens adonaríem que hi ha una part important de gent dins la UPC que ja no estan utilitzant el servei de correu i que per tant tampoc suposen un cost significatiu. Però també cal tenir en compte que fa una pila d’anys que s’intenta deixar de banda el Lotus Notes i que no hi ha manera d’aconseguir-ho, força usuaris segueixen utilitzant-lo per llegir el correu. Si fins ara no ha estat possible eliminar el Notes què ens fa pensar que aquests usuaris es voldran canviar a qualsevol altra cosa?

El risc de fracàs és realment alt per molts motius, però principalment perquè s’està plantejant una migració completa del servei de correu actual. Em pregunto per què no es pot fer un projecte pilot amb usuaris de diferents col·lectius i fer una anàlisi acurada del que suposaria la migració completa. S’ha fet amb el tema del teletreball, per què no es fa amb el correu?

Estic d’acord amb en Marc que hem de valorar si el correu és un servei estratègic o si cal dedicar els esforços a d’altres serveis que tinguin més impacte en la docència i la recerca. Però com a tècnic tinc la sensació que el correu UPC és com la xarxa UPC, són serveis transversals que vehiculen la resta de serveis. No els valorem perquè funcionen raonablement o perquè hem sabut trobar-hi alternatives (els mòbils amb 3G en són un exemple).

Si la UPC fos una startup dedicada a fabricar maquinari lliure o programari lliure, tindria clar que el correu no seria un servei estratègic i no hi dedicaria recursos propis. Però el nostre camp és el coneixement i per compartir-lo de forma eficient crec que hem de tenir el control dels nostres propis canals de comunicació. No es tracta de competir amb els serveis del núvol perquè qui vol ja els està utilitzant sense demanar permís, hem de donar el servei que necessiten els nostres usuaris. Per això potser ens hem de preocupar primer per saber si estem donant el servei que volen i si ho estem fent bé. Tampoc serveix de res parlar en nom dels usuaris sense tenir dades concretes del que opinen del servei que donem.

Finalment, un aspecte interessant a tenir en compte és que el servei de correu no ha evolucionat gaire perquè és un dels més omnipresents a tot el món i costa introduir canvis (per exemple, per combatre l’spam, etc.). Curiosament aquest és un àmbit de recerca que sembla en via morta, però crec que té molt de potencial. Si la UPC renuncia a gestionar el seu propi correu estarà renunciant a un dels serveis universals sobre els quals un avenç en recerca podria tenir un impacte molt important per a tota la humanitat. De debò la UPC s’ho pot permetre o ha de ser pionera en el futur del correu electrònic? Si ho hagués de ser, no tindria gaire sentit haver externalitzat el seu propi servei, oi?

Please mount Volume or label a new one?

A Monday morning we found several messages like this from Bacula:

09-Sep 18:27 Tape-A JobId 15196: Please mount Volume "A0000038" or label a new one for:
    Job:          sites.2012-09-08_01.50.03_40
    Storage:      "LTO-4" (/dev/nst0)
    Pool:         Default
    Media type:   LTO-4

That was Bacula complaining about the wrong volume on the drive. However, after examining the status of storage the weird thing was that the tape with barcode “A0000038” was actually mounted on the drive, it was purged and had 0 bytes used… WTF?

We started suspecting our tape rotation algorithm was not taking into account that maybe purged tapes were not used if data retention hadn’t expired, but Automatic Volume Recycling says otherwise and some tests on other purged tapes with expired data retention failed too.

Several days of searching similar issues later, it seemed clear that there was something wrong only with some purged tapes from the media catalog. So i came up with a quick test for each one of our purged tapes in order to make sure that they were labeled correctly. First, i loaded “A0000038” and read its label:

# mtx -f /dev/sg4 load 22
Loading media from Storage Element 22 into drive 0...done
# dd if=/dev/nst0 bs=65000 count=1 | od -a | head
0+0 records in
0+0 records out
0 bytes (0 B) copied, 3.81024 s, 0.0 kB/s
0000000

You can see that it failed to find any Bacula label, so next i tried the same test with another tape in full state that had been used the day before:

# mtx -f /dev/sg4 load 16
Loading media from Storage Element 16 into drive 0...done
# dd if=/dev/nst0 bs=65000 count=1 | od -a | head
0+1 records in
0+1 records out
64512 bytes (65 kB) copied, 3.73563 s, 17.3 kB/s
0000000   G   ;   =   < nul nul nul   D nul nul nul nul   B   B   0   2
0000020 nul nul stx  gs   L etx   O sub del del del   ~ nul nul nul nul
0000040 nul nul nul 240   B   a   c   u   l   a       1   .   0       i
0000060   m   m   o   r   t   a   l  nl nul nul nul nul  vt nul eot dc3
0000100   1   8   O  si  ff nul eot dc3   J   +   W stx   p nul nul nul
0000120 nul nul nul nul nul nul nul nul nul nul nul nul nul   A   0   0
0000140   0   0   0   0   6 nul nul   D   e   f   a   u   l   t nul   B
0000160   a   c   k   u   p nul   L   T   O   -   4 nul   v   m   -   h
0000200   o   s   t   -   4 nul   T   a   p   e   -   A nul   V   e   r
0000220   .       5   .   0   .   1       2   4       F   e   b   r   u

(Note that device /dev/nst0 has a minimum block size of 64512 bytes, otherwise dd would raise a Cannot allocate memory error.)

This time the Bacula label was found on the tape (the Bacula 1.0 immortal string is a clue), so we were now on the right track. Then i reviewed our wiki for the tape change procedure and there was an optional step in the tape purging section explaining how to blank a tape from another Bacula director before labeling it for this one. Therefore, it seemed that someone had been blanking the tapes after purging them and Bacula didn’t know what to make with them even though they had the right barcodes.

The fix was quick: i tested every purged tape to make a list of the blanked ones, then deleted them from the catalog and labeled them back from the bconsole:

* delete volume="A0000038"
* label barcodes slots=22 pool=Default

Bacula is happy again, and we are too! 🙂

etckeeper en mode silenciós

Hi ha eines que quan les descobreixes et semblen genials. Aquest és el cas de etckeeper, una eina que permet mantenir el directori /etc sota un sistema de control de versions (VCS) com ara git, mercurial, bzr o darcs. Un dels seus avantatges principals és que guarda una còpia abans i després d’instal·lar paquets al sistema, de forma que és molt fàcil de veure els canvis que es produeixen a les configuracions. Un altre és que s’acostuma a executar diàriament una còpia dels canvis mitjançant un crontab i si hi ha canvis es mostren en el correu corresponent que envia el dimoni cron. D’aquesta manera si faig canvis al /etc i no els he desat, el cron s’encarregarà de fer-ho un cop al dia.

Però aquest darrer avantatge es pot convertir en un greu inconvenient si instal·leu etckeeper en un clúster relativament gran o si gestioneu molts servidors. Idealment, per cada canvi que es faci al /etc caldria executar després «etckeeper commit …» per tal de guardar els canvis al VCS. Per exemple,  després de canviar la contrasenya d’un usuari o d’afegir-ne un de nou. Però si us oblideu de fer-ho, l’endemà potser us trobeu més d’un centenar de correus amb els canvis de cada servidor.

Doncs bé, una opció és acceptar que només us interessa rebre missatges en cas que es produeixi un error i els canvis diaris que es facin silenciosament. La primera idea que se’ns podria ocórrer és canviar el crontab del etckeeper perquè enviés la sortida estàndard a /dev/null però resulta que «bzr commit» (per defecte, etckeeper a ubuntu tria bzr com a VCS) treu el seu informe per l’error estàndard! Com que redirigir també l’error estàndard a /dev/null sempre és una mala idea (si es produís un error no us n’assabentaríeu), cal buscar una altra estratègia. Afortunadament és possible canviar les opcions dels diferents VCS a la configuració i per al cas de bzr només cal posar això al fitxer /etc/etckeeper/etckeeper.conf:

BZR_COMMIT_OPTIONS="-q"

Amb el que cada cop estic més a prop de tenir menys correu a la bústia d’entrada 🙂

Reduir els correus de Bacula

El Bacula és un sistema de gestió de backups professional en programari lliure (també es pot contractar suport empresarial, si cal). En la configuració predeterminada és costum enviar un correu per cada treball que indiqui si ha finalitzat correctament o no. Però en un entorn amb una pila de servidors i diversos treballs per servidor, això implica rebre diàriament molts correus que habitualment indiquen que tot ha anat bé. En el meu cas, són entre 60-70 correus diaris.

Afortunadament, si hom disposa d’un sistema de monitoratge compatible amb Nagios, pot utilitzar un connector que examina els logs del bacula director per veure si s’ha produït algun error. Per tant, ja no cal seguir rebent aquest allau diari de correus que indiquen que els treballs han acabat bé. Per fer-ho només cal que canvieu la configuració dels Messages anomenats Standard al fitxer /etc/bacula/bacula-dir.conf i on posava «mail» hi poseu «mail on error»:

Messages {
  Name = Standard
  mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
  operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
  mail on error = bacula@example.com = all, !skipped
  operator = bacula@example.com = mount
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
  catalog = all
}

Amb aquest canvi, tots els treballs que utilitzin els missatges estàndard passaran a enviar correus només en cas que es produeixi algun error. Però potser us interessa que els treballs de recuperació sí que notifiquin si han acabat bé i així podeu evitar d’estar pendents dels logs, oi? Doncs és ben fàcil també: només cal crear un nou tipus de missatge pels treballs de recuperació que tingui «mail» enlloc del «mail on error» i indicar-ho a la secció corresponent:

Job {
  Name = "RestoreFiles"
  Type = Restore
  Client = bacula-fd
  Storage = Tape
  FileSet = "Full Set"
  Pool = Default
  Messages = Restore
  Where = /tmp/bacula-restores
}

Messages {
  Name = Restore
  mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
  operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
  mail = bacula@example.com = all, !skipped
  operator = bacula@example.com = mount
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
  catalog = all
}

Es tracta d’un petit canvi que pot augmentar significativament la productivitat d’un equip de sysadmins amb una pila de servidors dels quals es fan còpies de seguretat cada dia.

Impuls i fricció

L’abast de la trajectòria balística d’un projectil és una funció de la inèrcia obtinguda en l’impuls inicial i de la fricció del mitjà en el qual es desplaça. Doncs bé, hi ha qui utilitza aquesta relació entre impuls i fricció per explicar algunes característiques de l’enginyeria del programari i com reduir la fricció per a millorar la productivitat obtinguda per l’impuls.

En aquesta metàfora l’impuls és l’energia necessària per emprendre una tasca habitualment llarga i que requereix una certa creativitat o fins i tot un aprenentatge previ, com podria ser el cas d’un projecte de programari per a un desenvolupador o el disseny d’un entorn d’alta disponibilitat per a un administració de sistemes. Per contra, la fricció serien totes aquelles petites tasques rutinàries o les interrupcions del dia a dia, que són necessàries però ens trenquen la concentració i redueixen l’impuls. Curiosament, sembla que la forma més habitual d’enfocar aquest problema és justament la menys efectiva.

Per tal d’aconseguir una finestra de temps prou gran per a dedicar al projecte important que tinc entre mans, tinc la tendència a mirar de treure’m de sobre primer totes les petites tasques (llegir el correu pendent, atendre les interrupcions, resoldre les tasques més ràpides o rutinàries, etc.). Idealment, un cop enllestit hauria de poder-me dedicar amb tota l’energia al projecte que tinc entre mans però en realitat no és així perquè de tasques petites i interrupcions en sorgeixen constantment en el món de l’administració de sistemes. Aleshores és evident que la solució és enfocar-ho a la inversa: em cal dedicar principalment tota l’energia (l’impuls) als projectes i deixar de banda les tasques petites tasques i rutinàries (la fricció). Però això no és pas tan fàcil perquè aquestes altres tasques no es poden deixar de banda indefinidament, part de la meva feina és resoldre-les també (sobretot les que afecten directament els usuaris).

Finalment, després de llegir els articles que esmentava al principi, crec que per mi la millor solució és una combinació de treball en equip i d’establir un calendari amb finestres sense interrupcions en què poder dedicar el temps necessari a tirar endavant els projectes de la forma més productiva. El treball en parella permet centrar-se en els interessos comuns dels dos individus a tirar endavant un projecte i per tant evita les temptacions de tots dos de caure en les tasques de fricció (no té gaire sentit llegir el correu en parella, per exemple). A més a més, si sumeu un tercer individu que us faci d’escut de les interrupcions (atengui els usuaris, respongui al telèfon, etc.) durant la finestra de temps que heu fixat, ja teniu la fórmula ideal per a la productivitat.

Cyrus said: 554 5.6.0 Message contains NUL characters

Feia unes quantes setmanes que rebia un munt de correus de backscatter a postmaster que em portaven de corcoll. Els missatges indicaven que el nostre MDA (Cyrus IMAP 2.2) no acceptava els correus que havien arribat al MTA intern (Postfix 2.5.1) perquè contenien caràcters nuls:

<xxxxxxxx@[x.x.x.x]>: host x.x.x.x[/var/run/cyrus/socket/lmtp]
    said: 554 5.6.0 Message contains NUL characters (in reply
    to end of DATA command)

Primer vaig mirar si la versió de Sieve que ve amb Cyrus suporta les extensions per filtrar basant-se en el contingut del cos però no hi va haver sort (amb Cyrus 2.4 ja està suportat però a la 2.2 no). Així que buscant buscant vaig trobar un fil molt interessant de la discussió original l’any 2005, on s’anaven passant la culpa de Postfix a Cyrus i a l’inrevés, com en un partit de tennis, mentre invocaven la màxima aquella de «be liberal in what you accept and strict in what you send». Tot i que en principi en Wietse Venema va dir que no podia dedicar temps a implementar el filtre a Postfix, finalment el va poder incloure a la versió 2.3 i ara la solució és prou senzilla:

message_strip_characters = \0

Amb aquest petit canvi he deixat de rebre diàriament centenars de notificacions de postmaster d’aquest tipus que em feien perdre un munt de temps.