Lo hice y lo entendí

En la anterior entrada, Usando ntfsclone y dd para clonado por red con netcat, decía algo que no es cierto:

Sin embargo, mientras que la salida del ntfsclone nos dice qué porcentaje de la imagen lleva leído o escrito, el dd no dice absolutamente nada hasta que finaliza. Como clonar un disco de muchos Gigabytes puede ser una tarea bastante larga, puede ser muy útil introducir entre los comandos de la tubería un pv para saber por dónde va la copia.

Sor Zitroën (¡gracias!) ha sido tan amable de indicarme que sí que hay una forma de obtener estadísticas del trabajo que lleva hecho dd, y que está hasta documentado en la página de man de dd:

Sending a USR1 signal to a running `dd' process makes it print I/O statistics to  standard
error and then resume copying.
 
       $ dd if=/dev/zero of=/dev/null& pid=$!
       $ kill -USR1 $pid; sleep 1; kill $pid
 
       18335302+0  records  in  18335302+0  records  out 9387674624 bytes (9.4 GB) copied,
       34.6279 seconds, 271 MB/s

Podría haber añadido esta nota como corrección a la anterior entrada, pero me ha gustado tanto, es una funcionalidad tan interesante y hasta ahora desconocida para mí, que he pensado que tiene entidad propia para comentarlo de forma separada.

Así, si estamos haciendo clonando un disco a través de la red, como veíamos previamente:

sisdest $ sudo nc -lp 2222 | dd of=/dev/hda

sisorig $ sudo dd if=/dev/hda | nc -q 0 sisdest 2222

En otro terminal (en cada una de las máquinas) podemos hacer un “ps -ef | grep dd” para buscar el PID del proceso y luego, al hacer el kill, en el terminal donde habíamos lanzado el dd, encontraremos, en la salida de error, las estadísticas del trabajo hecho hasta el momento por dd:

sisdest # ps -ef | grep dd
root     23772 23745  5 19:24 pts/1    00:00:01 dd of /dev/hda
sisorig # kill -USR1 23772
sisorig # kill -USR1 23772

sisorig # ps -ef | grep dd
root     34675 24619 28 11:23 pts/1    00:00:05 dd if /dev/hda
sisdest # kill -USR1 34675
sisdest # kill -USR1 34675

sisdest # nc -lp 2222 | dd of=/dev/hda
340522+0 records in
340522+0 records out
174347264 bytes (174 MB) copied, 21.9449 seconds, 7.9 MB/s
363920+0 records in
363920+0 records out
186327040 bytes (186 MB) copied, 23.4599 seconds, 7.9 MB/s

sisorig # dd if=/dev/hda | nc -q 0 sisdest 2222
242172+0 records in
242172+0 records out
123992064 bytes (124 MB) copied, 17.1812 seconds, 7.2 MB/s
270881+0 records in
270881+0 records out
138691072 bytes (139 MB) copied, 19.0057 seconds, 7.3 MB/s

Y una vez más vemos que los sistemas UNIX, día tras día, aún tienen la capacidad de sorprendernos con esas pequeñas funcionalidades medio ocultas que están siempre a la espera de que las descubramos.

:wq

Siguiendo con la entrada Alternativas al Ghost para crear imágenes de NTFS en Linux: Partimage y ntfsclone, veamos ahora cómo usar el ntfsclone y el dd para crear imágenes con ntfsclone de particiones en sistemas en los que no tenemos sitio para almacenarlas o para clonar discos completos con dd directamente a través de la red sin necesidad de crear un fichero de imagen intermedio.

Imaginemos, para empezar, el caso de que queremos hacer una imagen de una de las particiones NTFS de nuestro sistema. Puede ser para su posterior recuperación o puede ser para usar esa imagen con otros sistemas (y, por tanto, clonar el actual). Pero, desafortunadamente, no tenemos espacio en otra partición del sistema para almacenar el fichero de imagen localmente tal y como hacíamos en Alternativas al Ghost para crear imágenes de NTFS en Linux: Partimage y ntfsclone.

Si vamos a usar Partimage, no vamos a tener ningún problema para escribir la imagen remotamente, ya que es precisamente una de sus funcionalidades: la posibilidad de tener un servidor de imágenes de Partimage donde podemos escribir todas las imágenes de nuestros sistemas a través de la red.

Centrémonos, por tanto, en el ntfsclone, y en cómo usarlo a través de la red. La propia página de man del ntfsclone nos sugiere cómo hacerlo a través de SSH:

Backup an NTFS volume to a remote host, using ssh. Please note, that ssh may ask for a password!

    ntfsclone --save-image --output - /dev/hda1 | \\
    gzip -c | ssh host 'cat > backup.img.gz'

Restore an NTFS volume from a remote host via ssh. Please note, that ssh may ask for a password!

    ssh host 'cat backup.img.gz' | gunzip -c | \\
    ntfsclone --restore-image --overwrite /dev/hda1 -

Sin embargo, a mí me gusta más usar netcat para este propósito. netcat se autodenomina “la navaja suiza de TCP/IP”, y es verdad que lo es. De las varias implementaciones existentes, si usamos la original (cuyo autor es *Hobbit*) y leemos su README (en Debian/Ubuntu en /usr/share/doc/netcat-traditional/README.gz), veremos unos pocos ejemplos de sus posibilidades, suficientes para sorprendernos de la enorme versatilidad de esta herramienta.

Sigue leyendo »

Hay que reconocer que VMWare resulta bastante más cómodo que VirtualBox a la hora de usar interfaces en el sistema guest conectados directamente al interfaz de red del sistema host (es decir, no mediante NAT ni mediante una red privada entre el guest y el host). Mientras que con una instalación estándar de VMWare Server en Linux ya puedes usar un interfaz así en el asistente de configuración, con VirtualBox, no podemos hacerlo sin usar interfaces bridge e interfaces TAP. A cambio, dispondremos de más versatilidad a la hora de configurar la red.

El manual de VirtualBox denomina a esta forma de configurar la red entre el guest y el host Host Interface Networking (HIF). En su sección “6.8 Host Interface Networking and bridging on Linux hosts“, “6.8.1.1 Debian and Ubuntu hosts“, el manual nos detalla cómo conseguir configurar el sistema host para que el sistema guest pueda acceder a sus interfaces. Básicamente, los comandos que nos propone ejecutar en el host son:

1. sudo apt-get install bridge-utils

2. Añadir al fichero /etc/network/interfaces:

auto br0
   iface br0 inet dhcp
   bridge_ports eth0

3. sudo /etc/init.d/networking restart

4. sudo VBoxAddIF vbox0 <user> br0

Bueno, pues haciendo eso, lo que conseguiremos será perder la conectividad en el host y no tendremos red ni en el sistema real ni en el virtual.

Como sí que nos explica bien el manual de Ubuntu de VirtualBox en su sección de networking, sólo falta un detalle para que todo funcione bien, y es especificar que el interfaz real del sistema host lo pongamos a manual en el fichero /etc/network/interfaces, no a automático, que es lo que normalmente se tiene por defecto:

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
   bridge_ports eth0

Haciendo esto, sí que nos funcionará bien la red en el sistema real y en el virtual.

Pero, ¿de qué va todo esto? ¿Qué es el interfaz br0? ¿Y en qué consiste el interfaz vbox0?

Sigue leyendo »

En la mayoría de los casos, un usuario de Linux rara vez necesitará enfrentarse a la instalación manual de GRUB, el gestor de arranque más común para Linux, ya que en el momento de la instalación de su distribución favorita, ésta lo hará por él. En muchos casos, puede ser suficiente para el usuario medio saber cómo editar el fichero /boot/grub/menu.lst para modificar las entradas del menú de arranque de acuerdo a sus necesidades. Sin embargo, sigue habiendo casos en los que necesitaremos hacer esta instalación manualmente.

Por ejemplo, en entradas anteriores vimos cómo instalar manualmente GRUB en una memoria USB para poder arrancar múltiples sistemas operativos desde ella:

• Arrancar Linux, Windows y MS-DOS de una memoria USB
• Arrancar MS-DOS desde una memoria USB

También vimos cómo, en caso de estar trabajando sobre un fakeRAID, el instalador de la distribución no es capaz de instalar GRUB con éxito, teniendo que hacerlo nosotros mismos manualmente:

• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID

Esta entrada pretende resumir las diferentes técnicas que ya habíamos visto previamente en un único documento que sirva de referencia, así como dar algunos detalles adicionales sobre el funcionamiento interno de GRUB. Por supuesto, toda esta información ya existe, como no podía ser de otra forma, en el manual de GRUB.

Sigue leyendo »

Hoy la noticia buena y mala del día para los usuarios de Linux ha sido que Adobe ha liberado una versión alpha de su plugin Flash para navegadores: Barrapunto: Flash para 64 bits llega primero a Linux, Penguin.SWF: Now Supporting 16 Exabytes, Descargar versión de Linux de 64 bits de Flash Player 10.

Es una noticia buena para los usuarios de Linux AMD64 después de tanto tiempo pidiéndolo, porque el plugin de Flash es vital para nuestros sistemas de escritorio si queremos tener una experiencia completa en el uso de la web hoy en día. Su alternativa abierta, el Gnash, aún no está preparado para reemplazarlo completamente. La única opción que teníamos era usar el plugin de 32 bits con el nspluginwrapper (Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing), una opción que, aunque nos saca del apuro, es muy inestable y nos obligaba muy a menudo a reiniciar el navegador porque el plugin de Flash dejaba de funcionar.

Es una noticia muy mala para los usuarios de Linux porque es lamentable que en nuestro sistema, que nos gustaría ver libre de todo el software propietario, tengamos que pasar por el aro de dos cosas: del dichoso plugin de Flash y de los drivers cerrados. No es casualidad que a menudo sean componentes de software de nuestros sistemas que desearíamos que fueran algo más estables. Es muy desafortunado que tengamos que depender de que los señores de Adobe sean magnánimos con los pobres bichos raros que usan Linux de 64 bits para poder usar lo que todo el mundo usa, Internet.

Y por supuesto, también es lamentable que diseños web que se podrían hacer de forma perfectamente estándar y llamativa con un poco de CSS, HTML y JavaScript, acaben siendo pasto del todopoderoso y monopolístico Flash para desesperación de aquello que llamamos accesibilidad. El uso de Flash para reproducir vídeos en la web es razonable, aunque sería mucho más deseable que se usara cualquiera de los formatos de vídeo abiertos disponibles. Donde sí tiene perfecta cabida, hay que reconocerlo, es en el campo de las animaciones, como los juegos online o los típicos esquemas interactivos que a menudo nos presentan los periódicos en su edición digital.

Bueno, yo he probado hoy esta nueva versión del plugin en mi Ubuntu 8.10 y he de decir que funciona. No lo he probado intensivamente, pero funciona bien con algún juego (¿habéis probado el Play 99 Bricks?) y con Youtube, Metacafe y ZappInternet. Sin embargo, me da la sensación de que usa muchísima CPU.

Para instalarlo, he desinstalado el paquete flashplugin-nonfree:

 $ sudo dpkg -P flashplugin-nonfree
(Reading database ... 134935 files and directories currently installed.)
Removing flashplugin-nonfree ...
Purging configuration files for flashplugin-nonfree ...

y he hecho un autoremove para que elimine el nspluginwrapper también:

$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  nspluginwrapper
The following packages will be REMOVED:
  nspluginwrapper
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 483kB disk space will be freed.
Do you want to continue [Y/n]? 
(Reading database ... 134928 files and directories currently installed.)
Removing nspluginwrapper ...
Processing triggers for man-db ...

Finalmente, he descargado el fichero libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz y lo he descomprimido en el directorio ~/.mozilla/plugins. Sólo contiene una librería:

~ $ wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz

~ $ cd .mozilla/plugins/

~/.mozilla/plugins $ tar xvf ~/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
libflashplayer.so

Tras reiniciar el navegador, en el about:plugins ya veremos:

Shockwave Flash

File name: libflashplayer.so
Shockwave Flash 10.0 d20

Para instalar el plugin para todos los usuarios del sistema, habría que copiar la nueva librería en /usr/lib/mozilla/plugins/.

En fin, que la noticia deja un sabor muy agridulce. Es como cuando el driver de NVidia va mal y la actualización del driver cerrado arregla el problema. Se agradece la actualización, pero ésta no mitiga la impotencia que da depender de la voluntad que tenga una empresa para arreglar fallos o no hacerlo.

Actualización 20/11/08: The Inquirer: Instalación y rendimiento Adobe Flash 64bits en Linux

:wq

A finales de los 70, los monstruosos ordenadores de la época comenzaron a usar terminales serie para la consola y la entrada salida estándar (teclado y pantalla). Antes de ellos, los ordenadores interactuaban con el usuario usando teletipos (teletype: TTY, ¿te suenan de algo estas siglas?). Los terminales pioneros, tal y como los conocemos ahora, fueron el DEC VT52 y el DEC VT100, por allá por 1978. Éste era su aspecto:

Otros fabricantes desarrollaron otros tipos de terminales, con el mismo concepto, pero incompatibles con otros sistemas, como este HP 700/96, que aún se sigue usando en algunos CPD hoy en día:

Los ordenadores personales, como el PC y los Apple o los Commodore, Spectrum, Amstrad CPC, etc. siguieron otro camino para mostrar la información al usuario, ya que, o bien usaban un sistema de vídeo propietario para mostrar texto y gráficos (p.e. MDA o VGA), o bien se conectaban directamente al televisor.

Los grandes servidores UNIX (basados en AIX, HP-UX, Solaris, etc.) o similares (por ejemplo, basados en OpenVMS, o z/OS) han llegado a nuestros días permitiendo la conexión de un terminal serie para usar la consola, pero cada día es más infrecuente su uso, ya que han sido sustituidos por consolas LAN (accedemos por Telnet o por SSH a una dirección IP diferente a la propia del sistema) o por consolas Web (una página web donde nos aparece la consola), que, por supuesto, nos permiten interactuar con la máquina incluso durante el arranque y la parada.

Hoy en día los terminales serie están bastante en desuso. Sin embargo, los emuladores de terminal están en pleno apogeo, bien sean para conectarnos por Telnet, por SSH, o, por supuesto, por el puerto serie/módem (ya lo vimos en Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP). Por cierto, ¿qué tipo de terminal emulan la mayoría de emuladores de terminal como mínimo? Pues, por supuesto, el famoso VT100. Pero como otros fabricantes hicieron otros terminales con sus propios protocolos, secuencias de escape y capacidades, hay múltiples tipos de emuladores de terminal. Las emulaciones de terminal ansi y vt100 (y tal vez xterm) son las más usadas.

Sigue leyendo »

A mucha gente no le preocupará la resolución de la consola de Linux, el modo texto que se usa cuando no estamos en el entorno X Window, bien porque no lo hayamos cargado, bien porque hayamos salido temporalmente de él con la combinación de teclas Control+Alt+Fx.

Sin embargo, a mí sí que me gusta mucho salir a la consola. Y especialmente, me gusta ver el arranque detallado del sistema. Si me conformara con ver el bonito logotipo de Debian o de Ubuntu mientras espero a que arranque el sistema, nunca habría descubierto problemas como los que conté en Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel y en Disk might not be spun down properly. Update shutdown utility..

Es por eso que para mí es importante contar con una resolución en la consola adecuada a la pantalla que esté usando, para que las letras se vean lo más nítidas posibles y sin que sean monstruosamente grandes. La resolución la podemos especificar con el parámetro del kernel vga=DDD o vga=0xHHH, donde DDD es el número del modo VESA que queremos utilizar en decimal y HHH es el mismo número en hexadecimal. El único requisito es que el kernel haya sido compilado con soporte del driver de framebuffer VESA:

$ grep FB_VESA /boot/config-2.6.27-7-generic 
CONFIG_FB_VESA=m

Lo único que necesitamos saber es qué modos VESA acepta nuestro adaptador gráfico y qué números tienen. Los más comunes (800×600, 1024×768, 1200×1024, etc.) son bien conocidos, y es a lo que dediqué precisamente la tercera entrada de este blog: Modos VESA aceptados por el kernel de Linux.

Sin embargo, el advenimiento de infinidad de portátiles y pantallas con resoluciones nativas poco convencionales (1680×1050, 1400×1050, 1400×900, etc.) no nos facilita precisamente el saber qué modos soportará nuestra pantalla y nuestro adaptador gráfico ya que, en ocasiones, el modo ni siquiera está estandarizado.

Sigue leyendo »

El paquete sysstat es una colección de herramientas de monitorización de rendimiento. Nos puede proporcionar datos instantáneos de rendimiento, así como almacenarlos como históricos para nuestra futura referencia. Especialmente en entornos de servidor, sus datos nos proporcionan información muy valiosa sobre las posibles carencias y cuellos de botella de nuestro sistema.

Las herramientas que incluye son:

• iostat(1) reports CPU statistics and input/output statistics for devices, partitions and network filesystems.
• mpstat(1) reports individual or combined processor related statistics.
• pidstat(1) reports statistics for Linux tasks (processes) : I/O, CPU, memory, etc.
• sar(1) collects, reports and saves system activity information (CPU, memory, disks, interrupts, network interfaces, TTY, kernel tables,etc.)
• sadc(8) is the system activity data collector, used as a backend for sar.
• sa1(8) collects and stores binary data in the system activity daily data file. It is a front end to sadc designed to be run
  from cron.
• sa2(8) writes a summarized daily activity report. It is a front end to sar designed to be run from cron.
• sadf(1) displays data collected by sar in multiple formats (CSV, XML, etc.) This is useful to load performance data into a database, or import them in a spreadsheet to make graphs.

En Debian y Ubuntu, tras instalar el paquete (apt-get install sysstat), ya podemos ver datos instantáneos. Todos los comandos aceptan como parámetros:

[ interval [ count ] ]

con los que le decimos al comando cuántos valores queremos y cada cuántos segundos. Por ejemplo, 5 valores de uso de CPU separados un segundo:

$ sar 1 5
Linux 2.6.27-7-generic (sistema) 	11/08/2008 	_x86_64_

10:17:37 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:17:38 AM     all      2.45      0.00      1.47      0.00      0.00     96.08
10:17:39 AM     all      1.96      0.00      0.98      0.00      0.00     97.06
10:17:40 AM     all     11.17      0.00      2.91      0.00      0.00     85.92
10:17:41 AM     all     13.11      0.00      1.94      0.00      0.00     84.95
10:17:42 AM     all      3.37      0.00      2.88      0.00      0.00     93.75
Average:        all      6.42      0.00      2.04      0.00      0.00     91.54

Sigue leyendo »

Hace tiempo que lo venía haciendo en algunos sistemas Linux, pero últimamente, cada vez me he vuelto más estricto con esto: ¡Se acabaron las particiones de memoria de virtual o de swap en sistemas domésticos!

Si lo pensamos detenidamente, tener una partición de swap, es tener una cantidad de espacio ahí abandonada y que en rarísimas ocasiones veremos usar. Y si el kernel llega a usarla, hemos de prepararnos, en la mayoría de los casos, a experimentar un sistema extraordinariamente pesado, con lo que si es una situación habitual, más nos vale comprar una ampliación de la memoria. De nuevo, recalcar que me refiero a sistemas domésticos. En un servidor, la memoria swap nos puede ayudar a absorber un pico puntual de trabajo que sólo se da en ocasiones aisladas y que no podemos dejar de atender.

Para nuestro sistema doméstico, resulta mucho más conveniente un fichero de swap, igual que hacen todos los Windows basados en NT con el pagefile.sys. Las ventajas son muchas:

• Lo podemos poner en la partición/sistema de ficheros que queramos
• Podemos borrarlo para liberar espacio si éste nos hace falta
• Podemos crear uno nuevo en cualquier momento
• No supone tener un espacio en disco bloqueado inservible para otros propósitos
• Posiblemente su rendimiento sea algo peor que el de una partición dedicada de swap, pero si la memoria swap llega a tener que usarse intensivamente, el rendimiento será ya nefasto, ¿qué más da que sea un poco peor?

Y, además, lo último, lo de que el rendimiento es peor parece que ni siquiera es cierto. En la LKML leemos que usando kernels 2.6 el rendimiento de un fichero de swap no es peor que el de una partición de swap (Jesper Juhl: a swap file is just as fast as a swap partition):

With a 2.4.x kernel swap files were slower than swap partitions, but with the 2.6 kernel a swap file is just as fast as a swap partition.

Sigue leyendo »

En monitores y pantallas de grandes resoluciones (mayores de 1024×768), yo evito trabajar con el navegador maximizado. Entre otras cosas, porque en las páginas de ancho variable (entre ellas, la de un servidor) las líneas serán demasiado largas, y en las páginas de ancho fijo (que yo diría que son mayoría) aparecen demasiado vacías. Además, si no lo tengo maximizado, me resulta sencillo poder redimensionar el navegador frecuentemente cuando quiero adaptarlo a la página que estoy visitando. Bueno, y en cualquier caso, es que en general evito las aplicaciones maximizadas. Prefiero tener a la vista un trozo de todas las ventanas abiertas para hacerme una idea de todo lo que estoy haciendo.

Es por eso que, cuando una página decide por mí qué tamaño de ventana es el adecuado redimensionando mi navegador, me enfurezco. Si usara Internet Explorer 6, que no tiene pestañas, quizás no me importaría tanto, ya que sólo se redimensionaría la ventana de esa página web; pero en Firefox (o IE7, o Google Chrome, o Safari, o…), redimensionar el navegador es redimensionarlo para todas las pestañas. Pero aún así, hay diseñadores web que se empeñan en usar técnicas del pasado y redimensionarnos el navegador a la fuerza.

Un ejemplo sangrante es el de la página de ING Direct. Sin entrar en que, en mi opinión, sus diseñadores no usan las mejores técnicas de accesibilidad posibles, lo primero con que nos encontramos al entrar es una maximización del navegador. Bueno, no es exactamente una maximización, es que el navegador use el máximo tamaño posible sin maximizarlo:

<script language=javascript>

window.top.resizeTo(screen.availWidth, screen.availHeight); 
window.top.moveTo(0,0); 

</script>

Yo también te podría redimensionar el navegador ahora mismo, pero no lo hago porque considero que es de mal gusto que yo cuestione tu configuración del navegador. Pero si te apetece que lo haga, sólo tienes que pulsar sobre este enlace:

o si quieres que te moleste un poco más, tal vez quieras probar éste:

Sigue leyendo »