Redhat / Centos / Almalinux

Unificar scripts personalizados en todo el sistema con RPM en Red Hat/CentOS

Unificar scripts personalizados en todo el sistema con RPM en Red Hat/CentOS

Objetivo

Nuestro objetivo es crear paquetes de RPM con contenido personalizado, unificar scripts en cualquier cantidad de sistemas, incluidos los versiones, la implementación y el desacuerdo.

Sistema operativo y versiones de software

  • Sistema operativo: Red Hat Enterprise Linux 7.5
  • Software: rpm-construcción 4.11.3+

Requisitos

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

Dificultad

MEDIO

Convenciones

  • # - requiere que los comandos de Linux dados se ejecuten con privilegios raíz directamente como un usuario raíz o mediante el uso de sudo dominio
  • ps - Dados los comandos de Linux para ser ejecutados como un usuario regular no privilegiado

Introducción

Una de las características principales de cualquier sistema de Linux es que están construidos para la automatización. Si es posible que una tarea necesite ser ejecutada más de una vez, incluso con alguna parte de ella cambia en la próxima ejecución, un sistema de sistemas está provisto de innumerables herramientas para automatizarlo, desde simple caparazón Los scripts se ejecutan a mano a mano (eliminando así errores de error tipográfico, o solo guarda algunos golpes de teclado) a sistemas complejos de scripts donde las tareas se ejecutan desde cron En un tiempo 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 rico conjunto de herramientas de hecho se suma a la productividad, hay una trampa: como un sysadmin, escribe un script útil en un sistema, que demuestra ser útil en otro, por lo que copia el script sobre. En un tercer sistema, el script 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. Generalización en mente, extiende el script para proporcionar la nueva característica y completar la tarea para la que se escribió también. Ahora tiene dos versiones del script, el primero está en los dos primeros sistemas, el segundo en el tercer sistema.

Tiene 1024 computadoras que se ejecutan en el centro de datos, y 256 de ellas necesitarán parte de la funcionalidad proporcionada por ese script. Con el tiempo tendrá 64 versiones del script por todas partes, cada versión haciendo su trabajo. En la siguiente implementación del sistema, necesita una función que recuerde que codificó en alguna versión, pero cuál? Y en qué sistemas están?

En los sistemas basados ​​en RPM, como Red Hat Favors, un Sysadmin puede aprovechar el Administrador de paquetes para crear el pedido en el contenido personalizado, incluidos los scripts de shell simples que pueden no proporcionar más, pero las herramientas que el administrador escribió para conveniencia.

En este tutorial construiremos un RPM personalizado para Red Hat Enterprise Linux 7.5 que contienen dos intento guiones, parselogs.mierda y plenews.mierda 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 mayores y menores

En general, la versión menor y mayor de la máquina de compilación debe ser la misma que los sistemas que el paquete debe implementarse, así como la distribución para garantizar la compatibilidad. Si hay varias versiones de una distribución dada, o incluso diferentes distribuciones con muchas versiones en su entorno (oh, alegría!), debe configurar máquinas de compilación para cada. Para acortar el trabajo, puede configurar el entorno de compilación para cada distribución y cada versión principal, y tenerlos en la versión menor más baja existente en su entorno para la versión principal dada. Porque no necesitan ser máquinas físicas, y solo necesitan funcionar a la hora de construcción, para que pueda usar máquinas o contenedores virtuales.

En este tutorial, nuestro trabajo es mucho más fácil, solo implementamos dos scripts que no tienen dependencias (excepto intento), entonces construiremos noarch paquetes que representan "no dependientes de la arquitectura", tampoco especificaremos la distribución del paquete para la que está construida. De esta manera podemos instalarlos y actualizarlos en cualquier distribución que use rpm, y a cualquier versión, solo necesitamos asegurarnos de que la máquina de compilación construcción de rpm El paquete está en la versión más antigua del entorno.

Establecer un entorno de construcción

Para construir paquetes de RPM personalizados, necesitamos instalar el construcción de rpm paquete:

# yum instalación rpm-construcción

De ahora en adelante, nosotros no utilice raíz usuario, y por una buena razón. Los paquetes de construcción no requieren raíz privilegio, y no quieres romper tu máquina de construcción.

Construyendo la primera versión del paquete

Creemos la estructura del directorio necesaria para la construcción:

$ mkdir -p rpmbuild/especificaciones

Nuestro paquete se llama Admin-Scripts, versión 1.0. Creamos un specfile que especifica los metadatos, el contenido y las tareas realizadas por el paquete. Este es un archivo de texto simple que podemos crear con nuestro editor de texto favorito, como VI. El previamente instalado rpmbuild El paquete llenará su specfile vacío con datos de plantilla si usa VI Para crear uno vacío, pero para este tutorial considere la especificación a continuación llamada Scripts-Script-1.0.Especificaciones:

Nombre: Admin-Scripts Versión: 1 Release: 0 Resumen: Foobar Inc. Departamento. Admin Scripts Packager: John Doe Group: Aplicación/Otra licencia: GPL URL: www.foobar.com/admin-scripts Source0: %name- %versión.alquitrán.GZ Buildarch: Noarch %Descripción Paquete Instalación de la última versión Los scripts de administración utilizados por el departamento de TI. %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/ %limpio rm -rf $ rpm_build_root % %defattr. (-, raíz, raíz,-) %dir/usr/local/sbin/usr/local/sbin/parselogs.sh/usr/local/sbin/pullnews.sh %doc %ChangeLog * mié 1 de agosto de 2018 John Doe - Versión 1.0 - Liberación inicial
Copiar

Coloque la especificación en el rpmbuild/spec Directorio que creamos anteriormente.

Necesitamos las fuentes mencionadas en el specfile - En este caso los dos scripts de shell. Creemos el directorio para las fuentes (llamado como el nombre del paquete agregado con la versión principal):

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

Y copiar/mover los scripts en él:

$ ls rpmbuild/fuentes/admin-scripts-1/scripts/parselogs.SH PULLNEWS.mierda
Copiar

Como este tutorial no se trata de scripting de shell, el contenido de estos scripts es irrelevante. Ya que crearemos una nueva versión del paquete y el plenews.mierda es el script con el que demostraremos, su fuente en la primera versión es la siguiente:

#!/bin/bash echo "News Tire" Salida 0
Copiar

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

CHMOD +X RPMBUILD/Sources/Admin-Scripts-1/Scripts/*.mierda


Ahora creamos un alquitrán.GZ Archivo desde la fuente en el mismo directorio:

CD rpmbuild/ fuentes/ && tar -czf admin-scripts-1.alquitrán.GZ Admin-Scripts-1
Copiar

Estamos listos para construir el paquete:

RPMBUILD --BB RPMBUILD/SPECS/Admin-Scripts-1.0.Especificaciones

Obtendremos algo de salida sobre la compilación, y si algo sale mal, se mostrarán errores (por ejemplo, faltar archivo o ruta). Si todo va bien, nuestro nuevo paquete aparecerá en el directorio RPMS generado de forma predeterminada en 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 suministramos anteriormente:

$ rpm -qpi rpmbuild/rpms/noarch/admin-scripts-1-0.noarch.RPM Nombre: Admin-Scripts Versión: 1 Release: 0 Arquitectura: Noarch Fecha de instalación: (no instalada) Grupo: Aplicación/Otro Tamaño: 78 Licencia: GPL Firma: (Ninguna) Fuente RPM: Admin-Scripts-1-0.SRC.Fecha de construcción de RPM: 2018. ago. 1., Miércoles 13.27.34 CEST BUSCULS Host: Build01.foobar.Re -reubicación: (no reubicable) Packager: John Doe URL: www.foobar.com/admin-scripts Resumen: Foobar Inc. Departamento. Scripts de administración Descripción: Instalación del paquete de la última versión Los scripts de administración utilizados por el departamento de TI.
Copiar


Y de causa podemos instalarlo (con raíz privilegios):

Instalación de scripts personalizados con RPM

A medida que instalamos los scripts en un directorio que está en cada usuario $, Puede ejecutarlos como cualquier usuario en el sistema, desde cualquier directorio:

$ Pullnews.SH News Tiró
Copiar


El paquete se puede distribuir tal como está, y se puede impulsar a los 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 es.

Construyendo otra versión del paquete

Nuestro paquete y los scripts extremadamente útiles se vuelven populares en poco tiempo, considerando que son accesibles en cualquier lugar con un simple yum instala los script de administrador Dentro del medio ambiente. Pronto habrá muchas solicitudes para algunas mejoras: en este ejemplo, muchos votos provienen de usuarios felices de que el plenews.mierda Debería imprimir otra línea en la ejecución, esta característica guardaría toda la compañía. Necesitamos construir 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 Sysadmins en nuestra organización ya confían en él en gran medida.

Primero cambiamos la fuente del plenews.mierda En las fuentes a algo aún más complejo:

#!/bin/bash echo "News sacó" Echo "otra línea impresa" Salida 0

Necesitamos recrear el alquitrán.GZ con el nuevo contenido de origen: podemos usar el mismo nombre de archivo que la primera vez, ya que no cambiamos la versión, solo se lanza (y así el Fuente0 La referencia seguirá siendo válida). Tenga en cuenta que primero eliminamos el archivo anterior:

CD rpmbuild/ fuentes/ && rm -f admin-scripts-1.alquitrán.gz && tar -czf admin-scripts-1.alquitrán.GZ Admin-Scripts-1
Copiar

Ahora creamos otra FILE con un número de liberación más alto:

CP RPMBuild/Specs/Admin-Scripts-1.0.SPEC RPMBUILD/SPECS/Admin-Scripts-1.1.Especificaciones
Copiar

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

Nombre: Admin-Script Versión: 1 Lanzamiento: 1 Resumen: Foobar Inc. Departamento. Admin Scripts Packager: John Doe Group: Aplicación/Otra licencia: GPL URL: www.foobar.com/admin-scripts Source0: %name- %versión.alquitrán.GZ Buildarch: Noarch %Descripción Paquete Instalación de la última versión Los scripts de administración utilizados por el departamento de TI. %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/ %limpio rm -rf $ rpm_build_root % %defattr. (-, raíz, raíz,-) %dir/usr/local/sbin/usr/local/sbin/parselogs.sh/usr/local/sbin/pullnews.sh %doc %ChangeLog * Mié 22 de agosto de 2018 John Doe  - Versión 1.1 - Pullnews.SH V1.1 imprime otra línea * Mié 1 de agosto de 2018 John Doe - Lanzamiento 1.0 - Liberación inicial

Todo hecho, podemos crear otra versión de nuestro paquete que contenga el script actualizado. Tenga en cuenta que hacemos referencia a la Filea de Speces con la versión más alta como la fuente de la compilación:

RPMBUILD --BB RPMBUILD/SPECS/Admin-Scripts-1.1.Especificaciones

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
Copiar

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

Actualización de scripts personalizados con RPM

Y nuestros sysadmins pueden ver que la solicitud de función se aterriza en esta versión:

RPM -Q -CHANGELOG Admin -Scripts * Mié 22 de agosto de 2018 John Doe -Versión 1.1 - Pullnews.SH V1.1 Imprime otra línea * mié 01 de agosto de 2018 John Doe - Versión 1.0 - Liberación inicial

Conclusión

Envolvemos nuestro contenido personalizado en paquetes RPM versionados. Esto significa que no hay versiones más antiguas que queden dispersas en los sistemas, todo está en su lugar, en la versión que instalamos o actualizamos. RPM brinda la capacidad de reemplazar las cosas antiguas necesarias solo en versiones anteriores, puede agregar dependencias personalizadas o proporcionar algunas herramientas o servicios en los que confíen nuestros otros paquetes. Con el esfuerzo, podemos empacar casi cualquiera de nuestro contenido personalizado en paquetes de RPM y distribuirlo en nuestro entorno, no solo con facilidad, sino con consistencia.

Tutoriales de Linux relacionados:

  • Cosas para instalar en Ubuntu 20.04
  • Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
  • Archivos de configuración de Linux: los 30 principales más importantes
  • Una introducción a la automatización, herramientas y técnicas de Linux
  • Descarga de Linux
  • ¿Puede Linux obtener virus?? Explorando la vulnerabilidad de Linux ..
  • Cosas que hacer después de instalar Ubuntu 22.04 Jellyfish de Jammy ..
  • La mejor distribución de Linux para desarrolladores
  • Ubuntu 20.04 Guía
  • Cómo migrar de Centos a Almalinux