We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Compilar Kernel modular con grsecurity, QoS y más


Zento
12/09/2011, 10:31
Esto del cambio de kernel me está dando problemas con el RAID por software manejado por mdadm. Lo estoy haciendo en un Ubuntu Server 10.04 y he intentado varias soluciones: update-initramfs con el mdadm.conf modificado, actualizar el paquete mdadm a la versión 3.1...

¿Alguna idea?

sulvus
04/09/2011, 16:04
Cita Publicado inicialmente por albertdb
Lo máximo que ha llegado a registrar el RTM utilizando 100Mb/s de bajada y subida simultáneamente durante varios minutos ha sido esto:

Entrada : 74680.4 packet/s
Salida : 64923.8 packet/s

Podría ser problema del kernel, pero más bien creo que simplemente estás saturando la interfaz de red o el puerto del switch al que está conectado tu servidor. Piensa que para enviar 80000 paquetes por segundo en una conexión de 100Mb/s, estos deben ser como mucho de 0,00015625MB, o lo que es lo mismo, 163,84 bytes cada uno. Casi nada.

Salu2

Entonces el problema cual es?

Aquí le muestro una imagen actual
https://www.ovh.com:444/46.105.104/855572997682.png
https://www.ovh.com:444/46.105.104/625286258614.png

albertdb
04/09/2011, 10:55
Lo máximo que ha llegado a registrar el RTM utilizando 100Mb/s de bajada y subida simultáneamente durante varios minutos ha sido esto:

Entrada : 74680.4 packet/s
Salida : 64923.8 packet/s

Podría ser problema del kernel, pero más bien creo que simplemente estás saturando la interfaz de red o el puerto del switch al que está conectado tu servidor. Piensa que para enviar 80000 paquetes por segundo en una conexión de 100Mb/s, estos deben ser como mucho de 0,00015625MB, o lo que es lo mismo, 163,84 bytes cada uno. Casi nada.

Salu2

sulvus
04/09/2011, 04:14
Saludos,

Soy novato en el tema del kernel, pero me gustaria saber si el kernel tiene un límite de tráfico de packets o algo parecido, ya que tengo un emulador de un juego, que al llegar casi a los 80mil packetes, se queda en 79999 packet/s y empieza a perder packetes o al menos la respuesta aumenta considerablemente.

neojordan
03/08/2011, 11:41
Gracias, voy a ver si esa si que compila bien

albertdb
02/08/2011, 22:19
La versión 2.6.32 es la versión longterm elegida y mantenida por los principales fabricantes y el soporte hardware es el mismo (salvo tarjetas gráficas) que en la 2.6.38/2.6.39. Por eso los parches grsecurity calificados como estables son para esa versión. Si no tienes una razón de peso para utilizar las versiones más actuales, ve a lo seguro.

Salu2

neojordan
02/08/2011, 11:41
Yo tengo una duda. Si quiero poner el 2.6.38, qué version del grsecurity debo parchear? Es que no encuentro el archivo...

O si pongo la 2.6.39, la cual si tiene grsecurity (aunque test), qué archivo de configuración de ovh pongo? porque tienen hasta el 2.6.38...

albertdb
06/04/2011, 17:31
Cita Publicado inicialmente por simonbcn
Vale, es que yo no uso VirtualBox en el servidor (¿cual es la utilidad de instalar vbox en un servidor?)
Para casos como este: http://foros.ovh.es/showthread.php?t=8262

Salu2

simonbcn
19/01/2011, 19:45
Cita Publicado inicialmente por albertdb
Prueba a instalar VirtualBox o a añadir los módulos QoS con un kernel de OVH, por ejemplo .
Vale, es que yo no uso VirtualBox en el servidor (¿cual es la utilidad de instalar vbox en un servidor?) y los componentes QoS que recomiendas activar, como no especificas que hay que instalarlos como módulos, los he incluido en el propio kernel (me parece una tontería activar el soporte a módulos solo por estos dos).

¿Qué opináis sobre activar "TCP: advanced congestion control"? ¿No es aconsejable activar uno de los algoritmos de control de congestión en TCP?
Yo he activado Vegas, aunque me gustaría activar YeaH pero, no sé porqué, no me deja seleccionarlo. :confused:

albertdb
19/01/2011, 18:06
Cita Publicado inicialmente por simonbcn
Si no funciona, creo que es mucho más conveniente buscar la causa del problema.
La busqué y la solución que daban era esa o actualizar la versión (no recuerdo de qué).

Cita Publicado inicialmente por simonbcn
Vale, imaginemos que prescindimos del initramfs y que los módulos necesarios están integrados en el propio kernel: ¿hacer que el resto sean módulos no hace que el kernel sea más ligero, cuando se carga en memoria, ya que solo se cargarán los módulos que realmente son necesarios?
¿O es demasiado trabajoso determinar los módulos iniciales necesarios como para que compense?
Es más ligero, pero como dices es mucho trabajo para un beneficio del ¿1%?

Cita Publicado inicialmente por simonbcn
No entiendo qué sentido tiene activar el soporte a módulos en tu tutorial si no se usa.
Prueba a instalar VirtualBox o a añadir los módulos QoS con un kernel de OVH, por ejemplo .

Salu2

simonbcn
19/01/2011, 17:27
Cita Publicado inicialmente por albertdb
En teoría sí, pero precisamente lo añadí al ver que no había forma de que me instalara los módulos en cierta versión de Ubuntu o Debian que probé.
Si no funciona, creo que es mucho más conveniente buscar la causa del problema.
El "make modules_install" lo he ejecutado en los últimos kernels: 2.6.36, 2.6.36.2 y 2.6.37 (en Ubuntu 10.04) y funciona correctamente.

Cita Publicado inicialmente por albertdb
Modular es, cosa distinta es que quieras que todas las partes del kernel sean módulos. Y sí, has mutilado el kernel .
¿Cuales son las partes que no deberían ser módulos (a grosso modo)?

Cita Publicado inicialmente por albertdb
La pregunta es: ¿para qué quieres que todas las partes del kernel sean módulos si luego los quieres cargar igualmente (initramfs)?
Ok, ya te entiendo.

Cita Publicado inicialmente por albertdb
En los servidores de ahora no ocurre aquello de que hasta el último megabyte cuenta, así que yo me limitaría a dejar la configuración base tal como viene y lo que añadas tú como módulos.
Vale, imaginemos que prescindimos del initramfs y que los módulos necesarios están integrados en el propio kernel: ¿hacer que el resto sean módulos no hace que el kernel sea más ligero, cuando se carga en memoria, ya que solo se cargarán los módulos que realmente son necesarios?
¿O es demasiado trabajoso determinar los módulos iniciales necesarios como para que compense?

No entiendo qué sentido tiene activar el soporte a módulos en tu tutorial si no se usa.

Cita Publicado inicialmente por albertdb
Gracias, pero el parche milagroso ya lo he aplicado al kernel 2.6.37 y está funcionando sin problemas en mi servidor.
Además también he aprovechado para poner el procesador que me corresponde (Core 2) y algunas cosillas más.
Un saludo.

albertdb
19/01/2011, 16:13
Cita Publicado inicialmente por simonbcn
En el paso 10:
Código:
mkdir /lib/modules/`uname -r`
make modules_install
No es necesario el primer paso (el mkdir), el propio "make modules_install" ya crea el directorio correctamente para el linux que se está compilando.
En teoría sí, pero precisamente lo añadí al ver que no había forma de que me instalara los módulos en cierta versión de Ubuntu o Debian que probé.

Cita Publicado inicialmente por simonbcn
Además esto posibilita instalar los módulos antes de cargar el kernel (para, por ejemplo, el caso que se quiera hacer modular, cosa que estoy intentando sin éxito).
http://foros.ovh.es/showpost.php?p=45130&postcount=19

Cita Publicado inicialmente por simonbcn
He compilado el kernel 2.6.37 con el patch de Galbraith (SCHED_AUTOGROUP) y grsecurity sin problema usando la config base del kernel de OVH.
Pero no consigo hacerlo modular, quizás me he pasado porque prácticamente a todo lo que he podido lo he puesto como modulo (mi config)
Modular es, cosa distinta es que quieras que todas las partes del kernel sean módulos. Y sí, has mutilado el kernel .

Cita Publicado inicialmente por simonbcn
pero he hecho el paso que comenta ivanmh y, naturalmente, he instalado los módulos antes de reiniciar con este kernel. Pero no arranca, tampoco puedo ver el error porque cuando lo arranco con Kvm llega un momento, cuando está cargando el kernel, que se desconecta. ¿Alguna pista de lo que no debería poner como modulo? :confused:
La pregunta es: ¿para qué quieres que todas las partes del kernel sean módulos si luego los quieres cargar igualmente (initramfs)?

En los servidores de ahora no ocurre aquello de que hasta el último megabyte cuenta, así que yo me limitaría a dejar la configuración base tal como viene y lo que añadas tú como módulos.

PD: Respecto al parche milagroso: http://www.muylinux.com/2010/11/19/%...ear-el-kernel/

Salu2

simonbcn
19/01/2011, 13:43
En el paso 10:
Código:
mkdir /lib/modules/`uname -r`
make modules_install
No es necesario el primer paso (el mkdir), el propio "make modules_install" ya crea el directorio correctamente para el linux que se está compilando. Además esto posibilita instalar los módulos antes de cargar el kernel (para, por ejemplo, el caso que se quiera hacer modular, cosa que estoy intentando sin éxito).

También creo que es mejor instalar el kernel compilado con:
Código:
make install
Esto automaticamente copia el kernel compilado a /boot/, aunque con el nombre vmlinuz-n.n.n (hay que tenerlo en cuenta a la hora de editar el lilo.conf). Además también copia el System.map del kernel compilado y enlaza el de /boot/ con este nuevo. Y por último, pero no menos importante, crea un fichero con la configuración que hemos compilado ese kernel también en boot con el nombre de config-`uname -r`.

Más info en: FAQ/KernelCompilation
__________________________________________________

He compilado el kernel 2.6.37 con el patch de Galbraith (SCHED_AUTOGROUP) y grsecurity sin problema usando la config base del kernel de OVH.
Pero no consigo hacerlo modular, quizás me he pasado porque prácticamente a todo lo que he podido lo he puesto como modulo (mi config), pero he hecho el paso que comenta ivanmh y, naturalmente, he instalado los módulos antes de reiniciar con este kernel. Pero no arranca, tampoco puedo ver el error porque cuando lo arranco con Kvm llega un momento, cuando está cargando el kernel, que se desconecta. ¿Alguna pista de lo que no debería poner como modulo? :confused:

Yhoni1
19/12/2010, 22:26
Alberdb, gracias por el estupendo manual, aunque aún no me atrevo a recompilar un kernel reconozco que con este manual casi me tiro a la piscina, lo estudiaré para cuando me ponga manos a la obra.

Gracias mil por el aporte.

simonbcn
27/09/2010, 14:29
Muchas gracias por este manual, me ha ido de perlas para actualizar el kernel de mi Ubuntu y, de paso, aumentar la seguridad del mismo.
Un apunte, al poner grsecurity a High, habrá programas que no funcionen. Uno de ellos es "wine", para solucionarlo (en Ubuntu):
  1. Instalamos el programa paxctl
    Código:
    sudo aptitude install paxctl
  2. Cambiamos los binarios de wine
    Código:
    sudo paxctl -csmp /usr/bin/wine-preloader /usr/bin/wine

El paso 2 habrá que hacerlo cada vez que se actualice wine.

grafisoft
16/09/2010, 11:40
Ya tengo instalado un xp, el tema de la falta de hd para la maquina virtual creo que se podria resolver montando una carpeta compartida, nose hasta que punto sera esto eficaz, pero tratandose de carpetas compartidas dentro de la red de ovh que suele ir bien, puede servir de algo.

Gracias de nuevo a albertdb por la paciencia que ha tenido conmigo.

Saludos

grafisoft
15/09/2010, 23:16
Bien, ya parece que funciona, aqui volviendome loco y resulta que me colaba en dos mayusculas -.-

Gracias por toda la ayuda albertdb, te debo una

Saludos

albertdb
15/09/2010, 20:04
Está instalado correctamente. El problema es que intentas ejecutar la interfaz gráfica con el comando equivocado. Estos son los comandos disponibles (ojo con las mayúsculas):

root@mc-178-32-121-21:~# V
VBox VBoxHeadless VBoxManage VBoxSDL VBoxTunctl VBoxVRDP VirtualBox

Ejecuta el comando VirtualBox desde el escritorio remoto en el terminal.

Salu2

grafisoft
15/09/2010, 19:39
http://dl.dropbox.com/u/6147749/vbox.jpg

El log de instalacion, creo que hay varias instalaciones en el, creo que no me tira ningun error:
Código:
** Compiling vboxdrv
Attempting to install using DKMS

Creating symlink /var/lib/dkms/vboxdrv/3.2.8/source ->
                 /usr/src/vboxdrv-3.2.8

DKMS: add Completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=2.6.32-24-generic -C /lib/modules/2.6.32-24-generic/build M=/var/lib/dkms/vboxdrv/3.2.8/build.....................

Running the post_build script:
cleaning build area....

DKMS: build Completed.

vboxdrv.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.32-24-generic/updates/dkms/

depmod....

DKMS: install Completed.
** Compiling vboxnetflt
Attempting to install using DKMS

Creating symlink /var/lib/dkms/vboxnetflt/3.2.8/source ->
                 /usr/src/vboxnetflt-3.2.8

DKMS: add Completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Running the pre_build script:

Building module:
cleaning build area....
make KERNELRELEASE=2.6.32-24-generic -C /lib/modules/2.6.32-24-generic/build M=/var/lib/dkms/vboxnetflt/3.2.8/build......
cleaning build area....

DKMS: build Completed.

vboxnetflt.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.32-24-generic/updates/dkms/

depmod....

DKMS: install Completed.
** Compiling vboxnetadp
Attempting to install using DKMS

Creating symlink /var/lib/dkms/vboxnetadp/3.2.8/source ->
                 /usr/src/vboxnetadp-3.2.8

DKMS: add Completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Running the pre_build script:

Building module:
cleaning build area....
make KERNELRELEASE=2.6.32-24-generic -C /lib/modules/2.6.32-24-generic/build M=/var/lib/dkms/vboxnetadp/3.2.8/build.....
cleaning build area....

DKMS: build Completed.

vboxnetadp.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.32-24-generic/updates/dkms/

depmod....

DKMS: install Completed.

grafisoft
15/09/2010, 15:49
El escritorio lo tengo puesto, pero... nose si se me instala bien el virtualbox, luego vuelvo a instalarlo y te pongo una captura de la consola, por lo que se ve no se instala bien, y si intento instalarlo desde los repositorios, me dice que no encuentra el kernel.

El virtualbox este que no se si se instala correctamante, no me aparece en la interfaz grafica.

Podias probar tu de nuevo, con los clouds de ahora a ver si hay algo diferente?

Saludos

albertdb
15/09/2010, 01:26
Opción A) Aprende a usar el comando VBoxHeadless para crear y manejar las máquinas virtuales desde consola (tostón del 15, yo solo lo uso para arrancar la máquina y pararla).

Opción B) Instala una interfaz gráfica y crea la máquina virtual desde el escritorio remoto (recomendado).

Salu2

grafisoft
15/09/2010, 00:58
No logro llegar a buen puerto, he actualizado al kernel 2.6.32.24, luego he bajado de la web que me has indicado mas arriba el virtualbox 3.2, aparentemente se instala correctamente, no da ningun error, pero no esta, cuando pongo el comando virtualbox me dice que no existe.

No tengo ni idea de en que lugar meto la pata

grafisoft
15/09/2010, 00:14
Abro la interfaz grafica, busco la ultima version que salga ahi, y la instalo no? Voy a probar

albertdb
15/09/2010, 00:10
Desde interfaz gráfica de aptitude debería instalarte la última versión así... si no, instala la misma versión de los tres paquetes (preferiblemente la que tengas o la última).

Salu2

grafisoft
15/09/2010, 00:09
Supongo que a actualizar esos paquetes, te referiras a ejecutar los comandos:

aptitude install linux-headers-2.6

A esto te refieres?

Saludos

grafisoft
14/09/2010, 23:58
Me dice que tengo que elegir una version en concreto, pues me sale una lista con diferentes versiones.

Saludos

albertdb
14/09/2010, 23:27
Entra en el aptitude e instala/actualiza estos paquetes virtuales:

linux-headers-2.6
linux-image-2.6
linux-source-2.6

Salu2

grafisoft
14/09/2010, 23:11
Ando un poco perdido, los headers... si pongo uname -r me dice que tengo la version 2.6.32-22-generic

Al buscar los headers pues no encuentra, o no se cual elegir de los que salen. Lo del soucre supongo que te refieres al "apt-get install linux-source-la version de mi kernel"

Y lo de los headers pues igual que el anterior no?

Gracias por todo y perdona las molestias.
Saludos

albertdb
14/09/2010, 21:35
No instales VirtualBox de los repositorios de la distribución sino de http://www.virtualbox.org/wiki/Linux_Downloads

Instala headers y source del kernel antes.

Salu2

grafisoft
14/09/2010, 20:12
El del ubuntu 10.04 no lo pilla el virtualbox, me dice que no hay para ese kernel.

grafisoft
14/09/2010, 18:40
Estaba probando con debian 5 de 32 bits. Con el ubuntu no hace falta hacer lo de la guia? Paso directamente a instalar el virtualbox?

albertdb
14/09/2010, 17:05
Cita Publicado inicialmente por grafisoft
Esto funciona seguro en los clouds??? Porque a mi de momento no me va, cuando tengo que reiniciar, ya no puedo conectarme por ssh, voy a probar por ultima vez pero sin mucho convencimiento.
En su momento lo hice con un miniCloud beta de los que venían con Debian Lenny 64-bit y funcionó a la primera.

A menos que hayan cambiado la plantilla de Ubuntu Server 10.04, el kernel que trae es el de la distribución, es decir, modular, no hace falta compilarlo.

Salu2

grafisoft
14/09/2010, 16:46
Esto funciona seguro en los clouds??? Porque a mi de momento no me va, cuando tengo que reiniciar, ya no puedo conectarme por ssh, voy a probar por ultima vez pero sin mucho convencimiento.

Saludos

albertdb
29/07/2010, 12:34
Cita Publicado inicialmente por ivanmh
Creo que te falta initramfs para poder cargar los módulos al arranque.

En los kernels de OVH no hace falta porque no está habilitada la opción de cargar módulos, pero si lo activas al compilar un nuevo kernel, puede que los necesites al arrancar el servidor y se lo debes indicar a GRUB o LILO.
El uso de un initramfs es única y exclusivamente necesario en el caso de que se compilen partes vitales del kernel necesarias para el arranque (drivers de controladoras de disco, etc.) como módulos de éste, en vez de hacerlo de forma estática.

Partiendo, como partimos, de la configuración base de OVH, en la que el kernel resultante no es modular (no admite, por tanto, initramfs), es lógico pensar que todo lo necesario para arrancar viene integrado en el kernel, ya que en la guía no quitamos componentes, sólo los añadimos y de forma estática, por cierto.

El kernel seguirá cargando módulos cuando los necesite, sin problemas.

En definitiva, no es necesario usar ni configurar un initramfs en este caso. Me atrevería incluso a decir, sin miedo a equivocarme, que sería perder el tiempo.

Salu2

ivanmh
29/07/2010, 10:29
Cita Publicado inicialmente por albertdb
Me faltaba un paso del final que acabo de añadir (nº 11). Aunque no imprescindible, se recomienda seguirlo.

EDITO: El nº 10 del final estaba incompleto. Corregido. Este paso es imprescindible para poder instalar módulos.

Salu2
Creo que te falta initramfs para poder cargar los módulos al arranque.

En los kernels de OVH no hace falta porque no está habilitada la opción de cargar módulos, pero si lo activas al compilar un nuevo kernel, puede que los necesites al arrancar el servidor y se lo debes indicar a GRUB o LILO.

Código:
mkinitramfs -o /boot/initrd.img-2.6.32.16-xxxx-grs-ipv4-64 /lib/modules/2.6.32.16-xxxx-grs-ipv4-64

Y editar LILO con añadiendo o editando la linea initrd:

Código:
image = /boot/bzImage-2.6.32.16-xxxx-grs-ipv4-64
        initrd = /boot/initrd-img-2.6.32.16-xxxx-grs-ipv4-64
        label = "Linux"
        root = /dev/md1
        read-only
En un servidor de OVH no lo he probado porque tengo la carga de módulos deshabilitada, pero en un ordenador local que tengo, si me olvido de initrd, se produce un kernel panic nada más arrancar GRUB.

KhalidBasiyd
28/07/2010, 20:15
Hola,

Si uso centos, estoy probando en un miniCloud.

Saludos.

albertdb
28/07/2010, 20:09
Cita Publicado inicialmente por KhalidBasiyd
Sigue el tutorial pero al llegar al commando "maker" me da un error
Veo que estás utilizando un miniCloud para compilar el kernel. Qué distribución usas? En Debian y Ubuntu debería compilar sin problemas. Si estás usando CentOS, siento no poder ayudarte. Cuando salieron los miniClouds estuve probandola y no conseguí instalar ni un solo paquete del repositorio (nunca encontraba nada en la base de datos). Me sentí tan inutil que la borré al día siguiente. Donde esté la comodidad de aptitude... (expertos en CentOS, podéis echarme a la hoguera, o hacer una guía que explique como usar y configurar yum para usuarios de Debian y derivados; aunque prefiero lo segundo ).

Salu2

KhalidBasiyd
28/07/2010, 19:41
Hola,

Sigue el tutorial pero al llegar al commando "maker" me da un error

[root@mc-178-32-111-12 linux-2.6.32.16]# make
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86/Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/linux/utsrelease.h
UPD include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-x86
/usr/src/linux-2.6.32.16/arch/x86/Makefile:200: ***
*** 2.6 PaX kernels no longer build correctly with old versions of binutils.
*** Please upgrade your binutils to 2.18 or newer. Stop.
Salu2.

albertdb
27/07/2010, 22:08
Me faltaba un paso del final que acabo de añadir (nº 11). Aunque no imprescindible, se recomienda seguirlo.

EDITO: El nº 10 del final estaba incompleto. Corregido. Este paso es imprescindible para poder instalar módulos.

Salu2

albertdb
26/07/2010, 16:20
Cita Publicado inicialmente por ivanmh
La imposibilidad de cargar módulos es una ventaja de seguridad, ya que dificulta a alguien que haya entrado como root, meter un troyano o rootkit como módulo en el mismo kernel. De hecho creo que sería imposible sin reiniciar el ordenador.
No lo había pensado, pero tienes razón. Aún así, desde el momento en el que alguien no autorizado entra como root, tienes un problema.

Si quieres impedir que se instalen nuevos módulos, lo que se me ocurre es tener una partición dedicada para /lib/modules/ y montarla por defecto como solo lectura. Cuando se requiera escribir, se remonta en caliente como escribible y cuando acabas, la dejas como solo lectura. No lo he probado pero debería funcionar.

Cita Publicado inicialmente por ivanmh
Es exactamente igual como lo ha explicado albertdb, pero cambiando el paso 7.-
Hay que cambiar más cosas. He actualizado la guía con los pasos específicos para SO de 64-bit .

Salu2

juanillo
26/07/2010, 12:43
¡ Gracias ivanmh ! ... ahora me atrevo a probar sin miedo a romper algo ... jeje ...

ivanmh
26/07/2010, 11:20
Cita Publicado inicialmente por juanillo
,,, ¿ algun alma caritativa que los compile en 64 bits nos podria dejar la chuleta ? ...
Es exactamente igual como lo ha explicado albertdb, pero cambiando el paso 7.-

Código:
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-64

mv 2.6-config-xxxx-std-ipv4-64 .config
Y antes de compilar, en make menuconfig, te vas a Processor type and features -> Processor family (Generic x86-64) -> y especificar el procesador (en mi caso es Core 2/newer Xeon)

juanillo
26/07/2010, 10:52
Guau albertdb !! ... muchisimas gracias. Ahora tengo algo más en lo que trastear y aprender

,,, ¿ algun alma caritativa que los compile en 64 bits nos podria dejar la chuleta ? ...

Gracias !!

ivanmh
26/07/2010, 09:21
Cita Publicado inicialmente por Power
Hola,

Como he comentado antes, soy un pardillo integral en estos temas.
Supongo (aunque es posible que me equivoque) que la ventaja de tener kernel y módulos separados será que si no se necesitan no se cargan y se ahorran recursos.
Y la ventaja de tener kernel monolítico es poder olvidarse de módulos y similares.
¿Es así o hay alguna otra ventaja?
La imposibilidad de cargar módulos es una ventaja de seguridad, ya que dificulta a alguien que haya entrado como root, meter un troyano o rootkit como módulo en el mismo kernel. De hecho creo que sería imposible sin reiniciar el ordenador.

Para el ordenador de casa, es una molestia no poder cargar módulos, pero para un servidor en producción puede ser interesante por el pequeño plus de seguridad que aporta.

albertdb
25/07/2010, 22:03
Cita Publicado inicialmente por Power
Hola,

Como he comentado antes, soy un pardillo integral en estos temas.
Supongo (aunque es posible que me equivoque) que la ventaja de tener kernel y módulos separados será que si no se necesitan no se cargan y se ahorran recursos.
Y la ventaja de tener kernel monolítico es poder olvidarse de módulos y similares.
¿Es así o hay alguna otra ventaja?
Gracias de nuevo.

Saludos
En los kernels modulares, tienes el kernel con todo lo que le hayas integrado al compilarlo y por otra parte puedes cargar módulos externos para extender las funcionalidades del mismo. Si no instalas ningún módulo, se comporta igual que uno monolítico.

En los kernels monolíticos, tienes el kernel con todo lo que le hayas integrado al compilarlo pero si quieres añadir alguna función a posteriori o instalar algún programa que requiera instalar un módulo propio, o recompilas o, por decirlo mal y claro, te jodes.

Respecto al ahorro de recursos, en la época en que se empezó a desarrollar el núcleo del kernel podía tener sentido el hacerse un kernel monolítico adaptado a las necesidades de uno mismo pero en pleno siglo XXI resulta, cuanto menos, absurdo, puesto que lo que ganas y nada es, a efectos prácticos, lo mismo. De ahí que maldiga a la cabeza pensante de OVH que se le ocurrió la genial idea de hacer monolíticos los kernels propios.

Salu2

Power
25/07/2010, 20:13
Cita Publicado inicialmente por albertdb
Así es. Con la configuración que proporciona OVH, que es la que utilizamos como base, esa opción viene desactivada. Desde luego que al que se le ocurrió esa idea es para darle un par de capones bien dados .

Salu2
Hola,

Como he comentado antes, soy un pardillo integral en estos temas.
Supongo (aunque es posible que me equivoque) que la ventaja de tener kernel y módulos separados será que si no se necesitan no se cargan y se ahorran recursos.
Y la ventaja de tener kernel monolítico es poder olvidarse de módulos y similares.
¿Es así o hay alguna otra ventaja?
Gracias de nuevo.

Saludos

albertdb
25/07/2010, 19:28
Cita Publicado inicialmente por Power
Hola,

Muchísimas gracias por este maravilloso tutorial, Albertdb.

Sólo alguna duda de pardillo total:
Siempre he leído que los kernels de OVH eran monolíticos y no cargaban módulos.
Por eso mi pregunta es: ¿la opción "Enable loadable module support"? se salta esa peculiaridad de los kernel OVH?

Saludos
Así es. Con la configuración que proporciona OVH, que es la que utilizamos como base, esa opción viene desactivada. Desde luego que al que se le ocurrió esa idea es para darle un par de capones bien dados .

Salu2

Power
25/07/2010, 19:00
Hola,

Muchísimas gracias por este maravilloso tutorial, Albertdb.

Sólo alguna duda de pardillo total:
Siempre he leído que los kernels de OVH eran monolíticos y no cargaban módulos.
Por eso mi pregunta es: ¿la opción "Enable loadable module support"? se salta esa peculiaridad de los kernel OVH?

Saludos

lonas
25/07/2010, 16:39
Gracias Makina!!!! esto en mi pueblo se llama APORTAZO jejejje

Saludos

albertdb
25/07/2010, 13:01
En principio esto es todo. Si viérais algun error o que falta algo (escribo de memoria), lo decís.

Salu2

albertdb
25/07/2010, 12:59
Continuación
  1. Ya sólo nos queda configurar las opciones del parche grsecurity.
    Para ello, entramos en el menú Security options:
    http://i28.tinypic.com/1jkw2w.jpg
    y dentro de éste en el submenú Grsecurity:
    http://i25.tinypic.com/w9u2rm.jpg
    Una vez dentro, activamos Grsecurity:
    http://i28.tinypic.com/2u8ch1w.jpg
    Entre las nuevas opciones que aparecerán, nos situamos en Security Level y pulsamos Enter:
    http://i25.tinypic.com/2m7dwz5.jpg
    En la ventana de selección, nos situamos sobre High y presionamos la barra espaciadora:
    http://i26.tinypic.com/28vf1ue.jpg
    Por último, volvemos al menú principal (pulsando en dos ocasiones, dos veces Esc).

  2. Finalmente, salimos de la herramienta de configuración (pulsando dos veces Esc), seleccionando Yes cuando nos pregunte si queremos guardar la nueva configuración:
    http://i25.tinypic.com/6ibb7q.jpg

  3. Compilamos el kernel:
    Recomendación: Esto tarda, así que es mejor hacerlo antes de irse a comer, cenar o dormir para no estar perdiendo el tiempo viendo pasar centenares o miles de líneas de texto a velocidad de vértigo .
    Código:
    make
    Si nuestra conexión falla más que una escopeta de feria, puede cortarse la conexión SSH en medio de la compilación, en cuyo caso deberemos volver a empezar. Para evitar esto, es recomendable utilizar el comando nohup:
    Código:
    nohup make &
  4. Copiamos el kernel compilado a /boot
    Código:
    cp arch/x86/boot/bzImage /boot/bzImage-2.6.32.57-xxxx-grs-ipv4-32
    64-bit:
    Código:
    cp arch/x86_64/boot/bzImage /boot/bzImage-2.6.32.57-xxxx-grs-ipv4-64
  5. Editamos la configuración del gestor de arranque (LILO):
    Código:
    nano /etc/lilo.conf
    donde debemos cambiar la línea que indica la ruta en la que se encuentra la imagen del kernel, dejándola tal que así:
    Código:
    image=/boot/bzImage-2.6.32.57-xxxx-grs-ipv4-32
    64-bit:
    Código:
    image=/boot/bzImage-2.6.32.57-xxxx-grs-ipv4-64
    Ctrl + O
    Intro
    Ctrl + X

  6. Reinstalamos LILO en el sector de arranque para aplicar la nueva configuración:
    Código:
    /sbin/lilo
  7. Reiniciamos:
    Código:
    shutdown -r now
  8. Una vez hayamos comprobado que funciona todo correctamente con el nuevo kernel, volvemos al directorio en el que estábamos:
    Código:
    cd /usr/src/linux-2.6.32.57
  9. Instalamos los headers, necesarios para compilar nuevos módulos:
    Código:
    make headers_install
  10. Creamos el directorio de módulos específico para el nuevo kernel instalado:
    Código:
    mkdir /lib/modules/`uname -r`
    make modules_install
    64-bit:
    Código:
    mkdir /lib64/modules/`uname -r`
    make modules_install
  11. Copiamos el System.map generado durante la compilación:
    Código:
    cp System.map /boot/System.map-2.6.32.57-xxxx-grs-ipv4
    rm -f /boot/System.map
    ln -s /boot/System.map-2.6.32.57-xxxx-grs-ipv4 /boot/System.map
  12. (opcional) Algunos programas no se conforman con tener los headers para compilar sus módulos, tal es el caso de VirtualBox, por lo que tendremos que crear una variable de entorno que almacene la ruta donde se encuentran las fuentes del kernel:
    Código:
    export KERN_DIR=/usr/src/linux-2.6.32.57
    echo "export KERN_DIR=/usr/src/linux-2.6.32.57" >> $HOME/.profile
  13. Fin.

Duato

albertdb
25/07/2010, 01:29
La siguiente guía se ha basado parcialmente en la anteriormente realizada por Miguel Ángel García y publicada en su blog personal (http://www.itimag.com). Mismo concepto, diferentes contenidos y, por tanto, distinta licencia.

En el caso particular de esta guía, todos los comandos aquí mostrados han sido comprobados bajo un entorno de 32-bit. Se incluyen los pasos específicos para SO de 64-bit (algunas rutas y nombres de archivo varían ligeramente) pero no han sido comprobados personalmente, tenlo en cuenta.

  1. Cambiamos al directorio /usr/src :
    Código:
    cd /usr/src
  2. Descargamos último kernel disponible desde http://www.kernel.org/ y su correspondiente parche grsecurity desde http://www.grsecurity.net/download.php:
    Código:
    wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/linux-2.6.32.57.tar.bz2
    wget http://grsecurity.net/stable/grsecurity-2.2.2-2.6.32.57-201202131842.patch
  3. Descomprimimos el kernel:
    Código:
    tar -xjf linux-2.6.32.57.tar.bz2
  4. Cambiamos al directorio que contiene el kernel:
    Código:
    cd linux-2.6.32.57
  5. Aplicamos el parche grsecurity al kernel:
    Código:
    patch -p1 < ../grsecurity-2.2.2-2.6.32.57-201202131842.patch
  6. Hacemos una limpieza total del árbol del kernel y comenzamos una compilación en limpio:
    Código:
    make mrproper
  7. Descargamos el archivo de configuración específico que proporciona OVH desde ftp://ftp.ovh.net/made-in-ovh/bzImage/:
    Código:
    wget ftp://ftp.ovh.net/made-in-ovh/bzImage/old/2.6-config-xxxx-std-ipv4-32
    64-bit:
    Código:
    wget ftp://ftp.ovh.net/made-in-ovh/bzImage/old/2.6-config-xxxx-std-ipv4-64
    y lo renombramos:
    Código:
    mv 2.6-config-xxxx-std-ipv4-32 .config
    64-bit:
    Código:
    mv 2.6-config-xxxx-std-ipv4-64 .config
  8. Abrimos el menú de configuración gráfico, donde seleccionaremos las opciones con las que compilaremos el kernel:
    Código:
    make menuconfig
    http://i29.tinypic.com/xd8p3k.jpg

  9. Activamos (pulsando Y sobre la opción) Enable loadable module support y seguidamente presionamos Enter:
    http://i29.tinypic.com/10igml1.jpg
    En el nuevo menú que nos aparecerá, activaremos Module unloading y Forced module unloading:
    http://i25.tinypic.com/8wjcz6.jpg
    Por último, volvemos al menú anterior (pulsando dos veces Esc).

  10. Ahora, activaremos el soporte para QoS, muy útil para garantizar y/o limitar el ancho de banda a ciertos usuarios.
    Recomendación: Sigue los pasos aunque no tengas pensado utilizar este sistema.
    Entramos en el menú Networking support:
    http://i28.tinypic.com/34gm68j.jpg
    y dentro de éste en el submenú Networking options:
    http://i26.tinypic.com/2rcpgk9.jpg
    Bajamos hasta que encontramos la opción QoS and/or fair queueing, la activamos si no lo está y pulsamos Enter:
    http://i25.tinypic.com/344bbjm.jpg
    Una vez dentro, activamos Hierarchical Token Bucket (HTB):
    http://i31.tinypic.com/2vaawko.jpg
    y Netfilter mark (FW), que se encuentra casi al final:
    http://i29.tinypic.com/2jbmw5x.jpg
    Por último, volvemos al menú principal (pulsando en tres ocasiones, dos veces Esc).