Hace más de un año empecé mi empresa con una propuesta idealista.
Brindar servicios de seguridad informática a personas y empresas en Costa Rica y bueno desde donde quieran y ocupen estos servicios.
Les cuento, ha sido muy dificil, sobre todo porque en Costa Rica tendemos a creer que nada nos va a pasar, que le pasa a otros, y sobre todo que no tengo nada de valor que me roben así que no debo preocuparme.
Hoy salió una noticia en la nacion.com de que el sitio de Movistar Costa Rica (movistar.cr) fue "defaced", esto es que crackers modifican la página con una no autorizada. En la nación decía además que Movistar "levantó" la página, sin embargo lo que hicieron fue redirigir el sitio al sitio oficial de Telefónica.
Vemos que existe mucha desinformación en Tecnologías de Información en nuestro país y sobre todo que nos creemos intocables, así que brindar servicios para mejorar en estos aspectos es mucho más dificil en nuestro contexto de lo que había pensado inicialmente.
Lamentablemente no se vive de sueños, ni de intentos, muchos dicen que el peor intento es el que no se hace y es cierto, esta experiencia me ha dado mucha más confianza en mi mismo se que puedo manejar diferentes situaciones que antes simplemente no podía, he crecido como empresario y como persona.
Pero los intentos no llevan dinero a la casa y con una bebé en camino --nace en este diciembre-- pues la presión es mucho mayor.
Y es que en servicios para ganar más hay que trabajar más y se llega a un punto en el que no se puede trabajar más de 24 horas al día, así que he pensado que es momento de diversificar nuestro portafolio de productos además de los servicios de administración de TI, de seguridad, de administración de Linux y programación, necesitamos un producto que sea fácil de mercadear, que sea necesario no solo por Costa Rica sino que tenga un mercado más amplio y del que no dependa mi tiempo máximo de 24 hrs por día.
No es algo que se logre del dia a la mañana y definitivamente necesita inversión, pero trataremos de hacerlo de la mejor manera posible, de la misma manera que siempre he hecho todos los trabajos, aunque al inicio haya ciertos baches como en todo.
Con todo esto les digo no me doy por vencido voy a seguir con este emprendimiento y hay que trabajar más fuerte que antes.
Saludos,
Sergio,
18 November, 2011
10 September, 2011
Redes Inalámbricas
Las redes inalámbricas han traído una comodidad adicional a la hora de utilizar una computadora si recuerdan cuando apenas estaba iniciando esto: laptops con antenas WiFi externas o tipo PCMCIA en muy pocos lugares, había WiFi y sólo el personal más importante tenía acceso a esta tecnología, nadie pensaba en ese momento que un teléfono celular fuera a tener acceso a una red WiFi cierto?
Hoy día todo esto ha cambiado todas las laptops, netbooks, celulares, gadgets, etc.. se espera que soporten WiFi, lo único que se ha mantenido es la manera en que se configuran este tipo de redes, verán en los sitios que proveen internet inalámbrico WiFi las redes por lo general están abiertas, esto es sin encripción y la gente que cree que tener una red con encripción protege la red y los usuarios está equivocado, lo único que hace es proteger (dependiendo del cifrado y llave utilizada) el acceso a la red inalámbrica.
Cuantos de ustedes han visto una red llamada "linksys" y se han conectado a ella desde el celular o laptop, tal vez para probar si está abierta y pueden revisar el correo por un momento, eso no le hace daño a nadie cierto?
La respuesta si le hace daño a usted mismo si no sabe a que red se está conectando y si utiliza protocolos inseguros o si su dispositivo no está protegido.
Verán por lo general desactivo el WiFi de mi celular cuando salgo de casa por dos propósitos, ahorrar batería y para que el teléfono no se conecte a una red WiFi abierta, cuando un celular se conecta a una red WiFi ésta tiene prioridad sobre la red 3G o Edge, así que el tráfico irá por dicha red, así sea sincronizar el correo o cualquier cosa que funcione en background y se conecte a Internet.
Para hacernos más fácil la vida los diseñadores de estos dispositivos nos brindan una lista de redes preferidas que puede guardar el aparato para no tener que volver a poner la contraseña (si tiene) la próxima vez que queramos conectarnos a una red, pero también al estar una red en nuestra lista le hemos dado --sin querer-- cierta autorización que el dispositivo se conecte a dicha red cada vez esté al alcance.
Resulta que aunque cada red tiene más información que la identifica aparte del nombre, esto es lo único utilizado para conectarse, así que si usted confía en una red llamada MiCasa, la próxima vez que su dispositivo esté dentro del rango de MiCasa el mismo se va a conectar aunque no sea SuCasa sino la de un access point malicioso por ejemplo o la red de una persona sin malas intenciones.
En ese momento estará expuesto su dispositivo a cualquier ataque dentro de esa red, por ejemplo un virus, un hacker, un programa especial para atacar y robar datos o crear zombies para un botnet.
Por ese lado de las WiFi les recomiendo mantener su WiFi apagado (del celular, laptop o cualquier otro aparato y activarlo y verificar a cual red se está conectando), siempre tener un firewall local en su máquina, celular, o dispositivo, junto con antivirus actualizado, tanto en sus dispositivos móviles como los de su casa y estar atento a cualquier situación anómala con los mismos.
Con respecto a los celulares e Internet móvil, tal vez no muchos de ustedes sabrán que la tecnología GSM puede ser "escuchada" por un intermediario esto aplica para los SMS, llamadas, Internet por Edge o GPRS. Siempre que tenga acceso a 3G y su teléfono lo permite, desactivar el acceso a redes 2G.
Es mejor quedarnos sin acceso a Internet o llamadas a que puedan escuchar nuestras llamadas o manipular datos de nuestros dispositivos.
Saludos,
Be safe.
Hoy día todo esto ha cambiado todas las laptops, netbooks, celulares, gadgets, etc.. se espera que soporten WiFi, lo único que se ha mantenido es la manera en que se configuran este tipo de redes, verán en los sitios que proveen internet inalámbrico WiFi las redes por lo general están abiertas, esto es sin encripción y la gente que cree que tener una red con encripción protege la red y los usuarios está equivocado, lo único que hace es proteger (dependiendo del cifrado y llave utilizada) el acceso a la red inalámbrica.
Cuantos de ustedes han visto una red llamada "linksys" y se han conectado a ella desde el celular o laptop, tal vez para probar si está abierta y pueden revisar el correo por un momento, eso no le hace daño a nadie cierto?
La respuesta si le hace daño a usted mismo si no sabe a que red se está conectando y si utiliza protocolos inseguros o si su dispositivo no está protegido.
Verán por lo general desactivo el WiFi de mi celular cuando salgo de casa por dos propósitos, ahorrar batería y para que el teléfono no se conecte a una red WiFi abierta, cuando un celular se conecta a una red WiFi ésta tiene prioridad sobre la red 3G o Edge, así que el tráfico irá por dicha red, así sea sincronizar el correo o cualquier cosa que funcione en background y se conecte a Internet.
Para hacernos más fácil la vida los diseñadores de estos dispositivos nos brindan una lista de redes preferidas que puede guardar el aparato para no tener que volver a poner la contraseña (si tiene) la próxima vez que queramos conectarnos a una red, pero también al estar una red en nuestra lista le hemos dado --sin querer-- cierta autorización que el dispositivo se conecte a dicha red cada vez esté al alcance.
Resulta que aunque cada red tiene más información que la identifica aparte del nombre, esto es lo único utilizado para conectarse, así que si usted confía en una red llamada MiCasa, la próxima vez que su dispositivo esté dentro del rango de MiCasa el mismo se va a conectar aunque no sea SuCasa sino la de un access point malicioso por ejemplo o la red de una persona sin malas intenciones.
En ese momento estará expuesto su dispositivo a cualquier ataque dentro de esa red, por ejemplo un virus, un hacker, un programa especial para atacar y robar datos o crear zombies para un botnet.
Por ese lado de las WiFi les recomiendo mantener su WiFi apagado (del celular, laptop o cualquier otro aparato y activarlo y verificar a cual red se está conectando), siempre tener un firewall local en su máquina, celular, o dispositivo, junto con antivirus actualizado, tanto en sus dispositivos móviles como los de su casa y estar atento a cualquier situación anómala con los mismos.
Con respecto a los celulares e Internet móvil, tal vez no muchos de ustedes sabrán que la tecnología GSM puede ser "escuchada" por un intermediario esto aplica para los SMS, llamadas, Internet por Edge o GPRS. Siempre que tenga acceso a 3G y su teléfono lo permite, desactivar el acceso a redes 2G.
Es mejor quedarnos sin acceso a Internet o llamadas a que puedan escuchar nuestras llamadas o manipular datos de nuestros dispositivos.
Saludos,
Be safe.
09 September, 2011
Especialización de ataques informáticos
Hemos visto en los últimos años / meses ataques informáticos o cibernéticos, más especializados y elaborados que nunca antes, han ido variando desde robo de información confidencial principalmente secretos comerciales hasta el uso de gusanos especializados para atacar centrales nucleares.
Este año unos importantes y que llaman la atención han sido los ataques a Comodo y DigiNotar ambos son autoridades certificadoras de SSL, la idea detrás de los certificados SSL y los CAs, es que cada navegador de internet, distribución de Linux o programa confía en ciertos CAs.
Los ataques a los CAs se basan en esa confianza depositada ciegamente en las mismas autoridades certificadoras y que por lo mismo si yo compro un certificado a X CA espero que el mismo pueda ser validado por Y navegador de internet al otro lado del mundo.
Ese mismo es el problema con todo esto de los certificados, mis usuarios confían en que la transmisión de datos desde su navegador hasta mi servidor está encriptada y validada por un tercero del cual no tengo control alguno.
La idea de atacar los CAs es justamente crear certificados falsos para X.Y dominio el cual todos los navegadores van a confiar, entonces un ataque de phising bien elaborado hacia un servidor con una copia de un sitio web y utilizando certificados falsos (pero válidos por una CA) y tendrá la receta casi completa.
Verán, cuando uno ya tiene un certificado de SSL para un sitio web o aplicación específica, no piensa en comprar otro certificado a otra CA, por ejemplo usted tiene un certificado con Thawte vigente, no piensa en comprar uno a Verisign para el mismo nombre, cierto?
Sin embargo si lo hiciera y pusiera ambos certificados en dos servidores diferentes, un navegador que entre a ambos sitios estará navegando de manera segura, encriptada y validada por dos CAs diferentes.
Así que se debe mantener actualizado el software de nuestras computadoras, nuestros celulares aunque hasta ahora me parece que ninguno ha brindado una actualización de los certificados raíz de las CAs, sería algo muy importante que se hiciera.
La otra idea es como se puede traducir esto a otros sistemas? En Costa Rica ya se empieza a utilizar la famosa mal llamada "firma digital" (lo cual no es una firma y el que le puso ese nombre es un burro completo, pero eso será para otro momento), trabaja bajo el mismo concepto de un token con una llave privada y certificado firmado para dicha llave por parte de un CA (o banco y eventualmente otras instituciones) cuanto faltará para que este tipo de ataques se especialicen aún más y vayan detrás de este tipo de tecnologías.
Unan los ataques a los CAs, a RSA con los SecurID, gusanos especializados como Stuxnet, y ahora bancos que confían en CAs, RSA para los tokens, o firmas digitales.
Un gusano esperando a que todos estos puntos se junten y nuestros ahorros estarán otra vez en problemas.
Saludos,
Be safe!
Este año unos importantes y que llaman la atención han sido los ataques a Comodo y DigiNotar ambos son autoridades certificadoras de SSL, la idea detrás de los certificados SSL y los CAs, es que cada navegador de internet, distribución de Linux o programa confía en ciertos CAs.
Los ataques a los CAs se basan en esa confianza depositada ciegamente en las mismas autoridades certificadoras y que por lo mismo si yo compro un certificado a X CA espero que el mismo pueda ser validado por Y navegador de internet al otro lado del mundo.
Ese mismo es el problema con todo esto de los certificados, mis usuarios confían en que la transmisión de datos desde su navegador hasta mi servidor está encriptada y validada por un tercero del cual no tengo control alguno.
La idea de atacar los CAs es justamente crear certificados falsos para X.Y dominio el cual todos los navegadores van a confiar, entonces un ataque de phising bien elaborado hacia un servidor con una copia de un sitio web y utilizando certificados falsos (pero válidos por una CA) y tendrá la receta casi completa.
Verán, cuando uno ya tiene un certificado de SSL para un sitio web o aplicación específica, no piensa en comprar otro certificado a otra CA, por ejemplo usted tiene un certificado con Thawte vigente, no piensa en comprar uno a Verisign para el mismo nombre, cierto?
Sin embargo si lo hiciera y pusiera ambos certificados en dos servidores diferentes, un navegador que entre a ambos sitios estará navegando de manera segura, encriptada y validada por dos CAs diferentes.
Así que se debe mantener actualizado el software de nuestras computadoras, nuestros celulares aunque hasta ahora me parece que ninguno ha brindado una actualización de los certificados raíz de las CAs, sería algo muy importante que se hiciera.
La otra idea es como se puede traducir esto a otros sistemas? En Costa Rica ya se empieza a utilizar la famosa mal llamada "firma digital" (lo cual no es una firma y el que le puso ese nombre es un burro completo, pero eso será para otro momento), trabaja bajo el mismo concepto de un token con una llave privada y certificado firmado para dicha llave por parte de un CA (o banco y eventualmente otras instituciones) cuanto faltará para que este tipo de ataques se especialicen aún más y vayan detrás de este tipo de tecnologías.
Unan los ataques a los CAs, a RSA con los SecurID, gusanos especializados como Stuxnet, y ahora bancos que confían en CAs, RSA para los tokens, o firmas digitales.
Un gusano esperando a que todos estos puntos se junten y nuestros ahorros estarán otra vez en problemas.
Saludos,
Be safe!
01 September, 2011
Del compostaje
El compostaje es lo que se conoce como abono orgánico, pero ojo no todo lo orgánico es bueno para el compostaje.
¿Por qué? se preguntarán...
Bueno porque en algunos casos puede afectar el producto final, por ejemplo utilizar restos de comida en el compostaje, aumentará los niveles de grasas y sales en la mezcla, lo menos que queremos es que todo eso se traslade a la huerta en la que vamos a utilizar el compostaje.
Otro ejemplo es los desechos orgánicos de animales o humanos, aunque son ricos en materia orgánica no pensaríamos lo mismo al momento de ingerir los alimentos de nuestro huerto, además de que elementos patógenos podrían resistir el proceso de compostaje y eventualmente colarse hasta nuestra mesa.
Y todo esto es para comentarles que ya tengo mi pila de compost, a la cual no parece irle muy bien, sobre todo porque no ha aumentado la temperatura de la pila y esto impide la buena descomposición y en su lugar está sucediendo que los elementos se pudren, proliferan un montón de bichos como hormigas, gusanos, escarabajos entre otros que no creo les guste tanto vivir dentro de un ambiente de unos 60 grados centígrados (ideal en una buena pila de compost), en fin me parece que le falta un techito o algo para que no se moje tanto, y posiblemente le falte algún tipo de "ingrediente" para aumentar la temperatura.
Entre tanto sigo echándole las sobras de cáscaras de papa, papaya, banano, zanahoria, café y todas esas cosas que salen normalmente de la cocina y que van a parar al basurero, lo cual les puedo decir en mi casa ha dejado de dar malos olores.
Saludos,
¿Por qué? se preguntarán...
Bueno porque en algunos casos puede afectar el producto final, por ejemplo utilizar restos de comida en el compostaje, aumentará los niveles de grasas y sales en la mezcla, lo menos que queremos es que todo eso se traslade a la huerta en la que vamos a utilizar el compostaje.
Otro ejemplo es los desechos orgánicos de animales o humanos, aunque son ricos en materia orgánica no pensaríamos lo mismo al momento de ingerir los alimentos de nuestro huerto, además de que elementos patógenos podrían resistir el proceso de compostaje y eventualmente colarse hasta nuestra mesa.
Y todo esto es para comentarles que ya tengo mi pila de compost, a la cual no parece irle muy bien, sobre todo porque no ha aumentado la temperatura de la pila y esto impide la buena descomposición y en su lugar está sucediendo que los elementos se pudren, proliferan un montón de bichos como hormigas, gusanos, escarabajos entre otros que no creo les guste tanto vivir dentro de un ambiente de unos 60 grados centígrados (ideal en una buena pila de compost), en fin me parece que le falta un techito o algo para que no se moje tanto, y posiblemente le falte algún tipo de "ingrediente" para aumentar la temperatura.
Entre tanto sigo echándole las sobras de cáscaras de papa, papaya, banano, zanahoria, café y todas esas cosas que salen normalmente de la cocina y que van a parar al basurero, lo cual les puedo decir en mi casa ha dejado de dar malos olores.
Saludos,
19 July, 2011
Se me habia olvidado que existía este blog
Jajaja..
Será continuarlo y escribir más seguido.
Algunas de las ideas que tengo por el momento:
Será continuarlo y escribir más seguido.
Algunas de las ideas que tengo por el momento:
- Crear un invernadero para hortalizas y esas cosas
- Recopilar agua de lluvia para el invernadero
- Compostaje
- Aumentar las cámaras de video de la casa
10 March, 2010
Sysadmin Horror Story
Estaba haciendo una migración de un servicio, todo parecía bien.
La maniobra:
Mover IP 192.168.85.20 de servidor A a servidor B
Dejar en servidor A la IP 192.168.85.21 para poder acceder a el por medio de B posteriormente.
Iniciamos cambiando la IP de servidor A para liberar la .85.20
ifconfig eth0 192.168.85.21
(Que sucedió aquí?)
La IP de eth0 es cambiada exitosamente a 192.168.85.21 pero el default gw desaparece, se pierde conexión inmediatamente (debido a que estabamos logeados a 192.168.85.20)
Segundo paso, en servidor B:
at now + 5
reboot
C-D
Con eso se indica al servidor que se reinicie a los 5 minutos (si algo sale mal y se pierde conexión) al mismo.
Cambiamos IP:
(previamente se configura el servidor para levantar en eth0:0 la IP 192.168.85.22)
ifconfig eth0:0 192.168.85.22 (supongamos que tenemos acceso externo a esta IP)
ifconfig eth0 192.168.85.20
(Que sucedió aquí?)
Perdemos el default gateway, dichosamente tenemos nuestros 5 minutos de gracia.
Esperamos con paciencia....
...
...
...
Levantó perfecto.
Ingresamos a 192.168.85.22 en medio de una llamada telefónica preguntándonos que sucede..
Cambiemos IP rápidamente (el downtime del servicio aumenta)
ipconfig eth0 192.168.85.21
(Que sucedió aquí?)
Perdemos el default gateway y quedamos fuera completamente debido a que no ejecutamos nuestra medida de precaución "at now + 5"
Ok, anunciamos el problema y solicitamos apoyo para ubicar el servidor y reiniciarlo manualmente.
Primer problema, no hay documentación completa sobre la ubicación del servidor, y nadie sabe donde está, damos unas señas de como es el servidor pero no es suficiente.
Pasan los minutos....
Más minutos...
1 hora....
Nos indican que ya ubicaron el servidor... pero hay otro problema, está en un gabinete con llave por delante y por detrás.
Se hace conferencia con personal de servidores y telecomunicaciones, se les indica que el servidor tiene IP en 192.168.85.X que solo se ocupa otro equipo en el mismo segmento de red para poder ingresar por SSH.
Encuentran un equipo que nos funciona, pero no hay cliente de SSH disponible, no podemos enviar binarios a nuestra contraparte en sitio por medio de email, y el no puede acceder libremente a Internet para bajar uno.
A todo esto el único password que podría darle es el de root pero por defecto se tiene que root no puede iniciar sesión en SSH, el otro password no se puede dar a un tercero.
La idea de poder ingresar por SSH para agregar el default gateway, luego configurar los archivos y reiniciar la máquina.
Un compañero se apersona al lugar para ingresar por SSH con un cliente que lleva en una unidad de USB (usb key).
Ingresa, se ejecutan un par de comandos y listo.
Se reinicia la máquina y todo empieza a funcionar.
Un downtime que debió ser de 15 minutos máximo, resultó ser de 2 horas.
This is my sysadmin horror story, if only I had access to a VPN or something more transparent.
La maniobra:
Mover IP 192.168.85.20 de servidor A a servidor B
Dejar en servidor A la IP 192.168.85.21 para poder acceder a el por medio de B posteriormente.
Iniciamos cambiando la IP de servidor A para liberar la .85.20
ifconfig eth0 192.168.85.21
(Que sucedió aquí?)
La IP de eth0 es cambiada exitosamente a 192.168.85.21 pero el default gw desaparece, se pierde conexión inmediatamente (debido a que estabamos logeados a 192.168.85.20)
Segundo paso, en servidor B:
at now + 5
reboot
C-D
Con eso se indica al servidor que se reinicie a los 5 minutos (si algo sale mal y se pierde conexión) al mismo.
Cambiamos IP:
(previamente se configura el servidor para levantar en eth0:0 la IP 192.168.85.22)
ifconfig eth0:0 192.168.85.22 (supongamos que tenemos acceso externo a esta IP)
ifconfig eth0 192.168.85.20
(Que sucedió aquí?)
Perdemos el default gateway, dichosamente tenemos nuestros 5 minutos de gracia.
Esperamos con paciencia....
...
...
...
Levantó perfecto.
Ingresamos a 192.168.85.22 en medio de una llamada telefónica preguntándonos que sucede..
Cambiemos IP rápidamente (el downtime del servicio aumenta)
ipconfig eth0 192.168.85.21
(Que sucedió aquí?)
Perdemos el default gateway y quedamos fuera completamente debido a que no ejecutamos nuestra medida de precaución "at now + 5"
Ok, anunciamos el problema y solicitamos apoyo para ubicar el servidor y reiniciarlo manualmente.
Primer problema, no hay documentación completa sobre la ubicación del servidor, y nadie sabe donde está, damos unas señas de como es el servidor pero no es suficiente.
Pasan los minutos....
Más minutos...
1 hora....
Nos indican que ya ubicaron el servidor... pero hay otro problema, está en un gabinete con llave por delante y por detrás.
Se hace conferencia con personal de servidores y telecomunicaciones, se les indica que el servidor tiene IP en 192.168.85.X que solo se ocupa otro equipo en el mismo segmento de red para poder ingresar por SSH.
Encuentran un equipo que nos funciona, pero no hay cliente de SSH disponible, no podemos enviar binarios a nuestra contraparte en sitio por medio de email, y el no puede acceder libremente a Internet para bajar uno.
A todo esto el único password que podría darle es el de root pero por defecto se tiene que root no puede iniciar sesión en SSH, el otro password no se puede dar a un tercero.
La idea de poder ingresar por SSH para agregar el default gateway, luego configurar los archivos y reiniciar la máquina.
Un compañero se apersona al lugar para ingresar por SSH con un cliente que lleva en una unidad de USB (usb key).
Ingresa, se ejecutan un par de comandos y listo.
Se reinicia la máquina y todo empieza a funcionar.
Un downtime que debió ser de 15 minutos máximo, resultó ser de 2 horas.
This is my sysadmin horror story, if only I had access to a VPN or something more transparent.
16 February, 2010
Parametros del kernel
Me sucedió con una máquina, que se le puso 1GB de memoria y luego de esto tardaba alrededor de 15 minutos iniciando con un alto consumo de CPU.
Investigando en Internet, encontré y aprendí un poco como maneja Linux la memoria, resulta que el kernel separa un espacio de memoria directamente accesible, en la cual se va mapear la parte alta de la memoria.
Resulta que éste mapeo de la memoria tiene un costo de procesamiento, en el caso de la máquina de prueba el costo es demasiado alto, tal vez el kernel es un poco viejo, pero resulta que con el parámetro mem=896M al kernel se puede limitar la cantidad de memoria disponible, de ésta manera se trabaja sin el mapeo y el desempeño mejora, la verdad se podría intentar con un kernel más nuevo (el actual de la máquina es 2.6.18-128.2.16.v5 en CentOS 5.3) pero no vale el esfuerzo.
Resulta que buscando el valor mágico de 896M encontré que existe otro parámetro muy interesante cuando se trata de servidores Linux, de vez en cuando sucede un kernel panic, cuando esto sucede el kernel nos deja en la pantalla un mensaje del error, pero en mi caso particular me interesa que el servidor esté arriba la mayor parte del tiempo algunas veces no puedo desplazarme hasta donde está la máquina para ver el error y reiniciarla, hay un parámetro que permite que la máquina se reinicié luego de sucedido un kernel panic:
panic=X
donde X es la cantidad de segundos a esperar antes de que el kernel reinicie la máquina como último mandato.
Referencias:
http://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html
http://kerneltrap.org/node/2450
Investigando en Internet, encontré y aprendí un poco como maneja Linux la memoria, resulta que el kernel separa un espacio de memoria directamente accesible, en la cual se va mapear la parte alta de la memoria.
Resulta que éste mapeo de la memoria tiene un costo de procesamiento, en el caso de la máquina de prueba el costo es demasiado alto, tal vez el kernel es un poco viejo, pero resulta que con el parámetro mem=896M al kernel se puede limitar la cantidad de memoria disponible, de ésta manera se trabaja sin el mapeo y el desempeño mejora, la verdad se podría intentar con un kernel más nuevo (el actual de la máquina es 2.6.18-128.2.16.v5 en CentOS 5.3) pero no vale el esfuerzo.
Resulta que buscando el valor mágico de 896M encontré que existe otro parámetro muy interesante cuando se trata de servidores Linux, de vez en cuando sucede un kernel panic, cuando esto sucede el kernel nos deja en la pantalla un mensaje del error, pero en mi caso particular me interesa que el servidor esté arriba la mayor parte del tiempo algunas veces no puedo desplazarme hasta donde está la máquina para ver el error y reiniciarla, hay un parámetro que permite que la máquina se reinicié luego de sucedido un kernel panic:
panic=X
donde X es la cantidad de segundos a esperar antes de que el kernel reinicie la máquina como último mandato.
Referencias:
http://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html
http://kerneltrap.org/node/2450
Subscribe to:
Posts (Atom)
