Blog de Javi

Usando bash uno se acostumbra muy fácilmente al tabulador para autocompletar comandos y ficheros. Pero también podemos autocompletar usuarios y hosts en bash.

La combinación para autocompletar usuarios es la siguiente: Alt-AlGr-4 (Alt-~). En caso que no autocomplete si repetimos la combinación nos dará las opciones disponibles, deberemos añadir más caracteres ya que existe más de una posibilidad:

$ a
abrt           adm            apache         avahi          avahi-autoipd

Podemos hacer lo mismo para los hosts con la combinación Alt-AlGr-2 (Alt-@) que igualmente con dos veces nos indicará las opciones:

$ a
adama  apolo

Fuente: Systemadmin

Hoy voy a explicar como hacer una conexion SSH sin necesidad de meter la clave en cada conexion. Esto puede ser util para conexiones desde servidores de Backup, RSYNC, etc…

Lo primero de todo, ejecutamos en el “cliente” el siguiente comando:

javier@gedeon:~$ ssh-keygen -t dsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/javier/.ssh/id_rsa):
/home/javier/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/javie/.ssh/id_dsa.
Your public key has been saved in /home/javier/.ssh/id_dsa.pub.
The key fingerprint is: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Si os fijais, no pongo una clave “passphrase”, porque sino en cada conexion, nos pediria la clave del certificado. Una vez hecho esto, lo unico que nos queda por hacer es añadir el contenido del archivo ~/.ssh/id_dsa.pub en el servidor o servidores a los que nos vayamos a conectar en ~/.ssh/authorized_keys

Con esta sencilla operación ya podemos conectarnos sin necesidad de utilizar claves.

Si alguien quiere conocer mas acerca del metodo de autenticación mediante certificados, le invito a que busque sobre ello por Internet, ya que es muy interesante y se usa en muchos campos, tales como firmar digitalmente correo electronico y encriptarlo, conexiones SSL a servidores Web, DNIe, etc…

Para todo aquel que necesite hacer un script en bash y quiera meter la clave de una conexión SSH en línea de comandos para ejecutar scripts, la solución es sshpass. No recomiendo este método, ya que una clave en un script puede ser un problema de seguridad, para ello podemos realizar la conexión SSH con certificados que ya explicaré en otro momento. La idea de esta entrada es para usos puntuales.

wget http://heanet.dl.sourceforge.net/project/sshpass/sshpass/1.05/sshpass-1.05.tar.gz
tar xvf sshpass-1.05.tar.gz
cd sshpass-1.05
./configure
make
make install

Ahora una vez instalado sshpass en nuestro sistema o servidor, la sentencia para conectarnos a ssh es la siguiente:

sshpass -p 'passwd' ssh root@172.25.0.1

El popular servidor web que desde sus inicios adoptó la filosofía Open Source llevaba años sin ser modificado en gran medida, pero ahora se han dado los primeros pasos para llegar a una futura versión Apache 2.4. Los desarrolladores del proyecto Apache han publicado la versión Apache 2.3.11, que es el primer paso de lo que será Apache 2.4, y que llega con mejoras interesantes, sobre todo en el área de la gestión de varias peticiones de forma simultánea.

Seis años después de lanzarse la versión 2.2 del servidor web Apache, los responsables del proyecto han publicado Apache 2.3.11, que se supone es el primer paso hacia una futura versión Apache 2.4.

Las nuevas características de esta versión preliminar afectan por ejemplo a la arquitectura MPM (Multi-Processing Module) que permite múltiples peticiones para ser procesadas de forma casi simultánea. Por primera vez los usuarios no necesitan elegir un MPM cuando compilan el servidor.

Como cualquier otro componente software, los MPM se generan como módulos dinámicos que pueden ser seleccionados al iniciar el servidor. Como indican en The H Open, mientras que antes estos componentes estaban clasificados como “experimentales”, ahora se han unido a la lista de módulos plenamente funcionales.

También nos hablan de la directiva LogLevel, que ahora se puede configurar para mantener distintos tipos de directorios y de módulos. Otro nuevo módulo integra el lenjuaje de scripting Lua para permitir a los desarrolladores implementar los llamados “request habdlers” en este lenguaje.

Además mod_ssl permite que se usen certificados para ser verificados online a través de OCSP. Como suele suceder con este tipo de versiones preliminares, los desarrolladores recomienzan su uso siempre fuera de entornos de producción.

Podéis encontrar más detalles sobre este lanzamiento en el anuncio oficial y en el registro de cambios, y además podéis descargar Apache 2.3.11 desde la página oficial.

Tenemos un comando en Linux que se llama “smartctl” el cual nos da informacion vital sobre el disco duro consultado. Datos tales como temperatura, horas en funcionamiento, promedio de fallo, etc…

equipo ~# smartctl -a -d ata /dev/sda
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 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 67
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247181777
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21179
... ... ...

Tenemos 4 columnas: VALUE, WORST, THRESH y RAW_VALUE

VALUE es el valor actual que nos da el indicador que debe de ser superior a THRESH. En caso contrario vamos mal, ya que quiere decir que hay algo que está fallando (Old_age fallo típico de disco duro, Pre_fail fallo crítico en 24 horas).

WORST es el valor más bajo que nos ha dado este indicador, se cumple lo mismo que con el anterior, si es más bajo que THRESH, malo.

Y ahora viene el rollo del normalizado.

RAW_VALUE es el valor sin normalizar del indicador, la forma más fácil de explicarlo es con el valor de Power_On_Hours, horas que lleva el disco encendido.

Por ejemplo, el disco viene de fábrica con una vida útil de 100.000 horas, puede durar más o menos, pero en estudios que hemos hecho hemos observado unos porcentajes.

Hasta 30.000 horas falla el 1%
Hasta 50.000 horas falla el 5%
Hasta 70.000 horas falla el 15%
Hasta 95.000 horas falla el 30%
Hasta 100.000 horas falla el 55%
Hasta 120.000 horas falla el 80%
Hasta 130.000 horas falla el 100%

El RAW_VALUE puede contener cualquier cosa (horas, segundos, lunas, periodos de 18.3 segundos…) aquí cada fabricante guarda lo que el estima oportuno, pero este RAW_VALUE me lo tiene que traducir a un valor normalizado. Siguiendo el ejemplo anterior el número de horas lo puede traducir a los valores 100,99,98,97,96,95,94 con un THRESH situado en el 96. ¿por qúe de 100 a 94? porque el fabricante lo decide así, podría haber sido de 60 a 54 o de 100 a 0 con intervalos más grandes, logicamente el THRESH se mueve en la misma escala.

¿Y el RAW_VALUE?
Como he dicho el valor del RAW lo decide cada fabricante, que marque 60 en temperatura no indica obligatoriamente que el disco esté a 60 grados, pueden haber comenzado la escala a -10 grados, emplear grados farenheit o cualquier otra medida. Lo importante es que el valor normalizado (43 en tu caso, sean los grados que sean) es inferior al THRESH establecido para ese disco (45)

Hay algunos fabricantes que si que ofrecen la interpretación exacta del RAW_VALUE pero pocas veces necesitamos conocer tanto detalle .