El comando utmpdump permite visualizar el contenido de los ficheros btmp y wtmp. Ambos ficheros tienen formato binario y almacenan logs de:

• btmp: log que almacena un registro de los accesos fallidos al sistema
• wtmp: log que almacena un registro de los accesos al sistema

Los ficheros son ilegibles de forma directa debido a que están almacenados en binario:

# file wtmp
wtmp: data

Para ello tenemos el comando utmpdump. Simplemente pasamos el fichero de log como parámetro y podremos visualizar su contenido:

# utmpdump /var/log/btmp 
Utmp dump of /var/log/btmp
[6] [01585] [    ] [alex    ] [ssh:notty   ] [192.168.1.128       ] [192.168.1.128  ] [Mon Jan 16 21:45:56 2012 CET]
[6] [01585] [    ] [alex    ] [ssh:notty   ] [192.168.1.128       ] [192.168.1.128  ] [Mon Jan 16 21:45:59 2012 CET]
[6] [02927] [    ] [foo  ] [ssh:notty   ] [192.168.1.128       ] [0.0.0.0        ] [Fri Jan 27 21:52:13 2012 CET]
[6] [03787] [    ] [root    ] [ssh:notty   ] [192.168.1.128       ] [192.168.1.128  ] [Fri Jan 27 22:01:35 2012 CET]
[6] [03787] [    ] [root    ] [ssh:notty   ] [192.168.1.128       ] [192.168.1.128  ] [Fri Jan 27 22:01:51 2012 CET]

# utmpdump /var/log/wtmp | head
Utmp dump of /var/log/wtmp
[2] [00000] [~~  ] [reboot  ] [~           ] [2.6.32-220.el6.i686 ] [0.0.0.0        ] [Wed Dec 28 21:01:04 2011 CET]
[1] [00051] [~~  ] [runlevel] [~           ] [2.6.32-220.el6.i686 ] [0.0.0.0        ] [Wed Dec 28 21:01:04 2011 CET]
[6] [01052] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[6] [01054] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[6] [01056] [3   ] [LOGIN   ] [tty3        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[6] [01060] [4   ] [LOGIN   ] [tty4        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[6] [01062] [5   ] [LOGIN   ] [tty5        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[6] [01064] [6   ] [LOGIN   ] [tty6        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:25 2011 CET]
[7] [01052] [1   ] [root    ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Dec 28 21:01:31 2011 CET]
[7] [03021] [ts/0] [root    ] [pts/0       ] [192.168.1.128       ] [192.168.1.128  ] [Wed Dec 28 21:10:28 2011 CET]

utmpdump también nos permite visualizar el contenido del log a tiempo real (como un tail -f):

# utmpdump -f /var/log/wtmp 
Utmp dump of /var/log/wtmp
[8] [01555] [6   ] [        ] [tty6        ] [                    ] [0.0.0.0        ] [Fri Jan 27 22:20:43 2012 CET]
[2] [00000] [~~  ] [reboot  ] [~           ] [2.6.32-220.el6.i686 ] [0.0.0.0        ] [Sat Jan 28 10:34:12 2012 CET]
[1] [00051] [~~  ] [runlevel] [~           ] [2.6.32-220.el6.i686 ] [0.0.0.0        ] [Sat Jan 28 10:34:12 2012 CET]
...
...

Hoy vamos con una entrada de las tontas, de esas que por no mirar un log tardamos más de lo debido en resolver el problema. En este caso algo tan simple como configurar el acceso sin password y con llaves públicas de ssh me ha tenido unos minutos intrigado.

Básicamente, el problema ha sido por una configuración de umask un poco puñetera para el usuario:

$ umask
0002

Para los que no tengáis claro como funciona umask, revisad este artículo: El comando umask. En este caso al crear el fichero authorized_keys para almacenar las llaves públicas, este umask ha provocado que se creara con permisos muy poco seguros…

-rw-rw-r--. 1 foo foo    0 ene 27 22:12 authorized_keys

Y claro, ssh decía que de esta no era la forma correcta en el /var/log/secure:

Jan 27 21:55:52 nodo2 sshd[3282]: Authentication refused: bad ownership or modes
for file /home/foo/.ssh/authorized_keys
Jan 27 21:55:53 nodo2 sshd[3284]: Connection closed by 192.168.1.128

Securizamos con un 400 o 600 y solucionado:

$ chmod 600 /home/foo/.ssh/authorized_keys

Yo estaba empeñado en que era problema de SElinux, pero al ver que el modo permisivo no hacía que se solucionara el próximo paso tenía que ser mirar messages o secure.

Una vez que creamos un Web  Site en IIS, tenemos la opción de crear directorios virtuales (Virtual Directory) o aplicaciones (Application). Vamos a ver las diferencias más significativas entre ambos y cuando elegir uno u otro.

Directorio virtual (Virtual directory)

Comenzamos con el directorio virtual ya que es más simple que una aplicación. Básicamente un directorio virtual es un mapeo a una ruta local del servidor o remota en un directorio de nuestro website. Un ejemplo:

• Web Site: test.com (c:\inetpub\test.com\wwwroot)
• Virtual Directory: /test
• Mapeado a c:\test

En este ejemplo, cuando accedamos a www.test.com/test, en lugar de ir a su ruta lógica si no estuviera el directorio virtual creado, que sería c:\inetpub\test.com\wwwroot\test, accedemos a c:\test, gracias al mapeo del virtual directory. Esta es la característica principal del DV. A diferencia de lo que veremos a continuación con la aplicación, el directorio virtual se sirve a través del mismo application pool que el Web Site, y hereda por ello todas sus configuraciones a nivel de aplicación.

Aplicación (Application)

Las diferencias con el Virtual Directory ya se intuyen. Cuando conviertes un directorio en aplicación, permites que se ejecute con un application pool independiente al del website. Esto permite añadir un mayor nivel de personalización, de seguridad y de configuración. Respecto a la configuración, por ejemplo es muy útil en ASP.NET, ya que se buscará el web.config en esta ruta en lugar de en el raíz del Web Site. Podríamos considerar entonces el directorio virtual un mero puntero/mapeo a una ruta de almacenamiento, la aplicación por contra permite aislar del resto del Web Site las aplicaciones que lo contienen.

A groso modo esta es la explicación más básica de las diferencias entre ambos, cualquier puntualización será bienvenida, no soy para nada un experto en IIS ;)

En Linux y Unix existen otros comandos además de top para monitorizar de un modo eficiente la utilización de las CPU en el sistema. Hoy vamos a ver unos cuantos ejemplos del comando sar. En este primer artículo nos centramos en la CPU, veremos en sucesivos que podemos ir más allá (disco, red, procesos, carga, etc).

Para poder comenzar a utilizar sar, debemos tener en cuenta que es necesario por un lado tener corriendo el proceso sysstat:

# /etc/init.d/sysstat start
# chkconfig sysstat on

Además, hay que configurar sysstat para permitir la recolección de datos. Estos datos estadísticos se almacenan en /var/log/sysstat/sa*. Para ello es necesario tener estos parámetros en el fichero de configuración /etc/sysconfig/sysstat. Lo hacemos antes de reiniciar sysstat:

ENABLED="false"
SA1_OPTIONS="-S DISK"

Normalmente, si se instala el paquete por yum o apt, automáticamente se configuran los cron necesarios para recolectar la información que utiliza sar:

$ more /etc/cron.d/sysstat
# Global variables:
#
#  our configuration file
DEFAULT=/etc/default/sysstat
#  default setting, overriden in the above file
ENABLED=false
SA1_OPTIONS=""

# Activity reports every 10 minutes everyday
5-55/10 * * * * root [ -x /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [ "$ENABLED" = "true" ] && exec /usr/lib/sysstat/
sa1 $SA1_OPTIONS 1 1 ; }

# Additional run at 23:59 to rotate the statistics file
59 23 * * * root [ -x /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [ "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1
$SA1_OPTIONS 60 2 ; }

Vamos a ver unos cuantos ejemplos, os recomiendo como siempre revisar la página man porque es un comando con mucho potencial y opciones.

Mostrar el uso de CPU en un intervalo de tiempo determinado

El siguiente ejemplo muestra el uso de cpu cada 2 segundo:

# sar -u 2
Linux 2.6.28-17-generic (sistemas) 	22/01/12 	_i686_	(2 CPU)

19:14:05        CPU     %user     %nice   %system   %iowait    %steal     %idle
19:14:07        all     12,08      0,00      3,86      0,72      0,00     83,33
19:14:09        all      8,52      0,00      2,19      0,00      0,00     89,29
19:14:11        all      8,39      0,00      2,88      0,72      0,00     88,01
...
...
...

EL siguiente ejemplo hace lo mismo a excepción de que se ejecutará únicamente 4 veces. El anterior por contra se ejecutaba continuamente hasta que lo cancelaramos. Lo interesante de este ejemplo es que al final nos muestra una media de utilización durante el tiempo que se ha ejecutado:

# sar -u 2 4
Linux 2.6.28-17-generic (sistemas) 	22/01/12 	_i686_	(2 CPU)

19:16:39        CPU     %user     %nice   %system   %iowait    %steal     %idle
19:16:41        all     35,47      0,00      6,40      3,20      0,00     54,93
19:16:43        all     26,57      0,00     10,78      0,00      0,00     62,66
19:16:45        all     13,87      0,00      3,65      1,46      0,00     81,02
19:16:47        all     19,07      0,00      5,13      0,00      0,00     75,79
Media: all 23,69 0,00 6,46 1,17 0,00 68,68

Para los que no conozcáis el significado de cada columna:

• CPU: CPUs que se stán monitorizando, en los casos anteriores todas las del equipo.
• %user:  Porcentaje de tiempo de CPU utilizada por aplicaciones/procesos a nivel de usuario.
• %nice:  Porcentaje de tiempo de CPU utilizada por aplicaciones/procesos con prioridad nice asignada.
• %system:  Porcentaje de tiempo de CPU utilizada por aplicaciones/procesos a nivel de sistema/kernel.
• %iowait:  Porcentaje de tiempo de CPU en espera a que terminen operaciones de I/O.
• %steal:  Porcentaje de tiempo utilizado por las CPU en involuntary wait mientras el hypervisor servía a otro procesador virtual
• %idle: Porcentaje de tiempo de CPU en espera y sin operaciones de I/O pendientes.

Por supuesto se pueden añadir más columnas, revisad las páginas man:

# sar -u ALL 2 4
Linux 2.6.28-17-generic (sistemas) 	22/01/12 	_i686_	(2 CPU)

19:28:16        CPU      %usr     %nice      %sys   %iowait    %steal      %irq     %soft    %guest     %idle
19:28:18        all      9,18      0,00      2,90      0,97      0,00      0,00      0,00      0,00     86,96
19:28:20        all      7,95      0,00      4,34      0,00      0,00      0,00      0,00      0,00     87,71
19:28:22        all     14,46      0,00      5,15      1,47      0,00      0,25      0,00      0,00     78,68
19:28:24        all     17,89      0,00      5,39      0,00      0,00      0,00      0,00      0,00     76,72
Media:          all     12,34      0,00      4,44      0,61      0,00      0,06      0,00      0,00     82,55

Si ejecutaramos sar -u sin parámeteros nos mostaría la CPU utilizada durante el día, sacándola de los ficheros de estadísticas.

Monitorizar por CPU

En lugar de mostrar el estado de todas las CPU a la vez podemos seleccionar la que queramos o incluso mostrar una fila para cada CPU de forma independiente. En el siguiente ejemplo monitorizamos la CPU 1 durante 2 segundos y cuatro ejecuciones:

$ sar -P 1 2 4
Linux 2.6.28-17-generic (sistemas) 	22/01/12 	_i686_	(2 CPU)

19:29:17        CPU     %user     %nice   %system   %iowait    %steal     %idle
19:29:19          1     22,49      0,00      2,39      0,48      0,00     74,64
19:29:21          1      3,33      0,00      2,86      0,00      0,00     93,81
19:29:23          1     17,92      0,00      5,19      0,00      0,00     76,89
19:29:25          1     26,09      0,00     14,01      0,00      0,00     59,90
Media:            1     17,42      0,00      6,09      0,12      0,00     76,37

Como decía antes, una fila para cada CPU, en este caso un equipo con 2 CPU, únicamente una ejecución:

$ sar -P ALL 2 1
Linux 2.6.28-17-generic (sistemas) 	22/01/12 	_i686_	(2 CPU)

19:31:12        CPU     %user     %nice   %system   %iowait    %steal     %idle
19:31:14        all     17,69      0,00      3,93      0,74      0,00     77,64
19:31:14          0     22,39      0,00      2,99      0,00      0,00     74,63
19:31:14          1     13,04      0,00      5,31      1,45      0,00     80,19

Media:          CPU     %user     %nice   %system   %iowait    %steal     %idle
Media:          all     17,69      0,00      3,93      0,74      0,00     77,64
Media:            0     22,39      0,00      2,99      0,00      0,00     74,63
Media:            1     13,04      0,00      5,31      1,45      0,00     80,19

Mostrar toda la información almacenada en el fichero de estadísticas diario

$ sar -A

Sar no se limita únicamente a la monitorización de CPU, también podemos controlar la actividad en discos (al estilo iostat), de red, procesos, load average, etc. En este primer artículo no hemos centrado en la CPU, en los próximos veremos algunos ejemplos de ello.

Instalar y configurar el servidor VNC TigerVNC es realmente sencillo. Lo que muchas veces no nos paramos a pensar es que el protocolo en sí no es seguro por lo que el tráfico no está cifrado al conectar al escritorio remoto. Vamos a ver como solucionarlo.

Lo primero es instalar TigerVNC con yum (RHEL, CentOS, Scifi linux, etc). En este caso instalo también el cliente para hacer las pruebas en local:

# yum install tigervnc-server tigervnc

Una vez instalado debemos saber que la configuración se realiza en el fichero /etc/sysconfig/vncservers. Los comentarios del fichero nos indican claramente como configurarlo, también hice un artículo hace un tiempo, echadle un vistazo: Instalar y configurar vnc-server en CentOS/RHEL/Fedora

He creado un usuario “alex” al que únicamente se le permite el acceso local por seguridad:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see this URL:
# http://kbase.redhat.com/faq/docs/DOC-7028

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"
VNCSERVERS="2:ale
VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

Creamos el password VNC para el usuario del siguiente modo:

# su alex -c "vncpasswd"
Password: XXXX
Verify: XXXX

Arrancamos el servidor VNC para el usuario alex:

[alex@localhost /]$ vncserver
xauth:  creating new authority file /home/alex/.Xauthority

New 'rhcsa:1 (alex)' desktop is rhcsa:1

Starting applications specified in /home/alex/.vnc/xstartup
Log file is /home/alex/.vnc/rhcsa:1.log

Llegados a este punto podemos acceder sin problemas en local al escritorio remoto con el comando vncviewer:

$ vncviewer localhost:1

Desde fuera no, por motivos de seguridad. Para ello vamos a crear un tunel SSH de modo que las conexiones VNC con el exterior sí que estén cifradas. Vamos a usar por ejemplo el puerto 6922 para el tunel. El servidor VNC se encuentra en la IP 10.0.0.100, desde el equipo remoto con el que queremos conectar al servidor creamos el tunel:

$ ssh alex@10.0.0.100 -L 6922:10.0.0.100:5901 -N

Y ya está, podemos acceder remotamente al servidor VNC de forma segura con el nuevo puerto:

$ vncviewer localhost:6922

Si queréis usar el estandar podéis mantener los puertos de VNC:

$ ssh alex@10.0.0.100 -L 5901:10.0.0.100:5901 -N

$ vncviewer localhost:1

El objetivo de WebDAV es hacer de la World Wide Web un medio legible y editable, en línea con la visión original de Tim Berners-Lee. Este protocolo proporciona funcionalidades para crear, cambiar y mover documentos en un servidor remoto (típicamente un servidor web). Esto se utiliza sobre todo para permitir la edición de los documentos que sirve un servidor web, pero puede también aplicarse a sistemas de almacenamiento generales basados en web, que pueden ser accedidos desde cualquier lugar. La mayoría de los sistemas operativos modernos proporcionan soporte para WebDAV, haciendo que los ficheros de un servidor WebDAV aparezcan como almacenados en un directorio local.

Definición de WebDAV en Wikipedia

Preparación/instalación

Vamos a ver los pasos (sencillos) para activar WebDAV en Apache. Lo primero que hay que verificar es que el módulo mod_dav está cargado, ya sea de forma estática o dinámica. Normalmente cuando instalamos Apache por gestor de paquetes viene cargado de forma dinámica en el fichero httpd.conf:

Loadmodule dav_module modules/libdav.so

Si por contra compilamos Apache manualmente podemos decidir si compilarlo estáticamente o dinámicamente (como hemos visto antes). Para hacerlo estáticamente añadiremos la directiva correspondiente a la línea de compilación y podremos ver si está cargado con el comando:

# httpd -l

Otra opción es instalar el paquete por yum/apt/pkg si el paquete está disponible en un repositorio.

Configuración

Lo primero que tenemos que hacer es activar el soporte para WebDAV a nivel general de Apache, para ello añadiremos la siguiente línea en el fichero httpd.conf. Podemos restringirlo a nivel de <Directory> o <Location>:

Dav On

Además de esto, debemos especificar la base de datos de bloqueos (Lock Database) en la sección global de la configuración del httpd.conf:

DavLockDB /etc/apache/var/DavLock

Este directorio debe tener permisos de escritura para el usuario y grupo que ejecuta el servidor Apache.

El resultado final sería el siguiente, en este ejemplo activamos WebDAV en una ubicación (/webdav) únicamente para usuarios autenticados (admin) configurados con htpasswd

DavLockDB /usr/local/apache2/var/DavLock
<Location /webdav>
   Dav On

   AuthType Basic
   AuthName DAV
   AuthUserFile user.passwd

   <LimitExcept GET OPTIONS>
     require user admin
   </LimitExcept>
</Location>

Estas mismas directivas (a excepción del DavLockDB) podríamos añadirlas dentro de un virtualhost.

Conectar al WebDAV

Muchos sistemas soportan acceso a WebDAV de forma nativa. No obstante, en Linux podéis usar cadaver sobre línea de comandos:

$ cadaver http://dav.test.com/webdav/
...
...
dav:/webdav/>

En un servidor DNS montado con Bind, podéis encontrar un error como este en el log:

09-Jan-2012 08:23:44.055 client 10.0.0.50#59382: view internal-in:
 RFC 1918 response from Internet for 50.0.0.10.in-addr.arpa

El error es totalmente descriptivo, sólo hay que revisar la RFC 1918 y leer dos veces el error para darnos cuenta del fallo. En este caso estamos tratando de buscar en Internet una IP que pertenece a un rango privado. Podemos ver que además nos responde con la vista privada del named.

Rangos privados:

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Lo más sencillo y rápido es declarar la zona en la configuración de nuestro Bind, no es necesario ni crear el fichero de la zona:

zone "10.in-addr.arpa" {
          type master;
          file "named.empty";
  };

Es posible que en lugar de así tengáis que ponerlo tal que:

zone "10.in-addr.arpa" {
          type master;
          file "empty";
  };

El link al RFC: RFC 1918 – Address Allocation for Private Internets

Si ayer comentaba la forma de configurar rhn_register y yum para funcionar a través de un proxy hoy le toca a Windows 2008.

Es bastante sencillo, podemos hacerlo ejecutando directamente el siguiente comando en Start > Run

netsh winhttp set proxy 10.0.0.100:3128

Lo único que tendréis que modificar es la IP y el puerto del proxy. También se puede acceder a la shell de netsh y ejecutar desde ahí los comandos.

C:\Windows\system32>netsh
netsh>winhttp
netsh winhttp>set proxy 10.0.0.100:3128

Para desactivar el uso del proxy:

netsh winhttp>reset proxy

Y para ver el estado:

netsh winhttp>show proxy

Por otra parte, para activar Windows vía proxy tendréis que configurar el proxy en Internet Explorer.