Escrito por coder el 28 de abril de 2005 en Informática | Hits: 1064
Hace unas dos semanas hablábamos zayer y yo de Gentoo orientada a servidores en producción. Yo me estaba cagando en la puta madre del mantenedor del ebuild de Apache porque me daba un bonito segfault y zayer dijo:
19:35 [coder] vas a fdlipar
19:35 [coder] con los cambios que han metido
19:35 [zayer] o_O
19:35 [coder] en baselayout y apache
19:35 [coder] su puta madre
19:35 [zayer] no se, pero han quitado el 2.4...
19:35 [zayer] la están cagando para los servidores
19:35 [zayer] pero mucho
Yo creo que precisamente todos los cambios que están haciendo son precisamente para orientar la distribución hacia servidores en producción. De hecho, salió un GLEP al respecto hace ya tiempo:
http://www.gentoo.org/proj/en/glep/glep-0019.html.
Desde mi punto de vista, las claves para Gentoo en servers son las siguientes:
- Keyword stable: En el GLEP19 se propuso la keyword 'stable:arch' para poder controlar la arquitectura empleada y si esta se deseaba usar en su rama estable, normal o ~ (inestable).
- Árbol de Portage: En el mismo GLEP se discute la necesidad de tener un árbol estable que de alguna manera sea una versión 'congelada' del árbol normal. Esto significa que, por ejemplo, un ebuild de postgres 7.3 seguirá en en árbol al menos durante un año entero. Eso es algo _básico_ en entornos de producción. Yo hasta ahora lo que hacía era usar el OVERLAY en /usr/local/portage y salvar todos los ebuilds susceptibles a desaparecer ahí dentro. Un poco guarro, sí, y gracias a los desarrolladores pronto dejaré de hacerlo.
- Profiles: Los profiles tienen un ciclo de vida de 3 meses. ¿Corto periodo de tiempo? Sí, pero en realidad es como en muchas otras distros. RedHat y Mandrake sacan releases cada 3-4 meses. Pues aquí igual. ¿Qué tiene esto que ver con un server en producción? Pues que por ejemplo, muchos se han rasgado las vestiduras al ver gentoo-dev-sources pasar a gentoo-sources y por tanto tener un 2.6 como kernel oficial. No pasa nada, profile 2005.0/2.4 y seguirán teniendo su serie 2.4 del kernel pero al mismo tiempo un profile actualizado y con soporte. Además, hay ciertas variables en el make.defaults de cada profile que no sólo ayudan a estabilizar el sistema sino también a que sea super adaptable on-the-fly. Veamos algunas:
- ARCH: especificamos la arquitectura a usar (ppc, sparc, x86, ...)
- USERLAND: curioso nombre el escogido para esta variable. Nos permite elegir entre los 'sistemas' en los que se ejecutará Portage: GNU, BSD, CygWin, ...
- PORTAGE_LIBC: Hace relativamente poco que se soportan librerías distintas a glibc, pero ya se puede. Ahora mismo se soportan, al menos, uClibc (para embebidos más que nada) y la libc de BSD.
- PROFILE_ARCH: Diferenciamos entre por ejemplo, sparc32 y sparc64 o similar.
- Integración de GPG: Desde que salió la FEATURE 'gpg' la metí en casa y en el trabajo. Todavía no funciona a nivel global, pero firmar el contenido del árbol de Portage proporciona bastante seguridad. En un escritorio no hace falta, pero en servers sí. En el caso de que alguien corrompa un mirror y meta código malicioso, no nos afectará.
- Glibc-NTPL: Con la llegada del 2.6 en navidades de 2003/2004, apareció el nuevo modelo de hilos basado en POSIX. Glibc lleva tiempo dándole soporte a este nuevo modelo, sin embargo, hace relativamente poco tiempo sacaron una nueva USE en Gentoo, nptlonly, que permite, si el admin lo desea, compilar glibc sólamente con este modelo de hilos y no con el clásico pthreads. Esto es bueno porque por defecto la glibc se compila dos veces, una con un modelo y otra con el otro, y se instalan ambas. Así, Gentoo se acomoda más al resto de distribuciones y no va tan al límite, permitiendo nuevamente al bofh que escoja. Hay aplicaciones que aún no se comportan bien con NPTL así que tener una copia de libc6 con el soporte antiguo viene de maravilla si lo necesitamos.
- Glsa-check: El script para comprobar si nuestro sistema está afectado por algún GLSA. Experimental pero funcional. Herramienta básica del admin gentooza.
- USEs hardened, pic, etc: Hace tiempo, cuando se inició el proyecto Hardened, el tema este iba un poco 'cutre'. Yo metía a pinrel -fstack-protector (después del follón con el símbolo __guard y toda aquella historia) en las CFLAGS. Sin embargo, con el tiempo eso se hizo transparente y basta con tener la USE hardened activada para que aplique esas protecciones. Otra USE que llevo tiempo useando (xD) es 'pic', que viene de Position Independent Code. Con esta randomizamos las direcciones base de los ejecutables y librerías y hacemos realmente difícil la predicción de símbolos de glibc clásicos como strcpy() o system() para que ejecutar exploits tipo return-into-libc sean mucho más difíciles de ejecutar con éxito.
- wrappers, *-config, etc: autoconf, binutils-config, gcc-config. Todos estos ebuilds han ido evolucionando de cara a ser usados de forma estable, segura y autónoma los unos de los otros. Antes, por ejemplo, autoconf metía en un sólo ebuild 3 o 4 versiones y eso era una locura, pero lo han arreglado. Recientemente han sacado binutils-config para seleccionar las utilidades base a usar (para linkar y demás).
Lo único pendiente que queda es el kernel, pero siempre se puede usar el de CentOS para tener soporte que los kernels de Gentoo/Debian/cualquiera non profit no pueden proveer.
« DHCP Watchdog (II)
Personaje: Matthew Broderick »