A la feina¹ tenim un parell de servidors² que corren amb Debian on entre moltes altres coses hi tinc alguns processos amb cron i tal.

Com que des que vaig configurar un servidor de correu al servidor de casa estic rebent la sortida de l’execució dels processos que tinc en el cron per correu electrònic i trobo que és molt útil avui he fet el mateix a la feina, i la veritat és que ha sigut la cosa més senzilla del món!

Nota: amb aquesta configuració només rebreu els correus interns del propi servidor, no tindreu un servidor de correu completament funcional ni molt menys!

Passos per fer-ho:

1. Configurar un registre MX d’un domini que tingueu al vostre abast per poder adreçar-vos-hi per recollir el correu.
2. Deixar tal qual està l’exim4 tal com ve per defecte a Debian (o sigui no fer res ).
3. Instal·lar el dovecot-imap (apt-get install dovecot-imapd)³.
4. Llestos!

Ara l’únic que heu de fer és configurar el vostre client de correu perquè vagi a recollir a través d’IMAP els correus en el vostre servidor i d’aquesta manera tindreu puntualment la sortida de les execuccions dels processos del cron al vostre client de correu

Punts extra

• Per si no us n’adoneu quan instal·leu el dovecot-imapd: el propi dovecot crea un certificat auto-generat de manera que només fent els 4 passos de sobre⁴ teniu xifratge de la connexió gratuïtament

• Per no haver de tenir 40.000 comptes en el client de correu que utilitzeu podeu afegir la següent línia al crontab de tots els usuaris que tinguin cron:

MAILTO=jordi@localhost

D’aquesta manera tots els usuaris que en el seu crontab tinguin aquesta línia enviaran el correu a l’usuari jordi, de manera que l’únic compte que haureu de tenir en el vostre client de correu és el de l’usuari jordi.

1. Perdó per l’SPAM [↩]
2. El típic escenari de producció i desenvolupament/test [↩]
3. Si voleu també podeu instal·lar el dovecot-pop3d per accedir a través de POP [↩]
4. Realment dos: el primer i el tercer,  i un només en el propi servidor. [↩]

Resulta que a la feina tenim uns quants servidors virtuals per a diferents propòsits i com que un era amb CentOS i d’altres amb Debian un dia vaig adonar-me que quan em connectava al CentOS se’m canviava el títol del terminal però en canvi en connectar-me als Debian no.

Així que investigant una mica he descobert que hi ha la variable PROMPT_COMMAND que et permet canviar el títol, de manera que per exemple si poses al ~/.bashrc:

PROMPT_COMMAND=’echo -ne “\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007″‘

Et posarà com a títol el nom d’usuari, l’ordinador on estàs i el camí on estàs actualment.

Segur que els que utilitzeu el Vim ja n’heu buscar la solució ja que realment és molt molest.

Si aneu a una pàgina web i en copieu el codi font d’un tros de programa, per exemple:

Us trobareu que un cop enganxat al terminal queda tot el codi reformatat:

Per sort amb el Vim li pots dir que no reformati el codi:

El truc està en que abans d’enganxar al terminal ens posem en mode control i establim l’opció paste) o sigui, la seqüència és:

• (obres el fitxer)
• Passes a mode ordre (amb la tecla Esc)
• escrius :set paste
• tornes a mode edició (amb la tecla i)
• ja pots fer un Ctrl+Maj+V per enganxar el que tinguis al porta-retalls

Llestos ja tenim un bon tros de codi que no hem de picar i que a més continua ben formatat

No us heu cansat mai de teclejar ssh usuari@nom-interminable-de-la-maquina-hi-ha-sobre.domini ?

Doncs com en tot en el món linux té el seu fitxer de configuració: ~/.ssh/config (man ssh_config).

És tan senzill com tres línies:

Host nom-curt

HostName nom-del-servidor.com

User usuari

Un cop escrit això de sobre (canviant les cursives clar) ja podreu teclejar ssh nom-curt quan en realitat estaríeu teclejant ssh usuari@nom-del-servidor.com.

Sembla una petita diferència oi? Però penseu en els casos en que teniu més d’una clau pública¹ o qualsevol altre opció que heu d’especificar per connexió!

No hi ha dia que em deixi de sorprendre i trobar encara més útil l’OpenSSH!

1. La de la feina, la del servidor de casa, la del projecte on esteu col·laborant, la d’accés a repositoris de codi … [↩]

No us heu trobat mai amb la necessitat de veure els canvis que s’han fet en un commit? Res més senzill que fer un git log per agafar el SHA1 del commit en qüestió i després fer un git show SHA1.

Evidentment com qualsevol altre ordre de git pot fer molt més que només mostrar els canvis fets en un commit, ja que la descripció que se’n dóna en fer un git help show és: Mostra diversos tipus d’objectes.

Fins que no proves les coses no te n’adones de lo difícil, o fàcil, que és fer-les…

Avui havia de fer uns canvis a un dels servidors de la feina i com que eren temes de configuració … cd /etc

Però abans de prémer cap més tecla m’ho he pensat dues vegades i he teclejat unes quantes ordres ben senzilles i  molt útils de cara al futur:

Control de versions de la configuració d’un servidor

Sembla que pugui ser una cosa difícil, que requereixi molt de temps i que sigui complex de mantenir oi? Doncs res més senzill que fer:

cd /etc
git init
(opcionalment vim .gitignore per excloure els fitxers que no volem versionar)
git add -A
git commit -m"Configuració inicial que funciona del servidor"

Només amb aquestes senzilles ordres ja tenim tot el directori /etc versionat amb git. A partir d’ara qualsevol canvi a qualsevol fitxer que estigui dintre de /etc ens sortirà amb un git status i quan haguem fet les proves necessàries per assegurar que els canvis són correctes ja podrem fer un git commit FITXER1 FITXER2 -m”Missatge” per tenir controlada una nova revisió dels fitxers.

Ara ja no hi ha excusa per dir que s’ha perdut alguna configuració o que s’ha espatllat algun servei del servidor, sempre tindràs un git checkout o un git reset –hard HEAD per tornar a una versió dels fitxers de configuració correcta

Aquests dies estic començant a mirar-me tot el tema d’Android i per sort meva tenen un document, que per a mi, és molt important: Application Fundamentals.

Allà no t’explica cap truc per fer que la teva aplicació sigui perfecta, ni tan sols t’explica com l’has d’estructurar, però en canvi et vomita totes les paraulotes de la terminologia que es fa servir a Android. Per exemple: no fas crides a classes per crear una nova pantalla, sinó que fas un Intent. Totes les necessitats de hardware i software externs al teu projecte han d’estar escrits en un fitxer xml…

Evidentment llegint això no serveix per crear aplicacions, però sense llegir-ho ho passaràs força malament

Alguns consells sobre què més llegir o quines pàgines consultar per quan hi hagin dubtes sobre Android?

Una de les primeres coses que descobreixes quan utilitzes git és que de la mateixa manera que un mediawiki, per posar un exemple, hi ha mil i una maneres de treballar-hi:

Tot amb branques, arbres remots a github, via pedaços (com se solia anar amb subversion i cvs) …

De manera que igual com amb un mediawiki el més important és definir una bona guia d’estil, les plantilles i el sistema de categorització, treballant amb el git, el més important és definir dintre de l’equip de treball un bon cicle de treball per tal que no hi hagi diverges …

I és aquí on entra l’ordre git stash.

Un exemple ben fàcil: tens canvis a 5 fitxers diferents, fas un commit per a tres d’ells perquè els altres dos encara no estan llestos per enviar.  Si en aquell moment vols fer un git pull –rebase perquè el servidor de git és un servidor central i vols agafar els últims canvis i aplicar-hi els teus commits locals a sobre de les últimes actualitzacions, el git no et deixarà fer-ho, ja que hi ha canvis sense estar en un commit.

No pots fer-ne un commit perquè no estan acabats, de manera que el que pots fer és un git stash, que senzillament desa els canvis que no estan a cap commit i et deixa l’arbre sense cap fitxer que no estigui en un commit, de manera que ja pots fer un git pull –rebase i si tot va bé un git push per enviar els teus commits locals.

Ja només et queda fer un git stash pop per recuperar els canvis que tens que no estan a cap commit i continuar treballant tranquilament

Evidentment, com tota eina de git, el git stash et permet fer moltíssimes coses més, de fet per tal com es recupera la sessió desada (git stash pop) ja podeu veure que el git stash funciona com una pila, de manera que pots tenir tants stash com necessiteu¹ i aplicar-los a altres branques, o crear branques a partir dels stash, etc etc …

1. No exempt de perill que després no funcionin sobre el commit en el que esteu treballant [↩]

Un dels problemes de tenir un repositori en un servidor central és com de costum el tema dels permisos, per una banda has de tenir els usuaris creats en local, afegir-los en el mateix grup perquè cadascú pugui accedir als repositoris i finalment un cop està tot apunt tens el problema (amb solució!) de que quan algú fa un commit la resta no en poden fer ja que s’han canviat els permisos.

A primer cop d’ull penses que això amb un hook de git i un script que faci un chown ja n’hi pot haver prou, després ho rumies una mica més i penses que no hauria de ser tant complicat i arribes a la idea que l’umask serà el teu amic … però al final cerques una mica per Internet i et trobes amb una solució molt més elegant:

$ git repo-config core.sharedRepository true

Amb aquesta senzilla ordre executada per a tots i cadascun dels repositoris que vulguis compartir entre més d’un desenvolupador i llestos, a programar que és el que ens agrada.

Sempre hi ha aquells casos en que tot i tenir un sol codi font s’utilitzen diversos altres codis font que tenen la seva existència per separat però que són necessaris dintre del projecte.

A subversion existeixen els externals i a git hi ha els submòduls. Treballen de forma diferent i per tant no es poden comparar exactament (tot i que el concepte és el mateix), ja que per exemple a subversion assumeixen que sempre vols actualitzar el codi de tots els submòduls i en canvi a git ho has de forçar tu manualment, si això és un avantatge o un inconvenient ja depèn de cada projecte en concret.

Per si hi heu de treballar des de git el capítol sobre submòduls del llibre del Git és perfecte (de fet l’he seguit punt per punt per fer-ho al projecte que tinc ara entre mans).