Unificación de scripts personalizados en todo el sistema con rpm en Red Hat/CentOS

Objetivo

Nuestro objetivo es crear paquetes rpm con contenido personalizado, unificando scripts en cualquier cantidad de sistemas, incluido el control de versiones, la implementación y la anulación de la implementación.

Sistema operativo y versiones de software

• Sistema operativo: Red Hat Enterprise Linux 7.5
• Software: rpm-construir 4.11.3+

Requisitos

Acceso privilegiado al sistema para instalación, acceso normal para compilación.

Dificultad

MEDIO

Convenios

• # – requiere que los comandos de Linux dados se ejecuten con privilegios de root, ya sea directamente como usuario root o mediante el uso de sudo comando
• $ – comandos de Linux dados para ser ejecutados como un usuario regular sin privilegios

Introducción

Una de las características principales de cualquier sistema Linux es que están diseñados para la automatización. Si es necesario ejecutar una tarea más de una vez, incluso si alguna parte cambia en la próxima ejecución, un administrador de sistemas cuenta con innumerables herramientas para automatizarla, desde un simple shell desde scripts ejecutados a mano bajo demanda (eliminando así los errores tipográficos, o solo guardando algunas pulsaciones de teclado) hasta sistemas complejos con scripts donde las tareas se ejecutan desde cron en un momento específico, interactuando entre sí, trabajando con el resultado de otro script, tal vez controlado por un sistema de gestión central, etc.

Si bien esta libertad y este rico conjunto de herramientas aumentan la productividad, hay un problema:como administrador de sistemas, escribe un script útil en un sistema, que resulta ser útil en otro, por lo que copia el script. En un tercer sistema, la secuencia de comandos también es útil, pero con una modificación menor:tal vez una nueva característica útil solo en ese sistema, accesible con un nuevo parámetro. Teniendo en cuenta la generalización, amplía el script para proporcionar la nueva función y también completa la tarea para la que fue escrito. Ahora tiene dos versiones del script, la primera está en los dos primeros sistemas, la segunda en el tercer sistema.

Tiene 1024 computadoras ejecutándose en el centro de datos, y 256 de ellas necesitarán algunas de las funciones proporcionadas por ese script. Con el tiempo, tendrá 64 versiones del script por todas partes, cada versión haciendo su trabajo. En la próxima implementación del sistema, necesita una característica que recuerde que codificó en alguna versión, pero ¿cuál? ¿Y en qué sistemas están?

En los sistemas basados ​​en RPM, como los sabores de Red Hat, un administrador de sistemas puede aprovechar el administrador de paquetes para crear un orden en el contenido personalizado, incluidos los scripts de shell simples que pueden no proporcionar más que las herramientas que el administrador escribió para su comodidad.

En este tutorial crearemos un rpm personalizado para Red Hat Enterprise Linux 7.5 que contiene dos bash secuencias de comandos, parselogs.sh y pullnews.sh para proporcionar una forma en que todos los sistemas tengan la última versión de estos scripts en el /usr/local/sbin directorio y, por lo tanto, en la ruta de cualquier usuario que inicie sesión en el sistema.

Distribuciones, versiones principales y secundarias

En general, la versión secundaria y principal de la máquina de compilación debe ser la misma que la de los sistemas en los que se implementará el paquete, así como la distribución para garantizar la compatibilidad. Si hay varias versiones de una distribución determinada, o incluso diferentes distribuciones con muchas versiones en su entorno (¡qué alegría!), debe configurar máquinas de compilación para cada una. Para abreviar el trabajo, puede configurar un entorno de compilación para cada distribución y cada versión principal, y tenerlos en la versión secundaria más baja existente en su entorno para la versión principal dada. Por supuesto, no es necesario que sean máquinas físicas y solo deben estar ejecutándose en el momento de la compilación, por lo que puede usar máquinas virtuales o contenedores.

En este tutorial, nuestro trabajo es mucho más fácil, solo implementamos dos scripts que no tienen dependencias (excepto bash ), por lo que construiremos noarch paquetes que significan "no dependiente de la arquitectura", tampoco especificaremos la distribución para la que se creó el paquete. De esta manera podemos instalarlos y actualizarlos en cualquier distribución que use rpm , y a cualquier versión; solo debemos asegurarnos de que rpm-build de la máquina de compilación el paquete está en la versión más antigua del entorno.

Configuración del entorno del edificio

Para crear paquetes rpm personalizados, necesitamos instalar rpm-build paquete:

# yum install rpm-build

De ahora en adelante, no usamos root usuario, y por una buena razón. La construcción de paquetes no requiere root privilegio, y no quiere romper su máquina de construcción.

Construyendo la primera versión del paquete

Vamos a crear la estructura de directorios necesaria para construir:

$ mkdir -p rpmbuild/SPECS

Nuestro paquete se llama admin-scripts, versión 1.0. Creamos un specfile que especifica los metadatos, contenidos y tareas realizadas por el paquete. Este es un archivo de texto simple que podemos crear con nuestro editor de texto favorito, como vi . El rpmbuild previamente instalado el paquete llenará su archivo de especificaciones vacío con datos de plantilla si usa vi para crear uno vacío, pero para este tutorial considere la siguiente especificación llamada admin-scripts-1.0.spec :

Name:           admin-scripts
Version:        1
Release:        0
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Coloque el archivo de especificaciones en rpmbuild/SPEC directorio que creamos anteriormente.

Necesitamos las fuentes a las que se hace referencia en el specfile – en este caso, los dos scripts de shell. Vamos a crear el directorio para las fuentes (llamado como el nombre del paquete adjunto a la versión principal):

$ mkdir -p rpmbuild/SOURCES/admin-scripts-1/scripts

Y copie/mueva los scripts en él:

$ ls rpmbuild/SOURCES/admin-scripts-1/scripts/
parselogs.sh  pullnews.sh

Como este tutorial no se trata de secuencias de comandos de shell, el contenido de estas secuencias de comandos es irrelevante. Como vamos a crear una nueva versión del paquete, y el pullnews.sh es el script con el que demostraremos, su fuente en la primera versión es la siguiente:

#!/bin/bash
echo "news pulled"
exit 0

No olvide agregar los derechos apropiados a los archivos en la fuente; en nuestro caso, derecho de ejecución:

chmod +x rpmbuild/SOURCES/admin-scripts-1/scripts/*.sh




Ahora creamos un tar.gz archivo de la fuente en el mismo directorio:

cd rpmbuild/SOURCES/ && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Estamos listos para construir el paquete:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.0.spec

Obtendremos algunos resultados sobre la compilación y, si algo sale mal, se mostrarán los errores (por ejemplo, falta un archivo o una ruta). Si todo va bien, nuestro nuevo paquete aparecerá en el directorio RPMS generado por defecto bajo el rpmbuild directorio (ordenado en subdirectorios por arquitectura):

$ ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm

Hemos creado un paquete rpm simple pero completamente funcional. Podemos consultarlo para todos los metadatos que proporcionamos anteriormente:

$ rpm -qpi rpmbuild/RPMS/noarch/admin-scripts-1-0.noarch.rpm 
Name        : admin-scripts
Version     : 1
Release     : 0
Architecture: noarch
Install Date: (not installed)
Group       : Application/Other
Size        : 78
License     : GPL
Signature   : (none)
Source RPM  : admin-scripts-1-0.src.rpm
Build Date  : 2018. aug.  1., Wed, 13.27.34 CEST
Build Host  : build01.foobar.com
Relocations : (not relocatable)
Packager    : John Doe 
URL         : www.foobar.com/admin-scripts
Summary     : FooBar Inc. IT dept. admin scripts
Description :
Package installing latest version the admin scripts used by the IT dept.




Y por supuesto podemos instalarlo (con root privilegios):

Instalación de scripts personalizados con rpm

Como instalamos los scripts en un directorio que está en el $PATH de cada usuario , puede ejecutarlos como cualquier usuario del sistema, desde cualquier directorio:

$ pullnews.sh 
news pulled




El paquete se puede distribuir tal como está y se puede enviar a repositorios disponibles para cualquier número de sistemas. Hacerlo está fuera del alcance de este tutorial; sin embargo, construir otra versión del paquete ciertamente no lo está.

Construyendo otra versión del paquete

Nuestro paquete y los scripts extremadamente útiles que contiene se vuelven populares en poco tiempo, considerando que se puede acceder a ellos en cualquier lugar con un simple yum install admin-scripts dentro del medio ambiente. Pronto habrá muchas solicitudes para algunas mejoras; en este ejemplo, muchos votos provienen de usuarios satisfechos de que pullnews.sh debería imprimir otra línea en la ejecución, esta función salvaría a toda la empresa. Necesitamos crear otra versión del paquete, ya que no queremos instalar otro script, sino una nueva versión con el mismo nombre y ruta, ya que los administradores de sistemas de nuestra organización ya confían en él en gran medida.

Primero cambiamos la fuente del pullnews.sh en las FUENTES a algo aún más complejo:

#!/bin/bash
echo "news pulled"
echo "another line printed"
exit 0

Necesitamos recrear el tar.gz con el nuevo contenido fuente:podemos usar el mismo nombre de archivo que la primera vez, ya que no cambiamos la versión, solo la liberamos (y así el Source0 la referencia seguirá siendo válida). Tenga en cuenta que primero eliminamos el archivo anterior:

cd rpmbuild/SOURCES/ && rm -f admin-scripts-1.tar.gz && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Ahora creamos otro archivo de especificaciones con un número de versión más alto:

cp rpmbuild/SPECS/admin-scripts-1.0.spec rpmbuild/SPECS/admin-scripts-1.1.spec

No cambiamos mucho en el paquete en sí, así que simplemente administramos la nueva versión como se muestra a continuación:

Name:           admin-scripts
Version:        1
Release:        1
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Listo, podemos construir otra versión de nuestro paquete que contenga el script actualizado. Tenga en cuenta que hacemos referencia al archivo de especificaciones con la versión superior como fuente de la compilación:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.1.spec

Si la compilación es exitosa, ahora tenemos dos versiones del paquete en nuestro directorio RPMS:

ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm  admin-scripts-1-1.noarch.rpm

Y ahora podemos instalar el script "avanzado", o actualizar si ya está instalado.

Actualización de scripts personalizados con rpm

Y nuestros administradores de sistemas pueden ver que la solicitud de función se encuentra en esta versión:

rpm -q --changelog admin-scripts
* Wed aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line

* Wed aug 01 2018 John Doe 
- release 1.0 - initial release

Conclusión

Envolvimos nuestro contenido personalizado en paquetes rpm versionados. Esto significa que no quedan versiones anteriores dispersas entre los sistemas, todo está en su lugar, en la versión que instalamos o actualizamos. RPM brinda la capacidad de reemplazar elementos antiguos necesarios solo en versiones anteriores, puede agregar dependencias personalizadas o proporcionar algunas herramientas o servicios en los que se basan nuestros otros paquetes. Con esfuerzo, podemos empaquetar casi cualquier contenido personalizado en paquetes rpm y distribuirlo en nuestro entorno, no solo con facilidad, sino también con coherencia.