Articles avec les mots clés ’centos’
Installation de GLPI sous CentOS 7
GLPI (Gestionnaire Libre de Parc Informatique) est une solution libre de gestion de parc informatique. Il s’agit d’une application Web écrite en PHP où les différents éléments (matériel, logiciels, licences, contrats, interventions, …) constituant votre parc peuvent être organisés et gérés.
Dans cette documentation, nous allons installer la dernière version stable de GLPI (0.90.1) sur une distribution CentOS 7 de manière fonctionnelle. Cette procédure d’installation ne sera donc ni optimisée, ni sécurisée. Nous aurons besoin d’un serveur Web (Apache/HTTPD), d’une base de données de type MySQL (MariaDB remplace MySQL sous CentOS 7) et de PHP.
A noter qu’un paquet glpi est également disponible dans le dépôt EPEL (Extra Packages for Enterprise Linux). Nous n’utiliserons pas ce dépôt.
Ces opérations sont à réaliser en tant qu’utilisateur root.
– Désactivez SELinux de façon permanente à travers son fichier de configuration : vi /etc/selinux/config
SELINUX=disabled
– La prise en compte de ce changement nécessite un redémarrage de la machine : reboot
GLPI requiert l’installation d’extensions PHP (CType, FileInfo, GD, JSON, Mbstring, MySQLi, Session, Zlib). Certaines extensions sont incluses directement dans le paquet php et d’autres doivent être installées explicitement. Dans le cas où vous souhaiteriez mettre en place une méthode d’authentification externe, d’autres extensions PHP seront à prévoir. Dans notre exemple, nous utiliserons une base locale de comptes pour l’authentification.
– Installez les paquets suivants (serveur Apache/HTTPD, PHP, extensions PHP, serveur MariaDB et l’utilitaire wget) : yum install httpd php php-mysql php-gd php-mbstring mariadb-server wget
– Lancez le serveur MariaDB au démarrage de la machine : systemctl enable mariadb
– Lancez le serveur MariaDB : systemctl start mariadb
– Exécutez l’utilitaire mysql_secure_installation pour sécuriser l’installation de MariaDB : mysql_secure_installation
> Enter current password for root (enter for none): > OK, successfully used password, moving on... > Set root password? [Y/n] Y > New password: > Re-enter new password: > Remove anonymous users? [Y/n] Y > Disallow root login remotely? [Y/n] Y > Remove test database and access to it? [Y/n] Y > Reload privilege tables now? [Y/n] Y
Pour commencer, l’utilitaire mysql_secure_installation nous demande le mot de passe actuel de l’utilisateur root (celui de MariaDB). Ce mot de passe est vide par défaut. Ensuite, plusieurs questions vous sont posées pour sécuriser l’installation de MariaDB : affecter un mot de passe à l’utilisateur root, supprimer les connexions anonymes, désactiver la possibilité à l’utilisateur root de se connecter à distance, supprimer la base de données prédéfinie test et recharger les privilèges des tables.
GLPI nécessite la création d’une base de données spécifique à son utilisation.
– Lancez l’invite de commandes de MariaDB/MySQL : mysql -u root -p
> Enter password: > MariaDB [(none)]> CREATE DATABASE glpidb; > MariaDB [(none)]> GRANT ALL PRIVILEGES ON `glpidb` .* TO 'glpiuser'@'localhost' IDENTIFIED BY 'MotDePasse'; > MariaDB [(none)]> quit
Le mot de passe de l’utilisateur root est demandé. Il s’agit d’entrer le mot de passe que vous avez choisi précédemment. La première commande SQL créé la base de données glpidb. La deuxième commande créé et associe l’utilisateur glpiuser avec cette base de données en lui octroyant les autorisations adéquates. Vous êtes bien entendu encouragé à modifier le mot de passe de l’utilisateur glpiuser.
Nous allons maintenant configurer le serveur Web pour les besoins de GLPI.
– Éditez le fichier de configuration de PHP afin de préciser le fuseau horaire : vi /etc/php.ini
[Date] date.timezone = "Europe/Paris"
Lors de l’installation de GLPI, le script d’installation vérifie que les répertoires config et files ne soient pas accessibles.
– Créez le fichier de configuration pour interdire l’accès aux répertoires config et files : vi /etc/httpd/conf.d/glpi.conf
<Directory "/var/www/html/glpi/config">
AllowOverride None
Require all denied
</Directory>
<Directory "/var/www/html/glpi/files">
AllowOverride None
Require all denied
</Directory>
– Lancez le serveur Apache/HTTPD au démarrage de la machine : systemctl enable httpd
– Lancez immédiatement le serveur Apache/HTTPD : systemctl start httpd
CentOS 7 introduit le concept de zone réseau avec le pare-feu firewalld. Ce qui permet d’appliquer des règles en fonction de la zone réseau sur lequel on se trouve. Par défaut, la zone réseau est nommée public. Nous allons autoriser le service http pour la zone public de manière permanente et recharger les règles.
– firewall-cmd –permanent –zone=public –add-service=http
– firewall-cmd –reload
Nous allons passer à l’installation de GLPI.
– Placez-vous dans le répertoire suivant : cd /usr/local/src/
– Téléchargez la dernière version stable de GLPI (0.90.1 lors de l’écriture cette documentation) à l’aide de l’utilitaire wget : wget https://github.com/glpi-project/glpi/releases/download/0.90.1/glpi-0.90.1.tar.gz
– Décompressez l’archive de GLPI à la racine des documents du serveur Web : tar -xzvf glpi-0.90.1.tar.gz -C /var/www/html/
– Modifiez le propriétaire de manière récursive sur le répertoire de GLPI : chown -R apache:apache /var/www/html/glpi/
A l’aide de votre navigateur Web, vous devez entrer l’adresse du serveur Web suivi de glpi (http://xxx.xxx.xxx.xxx/glpi/). Un assistant vous guide dans l’installation de GLPI.
Sélectionnez la langue française dans la liste déroulante.
Acceptez la licence d’utilisation.
Une nouvelle installation complète doit être choisie.
Plusieurs tests sont effectués pour vérifier si les extensions PHP et la configuration sont conformes aux besoins de GLPI.
Indiquez les paramètres de connexion à la base de données.
Sélectionner la base de données existante glpidb.
Les différentes tables sont alors créées dans cette base de données.
L’assistant vous indique les comptes utilisateurs prédéfinis.
– Supprimez le script d’installation de GLPI : rm -f /var/www/html/glpi/install/install.php
Vous pouvez maintenant vous authentifier à l’interface Web de GLPI avec l’utilisateur glpi dont le mot de passe par défaut est aussi glpi.
Depuis le menu Administration, et le sous-menu Utilisateurs, vous pouvez modifier les mots de passe attribués aux utilisateurs prédéfinis (glpi, post-only, tech et normal).
Puppet : une première configuration simple
Nous partirons dans la configuration présentée dans l’article précédent sur Puppet.
Pour rappel, Puppet est un logiciel permettant de gérer les configurations de serveurs/machines esclaves depuis un serveur maître appelé puppetmaster. Un agent, appelé puppet agent, est installé sur chaque machine esclave (appelée nœud). A intervalle régulier, l’agent se connecte au puppetmaster et vérifie la configuration actuelle du nœud par rapport à la configuration de référence définie sur le puppet master pour ce nœud. En fonction des différences de configurations constatées, l’agent modifie la configuration du nœud pour la rendre identique à celle définie sur le puppetmaster.
Dans notre exemple, nous avons un serveur puppetmaster fonctionnant sous Centos 6 et un nœud installé sous Ubuntu exécutant l’agent puppet.
La configuration globale de puppet est effectuée dans le répertoire /etc/puppet/ sur le puppetmaster.
La structure du répertoire /etc/puppet est la suivante :
. |-- auth.conf |-- fileserver.conf |-- manifests | |-- nodes.pp | `-- site.pp |-- modules |-- puppet.conf
Configuration des autorisations
Le fichier auth.conf permet de paramétrer les autorisations d’accès entre les nœuds et le puppetmaster (par l’api REST). Son contenu, par défaut, est le suivant :
# Allow authenticated nodes to retrieve their own catalogs: path ~ ^/catalog/([^/]+)$ method find allow $1 # Allow authenticated nodes to access any file services --- in practice, this results in fileserver.conf being consulted: path /file allow * # Allow authenticated nodes to access the certificate revocation list: path /certificate_revocation_list/ca method find allow * # Allow authenticated nodes to send reports: path /report method save allow * # Allow unauthenticated access to certificates: path /certificate/ca auth no method find allow * path /certificate/ auth no method find allow * # Allow unauthenticated nodes to submit certificate signing requests: path /certificate_request auth no method find, save allow * # Deny all other requests: path / auth any
Bien évidemment, il est possible de remplacer allow * par allow 192.168.0.* ou allow *.be-root.com.
Le fichier fileserver.conf permet de gérer les autorisations d’accès au serveur de fichier de puppet.Dans notre exemple, nous n’utiliserons le transfert de fichiers qu’a travers les modules. Le contenu de ce fichier est alors le suivant :
[modules]
allow 192.168.0.*
Enfin, le fichier de configuration globale puppet.conf a été crée dans le précédent article.
Définition du site et des noeuds
Par défaut, puppet va lire la configuration globale dans le fichier de site /etc/puppet/manifests/site.pp.
Dans ce fichier, nous allons y mettre :
import "nodes.pp"
$puppetserver="puppet.be-root.com"
# Configuration du Filebucket
filebucket { "main":
server => puppet,
path => false,
}
File { backup => main }
La première ligne permet d’importer le fichier nodes.pp qui contiendra la définition des configurations de tous les nœuds. Nous pourrions très bien, en fonction des besoins organisationnels, rajouter d’autres clauses import et ainsi séparer la configuration des hôtes dans plusieurs fichiers.
La seconde ligne contient le fqdn du serveur puppet. La fin du fichier permet de configurer le filebucket. Le filebucket est un service permettant d’avoir une copie de sauvegarde des fichiers modifiés ou remplacés sur les nœuds.
Dans notre exemple, nous voulons installer le service openssh sur le nœud poste-client.
Nous allons donc définir le noeud poste-client et lui affecter le module ssh que nous définirons plus tard.
Voici donc le contenu du fichier /etc/puppet/manifest/nodes.pp :
node 'poste-client.be-root.com' {
include ssh
}
Rappel : Pour connaitre le nom du poste tel qu’il est identifié par le puppetmaster, on peut utiliser la commande :
puppetca list --all
Il nous est bien sûr possible de créer par la suite d’autres modules permettant d’autres actions de configuration et le rajouter les clauses include correspondantes dans la définition de l’hôte.
Dans cette configuration, nous allons assigner les modules hôte par hôte. Nous pouvions, si nous avions voulu une configuration globale pour l’ensemble des hôtes, utiliser le nœud spécial default
node default {
include ssh
}
De même, nous pouvons inclure une notion d’héritage entre les nœuds. Imaginons 2 serveurs web web1.be-root.com, web2.be-root.com et un serveur de mails mail.be-root.com. Sur l’ensemble des 3 serveurs, nous voulons installer ssh et sudo. Sur les serveurs web, nous installerons apache en plus. Sur le serveur de mails, ce sera postfix. La définition des nœuds pourrait alors être :
node base {
include ssh, sudo
}
node /^web\d+\.be-root\.com$/ inherits base {
include httpd
}
node 'mail.be-root.com' inherits base {
include postfix
}
Remarque : plutôt que de définir le nœud correspondant aux serveurs web à l’aide d’une expression régulière, nous aurions pu la définir comme ceci :
node ‘web1.be-root.com’, ‘web2.be-root.com’ inherits base {
Mais revenons à notre cas d’école, dans lequel nous affectons le module ssh
Création du module ssh
Un module est un regroupement de classes, de fichiers et de templates qui servent à configurer un ou plusieurs service sur les nœuds. Les modules sont stockés sous /etc/puppet/modules/nom_du_module.
Dans notre exemple, nous allons créer le module ssh, qui permettra d’installer et de configurer le service openssh.
Nous allons donc créer la structure du répertoire permettant d’accueillir le module :
mkdir -p /etc/puppet/modules/ssh/{files,templates,manifests}
Le répertoire manifests contiendra le fichier init.pp qui est lu en premier lors de l’appel à un module.
Le répertoire files contiendra le fichier un fichier sshd_config à déployer sur les hôtes.
Nous n’utiliserons pas de templates dans cet exemple mais, par convention, nous créons l’ensemble des trois répertoires. Un template est un modèle de fichier de configuration dont le contenu est « dynamique ». Lors du déploiement, il est adapté et modifié en fonction de chaque hôte.
Nous allons donc créer un fichier /etc/puppet/modules/ssh/files/sshd_config :
# Fichier installé par Puppet Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes
Nous allons ensuite créer le fichier /etc/puppet/modules/ssh/manifests/init.pp :
class ssh::install {
package { "openssh":
name => $operatingsystem ? {
/(Red Hat|CentOS|Fedora)/ => "openssh",
Ubuntu => "openssh-server",
default=> "openssh"
},
ensure => latest,
}
}
class ssh::config {
file {"/etc/ssh/sshd_config":
ensure => present,
owner => 'root',
group => 'root',
mode => 0600,
source => "puppet:///modules/ssh/sshd_config",
require=> Class["ssh::install"],
notify => Class["ssh::service"],
}
}
class ssh::service {
service { "sshd":
name => $operatingsystem ? {
/(Red Hat|CentOS|Fedora)/ => "sshd",
Ubuntu => "ssh",
default=> "sshd"
},
ensure => running,
hasstatus => true,
hasrestart => true,
enable => true,
require => Class["ssh::config"],
}
}
class ssh {
include ssh::install, ssh::config, ssh::service
}
Dans ce fichier, nous définissons trois classes ssh::install, ssh::config et ssh:service permettant respectivement d’installer les paquets, de déployer le fichier de configuration sshd_config défini précédemment et de lancer le service.
Enfin, nous définissons la classe principale ssh, qui inclus les trois précédentes.
La classe ssh::install :
Dans cette classe, nous définissons le nom du paquet à installer et nous nous assurons d’avoir la dernière version installée.
Du fait des informations fournies par facter, puppet sait quel gestionnaire de paquets utiliser en fonction de la plateforme (apt, yum, portage, …). La liste des providers supportés se trouve ici.
Dans l’exemple, nous faisons une différenciation du nom du paquet à installer en fonction de la plateforme. Si le paquet à le même nom sur l’ensemble des plateformes gérées, nous pourrions avoir simplement :
class ssh::install {
package { "openssh":
ensure => latest,
}
}
Le mot clé latest permet de s’assurer que la dernière version disponible du paquet est installée. Les autres mots clés possibles sont : present, absent, purged, held, latest.
La classe ssh::config :
Cette classe permet de déployer le fichier de configuration sshd_config placé sous le répertoire files. La clause ensure => present permet de s’assurer de la présence du bon fichier.
La cohérence du fichier sur le client est contrôlée par sa signature md5. Si cette signature diffère de celle du fichier présent sur le serveur, le fichier est à nouveau déployé.
Les autres mots clé possibles pour la clause ensure sont absent,present,file,directory,link
Si la clause ensure => absent est utilisée, alors le fichier et supprimé (s’il s’agit d’un répertoire à supprimer, rajouter recurse => true).
La clause ensure permet également de créer un lien symbolique. Par exemple :
file { "/etc/named.conf":
ensure => link,
target => "/var/named/chroot/etc/named.conf",
}
A noter que la source, définie par puppet:///modules/ssh/sshd_config correspond sur le disque au fichier /etc/puppet/modules/ssh/files/sshd_config. Les autorisations d’accès sont définies dans le fichier /etc/puppet/fileserver.conf
La classe ssh::service :
Cette classe permet de s’assurer que le service ssh est lancé du fait de la clause ensure => running. Les valeurs possibles sont : stopped ou running.
Comme précédemment, le nom du service (qui correspond au nom du script de démarrage /etc/init.d/……) est défini en fonction de la plateforme.
La clause hasrestart permet de définir si le script de démarrage (/etc/init.d/……) accepte l’argument restart. Les valeurs possibles sont true (par défaut) ou false. Si la valeur choisie est false, alors les commandes stop puis start seront utilisées à la place de la commande restart.
La clause hasstatus permet de définir si le script de démarrage (/etc/init.d/……) accepte l’argument status. Les valeurs possibles sont true (par défaut depuis v2.7.0) ou false. Si le script ne permet pas la commande status, alors une clause status fournissant le nom d’une commande à utiliser pour obtenir l’état du service. Cette commande doit avoir un code de retour à 0 si le service fonctionne.
La clause enable => true permet de définir si le service doit être activé au boot. Les valeurs possibles sont true, false, manual.
L’ensemble des valeurs possibles pour les différentes options se trouve dans la documentation officielle.
Vérification côté client :
Sur la machine poste-client, supprimons le paquet openssh-server si celui-ci était déjà installé.
sudo apt-get remove openssh-server sudo rm /etc/ssh/sshd_config
L’agent puppet fonctionnant, au bout d’un certain temps, nous voyons dans le fichier /var/log/syslog.conf des lignes du style :
puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content) content changed '{md5}8caefdd9e251b7cc1baa37874149a870' to '{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8'
puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/mode) mode changed '644' to '600'
puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]/enable) enable changed 'false' to 'true'
puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]) Triggered 'refresh' from 1 events
puppet-agent[11803]: Finished catalog run in 6.26 seconds
Le service ssh est installé, lancé et le fichier sshd_config correspond à celui centralisé sur le serveur puppetmaster.
On remarque que la conformité du fichier est evaluée en fonction de sa signature md5 :
content changed ‘{md5}8caefdd9e251b7cc1baa37874149a870’ to ‘{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8’
Modifions le fichier sshd_config manuellement sur la machine poste-client.
En regardant de nouveau le fichier /var/log/syslog, nous apercevons :
puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content) content changed '{md5}03b526a2efe419608151356c0ce4185d' to '{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8'
puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]) Triggered 'refresh' from 1 events
puppet-agent[11803]: Finished catalog run in 0.92 seconds
Nous nous rendons compte que, puppet ayant remarqué le changement sur le fichier, il va recharger la configuration stockée sur le puppetmaster et cela nous permet donc d’avoir une configuration cohérente.
Cependant, comme indiqué au début de l’article, avant de remplacer le fichier, puppet va effectuer une sauvegarde grace au service filebucket.
Si nous désirons restaurer le fichier que nous avions modifié manuellement, il suffit, sur le poste client, d’éxecuter la commande filebucket en indiquant en argument, la signature md5 du fichier à restaurer et son emplacement :
filebucket restore /etc/ssh/sshd_config 03b526a2efe419608151356c0ce4185d
Bien évidemment, il faut stopper le service puppet sur le poste client sinon, à la prochaine vérification, le fichier sera à nouveau remplacé.
Dans un prochain article, nous détaillerons l’utilisation des templates.
Pour aller plus loin dans l’exploration de puppet, je vous conseille de jeter un oeil au puppet cookbook
Installation de puppet sur Centos 6
Puppet est un logiciel libre permettant la gestion de la configuration de serveurs/machines esclaves depuis un serveur maître appelé puppetmaster.
Dans cet article, nous allons voir comment installer le puppetmaster (v2.6) sur une machine fonctionnant sous centos 6. Nous ne verrons pas comment gérer les configurations des machines esclaves depuis le puppetmaster. Ceci fera parti d’un article ultérieur.
Afin de tester notre configuration, nous installerons également puppet sur une machine cliente tournant sous ubuntu 11.10.
Pour démarrer sur de bonnes bases, il convient de déclarer le FQDN de votre serveur puppetmaster dans le DNS. En effet, Puppet se base énormément sur le DNS et il convient donc d’y déclarer le puppetmaster ainsi que les machines esclaves. De même, il peut être interessant de déclarer un CNAME nommé puppet pointant vers votre serveur puppetmaster. En effet, lorsque aucun serveur n’est spécifié,
puppet cherchera par défaut un hôte nommé « puppet ». Sur notre serveur (installation centos 6 minimale, selinux désactivé), si nous décidons d’utiliser iptables comme pare-feu, il faut penser à ajouter une règle autorisant l’accès au port 8140/tcp.
Installation du serveur puppet :
Tout d’abord, nous allons installer le dépôt EPEL :
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm yum update
Nous installons ensuite Ruby :
yum install ruby ruby-libs ruby-shadow rubygems ruby-devel
Nous pouvons ainsi installer puppet et facter depuis les gems.
Facter est un programme permettant de rassembler les informations des environnements clients afin de personnaliser les configurations qui y seront appliquées.
gem install puppet facter
Nous allons ensuite mettre en place une configuration minimale ainsi qu’un utilisateur puppet :
mkdir -p /etc/puppet && cd /etc/puppet puppetmasterd --genconfig > puppet.conf mkdir manifests touch manifests/site.pp groupadd puppet useradd -g puppet -G puppet puppet passwd -l puppet mkdir -p /var/run/puppet chown puppet:puppet /var/run/puppet/
Dans le fichier /etc/puppet/puppet.conf, modifions la ligne certname pour y mettre le fqdn du serveur puppet :
certname = puppet.be-root.com
Créons le fichier /etc/init.d/puppetmaster :
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
# Source function library.
. /etc/rc.d/init.d/functions
RETVAL=0
prog=puppetmasterd
PUPPETMASTER=/usr/bin/$prog
start() {
echo -n $"Starting puppetmaster: "
daemon $PUPPETMASTER
RETVAL=$?
echo
return $RETVAL
}
stop() {
echo -n $"Stopping puppetmaster: "
killall puppetmasterd
RETVAL=$?
echo
return $RETVAL
}
restart() {
stop
start
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
condrestart)
rh_status_q || exit 0
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac
exit $RETVAL
Puis positionnons les droits d’exécution dessus :
chmod +x /etc/init.d/puppetmaster
Nous pouvons le démarrer à présent à l’aide de la commande :
service puppetmaster start
Installation d’un client sur ubuntu 11.10
L’installation se fait de manière classique à l’aide d’apt-get :
apt-get install puppet facter
NB: En fonction du système, il peut être plus intéressant de passer par les gem afin d’avoir une version plus récente de Puppet. Il faut se rappeler également que la version du serveur doit toujours
être supérieure ou égale à celle du client. Un client en v2.6.x peut se connecter sur un serveur en version 2.7.x mais l’inverse ne fonctionne pas.
Par défaut avec le paquet debian de puppet, le service est lancé sitôt l’installation terminée. Arrêtons le avec la commande :
/etc/init.d/puppet stop
Créons le fichier /etc/puppet/puppet.conf :
[main] server = puppet.be-root.com report = true rundir = /var/run/puppet/ runinterval = 50 [agent] listen=true
Bien évidemment, modifiez le champ server pour y mettre le fqdn du serveur puppet.
Le paramêtre runinterval permet de définir l’intervalle de temps (en secondes) entre
deux connexions du client vers le serveur.
Lançons la commande :
puppetd --server puppet --waitforcert 60 --test
Nous devons obtenir la réponse suivante répétée plusieurs fois:
warning: peer certificate won't be verified in this SSL session
Sur le serveur, lançons la commande :
puppetca list
Elle doit nous retourner une ligne du style :
poste-client (5D:F9:DD:90:8D:89:03:88:45:37:00:87:12:B3:A3:0E)
Nous devons donc valider le client à l’aide de la commande suivante (sur le serveur) :
puppetca sign poste-client
ou, pour valider l’ensemble des clients :
puppetca sign --all
Coté client, si nous relançons la commande :
puppetd --server puppet --waitforcert 60 --test
La réponse doit maintenant être :
warning: peer certificate won't be verified in this SSL session info: Caching certificate for poste-client notice: Ignoring --listen on onetime run info: Caching certificate_revocation_list for ca info: Caching catalog for poste-client info: Applying configuration version '1328021042' info: Creating state file /var/lib/puppet/state/state.yaml notice: Finished catalog run in 0.02 seconds
Le serveur puppet est donc pleinement fonctionnel et prêt à accepter d’autres clients et à gérer des configurations.
Utilisation d’Apache+Passenger :
Par défaut, puppet utilise le serveur HTTP WebRick. En environnement de production, il est préférable d’installer un autre serveur web (apache, nginx) plus robuste.
Nous allons détailler ici l’installation d’un serveur apache et du module Passenger.
Pour schématiser, Passenger est à ruby ce que mod_perl est à perl.
Sur le serveur, nous allons donc installer apache et les outils de développement :
yum install httpd httpd-devel httpd-tools libcurl-devel apr-devel apr-util-devel ruby-devel mod_ssl
Sur le wiki de puppet, nous obtenons les numeros de versions conseillés pour rack et passenger.
Nous les installons donc :
gem install rack -v 1.2.2 gem install passenger -v 3.0.7 passenger-install-apache2-module
Nous créons ensuite le fichier /etc/httpd/conf.d/passenger.conf :
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7/ext/apache2/mod_passenger.so PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7 PassengerRuby /usr/bin/ruby PassengerHighPerformance on PassengerUseGlobalQueue on # PassengerMaxPoolSize = nombre de cores * 1.5 PassengerMaxPoolSize 4 PassengerMaxrequests 5000 PassengerPoolIdleTime 600
Ainsi que le fichier /etc/httpd/conf.d/puppetmaster.conf :
Listen 8140
<VirtualHost *:8140>
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /etc/puppet/ssl/certs/puppet.be-root.com.pem
SSLCertificateKeyFile /etc/puppet/ssl/private_keys/puppet.be-root.com.pem
SSLCertificateChainFile /etc/puppet/ssl/certs/ca.pem
SSLCACertificateFile /etc/puppet/ssl/ca/ca_crt.pem
SSLCARevocationFile /etc/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
RackAutoDetect on
DocumentRoot /etc/puppet/rack/puppetmaster/public/
<Directory /etc/puppet/rack/puppetmaster/>
Options None
AllowOverride None
Order Allow,Deny
Allow from All
</Directory>
</VirtualHost>
Comme précédemment, il faut remplace puppet.be-root.com.pem par le_fqdn_du_serveur.pem.
Ce vhost ce base sur les certificats générés pour le serveur lors de la première exécution de /etc/init.d/puppetmaster.
Finissons la configuration :
mkdir -p /etc/puppet/rack/puppetmaster/
ln -s /usr/lib/ruby/gems/1.8/gems/puppet-2.7.10/ext/rack/files/config.ru /etc/puppet/rack/puppetmaster/config.ru
mkdir -p /etc/puppet/rack/puppetmaster/{public,tmp}
chown -R puppet:puppet /etc/puppet/rack/puppetmaster
Pour pouvoir lancer apache (qui va donc écouter sur le port 8140/tcp), nous devons arrêter le service puppetmaster qui écoute sur le même port.
service puppetmaster stop service httpd start
Côté client, si on lance la commande :
puppetd --server puppet --waitforcert 60 --test
Nous obtenons la réponse :
notice: Ignoring --listen on onetime run info: Caching catalog for poste-client info: Applying configuration version '1328023381' notice: Finished catalog run in 0.02 seconds
Ce qui signifie que le client arrive à communiquer avec le serveur puppet fonctionnant avec apache+passenger.
Nous pouvons donc executer puppet en tant que service sur le client. Pour cela, il faut créer un fichier /etc/puppet/namespaceauth.conf vide sinon le service refuse de démarrer sur ubuntu.
Nous pouvons également changer le paramètre runinterval pour y mettre un delai plus important.
Ensuite, nous pouvons lancer la commande :
service puppet start
Dans le fichier /var/log/syslog, nous voyons que le client se connecte à intervales régulier au serveur :
puppet-agent[11803]: Finished catalog run in 0.03 seconds