[OT] Gentoo en produccion (encuesta)

[ackward]

Al hilo de Solo apache 2.2.x en portage? desde cuándo y razón de qué? me ha parecido mejor abrir un tema propio que seguir secuestrando al apache 2.2.

Voy a empezar con las premisas, para intentar concretar y que todos entendamos que es produccion y que significa.

1) Administrar un servidor de produccion no es tener la cuenta de root (igual que un "rm -rf /" tampoco lo es).
Mas que administracion nos dedicamos a "analisis y control de riesgos", mi aplicacion mas critica no es el ssh, es el project ( openproj.org ). Existen usuarios, programadores, aplicaciones, entornos, maquinas... y ademas seguridad, acceso, disponibilidad, rendimiento, redundancia, backups... el trabajo es que el circo de tres pistas parezca funcionar solo siempre pase lo que pase.

2) Dar soporte a Produccion no es un unico entorno, es asegurar el flujo: desarrollo->integracion->aceptacion/fixes->preproduccion->produccion.
No se puede hacer un cambio en produccion sin haberlo probado antes y sin comprobar que tus aplicaciones van a seguir funcionando. Esto se aplica a parches (maquinas que dejan de arrancar o servicios que dejan de funcionar), nuevas versiones, etc... (imagina actualizar el modulo pam y quedarte sin acceso kerberos... tendras un acceso de backup y otro de backup del backup, ya he dicho que nos dedicamos al control de riesgos, pero hazlo en produccion y los usuarios y los SLAs acaban contigo )

3) SLAs, acronimo de "service level agreement". Es a lo que te comprometes, es la forma de medir tu trabajo. Si todo funciona perfectamente para que estas no? (seguro que esa pregunta la habeis oido infinidad de veces), la respuesta son los informes de incidencias y como se refleja en los SLAs.

Un gran libro para empezar a comprender lo que es la administracion de sistemas es The Practice of System and Network Administration

Una vez conocido el marco de trabajo porque gentoo no es optimo como plataforma de produccion?

1) Seguridad
* Los compiladores estan prohibidos en maquinas de produccion (no cuela en las auditorias), una gentoo sin compilador es tan... antinatura? Puedes tirar de paquetes binarios y quizas hacer malabarismos con el portage... y el riesgo, y el tiempo?

2) Soporte
* Tu tiempo es oro y desde luego mas cuando ocurre una incidencia y tienes que estar pendiente de mil cosas a la vez :recuperar cintas, validarlas, tranquilizar usuarios, activar la contigencia, recuperar el sistema actual... Si hay un problema con el oracle mejor que venga el tecnico y lo arregle que estar de hombre orquesta porque ya estas ocupado coordinandolo todo. Y no puedes contratar un servicio cuando la plataforma no esta homologada. Asi que volvemos al riesgo, y no recibir soporte es un gran riesgo, tanto como que me echarian a la calle si me quedo con el culo al aire (sobretodo cuando cualquier parada no controlada cuesta mas que tu sueldo).
* Standarizacion, para evitar problemas tienes que instalar en x86 asi que gentoo pierde la velocidad de poder hacerlo en 64 bits. ¿por que? por el soporte de aplicaciones extra como plugins de backup o monitorizacion propietarios, No soportan gentoo y hay que currarse el que funcionen.A veces es imposible o complicado si las librerias son incompatibles... dan problemas y no estas para problemas, controlas el multilib y las librerias de emulacion y? que hago yo a tan bajo nivel arreglando los problemas de un proveedor que no me da soporte y se limpia las manos?. El problema de ahora arreglado de forma chapucera es una bomba de relojeria futura en una actualizacion posterior.

3) Actualizaciones
Si hay gente programando en cobol o rpg y no va a morir a corto plazo os deberia bastar para comprender la dificultad de actualizar ciertos programas. Sobretodo si hay un desarrollo interno fuerte con bajo mantenimiento (pj muchos nuevos productos/servicios cada mes pero poco tiempo o imposible para empezar de cero, como pueden ser servicios bancarios)
Asi que los entornos deben ser lo mas estables posibles, actualizaciones de apache 2.0 a 2.2 pueden ser triviales pero de php4 a php5 no (y encima de la mesa tengo aplicaciones para evaluar que solo funcionan en php4... y no esta en mi mano rechazarlas... de nuevo control de riesgos) o mysql... openldap es problematico, cambia de formato de bbdd y haz una migracion de usuarios de un software que se encarga de centralizarlos... riesgo
La cuestion es que no estas solo, debes empezar por desarrollo/integracion... avisar a los grupos de desarrollo a sus usuarios, que lo prueben todo, asegurarse que todo funciona para finalmente poder subirlo a produccion. Si una aplicacion no funciona en produccion es como si fuera una caida, si desarrollo se ha colado bien pero si vas de llanero solitario y la cuelas tu...
Ni que decir que a los desarrolladores les encantan estos temas, que les trastoques su planificacion metiendo una nueva variable que les exija revisar todo... encantados del nuevo curro y de explicar a sus usuarios porque deben mover las fechas (y no suele ser posible cuando se ha planificado una demostracion para el dia X y van retrasados o marketing ya tiene la campaña en television pactada)

4) Tiempo
Es la suma de todo, gentoo exige tiempo y dedicacion. Sincronizar cada poco, tenerlo al dia, no permitir demasiados saltos... suficiente hay en el dia a dia con incidencias, nuevos requisitos, proyectos, asegurarse que se hacen los backups, pruebas de contingencia, rendimiento, capacity plannings. Gentoo puede ser el mejor, mas rapido, menor tamaño... a un coste demasiado alto, tengo el mejor desktop en casa y desde hace 4 años... pero en casa.

Añadir mas gente para mantener los sistemas es una solucion (aunque incrementa la complejidad de la seguridad, la coordinacion... y las empresas son mas reacias a contratar personal que a gastar en licencias) y por supuesto no arregla la raiz del problema.

Quiza hablo de empresas demasiado monoliticas o poco flexibles (vale, pero trabajo de informatico en una empresa no informatica, todos los que esteis en sector servicios/consultoria sabreis de que hablo).Startups? salvo que la ventaja de personalizar tanto sea tu ventaja competitiva (pj googleplex) incluso en una startup con gente motivada, compensa al administrador utilizar una distro mas estable o conservadora (tendras tiempo para dedicarte a lo importante en vez de a mantener al dia el sistema).

[i92guboj]

1) Seguridad
* Los compiladores estan prohibidos en maquinas de produccion (no cuela en las auditorias), una gentoo sin compilador es tan... antinatura? Puedes tirar de paquetes binarios y quizas hacer malabarismos con el portage... y el riesgo, y el tiempo?

Los compiladores no se permiten en entornos de producción porque son un factor de riesgo más por varias razones. No me voy a parar a enumerarlas porque no creo que sea relevante para el hilo. Sin embargo, no veo el por qué esto es algo a tener en cuenta en este caso.

Como tú mismo muy bien dices: no se vuelca un update en un servidor de producción sin antes haber hecho varios tests que aseguren la integridad del sistema tras la operación. Ésto en Gentoo viene a ser lo mismo que decir que no vas a instalar algo en tu servidor de producción sin antes haberlo probado en un sistema Gentoo idéntico, que a su vez es lo mismo que decir que no vas a instalar algo en tu servidor sin antes haberlo compilado en otro lugar.

Es perfectamente recomendable que no quieras tener un compilador en tu servidor y también lo es que no quieras sobrecargar el servidor con operaciones pesadas como la compilación. Pero Gentoo no fuerza esa opción, es tan sencillo como montar un binhost. Como los paquetes ya están precompilados porque los has testeado antes, no entiendo cual es el problema.

http://gentoo-wiki.com/index.php?title= ... OST_server

2) Soporte
* Tu tiempo es oro y desde luego mas cuando ocurre una incidencia y tienes que estar pendiente de mil cosas a la vez :recuperar cintas, validarlas, tranquilizar usuarios, activar la contigencia, recuperar el sistema actual... Si hay un problema con el oracle mejor que venga el tecnico y lo arregle que estar de hombre orquesta porque ya estas ocupado coordinandolo todo. Y no puedes contratar un servicio cuando la plataforma no esta homologada. Asi que volvemos al riesgo, y no recibir soporte es un gran riesgo, tanto como que me echarian a la calle si me quedo con el culo al aire (sobretodo cuando cualquier parada no controlada cuesta mas que tu sueldo).

Cierto. Lo importante es evaluar qué es mejor para tí en un entorno determinado. Sin embargo, eso no le quita capacidad a Gentoo para servir de servidor. Tan solo demuestra que es inadecuado para tu problema concreto. Sin embargo, no entiendo que tiene que ver Oracle con que uses Gentoo o Red Hat... El funcionamiento de Oracle va a ser el mismo uses lo que uses como SO.

Cada técnico tiene sus cosas de las que preocuparse, y cuando se habla de software libre, hay montones de herramientas disponibles. Es por ello que podemos elegir la que mejor convenga a nuestras capacidades y al problema concreto con el que nos encontramos. No hay herramienta alguna que sea la solución universal a todos los problemas, ni para todos los usuarios o técnicos.

* Standarizacion, para evitar problemas tienes que instalar en x86 asi que gentoo pierde la velocidad de poder hacerlo en 64 bits. ¿por que? por el soporte de aplicaciones extra como plugins de backup o monitorizacion propietarios, No soportan gentoo y hay que currarse el que funcionen.A veces es imposible o complicado si las librerias son incompatibles... dan problemas y no estas para problemas, controlas el multilib y las librerias de emulacion y? que hago yo a tan bajo nivel arreglando los problemas de un proveedor que no me da soporte y se limpia las manos?. El problema de ahora arreglado de forma chapucera es una bomba de relojeria futura en una actualizacion posterior.

Ni idea de a qué te refieres. Si el problema es de 64 bits, lo vas a tener en todas las distros, no es nada que concierna específicamente a Gentoo. Si es por plugins, dudo mucho que sea algo que vaya a afectar a un servidor de producción serio. Pero como ya digo, cada uno tiene sus problemas específicos y escoge sus herramientas.

3) Actualizaciones
Si hay gente programando en cobol o rpg y no va a morir a corto plazo os deberia bastar para comprender la dificultad de actualizar ciertos programas. Sobretodo si hay un desarrollo interno fuerte con bajo mantenimiento (pj muchos nuevos productos/servicios cada mes pero poco tiempo o imposible para empezar de cero, como pueden ser servicios bancarios)
Asi que los entornos deben ser lo mas estables posibles, actualizaciones de apache 2.0 a 2.2 pueden ser triviales pero de php4 a php5 no (y encima de la mesa tengo aplicaciones para evaluar que solo funcionan en php4... y no esta en mi mano rechazarlas... de nuevo control de riesgos) o mysql... openldap es problematico, cambia de formato de bbdd y haz una migracion de usuarios de un software que se encarga de centralizarlos... riesgo
La cuestion es que no estas solo, debes empezar por desarrollo/integracion... avisar a los grupos de desarrollo a sus usuarios, que lo prueben todo, asegurarse que todo funciona para finalmente poder subirlo a produccion. Si una aplicacion no funciona en produccion es como si fuera una caida, si desarrollo se ha colado bien pero si vas de llanero solitario y la cuelas tu...
Ni que decir que a los desarrolladores les encantan estos temas, que les trastoques su planificacion metiendo una nueva variable que les exija revisar todo... encantados del nuevo curro y de explicar a sus usuarios porque deben mover las fechas (y no suele ser posible cuando se ha planificado una demostracion para el dia X y van retrasados o marketing ya tiene la campaña en television pactada)

Es cierto que Gentoo quizás no hace las cosas de la forma más adecuada para facilitarnos la tarea. Pero como dijiste más arriba, es responsabilidad de uno mismo comprobar que todo está bien antes de volcar el update a un servidor de producción.

4) Tiempo
Es la suma de todo, gentoo exige tiempo y dedicacion. Sincronizar cada poco, tenerlo al dia, no permitir demasiados saltos... suficiente hay en el dia a dia con incidencias, nuevos requisitos, proyectos, asegurarse que se hacen los backups, pruebas de contingencia, rendimiento, capacity plannings. Gentoo puede ser el mejor, mas rapido, menor tamaño... a un coste demasiado alto, tengo el mejor desktop en casa y desde hace 4 años... pero en casa.

Completamente de acuerdo. Dependiendo del tipo de servidor quizás no sea lo más adecuado. Pero si tienes pocas aplicaciones en un servidor, entonces es al revés. En Gentoo puedes customizar un paquete, añadir parches, quitar funcionalidades y librerías con las USE de forma muy sencilla. Todo esto quita vulnerabilidades de raíz, reduciendo el tamaño del código fuente al que se enlaza, lo cual es óptimo para un servidor en el que cada línea de código añadida es una posible vulnerabilidad nueva en tu sistema. Como ves, todo depende de como se mire

La ventaja de la personalización es que tienes un mayor control, y que el tamaño de las piezas a las que prestar atención es más fácil de acotar. Si, gentoo quizás no tenga el mejor sistema de cara al público, pero si eres tú el que está al tanto de las cosas, Gentoo es la herramienta perfecta para mantener tu código limpio y ordenado, con un tamaño mucho menor y con menos cosas de las que estar atento. Si quieres automatización quizás no sea lo tuyo, en ese caso mejor buscar algo que tenga soporte para empresas y pagarlo, todo depende del trabajo que quieras (o puedas) hacer tú mismo.

En definitiva, que no se trata de que Gentoo sea un producto que valga o nó, sino que se trata de que hay que estudiar cada caso, y escoger sabiamente las herramientas que más nos convengan, sea cual sea la razón que nos lleve a ello.

[Inodoro_Pereyra]

Ya que sale el tema seguridad, otro punto mas a favor de Gentoo es la posibilidad de instalar Hardened.

Yo iría por Gentoo para mis servidores a pesar de jugarme la cabeza con la decisión y por mas grande que sea la infraestructura a servir.

Ahora que lo pienso, si la distribución que elegiste para tu servidor es Gentoo, es mucho mas probable que conserves tu puesto en caso de downtime, nadie mas que vos sabrá como y por que funciona todo y llevará mas tiempo buscar a alguien que entienda el sistema que traerte de las orejas a que pongas todo a funcionar nuevamente, no?

Gente capacitada para administrar sistemas Linux, al menos de este lado del charco, escasean.

Salud!

[Acron_0248]

Hola,

Desde mi punto de vista, ackward tiene varios puntos interesantes y a ser tomados en cuentas, de igual manera i92guboj e Inodoro_Pereyra, una de las primeras cosas que me llamó la atención es el tema del control de riesgos y cómo ha sido expuesto por desde uno u otro punto de vista.

Yo en lo particular, no vería adecuado hacer de este tema una encuesta, y la razón es que la encuesta solo da dos posibles respuestas, 'si' y 'no' cuando la respuesta real a la temática es "si y no", como puede que no se me entienda mucho, me explicaré...

La respuesta a tener gentoo en un servidor en producción o no depende enteramente de la infraestructura de trabajo, el uso final que tendrá un servidor en particular, obviamente, gentoo no se adaptará a todas, tampoco lo hará red hat, debian o cualquier similar. Haciendo alución a lo que dijo i92guboj, es un tema que se puede mirar desde varias ópticas y obtener resultados antagónicos en base a las mismas.

Volviendo al tema de control de riesgos, creo que si es por tal cosa, gentoo tiene mucho que aportar, como se ha dicho, puedes evitar la instalación de 'extras' mediante las USE y con esto cubres tres aspectos importantes:

• Seguridad (menor código, menor número de posibles vulnerabilidades -- no enteramente aplicable)
• Rendimiento (menor cantidad de cosas a cargar por aplicación)
• Estabilidad (menor número de posibles conflictos entre librerías, paquetes, etc...)

Por otro lado, tan problemático es el tema de la actualización en gentoo como en cualquier otra distro, como ya mencionaron, sea gentoo o no, igual será imperativo probar antes de aplicar, pero gentoo puede facilitar una actualización en factores que otras distribuciones no pueden, por ejemplo, cosas como etc-update o dispatch-conf te permiten verificar los cambios en archivos de configuración dando la posibilidad de aprobarlos o no, lo cual facilita aún más el poder actualizar sin preocuparte de las configuraciones ya guardadas, lo que claro, entra en el tema del control de riesgos.

Siguiendo con el tema de las actualizaciones, también está collision-protect, cada paquete (sea por actualización o primera instalación) puede ser probado en busca de conflictos antes de ser instalado, lo que claro, también entra del tema de control de riesgos.

Cada servidor es diferente y lo normal es instalar algo que pueda cubrir las necesidades particulares, control sobre el sistema no he visto en otras distribuciones, tal vez en LFS pero es algo de diferente tónica y que no viene al tema, mi punto es que si eres capaz de controlar cada aspecto relacionado al funcionamiento, será menor el riesgo de una caída súbita en ese funcionamiento.




Salu2