• Tag Archives com es fa
  • Instal·lació de xdebug per PHP i Apache2 a Ubuntu

    Un dels principals defectes de la majoria de programadors de PHP és oblidar-se de les eines de depuració (debugger). Tots hem estat en feines on no disposaven d’aquestes eines a la nostra màquina, o no permetien la seva instal·lació, o senzillament no hem pensat en posar-les.

    Jo vaig començar el meu primer contacte amb la programació amb el llenguatge c. Llavors a la universitat ens feien usar el programa Microsoft Visual Studio, amb el qual podíem compilar i depurar (debug). La depuració ens permetia seguir el programa pas a pas i saber el valor de cada variable en cada moment, i corregir així errors existents que s’escapaven a simple vista i que no eren de sintaxi.

    En passar a PHP, penso que és més difícil entendre com funciona la depuració, pel fet de tenir el navegador per un costat i l’entorn integrat de desenvolupament (o IDE de l’acrònim en anglès) per un altre. Tanmateix, cal instal·lar prèviament alguna cosa al servidor per poder-li indicar des del nostre IDE l’ordre d’aturar-se a la línia de codi que nosaltres vulguem. Per aquest conjunt de factors la majoria de programadors prescindeixen del depurador com a tal i utilitzen el mètode de prova i error, i miren el valor de les variables enviant el seu valor directament al navegador. Les tres funcions de PHP més utilitzades per fer això són: echo, print_r i var_dump.

    Jo he passat força temps utilitzant-les també, però quan tornes a la depuració t’adones que abans estaves perdent el temps. Amb aquest rudimentari mètode, si no coneixes molt bé el codi, primer has de trobar el punt on està la variable que vols observar, teclejar el codi que mostri el seu valor i executar la consulta de la pàgina des del navegador. Molt bé, ja has vist el seu contingut, però com ha estat calculat? Com s’ha arribat fins aquí, a través de quins fitxers, mètodes o funcions? La majoria de vegades has de tornar a escriure més codi per mostrar altres variables, perquè l’anterior no t’ha servit de massa, i tornar a actualitzar el navegador. A més a més, després cal eliminar tot aquest codi extra que has creat només per mirar el valor d’algunes de les variables. I quantes vegades passa -a mi també- que acaba pujant a producció codi amb aquestes sentències de “depuració”?

    Per evitar tot això, el millor és usar un depurador de veritat. Encara que al principi perdem una mica de temps per configurar-lo i aprendre com funciona, després ens estalviarà molt temps i mal de caps. Jo per desenvolupar en PHP i MySQL utilitzo el servidor web Apache2 sobre Ubuntu; una solució LAMP vaja. I com a IDE l’Eclipse amb el PDT (PHP Development Tools) i alguns altres plugins.

    Amb els següents passos podreu instal·lar xdebug amb l’Apache2 i PHP:

    sudo apt-get install php5-xdebug

    Això ha instal·lat el paquet corresponent i ha creat el fitxer /etc/php5/conf.d/xdebug.ini amb aquest contingut:

    zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so

    Si ara comprovem el resultat de cridar a phpinfo(), veurem:

    This program makes use of the Zend Scripting Language Engine:
    Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
        with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans

    Al mateix fitxer xdebug.ini hem d’afegir aquestes línies:

    xdebug.remote_enable=on
    xdebug.remote_handler=dbgp
    xdebug.remote_mode=req
    xdebug.remote_host=localhost
    xdebug.remote_port=9000
    

    I ja per acabar, carreguem els canvis de configuració a l’Apache:

    sudo /etc/init.d/apache2 reload

    En un altre capítol escriuré com configurar l’Eclipse per depurar des d’allà.

    Gràcies Derick pel fantàstic xdebug!

    GD Star Rating
    loading...

  • Com usar paquets d’una versió anterior d’Ubuntu

    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
    GD Star Rating
    loading...

  • Com trobar els UUIDs de les particions a Ubuntu

    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.

    GD Star Rating
    loading...

  • Comprovar sectors danyats d’un disc dur amb badblocks

    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! 😉

    GD Star Rating
    loading...

  • GNU ddrescue per recuperar dades de discs durs

    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–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:
    Continue reading  Post ID 343

    GD Star Rating
    loading...

  • Com copiar un enllaç simbòlic a GNU/Linux

    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í.

    GD Star Rating
    loading...

  • Substituir text en múltiples fitxers amb sed

    Si volem substituir una cadena de caràcters per una altra en un fitxer o en múltiples fitxers simultàniament i de forma recursiva1 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”.

    1 Si volem fer-ho en un sol fitxer o en varis sense necessitar la recursivitat no cal usar find, podem usar sed directament:

    sed -i 's/CADENA A SUBSTITUIR/CADENA NOVA/g' fitxer1 *.txt
    GD Star Rating
    loading...

  • Actualitzar automàticament la revisió/data/autor en fer commit a subversion

    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! 😉

    GD Star Rating
    loading...

  • Cerca amb la comanda find de GNU/Linux

    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.

    GD Star Rating
    loading...

  • Error javascript provocat pel plugin Ozh’ Admin Drop Down Menu de WordPress

    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

    GD Star Rating
    loading...