Ahir estava clonant un disc al servidor de fitxers de l’empresa amb Clonezilla, o sigui, treballant offline. És un disc d’1TB, però deu estar ple a un 20%, així que vaig pensar que el podria clonar a mig matí sense massa problemes. Quan me’n vaig adonar que el temps estimat era de l’ordre de 18 hores, vaig decidir interrompre la operació, i reiniciar el sistema. Vaig pensar que no tindria cap problema, ja que el disc d’origen simplement estava sent llegit, i el de destinació l’havia de tornar a clonar sencer, així que vaig interrompre “a la brava” i vaig reiniciar… Sorpresa! El sistema no volia iniciar… El sistema tota la estona em deia que no trobava l’init.

Després d’uns instants de pànic, de reiniciar i assegurar-me que estava fent servir el disc original, vaig decidir desconnectar-lo i el sistema va iniciar.

Avui, pensant, he arribat a la conclusió del motiu: el disc està amb LVM2, i al clonar-lo també es van clonar totes les estructures de LVM2, tot i que les dades del disc no estaven clonades. Quan el sistema va iniciar, va trobar dos discs durs amb UIDs de LVM2 idèntics, i va donar preferència al segon disc, que era el que no tenia dades. Resultat: no trobava la partició de root. Misteri resolt!

L’altre dia vaig rebre un avís d’Una-al-dia, butlletí al qual hi estic subscrit. Aquest es titulava Ejecución remota de código en impresoras multifunción Xerox, i ens explica una vulnerabilitat a aquest dispositiu degut a una vulnerabilitat a Samba, la implementació Open Source del protocol de compartició de fitxers i impressores de Windows.

El cas és que, pensant-ho, el fet de que els dispositius embedded facin servir Linux, o altres paquets Open Source, te una part bona i una dolenta. La part bona és el fet que fa servir codi lliure, tenint un producte de qualitat a un preu més ajustat, i a més per els que ens ve de gust normalment ens permet hackejar el dispositiu. La part dolenta és que quan es detecta un problema amb aquest software Open Source, aquest també afecta (normalment) a la plataforma embedded, i pot permetre desenvolupar exploits contra aquesta, obligant als usuaris i administradors a tenir en compte un dispositiu més a l’hora de pensar amb els pedaços (patch) de seguretat. Si, és clar, amb els firmwares de codi tancat també passa, però amb l’avantatge que cal un atac específic contra aquest firmware, no val traslladar un atac d’una plataforma més utilitzada al dispositiu sense més. És com la biodiversitat, quan més gran més resistent és un ecosistema a les plagues i enfermetats.

Fa un temps em van regalar un EeePC, i fent proves un dia vaig voler accedir a un terminal virtual. Faig la combinació estàndard Ctrl-Alt-F1 i… res. Un moment, res!? Doncs si. El cas és que buscant una mica vaig trobar el següent a uns foros (en anglès), que passo a traduir-ho al català:

1. Cal activar la opció DontVTSwitch al fitxer xorg.conf (/etc/X11/XOrg.conf, crec, ara ho dic de memòria)
2. Reiniciar les X (Ctrl-Alt-Borrar, NO Ctrl-Alt-Suprimir!). Compte perquè això ens mata totes les aplicacions que tinguem actives. També podem reiniciar l’EeePC…
3. Per accedir al terminal virtual fer Ctrl-Alt-F3. Compte al fer “exit”, ja que no ens torna a apareixer el prompt de login de nou (no es fa respawn).
4. Per retornar a les X Ctrl-Alt-F2.

Això que sigui el terminal virtual 3 és degut a que la Xandros de l’EeePC no fa servir l’init normal, si no que fa servir el fastinit, un init que han fet els d’Asus (crec). Com a alternativa tenim el finit (on també tenim informació de com funciona el fastinit, ja que l’emula), però d’això parlaré un altre dia…