miércoles, 31 de diciembre de 2008

Servidor Subversion

Hace poco he instalado un servidor SVN para que distintas personas puedan alojar sus proyectos. Vamos a ver cómo lo he hecho.

El primer paso ha sido, evidentemente, instalar Subversion:

aptitude install subversion


Claro que, para que todos los colaboradores puedan contribuir, tienen que poder acceder a los repositorios. Para ello hay dos métodos, un servidor especializado (svnserve) y el bueno de nuestro querido Apache con web-DAV.

Dados los problemas que puede presentar el servidor especializado con respecto a cortafuegos, proxys y similares, y dado que de todos modos vamos a usar Apache, que además nos permitirá navegar por la versión más reciente de cada repositorio, o incluso descargarlo con herramientas del tipo de wget, hacemos:

aptitude install apache2


Y claro, necesitamos que Apache y Subversion se entiendan:

aptitude install libapache2-svn


El primer paso de decisión es colocar los repositorios. La elección obvia sería /var/svn pero también se pueden considerar otras opciones como /srv/svn o /usr/lib/svn o incluso /usr/local/lib/svn.

Así, dentro de /var/svn tendremos un subdirectorio para cada repositorio completo. Ahora hay que convencer a Apache de que nos los muestre. Para ello, en el mismo directorio creamos un fichero como éste:

#Fichero /var/svn/repositorio_dav_svn.apache2.conf

<Location /svn/>
# Repositorio Subversion vía WebDAV
DAV svn

# Cualquier petición "/svn/algo" corresponderá al repositorio /var/svn/algo
SVNParentPath /var/svn

# Permitimos el listado de repositorios
SVNListParentPath on
</Location>


Con esta configuración ya podemos crear repositorios con
svnadmin create
y directamente los podremos utilizar desde otros ordenadores con órdenes del estilo de
svn co http://host/svn/repositorio
tanto para hacer checkout como commit.

¿O no?

Pues no. Hay dos detalles que se nos han quedado pendientes. El primero es que Apache no se entera de la existencia de ese fichero por arte de magia. Hay que decirle que hay un nuevo sitio disponible y que lo use:

ln -s /var/svn/repositorio_dav_svn.apache2.conf /etc/apache2/sites-available/repositorio_dav_svn
a2ensite repositorio_dav_svn
apache2ctl graceful


Sí, ya sé que sites-available está para configuraciones de tipo VirtualHost, pero es que prefiero dejar las cosas limpitas.

El segundo detalle es que al crear un repositorio con
svnadmin create repositorio
no podremos realizar commit en él, ya que Apache no puede escribir en el directorio. Por ello, ejecutamos

chgrp -R www-data repositorio
chmod -R g+w repositorio


Claro que puede que a los colaboradores no les maraville que todas las versiones de todos los proyectos estén disponibles a todo el mundo, y menos aún con acceso de escritura. Así que hay que hacer algo con los permisos, pero ya no puede ser sobre los repositorios, porque quien accede a ellos es Apache. Así que lo que hacemos es decirle a él que se encargue de la autentificación de usuarios y de su autorización.

Para ello, cogemos el fichero /var/svn/repositorio_dav_svn.apache2.conf de antes y lo modificamos un poco:

#Fichero /var/svn/repositorio_dav_svn.apache2.conf

# Esto es para evitar la incompatibilidad entre SVNListParentPath y AuthzSVNAccessFile
RedirectMatch ^(/svn)$ $1/

<Location /svn/>
# Repositorio Subversion vía WebDAV
DAV svn

# Cualquier petición "/svn/algo" corresponderá al repositorio /var/svn/algo
SVNParentPath /var/svn

# Permitimos el listado de repositorios
SVNListParentPath on

# Fichero de control de acceso por repositorios y ramas
AuthzSVNAccessFile /var/svn/authz

# Orden de prueba de usuarios
Satisfy Any
Require valid-user

# Método de autenticación y fichero de contraseñas
AuthType Digest
AuthDigestDomain http://miservidor/svn/
AuthName "Repositorio Subversion de miservidor"
AuthUserFile /var/svn/passwd-digest
</Location>


Hemos añadido cuatro piezas nuevas. La primera es para evitar un problema con las autentificaciones que puede surgir si se trata de ver el listado de repositorios, y las otras tres, ya dentro de la Location, configuran la autentificación y la autorización.

Ojo, que ese RedirectMatch está para algo, y es que AuthzSVNAccessFile da problemas si la barra final no está, así que es muy importante que la Location diga algo como <Location /svn/> y no <Location /svn> sin la barra final, aunque eso sea lo que viene en la documentación.

La autentificación es el último bloque. En él decimos que queremos que las contraseñas viajen cifradas (AuthType Digest), qué Reino de Autentificación (conjunto de dominios y subdirectorios en ellos) está en juego (es una manera de separar los accesos para distintos sitios con el mismo nombre de usuario, y también de agruparlos), que el cliente utiliza para no requerirnos cada vez el nombre de usuario y la contraseña (AuthDigestDomain http://miservidor/svn/), el nombre del Reino de Autentificación (para que el usuario sepa a qué corresponden el nombre de usuario y contraseña que debe introducir) que el cliente normalmente nos mostrará en el formulario (AuthName "Repositorio Subversion de miservidor") y, finalmente, en qué fichero almacenamos las parejas nombre de usuario-contraseña (AuthUserFile /var/svn/passwd-digest).

Este fichero hay que crearlo con la orden htdigest. Y ojo, que como vamos a utilizar autentificación por digest tenemos que activar el módulo correspondiente de Apache:

a2enmod auth_digest


Los otros dos bloques son el control de acceso. La parte

# Orden de prueba de usuarios
Satisfy Any
Require valid-user

hace que el acceso sin identificarse sea posible allí donde esté permitido. Si no lo ponemos, será imposible incluso acceder a la lista de repositorios sin identificarse. La otra parte simplemente indica qué fichero tiene la lista de control de acceso, es decir, qué nombres de usuario tienen permitido el acceso de lectura o de escritura a cada repositorio y a cada directorio de cada repositorio (AuthzSVNAccessFile /var/svn/authz). Este fichero tiene aproximadamente este aspecto:

# Fichero /var/svn/authz

# Acceso de lectura libre a todos sitios
# (es decir, al listado de repositorios) para todos
# y acceso de escritura al administrador del sitio
[/]
administrador = rw
* = r

# Permisos particulares para el repositorio repo1
# Añadimos permiso de escritura para algunos usuarios
# y quitamos el permiso de lectura para el usuario sin identificar
[repo1:/]
repo1admin = rw
repo1colaborador = rw
* =

# Quitamos el permiso de lectura al colaborador en determinado directorio
[repo1:/privado]
repo1colaborador =


Por supuesto, esta estructura puede complicarse bastante, y además los usuarios se pueden organizar en grupos. Hay más información en http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html.

Y adelante, ya tenemos un servidor Subversion preparado para aguantar lo que le echen.

miércoles, 17 de diciembre de 2008

Esas pequeñas herramientas (I)

Hoy, UDP Cast.

UDP Cast es una herramienta que permite enviar un fichero a través de una red Ethernet a varios destinos a la vez. Para ello utiliza tramas Broadcast de Ethernet y direcciones multicast de IP.

Tiene dos usos principales, como programa instalado y como programa independiente. Como programa instalado, se puede utilizar en cualquier instalación de Unix (o de otros sistemas) para transmitir un fichero cualquiera. Así, el coste de distribuir un parche, por ejemplo, de un servidor a trescientos clientes es el mismo que el coste de distribuirlo a uno.

Como programa independiente, podemos arrancar varios ordenadores desde un disquete o un CD-ROM (o por PXE o por bootp o por...) y tras una configuración muy, muy sencilla, copiar discos completos o particiones entre sistemas, lo cual es enormemente útil para instalar aulas completas de ordenadores idénticos.

Por supuesto, en este caso hay que tener cuidado con las posibles diferencias en el hierro de los ordenadores, ya que discos o particiones de distinto tamaño o geometría, por ejemplo, pueden dar problemas.

En cualquier caso, siempre es bueno tener un par de discos de UDP Cast a mano.

martes, 2 de diciembre de 2008

Inestablemente estable


A veces, en Debian, uno tiene que instalar un paquete de una rama diferente a la que está utilizando. Por ejemplo, uno tiene un servidor instalado con la rama estable y tiene que instalar un determinado paquete de la rama de pruebas o de la inestable porque es la única manera de conseguir determinada característica.

Para entendernos, Debian tiene cuatro ramas: la estable (stable), la de pruebas (testing), la inestable (unstable) y la experimental (experimental). Normalmente el trabajo de desarrollo se hace en la inestable, y los programas que después de diez días en inestable no dan problemas se pasan a la rama de pruebas. Así, si se quiere estar siempre a la última hay que instalar el sistema con la rama inestable, pero es perfectamente posible que el sistema quede inutilizable. La rama de pruebas es la preferida por mucha gente que quiere estar a la última con sus escritorios pero sin arriesgarse a que todo quede parado, mientras que la rama estable es ideal para servidores o para administrar grandes conjuntos de máquinas iguales.

Por su parte, la rama experimental tiene versiones demasiado inestables incluso para la rama inestable. De hecho no es una rama completa, uno no puede instalar un sistema complete utilizando solamente paquetes de esta rama.

Pues bien, se me ha dado el caso de que en un ordenador con la rama de pruebas instalada necesité instalar ImageMagick, pero resulta que la versión de este programa que viene en esta rama (la 6.3.7.9) utiliza como compresor MPEG el programa mpeg_encode, que no existe en Debian. En cambio, la versión de la rama experimental es la 6.4.5.4 que utiliza ffmpeg, que sí está disponible.

La primera opción es bajarse el imagemagick de experimental e instalarlo a mano. Esto se empieza a complicar cuando uno descubre que necesita dos librerías más, también de experimental, y cambiar la versión de otro paquete que también tiene dependencias.

Y claro, uno se pregunta "¿Para qué tengo que hacer todo esto si es justo el tipo de cosas que le encanta a apt?"

La solución:

Lo primero, hay que dejarle bien claro a apt qué rama queremos utilizar normalmente:

#/etc/apt/apt.conf

APT::Default-Release "testing";


Lo segundo, hay que tener las fuentes de la rama que necesitamos, aparte de las fuentes de la rama que tenemos normalmente:

#/etc/apt/sources.list

# Fuentes remotas de paquetes
deb http://ftp.es.debian.org/debian/ stable main contrib non-free
deb http://ftp.es.debian.org/debian/ testing main contrib non-free
deb http://ftp.es.debian.org/debian/ unstable main contrib non-free
deb http://ftp.es.debian.org/debian/ experimental main contrib non-free

# Actualizaciones de seguridad
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free


Y listo. Actualizamos las listas de paquetes con aptitude update o apt-get update (o dselect o Synaptic o lo que cada uno prefiera) y ya estamos preparados para indicarle al sistema lo que queremos:

# aptitude install imagemagick/experimental
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes... Hecho
Leyendo las descripciones de las tareas... Hecho
Los siguientes paquetes están ROTOS:
libmagickcore1
Se instalarán los siguiente paquetes NUEVOS:
ghostscript{a} gsfonts{a} imagemagick imagemagick-doc{a} libcupsimage2{a} libgd2-noxpm{a} libgomp1{a} libgraphviz4{a}
libgs8{a} libilmbase6{a} libjasper1{a} libltdl3{a} libmagickwand1{a} libopenexr6{a} libpaper-utils{a} libpaper1{a}
libwmf0.2-7{a} psfontmgr{a}
0 paquetes actualizados, 19 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 13,7MB de ficheros. Después de desempaquetar se usarán 48,4MB.
No se satisfacen las dependencias de los siguientes paquetes:
libmagickcore1: Depende: libdjvulibre21 (>= 3.5.21) pero no es instalable
Las acciones siguientes resolverán estas dependencias

Instalar los paquetes siguientes:
libdjvulibre-text [3.5.21-1 (unstable)]
libdjvulibre21 [3.5.21-1 (unstable)]

La puntuación es 12

¿Acepta esta solución? [Y/n/q/?]
Se instalarán los siguiente paquetes NUEVOS:
ghostscript{a} gsfonts{a} imagemagick imagemagick-doc{a} libcupsimage2{a} libdjvulibre-text{a} libdjvulibre21{a}
libgd2-noxpm{a} libgomp1{a} libgraphviz4{a} libgs8{a} libilmbase6{a} libjasper1{a} libltdl3{a} libmagickcore1{a}
libmagickwand1{a} libopenexr6{a} libpaper-utils{a} libpaper1{a} libwmf0.2-7{a} psfontmgr{a}
0 paquetes actualizados, 21 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 14,4MB de ficheros. Después de desempaquetar se usarán 50,5MB.
¿Quiere continuar? [Y/n/?]
Escribiendo información de estado extendido... Hecho
Des:1 http://ftp.fr.debian.org testing/main libcupsimage2 1.3.8-1lenny2 [98,5kB]
Des:2 http://ftp.fr.debian.org testing/main libpaper1 1.1.23+nmu1 [20,6kB]
Des:3 http://ftp.fr.debian.org testing/main libgs8 8.62.dfsg.1-3.1 [2219kB]
Des:4 http://ftp.fr.debian.org testing/main gsfonts 1:8.11+urwcyr1.0.7~pre44-3 [3373kB]
Des:5 http://ftp.fr.debian.org testing/main ghostscript 8.62.dfsg.1-3.1 [766kB]
Des:6 http://ftp.fr.debian.org testing/main libgomp1 4.3.2-1 [13,2kB]
Des:7 http://ftp.fr.debian.org unstable/main libdjvulibre-text 3.5.21-1 [74,4kB]
Des:8 http://ftp.fr.debian.org unstable/main libdjvulibre21 3.5.21-1 [682kB]
Des:9 http://ftp.fr.debian.org testing/main libgd2-noxpm 2.0.36~rc1~dfsg-3 [221kB]
Des:10 http://ftp.fr.debian.org testing/main libltdl3 1.5.26-4 [177kB]
Des:11 http://ftp.fr.debian.org testing/main libgraphviz4 2.20.2-3 [536kB]
Des:12 http://ftp.fr.debian.org testing/main libilmbase6 1.0.1-2+nmu2 [118kB]
Des:13 http://ftp.fr.debian.org testing/main libjasper1 1.900.1-5.1 [145kB]
Des:14 http://ftp.fr.debian.org experimental/main libmagickwand1 7:6.4.5.4.dfsg1-1 [332kB]
Des:15 http://ftp.fr.debian.org testing/main libopenexr6 1.6.1-3 [262kB]
Des:16 http://ftp.fr.debian.org testing/main libwmf0.2-7 0.2.8.4-6 [174kB]
Des:17 http://ftp.fr.debian.org experimental/main libmagickcore1 7:6.4.5.4.dfsg1-1 [1667kB]
Des:18 http://ftp.fr.debian.org experimental/main imagemagick 7:6.4.5.4.dfsg1-1 [86,1kB]
Des:19 http://ftp.fr.debian.org experimental/main imagemagick-doc 7:6.4.5.4.dfsg1-1 [3410kB]
Des:20 http://ftp.fr.debian.org testing/main libpaper-utils 1.1.23+nmu1 [17,6kB]
Des:21 http://ftp.fr.debian.org testing/main psfontmgr 0.11.10-0.2 [22,2kB]
Descargados 14,4MB en 3min47s (63,5kB/s).
Preconfigurando paquetes ...
[...]
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes... Hecho
Escribiendo información de estado extendido... Hecho
Leyendo las descripciones de las tareas... Hecho


Como se puede ver, la barra al final del nombre del paquete indica "quiero este paquete de esta rama", y el sistema ha bajado el paquete de experimental, y sus dependencias, mientras fue posible, de la rama actual, la de pruebas. Además, las actualizaciones del sistema no darán problemas diciendo siempre "hay nuevos paquetes disponibles" cuando esos paquetes no sean de la rama actual.

martes, 11 de noviembre de 2008

¿Cuanto polvo cabe en un ordenador?




La respuesta es: mucho. Sobre todo si no se limpia.

El otro día me decidí a limpiar de polvo un ordenador que tengo en casa. Lleva años funcionando, y hace tiempo que no lo limpiaba. De hecho, había dejado de funcionar: ya sabemos que el polvo es conductor, y además tiene otro problema, y es que bloquea los ventiladores, con lo que las temperaturas suben.

El caso es que lo desmonté pieza a pieza. Se puede ver en la primera foto el estado del disipador del procesador cuando quité su ventilador. Y el ventilador andaba igual, así como el resto de la placa.

La tercera foto muestra todas las piezas y el total de polvo extraído: un montón.

Y eso que al ventilador de carcasa tuve incluso que darle aceite vegetal a ver si volvía a funcionar, porque tenía tanto polvo dentro del mecanismo, entre el rotor y el estator, que andaba a menos de la mitad de su velocidad normal.

Eso sí, una vez limpio y vuelto a montar, la máquina no ha vuelto a dar problemas.

martes, 14 de octubre de 2008

SMART

Este artículo es principalmente una traducción del que me han publicado en Debian Package of the Day y que llegó luego a DebianTimes.




Uno de los paquetes que instalo manualmente en toda nueva instalación es smartmontools. Tengo cierta experiencia administrando ordenadores y redes, y es un hecho que los piratas informáticos y los fallos de los programas (bugs) no son la mayor causa de problemas en instalaciones pequeñas y medianas. Lo es el hardware.


Luego tenemos aparatos que pueden fallar, y Murphy dice que si algo puede fallar, fallará. El asunto no es evitar los fallos físicos, lo que es imposible, sino detectarlos rápidamente o incluso prevenirlos.


Particularmente para los discos duros, la herramienta encargada es smartctl del paquete smartmontools. Los discos IDE (si no son de la era de los dinosaurios) tienen una herramienta integrada de autoanálisis llamada SMART que significa“Self-Monitoring, Analysis and Reporting Technology” (Tecnología de Auto-Monitorización, Análisis e Informe). Los discos SCSI modernos también la tienen si son SCSI 3 o más nuevos. Lo que ocurre es que en la circuitería del disco hay rutinas para controlar parámetros de salud del disco: tiempo de comienzo de rotación (spin-up time), número de fallos de lectura, temperatura, tiempo de vida… Y todos esos parámetros no son solamente controlados por el propio disco, sino que tienen asignados límites de seguridad, y tanto los parámetros como los límites pueden ser obtenidos por programas que accedan a los discos utilizando las instrucciones I/O apropiadas.


Y ese programa es smartctl, una pieza del paquete Debian smartmontools. Por supuesto, como accede al disco directamente, hay que ser superusuario (root) para usar estas órdenes.


smartctl puede preguntarle al disco por su identificación SMART:



# smartctl -i /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family: Fujitsu MHV series
Device Model: FUJITSU MHV2060BH
Serial Number: NW10T652991F
Firmware Version: 00850028
User Capacity: 60,011,642,880 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a
Local Time is: Mon May 12 02:39:31 2008 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Más interesante, smartctl puede preguntarle al disco por los valores de sus parámetros:



# smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 046 Pre-fail Always - 124253
2 Throughput_Performance 0x0004 100 100 000 Old_age Offline - 18284544
3 Spin_Up_Time 0x0003 100 100 025 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1199
5 Reallocated_Sector_Ct 0x0033 100 100 024 Pre-fail Always - 8589934592000
7 Seek_Error_Rate 0x000e 100 087 000 Old_age Always - 1761
8 Seek_Time_Performance 0x0004 100 100 000 Old_age Offline - 0
9 Power_On_Seconds 0x0032 079 079 000 Old_age Always - 10866h+57m+47s
10 Spin_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1199
192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 283
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 6953
194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 45 (Lifetime Min/Max 14/58)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 62
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 459276288
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x000e 100 082 000 Old_age Always - 22371
203 Run_Out_Cancel 0x0002 100 100 000 Old_age Always - 1533257648465
240 Head_Flying_Hours 0x003e 200 200 000 Old_age Always - 0

Como se puede ver, algunos atributos están marcados como “Pre-fail”. Si cualquiera de estos atributos traspasa su límite, el disco está para fallar en cuestión de horas, quizá minutos.


Aunque hay más opciones para smartctl, las últimas que voy a comentar son -a y -t.


smartctl -t lanza una prueba automática de todo el disco. Necesita un parámetro indicando el tipo de prueba, y en el caso más largo puede durar varias decenas de minutos y comprobará el rendimiento eléctrico y mecánico del disco así como el rendimiento de lectura de las cabezas por toda la superficie. smartctl -a, por su parte, muestra toda la información disponible sobre el disco, incluidos los resultados de las pruebas automáticas. Como estas pruebas duran minutos, o decenas de minutos, no podemos observarlas. Todo lo que obtenemos al lanzar una de estas pruebas es:



# smartctl -t long /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in
off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in
off-line mode" successful.
Testing has begun.
Please wait 41 minutes for test to complete.
Test will complete after Mon May 12 05:44:03 2008

Use smartctl -X to abort test.

Aquí se nos informa de que (quizá) tengamos un rendimiento ligeramente menor del disco durante los próximos 41 minutos, porque la prueba ha comenzado. Se produce completamente en segundo plano, o sería mejor decir “fuera de plano”, ya que no ocurre bajo el control del Sistema Operativo en absoluto: todo ocurre internamente al disco, y lo único que vamos a obtener es el resultado.


smartctl -a, por su parte, muestra una enorme cantidad de información SMART sobre el disco: prácticamente toda la información SMART disponible. Normalmente es mejor utilizar una opción específica, como se puede ver en la página de manual (man).


Finalmente, quiero comentar que hay un demonio en el paquete smartmontools, llamado smartd, que se encarga de realizar las pruebas automáticas por uno. Funciona ejecutando smartctl de forma periódica (típicamente cada 30 minutos) y registrando todos los errores y los cambios de los valores de los parámetros en el registro del sistema (syslog). La configuración por defecto en Debian además enviará un mensaje al superusuario con cualquier problema detectado. No voy a explicarlo aquí porque quiero que se lean la documentación, que es concisa y clara, pero recuerden que para usarlo deben activarlo en /etc/default/smartmontools.


El paquete smartmontools ha estado disponible en Debian y Ubuntu desde hace mucho tiempo.



Hay quien ha preguntado por qué en los ejemplos todos los valores aparecen por encima de los límites. Es lo normal: los valores normalizados de los parámetros comienzan típicamente en 100 o 200, y a medida que el disco sufre van descendiendo. El problema lo tenemos cuando un parámetro desciende por debajo de su límite, no cuando está por encima. Aunque también hay que estar atento a las bajadas significativas de los parámetros aunque no leguen a los límites: son signos de que algo malo está pasando.

Como nota, los discos de Seagate tienen la costumbre de poner el parámetro de temperatura en su valor real, lo que lo convierte en uno de los pocos casos en los que un parámetro empeora cuando crece.

lunes, 22 de septiembre de 2008

El escritorio que no cubría la pantalla

NOTA: Actualizado con todos los datos y capturas de pantalla.

Hoy me tocó arreglar el sistema X-Window de un portátil, un Toshiba Satellite U300 13H. Ya lo había hecho una vez, pero no recordaba cómo. El caso es que el escritorio no cubría toda la pantalla: la barra del escritorio no tocaba el fondo ni llegaba completamente a la derecha.



Y claro, fueron unas cuantas horas tratando de averiguar lo que pasaba, en realidad de recordarlo, trasteando con el siempre servicial xrandr que acudió en mi ayuda y me dijo lo que pasaba: La tarjeta gráfica se confundía y pensaba que estaban activas a la vez la salida LDVS y la salida TV. Y trataba de mostrarlas ambas en el monitor. Como la salida TV tiene menos resolución que la LDVS, pues ahí estaba el problema:

crab:~> xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right)
LVDS connected 1280x800+0+0 (normal left inverted right) 286mm x 179mm
1280x800 59.9*+ 60.0
1280x768 60.0
1024x768 60.0
800x600 60.3
640x480 59.9
TV connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
1024x768 30.0*
800x600 30.0
848x480 30.0
640x480 30.0

La solución ya la había hallado, no recuerdo ahora dónde, cuando instalé este portátil por primera vez, cuando se compró. Esta vez, me lié con la opción Option "Enable" "false" cuando no es correcta, y la solución al final me la dió esta entrada de una bitácora que se llama, curiosamente, No pienso arreglar tu ordenador. Tenía que haber usado Option "Ignore" "true".

Para explicarlo un poco mejor, el fichero xorg.conf lleva una sección donde se configura el dispositivo (la tarjeta de vídeo), otra donde se configuran los monitores (porque puede haber varios), y otra donde se junta todo creando una "pantalla".

La solución es configurar dos monitores:
Section "Monitor"
Identifier "Configured Monitor"
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Disabled Monitor"
Option "Ignore" "true"
EndSection

y configurar la tarjeta para que ponga sus salidas en esos dos monitores, sacando así la molesta salida TV al monitor deshabilitado:

Section "Device"
Identifier "Intel Corporation Mobile GM965/GL960 Integrated Graphic
s Controller"
Driver "intel"
BusID "PCI:0:2:0"
Option "Monitor-LVDS" "Configured Monitor"
Option "Monitor-TV" "Disabled Monitor"
EndSection

miércoles, 17 de septiembre de 2008

Diseños de teclado (II)

Siguiendo con lo escrito en "Diseños de teclado", esta vez he tenido que hacer algo semejante: que un teclado estadounidense pueda ser utilizado para escribir normalmente en castellano.

Gracias a la documentación que menciono allí [1] [2] [3] no tuve muchos problemas para conseguirlo. El modelo de teclado a utilizar era, evidentemente, el teclado estadounidense us, lo que, así solo, significa la variante basic, es decir us(basic). Pero el teclado us tiene otra variante, la internacional us(intl), que permite cosas como que las teclas con acentos se consideren teclas muertas: teclas que necesitan que se pulse otra después, como en el teclado castellano es normal.

Pero no quería poner el teclado us(intl) tal cual, porque redefine demasiadas teclas.

La solución ha sido elegir la variante de teclado compuesta us+us(intl), que utiliza como base el us(basic) y allí donde éste no llega le añade el us(intl).

Así, la sección correspondiente del fichero /etc/X11/xorg.conf la he modificado de

Section "InputDevice"

# keyboard added by rhpxl
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

a
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us+us(intl)"
EndSection

lunes, 1 de septiembre de 2008

El estrangulador del procesador

Los procesadores modernos (me refiero a la familia de los x86) tienen una característica muy interesante: el estrangulador (throttling) del procesador.

Muchas veces hemos oído hablar de características de los procesadores para portátiles como la de bajar la frecuencia de trabajo cuando se utiliza la batería, para que dure más. Pero el caso es que hay otras características que nos ayudan a hacer lo mismo, y mejor. Se trata de los estados de throttling del procesador, que fuerzan al mismo, independientemente de lo cargado que se encuentre, a <<echarse a dormir>> parte del tiempo. Estos estados se identifican con la letra T. El Intel Centrino Duo T2400 de mi portátil, por ejemplo, tiene 8 de estos estados de estrangulamiento, desde el T0 hasta el T7. Cuando está en el estado T0 el procesador no descansa: siempre está ejecutando algo, aunque sea el <<ciclo idle>>, y por lo mismo además siempre está gastando energía. En el estado T4, por ejemplo, el procesador estará dormido el 50% del tiempo: todas las operaciones que el usuario (o el sistema) trate de hacer, incluso a la máxima frecuencia, tardarán el doble de lo que tardarían en el estado T0.

Hoy en día, con núcleos Linux como el 2.6.26 que tengo funcionando, con las implementaciones modernas de ACPI, el estrangulador no es la vía preferida para cambiar la capacidad (ni el consumo) del procesador. Para eso están los cambios de frecuencia (los estados P del procesador), que son lo que normalmente podemos cambiar con herramientas de usuario como KPowersave. Otro día hablaré más profundamente sobre los estados P, los estados T, los estados S, los estados C, los estados G e incluso los estados D.

Antiguamente, cuando no se podía cambiar la frecuencia de los procesadores, los estados T eran la única manera de hacer que gastaran menos. Como expliqué arriba, esto se consigue poniendo el procesador a dormir por cortos períodos de tiempo, que en mi caso pueden llegar al 88% del tiempo total, dejando sólo el 12% del tiempo para ejecutar realmente instrucciones. Hoy, normalmente no se cambian estos estados salvo en caso de emergencia térmica: si el procesador está sobrecalentado por exceso de trabajo (y una ventilación o disipación deficiente), el sistema puede estrangular el procesador para obligarle a gastar menos energía (y así generar menos calor) incluso bajo las demandas más altas por parte del usuario.

Pero se pueden cambiar a mano para ver sus efectos.

Los núcleos Linux de hoy en día están cambiando sus interfaces ACPI del tradicional /proc al nuevo /sys, pero este cambio todavía no ha finalizado y nos las tenemos que ver con ambos. Para los estados T, en particular, vamos a requerir trastear con los ficheros de /proc/acpi/processor/. En este directorio veremos que hay un directorio por cada núcleo de procesador: /proc/acpi/processor/CPU0/, /proc/acpi/processor/CPU1/, etc. Utilicemos /proc/acpi/processor/CPU0/ como ejemplo. En su interior veremos varios ficheros, de los cuales nos va a interesar, en este caso, /proc/acpi/processor/CPU0/throttling. Este fichero nos indica qué estados de estrangulamiento soporta nuestro procesador (8 en el ejemplo inferior), qué tiempo duerme el procesador en cada uno de ellos y qué estado está en uso actualmente:

$ cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%


En este ejemplo vemos que el sistema tiene 8 estados de estrangulamiento (state count), numerados de T0 a T7 (state available y la lista states), los tiempos de procesador activo de cada uno, del 100% activo (0% durmiendo) del T0 al 12% activo (88% durmiendo) del T7 (la lista states) y que el estado actual es el T0 (active state y el * en la lista states).

Se puede cambiar el estado a mano, siendo el superusuario, mediante una sencilla orden típica de /proc:

# echo 4 > /proc/acpi/processor/CPU0/throttling
o bien
# echo T4 > /proc/acpi/processor/CPU0/throttling
Si estás tratando de subirlo y no funciona, es que tu máquina está demasiado caliente y el sistema obliga al estrangulador a bajar el consumo para generar menos calor. Recuerda que cada watio gastado es un watio de calor que hay que sacar del sistema. Si sacas menos calor del que generas, el sistema se calienta y puede quemarse.

Un ejemplo: poner mi portátil sobre una esterilla aislante y poner la máquina a calcular hashes para el aMule pone la máquina en T7 independientemente de lo que yo haga. Simplemente levantarla 1cm de la esterilla aislante con unas pinzas de la ropa lleva al sistema a T4 casi inmediatamente y a T0 en unos 30 segundos. Y además en T0 el sistema responde mejor ;)

lunes, 28 de julio de 2008

Información sobre la batería

Recientemente los núcleos de Linux han dejado de proporcionar la información de la batería que antes se encontraba en /proc/acpi/battery/BAT0 y ahora se considera que utilizar /proc para esas cosas está desaconsejado, debiéndose utilizar /sys. Pero por ningún sitio encontré información sobre en qué sitio de /sys se encuentra ahora esa información.

Y positivamente no es en /sys/bus/acpi, /sys/firmware/acpi ni /sys/module/acpi.

Después de mucho buscar (incluso buceando en los parches de varias herramientas para adaptarse al cambio) lo he encontrado: /sys/class/power_supply.

jueves, 3 de julio de 2008

My Review of Sun Fire X4600 Server

Originally submitted at Sun Microsystems

The Sun Fire X4600 server, featuring AMD Opteron processors, packs the punch of two Xeon 4P servers in a more space-efficient and energy-efficient system for tremendous operating cost savings. Its modular design makes upgrading to future processor technologies simple and non-disruptive. The server'...


Insufficient disk space

By Noel "Envite" Torres from Valencia, Spain on 7/3/2008

 

4out of 5

Pros: Fast, Up to 8 Quad, Easy Set Up

Cons: Bulky, Small disk space

Best Uses: Science

Describe Yourself: Quality Oriented

At Universidad de Valencia we bought this machine for scientific simulations. We're very happy with it's ease of installation and configuration, and with it's calculating power with 8 Quad (that's 32 processors).
But the hard disk is absolutely insufficient. Best possible configuration is 576GiB which is by no means sufficient for a normal simulation in Physics.

I wrote a core complete review (in spanish) at my blog in http://denvite.blogspot.com/2008/07/maravilloso-sunfire.html

(legalese)

Maravilloso SunFire

Hoy hemos instalado otra máquina con cuatro procesadores AMD Quad Core de 64 bits como los del TYAN que comentaba ayer. Esta vez, la máquina es una SunFire X4600 M2, de Sun Microsystems. Ha salido más cara por procesador, sin ninguna duda, pero a cambio me gusta más.

Una de las cosas que hacen, sin género de dudas, que esta máquina me guste más que la anterior es su procesador de servicio. Una pequeña tarjeta adicional integrada en la máquina que permite, incluso con la máquina apagada, con tal de que tenga corriente, ver el estado del hardware, encender la máquina, apagarla, reiniciarla, etc. No me cabe ninguna duda de que los fallos que ha estado teniendo la otra máquina, que tiene, repito, los mismo procesadores, caso de que se reprodujeran en esta máquina, hubieran sido más sencillos de atender. Con la otra máquina, cada vez que notábamos que la máquina no respondía, alguien tenía que acercarse a ver qué pasaba y darle al botón. Ahora, si notáramos lo mismo, podríamos conectar al procesador de servicio <<desde la playa>> y ver qué estaría ocurriendo, y en su caso, podríamos reiniciar la máquina sin tener que ir allí. Salvo, claro está, que el problema fuera un corte de luz para todo el armario. Todo eso gracias al sistema ILOM del procesador de servicio, que nos permite, además, acceder por red (HTTP, SNMP y SSH) o por consola serie.

Otra de las grandes ventajas, a mi entender, del SunFire X4600 M2 sobre el ordenador que comentaba ayer es la manera que tiene de organizar los procesadores y la memoria. Allí, cuatro procesadores iban en la placa base, y cuatro en una especie de <<placa base de expansión>>. Aquí los procesadores van, con su memoria asociada, en placas verticales, todas iguales (no cuatro preferentes y cuatro secundarios) que encajan en la placa base individualmente. Aparte de hacer más sencillo el cambio de un procesador (tan tonto como sacar una placa vertical, como se ve en la foto), encuentro el diseño más elegante y mejor pensado.

Otras ventajas, más secundarias desde mi punto de vista, son las cuatro tarjetas de red Gigabit, las cuatro fuentes de alimentación redundantes colocadas en vertical (el otro las tiene en horizontal), los cuatro ventiladores extraíbles (el otro tiene tres, y no forman túnel de aire) y el hecho de que la colocación de las placas de procesador evita una de las pesadillas de un administrador de sistemas en verano: que se estropee un ventilador de procesador. Al X4600 no se le pueden estropear porque no tiene: la ventilación frontal formando túnel de aire, con los procesadores (y sus disipadores de rejilla) justo detrás, hace todo el trabajo.

Entre lo malo está que, a consecuencia de lo anterior, se trata de una máquina que ocupa 4U.


Lo peor, los discos duros. Son discos SAS (eso es una <<Cosa Buena>> ®) pero de 2,5 pulgadas, lo que no permite tener los grandes discos propios de las máquinas de cálculo científico. El mayor disco soportado es de 146GiB, lo que nos da una capacidad total máxima de 576GiB, claramente insuficiente para cálculos científicos masivos, ya que una configuración normal para simulaciones científicas puede tener perfectamente seis discos de 500GiB cada uno. Y no es raro oír acerca de espacios de disco aún mayores. Total, que hemos acabado (gracias $DEITY por darnos RAID) con un espacio de disco de aproximadamente medio TiB para almacenar los resultados.

Eso sí, la instalación de la nueva OpenSuSE 11, recién salida del horno, con su flamante KDE 4, fue una delicia. En un ratito tuvimos la máquina completamente instalada, sin problemas de reconocimiento de <<hardware>> ni nada que se le pareciera. Ya está trabajando, y de momento no se ha caído.

miércoles, 2 de julio de 2008

Algo huele a podrido en OpenSuSE 10

TYAN Transport VX50Una de las cosas que más ocupado me ha tenido estas últimas semanas es un ordenador que se quedaba bloqueado porque sí.

Se trata de una máquina TYAN (un Transport VX50), que venía del distribuidor (una pequeña empresa local, que lo montó en instaló el S. O.) con una placa base TYAN (la Thunder n4250QE (S4985-E)) para cuatro procesadores AMD Quad Core de 64 bits, y una placa de expansión de la placa base también TYAN (la M4985), para montar un total de 8 procesadores de núcleo cuádruple y 128GiB de memoria. Ah, y 8TB de disco.

¿A que mola? El caso es que la máquina, que venía del distribuidor con OpenSuSE 10 (la 11 no había salido aún), se quedaba bloqueada. Como suena. Simplemente estaba trabajando y de repente dejaba de responder. Todo. Ni contestaba al PING ni se veía nada en la pantalla. Y los leds del teclado, parpadeando.

Pensamos que era cosa de la temperatura, así que subimos la velocidad de los ventiladores en la BIOS. Se siguió cayendo.

Pensamos que era cosa del ECC, así que lo desactivamos en la BIOS. No estamos seguros, quizá se caía menos, pero se siguió cayendo.

Pensamos que era cosa de la memoria, así que le corrimos un memtest durante un fin de semana. Con 128GiB pues solamente le dió una vuelta a la memoria, pero estaba limpia. Otras pruebas en la que obligamos a la máquina a swapear de mala manera con cargas del orden de 400 no hicieron caerse la máquina.

Finalmente hemos pensado que fuera cosa del entorno gráfico. A fin de cuentas, ¿quién sabe? ¿Y qué falta hace un entorno gráfico en una máquina de cálculo científico? Hemos desactivado el entorno gráfico pasando el nivel de ejecución del 5 al 3. Y la máquina lleva dos días calculando sin parar.

¿Habremos acertado ya?

Lo peor es que si fuera eso, algo en OpenSuSE 10 (en su entorno gráfico, en particular) no está nada bien. Y de ser así, mi candidato a culpable es earlyxdm.

viernes, 27 de junio de 2008

Pongamos un SAI al mundo

Un ordenador.

Una subida de tensión.

¿Qué tenemos? Ordenador frito.

Y sabiendo el estado de la red eléctrica nacional, y más en estas fechas en que todo el mundo enciende el aire acondicionado, debería ser obligatorio que el dinero que salga de mis impuestos esté protegido, ¿no?

Me refiero a que debería ser obligatorio que los ordenadores de las instituciones públicas tuvieran SAIs (o mejor SS.A.I.) para evitar las pérdidas causadas por picos o apagones.

Pero bueno, el caso es que he conseguido 10 SSAI para proteger algunos de los ordenadores de quien ahora mismo hace como que paga mis facturas: el Departamento de Astronomía y Astrofísica de la Universidad de Valencia. Deberían haber sido prácticamente el doble, pero todavía hay gente que considera que el material de trabajo de <<su>> puesto de trabajo es suyo. Y se equivocan, pero yo no puedo obligarlos a hacer las cosas bien. Algunos me han dicho, incluso: <<¿SAI? Ni tengo ni quiero.>> Debería ser delito de malversación de caudales públicos.

Eso sí, cuando venga otro apagón generalizado, a mí que no vengan a quejárseme.

Bueno, a lo que íbamos. Ya he instalado el primero de esos SSAI. Un ordenador que antes estaba desprotegido, ahora está protegido.

El programa de elección para efectuar el apagado del ordenador ha sido Network UPS Tools (NUT), en su versión 2.2

El SAI elegido es un APC Back-UPS CS 500. No proporciona mucha autonomía a un ordenador grande con su pantalla, pero la idea no es proporcionar autonomía, sino evitar un casque por un mal apagado, de los que ya hemos tenido por aquí.

Me hubiera gustado elegir otra marca de SSAI. Las APC tienen buenas y malas costumbres. Entre las buenas, que son fiables como rocas y que tienen asegurado el suministro de baterías de recambio. Entre las malas, que no colaboran con los programadores de programas libres y tratan de obligarte a utilizar su pesado y patético programa PowerChute.

Gracias a $DEITY los SSAI de la serie CS se pueden enchufar por el puerto USB y responden aceptablemente al controlador usbhid-ups de NUT.

Así, tras bajar NUT y realizar los típicos ./configure, make y make install (lamentablemente el ordenador a proteger dispone de una distribución que no tiene paquetes para NUT), obtuve un precioso y funcional sistema. Luego fue cosa de tocar un poco los ficheros de configuración.

Como nota, el SAI informa de batería en estado crítico cuando se encuentra al 10% de su capacidad, lo que no da tiempo al ordenador para apagarse correctamente. Por ello, he tenido que utilizar la última pieza del conjunto, upssched, diseñada específicamente para apagar el sistema antes de que se alcance la condición de batería en estado crítico.

martes, 24 de junio de 2008

Algunas verdades

Una imagen...

Diseños de teclado

A consecuencia de una pregunta de un compañero, he pasado hoy buena parte de la tarde mirando documentación (ciertamente escasa) sobre el sistema XKB. Se trata de la capa que transforma las pulsaciones de teclas en símbolos que entienden las aplicaciones. Además, he mirado no solamente la propia documentación (sobre todo la muy completa de Ivan U. Pascal y la muy comprensible de Doug Palmer) sino los propios ficheros de definiciones y reglas de XKB. Allí me he dado cuenta de que existe un modelo de teclado llamado «latitude», equivalente en casi todos los aspectos al «pc105» que se supone que debería usar, solo que tiene correctamente asignadas las teclas 174, 176 y 160, es decir, <I2E>, <I30> e <I20> a las «pseudoteclas» XF86AudioLowerVolume, XF86AudioRaiseVolume y XF86AudioMute.
Así, sólo con haber cambiado el modelo de mi teclado en /etc/X11/xorg.conf de


Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
EndSection

a

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "latitude"
Option "XkbLayout" "es"
EndSection

he conseguido que funcionen las teclas para subir o bajar el volumen.

viernes, 13 de junio de 2008

Blog de Toscalix en castellano

Bueno, hace mucho que no escribo en la desbitácora, al contrario que en la bitácora. Pero no ha sido por falta de trabajo, sino al contrario.

Pero en fin, al grano. He inaugurado la sección de Enlaces (quizá) interesantes (al fondo a la derecha, como el servicio) con la bitácora de un amigo y ex-jefe, Agustín Benito.

Él no es desarrollador, al contrario de lo que podría parecer ya que enlazo su bitácora en castellano (tiene otra en inglés) desde aquí. Es una cosa rara. Yo lo llamaría un intermediador. Busca gente que necesite programas libres, y tiene contacto con gente que hace o gestiona programas libres. Y gana dinero en el proceso. Bien es verdad que no demasiado: en ese plan tuvo una empresa en la que yo trabajaba. Éramos solamente nosotros dos, y la relación tenía una parte de jefe-empleado, obviamente, y otra parte de comercial-técnico. Yo a veces decía que él trabajaba para mí, como comercial de mis soluciones técnicas, y además me pagaba.

Finalmente yo me vine a la Universidad de Valencia a mantener sistemas y acabar de una vez mi doctorado, y él, dado que no se puede mantener una empresa técnica sin un técnico, cerró. Por el camino hicimos varias cosas interesantes, y a veces uno debe pararse y mirar atrás.

En colaboración con otras miniempresas como Neuroomante de Pedro Gracia (Lasarux) desarrollamos una solución de aula LTSP con UML para docencia informática que era un primor. O las soluciones de firma de discos duros que están en esta misma desbitácora. Pero no siempre había clientes, y había que comer todos los meses (él vivía de ello, y yo trabajaba a media jornada), y también nos tocó «pringar» con cuestiones de mantenimiento de sistemas Windows, casi siempre piratas, subcontratados para empresas de nuestro mismo estilo pero un poco más grandes, o instalar cableado.

En esa época aprendí mucho, no sólo como técnico (lo que debo agradecer sobre todo a Lasarux, Kuko y la gente más antigua de Fotón, ustedes saben quienes son, chicos, gracias por todo), sino sobre cómo llevar (y cómo no llevar) una empresa o un proyecto basados en programas libres. Toscalix, a su vez, creo que aprendió de mí algo de filosofía libre (no demasiado, porque interferiría en su trabajo, que es ganar dinero con ello), algo de sistemas, y sobre todo de cómo trabajar con programas libres y montar redes. O al menos eso quiero creer.

Bueno, la etapa ha acabado. Ahora yo, con todo lo que aprendí con él, mantengo ordenadores de cálculo científico en Valencia, y él, con todo lo que aprendió conmigo, trabaja en un proyecto de migración a programas libres en una comarca de Málaga. Y seguimos pensando diferente, y seguimos siendo amigos.

Como nos enseña la mecánica cuántica, quizá nuestros caminos (profesionales) nunca se vuelvan a cruzar, pero habernos cruzado ha alterado nuestras historias para siempre.

jueves, 17 de enero de 2008

Gráficos en TeX

Últimamente he tenido que escribir un trabajo académico. Lo he hecho en TeX porque me maravilla la capacidad tipográfica que tiene y la calidad del resultado final.

La mayor parte de los usuarios de TeX, en realidad, son usuarios de LaTeX. Si TeX hace el trabajo del cajista, LaTeX hace el del tipógrafo-compositor. En mi caso particular, prefiero utilizar TeX en vez de LaTeX (me gustan las cosas a bajo nivel).

Claro que TeX no está directamente preparado para soportar gráficos. Knuth, previendo la diversidad de dispositivos de salida y de tipos de gráficos, tan sólo diseñó la orden \special como una manera genérica de enviar datos a dispositivos de salida. LaTeX quedó mejor en ese sentido.

Fianlmente, la almendra del asunto es que los que usamos TeX, a pelo, también queremos poner gráficos en nuestros trabajos. Y no queremos lidiar con los \special. Esta semana he descubierto que la solución la aporta graphics-pln, gracias al cual podemos utilizar en TeX comandos de LaTeX como \includegraphics o \rotatebox.

La instalación de graphics-pln no merece siquiera tal nombre. Basta con descargar el fichero graphics.zip y descomprimirlo en el directorio de trabajo del documento. A partir de ahí, ya se pueden usar directamente las órdenes gráficas habituales.

En otra entrega hablaré de modos más generales de instalación.