por ·3 comentarios

 

Esta me la paso un capo (gracias estimado), con quien que tuve el privilegio de compartir keys SSH, bajo el título de «one liners endemoniados»: uno de esos one-liners que normalmente cuestan un huevo memorizar por lo complejo de la sintaxis, y que conviene siempre tener a mano en tu coso de agendar todas estas mierdas.

 

A la izquierda Linux, a la derecha Windows. Seamos realistas: algunas cosas en Windows son particularmente fáciles.

A la izquierda Linux, a la derecha Windows. Seamos realistas: algunas cosas en Windows son particularmente fáciles.

Más de una vez te habrá pasado que necesitas ordenar por fecha, saber por ejemplo cuál fue el último archivo modificado. Esta tarea que en Windows es una pavada, una cosa trivial, en Linux es un reverendisimo dolor de huevos (como todo en Linux en realidad, hasta que lo entendiste en lugar de memorizarlo, claro).

Continúa leyendo

por ·4 comentarios

Otro título sugerido: como evitar que cryptolocker, locky, o el ransomware de turno te siga haciendo mierda encriptando todos los archivos de la red.

 

Es imposible que a esta altura del partido no te hayas encontrado nunca o hayas escuchado hablar de los virus que te encriptan los archivos secuestrándolos para pedir rescate.

Ransomware - montaje representativo

Ransomware – montaje representativo

 

El modelo de negocio al parecer funciona demasiado bien, por lo que existen diversas variantes, cada cual con mayor o menor grado de astucia y complejidad, pero en el fondo todas apuntan a lo mismo: encriptar todo lo que haya a mano e imposibilitar los métodos más obvios de recuperación, rompiendo volume shadow copy por citar un ejemplo, incluidos los shares de la LAN (los recursos compartidos de las computadoras o servidores de la red).

Cuando estás del lado de los que administran los servidores de la red, a la primera señal de que hay un cryptolocker en la LAN vas a querer salir corriendo a:

  • Desconectar la workstation infectada con él ransomware para aislarla de la red.
  • Apagar todos los directorios compartidos de la red para que ningún otro idiota vaya por error a abrir el ejecutable que infecta las PC y continúe la cadena.

Continúa leyendo

por ·Sin comentarios

Otro título sugerido: como cortar clavos cortar bulones tirafondo de ocho pulgadas al reiniciar un servidor.

 

Esta si sos Linuxero, la tenés que conocer si o sí: ¡¡¡REInicia SUBnormal!!! (de acuerdo a la Wikipedia).

También te puedo remitir al artículo que escribí al respecto hace algunos años acerca de lo mismo: «[TIP] Linux nunca se cuelga y puedo probarlo.«.

 

Bueno, hoy vengo con la misma pero remota, que también se puede. Por que a veces Linux se traba tan pero tan jodido que no le sacás el palo de la rueda ni con el comando reboot, por que el comando también crashea o se queda trabado.

Esta se me ocurrió ayer, luego de no poder reiniciar un servidor que quedó paralítico después de que se le murió un disco. Cuando te pasa esto, es probable no puedas –como me pasó a mi– ni siquiera ejecutar el comando para mandar a reiniciar el servidor, sea shutdon, init o reboot. Las bolas, no se reinicia y todo se queda trabado.

Mandando a reiniciar ese servidor que se hace el duro desde la comodidad de tu casa

Mandando a reiniciar ese servidor que se hace el duro desde la comodidad de tu casa

 

Una vez mas: REISUB al rescate.

Así como ponés al Kernel en modo System Request (Un modo al que el kernel responderá ni importa que cosa sea que esté haciendo) para comandarlo con combos de teclas, también podés comandarlo mediante la consola de comandos, lo que posibilita que en determinadas circunstancias como la que te contaba me pasó ayer, puedas mandar el combo de teclas equivalente a la fatality (ALT + SysRQ/PrnScrn + O/B) cómodamente desde el sillón de tu casa, sin haber despegado nunca el culo del antes mencionado ni haber tenido que ir hasta el servidor a hacharle el cable power al grito de «apagate sorete!».

Lo que sigue es el equivalente a estar presente con toda la parsimonia y presionar el botón de reset. Cosa particularmente útil además si consideramos que prácticamente ningún servidor tiene en realidad un botón de reset y para eso está el ILO/iDRAC/IMMS y etc.

 

Paso 1: poner al kernel en modo System Request:

echo 1 > /proc/sys/kernel/sysrq

 

Paso 2: cruzar los dedos e ir aprontando todo lo necesario para viajar hasta el lugar de la reparación cuando el servidor no vuelva del reboot y no te funcione la credential del KVM IP.

 

Paso 3 (a.k.a: Release the Kraken!), mandar a rebootear:

echo b > /proc/sysrq-trigger

 

¿Te sirvió? ¿Te salvé el culo? De nada, ¿Eh?.

Y por si no era super-obvio, también responde a todos los demás comandos de SysRQ por la misma vía, entonces podés por ejemplo sincronizar los discos, vaciar todas las caché y desmontar todo antes de reiniciar, por ejemplo.

por ·Sin comentarios

Prefacio: no le mandé un signo de admiración en el título para hacerlo mas llamativo. El mensaje de error propiamente dicho –cuando se manifiesta y si estás leyendo esto por que te pasó va mi mas sentido pésame-, citado literalmente dice «Directory index full!» así como le leés, provocador, quilombero y gritón.

Puto el developer que dió por sentado que cualquier usuario de Linux de a pié va a saber que carajos es el directory index y puto el que le agregó un signo de exclamación al final. Mangas de hippies melodramáticos. Como si fuera tan grave.

No importa. Si estás leyendo esto por que llegaste desde Google, cosa que dudo por que este blog no rankea y por eso no me lee nadie, estás en el mismo bote en donde ya estuve muchas veces y seguramente habrás dicho: uh? WTF?

Si no llegaste desde Google, posiblemente quieras cerrar la tab del navegador e irte a hacer otra cosa. Lo que sigue no le importa a nadie mas que a los pocos infelices que nos topamos alguna vez con este error de mierda.

ext3_dx_add_entry: Directory index full! - Este soy yo cuando me pasa, notesé mi cara de felicidad.

ext3_dx_add_entry: Directory index full! – Este soy yo cuando me pasa, notesé mi cara de felicidad.

Continúa leyendo