¿El mayor error en la línea de comandos? [cerrado]

¿Cuál es el mayor daño (de cualquier tipo) que haya causado con una sola línea de comando equivocada / mal escrita / equivocada? Eliminé una base de datos del sistema de producción por error hace un tiempo, por ejemplo, pero tuve suerte (es decir, hice una copia de seguridad) y no hubo pérdida permanente de datos, pérdida de dinero, daños a la propiedad, etc.

Lo más importante (para los votos), ¿qué hace para asegurarse de que nunca vuelva a suceder?

En el servidor SQL, en un sistema de producción:

update customer set password = '' <enter>

La copia de seguridad más reciente tenía como una semana de antigüedad.

Para mitigar esto, ahora generalmente escribo una selectdeclaración primero para asegurarme de que tengo la wherecláusula correcta, luego vuelvo y la edito para insertar la setcláusula y cambiar la declaración a update.

¿El error más grande? Pensando que había establecido dos variables cuando no lo había hecho. Entonces rm -rf $ VARIABLE / $ VARIABLE2 se convirtió en rm -rf /. ¡FreeBSD ha actualizado recientemente su herramienta rm para que rm -rf / ya no sea posible precisamente debido a este error!

shutdown -h now 

destinado a la estación de trabajo local, pero lo escribió mientras estaba conectado a través de ssh en el servidor de producción. Desde entonces siempre tengo nombre de host en mi $PS1.

Omitir -r de un comando de apagado. En un servidor remoto. Al otro lado del país. Sin personal de TI en la oficina remota.

Todos lo hemos hecho, es casi como un rito de iniciación en esta etapa.

En un sistema VMS, había estado usando el comando ASSIGN DCL para asignar nombres lógicos, y quería RECUPERAR una línea de comando ASSIGN anterior. Ahora, en VMS, solo escribió tantos caracteres de un comando para que sea inequívoco. Así que tenía la intención de escribir

REC ASS

pero accidentalmente escribí

REQ ASS

en lugar. REQ no fue lo suficientemente ambiguo para el comando SOLICITAR, que transmite el argumento a todos los que tienen privilegios de operador (que eran todos en TI). Así que todo el departamento recibió mi mensaje de difusión que era simplemente "CULO".

En un sistema Solaris: "killall dataLoader".

'dataLoader' era una aplicación en la que estaba trabajando. En Linux, killall funciona como pkill. Envía una señal a los procesos que coinciden con una cadena dada como argumento. En Solaris, killall intenta matar todo lo que el usuario actual puede matar en el sistema. Yo era root.

Una vez, hace muchas lunas, necesitaba encontrar un ejecutable en particular, pero no podía recordar el nombre completo (pero podía recordar algunas de las letras). Así que pensé en verificar el directorio / usr / bin con algo como esto

rm /usr/bin/i*g*

Extraño. Nada ha vuelto. Pensando que acababa de recordar la segunda carta, intenté nuevamente con

rm /usr/bin/i*

De nuevo, nada. Después de hacer lo mismo con / usr / local / bin, / usr / sbin, y cualquier otra cosa que supuse que podría estar dentro, me di cuenta de que había estado escribiendo mal el comando 'ls'.

No sé exactamente de dónde vino el pedo cerebral, pero definitivamente no es un error que haya cometido nuevamente.

setup.exe

Fue Windows Vista.

Intentando cambiar la propiedad de todo en un directorio, incluidos los archivos de puntos, con:

chown -R user * .*

¿Adivina qué hace eso ?

Pretendía destruir / dev / sdb, afortunadamente tenía una buena copia de seguridad actualizada

dd if=/dev/urandom of=/dev/sda

select * from <File1> join <file2>

En una caja de producción. Tenga en cuenta la falta de una oncláusula. :-) Ambas tablas eran tablas de filas multimillonarias, y esto estaba en un AS / 400 a mediados de los 90 donde una vez que se ejecutaba el SQL no se podía matar.

En uno de nuestros servidores de producción de datos, una de mis raíces escribió:

chmod -R 777 /

Debido a que estaba recibiendo un error de permisos con algunos scripts ...

Poco después de eso, su clave privada fue eliminada de todos los servidores y se encargó de la restauración de datos de 1TB en el servidor de producción de datos ...

Mi erm favorito fue cuando estaba en la universidad. Estaba creando una aplicación (no recuerdo qué) y como no era root la había construido con

PREFIX=~username/usr/local

Entonces podría instalarlo en mi directorio de inicio. Lamentablemente se instaló en

/home/username/src/app/~username/usr/local

en lugar. Naturalmente para eliminarlo como inicio nuevamente ejecuté

rm -rf ~username

En el directorio de origen.

Me preguntaba por qué tardaba tanto ...

:-)

Sin embargo, lo peor fue cuando estaba trabajando con una estación de trabajo solaris y después de configurarlo todo, queríamos borrar la configuración lista para la configuración en vivo. Entonces ejecuté

sys-unconfig

Aceptó el mensaje de advertencia y, en lugar de que la máquina se reiniciara y volviera a los "valores predeterminados de fábrica", la ventana xterm simplemente decía

connection closed by foreign host.

Moraleja de la historia ¡Nunca dejes un shell de root abierto en otro host! ¡¡SIEMPRE!!

Hace muchos años, estaba en casa codificando algunas cosas en php mientras trabajaba en un proyecto con un amigo mío que era el encargado del mantenimiento del proyecto. Nos estábamos intercambiando mensajes instantáneos en un esfuerzo de colaboración. Siempre bromeamos de un lado a otro en el juego.

Estaba tratando de hacer que ssh-agent funcionara correctamente en mi máquina mientras teníamos una guerra religiosa de Perl contra PHP. Luego mencioné algo sobre ssh-agent que necesita ser evaluado (no estoy seguro de por qué dije eso). Entonces él me envió este mensaje en un esfuerzo, por lo que pensé, para ayudarme con mi problema (tenga en cuenta que estaba destinado a rootear):

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

¡ADVERTENCIA! ¡NO EJECUTE ESE MANDO!

SI elimina la evaluación y ejecuta el comando interno por sí mismo es:

rm -rf /

Me tomó 4 segundos notar lo que estaba sucediendo, pero el daño ya estaba hecho. Tuve que reinstalar mi sistema operativo. Afortunadamente, nada de mi trabajo fue eliminado excepto algunas cosas en / etc iirc. Se rió ENORME cuando le envié un mensaje de horror preguntando por qué hizo eso. Ambos somos ingenieros de sistemas a largo plazo. Él no pensó que lo ejecutaría y sería más cuidadoso de verificarlo antes de simplemente hacer c & p y simplemente confié en él, así que ni siquiera consideré que estaba jugando. No hace falta decir que esta pequeña historia surge todo el tiempo entre nosotros. Entonces, decidí inmortalizarlo.

¿Cómo he mitigado que esto vuelva a suceder? ¡No confío en nadie!

Otra historia menos interesante es que hace un par de años estaba trabajando en una caja de misión crítica en el trabajo. Tenía algunos términos abiertos a diferentes máquinas. Necesitaba eliminar algunas cosas superfluas en un directorio. Bueno, me perdí en mis términos y accidentalmente corrí .en mi directorio local pero en el host incorrecto (término incorrecto) !!. Ejecuté el comando en / var / lib / mysql en lugar de / tmp en el servidor de aplicaciones (término diferente). No hace falta decir que borré la base de datos de producción. Afortunadamente, tuvimos un modo de espera cálido al que pasamos mientras yo y un compañero de trabajo reconstruíamos la primaria a partir de las copias de seguridad y el modo de espera. Eso llevó unas 18 horas.

Mitigación: más cuidado con las ventanas en las que ejecuto los comandos antes de ejecutarlos.

la versión corta

#/bin/bash
$0&
$0

Una vez quise eliminar un montón de archivos en un directorio.

del *.*

La computadora entonces dijo "¿Estás seguro? [S / N]" Pensé "¡POR supuesto que estoy seguro, de lo contrario no habría escrito el maldito comando! Las computadoras estúpidas de Sheesh se quejan ..."

Y <enter>

C:\Windows>_

Um ... ¿WTF? ¿Acabo de borrar mi directorio de Windows? ....

undelete *.*

En aquellos días de pequeños discos duros, sabía para qué era cada archivo en c: \ windows y cuál era su nombre, pero incluso después de recuperar todo, el sistema nunca fue el mismo. Gané un poco de respeto por el mensaje "¿estás seguro?". Solo un poco.

Creo que lo más estúpido que hice fue eliminar la ruta predeterminada en el clúster de firewall externo, mientras realizaba una copia de seguridad en mi escritorio a más de cien millas de distancia.

Afortunadamente fue en un período designado como tiempo de inactividad planificado (por si acaso), pero eso no me ahorró el viaje de ida y vuelta de 200 millas para reconfigurar el firewall en el sitio. Tampoco ayudó que esto eliminó nuestros sistemas de producción expuestos a Internet durante la duración de mi viaje y su posterior reparación.

Todos conocemos la definición de un nano-segundo. Un ohno-segundo es aún más pequeño, y es el tiempo entre presionar 'enter' y darse cuenta de su error.

Primero de dos ...

En una caja de Solaris teníamos una copia de seguridad de tar de una máquina AIX.

Uno de los desarrolladores escribió:

tax xvf AIX_Backup.tar

Por supuesto, las rutas en el impuesto eran absolutas y terminamos haciendo una nueva distribución de Unix ... Solarix ... El único problema con la distribución es que no arranca :(

La historia me contó:

Otra sucursal llamó porque su PBX local tenía algunos problemas. Después de una investigación, supimos que actualizaron su servidor, pero no su configuración de Asterisk. Entonces, el administrador decidió instruir al tipo de la rama para rehacer la configuración.

Administrador: "Ok, ahora, escriba rm -rf / etc / asterisk"

Guy: "Ok"

Admin: "Ahora, escriba cp / var / ..."

Guy: "Espera, todavía se está ejecutando ..."

Admin: ??? ... !!!

rm -rf / some/path 

en lugar de

rm -rf /some/path 

Por suerte no me pasó a mí ;-)

source ~/.bash_history

Mi intención era la fuente .bashrc, pero era demasiado apresurado con la pestaña completa ...

Algo en la línea de esto:

sudo dd if=/dev/zero of=/dev/sda

Me refería a sda4. Limpié todo el disco, no solo la partición :-(

XCOPYes una bestia poderosa, despiadada en su ejecución y retrasada por el hecho de que sus argumentos de línea de comando van en reversa de Windows COPYy UNIX cp.

Hace un par de días escribí accidentalmente:

xcopy src \path\to\a\new\nonexistent\directory

XCOPYtuvo la amabilidad de sobrescribir mi srcdirectorio con ... ¡nada! Y tampoco se molestó en poner los archivos antiguos en la Papelera de reciclaje.

Ah, y resulta que en XCOPYrealidad sobrescribe los mismos sectores en el disco en lugar de asignar otros nuevos. He probado 3 programas de recuperación de disco, y el mejor solo pudo recuperar 3 de los 10 archivos perdidos. Por supuesto, esos 3 archivos eran únicos vshost.exey sus amigos. ¡Hinchar!

tuvo problemas con la red (en una máquina remota) y solo quería reiniciar la interfaz

ifconfig eth0 down && ifconfig eth0 upp

Hoy en día, me aseguro de que alguien esté cerca de la máquina antes de intentar cosas como esta (iptables también es un buen candidato). Y cuando no había nadie allí, una vez escribí

sleep 600; reboot

en otra terminal (pantalla), para que se reinicie si no puedo ctrl + c el comando en 10 minutos.

También aprendí de ese error (ctrl + c el sueño ejecutará el reinicio) y ahora uso

sleep 600 && reboot

lo que me permitirá ctrl + c.

ifconfig eth0 down

Vaya, estoy en el lado externo de eth0. El servidor web está al otro lado del mundo, en una habitación cerrada. Sin acceso a la red para iniciar sesión o reiniciar. Mierda.

Una cookie gratuita para cualquiera que pueda decirme por qué fui un idiota por tratar de eliminar todos los archivos y directorios ocultos:

rm -rf. *

Mientras limpiaba mi carpeta de inicio en un servidor web de producción, olvidé que había enlazado la raíz web del servidor a un lugar en mi carpeta de inicio. Sin pensarlo, ejecuté un rm -rf en esa carpeta y lo siguiente que sé es que la gente dice que el sitio web no funciona.

¡Vaya!

Una vez estaba comparando datos en dos carpetas y ejecuté rsync con la opción -d (eliminar archivos en el destino que no están en la fuente). Y luego cambié el origen y el destino cuando ejecuté rsync. Eso eliminó todos los archivos nuevos, que quería hacer una copia de seguridad. Ahora aprendí a ejecutar rsync con -n (ejecución en seco).

rsync -trvd --stats --progress /destination /source

No tenía respaldo.

Érase una vez (probablemente el Sistema III, pero fue hace mucho tiempo), fue posible crear un archivo llamado *usando la cita de shell correcta. Cuando encontré uno en mi directorio personal, había escrito rm *y tenía el dedo en la tecla de retorno cuando algo me hizo dudar y pensar en ello ...

Crear dicho archivo para otros usuarios era una broma común.

Si el archivo se encuentra allí en un directorio, es difícil de mitigar. El reflejo de simplemente escribir su nombre exactamente comols muestra es bastante fuerte.

La otra broma (menos dañina) fue nombrar archivos con espacios en blanco al final (o solo espacios en blanco) que eran mucho más difíciles de eliminar ...

Debido a alguna mala experiencia con la fragilidad general de JBoss después de un reinicio, me gusta borrar los archivos de trabajo de JBoss antes de un reinicio. Normalmente haría:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

Para protegerme de escribir cualquiera de los muchos errores desastrosos posibles, como:

• / tmp / *
• tmp / *
• tienes la idea

Hago el último comando:

# sudo -u jboss rm -rf tmp/* work/*

Dado que al usuario de JBoss le resultaría difícil eliminar los archivos críticos que no le pertenecen.

En realidad nunca cometí ese error, pero estoy a salvo en el caso de que lo haga.