Historias BOFH: el día a día de un pobre SysAdmin

Segunda entrega de Historias BOFH y tengo una lista demasiada larga. Realmente podría sacar varias entregas más, pero por el momento haremos esta.

Vamos al lío, que los usuarios se acumulan!

No hace falta revisar el espacio en disco

A veces hay clientes que dejan información de la incidencia a cuentagotas y les tienes que ir extrayendo información como si de un espía de la URSS se tratara.

Se crea una escena por e-mail donde te ves con traje y con un abrigo largo y gafas de sol en una habitación oscura iluminada por una lampara que enfoca a tu cliente sentado en una silla.

Pero hay otras veces, que el cliente te da todo tipo de detalle y que incluso le tienes que decir "Oye, suficiente información".

En el e-mail detallado nos cuenta lo siguiente:

Hemos creado un servidor nuevo con 80GB de disco, 2 vCores y 4GB de RAM. Estamos migrando un PrestaShop que ocupa 40GB y lo estamos copiando de VPS a VPS. El problema viene que cuando lleva 20GB copiado deja de copiar y el espacio en disco deja de variar. Pero queda suficiente espacio en disco:

# df -h
/dev/sda1 79G 24G 52G 32% /

También nos comenta que tiene problemas para instalar paquetes y que le aparece un error diciendo que no queda espacio en el disco.

Revisamos el servidor y vemos que efectivamente, tiene algún problema de espacio:

# touch test
touch: cannot touch 'test': No space left on device

Entonces en ese momento pienso que si aparece que tiene espacio y no puede crear un fichero por falta de espacio no puede ser otra cosa que le falten inodos en el disco.

Para quien no esté al tanto, en algunos sistemas de ficheros de GNU/Linux trabajan con inodos. Un inodo contiene la totalidad de metadatos de un fichero de nuestro sistema de archivos. Información como número del inodo (que es único), el tamaño del fichero (y el número de bloques que ocupa el fichero en el disco), el dispositivo de almacenamiento, el número de enlaces (algunos ficheros pueden apuntar al mismo inodo), identificación de usuario y grupo (el UID y el GID), marcas de tiempo (fecha de creación, modificación, etc), etc.

Resumiendo mucho, podríamos decir que es un armario lleno de carpetas con información de los ficheros. Entonces, se puede dar el caso, de que tengas muchos inodos ocupados por una cantidad ENORME de ficheros pero que esos ficheros ocupen muy poco. Así que te puedes quedar sin carpetas pero tener espacio para ficheros.

Así que reviso los inodos del disco:

# df -i
/dev/sda1      5242880 5242880      0  100% /
# df -h
/dev/sda1 79G 24G 52G 32% /

A lo que me comentan mis jefes que está copiando este usuario y les digo que en teoria un PrestaShop y les digo que imagino que tendrán muchas fotos de productos.

Reviso en que está ocupando espacio en disco y me doy cuenta de algo:

# du -sh *
60M     adminpanel
34G     cache
12K     cgi-bin
3.3M    classes
1.2M    config
4.0K    CONTRIBUTING.md

En este momento me empiezo a reir solo y sin sentido. En el mismo momento entra mi jefe en la oficina y le digo "el de los inodos, tiene una carpeta caché en PrestaShop que ocupa 34GB, de ahí los inodos".

A lo que nos empezamos a reir todos y uno suelta "Pues borrar la cache de vez en cuando no es pecado" [risas].

Premio al ticket del año

Era una tarde relativamente tranquila, cuando de golpe llega un ticket. Quedaba poco tiempo para acabar la jornada laboral y al ver como llegaba el e-mail fue un poco "espero que no sea nada urgente".

Leemos el ticket y no dábamos crédito:

Buenas tardes,

Me ocurre algo que no creo que sea normal. Es normal que cuando hago sudo reboot, se cierra mi conexión con el servidor?

# sudo reboot
Connection to 85.208.22.22 closed by remote host.
Connection to 85.208.22.22 closed

Muchas gracias.

A veces cuesta un poco responder a estas cosas. Pero a ver es mejor responder un:

Si, claro, es normal.

Te paso un error que me dice donde está el problema

Con el tiempo hablas con muchos usuarios pero también acabas teniendo como un grupo de usuarios que los llamas "los cracks" porque te envían e-mails que no sabes por donde cogerlos.

Esta vez este usuario nos envía un e-mail diciendo que está configurando una cosa en IIS en Windows y que le da un error al guardar y nos pasa dos capturas.

Y nos pregunta que no entiende el error y que no sabe que hacer o como configurar correctamente lo que pone.

La configuración es la siguiente:

Y el error que le da es este:

Me pongo a leer el error y mientras leo acabo viendo que es más bien un aviso donde dice claramente "Si la ruta del script (solo en el caso de ser un .exe) tiene espacios, tienes que usar doble comillas para especificar el ejecutable"

Y llega ese momento en el que no sabes que responder. Puedes responder un "¿Pero te has leído el error hijo mío?" o responder "Debes de reinstalar IIS por completo y configurarlo de nuevo". Y te da miedo de saber que ese usuario pueda hacer eso porque simplemente se lo dices tu.

Decimo octavo intento al instalar Moodle

Teníamos un usuario instalando Moodle en un servidor donde tenía un panel y que ya venía todo montado.

Cuando los usuarios borran los servidores, tienen opción de enviarnos un comentario para saber la experiencia que han tenido.

Nos llegó el comentario más triste que jamás habiamos recibido:

Hola,

Mi experiencia con Ubuntu ha sido bastante frustante. Llevo días intentando instalar Moodle y por más que modifique permisos y grupos de los ficheros NO consigo que funcione correctamente y acceder a la instalación.

He intentado instalar un .exe y me dice que necesito de archivos mime o alguna cosa así. Pero cuando le digo que descargue los necesarios, me dice que "no puedo encontrar nada".

En este comentario, a demás del escrito del usuario, nos llega información en formato JSON de la maquina eliminada. Información como el nombre, IP pública, imagen usada para crear el servidor, SO, y demás información interna.

Revisando esa información, veo que en la información del SO hay lo siguiente:

"Name": "Ubuntu 18.04 64Bit"

El pobre había montado un servidor de Ubuntu y estaba ejecutando .exe a lo loco y sin éxito (LOL).