Colega, ¿donde está mi last?
Uno de los misterios más habituales, que ha causado más de un quebradero de cabeza a los sysadmins del mundo mundial es la falta de informacióncuando hacemos un last.
Para los que no lo tengan muy claro, last es una herramienta de seguridad que indica los últimos accesos a la máquina en orden reverso. Cada línea nos va a indicar nombre de usuario, la consola (tty) desde donde conecta, nombre de máquina y el comienzo y el fin de la sesión. Utilísimo para los paranoicos en todos nosotros 
Un ejemplo práctico:
root@madhatter # last root pts/4 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Wed Oct 8 12:30 - 12:36 (00:05) root sshd 10.0.231.64 Wed Oct 8 11:55 - 12:25 (00:29) root pts/4 10.10.1.229 Wed Oct 8 11:30 - 12:41 (01:11) root sshd 10.10.1.229 Wed Oct 8 11:30 - 11:55 (00:25) root console :0 Tue Sep 30 12:27 still logged in root pts/2 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root sshd 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root pts/2 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Thu Sep 18 14:17 - 14:32 (00:15) root pts/2 10.10.1.229 Thu Sep 18 14:15 - 14:47 (00:31) root sshd 10.10.1.229 Thu Sep 18 14:15 - 14:17 (00:01) root pts/2 10.10.1.229 Thu Sep 18 08:44 - 08:44 (00:00) [...]
Imaginemos ahora una situación como esta
root@madhatter # last wtmp begins Wed Feb 25 04:30
La cara de tonto que se te queda cuando compruebas que el fichero está actualizado
root@madhatter # ls -l /var/adm/wtmpx -rw-r--r-- 1 adm adm 43599145 Oct 21 13:28 /var/adm/wtmpx
Que forzando te manda a peinarte
root@madhatter # last -f /var/adm/wtmpx wtmp begins Wed Feb 25 04:30
Que el filesystem no está lleno
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/bootdg/rootvol 15345315 8665186 6526676 58% /
La causa más normal de este comportamiento es corrupción de datos en el fichero /var/adm/wtmpx que es donde se almacenan los datos para sacar el last. Las causas son variadas, desde llenado temporal de ese filesystem, un backup mal realizado, truncados de ficheros o simple y pura mala práctica.
La cuestión es arreglarlo. La forma más sencilla es, simplemente, recrearlo con los permisos adecuados, haciendo copia de seguridad previa:
root@madhatter # mv /var/adm/wtmpx /var/adm/wtmpx.BAK root@madhatter # touch /var/adm/wtmpx root@madhatter # chown adm:adm /var/adm/wtmpx root@madhatter # chmod 644 /var/adm/wtmpx
Listo. En caso de que nos interese mucho guardar los datos contenidos en el fichero, hay una operativa mucho más complicada que podéis examinar a fondo.
Esto es grande… Esto es pequeño
La comprobación de que el tamaño de las cosas es elástico (ejem, ejem) y más todavía en Unix.
Como me imagino que todos sabréis, el archivo de /var/adm/lastlog registra y almacena el tiempo de login de cada usuario, sea este correcto o incorrecto. Es útil para saber quien se ha conectado, cuanto tiempo, y desde donde.
En ocasiones, me han dado un toque de atención por el excesivo tamaño de /var y concretamente el de lastlog. Yo siempre les digo que para qué andan mirando donde no deben 
y luego les explico lo que me contaron a mí en su momento: El tamaño del archivo de lastlog al hacer un ls no se corresponde con su tamaño real.
El tamaño indicado al hacer un ls -l del fichero lastlog está basado en el UID más alto de los usuarios que estén conectados a la máquina. La fórmula que utiliza Solaris para esto es tamaño total de lastlog=(UID más alto de los usuarios + 1) * 28
De ésta manera, el fichero de lastlog se convierte en un fichero “disperso” en el que su tamaño real es mucho más pequeño del que pueda parecer. Para comprobarlo, vamos a seguir unos ejemplos sencillos:
Tamaño de /var actual de la máquina nuestra de pruebas:
root@madhatter # df -k /var/ Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472886 497282 75% /var
Tamaño de lastlog según ls (Aparente)
root@madhatter # ls -la /var/adm/lastlog -r--r--r-- 1 root root 1820084 Dec 10 14:17 /var/adm/lastlog root@madhatter # ls -lha /var/adm/lastlog -r--r--r-- 1 root root 1.7M Dec 10 14:17 /var/adm/lastlog
Tamaño real del mismo fichero
root@madhatter # du -ks /var/adm/lastlog 24 /var/adm/lastlog
Procedemos a vaciar el fichero lastlog y comprobamos su tamaño
root@madhatter # > lastlog
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 0 Dec 10 14:30 lastlog
root@madhatter # du -ks lastlog
0 lastlog
Así como el de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472862 497306 75% /var
Vemos que sólo ha aumentado en 24 Kb.
Ahora, entramos como usuario root. Según lo especificado en la fórmula, crece de tamaño en 28 bytes aparentes (Pero solo 1 kb real)
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 28 Dec 10 14:32 lastlog
root@madhatter # du -ks lastlog
1 lastlog
Kb que se descuenta de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472863 497305 75% /var
Ahora, procedemos a entrar con el usuario que tiene el UID mas alto en la maquina
prueba:x:65002:1::/var/tmp/usuario_prueba:/usr/bin/ksh
De nuevo, el fichero crece según la fórmula (65002+1)*28=1820084
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 1820084 Dec 10 14:35 lastlog
Pero sólo ha aumentado 23 Kb
root@madhatter # du -ks lastlog 24 lastlog
Así como /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472894 497274 75% /var
Así pues no hay reserva de espacio en/var por parte de last log en lo que concierne al tamaño aparente, sino únicamente al tamaño real.
Y recordad: This is not a bug, is a feature
