O de como nunca hay que decir nunca…

Eso, de la muerte, los impuestos y los cuernos no se salva nadie dicen. Le voy a agregar una vuelta mas a la rosca:

Entre los usuarios de Linux, del rm -fr no se salva nadie.

Houston, tenemos un problema. Frase proferida por el astronauta Jack Swigert durante el accidentado viaje del Apolo 13

Houston, tenemos un problema. Frase proferida por el astronauta Jack Swigert durante el accidentado viaje del Apolo 13.

Por eso algunos maricones dicen que no hay que ir por la vida logueándose como root, por que las cagadas son bien grandes. Pero no, yo por pecar de exceso de autoestima y pelo en pecho o simplemente para sentir la adrenalina en las venas de vez en cuando ya que no practico ningún deporte de riesgo –en realidad no practico ningún deporte ¿Correr desde la puerta de un banco al otro no cuenta, no?– siempre que ando ejecutando comandos desde la consola tengo un signo « # « en el command prompt. Siempre voy como root y nunca me pasó nada. Por que soy macho y me la aguanto.

Así que allí estabamos, mi exceso de testosterona y yo, en uno de esos días en los que podés decir «he tenido días mejores», pensado en 25 cosas simultaneamente y contra reloj copiando un directorio tras otro, desde una ubicación a la otra, con el # adelante:

  • cp dir1 dir2/
  • cp dir2 dir2/
  • cp dir3 dir2/

Y así sucesivamente. Con la prisa, recuperando con las flechas de cursor los últimos comandos tipeados para poder modificar únicamente el nombre del directorio de origen y evitarme tipear el resto, hasta que en una de esas, me pasé de largo…

El comando inmediato anterior que bash tenía almacenado antes de que empezara a ejecutar la orden cp para copiar era un rm -fr, con lo que muy pancho, casi sin mirar la pantalla ejecuté:

rm -fr dir4 dir2/

Y demoraba, y demoraba… Y yo estaba mientras pensando en mil cosas y haciendo un par de cosas mas a la vez, y el asunto seguía demorando mas de la cuenta…

Todo el proceso de copia debería haber demorado  no mas de diez segundos pero esto ya llevaba cerca de un minuto. Entonces, en una fracción de segundo que me quedará marcada a fuego en la memoria, miré el led de actividad del disco rígido: 100% encendido, ni parpadeaba… Miré a continuación la pantalla, leí lo que había tipeado, leí los argumentos, piel de gallina en todo el cuerpo, frío desde la nuca hasta la cintura, CTRL + C para cancelar la operación.

… El CTRL + C mas rápido del oeste…

Ya era demasiado tarde… De una partición que contenía 300Gb de datos, me llevé al garete casi 110. Y eran de un servidor. Peor aún, de un servidor mío. Para embarrarla mas: De un servidor en producción, y para ponerle la guinda al postre, sin copia de seguridad.

Alguna vez me tenía que pasar. En toda la pila de años que llevo usando Linux, esta fué la primera por suerte pero me dolió y en forma, cosa que me sirvió para aprender un único precepto:

Si estás tipeando comandos como root, no importa cuán seguro de vos mismo estés, ni cuan relajado o enfrascado, ni cuan grandes tengas las pelotas, ni cuán mutitarea por prioridades y en tiempo real tu cerebro sea capaz de funcionar, tres carajos: Toda la potencia de procesamiento cerebral dedicada exclusivamenta a lo mas importante del mundo, Prestar atención a lo que escribís en la pantalla.

¿Quién no se manda una metida de pata cada tanto? Yo tengo varias de diversa índole en prácticamente todos los aspectos de la vida. Estas son las mejores que puedo recordar que me hayan pasado en Linux tipeando comandos en la consola:

haha_nelson

Ejecutar comandos en el host equivocado:

Ejecutar un comando creyendo estar en la consola local cuando en realidad se trataba de una jaula chroot o un host remoto:

# reboot

# halt

# killall (nombre de proceso importante)

De a poco se me ha hecho costumbre cambiarle el nombre al shell ni bien inicio sesión remotamente. Si me logueo en un Host cuyo nombre es pepito, renombro el prompt para que lo refleje:

# export PS1=”[pepito] $PS1”

Cambiar el puerto del servidor SSH

Eso, por muy boludo que suene ya me pasó unas dos o tres veces cambiar el puerto en el que escucha el servidor SSH y olvidarme de modificar el reenvío de puertos en el router que hace NAT o en el Firewall con lo que me encierro solo del lado de afuera y no puedo volver a conectarme remotamente:

# echo “Port 12345” >> /etc/ssh/sshd_config && /etc/init.d/sshd restart

De ahí viene la costumbre que tengo de instalar una VPN que traspase el firewall en cuanto servidor tengo bajo mi control.

Bajar la interface WAN en lugar de la LAN

Estando logueado por SSH, en lugar de bajar eth1 que era la interface LAN, bajé eth0 que era la WAN. El servidor se queda sin internet, yo me quedo fuera sin conexión. El servidor está a 70 kilómetros de distancia y es domingo a la siesta, nada mas que hacer hasta el lunes a la mañana en que alguien físicamente pueda solucionar el “problemita” reinciando el servidor o levantando eth0 nuevamente.

ifconfig eth0 down

Desde entonces tengo la costumbre de usar variables para asignarle nombres a las interfaces de red y usar la variable en lugar del nombre en el script:

export wan=eth0

Compilar mal el kernel

En un servidor remoto, compilar mal el kernel y reiniciar para probarlo resultando en un kernel panic o en quedarme sin conectividad en el servidor imposibilitando la reconexión remota por SSH para verificar los cambios.

make –j4 && make modules_install && cp arch/i386/boot/bzImage /boot/kernel && reboot

Desde entonces, si necesito reiniciar un host linux que no se si va a volver a la vida después del reboot uso una combinación de este watchdog en caso de pérdida de conectividad con este sistema de reinicio automático en caso de kernel panic y el método fallback que provee grubya voy a escribir al respecto alguna vez– para asegurarme de que si algo me salió mal, el equipo se reinicie solo volviendo a usar la configuración anterior en donde todo funcionaba.

Echando a perder se aprende, ¿Vieron?