En actualitzar (ahir) a Ubuntu 10.04 LTS Lucid Lynx, he passat de la versió de PHP 5.2.10.dfsg.1-2ubuntu6 a la 5.3.2-1ubuntu4. Si volem tornar a tenir la versió 5.2, hem de configurar l’APT per tal que usi aquells paquets que vulguem de les fonts de Karmic Koala. Així:

Primer llistarem els paquets de php que tenim instal·lats:

dpkg -l | egrep php

En el meu cas són:

• php5-common
• libapache2-mod-php5
• php-pear
• php5-cli
• php5-curl
• php5-dev
• php5-mysql
• php5-memcache
• php5-suhosin

Dupliquem el fitxer amb les fonts de programari canviant la paraula lucid per karmic:

sed s/lucid/karmic/g /etc/apt/sources.list | sudo tee /etc/apt/sources.list.d/karmic.list

Creem un nou fitxer de preferències que anomenem per exemple “php”:

sudo nano /etc/apt/preferences.d/php

I copiem aquestes tres línies per cada paquet dels llistats anteriorment, tot canviant el nom del paquet:

Package: php5-common
Pin: release a=karmic
Pin-Priority: 991
...

Un cop ho hem configurat tot, actualitzem els paquets:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

No ens oblidem de reiniciar el servidor web; per l’Apache:

sudo apache2ctl restart

El UUID, o Universally Unique Identifier en anglès, és un identificador estàndard usat en la construcció de programari, estandaritzat per la Open Software Foundation (OSF), amb l’objectiu de permetre que sistemes distrubuïts identifiquin informació de forma única sense dependre de coordinació central.

A Ubuntu i a d’altres distribucions de GNU/Linux basades en Debian, es poden obtenir aquests identificadors per a cadascuna de les nostres particions amb una comanda ben simple:

blkid

Que haurem d’executar com a superusuari (root) o amb sudo al davant. La sortida d’aquesta serà semblant a:

/dev/sda1: UUID="8a866472-a077-4da9-9663-cd5a2774f801" TYPE="reiserfs"
/dev/sdb1: UUID="af8e31aa-9bb3-4c5e-b13a-433b06bb2231" TYPE="reiserfs"
/dev/sdc1: UUID="c027fa2e-ad9d-4324-bdad-941a5c43d2b3" TYPE="reiserfs"
/dev/sdc2: UUID="a9dbb0c9-3c60-4083-8f4c-de7e69d0ffda" TYPE="swap"
/dev/sdc5: UUID="8be8352b-e28e-44ee-a2e2-9abfa1eb43eb" TYPE="reiserfs"

Informació que ens pot resultar útil per configurar el fitxer /etc/fstab, amb les regles i opcions per muntar les diferents particions que tinguem.

Després d’haver recuperat totes les dades dels dos discos durs, i d’haver comprovat que el disc important no té errors de maquinari, l’he formatat. He creat el sistema de fitxers reiserfs amb:

cfdisk /dev/sda1 #crear la partició de forma interactiva
mkreiserfs /dev/sda1 #formatejar amb reiserfs

He passat totes les dades d’un disc dur (de la marca Seagate) a un altre (Western Digital), tots dos SATA i de 500 GB. Primer he mirat la quantitat de dades que havia de passar, en kibibytes (KiB) i en gibibytes (GiB):

minterior@jau:/media/recuperat$ du -sc
309201518       .
309201518       total
minterior@jau:/media/recuperat$ du -sch
295G    .
295G    total

Podem comprovar l’equivalència: 309201518 KiB / 1024 / 1024 = 294,877546 GiB ≈ 295 GiB

La còpia l’he feta des del terminal, anteposant la comanda time a la comanda cp -rp per obtenir el temps de duració de la còpia, que ha estat:

15.63user 2163.99system 1:54:07elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
618162424inputs+617982328outputs (1major+347minor)pagefaults 0swaps

Quasi dues hores. Per tant ha estat 6847 segons (1*3600 + 54*60 + 7) per escriure 316.622.354.432 bytes (309201518 * 1024), el que és una velocitat de:

46242493.71 bytes/s ≈ 46,2425 MB/s = 44,1003 MiB/s

Un cop recuperades les dades dels discs durs que tenien problemes, volia comprovar si aquests tenien sectors danyats. Ho he fet amb l’eina de Linux badblocks. Es pot executar de forma destructiva o no-destructiva, i jo he triat la primera perquè no tenia dades al disc que hagués de conservar. Per tant he executat:

badblocks -wvs -o badblocks-sda.log /dev/sda

Les opcions triades volen dir:

-w    test de lectura i escriptura DESTRUCTIU.
-v    mostra més informació
-s    mostra el progrés
-o    fitxer on escriure la llista de blocs defectuosos

Si observeu la comanda, no he indicat cap partició sinó tot el disc sencer (/dev/sda), la qual cosa combinada amb l’opció -w implica que el MBR, particions existents i dades, seran destruïts.

Si no voleu perdre cap dada del disc i fer també el test de lectura i escriptura canvieu l’opció -w per -n. Si no en poseu cap de les dues el test serà de només lectura. Per a més informació i opcions recordeu mirar el manual escrivint al terminal:

man badblocks

En el meu cas, després d’esperar unes quantes hores, vaig tenir sort i cap sector del disc dur estava danyat.

Sort!

L’altre dia (uf, ja fa un mes d’això!) vaig explicar la mala sort que vaig tenir quan dos discs durs tenien errors dels tres que tinc al meu ordinador. Abans d’ahir vaig començar les tasques de recuperació de dades, amb el programa GNU ddrescue. Al mateix manual en línia de ddrescue hi ha exemples molt útils, el primer dels quals és el que necessito jo. Anem per feina.

Recordo que l’objectiu és recuperar les dades de dos discos idèntics de 500 GB a un tercer disc auxiliar de la mateixa capacitat, que em va deixar un bon amic meu. És obvi que l’auxiliar ha de ser de la mateixa capacitat o major que el disc que volem recuperar. Primer ho intentaré amb un disc i després amb l’altre. El paràmetre de ddrescue -n o –no-split no intenta dividir o reintentar blocs fallits, i això faig a la primera passada:

root@jau:~# ddrescue -n /dev/sda /dev/sdb ddrescue-sda-a-sdb.log

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:   500107 MB,  errsize:    143 kB,  current rate:    10265 B/s
ipos:       29744 kB,   errors:      36,    average rate:   14150 kB/s
opos:       29744 kB,     time from last successful read:       0 s
Finished

El procés ha trigat unes 10 hores. Cosa que podem comprovar a partir de les dades informatives anteriors:
500107 MB / 14,150 MB/s / 3600 s/h ≈ 9,8 hores.

Tot seguit executo ddrescue amb les opcions -d o –direct , que usa accés directe al disc d’entrada, i -r o –max-retries=<n>, que surt després de n intents. Li passo el mateix nom de fitxer de log que a la comanda anterior i així ddrescue sap que només ha de buscar els sectors on ha tingut problemes durant la primera lectura:
Continua llegint la resta de l’entrada »

Segons llegeixo al manual oficial de GNU Privacy Guard: http://www.gnupg.org/gph/en/manual.html#AEN282, primer entrem a l’editor de claus amb la comanda gpg –edit-key i tot seguit teclegem adduid. Responem a les preguntes pel nou identificador, introduïm la contrasenya per la nostra clau privada i llest.

gpg --edit-key minterior@gmail.com
Ordre>adduid
Nom i cognoms: Jaume Casado Ruiz
Adreça electrònica: jcasado@unaplauso.com
Comentari: unAplauso.com
Heu triat l'identificador d'usuari:
    "Jaume Casado Ruiz (unAplauso.com) <jcasado@unaplauso.com>"

Canvia (N)om, (C)omentari, (E)mail o (O) d'acord / (X) ix O

You need a passphrase to unlock the secret key for
user: "Jaume Casado Ruiz (minterior) <minterior@gmail.com>"
1024-bit DSA key, ID F71B3570, created 2009-07-28

pub  1024D/F71B3570  created: 2009-07-28  expires: mai       usage: SCA
                     trust: desconeguda   validity: desconeguda
sub  2048g/68D20780  created: 2009-07-28  expires: mai       usage: E
[ unknown] (1)  Jaume Casado Ruiz (minterior) <minterior@gmail.com>
[ unknown] (2). Jaume Casado Ruiz (unAplauso.com) <jcasado@unaplauso.com>

Ordre>quit
Save changes? (y/N) y

Si després volem enviar la nova informació a un servidor de claus, per exemple a pgp.mit.edu:

gpg --keyserver 'pgp.mit.edu' --send-keys 0x5600e9c7f71b3570

La clau la podem expressar amb el seu finger print, com he fet jo, o amb el seu ID. Per obtenir el finger print:

gpg --fingerprint

Estava cercant com copiar un enllaç simbòlic des de la lína de comandes. Pensava que amb l’ordre cp i algun paràmetre de l’estil –link (o -l) es podria fer. Amb “cp -l” aconseguim enllaçar els fitxers en lloc de copiar-los, però no és el que vull ara. He trobat com fer-ho, és així:

cd directori
find nom_del_link_a_copiar | cpio -pmadv directori_destí

Si el directori de destí no existeix es crearà. Es copiarà l’enllaç simbòlic amb el mateix nom dins el directori de destí.

Si volem copiar l’enllaç simbòlic al mateix directori però amb un altre nom, sempre podem crear-lo en un lloc temporal i després moure’l:

cd directori
find nom_del_link_a_copiar | cpio -pmadv /tmp
mv /tmp/nom_del_link_a_copiar ./nou_nom

Cal tenir en compte que els enllaços simbòlics relatius poden trencar-se. Això vol dir que si no es troben en directoris del mateix nivell, el nou enllaç no apuntarà correctament al seu destí.

Si volem substituir una cadena de caràcters per una altra en un fitxer o en múltiples fitxers simultàniament i de forma recursiva¹ ho podem fer amb aquesta comanda:

find -type f -exec sed -i 's/CADENA A SUBSTITUIR/CADENA NOVA/g' {} \;

On CADENA A SUBSTITUIR és una expressió regular. Això vol dir que hem d’escapar els caràcters amb connotacions especials amb una barra invertida \, com . + * [ ] etcètera.

També cal tenir en compte que això substituirà totes les aparicions de la cadena a substituir que es trobin per tots els fitxers. Si volem que només s’apliqui a certs fitxers, podem utilitzar el paràmetre -name de la comanda find.

Si combinem el que he dit als dos paràgrafs anteriors, per exemple la comanda:

find -type f -name aliments* -exec sed -i 's/pebrot (vermell)/maduixa vermella/g' {} \;

cercarà només en fitxers els noms dels quals comencin per aliments,  i substituirà pebrot (vermell) per maduixa vermella.

Ho podem complicar més, i aprofitar la paraula vermell de la cadena inicial i afegir-li la lletra a per fer-la femenina: vermella, tot amb expressions regulars:

find -type f -name aliments* -exec sed -i 's/\(pebrot (\)\(vermell\))/maduixa \2a/g' {} \;

Aquesta expressió crea dos grups: el primer conté “pebrot (” i el segon “vermell” (el darrer parèntesi queda fora de cap grup). Així podem usar la seqüència \2 per referir-nos al contingut del segon grup, al qual li afegim la lletra a per transformar-lo en “vermella”.

sed -i 's/CADENA A SUBSTITUIR/CADENA NOVA/g' fitxer1 *.txt

Si recentment escrivia l’entrada sobre la comanda find amb la possibilitat de fer diferents cerques simultànies, avui explico un cas on ho he usat.

Alguna vegada haureu vist en fitxers amb codi font (siguin del llenguatge de programació que siguin), que a la part superior apareix informació sobre què conté el fitxer, la seva llicència, o l’autor, la data i el número de revisió dels darrers canvis que ha patit el fitxer en qüestió. En referència a aquestes tres darreres em refereixo a una línia d’aquest estil:

$Id: codi.php 148 2006-07-28 21:30:43Z jaume $

Evidentment aquestes dades no són escrites a mà per l’autor cada vegada que fa un canvi al fitxer (una nova revisió), sinó que es realitza automàticament; i concretament aquest és el format que utilitza subversion per la variable Id. En realitat jo havia escrit $Id$ allà on he volgut del fitxer anomenat codi.php, i en fer el commit al dipòsit el sistema ho ha substituït per la línia completa que veieu a dalt. Id és una combinació reduïda de les paraules clau $Author$, $Revision$ i $Date$, que també podeu utilitzar de forma independent. Al manual de subversion (en anglès) podeu llegir més al respecte. Si volem que tots els fitxers del nostre projecte que tinguem al sistema de control de versions subversion incorporin aquesta funcionalitat, hem de configurar el servidor de certa manera. Editem el fitxer /etc/subversion/config (aquest és el camí a Ubuntu, però serà similar a altres distribucions). Per defecte enable-auto-props està comentat, ho deixem així:

### Set enable-auto-props to 'yes' to enable automatic properties
### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-auto-props = yes

I una mica més avall editem les propietats automàtiques:

### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
###   file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?').  All entries which match (case-insensitively) will be
### applied to the file.  Note that auto-props functionality
### must be enabled, which is typically done by setting the
### 'enable-auto-props' option.
*.php = svn:eol-style=native;svn:keywords=Author Date Id Revision
*.txt = svn:eol-style=native;svn:keywords=Author Date Id Revision
*.sh  = svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable
*.tpl = svn:eol-style=native
*.css = svn:eol-style=native
*.js  = svn:eol-style=native
*.htm = svn:eol-style=native
*.html = svn:eol-style=native
*.htaccess = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.gif = svn:mime-type=image/gif

Jo he definit que només els fitxers amb l’extensió php, txt i sh tinguin la capacitat de substitució de paraules clau. A més a més els .sh vull que siguin executables (de manera que si algú fa un check out el propi subversion s’encarregui de marcar el bit d’execució per nosaltres). I si us hi fixeu, la resta de fitxers de text tenen una altra propietat: svn:eol-style=native. Això fa referència al final de línia (en anglès, eol = end of line), i serveix per què vàries persones treballin sobre els mateixos fitxers en sistemes operatius diferents (els quals usen diferents caràcters per indicar el final de línia). Les tres darreres línies són pels fitxers d’imatge, cadascun amb el seu tipus mime corresponent.

Un cop fet això, ens assegurem que els fitxers nous que agreguem al dipòsit tindran aquestes propietats, però què passa amb els fitxers existents? Cal que els donem les propietats nosaltres manualment, i aquí entra la potència de la comanda find. I si ho podem fer tot d’una sola passada millor Ens situem al directori arrel del nostre projecte i executem:

find . \
\( -name '*.php' -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; \) , \
\( -name '*.txt' -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; \) , \
\( -name '*.sh'  -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; -exec svn propset svn:executable {} \; \) , \
\( -name '*.tpl' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '*.css' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '*.js' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '*.htm' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '*.html' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '.htaccess' -exec svn propset svn:eol-style native {} \; \) , \
\( -name '*.png' -exec svn propset svn:mime-type 'image/png' {} \; \) , \
\( -name '*.jpg' -exec svn propset svn:mime-type 'image/jpeg' {} \; \) , \
\( -name '*.gif' -exec svn propset svn:mime-type 'image/gif' {} \; \) > /dev/null

I això és tot, a programar de gust!

Fins ara, sempre que havia de cercar diferents tipus de fitxers i/o directoris amb la comanda find, executava una comanda de forma independent per a cada cosa. Però això no és gens òptim, perquè cerquem una i altra vegada per tots els fitxers desitjats. Fa uns dies vaig aprendre com cercar vàries coses alhora, en una sola cerca, de manera que se li puguin indicar a find diferents patrons. Aquí mostro l’exemple que apareix al manual (que es pot accedir amb la comanda: man find), escrit en multilínia per fer-lo més entenidor (recordo també que per canviar de línia a la shell abans de pitjar la tecla retorn o enter cal acabar la línia amb un espai i una barra invertida \):

find / \
\( -perm -4000 -fprintf /root/suid.txt %#m %u %p\n \) , \
\( -size +100M -fprintf /root/big.txt %-10s %p\n \)

Recorre el sistema una única vegada, llistant fitxers i directoris amb setuid al fitxer /root/suid.txt i fitxers grans (majors de 100 MB) al fitxer /root/big.txt.

Un exemple més fàcil d’entendre:

find . \
\( -name '*.php' -exec echo "Trobat fitxer PHP:" {} \; \) , \
\( -name '*.exe' -exec rm -f {} \; -exec echo "Eliminat fitxer .exe:" {} \; \) , \
\( -name '*.txt' -exec ls -l {} \; \)

Al primer patró busquem els fitxers el nom dels quals acabi amb ‘.php’ i mostrem una frase per la sortida estàndard, al segon eliminem fitxers ‘.exe’ i informem de l’acció, i al tercer llistem informació de fitxers ‘.txt’ en un format llarg.

Podeu veure que a més a més es poden executar vàries comandes per cada patró de cerca. En el segon patró, executem dues comandes amb l’opció -exec: la primera per eliminar els fitxers trobats i la segona per informar què hem fet.

Bon profit.