por ·Sin comentarios

Lo de sin SWAP: no se puede, pero que hice el intento, que quede constancia.

Nada mas hacer swapoff /dev/sda2 y sdb2 (esta pc tiene dos discos rígidos en raid) se me murió el kernel y tuve que usar el viejo truco para poder hacer un reinicio limpio.

Me preguntaba hasta que punto puede optimizarse el código en un sistema operativo y que tanto es dependiente de la cantidad de memoria ram instalada… ¿La respuesta? Es MUUUUY dependiente.

Le he quitado los dos módulos de memoria DDR a esta pc desde la que escribo y le he puesto uno que andaba por ahí tirado, de 128Mb. Le he retirado además la placa de video y estoy escribiendo con la onboard y el driver VESA. De los 128Mb totales estoy usando 32 como memoria de video.

Niños, no intenten esto en casa. Ni siquiera siendo Gentoo el sistema es algo parecido a utilizable.

Escribo desde un Gentoo con kernel 2.6.30, sin nada de otro mundo. XFCE 4.6 como entorno de escritorio, Opera 10 y aMSN corriendo… El resultado:

  • 92Mb de ram utilizados, 2 disponibles.
  • 101Mb de memoria SWAP en uso
  • 10 segundos de espera entre un click y el siguiente…

Y hasta aquí llegué, voy a reiniciar para volver todo a la normalidad. Se me terminó la paciencia.

por ·6 comentarios

Bajo la premisa: «No es que yo sea paranoico, es que me están siguiendo…» alguien ha creado un par de scripts que hacen a tu pc ridículamente segura y hasta le ha dado nombre (y apellido); Crypto Port Knocking 0 Single packet authentication. –o ambas cosas juntas, en realidad–

Sencillamente genial.

¿Creíste que tu Linux con SELinux, ACL, Port knocking, Fail2ban, Snort, OSSEC, sin puertos abiertos, con autenticación SSH basada en llaves, con el usuario root deshabilitado y todos los servicios enjaulados, los DNS y la tabla ARP estática era seguro?

No… No es seguro. Al menos no para el creador de esta obra maestra de la seguridad que ha llevado la cosa a tal extremo que raya con el absurdo.

Si te interesan estos temas, después del salto viene lo bueno. Es fundamental tener una noción básica de bash y entender un poco de inglés para echarlo a andar:  Continúa leyendo

por ·Sin comentarios

No son leyenda urbana. Los kernel panics existen…

Mientras el hardware esté sano, linux no falla, pero ¿Y si el hardware falla? ¿Y si falla en un servidor al cual no tenemos acceso físico? En esos casos es vital que la pc o el servidor remoto reinicien automáticamente después de un kernel panic.

El kernel de linux por defecto no reinicia el sistema en caso de un kernel panic de forma de que sea accesible por pantalla el volcado de memoria y el error específico, y esto no siempre es lo que se necesita (sobre todo si el sistema remoto no tiene un monitor instalado o no hay nadie presente físicamente en el lugar).

Para lograr que el kernel reinicie el sistema en caso de un kernel panic hay que modificar el contenido del archivo /proc/sys/kernel/panic:

~ # echo 5 >> /proc/sys/kernel/panic

Donde 5 es la cantidad de segundos que queremos esperar antes de que se produzca el reinicio del sistema.

Verificando el contenido del archivo:

~ # cat /proc/sys/kernel/panic
5

De esta forma el cambio de aplica de manera inmediata, pero como el contenido del archivo panic es volatil, los cambios se pierden luego del primer reinicio del sistema operativo.

Para que el cambio sea efectivo de forma permanente hay que implementarlo sobre el archivo /etc/sysctl.conf descomentariando la siguiente línea:

# When the kernel panics, automatically reboot in 3 seconds
#kernel.panic = 3

O bien, pasarle el parametro en cuestión al kernel durante el arranque desde el boot loader, por ejemplo, agregando panic=5 a /boot/grub/menu.lst:

kernel /boot/kernel root /dev/sda1 panic=5

Usando la combinación de el parámetro panic con la opción fallback de grub  es posible por ejemplo, testear un nuevo kernel de manera remota, de esta forma, en caso de un kernel panic arrancando un nuevo kernel grub puede arrancar al segundo intento desde un kernel viejo, sistema de archivos viejo, etc, etc, pero eso es tema para otro artículo.