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 »

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.

No sé si hi ha alguna incompatibilitat entre els plugins RB Internal Linker i Ozh’ Admin Drop Down Menu de WordPress, però ahir vaig actualitzar el primer a la versió 2.0.11 i ara està fallant. El problema l’he detectat amb Firebug (quina eina més meravellosa!), que mostrava el següent error de javascript:

syntax error
var oam_toomanypluygins = ;\n

He cercat directament al directori de plugins quin fitxer contenia aquest nom de variable, des d’una connexió ssh al servidor, així:

egrep -r oam_toomanypluygins *

Han sortit tres resultats. El problema es troba al fitxer ozh-admin-drop-down-menu/inc/core.php, a la funció en llenguatge PHP wp_ozh_adminmenu_js().
A la línia:

$toomanyplugins = $wp_ozh_adminmenu['too_many_plugins'];

veiem que la variable PHP $toomanyplugins és assignada i més endavant inserida directament entre codi javascript. Ràpidament ens podem adonar que si la variable és buida s’introduïrà un error al codi javascript perquè faltarà algun valor entre els caràcters = i ;

var oam_toomanypluygins = ;

Per resoldre-ho, després de la línia PHP anteriorment esmentada he afegit:

if (empty($toomanyplugins)) {
    $defaults = wp_ozh_adminmenu_defaults();
    $toomanyplugins = $defaults['too_many_plugins'];
}

D’aquesta manera comprovem si la variable és buida i li donem el valor per defecte abans d’inserir-la entre codi javascript.

Resolt!

Actualització (01-03-2010): a vegades les coses serveixen per més persones, per això és bo compartir. El desenvolupador del plugin m’ha contestat:

Hello Jaume
Nice catch, thanks for this! I’ve updated the plugin to deal with this case
Cheers,
Ozh

Primer de tot, per aquells qui no sapigueu de què parlo, us poso la definició de Pagerank de la Viquipèdia:

PageRank és l’algorisme que utilitza Google per determinar la posició d’una pàgina web a l’hora de fer una consulta mitjançant el seu motor de cerca. Aquest mètode mesura el seu grau d’importància de forma numèrica i permet situar els resultats més fiables en primer lloc. Alhora, reflecteix la probabilitat que hi ha de que un usuari que navega a través d’enllaços de forma aleatòria arribi a una pàgina web concreta.

Doncs bé, he trobat un script en el llenguatge de programació PHP que permet obtenir el Pagerank . L’he transformat en una classe i aquí el teniu…

Avui he compilat el programa ffmpeg per habilitar el suport de mp3 i amr amb el gcc 4.4.1. El que ve per defecte a Kubuntu no inclou aquests còdecs perquè no són lliures. Després de baixar el seu codi font primer he hagut d’instal·lar alguns paquets extres tot teclejant a la consola:

sudo apt-get install libmp3lame-dev libamrnb-dev libamrwb-dev

I a continuació:

./configure --extra-version=4:0.5+svn2010122-jau --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --extra-cflags=-I/build/buildd/ffmpeg-0.5+svn2010122-jau/debian/include --enable-shared --disable-static --disable-mmx --enable-nonfree --enable-libamr-nb --enable-libamr-wb  --enable-libmp3lame --enable-libxvid --enable-libx264

make

Com podeu veure he aprofitat per incloure el còdec xvid. I ja tinc la versió: FFmpeg 0.5-4:0.5+svn2010122-jau

El tema per a WordPress Mandingo té la funcionalitat de poder excloure certes pàgines del menú superior; aquestes es poden configurar des de l’administrador, a la secció del tema. El que no permet és triar quines en volem incloure al menú. Per no haver de marcar cada nova pàgina que creem, i evitar així que aparegui al menú superior, podem fer un petit canvi de funcionalitat: en lloc de marcar les que no volem, marcarem les que sí que volem.

A més a més hem de fer un petit canvi al codi font del tema. Editem el fitxer:

themes/mandigo/header.php

Busquem la crida a la funció PHP:

wp_list_pages

I a la línia

'exclude' => @implode(',', $mandigo_options['header_navigation_exclude_pages']),

canviem ‘exclude’ per ‘include‘. Desem el fitxer i ja hem acabat.

D’aquesta manera, només haurem de treballar quan vulguem modificar el menú superior, i no sempre que creem pàgines noves