El documento describe la instalación y configuración de Puppet para gestionar de forma centralizada una nube de servidores. Se instala Puppetmaster en un servidor central y el agente Puppet en cada servidor. Puppetmaster firma certificados SSL para cada servidor, permitiendo la comunicación segura y la sincronización de configuraciones entre el servidor central y los demás nodos de la nube.
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
Gestion de nubes de servidores
1. UNIVERSIDAD DE EL SALVADOR
FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE
DEPARTAMENTO DE INGENIERA
CATEDRA:
PROTOCOLOS DE COMUNICACIÓN
CATEDRÁTICO:
ING. JUAN CARLOS PEÑA
TEMA:
GESTIÓN DE NUBES DE SERVIDORES
INTEGRANTES:
BR. GÓMEZ ASCENCIO, CARLOS BENJAMIN
BR. MENDOZA FIGUEROA, HENRY RAFAEL
2. PLANTEAMIENTO DEL PROBLEMA
Luego de un reñido proceso de selección, se la ha contratado como parte del Staff de IT que
gestiona a una nube de servidores web que brindan balanceo de carga a varios sitios web. Esta nube
cuenta con 60 servidores web que usan el mismo software, configurados prácticamente de manera
2. idéntica. Cuando se quiere hacer alguna actualización o cambio en la configuración, se hace de
manera manual en un servidor a la vez, lo que conlleva a inestabilidades, y tiempos muertos debido
a errores humanos en las configuraciones, y el tiempo que conlleva realizar las configuraciones
mismas. Por tanto el primer proyecto que le asignan es buscar una manera de sincronizar los
servidores de manera tal que cuando se realice alguna modificación en alguno de ellos, estas
modificaciones se reflejen en el resto. Además, deberá considerarse que la sincronización deberá
aplicarse únicamente a los hosts que se tengan registrados en las bases de datos de credenciales
(LDAP o Active Directory).
3. SERVIDORES WEB
En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los
usuarios. El término servidor ahora también se utiliza para referirse al ordenador físico en el cual
funciona ese software, una máquina cuyo propósito es proveer datos de modo que otras máquinas
puedan utilizar esos datos.
Este uso dual puede llevar a confusión. Por ejemplo, en el caso de un servidor web, este término
podría referirse a la máquina que almacena y maneja los sitios web, y en este sentido es utilizada
por las compañías que ofrecen hosting o hospedaje. Alternativamente, el servidor web podría
referirse al software, como el servidor de HTTP de Apache, que funciona en la máquina y maneja la
entrega de los componentes de los páginas web como respuesta a peticiones de los navegadores de
los clientes.
3.2 MONTANDO SERVIDOR WEB (DEBIAN)
Para empezar necesitamos conocer la red que nuestro ISP nos proporciona, esto lo averiguamos con
el comando #ifconfig, en nuestro caso la red que utilizaremos sera 192.168.0.0 .
3.2.1 IP ESTATICA
Como primer paso necesitamos configurarle a nuestra tarjeta de red una ip fija o estatica, esto es
porque si vamos a ofrecer servicios a internet deberemos abrir ciertos puertos a nuestro Router, para
poder asignar una direccion X a un puerto X, cosa que no fuera posible con una IP DINAMICA.
Lo haremos editando el archivo interfaces, accediendo asi:
# nano /etc/network/interfaces
y colocar lo siguiente, para el caso nuestro:
auto lo
iface lo inet loopback
iface eth0 inet static
2
3. address 192.168.0.104
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.198.0.255
gateway 192.168.0.100
Con esto ya podemos direccionar un puerto del router a nuestra ip fija.
3.2.2 ACCESO REMOTO CON SSH (SecureShell)
SSH (Secure SHell) es una forma segura con la que vamos a poder conectarnos a nuestro servidor
de manera remota. Podremos conectarnos a el por nuestra red siendo de manera local o desde
Internet.
apt-get update
Seguidamente instalamos el programa para el acceso remoto seguro SSH
apt-get install ssh
Ahora reiniciamos la maquina para ver si arranca bien en el inicio
reboot
Una vez tengamos reiniciada la maquina vamos a conectarnos a ella desde otro ordenador de
nuestra red. Si recordamos el articulo anterior configuramos una IP fija para nuestra tarjeta de red,
así que ahora nos vamos a conectar a esa IP.
Para los usuarios LINUX sera mas facil conectarnos ya que no necesitamos instalar algun
programa. Ejecutamos
#ssh 192.168.0.103 (ip del ordenador al que nos conectaremos remotamente)
El sistema Secure SHell genera una llave de autentificación y si nos equivocamos el sistema nos
beta para no dejarnos pasar mas. Esta es una de las medidas de seguridad que nos ofrece este
programa.
Le indicamos YES …
Luego la contraseña del equipo al que nos conectaremos y asi ya tendremos remotamente control
sobre el equipo de manera local.
3.2.3 INSTALANDO APACHE SERVER
Seguidamente instalaremos el paquete Apache2 y acto seguido el apache2-mpm-prefork:
#apt-get install apache2
#apt-get install apache2-mpm-prefork
3
4. Una vez finalizada la instalación abrimos un navegador en nuestro PC de escritorio e introducimos
la IP del servidor ( en mi caso http://192.168.0.104 ) y veremos el mensaje ( It works! ), algo así:
Despues de instalarlo podemos cambiar el directorio raiz de nuestro servidor, editando el archivo
ubicado en /etc/apache2/sites-available/default.
3.2.4 SOPORTE PARA PHP
Ahora bien vamos a dar soporte PHP5 a nuestro apache 2 y para eso instalamos.
#apt-get install php5 libapache2-mod-php5 php5-common
Nos pregunta si deseamos instalarlo, y todo el asunto le decimos que si, y para asegurarnos que no
hay errores crearemos un archivo .php y lo colocamos en el directorio raiz que asignamos
anteriormente. Ejemplo php5.php y escribirmos lo siguiente:
<?php phpinfo(); ?>
Luego para comprobar en nuestro navegador escribimos http://localhost/php5.php y listo!
3.2.5 INSTALANDO MYSQL Y PHPMYADMIN
Arrancamos nuestro sistema y nos logeamos como ( root ) e instalamos los siguientes paquetes:
#apt-get install mysql-server-4.1 mysql-client-4.1 php4-mysql
Para facilitarnos manejo y la administración de nuestras bases de datos vamos a usar el entorno web
PhpMyAdmin, con este software podremos crear, borrar, modificar, dar permisos, bueno podemos
hacer todo a lo que se refiere a la administración de bases de datos MySQL. Comenzamos la
instalación con:
#apt-get install phpmyadmin
Seguramente recordareis el directorio raíz de nuestro servidor web. Resulta que el programa
phpmyadmin se instala en la ruta /var/www/ de nuestro apache2 por defecto pero nosotros la
vamos a enlazar a /home/usuario/www/ para poder acceder a ella desde un navegador, así que
ahora tendremos que hacer otro enlace simbólico para poder ver el entorno web de phpmyadmin
de la siguiente manera …
#ln -s /var/www/phpmyadmin /home/usuario/www/phpmyadmin
Una vez creado el enlace debemos ver ya el directorio de la aplicación en la raíz de nuestro
4
5. servidor.
Abrimos un navegador e introducimos la dirección http://ipdelservidor/www/phpmyadmin/ ( En
mi caso http://192.168.0.104/www/phpmyadmin/ )como podéis ver en la imagen siguiente:
Daremos click sobre el directorio de phpmyadmin y veras una pantalla como esta:
Con respecto a montar servidores web, nos quedaremos hasta aquí, unicamente con las instalaciones
basicas de un servidor web.
4. BALANCEADOR DE CARGA
El balanceador de carga es capaz de repartir la carga entre varios servidores basándose en el método
Round Robin basado en en Software Libre PEN Load Balancer. Este mismo trata de dar paso a
cada uno de los servidores correlativamente. PEN es capaz de colgar de el y repartir la carga entre
15 servidores como máximo.
5
6. Para su instalacion vamos a tomar en cuenta 3 aspectos importantes :
• Puente de Red o Bridge.
• Balanceo de Carga Con PEN.
• Posibles Usos.
4.1 INSTALANDO NUESTRO BRIDGE.
Ahora vamos a instalarle el software llamado ( bridge-utils ) el cual nos facilita herramientas para
poder montar el puente de red. Lo instalamos con:
#apt-get install bridge-utils
Una vez instalado este software y contando con que no configuramos las tarjetas de red
anteriormente vamos a crear una configuración especifica que montará ( br0 ) como una tarjeta de
red y hará que las cuatro tarjetas actúen como una sola, con una sola dirección IP y de manera
transparente.
Para poder enviar todas las peticiones de un puerto especifico desde el Router hacia un ordenador
en cuestión necesitamos que este tenga una IP fija y no dinámica. Si en vez de cuatro tarjetas tenéis
tres o dos no es problema ya que tan solo tendréis que agregar vuestras interfaces en la linea
( bridge_ports eth0 eth1 eth2 eth3 ). Sabidos estos cuatro términos vamos a editar el archivo
( interfaces ) y después lo configuraremos.
Antes de hacer esto no esta de mas que tengamos una copia de seguridad del archivo existente así
siempre podremos recurrir a la versión existente del archivo en un momento dado. Hacemos la
copia de seguridad con:
#cp /etc/network/interfaces /etc/network/interfacesOK
Luego de realizar la copia modificamos su contenido y agregamos lo siguiente:
uto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.0.100
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.254
bridge_ports eth0 eth1 eth2 eth3
bridge_maxwait 0
Hay que tomar en cuenta que las ips que se utilizan son las de nuestra red, ademas tenemos que
cambiar las interfaces dependiendo de las tarjetas de red que se utilicen, luego guardaremos el
archivo y reiniciaremos la red, asi que tendremos que reiniciara el demonio para cargar las
configuraciones de la siguiente manera:
#etc/init.d/networking restart
Ahora para comprobar que todo fue bien y que se creo el interfaz ( br0 ) con la ip xxx.xxx.xxx.xxxx
6
7. y las demás tarjetas se han quedado sin IP teclearemos el siguiente comando
#ifconfig
4.2 INSTALACION DE PEN
Bien después de tener el puente de red o bridge funcionando vamos a continuar por instalar PEN
en nuestra maquina con:
#apt-get install pen
PEN es tan simple que bajo una linea de comandos podremos ejecutarlo completamente
configurado. Si introducimos ( pen ) en nuestra terminal veremos las opciones simplificadas de las
que dispone:
Una vez instalado vamos lanzaremos a PEN con una simple linea de comandos como esta …
pen -r -a -f -d 192.168.0.100:80 192.168.0.104:80 192.168.1.211:80 192.168.0.105:80
Al final de la carga se queda en espera y muestra una tabla como esta:
7
8. Bien, ahora ya tenemos nuestro balanceador de carga preparado para ir repartiendo peticiones
hacia el puerto 80 entre las IPs de nuestros servidores.
5. TOPOLOGIA UTILIZADA EN LA GESTION DE NUBES DE
SERVIDORES
8
9. 6. INSTALACION Y USO DE PUPPET
6.1 PUPPET
Nos permite manejar varios equipos desde un nodo central mediante definiciones de módulos en
archivos de configuración, que pueden ser paquetes, archivos, servicios, etc, independientemente
de la distribución. Obviamente, homogenizar la distribución a utilizar es preferible para mantener
las mismas versiones y evitar errores en implementaciones de las ramas.
PUPPET es una herramienta que facilita el trabajo de un administrador de sistemas permitiéndole
hacer instalaciones, actualizaciones, cambios de configuraciones, etc... en equipos remotos.
9
10. Puppet se compone de varios elementos:
• Un servidor -> puppetmaster.
• Un servicio para los clientes -> puppetd.
• Un lenguaje declarativo para definir lo que se quiere hacer en los clientes.
• Un sistema para obtener datos de los clientes -> facter.
6.2 INSTALACION DE PUPPET
Para instalar puppet, tendremos que hacer varias cosas:
• Instalar un servidor puppet.
• Configurar el servidor puppet.
• Instalar el cliente puppet en todas las máquinas que queramos administrar.
• Configurar el cliente puppet.
6.2.1 INSTALACION DE UN SERVIDOR PUPPET
Antes de comenzar debemos verificar que nuestras definiciones del host y dominio sean correctas
en todos los equipos, si no tendremos muchos problemas al entablar el dialogo de servidor-cliente.
Revisamos el archivo /etc/hosts donde incluiremos el FQDN para 127.0.1.1
127.0.0.1 localhost
127.0.1.1 carlos.dominio.com gatio
192.168.0.105 henry.dominio.com
Debido a que no poseemos un servidor DNS incluiremos tambien las direcciones IP de nuestros
nodos tanto en el servidor como en el cliente.
El FQDN debe ser incluido tambien en /etc/hostname, quedando nuestro archivo:
carlos.dominio.com
Despues de realizar los cambios ejecutamos:
# /etc/init.d/hostaname.sh
Comprobamos los resultados con #hostname:
carlos.dominio.com
Luego con #dnsdomainname
dominio.com
Con esto previamente establecido podemos iniciar la instalacion, Debian incluye en su repositorio a
10
11. puppetmaster y puppet, los cuales seran instalados dependiendo del objetivo, puppetmaster se
instalara en nuestro servidor y puppet en nuestros clientes.
Como metodo de autentificación con los clientes, puppetmaster utiliza llaves SSL, las cuales
deberemos firmar para cada uno de ellos. Para el manejo de los certificados existe un script llamado
puppetca con el cual aparte de firmar llaves podremos revocarlas o renovarlas si es necesario, tanto
para cada cliente independiente o todos juntos.
Instalando puppetmaster en nuestro servidor ejecutamos la linea de codigo:
#apt-get install puppetmaster
#apt-get install puppetmastered --n - daemonize -vd
Donde -v es para desplegar todos los mensajes generados (verbose) y -d para indicar que estamos en
modo debug asi que queremos mas mensajes. Sin problemas debemos obtener
notice: Starting Puppet master version 2.6.2
Lo siguiente es firmar los certificados para cada cliente que lo solicite, asi que despues de instalar
puppet en nuestros clientes y verificar el FQDN en cada uno de ellos ejecutaremos:
(CLIENTES)
# apt-get install puppet
#apt-get install --server henry.dominio.com -tvd -w 10
donde -server indica el FQDN del servidor, -t para modo de pruebas, y -w para indicar que
esperaremo 10 segundos para que el servidor firme nuestro certificado.
Al ejecutarlo podemos observar en el servidor:
notice: henry.dominio.com has a waiting certificate request
Ahora firmamos la llave, y ejecutamos:
(SERVIDOR)
#puppetca -l
Para listar todas las peticiones pendientes de ser firmadas donde debemos ver a la que generaremos
desde henry.dominio.com, si es correctamente procedemos a ejecutar:
(SERVIDOR)
#puppetca -sign henry.dominio.com
para aceptar la peticion, donde observamos:
notice: Signed certificate request for henry.dominio.com
Por ahora dejaremos nuestros clientes listos para iniciar, primero haremos posible ejecutar los
scripts de inicializacion para puppet en /etc/default/puppet (en servidor y clientes)
#nano /etc/default/puppet
11
12. #Start puppet on boot?
START=yes
#Startup options
DAEMONS_OPTS=""
Por ultimo definimos la configuracion del cliente en /etc/puppet/puppet.conf, la direccion d e
nuestro servidor (solo para los clientes):
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=/var/lib/puppet/templates
certname="Nombre de Servidor"
autosign=false
6.2.2 CREAR ESQUELET MANIFEST
Si no estuviera creado el directorio de clases y/o el directorio manifests, lo creamos:
# mkdir -p /etc/puppet/manifests/classes
6.2.3 CREAR EL FICHERO SITE.PP
Este es un fichero de control fundamental del servidor puppet. Podríamos crearlo con:
# touch /etc/puppet/manifests/site.pp
Supongamos que en el directorio /etc/puppet/manifests/classes/ hemos creado un fichero llamado
test_class.pp con el siguiente contenido:
class test_class {
file {"/tmp/fichero.test":
ensure => present,
mode => 744,
owner => root,
group => root
}
}
En este archivo hemos definido la clase test_class, que contiene una definición del tipo file que se
puede leer de la siguiente forma: Debe existir el archivo /tmp/fichero.test con permisos 744 y debe
pertenecer al usuario root y al grupo root.
Existen otros tipos de definición que podemos utilizar y que son particularmente útiles. Por
ejemplo:
• package, para el manejo de de software.
• exec, para ejecutar comandos en el sistema del cliente.
• cron, para programar tareas en el sistema del cliente.
• Existen muchos más tipos de definiciones.
Podemos añadir un contenido básico al fichero site.pp, y utilizar en él la clase test_class creada en
12
13. anteriormente:
# Importamos todas las clases del directorio
classes
import "classes/*.pp"
# En node default incluimos las tareas para todos los nodos
node default {
include test_class
}
# Definimos un nodo de pruebas
node "a25-pro" inherits default {
# include clase_a_probar
}
Crearemos las tareas en el directorio /etc/puppet/manifests/classes y las llamaremos con include en
el nodo de pruebas. Las ejecutaremos. Y si todo va bien, pasaremos la tarea al nodo default para que
se ejecute en todos los clientes.
Una vez terminada la configuración del servidor puppet, si no está iniciado, lo iniciamos:
# /etc/init.d/puppetmaster start
No es necesario reiniciarlo después de hacer cambios en los ficheros de configuración. El servidor
está monitoreando los archivos de configuración y los reelerá a los pocos segundos de ser
modificados.
6.3 FUNCIONAMIENTO DE PUPPET Y COMPROBACIONES
No olvidemos que, para que el sistema funcione, deben estar iniciados puppetmaster en el servidor
y puppet en el cliente. Si no lo están, los iniciamos:
#/etc/init.d/puppetmaster start (en el servidor)
#/etc/init.d/puppet start (en el cliente)
Si hubiera algún problema en el funcionamiento, lo mejor es echar un vistazo a los logs, que se
encuentran almacenados en /var/log/puppet
El tiempo predeterminado de contacto del cliente con el servidor, al instalar el sistema, es de 30
minutos, cosa que podemos cambiar. Por cierto, el tiempo hay que indicarlo en segundos.
Para probar si una tarea se ejecuta correctamente en un cliente, paramos puppet y ejecutamos
puppetd -t:
#/etc/init.d/puppet stop
#puppetd -t
Una vez comprobado que las tareas se han ejecutado, volvemos a iniciar el servicio:
13
14. #/etc/init.d/puppet start
No es necesario reiniciar puppet ni puppetmaster después de hacer cambios en los ficheros de
configuración. El servidor está monitoreando los archivos de configuración y los reelerá a los pocos
segundos de ser modificados.
7. ALMACENAMIENTO DE LA INFORMACION DE NODO EN LDAP
Por defecto, puppetmasterd busca nodos en sus manifiestos normal, pero puede además o en lugar
de tener que buscar en el LDAP. Esto funciona especialmente bien si usted ya está almacenando la
información de su anfitrión en LDAP.
PORQUE HACER ESTO?
Existen múltiples beneficios a los nodos de almacenamiento en LDAP en lugar de utilizar
marionetas incorporado en el nodo de apoyo:
• Otras aplicaciones pueden acceder fácilmente a los mismos datos
• Todos los atributos en los nodos de LDAP son asignados como variables en la configuración
de marionetas, así como los hechos, por lo que usted puede configurar fácilmente los
atributos de las clases individuales
• Es sencillo para permitir que otras aplicaciones para modificar estos datos para configurar
los nodos (por ejemplo, como parte de un proceso de implementación), lo que es más fácil
apoyar a la generación de configuraciones de PUPPET.
7.1 PUPPET PRE-RUBY Y LDAP VALIDATION
Puede ejecutar las siguientes pruebas para asegurarse de que la Biblioteca Ruby-LDAP y el
software de LDAP están configurados correctamente:
#ruby -rldap -e 'puts :installed'
Si esto vuelve instalado, entonces usted puede intentar:
#ruby -rpuppet -e 'p Puppet.features.ldap?'
Estos son, básicamente, hacer lo mismo, por lo que sea que ambos tienen éxito o fracasan los dos, y
si tanto éxito, entonces los nodos LDAP debería funcionar.
7.2 LO ATRIBUTOS DEL NODO
Como se ha mencionado, todos los atributos devueltos por los nodos de LDAP o nodos padre será
asignado como una variable en las configuraciones de títeres durante la compilación. Atributos con
varios valores, se creará como matrices. Atributo PuppetVar permite pasar variables a un nodo.
Tenga en cuenta variables no pueden tener espacio en el par nombre / valor o entre comillas.Como
ejemplo, tomemos los siguientes nodos de LDAP simple:
dn: cn=basenode,ou=Hosts,dc=madstop,dc=com objectClass: device objectClass:
ipHost objectClass: puppetClient objectClass: top cn: basenode environment:
production ipHostNumber: 192.168.0.1 description: The base node puppetClass:
14
15. baseclass puppetVar: config_exim=true puppetVar:
config_exim_trusted_users=lludwig,lak,joe dn:
cn=testserver,ou=Hosts,dc=madstop,dc=com objectClass: device objectClass: ipHost
objectClass: puppetClient objectClass: top cn: testserver environment: testing
ipHostNumber: 192.168.0.50 description: My test server l: dc1 puppetClass:
testing puppetClass: solaris
En este caso, el resultado final para el nodo será la siguiente (se muestra como YAML):
:objectClass: - device - ipHost - puppetClient - top :cn: testserver
:environment: testing :description: My test server :l: dc1 :classes: - testing -
solaris :dn: cn=testserver,ou=Hosts,dc=madstop,dc=com
7.3 MODIFICAR EL ESQUEMA LDAP
En primer lugar, tiene que proporcionar el esquema de marionetas en el servidor LDAP.Usted
puede encontrar el esquema de Puppet en Git. Colocar este esquema en el directorio de esquema, en
Debian, por ejemplo, esto sería / etc / ldap / schema. Recomiendo mantener el nombre
puppet.schema.
Con el archivo de esquema en su lugar, modificar su slapd.conf para cargar este esquema añadiendo
a la lista de archivos de esquema cargado:
#include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema
#include /etc/ldap/schema/nis.schema include
#/etc/ldap/schema/inetorgperson.schema
#include /etc/ldap/schema/puppet.schema
Reiniciar el servidor, asegurándose de que se trata de una copia de seguridad, y eso es todo.
7.4 CARGANDO LOS NODOS LDAP
En mi opinión, el espacio sigue siendo la herramienta LDAP deprimente de repuesto.Yo
generalmente uso el mío ldapsh herramienta de gestión de LDAP, pero que no funciona bien para la
carga de datos. Sin embargo usted decide cargar los datos, es necesario crear entradas de host (por
lo general las entradas de dispositivos, probablemente con ipHost como una clase auxiliar) y luego
añadir los datos de marionetas.Esto es lo que mi definición de estación de trabajo se ve como en
LDAP:
dn: cn=culain,ou=Hosts,dc=madstop,dc=com objectClass: device objectClass: ipHost
objectClass: puppetClient objectClass: top cn: culain environment: production
ipHostNumber: 192.168.0.3 puppetclass: webserver puppetclass: puppetserver
puppetclass: mailserver parentnode: basenode
7.5 CONFIGURACION DE PUPPET PARA USAR LDAP
Una vez que usted tiene los datos en LDAP, sólo tiene que configurar de marionetas a buscar allí.
Es casi siempre puppetmasterd que se busca en LDAP así que tenemos que configurar el
puppetmasterd] sección del archivo de configuración puppet.conf. En la versión de marionetas 0,24
y más tarde, esto significa la selección de la terminal de nodo adecuado, la opción ldapnodes
anterior es totalmente obsoleto y no debería ser utilizado. Para los nodos de LDAP que usar LDAP
15
16. como el término en la opción de configuración node_terminus:
[puppetmasterd] node_terminus = ldap ldapserver = ldapserver.yourdomain.com
ldapbase = dc=puppet
Sólo hay un ajustes necesarios: ldapbase de dónde buscar para los nodos de LDAP. Es posible que
también desee especificar ldapserver, ya que el valor predeterminado es ldap, lo que probablemente
no va a funcionar para la mayoría de la gente.
En otras palabras, permite la búsqueda de nodos de LDAP mediante el establecimiento de la
node_terminus a LDAP, y luego proporcionar la información necesaria para que funcione. Es una
buena idea especificar en realidad el árbol de los Ejércitos como su base de búsqueda (por ejemplo,
ldapbase = ou = Hosts, dc = madstop, dc = com), pero mi base de datos es lo suficientemente
pequeño que no tiene importancia.
Con la versión 0.23.2 y luego que no es necesario reiniciar el demonio puppetmasterd pero
probablemente es sensible.
16