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.

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.

2012 serà el meu any d’automatització

Després d’una temporada aprenent i muntant eines com Puppet i FAI a la feina, veient el panorama que dibuixa Ubuntu amb l’Orchestra, el Juju i el nou projecte MaaS, segurament el propòsit més important que m’he fet per aquest 2012 és el d’automatitzar tot el que pugui per evitar perdre temps en tasques repetitives i mecàniques, tal com apunta en Tom Limoncelli al seu llibre sobre gestió de temps per a administradors de sistemes.

En aquest sentit, un bon indicador de coses a automatitzar són els correus que rebo diàriament sobre els backups, els crons i les notificacions de postmaster. He decidit que com que no puc ignorar-los i mentre els segueixi rebent continuaré perdent molt de temps processant-los cada dia, el meu objectiu serà deixar-los de rebre; preferiblement perquè hauré pogut automatitzar algun procediment, simplificar alguna tasca o emmagatzemar alguna sortida, etc. Si per algun motiu no ho puc aconseguir, no em quedarà altre remei que delegar aquesta feina, que en el fons és una de les solucions que proposen tant en David Allen com en Tom Limoncelli.