Hardware on Marco Antonio Blanco

Obteniendo informacion del sistema desde consola e IRC con inxi

Wed, 08 Oct 2014 10:33:55 +0000

No hace mucho publiqué una serie de artículos sobre cómo obtener información del hardware de un sistema Linux en producción sin necesidad de pararlo. Recientemente me he topado con otra herramienta que nos sirve para esta tarea: inxi, un script que recaba información completa sobre el hardware y el software más importante de un sistema y lo muestra en consola o, si así lo configuramos, a través de IRC.

La instalación de inxi es muy sencilla y en su web oficial se encuentran las instrucciones para las distribuciones Linux más populares, si no se encuentra instalado ya de serie como es el caso de Linux Mint y otras.

Para su instalación en Debian, tendremos que seguir pasos diferentes dependiendo de la versión que tengamos instalada. Si usamos Jessie o posterior, tenemos un paquete a nuestra disposición en los repositorios oficiales, por lo que bastará con el siguiente comando:

# apt-get install inxi

Sin embargo, en el caso de Wheezy (la actual versión estable), hay que descargarse el paquete e instalarlo a mano. Primero, accedemos al repositorio de inxi en Jessie y nos lo descargamos del servidor que queramos. Después, instalaremos con este comando:

# dpkg -i inxi_2.1.28-1_all.deb

La forma más sencilla y directa de utilizar inxi es invocarlo directamente sin parámetro alguno:

# inxi
CPU~Dual core AMD A6-5400K APU with Radeon HD Graphics (-MCP-) clocked at Min:1400.000Mhz Max:3600.000Mhz Kernel~3.16-0.bpo.2-amd64 x86_64 Up~16:29 Mem~1798.6/7406.1MB HDD~4000.8GB(19.8% used) Procs~190 Client~Shell inxi~2.1.28

La salida de inxi por defecto es a color, por lo que si nos resulta molesto podemos o bien cambiar el esquema de color utilizado con el parámetro -c, que admite un número de 0 a 32, donde 0 lo desactiva completamente. El otro parámetro genérico es -v, que aumenta el nivel de detalle de la salida de inxi según el valor que le indiquemos entre 0 (mínimo) y 7.

El resto de parámetros están dedicados a obtener información específica sobre componentes hardware concretos, lo que podemos consultar en el manual electrónico (man inxi) de inxi. Por ejemplo, si queremos información sin color sobre la CPU y la tarjeta gráfica:

# inxi -C -G -c0
CPU: Dual core AMD A6-5400K APU with Radeon HD Graphics (-MCP-) cache: 2048 KB 
 Clock Speeds: 1: 1900 MHz 2: 1400 MHz
Graphics: Card: Advanced Micro Devices [AMD] ATI Device 9991
 Display Server: N/A driver: N/A tty size: 177x25 Advanced Data: N/A for root out of X

En cuanto al uso de inxi a través de IRC, basta con que lo integremos con nuestro cliente IRC favorito y recibiremos la información de nuestros sistema a través suyo. En el wiki oficial del proyecto se habla de los clientes IRC más populares. Por ejemplo, para integrar inxi con Konversation en KDE4:

# ln -s /usr/local/bin/inxi /usr/share/kde4/apps/konversation/scripts/inxi

En el poco tiempo que llevo probándolo, inxi me está resultando muy útil y es más que probable que termine definitivamente formando parte de mi “caja de herramientas” de administración de sistemas. Si lo probáis, no dudéis en compartir vuestra experiencia con inxi.

Cómo recuperar ficheros de discos defectuosos bajo Linux

Thu, 20 Feb 2014 14:38:50 +0000

En un artículo anterior describía unos procedimientos para comprobar la salud de los discos duros de un sistema Linux. El objetivo de dicho artículo era descubrir si los discos presentaban algún tipo de problema físico, recomendando su sustitución lo antes posible. Sin embargo, ¿qué hacemos si queremos recuperar ficheros que tienen partes de los mismos residiendo en sectores defectuosos? Veámoslo, teniendo en cuenta que la información que se encuentre en dichos sectores tiene una alta probabilidad de ser irrecuperable. En este caso, al menos podemos intentar recuperar el contenido accesible, que podemos editar a posteriori.

El método consiste en realizar una copia del fichero con tolerancia a fallos, de forma que cuando se produzca un error de lectura el procedimiento siga adelante y recupere al final la información que sí ha podido leer sin problemas. Para ello contamos con una herramienta clásica de UNIX, el comando dd, tan útil como peligroso si no lo utilizamos bien.

En el caso que nos ocupa, tendremos que indicarle a dd el fichero a recuperar, el destino en el que guardaremos el contenido recuperado y que debe realizar la copia con tolerancia a errores de lectura. El comando completo, que hay que ejecutar como root, sería el siguiente:

# dd if=/home/usuario/fichero of=/media/usbdrive/fichero_limpio conv=noerror,sync

Como se puede ver, la salida se realiza en un dispositivo diferente al disco defectuoso (por ejemplo, un pendrive) para evitar males mayores.

Una vez terminada la copia, sólo resta desechar el disco y sustituirlo por otro en buenas condiciones. POr cierto, debido a los errores de lectura, la copia con dd puede tardar bastante tiempo en llevarse a cabo, sobre todo dependiendo del tamaño del fichero original y de la cantidad de sectores defectuosos por los que hay que pasar. En definitiva, que hay que armarse de paciencia.

Si no queremos deshacernos del disco problemático (por ejemplo, forma parte de un RAID, no tenemos recambio a mano o simplemente lo queremos reutilizar), existe una opción que hay que utilizar como último recurso, ya que se trata de un procedimiento que elimina la información del sector y que tiene un alto grado de riesgo destructivo para todo el sistema de ficheros. Se trata de forzar la relocalización dinámica de sectores defectuosos, algo que los discos suelen llevar a cabo de forma automática por su cuenta pero que en esta ocasión vamos a obligarle a hacer.

Para ello contamos con la herramienta hdparm, la cual ya mencionamos en el artículo anterior. Pero antes de comenzar con la relocalización, comprobaremos si el disco ya ha reasignado sectores en el pasado. Hay que tener en cuenta que cada disco duro ofrece un número máximo de sectores de reserva y que si se ha agotado este procedimiento será inútil. El comando es el siguiente:

# smartctl -a /dev/sda | grep -i reallocated
 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0

Si nos fijamos en el último dato, vemos que está a cero, lo que indica que nunca se han relocalizado sectores en el disco. En el ejemplo del artículo anterior, la cuenta estaba en 10640, una mala noticia sin duda.

El siguiente paso es confirmar que el supuesto sector defectuoso tiene realmente problemas de lectura. Siguiendo en el ejemplo del otro artículo, el comando es como sigue:

# hdparm --read-sector 2307480536 /dev/sda

/dev/sda:
reading sector 2307480536: FAILED: Input/output error

Efectivamente, el sector es defectuoso, así que podemos proceder a relocalizarlo:

# hdparm --write-sector 2307480536 /dev/sda

/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

# hdparm --write-sector 2307480536 --yes-i-know-what-i-am-doing /dev/sda

/dev/sda: re-writing sector 2307480536: succeeded

Como comentaba más arriba, hdparm nos avisa de que se trata de una operación peligrosa porque estamos escribiendo en el disco duro a bajo nivel saltándonos los mecanismos estándares de escritura de bloques del sistema de ficheros residente.

Si la operación anterior tiene éxito, podemos comprobar el resultado:

# hdparm --read-sector 2307480536 /dev/sda

/dev/sda:
reading sector 2307480536: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
...
(siguen muchas líneas con ceros a continuación)

# smartctl -a /dev/sda | grep -i reallocated
 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 1

Vemos que el sector vuelve a estar disponible para su uso y que la cuenta de sectores relocalizados ha aumentado en uno.

Ahora sólo es cuestión de decidir si seguimos con el disco adelante, lo reutilizamos para datos menos importantes o lo tiramos a la basura directamente.

Comprobando la salud de los discos duros en un sistema Linux

Fri, 22 Nov 2013 13:13:29 +0000

En los últimos meses nos hemos visto en la tesitura de tener que sustituir discos duros defectuosos en diversos servidores cuyo mantenimiento caen bajo nuestra responsabilidad, algunos con acceso local y otros sólo con acceso remoto por encontrarse geográficamente en otros países. Afortunadamente todos esos servidores corren Linux, lo que facilita enormemente la tarea de detectar fallos en discos duros, proceder a su parada y sustituirlos por otros nuevos, integrándolos transparentemente en el RAID que solemos implementar en nuestros servidores.

¿Cómo se detecta que un disco es defectuoso? La primera pista nos la va a dar un cambio drástico en el servidor: bajada de rendimiento, problemas de acceso a ficheros, servicios caídos, etc. Es en ese momento cuando debemos pasar a comprobar la salud de los discos duros del sistema y descubrir cuál (o cuales) es el que tiene problemas.

La forma más directa y sencilla de comprobar si un disco duro está teniendo problemas es consultar el registro de los mensajes del núcleo con el comando dmesg. Ahí buscaremos referencias a errores de acceso a disco, problemas en las operaciones de lectura/escritura, menciones a relocalización de sectores, etc.

# dmesg | less
...
ata2.00: failed command: READ FPDMA QUEUED
ata2.00: cmd 60/08:00:d8:5b:89/00:00:89:00:00/40 tag 0 ncq 4096 in
 res 41/40:08:d8:5b:89/00:00:89:00:00/00 Emask 0x409 (media error)
ata2.00: status: { DRDY ERR }
ata2.00: error: { UNC }
sd 1:0:0:0: [sdb] Unhandled sense code
sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 89 89 5b d8 00 00 08 00
end_request: I/O error, dev sdb, sector 2307480536
...

En el ejemplo vemos que el disco problemático es sdb. Igualmente sencillo es comprobar si se ha caído algún disco del RAID del servidor:

# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active raid1 sda4[2] sdb4[1](F)
 1839220031 blocks super 1.2 [2/1] [U_]

De nuevo comprobamos que sdb es el culpable. Sin embargo, al tratarse de servidores, la forma más adecuada de detectar fallos en los discos es mediante la prevención a través de un sistema de monitorización al que incorporemos los controles necesarios, normalmente basados en la tecnología S.M.A.R.T. que se encuentra presente en los discos duros desde hace ya muchos años.

El soporte S.M.A.R.T. en Linux se consigue a través del paquete smartmontools, que permite controlar y monitorizar sistemas de almacenamiento utilizando dicha tecnología. De hecho, se incluye un demonio que nos avisa inmediatamente si se producen errores en alguno de los discos monitorizados.

Una vez identificado el disco defectuoso procedemos a comprobar su salud mediante smartctl, una herramienta de línea de comandos incluida en smartmontools. Con esta utilidad podremos no sólo obtener detallada información sobre el disco, sino además llevar a cabo completos tests que nos mostrarán si es defectuoso y cuál es el defecto concreto. Veamos unos ejemplos.

Para obtener información sobre un disco tenemos a nuestra disposición varios parámetros. Si queremos información sobre el hardware:

# smartctl -i /dev/sdb
=== START OF INFORMATION SECTION ===
Device Model: ST...
Serial Number: W...
Firmware Version: C...
User Capacity: 3,000,592,982,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Fri Nov 22 12:33:54 2013 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Podemos ampliar estos datos con la información SMART del disco duro con el parámetro -a. Si en cambio usamos -x, la salida del comando incluirá la información que no proviene de SMART.

# smartctl -a /dev/sdb
=== START OF INFORMATION SECTION ===
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
 was never started.
 Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
 the read element of the test failed.
...
SMART Attributes Data Structure revision number: 10
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 107 098 006 Pre-fail Always - 186855524
 3 Spin_Up_Time 0x0003 093 093 000 Pre-fail Always - 0
 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 8
 5 Reallocated_Sector_Ct 0x0033 092 092 036 Pre-fail Always - 10640
 7 Seek_Error_Rate 0x000f 083 060 030 Pre-fail Always - 219208774
...

Si alguno de los anteriores comandos falla, podemos añadir el parámetro -T permissive (e incluso -T verypermissive) para intentar que smartctl ignore los errores que pueda y obtenga toda la información posible del disco.

Pasemos a lo realmente interesante: la realización de tests en los discos duros. La primera y más sencilla opción que tenemos a nuestra disposición es el parámetro -H, que nos informa de la salud SMART del disco.

# smartctl -H /dev/sdb
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Esta opción sólo indica que la salud es mala cuando el disco ya ha fallado o va a fallar en las próximas 24 horas. Podemos ver en el ejemplo que, a pesar de que sdb es defectuoso, se nos informa de que la salud SMART del disco es buena.

Para detectar el problema del disco en detalle contamos con el parámetro -t, que a su vez admite un argumento que indica el tipo de test a realizar: offline, short, long y conveyance. Todas estas pruebas se pueden realizar con el sistema en producción, a menos que usemos el parámetro -C, que las ejecuta en modo cautivo (no tiene efecto en tests de tipo offline). Este modo sirve para realizar las pruebas más rápidamente y tiene especial utilidad cuando la máxima prioridad es comprobar la salud del disco. La explicación en detalle de cada uno de estos tests se encuentra en el manual electrónico de smartctl.

Excepto en el mencionado modo cautivo, los tests se realizan en segundo plano, por lo que no obtenemos ninguna información por pantalla a menos que la pidamos explícitamente con el parámetro -l selftest. Dado que esto sólo nos muestra un instante del progreso del test, es interesante combinarlo con el comando watch, que por defecto realiza la tarea que le asignemos cada dos segundos. Veamos un ejemplo:

# smartctl -t short /dev/sdb
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after ...

Use smartctl -X to abort test.

# watch smartctl -l selftest /dev/sdb
Every 2,0s: smartctl -l selftest /dev/sdb

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 15073 2307480536

¡Eureka, hemos encontrado el defecto del disco sospechoso! Se trata de un error de lectura en al menos un sector del disco, siendo el primero detectado el especificado en la salida de smartctl. Ahora sólo queda cambiarlo por uno nuevo y llevar el defectuoso al fabricante a que nos lo cambie (si está en garantía, claro). Por cierto, en el ejemplo vemos cómo se nos informa de que podemos abortar cualquier test con smartctl -X.

Como curiosidad, si necesitamos conocer el modelo y número de serie del disco para el trámite con el fabricante, podemos obtenerlos con este sencillo comando (además de con smartctl -i):

# hdparm -i /dev/sdb | grep SerialNo
 Model=ST..., FwRev=C..., SerialNo=W...

¡Suerte con los discos duros!

Comprobando el hardware de un servidor Linux sin abrirlo: pequeñas utilidades de línea de comandos (y IV)

Tue, 22 Oct 2013 10:36:53 +0000

Para terminar esta serie de artículos sobre herramientas software para conocer el hardware de un servidor que esté en producción sin pararlo ni abrirlo, quiero dedicar este artículo a enumerar una serie de sencillas utilidades de línea de comandos que sólo hacen una tarea pero la hacen de una manera muy especializada y eficiente, lo que las convierten en realmente útiles para el administrador de sistemas.

lspci

lspci es una herramienta que lista todos los dispositivos PCI presentes en el sistema.

# lspci
00:00.0 Host bridge: Intel Corporation Device 0150 (rev 09)
00:01.0 PCI bridge: Intel Corporation Device 0151 (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 09)
00:14.0 USB Controller: Intel Corporation Device 1e31 (rev 04)
00:16.0 Communication controller: Intel Corporation Device 1e3a (rev 04)
00:1a.0 USB Controller: Intel Corporation Device 1e2d (rev 04)
00:1c.0 PCI bridge: Intel Corporation Device 1e10 (rev c4)
00:1c.4 PCI bridge: Intel Corporation Device 1e18 (rev c4)
00:1d.0 USB Controller: Intel Corporation Device 1e26 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Device 1e4a (rev 04)
00:1f.2 SATA controller: Intel Corporation Device 1e02 (rev 04)
00:1f.3 SMBus: Intel Corporation Device 1e22 (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)

Gracias a la gran cantidad de parámetros que admite, podemos controlar el nivel de detalle y la forma de presentar la información que nos devuelve lspci. Por ejemplo, -k nos indica el módulo del kernel que gestiona cada dispositivo, -t nos muestra los dispositivos en un árbol, -m saca la información en un formato fácilmente analizable por scripts y -v nos da información detallada sobre cada dispositivo (podemos poner hasta tres v para aumentar el nivel de detalle).

# lspci -k
00:00.0 Host bridge: Intel Corporation Device 0150 (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: agpgart-intel
00:01.0 PCI bridge: Intel Corporation Device 0151 (rev 09)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
00:14.0 USB Controller: Intel Corporation Device 1e31 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation Device 1e3a (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
...

# lspci -t
-[0000:00]-+-00.0
+-01.0-[01]--
+-02.0
+-14.0
+-16.0
+-1a.0
+-1c.0-[02]--
+-1c.4-[03]----00.0
+-1d.0
+-1f.0
+-1f.2
\-1f.3

lsusb

lsusb realiza un trabajo similar pero con el subsistema USB y los dispositivos conectados.

# lsusb
Bus 002 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

lsusb cuenta con un menor número de parámetros que modifican su salida pero son igualmente útiles. Por ejemplo, -t nos muestra los dispositivos en un árbol, -v nos da información detallada y -s y -d muestran sólo los dispositivos especificados por bus y dispositivo o por identificador de fabricante, respectivamente.

# lsusb -d 046d:c50e -v
Bus 002 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc50e Cordless Mouse Receiver
...

ethtool

ethtool sirve para mostrar o cambiar la configuración de los interfaces de red. Esta herramienta necesita de al menos un argumento para trabajar (el interfaz de red a consultar) y de parámetros que indiquen qué información requerimos.

# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes

# ethtool -i eth0
driver: forcedeth
version: 0.64
firmware-version:
bus-info: 0000:00:08.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

# ethtool -S eth0
NIC statistics:
tx_bytes: 266807800
tx_zero_rexmt: 333342
tx_one_rexmt: 0
tx_many_rexmt: 0
tx_late_collision: 0
...

# ethtool -t eth0
The test result is PASS
The test extra info:
link (online/offline) 0
register (offline) 0
interrupt (offline) 0
loopback (offline) 0

dmesg

dmesg es un comando que nos muestra el contenido del registro del núcleo, lo que implica que al comienzo se encuentra toda la información relativa a la detección del hardware. Personalmente recomiendo su invocación de la siguiente manera para no mostrar las marcas de tiempo del núcleo y paginar la exhaustiva información que se nos va a mostrar en pantalla:

# dmesg -t | less
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.9-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.9.6-1~bpo70+1
Command line: BOOT_IMAGE=/boot/vmlinuz-3.9-0.bpo.1-amd64
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
...
NX (Execute Disable) protection: active
SMBIOS 2.3 present.
DMI: /M55S-S3, BIOS FB 01/10/2007
No AGP bridge found
...
ACPI: RSDP 00000000000f6260 00014 (v00 GBT )
ACPI: RSDT 00000000cfff3000 00038 (v01 GBT NVDAACPI 42302E31 NVDA 01010101)
...
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
ehci-pci: EHCI PCI platform driver
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21
forcedeth 0000:00:08.0: setting latency timer to 64
forcedeth 0000:00:08.0: ifname eth0
...

/proc

Para terminar el artículo, quiero hablar de /proc, que no es una herramienta en sí, sino el sistema de ficheros a través del cual se puede interactuar con el núcleo en vivo. Por tanto, podemos utilizar los comandos habituales tanto para consultar información como para modificarla al vuelo. Veamos varios ejemplos de uso de /proc para conocer el hardware del sistema.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping : 9
microcode : 0x12
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq est ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes avx f16c rdrand hypervisor lahf_lm ida arat epb xsaveopt pln pts dtherm fsgsbase smep erms
bogomips : 6800.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

# cat /proc/meminfo
MemTotal: 19554776 kB
MemFree: 156468 kB
Buffers: 239696 kB
Cached: 18424088 kB
SwapCached: 5088 kB
Active: 9483528 kB
Inactive: 9367064 kB
Active(anon): 152516 kB
Inactive(anon): 34384 kB
Active(file): 9331012 kB
Inactive(file): 9332680 kB
Unevictable: 20 kB
Mlocked: 20 kB
SwapTotal: 33553332 kB
SwapFree: 33537992 kB
...

# cat /proc/partitions
major minor #blocks name

2 0 4 fd0
11 0 1048575 sr0
8 0 156289847 sda
8 1 1951744 sda1
8 2 97655808 sda2
8 3 56680448 sda3

Conclusión

Existen muchas más herramientas, como free, top, uname, lsmod, fdisk, etc. La lista es sencillamente interminable. Basta con hacer una sencilla búsqueda por Internet para encontrar pequeñas joyas como las que he comentado en este artículo, consultar su manual y añadirlas a nuestra “caja de herramientas” particular.

Con esta serie de artículos espero haber facilitado un poquito el día a día a mis colegas administradores de sistemas. Espero vuestros comentarios.

Comprobando el hardware de un servidor Linux sin abrirlo: OCS Inventory (III)

Thu, 19 Sep 2013 13:58:58 +0000

Las herramientas de las que he hablado hasta ahora en esta serie de artículos eran utilidades de línea de comandos dirigidas a descubrir de forma puntual qué hardware tiene un sistema en producción sin pararlo. Si lo que buscamos es algo más complejo más allá de una simple consulta de vez en cuando, que nos permita elaborar y mantener el inventario hardware y software de los sistemas a nuestro cargo, una gran opción es sin duda OCS Inventory.

Se trata de un completo entorno de gestión (de licencia libre) de los activos TIC de cualquier organización. Cuando se publicó por primera vez en 2001, OCS Inventory permitía la creación automatizada del inventario del hardware. A día de hoy ha evolucionado tanto que inventaria también el software, realiza escaneos de red e incluso permite la instalación distribuida de software. También incluye un sistema de plugins que permite ampliar las capacidades de serie de OCS Inventory. Aunque la lista de plugins disponibles no es muy extensa, ofrece la suficiente utilidad como para tenerlos en cuenta.

OCS Inventory se compone de tres elementos: un servidor, los agentes y las herramientas de distribución de software. El servidor es el elemento principal del entorno, gestionando la información y poniéndola a disposición de los administradores del sistema. Existen versiones tanto para Linux (y otros Unix) como para Windows.

Sin embargo, el servidor no serviría de nada sin los agentes, pequeños componentes software que se instalan en los dispositivos que queremos inventariar y gestionar a través del servidor y que nutren a éste con toda la información que puedan descubrir sobre el sistema en el que están instalados. Por la naturaleza de su función, en el caso de los agentes existen versiones para todos los sistema operativos más populares, incluyendo los de los smartphones y tablets (excepto iOS).

Por último se encuentran las herramientas de distribución de software, con versiones para Linux, Windows y MacOS, que permiten de una manera sencilla la instalación remota y controlada de programas en equipos que corran dichos sistemas operativos. Es sin duda una gran ayuda para los administradores de redes y una de las capacidades más celebradas de OCS Inventory.

Su instalación es realmente sencilla. Basta con dirigirnos a la sección de descargas de la web oficial y obtener las versiones adecuadas a los sistemas que vamos a gestionar. Sin embargo, lo más sencillo para instalar un servidor OCS Inventory es utilizar una distribución Linux en cuyos repositorios esté disponible.

Por ejemplo, en Debian empezaríamos con el servidor:

# apt-get install ocsinventory-server

y seguiríamos con la consola de administración, que se puede instalar en el mismo equipo que el servidor o en otro de nuestra elección:

# apt-get install ocsinventory-reports

Si accedemos mediante navegador a http://servidor_consola_admon/ocsreports , podremos proceder a configurar la consola de administración, indicando entre otras cosas dónde se encuentra el servidor de OCS Inventory.

Sólo restaría instalar los agentes en los equipos a monitorizar. En el caso de Debian sería así:

# apt-get install ocsinventory-agent

Durante la instalación debemos elegir http como método para generar el inventario e introducir el nombre o dirección IP del servidor OCS cuando se nos solicite.

Con esto OCS empezará de inmediato a escanear nuestra red y a recibir todo tipo de datos sobre la configuración de nuestros sistemas. Esta información se muestra poco después en la consola de administración. A partir de ese momento, OCS se encarga de mantener actualizada la información mediante escaneos periódicos, cuya frecuencia podemos configurar.

En definitiva, OCS Inventory se convierte en un importante aliado para los administradores de sistemas en sus tareas diarias. Es sencillo de instalar y a cambio ofrece un gran valor. Evidentemente no está pensado para consultas puntuales de información, ya que para ello están los comandos revisados en los artículos anteriores, pero sin duda OCS no debería faltar en ninguna red gestionada por buenos profesionales.

Comprobando el hardware de un servidor Linux sin abrirlo: dmidecode (II)

Fri, 09 Aug 2013 12:17:56 +0000

La segunda herramienta que nos va a permitir conocer la configuración del hardware de un sistema en producción sin tener que pararlo ni abrirlo es dmidecode. Al igual que hwinfo, se trata de una utilidad de línea de comandos. Sin embargo, en vez de sondear el hardware, dmidecode analiza la información almacenada en la BIOS en las tablas DMI y la muestra en pantalla.

Para instalar dmidecode en un sistema Debian, basta con seguir el procedimiento habitual:

# apt-get install dmidecode

La forma de utilizar dmidecode es muy sencilla y similar a la de hwinfo, es decir, invocamos el comando junto con un argumento que nos permitirá obtener la información concreta deseada. Evidentemente, si ejecutamos dmidecode sin argumentos, obtendremos toda la información disponible:

# dmidecode
SMBIOS 2.7 present.
109 structures occupying 3956 bytes.
Table at 0x000EB6C0.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: 0915
 Release Date: 07/27/2012
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 8192 kB
 Characteristics:
 PCI is supported
 BIOS is upgradeable
...

dmidecode tiene dos parámetros para seleccionar la información a mostrar, --string y --type. El primero obtiene el valor de la cadena DMI indicado por la palabra clave que hay especificar. Por ejemplo, para conocer la marca del procesador:

# dmidecode --string processor-manufacturer
Intel

Al contrario que hwinfo, sólo podemos utilizar un valor a la vez. La lista de palabras clave admitidas se puede consultar en el manual electrónico de dmidecode:

# man dmidecode

El parámetro --type muestra las entradas en la BIOS del tipo que especifiquemos, donde el tipo es o bien un número (pudiendo indicar más de uno separados por comas) o bien una palabra clave (de una lista que es distinta a la utilizada por --string). Por ejemplo, para conocer información sobre el sistema y la placa base:

# dmidecode --type 1,2
SMBIOS 2.7 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
 Manufacturer: System manufacturer
 Product Name: System Product Name
 Version: System Version
 Serial Number: System Serial Number
 UUID: XXX
 Wake-up Type: Power Switch
 SKU Number: SKU

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
 Manufacturer: ASUSTeK COMPUTER INC.
 Product Name: P8H77-M PRO
 Version: Rev X.0x
 Serial Number: XXX
 Features:
 Board is a hosting board
 Board is replaceable
 Chassis Handle: 0x0003
 Type: Motherboard
 Contained Object Handles: 0

Y para saber más sobre el chasis del servidor:

# dmidecode --type chassis
SMBIOS 2.7 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
 Manufacturer: Chassis Manufacture
 Type: Desktop
 Lock: Not Present
 Version: Chassis Version
 Serial Number: Chassis Serial Number
 Asset Tag: Asset-1234567890
 Boot-up State: Safe
 Power Supply State: Safe
 Thermal State: Safe
 Security Status: None
 OEM Information: 0x00000000
 Height: Unspecified
 Number Of Power Cords: 1
 Contained Elements: 0

Al igual que antes, la lista de tipos numéricos y palabras clave admitidas se puede consultar en el manual electrónico de dmidecode.

Como curiosidad, el paquete dmidecode incluye otras herramientas, destacando biosdecode, que analiza la memoria de la BIOS y muestra las estructuras de las que tiene conocimiento.

Para terminar dos advertencias. La primera es que dmidecode sólo muestra lo que la BIOS conoce, por lo que si se trata de un sistema de esos en los que la BIOS es muy espartana, es posible que no obtengamos todo lo que queremos conocer (típico de un sistema de marca). La segunda es que hay que tener cuidado al utilizarlo en un sistema en producción (aunque este sea su objetivo). Todo lo que suponga sondear el hardware está sujeto a una probabilidad (mínima) de provocar problemas en la plataforma y su caída.

Comprobando el hardware de un servidor Linux sin abrirlo: hwinfo (I)

Mon, 08 Jul 2013 13:43:00 +0000

Existen situaciones en las que es necesario conocer en detalle el hardware del que se compone un servidor del que no tenemos información pero que está en producción y que por tanto no se puede detener para abrirlo y ver sus “tripas”. Un caso muy típico es cuando es necesario ampliar la memoria RAM y no sabemos ni qué tipo admite su placa base ni cuantas ranuras están ya ocupadas. Si se trata de un servidor basado en Linux, tenemos varias herramientas a nuestra disposición para esta tarea. La primera de la que voy a hablar, por su sencillez de uso, es hwinfo.

Se trata de una utilidad de línea de comandos que es necesario ejecutar como administrador ya que de otra forma no tendremos los privilegios necesarios para acceder a la información del hardware. Para instalarlo en Debian basta con ejecutar:

# apt-get install hwinfo

Si se invoca directamente hwinfo sin ningún parámetro, veremos como se pone inmediatamente a detectar el hardware del servidor, tras lo cual muestra en pantalla un informe completo sobre el mismo. Como esta información suele ser muy extensa, lo más apropiado es redirigir la salida estándar a un fichero:

# hwinfo > /tmp/$(date +%Y%m%d)-$(hostname)-hardware.txt

De este modo obtendremos un fichero de texto plano que contiene el informe detallado del hardware del sistema y cuyo nombre está compuesto por la fecha y el nombre del servidor. Para consultarlo, podemos abrirlo así:

# less /tmp/20130708-servidor-hardware.txt

El informe por defecto es como digo muy extenso, por lo que también podemos optar por su versión resumida:

# hwinfo --short
cpu: 
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 2000 MHz
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 800 MHz
keyboard:
 /dev/input/event14 USB Keykoard
 /dev/input/event0 AT Translated Set 2 keyboard
mouse:
 /dev/input/mice Pixart Imaging USB Optical Mouse
 /dev/input/mice SynPS/2 Synaptics TouchPad
graphics card:
 nVidia GeForce 8600M GT
...

En el caso de que sólo nos interese conocer los detalles de ciertos componentes hardware, podemos restringir la consulta mediante el uso de una serie de palabras clave cuyo listado podemos obtener en el manual electrónico mediante el comando man hwinfo.

Por ejemplo, si quiero conocer información sobre el procesador:

# hwinfo --cpu
01: None 00.0: 10103 CPU 
 [Created at cpu.304]
 Hardware Class: cpu
 Arch: Intel
 Vendor: "GenuineIntel"
 Model: 6.15.13 "Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz"
 ...

Y si quiero detalles sobre la RAM:

# hwinfo --mem
1: None 00.0: 10102 Main Memory 
 [Created at memory.61]
 Hardware Class: memory
 Model: "Main Memory"
 Memory Range: 0x00000000-0xbe053fff (rw)
 Memory Size: 3 GB
 Config Status: cfg=new, avail=yes, need=no, active=unknown

Estos parámetros se pueden combinar en un sólo comando e incluso con --short para obtener un informe resumido:

# hwinfo --short --cpu --network
cpu: 
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
network:
 wlan0 Dell Wireless 1390 WLAN Mini-Card
 eth0 Broadcom BCM4401-B0 100Base-TX

En todo el tiempo que llevo usándolo, hwinfo se ha mostrado muy estable y nunca ha producido problemas en los sistemas en los que lo he ejecutado. Sin embargo, si sospechamos que algún componente hardware pueda estar defectuoso, considero una temeridad utilizar una herramienta como hwinfo, ya que podríamos provocar un “kernel panic” y la más que probable caída del servidor.

Según consta en el manual de hwinfo, tiene un problema: no es capaz de detectar todo el hardware. Por eso, lo complementaremos en futuros artículos con otras herramientas igualmente interesantes.

Raspberry Pi: Linux embebido para todos

Wed, 08 Feb 2012 16:11:13 +0000

Personalmente nunca he sido un fan del mundo embebido. Sin embargo el anuncio de Raspberry Pi despertó mi interés por esta concepción minimalista del software y hardware.

R-Pi es un proyecto patrocinado por la Fundación Raspberry Pi, que consiste en comercializar una computadora por sólo 25 dólares, con objetivo de fomentar la enseñanza de ciencias de la computación. Y cómo no, el sistema operativo que ejecutará será Linux.

Obviamente, 25 dólares es un precio que llama la atención. Sobre todo cuando estamos hablando de sistemas SoC (System-on-a-chip) que suelen irse a más de cien. Lo que nos proporciona R-Pi es un procesador ARM, memoria RAM DDR, una GPU, puertos USB/UART y GPIO, Audio, salida de video HDMI y Composite, slot para tarjeta SD. En resumen, en apenas el espacio de una tarjeta de crédito, un mini ordenador personal. El modelo A costará 25 dólares, y el modelo B costará 35, ya que trae el doble de memoria (256MiB) y un puerto ethernet.

Pero más allá de su precio, el anuncio de su lanzamiento ha creado un verdadero revuelo en la comunidad Linux. Sin haber salido al mercado, R-Pi tiene ya una amplia comunidad. Hackers y programadores de todo el mundo planean ya los posibles usos o aplicaciones que crearán con esta maravilla. En la propia página Web ya nos muestran algunas de sus habilidades:

XBMC ejecutándose sobre R-Pi. XBMC es un conocido media player. R-Pi demuestra ser capaz de reproducir vídeos de alta definición usando este software, gracias a su GPU. Por ello, una de las aplicaciones que más seguidores tiene es la de su configuración como centro multimedia (Por cierto que XMBC merece algún dia un artículo aparte en este blog). Dado que el modelo B posee un puerto ethernet, podremos unirlo a nuestra red local. También le podemos poner un adaptador wireless USB, o bien conectarle un disco duro USB, o incluso un adaptador TDT.. Al fin y al cabo, es un sistema Linux completo con lo que tendremos infinidad de drivers a nuestra disposición..
AirPlay and Raspberry Pi. Reproducción en vivo desde un iPad.
Desarrollo de aplicaciones con QT. La GPU del R-Pi implementa OpenGL ES. Esto es una pequeña demo de live coding, donde los cambios en el programa se ejecutan en vivo en una capa inferior de la pantalla.

Y, por si le faltara algo, Debian será una las distribuciones oficialmente soportadas. Así pues, R-Pi es barato, tiene momentum, y sólo la imaginación pone límite a sus posibles aplicaciones. Vamos, que es todo un caramelo para linuxeros recalcitrantes como yo.

El apoyo de los fabricantes de hardware a Linux

Thu, 13 Nov 2008 09:39:27 +0000

Uno de los principales caballos de batalla de Linux desde sus inicios ha sido y sigue siendo el soporte de hardware. El origen de este problema se encuentra en la naturaleza del propio nacimiento de Linux. Al tratarse de un proyecto libre nacido de la voluntad de colaboración de un conjunto de usuarios sin dependencia alguna de ninguna empresa, la relación con los fabricantes de hardware fue desde el principio prácticamente inexistente.

Esta dinámica ha ido cambiando a lo largo del tiempo hacia un interés de buena parte de dichos fabricantes por un mercado que indudablemente está creciendo y que reporta pingües beneficios al que sabe estar ahí. No en vano, empresas como Intel, IBM, HP o AMD/ATI se han tomado muy en serio al usuario Linux y, no sólo les dan soporte con controladores Linux para su hardware, sino que además ofrecen las especificaciones técnicas del mismo para ayudar a los desarrolladores del núcleo.

Sin embargo, seguimos encontrándonos a fabricantes reticentes que, usualmente por motivos nada claros, no quieren saber nada del sistema del pingüino, aunque haya usuarios que les compran su hardware y les exijan soporte, con todo derecho. ¿Qué debemos hacer los “sufridos” usuarios de Linux en este caso? La respuesta es obvia: ignorar estos fabricantes y apoyar a los que nos apoyan, aunque esto suponga tener que renunciar a “golosas ofertas”, como ocurrió en 2002 con el caso de las promociones de alta de líneas ADSL de la mayoría de las operadoras que incluían un módem USB. En aquel entonces este tipo de modems no tenía soporte Linux, ni parecía que fuera a tenerlo, ya que ni los fabricantes ni las operadoras ponían el más mínimo interés. Aunque se trataba de hardware de calidad dudosa en el mejor de los casos, los usuarios de Linux querían tener acceso a dichas ofertas. Afortunadamente, gracias a la presión ejercida y al esfuerzo de desarrollo de muchos usuarios, esta situación cambió y fue posible utilizar este tipo de modems bajo Linux con mayor o menor fortuna dependiendo del modelo.

Esto nos lleva al más interesante de los aspectos del soporte de hardware bajo Linux: la calidad. Es una característica reconocida de Linux que se trata de un sistema muy exigente con el hardware, ya que debe ofrecer las mayores garantías a los datos del usuario (y no como ocurre en la acera de enfrente). Por ello, el que una pieza de hardware tenga soporte bajo Linux es sinónimo de calidad y garantía de rendimiento. ¿Alguien da más? Esperemos que sigan cayendo vendas de los ojos de más fabricantes de hardware.