Aquest post va dedica al Marc. Finalment i quan ja no ho buscava he trobat el que buscava aquest matí. Com en un sol apt-get puc instal·lar el indispensable per poder compilar coses en una ubuntu recent instal·lada:
apt-get install linux-headers-`uname -r` build-essential
El sistema operatiu de treball o sistema operatiu de l’equip host que uso habitualment com ja sabeu és un Linux, concretament una Gentoo. Doncs bé, al instal·lar un WinXP com a sistema guest en una màquina virtual d’VMWare malgrat molts dels dispositius USB del meu portàtil es reconeixen directament. Per exemple, la webcam, lector d’empremta digital o modem 3G intern. Això no passa al connectar algún dels dos smartphones que tinc el HTC Kaiser o l’Artemis el VMWare em donava l’error: VMWare Workstation was unable to claim the device (No such file or directory).
<div class="imatge" style="text-align: center;"></div>Després de molt buscar per forums i d’altres similars vaig trobar un simple hack que em soluciona el problema (perdoneu però no recordo l’enllaç perquè era un comentari d’un forum). El motiu exacte de perquè això passa no l’acabo de tenir clar però l’enginy funciona. De forma que l’activesync o el pocket controller pro reconeixen perfectament el telèfon i em permeten controlar-lo i sincronitzar-lo des del WinXP virtual. Que per altre banda, tal com vaig comentar en l’article sobre com arrancar el WinXP de l’altre partició mentre estem en Linux em permet no haver de mantenir dos instal·lacions de WinXP en parl·lel sinó que la versió virtual i la que corre sobre el host son la mateixa.
Bé doncs, anem al gra el que heu de fer és localitzar on teniu connectat el vostre dispositiu. Fent un lsusb podeu veure algo semblant a:
# lsusb
...
Bus 005 Device 004: ID 0bb4:0b0b High Tech Computer Corp.
...
Ara ja sabem que es troba en el Bus 5 però encara no sabem en quin port ni a quina PCI esta connectat aquest bus. Desocbrim ID de la PCI on és el Busc 5:
# find /sys/devices/ -name "usb5"
/sys/devices/pci0000:00/0000:00:1d.0/usb5
Ja sabem la PCI i bus USB on és connectat el dispositiu, ara només cal saber en quin port usa. Per fer això el que farem és buscar el idProduct i l’idVendor del HTC Kaiser, això ho obtenim del lsusb són els números en hexadecimal separats per uns dos punts. Així doncs, el meu idProduct: 0b0b i el idVendor: 0bb4. Amb aquestes dades el que faig és posar-nos en el directori del bus que hem localitzat i llenço una búsqueda sobre els fitxers que contenen aquestes dades per localitzar en quin port del bus tenim connectat el dispositiu:
# cd /sys/devices/pci0000:00/0000:00:1d.0/usb5
# grep -ri 0b0b $(find . -name "idProduct")
./5-1/idProduct:0b0b
# grep -ri 0bb4 $(find . -name "idVendor")
./5-1/idVendor:0bb4
Com podem veure en els dos casos els fitxers que contenen aquesta informació són al directori 5-1, o sigui, que tenim connectat el nostre telèfon a /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1/. Directori on hi trobarem el fitxer bConfigurationValue que és completament buit. Doncs bé, l’únic que hem de fer és posar-hi un 1, per exemple així:
# echo 1 > /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1/bConfigurationValue
Després ens assegurem que tenim associat el dispositiu a la màquina virtual i veurem que el missatge d’error desapareix i el WinXP detecta el nou hardware connectat.
<div class="imatge" style="text-align: center;"></div>Finalment aquí tenim l’enllaç funcionant:
<div class="imatge" style="text-align: center;"></div>Reading time: 2 – 4 minutes
Aquesta funcionalitat d’Evolution fa molt temps que la vaig veure, però no se m’havia mai acudit com treure-li rendiment amb la meva forma d’usar el correu. Com sabeu de fa molt de temps tinc les carpetes organitzades intentant seguir la idea de GTD. Doncs bé, malgrat això tenia certs problemes per seguir alguns llistes de correu i d’altres informacions que m’arriben al correu però que són de caire més secundari o personal. La solució l’he trobat gràcies a aquestes carpetes tan especials que em permeten agrupar correus en funcionar de paràmetres ben diferents.
Per si això de les search folders ni ús sona, jo ho definiria com carpetes amb continguts virtuals, és a dir, imagineu que teniu configurades diverses comptes de correu, llavors tindreu divers carpetes d’entrada de correu (inbox) si a més cada una de les comptes té diverses carpetes creades això farà que els diversos inbox no capiguen a la pantalla. Llavors sempre haureu d’estar fent scroll per estar al corrent dels nous correus que ús entren en les diverses comptes i diverses carpetes de cada compte.
Llista de carpetes de tipus search folder:
La solució és tan senzilla com la de configurar, per exemple, un general inbox:
Un altre search folder que tinc configurada és una que m’agrupa tots els missatges que tinc marcats com a importants, això ho acostumo a usar moltíssim per varies funcions. Per exemple, contestar correus en llistes de correu, saber tasques importants que esperant que es facin ja, o coses importants que espero que arribin fetes, etc.
A més d’aquests dos exemples que he comentat tinc ues quantes carpetes més d’aquest tipus, com la de missatges no llegits, tasques a fer, tasques en espera, etc. a mi aquesta idea realment m’ha canviat la forma d’usar Evolution.
No oblideu que els missatges realment, no tenen perquè pertanyer a la mateix compte de correu i que la carpeta virtual no és una carpeta real. Així doncs, no s’hi poden arrossegar elements a dintre. De totes formes, si que es poden arrossegar correus de dintre cap a un altre carpeta, no virtual. Així doncs el focus de treball del meu Evolution ha canviat molt i ara treballo sempre amb la vista posada a la part on hi ha aquestes carpetes especials i a sobre tinc obertes totes les carpetes de la compte de correu principal. Així puc anar arrossegant i organitzant les tasques tal com feia abans.
La base del MPK és una Ubuntu 6.06 Dapper, doncs bé ahir vaig tenir la necessitat de configurar-hi una targeta Wifi per primera vegada. La qüestió és que la cosa em va donar una mica més de feina de la esperada. Així doncs, aquí penjo quatre notes de com posar-la en solfa ben ràpid.
Al iniciar l’Ubuntu amb l’Atheros punxada els drivers de madwifi del kernel la detecten perfectament però malgrat no em donava cap error i després d’associar-me a diversos APs amb WEP i WPA-PSK no hi havia manera d’intercanviar tràfic, sempre donava l’error de que no trobava el destí del paquet. Finalment el que vaig fer va ser descarregar els drivers de madwifi, concretament la versió 0.9.3.3. Que ha compilat sense problemes i després de borrar els drivers que inclou l’Ubuntu per defecte, s’han instal·lat a la carpeta dels mòduls del kernel. Després de comprobar que amb un depmod -a no donen cap error he reiniciat i la targeta s’ha detectat sense problemes.
Amb les següents simples comandes:
iwconfig ath0 essid ssid_ap
iwconfig ath0 key codi_wep_en_hexadecimal
ifconfig ath0 up
dhclient ath0
Només amb això ja esta llesta la xarxa wifi per funcionar amb xifrat WEP, obviament no ús el recomano però hi ha gent que encara viu enganyada confiant-hi. En cas de voler-la configurar per WPA-PSK la cosa és tan senzilla com crear el següent fitxer /etc/wpa_supplicant.conf:
network={
ssid="ssid_ap"
scan_ssid=1
proto=WPA
key_mgmt=WPA-PSK
psk="clau_psk"
}
Després des de la línia de comandes podem cridar el wpa_supplicant per provar-lo així:
wpa_supplicant -Dwext -iath0 -c/etc/wpa_supplicant.conf
Un cop veiem que s’ha associat podem anar a una altre consola i configurar la interficie de xarxa. Com sempre amb la comanda iwconfig podem observar si l’associació s’ha fet correctament, entre d’altres dades com el nivell de senyal.
Finalment si voleu posar en la seqüència d’arrencada la crida del wpa_supplicant podem afegir el següent a /etc/network/interfaces:
auto ath0
iface ath0 inet dhcp
pre-up wpa_supplicant -Bw -Dwext -iath0 -c/etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant
Per automatitzar el WEP, el que he fet malgrat sigui una mica xapussa és fer un script que fa les dues comandes iwconfig i aquest script es crida a pre-up al fitxer /etc/network/interfaces.
Aquesta setmana he clonat un sistema montat en Ubuntu, d’una màquina real a una màquina virtal corrent dins d’un VMWare Server. La veritat pensava tenir més problemes, però finalment la cosa ha estatm és senzilla del que pensava. Intentearé explicar-vos els passos que he seguit, espero no deixar-me cap detall important ja que ho faré de memòria.
/proc
/sys
/dev
/mnt
/cdrom
/tmp
/etc/fstab
/etc/mtab
/boot
/etc/iftab
rsync -cavz --exclude-from=exclude.txt /* root@IP_NOVA_MAQUINA:/
Reading time: 1 – 2 minutes
Una eina senzilla i útil, a més programada totalment en shell script que encara té més merit. Servei per fer coses tan vistoses com un línia de progrés mentre fem un tar, cp, etc.
Una imatge val més que mil paraules…
És fàcil i vistosa, oi que si? en l’exemple es veu com descomprimeixo la pròpia eixa amb una barra de progrés generada per ella mateixa.
Doneu un cop d’ull a la web, a mi m’ha agradat molt l’eina i l’he usat per fer un CD d’instal·lació d’una eina de la feina. Per si la web deixés d’existir, que això ja passa amb aquest tipus d’eines deixo una còpia del programa a l’article: bar-1.4.tar.bz2.
Fa forces anys, vaig parlar del dnotify és una eina que ens permetia saber quan hi havia un canvi en els fitxers d’un directori, llavors aprofitabem per llençar un procés al produir-se l’event. Com que l’arquitectura interna del programa comentat no era massa bona (controlava els canvis a base de fer pooling) i degut a les millores dels nous kernel, s’ha aprofitat el concepte de l’inotify: inotify is a Linux kernel subsystem that provides file system event notification..
Així doncs, les inotify-tools són les eines que ens permeten usar aquesta funcionalitat del kernel des de l’espai d’aplicacions d’usuari. Realment un passada. Permeten vigilar un fitxer, per generar-ne estadístiques, llençar processos associats quan es detecti un determinat canvi en el fitxer, etc. Però potser la funcionalitat que més m’ha interessat és la de la llibreria que ofereix per programar aplicacions usant les funcionalitats de l’inotify.
Concretament aquestes llibreries són les necessaries per compilar el incron. Per mi l’aplicació final més genial de totes: es tracta d’un ‘inotify cron’. Bàsicament l’eina es composa de dues parts d’un dameon i d’una taula d’accions. Aquesta taula s’usa d’una forma semblant al servei de cron. La diferència és que els events no són senyals horaris, sinó captures d’evenets del sistema de fitxers.
Un exemple d’especte que pot tenir el incrontab -l:
/var/mail IN_CLOSE_WRITE abc $@/$#
Això captura l’event cada cop que s’hagi canviat un fitxer (IN_CLOSE_WRITE) dins del directori /var/mail, després llença el programa abc passant com a paràmetre el path/file_name. Com podeu veure la potència és infinita i la simplicitat d’ús és impressionant. Potser el que més m’agrada és el fàcil que és tenir centrilitzats tots els directoris que estic controlant i les accions associades. Per exemple, és ideal per mantenir un RSS de les novetats de música, video, descàrregues, etc.
Una xorrada molt útil si no t’agrada el nano que és l’editor per defecte que porta l’Ubuntu:
update-alternatives --config editor
Amb això podem escollir quin serà l’editor per defecte, simple i molt útil pels amants del vim com jo.
Fa temps que no escribia coses tècniques així que per anar fent boca aquí va un petit truquillo pel Subversion.
Si sou usuaris de línia de comandes del SVN quan esteu programant un projecte i no sabeu quins fitxers no heu pujat al repositori sabeu que podeu fer un:
svn status
I això ús mostra una llista dels fitxers que s’ha modificat i dels que no han estat afegits al repositori, doncs ara ve un petit script per afegir-los tots de cop:
for F in $(svn status | grep "?" | cut -c 8-);
do
svn add $F;
done
Ara ja podem fer un commit i no em d’anar recorrent tots els directoris i fitxers per afegir-los al repositori.
El gener passat vaig escriure sobre com arrencar un LiveCD d’Ubuntu en mode persistent, és a dir, guardant la configuració en un pendrive o disc dur de forma que els ajustos que fem a la configuració del CD no es perdin. Bé doncs, ara del que es tracta és que fem el mateix però sense el LiveCD. M’explico, l’objectiu és tenir una partició de només lectura al nostre disc dur, o en un altre disc dur on hi hagi el LiveCD copiat. Llavors usem una altre partició per guardar les modifiacions que fem sobre el CD, o sigui, la informació persistent. Això ens permet al propi GRUB tenir modes de recuperació sense haver de posar el CD. A més sempre podrem tornar enrera i tenir una configuració bàsica. I podrem treballar exactament igual que si tinguessim un LiveCD però sense tenir-lo físicament.
La solució és ben senzilla, potser el problema més greu esta en que s’ha de modificar un arxiu de configuració que es diu /scripts/casper i que es troba dintre del fitxer /boot-live/initrd.gz cosa que fa una mica entretingut modificar-lo. A continuació faig un petit cookbook de tots els passos a seguir.
default 0
timeout 30
hiddenmenu
color cyan/blue white/blue
# Calling LiveCD from hard drive
title mpti
root (hd0,0)
kernel /boot-live/vmlinuz boot=casper initrd=new-initrd.gz ramdisk_size=1048576 root=/dev/ram rw quiet splash vga=791 -- persistent
initrd /boot-live/new-initrd.gz
boot
# Calling LiveCD from hard drive in single user and persistent mode
title mpti persistent (recovery mode)
root (hd0,0)
kernel /boot-live/vmlinuz boot=casper initrd=initrd.gz ramdisk_size=1048576 root=/dev/ram ro single persistent
initrd /boot-live/new-initrd.gz
boot
# Calling LiveCD from hard drive without persistent and single user mode
title mpti w/o persistent (recovery mode)
root (hd0,0)
kernel /boot-live/vmlinuz boot=casper initrd=initrd.gz ramdisk_size=1048576 root=/dev/ram ro single
initrd /boot-live/new-initrd.gz
boot
mkdir new-initrd
cd new-initrd
gzip -dc /boot-live/new-initrd.gz | cpio -id
is_usb_device() {
# sysfs_path="${1#/sys}"
# if /lib/udev/path_id "${sysfs_path}" | grep -E -q "ID_PATH=(usb|pci-[^-]*-usb)"; then
return 0
# fi
# return 1
}
# Fem una còpia l'antic new-initrd.gz per si les mosques
cd /boot-live
cp new-initrd.gz new-initrd.gz.old
# Creem el nou new-initrd.gz
cd new-initrd
find . | cpio --quiet --dereference -o -H newc | gzip -9 > ../new-initrd.gz
cd ..
rm -rf new-initrd
Al fitxer casper és on es detecta si hi ha algún LiveCD posat a partir del qual es montarà el sistema de fitxers root. L’script busca a molts llocs si troba una unitat de CD, fins hi tot busca pendrives formatejats en vfat amb el contingut del CD, però abans d’intentar montar-los i buscar dintre seu el directori /casper i algún fitxer anomenat *.squashfs comproba que el dispositiu estigui connectat via USB.
Així doncs, la modificació que jo he fet només força que la comprobació d’USB sempre sigui certa, així també intentarà montar les pariticions dels possibles discs durs connectats o d’altres similars. Així doncs, després l’únic que faig és crear una partició vfat, crear-li el directori que busca i copiar el fitxer *.squashfs que és on hi ha el sistema de fitxers squashfs que conté l’arbre de directoris i fitxers del LiveCD.
Malgrat estic content en el resultat obtingut, m’hagués agradat aconseguir el mateix resultat sense haver de modificar els fitxers del initrd.gz ja que això fa que a l’actualitzar l’Ubuntu si hi ha modificacions en l’script casper hauré de mirar-me què ha canviat per actualitzar el meu sistema.