GNU/Linux >> Tutoriales Linux >  >> Linux

El forkbomb accidental:Cómo un script *nix sale mal

Uno de los primeros trabajos de la industria que tuve fue en un pequeño ISP regional. En ese momento, los módems de 56k eran brillantes y nuevos. Teníamos un par de docenas de PoP (puntos de presencia) en los que instalamos bancos de módems y devolvíamos los datos a nuestra oficina principal a través de una serie de líneas T1 completas y fraccionadas.

Ofrecimos la gran cantidad de servicios típicos:correo electrónico, noticias de la red y acceso general a Internet. Por supuesto, para brindar estos servicios, necesitábamos servidores propios. La solución fue configurar un clúster de sistemas SCO Unix. Sí, *eso* SCO. Ha pasado bastante tiempo, pero una configuración de clúster como esta es difícil de olvidar. Los servidores se configuraron de tal manera que tenían dependencias entre sí. Si uno fallaba, no causaba que todo colapsara, pero obtener una copia de seguridad de ese servidor generalmente requería reiniciar todo.

La configuración general era que el NFS de los servidores se montaba entre sí al inicio. Esto, por supuesto, provoca una condición de carrera durante el arranque. Los ingenieros habían escrito un documento detallado que explicaba los pasos necesarios para recuperar todo el clúster después de una falla. El proceso completo generalmente tomó de 30 a 45 minutos.

En ese momento, yo era un miembro humilde del soporte técnico, y pasaba la mayor parte de mi tiempo ayudando a los nuevos clientes a través del proceso de instalación del software necesario para estar en línea. Era relativamente nuevo en el mundo de Unix y las redes de alta velocidad y absorbía todo el conocimiento que podía.

[ También te puede interesar: Aspectos destacados de la terminal de Linux:más allá de lo vulgar]

Una de las personas con las que trabajé, Brett, me enseñó mucho. Escribió el sistema de monitoreo de red que usamos y dividió su tiempo entre eso y mantener la red en funcionamiento. A veces también era un poco bromista.

Al final de un día bastante típico, me encontraba en el clúster de Unix. De repente, mi conexión falló y reinicié mi sistema operativo local. Esto fue un poco extraño, pero sucedió de vez en cuando, así que simplemente volví a iniciar sesión. En unos segundos, fui expulsado nuevamente.

Empecé a hacer un poco de depuración, tratando de averiguar qué estaba pasando. No recuerdo todo lo que hice, pero sí recuerdo armar algunos scripts rápidos para iniciar sesión, verificar varios procesos e intentar averiguar qué estaba sucediendo. En algún momento, determiné que otro usuario, Brett, me estaba arrancando del sistema.

Una vez que me di cuenta de lo que estaba pasando, tuve que defenderme. Así que comencé a jugar con secuencias de comandos de shell, tratando de descubrir cómo identificar el PID de su shell para poder desconectarlo. Esto fue de ida y vuelta por un momento, cada uno de nosotros escalando los ataques. Empezamos a usar otros servicios para recuperar el acceso, lanzar ataques, etc.

Finalmente, lancé lo que pensé que sería el ataque DEFINITIVO. Escribí un pequeño script de shell que buscaba su inicio de sesión, identificaba el shell y, posteriormente, eliminaba su acceso. Bastante simple, pero agregué el toque final. Después de que se ejecutó el script, ejecutó una copia de sí mismo. AUGE. No hay forma de que pueda volver ahora.

¡Y funcionó! Brett perdió su acceso y simplemente no pudo establecer un punto de apoyo durante los siguientes cinco minutos más o menos. Y, por supuesto, había puesto en segundo plano la tarea para poder interactuar con la consola y verificar que estaba vencido. Habia ganado. Había demostrado que podía vencer al ingeniero experimentado y, maldición, me sentía bien al respecto.

Hasta que...

ksh:bifurcación:Recurso temporalmente no disponible

El principio del fin

Nunca antes había visto un error así. ¿Que era esto? ¿Por qué el sistema estaba haciendo esto? ¿Y por qué se transmitía por toda mi consola, lo que me impedía hacer algo?

[ Hoja de referencia gratuita:consejos para entrevistas de trabajo de TI ] 

Le tomó unos momentos, pero Brett también notó el problema. Salió a ver qué había pasado. Le expliqué mi brillante estrategia y él simplemente suspiró, sonrió y me dijo que tendría que encargarme de reiniciar y volver a sincronizar los servidores. Y luego se tomó el tiempo de explicarme lo que había hecho mal. Ese fue el día que aprendí sobre "ejecutivo" y lo importante que es.

Desafortunadamente, Brett falleció aproximadamente una década después de esto. Fue un gran amigo, un gran mentor y lo extraño.


Linux
  1. Carreras de administrador de sistemas:la correlación entre los mentores y el éxito

  2. ¿Cómo obtener la dirección IP propia y guardarla en una variable en un script de Shell?

  3. ¿Cómo saber la última vez que se utilizó un correo electrónico?

  4. Cómo saber cuándo se creó el Spfile en un servidor Linux

  5. ¿Cómo sé el nombre del archivo de script en un script Bash?

Cómo juego Tetris en el mainframe

Cómo ha crecido el escritorio de Linux

Cómo hacer que el escritorio Plasma se parezca a Unity

¿Cómo funcionan los pseudo-terminales *nix? ¿Cuál es el canal maestro/esclavo?

¿Cómo canalizo o redirijo la salida de curl -v?

¿Cómo copiar la salida del terminal?