Imagenes de instalación de las versiones estables para Mageia y OpenMandriva.
OpenMandriva: Mageia (Mageia 9) 20/Agosto/2023 - Anuncio, Descargas.
Blogdrake recomienda descargar las imágenes de instalación (iso) vía torrent para evitar corrupción de datos, aprovechar mejor su ancho de banda y mejorar la difusión de las distribuciones.
Solicitud de traducción de un laaaaargo post de sysadmins
Hola chicos,
Se requiere ayuda para esta traducción del blog de Mageia.
El método es el de siempre: eligen una parte, avisan que la toman para traducir, envían la traducción.
------------------ Parte 1 ---------------------
They Make Mageia – the Sysadmin team : Installation and configuration of software on Mageia servers
In the Mageia project the sysadmin team is responsible for the setup and maintenance of all the Mageia infrastructure, for users and contributors alike. To help people understand what this team does, and to share some ideas with other sysadmins, we will publish a series of posts to explain the things that we do.
Our main tasks are :
Installation of the servers in the datacenter
Installation and configuration of various software on Mageia Servers
Various admin tasks such as user permissions update, package removal, package movement between repositories etc.
Development and maintenance of various tools, such as components of the package build system
This first post will talk about the process used for the installation and configuration of software on Mageia servers, and explain some of the reasons we do this, and why you might want to use similar process when managing your own servers.
A summary of the process used to set up software on Mageia servers could be :
All software is installed using packages
All packages are built using the build system
All packages are installed and configured using puppet
The reasons for doing this might already be obvious for many Mageia packagers. This post will try to explain it for people who are not necessarily packagers.
------------------ Parte 2 ---------------------
Building and installing the software
One of the most common sysadmin tasks is software installation or update. When your Linux distribution provides packages for the software that you want to use, it is easy; the package can be installed using the packages manager.
However, in many cases the software that you need won’t be available in the distribution you are using, or will not be the version that you want to use.
Doing manual builds
Many people think that the simplest solution in this case is to download the source code for the software, follow the build instructions and run the provided install script or Makefile. There are however many problems when doing this:
Installing build dependencies :
You need to have all the build dependencies installed on your system. In most cases you will want to build the software on a dedicated build server in order to avoid installing too much build dependencies on your target machine, and then copy the resulting binaries on your machines.
Managing dependencies :
If you are using tarballs or an NFS server to distribute your binary software to the target machines, you will need to find and install the required dependencies on each machine where the software will be used. You will want to write the list of dependencies somewhere, so you can know what needs to be installed when you need to use that software on a new machine.
Updating software :
When building software, you often need to set specific options to a configure script, or in a configuration file. Some software can be difficult to build, or require some complex operations or configuration to build. When updating the software to a newer version, you will probably want to keep the same build configuration as before, to avoid introducing unneeded changes that could cause breakage. All of this is difficult to remember and unless you do it everyday you will probably forget. So you will want to save the build instructions in a file, to be able to reuse them the next time you need to update this software.
Patching the software :
Sometimes the software will require some small modifications to build, or to run, or you want some new feature. You can apply the changes before starting the build process. However those changes will be lost the next time you extract a new source tarball to update the software.
To be able to apply the same changes on the next versions, you will want to save those changes as a patch somewhere.
Keeping a changelog :
It’s easy to forget why you made some changes or updated a particular piece of software. Especially if you are not alone and working within a
team, you will want to keep a changelog of the changes you make on the software you build and install.
Knowing what version of your software is installed, uninstalling or updating software :
Knowing what version of a software is currently installed is very useful. It’s also very useful to be able to uninstall software, or install a different version for testing or debugging, or revert to a previous version if there’s a problem. If you use the standard install procedure, most software will install files in many different places on the system. Knowing which files are installed where, and which version is in use, is difficult if not impossible. When installing a new version of software, the install scripts will overwrite the old files, but will not remove obsolete files, which can create confusion or problems. Some people avoid this kind of problem by installing each piece of software in its own directory, including the version number in the directory name. This can, however, create other problems: most software is not intended to be installed this way and will require complex tricks to run. And the selection of the version that should be used needs some complex symbolic links or PATH environment variable updates. This becomes even more complicated when you install different software with dependencies between them. In order to avoid this kind of problem, the best solution is to use some tools to track which files are installed where, and which version.
------------------ Parte 3 ---------------------
Using packages
To solve all those problems you will want to use specific tools. You might want to start writing your own scripts and tools to manage these kinds of things. It makes sense to use the tools already available, instead of using your own specific tools. The best tools to solve this kind of problem are the Package Managers.
If you have never created packages before, you will need to spend some time learning how to do it. However this can save you a lot of time afterward. Using packages to build and install software has a lot of advantages:
Installing build dependencies :
Packages will permit you to build your software on a dedicated machine, producing packages that will be installed on the target machines without requiring you yo install any of the build dependencies. The package source also allows you to define the list of build dependencies, so that they can be installed automatically on your build machine when you want to build the package, and possibly removed afterward.
Managing dependencies automatically :
Tracking dependencies is time consuming and not always easy. Fortunately, most packaging systems will analyse the files included in the package to automatically detect the dependencies of the software. The perl, python, ruby, PHP, C/C++ libraries will usually automatically be detected during the package build. For the dependencies that cannot automatically be detected, it is also possible to define explicit dependencies in the package. All of those dependencies can then be installed automatically by the package manager when installing the software.
Updating software :
The source package contains the build instruction. The process used to build software will sometimes change a little, but most of the time it will be the same for all versions of the software. In that case, updating a package to a newer version is as simple as updating the version number in the package source and typing the command to start the package build. Rebuilding your software with a different option is also something that can be done easily.
Patching the software :
Source packages allow you to include patches that will be applied during the build of the package. This makes it easier to track the changes you applied to your software. When updating the software to a newer version, the same changes can easily be applied.
Keeping a changelog :
Packages include a changelog that you can use to explain the reasons for you changes, so you or other team members can know why you did some change 6 months ago. If you are using a source control tool like git or subversion to manage your source packages (which is recommended), you can also use the commit logs as a changelog.
Knowing what version of your software is installed, uninstalling or updating software :
Packages allow you to track the version of the software installed on your system. It also allows you to easily install, uninstall or update software, or find which package provides a file.
------------------ Parte 4 ---------------------
Building packages in a clean environment and deploying your packages
Why you should use a build system
The package manager is a very nice tool to manage the build and installation of software. However this is not enough. The package manager will build the software using the tools and libraries available on the current system, after installing the listed build dependencies.
There are a few problems with this :
Multiple-distribution support :
Sometimes your infrastructure will be using different distributions, or different releases of the same distribution. A package built on one distribution will not necessarily work on an other one, because the version of some components are different or incompatible. In order to avoid this kind of problems, the packages should be built using the same distribution as where they will be used.
Clean building environment :
The source packages include a list of build dependencies that should be installed to build the package. However when building the package on your own machine or on a specific build server, there are usually other packages that are already installed and will potentially be used during a package build. It is therefore very easy to forget that you installed some package, forget to include it in the package build dependencies and not notice the problem because the build works for you. You system might also have some custom configuration or updates that you forgot you installed, that can also impact package build. The problem will not be noticed until someone needs to rebuild the package on another system. If you want to increase the chances of being able to reproduce a package build in the future, you should use a clean environment for building packages. Usually this is done by creating, for each package build, a new minimal chroot for the selected distribution.
Once your package has been built, it needs to be copied onto the machines where it will be installed. Distributions usually provide tools to manage this (apt-get on Debian, urpmi on Mageia, yum on Fedora, etc.). Those tools will automatically download and install a package and its dependencies from a server sharing a package repository. In order to use those tools, you need to set up a package repository, which is a directory containing all the available packages and some metadata.
------------------ Parte 5 ---------------------
All of this can be managed manually, however it is much better to set up a package build system that will manage all of this for you automatically. Using a package build system has many advantages :
Less error-prone :
Building packages in a chroot, copying the resulting files to the correct repository and regenerating repository metadata is not very difficult, but is time consuming and error-prone if done manually. Using an automated packages build system will save time and avoid many errors.
Easier :
If building and installing packages in the repository is a difficult and time consuming task, you or other members of your team will be tempted to avoid it and do it using another solution.
Revision control tools and traceability :
Using a revision control tool like git or subversion to manage your source package changes is recommended. An SCM tied to the build system will ensure that any package available in the package repository is also available in the source control repository, giving traceability to your packages.
Enforcing packaging policies :
Some tools are available to enforce some packaging policies (rpmlint for rpm, lintian for deb). Having some packaging policies is useful to have consistent packages. The package build system can be configured to automatically run some policy tests and refuse upload of packages not complying with the policy.
Monitoring :
The build system allows monitoring of the latest builds. A web interface provides a review of the latest build, build logs. A mailing list can be used to receive build notifications. When working with a team it allows all team members to follow the latest changes.
Automation :
Some specific packages may require additional tasks to be done when they are updated. Sending an email, extracting some files to update a website or other tasks can be scripted so they are done automatically when this specific package is updated. This is what is used to extract the Mageia installer files in the mirror tree when the package is
updated.
How to install a Mageia Build System
This will be the topic of an other post.
------------------ Parte 6 ---------------------
Configuring your software
Installing software is usually only the first part of the work that is done by sysadmins. The second part is the configuration of the software. The package will do the first part of the initial configuration, however more configuration is usually needed.
There are various ways to do it :
Edit the configuration directly on the server manually
Avoid doing any manual configuration on any of your servers, but use a configuration management tool such as Cfengine, Puppet or Ansible to do it for you.
When using a configuration management tool, you don’t directly update the configuration on your servers, but write some rules in your configuration management repository that will be applied automatically by your configuration management tool. This is not as fast as directly editing the configuration on your server, but there are many advantages :
Manage your infrastructure like a software project :
Configuration tools allow you to manage your infrastructure like any other regular software development project. Many of the tools available to software developers can be used : source revision control, patch submission, code review, automated tests, etc.
Teamwork :
If working with a team, you can store your server configuration rules in a common source revision control repository, making it possible to follow and review all changes to the servers made by all members of the team.
Documentation :
Having some documentation about what software is installed on your servers and how they are configured is very useful, especially when there can be more than one person working on it. However a very common problem with documentation is that someone writes it initially, but nobody maintains it and it quickly becomes outdated. It is very easy to make a change and forget to document it, or forget that a documentation exists somewhere and needs to be updated. But having accurate documentation is important, and sometimes having outdated documentation providing false information can be worse than no documentation. The configuration management repository can be used as a kind of documentation on your infrastructure, and as it is what is actually used to set up your infrastructure, it is much more likely to be accurate than any other documentation. In software development, having self-documented code or code that can be understood without documentation is in general better than having documentation maintained separately, and this is the same for system administration.
Testing environment and reproducibility :
Using a configuration tool allows you to easily reproduce the configuration of a server on another server. This is useful when you need to replace or add a server, or if you need to set up a testing environment.
Maintaining a correct configuration :
The configuration management tool will run at regular intervals to check that the configuration is still correct and apply any necessary changes.
Reusability :
Like in software development, the use of a configuration management tool allows you to reuse the components that you created. It is usually possible to create modules with parameters to change the behaviour of the module. You can sometimes find existing modules on the internet, but unfortunately most of them will require important modifications to be adapted for your own use case. Earlier versions of puppet were missing important features such as parameterised class, so creating reusable components was difficult, but this has evolved.
------------------ Parte 7 ---------------------
Which configuration management tool to use ?
When we started the setup of Mageia servers, at the beginning of the Mageia Project, we decided to use puppet, after looking at the different tools available. Puppet looked like the most interesting configuration management tool at the time. In the last few years, things have evolved a lot in this area, and there are other alternatives to puppet that you might want to check before deciding which one to use :
ansible
salt stack
The Mageia puppet modules
The puppet modules that we use to configure the Mageia servers are available on an svn repository.
What needs to be improved
The current process is good, but there are still some things that could be improved. If you want to contribute but don’t know what could be useful, here are some ideas.
Automatic packages generation :
Some languages such as Perl, Python or Ruby provide their own packaging system for libraries. Many people like to use those packages rather than RPM packages because in the distribution packages are not always available or up to date. The advantage of those packages is that they are made upstream, so are immediately available. The problem is that they are usually not very well integrated with the rest of the system, and require using two different packaging systems, which makes things more complicated. In many case, people are not experienced packagers, so they simply use the available language specific packages, because they think packaging is too complex or don’t have time to do it. If a conversion from those packages to RPM was more simple, people could benefit from good availability of packages well integrated with the rest of the system. Fortunately those languages’ specific packages usually contain all the information that is needed for RPM packaging (descriptions, license, dependencies, etc.), so creating an RPM package is usually a simple conversion of that information into RPM format and can be automated. Thanks to the work from Jérôme Quelin on cpan2dist it’s possible to generate Mageia RPM packages from CPAN modules automatically. This is what allows us to have 3300 Perl packages available in the distribution.
We need to have similar tools for python, ruby and other language packages.
Build System setup :
We are using a build system to build our packages because we already have a build system available to build the Mageia distribution, so it’s not much more work to configure it to also have our own package repository. However installing a Mageia build system is currently not an easy task and people who don’t build a complete distribution will not want to spend too much time to configure a build system. So we need to improve the build system setup process to make it more simple. What is currently missing is some documentation to explain how to do this, using our puppet module. A future blog post on this blog will explain how to do this.
OBS Support :
Another alternative is to use OBS (Open Build Service), which is a nice build system with support for multiple distributions. However it is still lacking support for Mageia. We need to fix that so that it becomes possible to manage Mageia repositories using OBS.
Mageia support in Ansible and Salt Stack :
Ansible and Salt Stack are both interesting configuration management tools. However, they are still missing urpmi support for package installation. Update: Philippe Makowski has been working on a urpmi module for Ansible, but this is not yet integrated upstream, and contributions are welcome.
- Entra a tu cuenta o crea una para poder comentar.
# 121578 Partes 1 y 2
------------------ Parte 1 ---------------------
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 articulos 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:
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 (http://es.wikipedia.org/wiki/Puppet_%28software%29)
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.
------------------ Parte 2 ---------------------
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 facil 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.
¿lo usas?, ¿la lees?, ¿las conoces?,Herramienta útil
# 121586 Partes 3 y 4
------------------ Parte 3 ---------------------
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.
------------------ Parte 4 ---------------------
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.
¿lo usas?, ¿la lees?, ¿las conoces?,Herramienta útil
# 121589 Partes 5 y 6
----------------- Parte 5 ---------------------
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 (http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_configuraci%C3%B3n_de_software) 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.
------------------ Parte 6 ---------------------
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 deconfiguraciones 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.
¿lo usas?, ¿la lees?, ¿las conoces?,Herramienta útil
# 121590 Parte 7 (En progreso)
------------------ Parte 7 ---------------------
¿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 :
ansible
salt stack
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 facil 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 upstream, y las contribuciones son bien recibidas..
¿lo usas?, ¿la lees?, ¿las conoces?,Herramienta útil
BOFH
# 121595 Gracias!
Lo voy a subir ahora.
Un montón de gracias.
Jacen
BOFH y miembro del equipo MDKtrans
Linux user #294897