Articles avec les mots clés ’apache’
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
Ajouter le support OCI8 à php sous Centos 5
L’extension OCI8 permet ajoute à php des fonctionnalités permettant de communiquer avec une base Oracle.
OCI8 n’est pas fourni de base avec php, il convient de l’installer manuellement.
Avant toute chose, nous allons installer apache-php :
yum install php php-devel httpd /etc/init.d/httpd start
Nous créons ensuite un fichier /var/www/html/phpinfo.php contenant :
<?php
phpinfo();
?>
Cette page est donc accessible depuis l'adresse http://127.0.0.1/phpinfo.php
Il faut ensuite télécharger et décompresser l'extension oci8 pour php :
wget http://pecl.php.net/get/oci8-1.4.5.tgz tar zxf oci8-1.4.5.tgz
Pour installer l'extension OCI8, deux cas de figures peuvent se présenter. Soit la machine possède déjà un serveur oracle configuré (cf article sur l'installation d'un serveur oracle) soit la machine ne possède pas de serveur oracle local et devra accéder à un serveur oracle distant.
Si un serveur oracle local est installé :
cd oci8-1.4.5 phpize ./configure --with-oci8=shared,$ORACLE_HOME make make install
Si aucun serveur oracle n'est présent sur la machine :
Il faut alors installer oracle_instantclient. Nous choisirons la version 11.2-basic et 11.2-devel en rpm depuis cette page
rpm -ivh oracle-instantclient11.2-basic-11.2.0.2.0.i386.rpm rpm -ivh oracle-instantclient11.2-devel-11.2.0.2.0.i386.rpm
Nous pouvons maintenant compiler l'extension OCI8 :
cd oci8-1.4.5 phpize ./configure --with-oci8=shared,instantclient,/usr/lib/oracle/11.2/client/lib make make install
Configuration de php
Cette étape est commune aux deux méthodes d'installation précédentes.
Ajouter au fichier /etc/php.ini la ligne :
extension=oci8.so
et redémarrer le serveur apache :
/etc/init.d/httpd restart
Maintenant, en allant sur la page http://127.0.0.1/phpinfo.php, vous devez avoir une section oci8 de ce style :
Executer des scripts php sous différentes identités.
Il peut parfois être utile que des scripts php s’exécutent sous différents UID/GID.
Dans notre exemple,nous allons faire en sorte que les scripts s’exécutent sous l’uid/gid du propriétaire du script. Nous allons également permettre d’executer des scripts sous l’identité du root (ATTENTION : CECI EST UNIQUEMENT FAIT A DES FINS PÉDAGOGIQUES ET NE DOIT PAS ÊTRE MIS EN PRODUCTION POUR DES RAISONS ÉVIDENTES DE SÉCURITÉ).
La plateforme utilisée est une Centos 5.5.
Tout d’abord, il convient d’installer apache ainsi que la version « cgi » de php.
yum install httpd httpd-devel php-common php-cli
Attention à ce que le module apache php ne soit pas installé sinon le désinstaller :
rpm -e php
Nous installons ensuite quelques outils de compilation
yum install autoconf gcc-c++ gcc libtool-ltdl-devel
Il nous faut ensuite installer apr depuis les sources :
wget http://mir2.ovh.net/ftp.apache.org/dist/apr/apr-1.4.2.tar.gz tar zxf apr-1.4.2.tar.gz cd apr-1.4.2 ./configure --prefix=/usr/ && make && make install
Nous allons ensuite compiler et installer le module Apache suPHP :
wget http://www.suphp.org/download/suphp-0.7.1.tar.gz tar zxf suphp-0.7.1.tar.gz ./configure --prefix=/usr --disable-checkpath --disable-checkuid --disable-checkgid --with-min-uid=0 --with-min-gid=0 --with-apache-user=apache --with-apr=/usr/bin/apr-1-config --sysconfdir=/etc --with-setid-mode=owner make make install
Si nous avions voulu interdire l’exécution de scripts possédant des uid/gid <100, il aurait fallu modifier les parametres –with-min-uid et –with-min-gid en conséquence.
Editons ensuite un fichier /etc/suphp.conf :
Modifions ensuite le fichier /etc/httpd/conf/httpd.conf.
Dans les options générales du fichier de configuration, ajoutons :
LoadModule suphp_module modules/mod_suphp.so suPHP_Engine on
puis sous la section <Directory /var/www/html> :
AddType application/x-httpd-php .php suPHP_AddHandler application/x-httpd-php
Il faut ensuite relancer le service avec :
service httpd restart
Pour tester, créons un fichier /var/www/html/test.php
<?
echo("<html><body>");
system("/usr/bin/id");
echo("</body></html>");
?>
Positionnons les droits sur ce fichier sur root:root :
chown root:root /var/www/html/test.php
Si nous lancons un navigateur sur http://xxx.xxx.xxx.xxx/test.php
nous obtenons :
Et si nous changeons les droits sur le fichier :
chown nobody:nobody /var/www/html/test.php
Nous obtenons :
Le script est donc bien exécuté en fonction du propriétaire du script et non pas sous l’identité « apache:apache ».
suPhP propose de nombreuses options permettant d’affiner les permissions accordées aux scripts. Pour cela, consultez la documentation officielle ici.