¿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:
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 grub –ya 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?
Querer agregarle una pequeñita linea nueva al enorme crontab, y errarle por un centímetro y poner «crontab -r» cuando quisiste poner «crontab -e»?
Jeje, ¡Ese es buenísimo!
No, no he tenido el gusto, no me ha pasado nunca… Y desde entonces tenés la costumbre de… ¿Imprimir un banner bien grande que diga crontab -e y pegarlo arriba del monitor quizás? ¿alias para crontab -r que apunte a crontab -e?
¡Saludos!
jajaja, en realidad el problema está en ir a mil por hora y apretar Enter justo en el momento en que te das cuenta de que pusiste el comando mal, y al instante se te para el corazón cuando te das cuenta de que el comando se ejecutó «exitosamente» (porque no dio error, no mostró la ayuda, etc-), con lo que luego te das cuenta de lo que pasó realmente y te querés morir
Desde entonces tengo alias crontab=’crontab -i’ de la misma que tengo alias rm=’rm -I’ (si necesito que no me pida confirmación uso ‘rm’ en lugar de rm)
PD: Felicitaciones, tenés lector nuevo 🙂
Bueno, gracias desde ya, me alegro que guste.
¡Saludos!