Los que hacen Mageia – equipo Sysadmin : Instalación y configuración de software en los servidores de Mageia

En el proyecto Mageia el equipo sysadmin es responsable de la configuración y mantenimiento de toda la infraestructura de Mageia, para usuarios y contribuidores por igual. Para ayudar a entender lo que hace este equipo y compartir algunas ideas con otros administradores de sistemas, publicaremos una serie de artículos para explicar las cosas que hacemos.

Nuestras tareas principales son :

  • Instalación de servidores en el centro de datos
  • Instalación y configuración de software en los servidores de Mageia
  • Varias tareas administrativas como actualizar permisos de usuario, eliminar paquetes, mover paquetes entre repositorios, etc.
  • Desarrollo y mantenimiento de varias herramientas, como los componentes del sistema de construcción

Este primer articulo hablara sobre la instalación y configuración del software en los servidores de Mageia, explicara algunas de las cosas que hacemos, y el por que podría querer usar un proceso similar cuando administre sus propios servidores.

Un resumen del proceso utilizado para configurar software en los servidores de Mageia sería:

  • Todo software se instala usando paquetes
  • Todos los paquetes son creados en nuestro sistema de construcción
  • Todos los paquetes son instalados y configurados usando puppet

Los motivos para hacer esto puede ser obvio para muchos de los empaquetadores de Mageia. Este articulo intentara explicarlo para todos aunque no sean empaquetadores.

Construyendo e instalando el software

Una de las tareas mas comunes del administrador de sistemas es la instalación o actualización de software. Es fácil cuando su distribución Linux proporciona paquetes para el software que quiere usar; el paquete puede instalarse usando el administrador de paquetes.

Sin embargo, en muchos casos el software que necesita no está disponible en la distribución que está usando o no es la versión que requiere.

Compilando manualmente

Mucha gente piensa que la solución más fácil en este caso es descargar el código fuente del software, seguir las instrucciones de compilación y ejecutar el script de instalación o Makefile proporcionado. Sin embargo hay muchos problemas al hacer esto:

  • Instalar dependencias para compilar:
    Necesita tener todas las dependencias para compilar instaladas en su sistema. En muchos casos querrá compilar el software en un servidor dedicado para evitar instalar demasiadas dependencias en su equipo, y posteriormente copiar los binarios resultantes a sus equipos.
  • Administrando dependencias:
    Si está usando tarballs o un servidor NFS para distribuir su software binario a otros equipos, necesitara encontrar e instalar las dependencias requeridas en cada equipo en el que el software sera usado. Querrá escribir la lista de dependencias en algún lugar para saber lo que se necesita instalar cuando necesita usar ese software en un equipo nuevo.
  • Actualizar software:
    Cuando compila software, es frecuente establecer opciones especificas al script configure o en un archivo de configuración. Algún software puede ser difícil de compilar o requiere de complejas operaciones o configuraciones para poder hacerlo. Al actualizar el software a una nueva versión, probablemente quiera mantener la misma configuración para evitar introducir cambios innecesarios que podrían causar fallos. Todo esto es difícil de recordar y a menos que lo haga diario probablemente lo olvidara. Por lo que deseara guardar las instrucciones de compilación para poder reutilizarlas la próxima vez que actualice este software.
  • Parchar el software:
    A veces el software requiere algunas pequeñas modificaciones para compilarlo o ejecutarlo, o quiere alguna nueva característica. Puede aplicar los cambios antes de iniciar el proceso de compilación. Sin embargo esos cambios se perderán la siguiente ocasión en que extraiga las fuentes de un nuevo tarball para actualizar el software.
    Para poder aplicar los mismos cambios en la nuevas versiones, deberá guardar esos cambios como un parche en algún lugar.
  • Llevar un registro:
    Es fácil olvidar por que hizo algún cambio o actualizo una pieza de software en particular. Especialmente si no está solo y trabaja dentro de un equipo, deberá llevar un registro de los cambios que realice en el software que compila e instala.
  • Saber que versión de su software está instalada, desinstalar o actualizar software:
    Es muy útil saber la versión actualmente instalada de un software. También es muy útil poder desinstalar software, o instalar una versión diferente para evaluar , depurar o revertir a una versión previa si hay algún problema. Si utiliza el proceso estándar de instalación, mucho software instalara archivos en varios lugares distintos en el sistema. Saber que archivos y en donde son instalados, y que versión está en uso es difícil si no imposible. Cuando instala una nueva versión de software, los script de instalación sobreescribirán los viejos archivos, pero no eliminaran los obsoletos, lo que puede causar confusión o problemas. Algunos evitan estos problemas instalando cada software en su propio directorio, incluyendo el numero de versión en el nombre de directorio. Sin embargo, esto puede crear otros problemas: mucho software no está preparado para instalarse de está forma y requiere de complejos trucos para funcionar. Y la selección de la versión que sera usada necesita de complejos enlaces simbólicos o actualizaciones de la variable de entorno PATH. Esto se hace aun más complicado cuando instala varias aplicaciones con dependencias entre ellas. Para evitar este tipo de problemas la mejor solución es usar algunas herramientas que rastree el lugar y la versión de los archivos instalados.

Usando paquetes

Para resolver todos esos problemas deberá usar herramientas especificas. Tal vez quiera comenzar a escribir sus propias herramientas y scripts para manejar ese tipo de cosas. Tiene más sentido usar las herramienta ya disponibles que usar las suyas propias. Las mejores herramientas para solucionar este tipo de problemas son los administradores de paquetes.

Si anteriormente no ha creado paquetes, necesitara invertir algo de tiempo en aprender a hacerlo. Sin embargo esto le puede ahorrar un montón de tiempo posteriormente. Usar paquetes para compilar e instalar software tiene muchas ventajas:

  • Instalar dependencias de compilación:
    Los paquetes le permiten compilar su software en una maquina dedicada, producir paquetes que serán instalados en el equipo requerido sin tener que instalar ninguna de las dependencias de compilación.
    El paquete fuente también le permite definir la lista de dependencias de compilación, así podrá instalarlas automáticamente en su equipo cuando quiera compilar un paquete y tal vez quitarlas posteriormente.
  • Manejo manual de dependencias:
    El seguimiento de dependencias consume tiempo y no siempre es fácil. Afortunadamente muchos de las sistemas de empaquetado analizaran los archivos incluidos en el paquete y detectaran automáticamente las dependencias del software. Las librerías de perl, python, ruby, PHP, C/C++ usualmente se detectan automáticamente durante la construcción del paquete. Para las dependencias que no puedan ser detectadas automáticamente es posible definirlas explícitamente en el paquete. Entonces todas esas dependencias podrán ser automáticamente instaladas por el administrador de paquetes al instalar el software.
  • Actualizar el software:
    El paquete fuente contiene las instrucciones de compilación. El proceso para compilar el software a veces cambia un poco, pero la mayoría de las veces sera el mismo para todas las versiones del software. En ese caso actualizar un paquete es tan simple como actualizar el numero de versión en el paquete fuente y ejecutar el comando para construir el paquete. Recompilar el software con una opción diferente también puede hacerse fácilmente.
  • Parchar el software:
    Los paquetes fuente le permiten incluir parches que serán aplicados durante la construcción del paquete. Esto hará más fácil el seguimiento de los cambios que aplique al software. Cuando actualice el software a una nueva versión los mismos cambios pueden aplicarse fácilmente.
  • Mantener un registro:
    Los paquetes incluyen un registro que puede usar para explicar las razones de sus cambios, así usted u otro miembro podrán saber el por que realizo un cambio hace 6 meses. Si utiliza una herramienta de control de fuentes como git o subversion para administrar sus paquetes (lo recomendamos), puede usar el registro de envíos para este fin.
  • Saber que versión de su software está instalada, desinstalar o actualizar software:
    Los paquetes le permiten rastrear la versión del software instalado en su sistema. También le permite facilitar la instalación, eliminación o actualización del software, o encontrar que paquete proporciona un archivo.

Construir paquetes en un ambiente limpio e implementar sus paquetes

Por que debería usar un sistema de construcción

El administrador de paquetes es una herramienta hermosa para administrar la construcción e instalación de software. Sin embargo, esto no es suficiente. El administrador de paquetes compilara el software utilizando las herramientas y librerías disponibles en el sistema, tras instalar la lista de dependencias de compilación.

Hay algunos problemas con esto :

  • Soporte multi distribución:
    Algunas veces su infraestructura constara de diferentes distribuciones, o diferentes versiones de la misma distribución. Un paquete construido en una distribución no necesariamente funcionara en otra, debido a que las versiones de algunos componentes son diferentes o incompatibles. Para evitar este tipo de problemas, los paquetes deben construirse en la misma distribución en la que serán usados.
  • Limpiar el entorno:
    Los paquetes fuente incluyen una lista de dependencias de compilación que deberán instalarse para construir el paquete. Sin embargo cuando construya el paquete en su sistema o en un servidor de construcción especifico, usualmente hay otros paquetes instalados que podrían utilizarse durante la construcción del paquete. Por lo tanto es muy fácil olvidar que instalo algún paquete,olvidar incluirlo en la lista de dependencias de compilación y no notar el problema por que a usted le funciona. Su sistema también puede tener algunas configuraciones personalizadas o actualizaciones que olvido que había instalado, eso también puede impactar en la construcción del paquete. El problema no se notara hasta que alguien necesite reconstruir el paquete en otro sistema. Si quiere incrementar las oportunidades de poder reproducir la construcción de un paquete, debe utilizar un entrono limpio para construir paquetes. Usualmente esto se hace creando un entorno chroot mínimo para la distribución seleccionada.

Una vez que su paquete se ha construido, es necesario copiarlo a las maquinas en las que sera instalado.

Las distribuciones usualmente proporcionan herramientas para hacer esto (apt-get en Debian, urpmi en Mageia, yum en Fedora, etc.). Estas herramientas automáticamente descargaran e instalaran un paquete y sus dependencias desde un servidor que comparta un repositorio de paquetes. Para poder usar estas herramientas, es necesario que configure un repositorio de paquetes, que es un directorio que contiene todos los paquetes disponibles y algunos meta datos.

Todo esto puede administrarse manualmente,sin embargo es mejor configurar un sistema de construcción de paquetes que haga todo esto automáticamente. Usar un sistema de construcción de paquetes tiene muchas ventajas :

  • Menos propenso a errores:
    Construir los paquetes en un entorno chroot, copiar los archivos resultantes al repositorio correcto y regenerar los metadatos del repositorio no es muy difícil, pero requiere tiempo y es propenso a errores si se hace manualmente. Usar un sistema automático de construcción de paquetes le ahorrara tiempo y le evitara muchos errores.
  • Simplificando:
    Si construir paquetes e instalarlos en el repositorio son tareas difíciles y tardadas, usted o los miembros de su equipo estarán tentados a evitarlas y a usar otra solución para realizarlas.
  • Herramientas de control de revisión y rastreabilidad:
    Se recomienda usar herramientas de control de revisión como git o subversion para administrar los cambios en los paquetes fuente. Un SCM anclado al sistema de construcción se asegura que cualquier paquete disponible en los repositorios también se encuentre en el repositorio de control de fuentes, dando rastreabilidad a sus paquetes.
  • Vigilar las políticas de empaquetado:
    Existen algunas herramientas para vigilar algunas políticas de empaquetado (rpmlint para rpm, lintian para deb). Tener políticas de empaquetado es útil para tener paquetes consistentes. El sistema de construcción de paquetes puede ser configurado para ejecutar automáticamente algunas pruebas y rechazar la subida de paquetes que no cumplan las políticas.
  • Monitorear:
    El sistema de construcción permite monitorear las ultimas compilaciones. Una interfaz web proporciona una vista de las ultimas compilaciones y registros de compilación. Se puede utilizar una lista de correo para recibir notificaciones sobre las compilaciones. Cuando se trabaja en equipo, esto permite a los miembros del equipo seguir los últimos cambios.
  • Automatización:
    Algunos paquetes pueden requerir hacer tareas adicionales al ser actualizarlos. Enviar un correo electrónico, extraer algunos archivos para actualizar un sitio web u otras tareas, pueden realizarse mediante scripts y por lo tanto realizarse automáticamente cuando se actualizan esos paquetes. Esto es lo que se hace cuando se extraen los archivos del instalador de Mageia en el servidor, al momento de actualizar el paquete.

Como instalar el Sistema de Construcción de Mageia

Esto sera tema de otro articulo.

Configurar el software

Instalar el software usualmente solo es la primer parte del trabajo hecho por los administradores de sistemas. La segunda parte es la configuración de ese software. El paquete hará la primer parte de la configuración inicial, sin embargo, usualmente se requiere de configuración adicional.

Hay varias formas de hacerlo :

  • Editar manualmente la configuración directamente en cualquiera de sus servidores
  • o hacer que una herramienta de manejo de configuraciones como Cfengine, Puppet o Ansible lo haga por usted.

Cuando utiliza una herramienta de manejo de configuraciones, no se actualiza directamente la configuración en sus servidores, se escriben algunas reglas en su repositorio de manejo de configuraciones, las cuales serán aplicadas automáticamente por su herramienta de manejo de configuraciones. Esto no es tan rápido como editar directamente la configuración en su servidor, pero tiene muchas ventajas:

  • Administrar su infraestructura como un proyecto de software:
    Las herramientas de configuración le permiten administrar su infraestructura de forma similar a cualquier otro proyecto de software. Muchas de las herramientas disponibles para los desarrolladores de software pueden utilizarse : control de revisiones, envió de parches, vista del código, pruebas automáticas, etc.
  • Trabajo en equipo:
    Si trabaja en un equipo, puede almacenar las reglas de configuración de su servidor en un repositorio de control de revisiones común, haciendo posible seguir y revisar todos los cambios hechos por los miembros del equipo en todos los servidores.
  • Documentación:
    Tener alguna documentación sobre que software está instalado en sus servidores y como está configurado, es muy útil, especialmente cuando más de una persona está trabajando en ellos. Sin embargo un problema muy común con la documentación es que alguien la escribe inicialmente, pero nadie la mantiene y rápidamente queda anticuada. Es muy fácil hacer un cambio y olvidar documentarlo, o olvidar que la documentación existe y necesita ser actualizada. Pero tener una documentación precisa es importante, y en ocasiones tener documentación anticuada que proporciona información falsa puede ser peor que no tener documentación. El repositorio de manejo de configuraciones puede usarse como un tipo de documentación de su infraestructura, y sobre lo que realmente se usa para configurar su infraestructura, donde es más importante que la documentación sea precisa. En el desarrollo de software, tener código auto documentado que puede entenderse sin documentación es en general mejor que tener que mantener separadamente la documentación, y es igual en la administración de sistemas.
  • Probar el entorno y reproducibilidad:
    Utilizar una herramienta de configuración le permite reproducir fácilmente la configuración de un servidor en otro servidor. Esto es util cuando tiene que reemplazar o añadir un servidor, o si necesita configurar un entorno de prueba.
  • Mantener una configuración correcta:
    La herramienta de manejo de configuraciones se ejecutara a intervalos regulares para revisar que la configuración está correcta y aplicara cualquier cambio necesario.
  • Reusabilidad:
    Como en el desarrollo de software, el uso de herramientas de manejo de configuración le permite reutilizar componentes que ha creado. Usualmente es posible crear módulos con parámetros que cambien el entorno del modulo. A veces puede encontrar módulos preparados en el internet, pero desafortunadamente muchos de ellos requerirán de importantes modificaciones para adaptarlos para su uso. Versiones anteriores de puppet carecían de características importantes como clases parametrizadas, así que crear componentes reutilizables era difícil, pero eso ha cambiado.

¿Que herramienta de manejo de configuración usar?

Cuando comenzamos a configurar los servidores del proyecto Mageia, decidimos tras mirar las diferentes herramientas disponibles, usar puppet. Puppet parecía la más interesante herramienta de manejo de configuración en ese momento. En pocos años las cosas han evolucionado un montón en está área, y hay otras alternativas que tal vez quiera revisar antes de decidir cual quiere usar :

Los módulos puppet de Mageia

Los módulos puppet que usamos para configurar los servidores de Mageia están disponibles en un repositorio svn.

Lo que necesita mejorarse

El proceso actual es bueno, pero aún hay cosas que pueden mejorarse. Si quiere contribuir pero ignora que podría ser de utilidad, aquí hay algunas ideas.

  • Generación automática de paquetes:
    Algunos lenguajes como Perl, Python o Ruby proporcionan su propio sistema de empaquetamiento para sus librerías. A muchas personas les gusta usar esos paquetes en lugar de paquetes RPM debido a que no siempre hay paquetes disponibles en la distribución o no están actualizados. La ventaja de de esos paquetes es que son hechos por el desarrollador y están disponibles inmediatamente. El problema es que usualmente no se integran muy bien en el resto del sistema y requieren utilizar dos diferentes sistemas de paquetes, lo que podría complicar más las cosas. En muchos casos, las personas no son empaquetadores experimentados, por lo que simplemente utilizan los paquetes del lenguaje, por que piensan que empaquetar es muy complicado o no tienen tiempo de hacerlo. Si convertir esos paquetes a RPM fuera más simple, las personas se beneficiaran de una buena disponibilidad de paquetes bien integrados con el resto del sistema.

    Afortunadamente los paquetes de esos lenguajes usualmente contienen toda la información necesaria para empaquetarlos en RPM (descripciones, licencia, dependencias, etc.), así que crear un paquete RPM es usualmente una simple conversión de esa información al formato RPM fy puede automatizarse. Gracias al trabajo de Jérôme Quelin en cpan2dist es posible generar paquetes RPM para Mageia desde los módulos CPAN automáticamente. Esto es lo que nos permite tener disponibles 3300 paquetes de Perl en la distribución.
    Necesitamos herramientas similares para python, ruby y otros lenguajes.

  • Configuración del Sistema de Construcción:
    Estamos usando un sistema de construcción para nuestros paquetes por que ya teníamos disponible un sistema para construir la distribución, así que no es mucho trabajo configurarlo para también tener nuestro propio repositorio. Sin embargo instalar el sistema de construcción de Mageia no es una tarea fácil y las personas que no hagan una distribución completa no querrán gastar demasiado tiempo configurando un sistema de construcción. Así que necesitamos mejorar el proceso de configuración del sistema de construcción para hacerlo mas sencillo. Actualmente falta alguna documentación que explique como hacerlo utilizando nuestro modulo puppet. Un futuro articulo del blog explicara como hacerlo.
  • Soporte de OBS:
    Otra alternativa es utilizar OBS (Open Build Service), que es un buen sistema de construcción con soporte para varias distribuciones. Sin embargo aun no tiene soporte para Mageia. Necesitamos corregir eso para que sea posible administrar los repositorios de Mageia mediante OBS.
  • Soporte a Mageia en Ansible y Salt Stack:
    Ansible y Salt Stack son interesantes herramientas de manejo de configuración. Sin embargo aun carecen de soporte a urpmi para la instalación de paquetes.
    Actualización: Philippe Makowski ha estado trabajando en un modulo de urpmi para Ansible, pero aun no se integra oficialmente, y las contribuciones son bien recibidas.

Traducción del artículo escrito por boklm

Publicado en Mageia, Sin categoría, sysadmin | 1 comentario

Nuevas iso para Mageia 3 (instalador clasico)

A pesar del cuidado con el que probamos las iso de las nuevas versiones de Mageia, omitimos un fallo potencialmente grande… Afecta a las iso que utilizan el instalador clasico. Si el usuario elige añadir repositorios al inicio de la instalación, provocara que el sistema se actualice a Cauldron, la versión de desarrollo de Mageia. Esto se debe a que las primeras iso incluían un fallo de identificación parcial que hacia referencia a la versión de desarrollo (y no a la oficial). Los repositorios de actualización apuntaban a Mageia Cauldron y no a Mageia 3. Por favor note que los usuario que eligen añadir repositorios al final de la instalación no están afectados por este problema.

Mientras se preparaban y probaban nuevas iso, se aplico un arreglo temporal en nuestra infraestructura para redirigir automáticamente hacia los repositorios de Mageia 3. Esto solo afecto a los usuarios de Cauldron quienes tuvieron que instalar explícitamente los repositorios para Cauldron.

Se ha aplicado el parche y nuevas iso están disponibles para reemplazar a las primeras.

Si descarga las iso directamente de alguno de nuestros servidores, puede fácilmente revisar que tiene la ultima versión. Revise el archivo DATE.txt. Debera tener:

  • DVD 32: Thu Jun 6 2013 3:40:24 p.m. EST
  • DVD 64: Thu Jun 6 2013 3:49:47 p.m. EST
  • Dual CD: Thu Jun 6 2013 3:56:17 p.m. EST

Utilizando nuestro sitio (puede hacerlo en otros casos), puede revisar la md5sum:

  • Mageia-3-dual-CD.iso: a2a9917c068d2a50ff2312821b055a1e
  • Mageia-3-i586-DVD.iso: d80fd26018e98a03ae020f15327fccf4
  • Mageia-3-x86_64-DVD.iso: 16547c7c1f933322122820468aa91e14

 

También puede revisar el contenido de los siguientes archivos (ejemplo de una instalación x86_64):

  • /etc/product.id

vendor=Mageia.Org,distribution=Mageia,type=Basic,version=3,
branch=Official,release=1,arch=x86_64,product=Default

  • /etc/mageia-release

Mageia release 3 (Official) for x86_64

Por favor note que no actualizamos el software contenido en las iso para evitar nuevos problemas y regresiones no deseadas. Por lo tanto las erratas siguen vigentes, fueron adecuadamente actualizadas.

Traducido del original publicado por ennael

Publicado en Sin categoría | 5 comentarios

Mageia en el LSM

rmllenComo parte de nuestro Recorrido Europeo, Mageia estará en LSM (en Francés RMLL), la 14ta Reunión de Software Libre Software que se efectuara en Bruselas del 6 al 11 de Julio en la Université Libre de Bruxelles.

Planeamos tener nuestros primeros Dias de Mageia en el LSM – días en los que las personas de Mageia pueden reunirse para hablar, planear y descubrir juntos Mageia. Para hacer eso posible, Mageia tendrá un Dev Room en el LSM. ¡Seremos la única distro que tendrá un dev room!

El LSM es un evento organizado por voluntarios, pero aun tienen que cubrir algunos gastos para poder organizar este tipo de evento, y como la entrada es gratuita ellos depende de las donaciones para hacerlo. El Consejo de Mageia acordó donar €500 a LSM a cambio del uso del dev room y las facilidades proporcionadas.

Asegúrese de tener la oportunidad de ¡Conocer a otras personas de Mageia! Para ayudarnos a saber cuanta gente estará, puede añadir su nombre en la pagina del wiki.

Traducido del original publicado por trish.

Publicado en Sin categoría | Comentarios desactivados en Mageia en el LSM

Ya creció y está lista para salir a bailar: ¡Mageia 3 ha sido lanzada!

Aún no podemos creer lo entretenido que ha sido hacer juntos Mageia, y lo hemos estado haciendo por dos años y medio.

Para quienes no pueden esperar, aquí lo tienen. Las notas de la versión están aquí. Para actualizar desde Mageia 2, vean aquí.

Antes de continuar con la descripción, dedicamos este lanzamiento a la memoria de Eugeni Dodonov, nuestro amigo, colega y gran inspiración para quienes ha dejado atrás. Extrañamos su inteligencia, cortesía y dedicación.

 ¿Qué hay de nuevo en Mageia 3?

Puede dar un vistazo a la lista completa de paquetes actualizados desde Mageia 2 revisando la Base de datos de Aplicaciones de Mageia:

Las características nuevas mas importantes

  • Actualizaciones de RPM (4.11) y urpmi, las que han recibido una buena limpieza y asistencia de Mageia
  • Kernel 3.8
  • systemd 195
  • GRUB es el gestor de arranque predeterminado. GRUB2 está disponible para pruebas.
  • Una renovada agrupación de paquetes para instalación y para rpmdrake
  • KDE 4.10.2
  • GNOME 3.6.
  • Xfce 4.10
  • Libreoffice 4.0.3

Y además: ¡Steam para Linux!

Vea las Notas de la Versión y MageiaAppDB para la lista completa.

¿Por qué elegir Mageia?

Comunidad

Todos trabajamos juntos para hacer la mejor distribución que podamos y para ayudar el uno al otro. Únasenos, y conozca a los mejores amigos que podrá conocer, en IRC, en los Foros, en cualquiera de los equipos, en Google+, en Facebook o síganos en Twitter .

Soporte abierto

El sistema de reporte de fallos de Mageia está abierto para todos, así como también lo están las listas de correo y el soporte de la comunidad. Esto hace mas fácil que su voz sea oída y que pueda seguir lo que está ocurriendo. ¡Y el acceso a nuestras actualizaciones de seguridad completamente probadas y prontas es gratis para todos!

¡Que bien se ve!

Usted se dará cuenta de que hemos actualizado nuestro logo. Gracias a Nicolas Duval por este gran diseño. Sigue siendo Mageia, sigue siendo Cauldron, pero con un toque real de Mageia.


Nuevamente gracias a Leo por nuestro nuevo gran fondo de pantalla.
El equipo Atelier de Mageia desea que le agrade nuestro nuevo look tanto como nos gustó hacerlo.

No podríamos haberlo hecho sin…

Nuestras gracias de corazón a toda la gente que donó su tiempo para hacer posible este lanzamiento, y a toda la gente que donó dinero para comprar los servidores que utilizamos para construir la distribución.

Todos los Mageianos hemos dependido de Gandi y Ielo quienes han estado auspiciando Mageia de manera silenciosa desde el inicio del proyecto. Gandi nos ha provisto máquinas en su infraestructura de nube las que usamos para hospedar el blog y el sitio web. Ielo ha provisto espacio en su centro de datos y la conexión de red para hospedar todos los otros servidores que utilziamos para toda la infraestructura de Mageia tal como el sistema de construcción de paquetes, seguimiento de fallos, listas de correo, espejo principal, etc. ¡Gracias!

¡Bienvenido a Mageia 3!

Publicado en Mageia, versiones | Etiquetado , | 3 comentarios

Tour europeo 2013 de Mageia

Mageia estará presente en los principales eventos Linux en Europa este año, tal como lo hemos hecho en años anteriores.

Ya asistimos a la FOSDEM donde celebramos nuestra asamblea.

El tour seguirá en las próximas semanas.

El primer evento será Linuxtag en Berlin, Alemania. Linuxtag es evento líder de Código Abierto y Linux en Europa. Este año es la versión 19 de Linux tag y es la séptima que se realiza en Berlin fair grounds. Linuxtag se realizará entre el 22 de y el 25 de mayo.

Mageia tendrá un puesto ahí, donde presentaremos el proyecto y la nueva versión Mageia 3. Tendrá la oportunidad de conocernos ahí y preguntarnos todo lo que ha querido preguntar sobre el proyecto. Como es usual, tendremos una cena de Mageia el viernes en la noche. Si quiere unírsenos, pase por el puesto de Mageia y pregunte por el lugar y la hora.

Después de Linuxtag, estaremos en Solutions Linux en París, Francia, entre el 28 y el 29 de mayo. Tendrá oportunidad de conocer a algunas de las personas que apoyan y desarrollan su distribución favorita y obtener poleras y adhesivos de Mageia ¡y también descubrir Mageia 3!

¡Y eso no es todo! La gente de Mageia asistirá también a RMLL en Bruselas, Bélgica, a realizarse entre el 6 y el 11 de julio en la ULB.

Después estaremos en la FrOSCon el 24 y 25 de Agosto. La FrOSCon es organizada por los estudiantes de la Universidad de ciencias aplicadas Bonn-Rhein-Sieg cerca de Cologne, Alemania.

El último evento del tour de este año será OpenRheinRuhr el 9 y 10 de Noviembre en el Museo industrial en Oberhausen, Alemania.

Traducción de la entrada publicado por obgr_seneca.

Publicado en Sin categoría | 1 comentario