Apache HTTP Server

Objectifs de certification

RHCE EX300

1. HTTP/HTTPS
   • 3.1. Configure a virtual host.
   • 3.2. Configure private directories.
   • 3.3. Deploy a basic CGI application.
   • 3.4. Configure group-managed content.
   • 3.5. Configure TLS security.

LPI 202

• Sujet 208 : Services Web
• 208.1 Configuration élémentaire d’Apache (valeur : 4)
• 208.2 Configuration d’Apache pour HTTPS (valeur : 3)

1. Introduction à Apache HTTP Server

Le logiciel libre Apache HTTP Server (Apache) est un serveur HTTP créé et maintenu au sein de la fondation Apache. C’est le serveur HTTP le plus populaire du World Wide Web. Il est distribué selon les termes de la licence Apache.

Sources et crédits

• https://fr.wikipedia.org/wiki/Apache_HTTP_Server
• https://httpd.apache.org/docs/2.4/fr/new_features_2_4.html

1.1. Historique

Apache est apparu en avril 1995. Au début, il s’agissait d’une collection de correctifs et d’additions au serveur NCSA HTTPd 1.3, qui était dans ledomaine public et le serveur HTTP alors le plus répandu. De cette origine, de nombreuses personnes affirment que le nom Apache vient de a patchy server, soit « un serveur rafistolé ». Par la suite, Apache a été complètement réécrit, de sorte que, dans la version 2, il ne reste pas de trace de NCSA HTTPd.

Au début, Apache était la seule alternative sérieuse et libre au serveur HTTP de Netscape (iPlanet, maintenant Sun ONE). Depuis avril 1996, selon l’étude permanente de Netcraft, Apache est devenu le serveur HTTP le plus répandu sur Internet.

Part de marché d’Apache :

• En mai 1999, il faisait tourner 57 % des serveurs Web, début 2004, il était à environ 69 % de parts de marché, et il ne détient plus que 50,61 % du marché à la fin du mois de janvier 2008 ;

• En février 2008, Apache représente 50,93 % des parts de marché ;

• En novembre 2008, 72,45 % de parts de marché pour Apache ;

• En novembre 2011, 65,00 % de parts de marché pour Apache ;

• En mai 2014, 38,00 % de parts de marché pour Apache et 33,00 % pour Microsoft IIS.

• En janvier 2015 sur l’analyse de 876,812,666 sites, correspondant à 5,061,365 ordinateurs frontaux, les parts de marché sont de 39.74 % pour Apache, et 27,52 % pour IIS. Sur les part de marché des serveurs actifs (en excluant les sites parkings) par contre, 50.72 % pour Apache, 14.82 % pour Nginx et IIS passe en 3e position avec seulement 10.55 %, perdant 1.17 % de parts par rapport au mois précédent.

La version 2 d’Apache possède plusieurs avancées majeures par rapport à la version 1, entre autres le support de plusieurs plates-formes (Windows, Linux et UNIX, entre autres), le support de processus légers UNIX, une nouvelle API et le support IPv6.

La fondation Apache (Apache Software Foundation ou ASF) a été créée en 1999 à partir du groupe Apache (Apache Group) à l’origine du serveur en 1995. Depuis, de nombreux autres logiciels utiles au World Wide Web sont développés à côté du serveur HTTP.

https://en.wikipedia.org/wiki/Comparison_of_web_server_software

1.2. Disponibilité

Apache fonctionne principalement sur les systèmes d’exploitation UNIX (Linux, Mac OS X, Solaris, BSD et UNIX) et Windows. La version Windows n’est considérée comme stable que depuis la version 1.2 d’Apache. Apache est utilisé par de nombreux produits, dont WebSphere d’IBM, ainsi que par Oracle Corporation.

1.3. Fonctionnalités

Apache est conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation du langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, Server Side Includes, réécriture d’URL, négociation de contenu, protocoles de communication additionnels, etc. Néanmoins, il est à noter que l’existence de nombreux modules Apache complexifie la configuration du serveur web. En effet, les bonnes pratiques recommandent de ne charger que les modules utiles : de nombreuses failles de sécurité affectant uniquement les modules d’Apache sont régulièrement découvertes.

Les possibilités de configuration d’Apache sont une fonctionnalité phare. Le principe repose sur une hiérarchie de fichiers de configuration, qui peuvent être gérés indépendamment. Cette caractéristique est notamment utile aux hébergeurs qui peuvent ainsi servir les sites de plusieurs clients à l’aide d’un seul serveur HTTP. Pour les clients, cette fonctionnalité est rendue visible par le fichier .htaccess.

Parmi les outils aidant la maintenance d’Apache, les fichiers de log peuvent s’analyser à l’aide de nombreux scripts et logiciels libres tels que AWStats, Webalizer ou W3Perl. Plusieurs interfaces graphiques facilitent la configuration du serveur.

1.4. Quelques modules intéressants

Les modes Prefork, Worker et Event

Ces deux grands modes de fonctionnement changent notamment les performances du serveur HTTP.

Historiquement, Apache fonctionne en Prefork, ce qui signifie qu’un processus père lancé avec des droits étendus (root) démarre des processus enfants qui traiteront chacun un certain nombre de requêtes clients. Cependant, sous Linux, la multiplication des processus provoque une augmentation de consommation de ressources (mémoire, descripteurs de fichiers).

En mode Worker, Apache lance des threads qui géreront les demandes entrantes. La différence est qu’il s’agit d’un mode plus préemptif dans lequel le processus père prépare les ressources pour ses threads. Certains modules développés par des tiers, ou des librairies utilisées par ces modules, peuvent parfois ne pas être prévus pour fonctionner dans un environnement multi-thread, et dans ce cas peuvent provoquer des problèmes si on les utilise en conjonction avec le mode Worker.

Depuis la version 2.4, le module event est disponible en production. C’est un fonctionnement derivé du mode worker à ceci près que les threads ne desservent pas seulement une connexion client mais peuvent réaliser plusieurs tâches indépendamment de la connexion. Ainsi, les notions de KeepAlive sont mieux gérées dans le sens où un thread n’attend plus que la connexion soit terminée pour en desservir une autre. Plus clairement, le thread dessert une requête et non pas une connexion.

Les modules de Proxy

Par le biais de mod_proxy, entre autres, il est possible de se servir de Httpd Server comme d’un véritable Proxy.

Une des utilisations les plus intéressantes consiste en la répartition de charge, soit dans le cadre d’une haute disponibilité, soit dans le but d’obtenir de meilleures performances. Les aptitudes de Reverse Proxying sont suffisamment au point pour une mise en production sans difficultés à partir de la version 2.1.

1.5. Nouvelles fonctionnalités Apache 2.4

Améliorations du noyau

Modules multiprocessus (MPMs) chargeables à l’exécution

Plusieurs MPMs peuvent maintenant être compilés en tant que modules chargeables. Le choix du MPM à utiliser s’effectue à l’exécution via la directive LoadModule.

MPM Event

Le MPM Event n’en est plus au stade expérimental et est maintenant pleinement supporté.

Support du mode asynchrone

Le support des lectures/écritures asynchrones pour les MPMs et les plateformes qui l’implémentent a été amélioré.

Configuration du niveau de journalisation (LogLevel) par module et par répertoire

La directive LogLevel peut maintenant être définie par module et par répertoire. Les nouveaux niveaux trace1 à trace8 ont été ajoutés au dessus du niveau de journalisationdebug.

Sections de configuration au niveau requête

Les sections If, [](https://httpd.apache.org/docs/2.4/fr/mod/core.html#elseif) et [](https://httpd.apache.org/docs/2.4/fr/mod/core.html#else) permettent de définir une configuration en fonction de critères liés à la requête.

Interpréteur d’expressions à usage général

Un nouvel interpréteur d’expressions permet de spécifier des conditions complexes via des directives à syntaxe commune comme SetEnvIfExpr, RewriteCond, Header,[](https://httpd.apache.org/docs/2.4/fr/mod/core.html#if), etc...

KeepAliveTimeout en millisecondes

Il est maintenant possible de définir la directive KeepAliveTimeout en millisecondes.

Directive NameVirtualHost

Cette directive n’est plus nécessaire et est maintenant obsolète.

Directives autorisées dans les fichiers .htaccess

La nouvelle directive AllowOverrideList permet de contrôler de manière plus précise la liste des directives autorisées dans les fichiers .htaccess.

Variables dans les fichiers de configuration

La directive Define permet de définir des variables dans les fichiers de configuration, améliorant ainsi la clareté de la présentation si la même valeur est utilisée en plusieurs points de la configuration.

Diminution de la mémoire utilisée

Bien qu’elle propose de nombreuses nouvelles fonctionnalités, la version 2.4.x tend à utiliser moins de mémoire que la version 2.2.x.

Nouveau modules

1. mod_proxy_fcgi : Mise à disposition du protocole FastCGI pour mod_proxy.
   • mod_proxy_scgi : Mise à disposition du protocole SCGI pour mod_proxy.
   • mod_proxy_express : Ajoute à mod_proxy la configuration dynamique de mandataires inverses en masse.
   • mod_remoteip : Remplace l’adresse IP distante et le nom d’hôte apparents du client pour la requête courante par la liste d’adresses IP présentée par un mandataire ou un répartiteur de charge via les en-têtes de la requête.
   • mod_heartmonitor, mod_lbmethod_heartbeat: Permet à mod_proxy_balancer de répartir la charge en fonction du nombre de connexions actives sur les serveurs d’arrière-plan.
   • mod_proxy_html : Anciennement module tiers, il supporte la correction des liens HTML dans une situation de mandat inverse, où le serveur d’arrière-plan génère des URLs qui ne sont pas valides du point de vue des clients du mandataire.
   • mod_sed: Une amélioration de mod_substitute qui permet d’éditer le corps de la réponse avec toute la puissance de la commande sed.
   • mod_auth_form: Implémente une authentification à base de formulaire.
   • mod_session : Permet de conserver les données de sessions des clients sous forme de cookies ou dans une base de données.
   • mod_allowmethods : Permet de restreindre l’utilisation de certaines méthodes HTTP sans interférer avec l’authentification et l’autorisation.
   • mod_lua : Embarque le langage Lua dans httpd pour la configuration et les fonctions logiques courantes (Expérimental).
   • mod_log_debug : Permet d’introduire une journalisation personnalisée à différentes phases du traitement de la requête.
   • mod_buffer : Fournit un tampon pour les piles des filtres en entrée et en sortie.
   • mod_data : Convertit un corps de réponse en URL de type données RFC2397.
   • mod_ratelimit : Permet de limiter la bande passante pour certains clients.
   • mod_request : Fournit des filtres permettant de gérer et de mettre à disposition les corps des requêtes HTTP.
   • mod_reflector : Permet de renvoyer comme réponse le corps de la requête via la pile du filtre de sortie.
   • mod_slotmem_shm : Met à disposition un fournisseur de mémoire partagée à base de slots (du style tableau de bord).
   • mod_xml2enc : Anciennement module tiers, il supporte l’internationalisation dans les modules de filtrage basés sur libxml2 (support du markup)
   • mod_macro (disponible à partir de la version 2.4.5) : Permet d’utiliser des macros au sein des fichiers de configuration.
   • mod_proxy_wstunnel (disponible à partir de la version 2.4.5) : Support des tunnels web-socket.
   • mod_authnz_fcgi (disponible à partir de la version 2.4.10) : Permet aux applications d’autorisation FastCGI d’authentifier et/ou autoriser les clients.

1.6. Améliorations des modules

mod_ssl

mod_ssl peut maintenant vérifier la validité des certificats clients en se connectant à un serveur OCSP. Il est possible de définir un répondeur par défaut, et de choisir si l’on préfère le répondeur désigné dans le certificat client.

En outre, mod_ssl supporte maintenant l’estampillage OCSP (OCSP stapling), qui permet au serveur d’attester la validité de son certificat auprès du client au cours de la phase de négociation de la connexion.

Enfin, mod_ssl peut maintenant être configuré pour que celui-ci partage les données de session SSL entre les serveurs via memcached.

Le support des clés EC a été ajouté à celui des clés RSA et DSA.

Support de TLS-SRP (disponible à partir de la version 2.4.4).

mod_proxy

La directive ProxyPass est maintenant configurée de manière optimale dans les sections Location ou LocationMatch, et offre un gain de performances important par rapport à la syntaxe traditionnelle à deux paramètres lorsqu’elle est présente en grand nombre.

Il est maintenant possible de configurer l’adresse source dans les requêtes mandatées.

Support des sockets de type Unix vers le serveur d’arrière-plan (disponible à partir de la version 2.4.7).

mod_proxy_balancer

Le gestionnaire de répartition de charge propose de nouvelles fonctionnalités. Ainsi, les possibilités de configuration des membres du groupe de répartition de charge pendant l’exécution ont été améliorées (possibilité d’ajout d’un membre supplémentaire).

Configuration à l’exécution d’un sous-ensemble de paramètres de répartition de charge.

Les membres du groupe de répartition peuvent être définis à ‘Drain’ de façon à ce qu’ils ne répondent qu’aux sessions persistantes existantes, ce qui permet de les mettre hors ligne en douceur.

Les réglages du répartiteur de charge peuvent être rendus persistants après redémarrage.

mod_cache

Le filtre CACHE du module mod_cache peut être inséré à un certain point de la chaîne de filtrage pour contrôler plus finement la mise en cache.

mod_cache peut maintenant mettre en cache des requêtes HEAD.

Chaque fois que cela est possible, les directives de mod_cache peuvent maintenant être définies au niveau du répertoire, et non plus seulement au niveau du serveur principal.

L’URL de base des URLs en cache peut être personnalisée de façon à ce qu’un cluster de caches puisse partager le même préfixe d’URL.

mod_cache peut maintenant servir du contenu non mis à jour lorsqu’un serveur d’arrière-plan n’est pas disponible (erreur 5xx).

mod_cache peut maintenant insérer HIT/MISS/REVALIDATE dans un en-tête X-Cache.

mod_include

Support de l’attribut ‘onerror’ dans un élément ‘include’, permettant de renvoyer un message d’erreur personnalisé à la place du message d’erreur par défaut.

mod_cgi, mod_include, mod_isapi, …

La traduction des en-têtes en variables d’environnement est plus stricte qu’avant, ce qui permet de diminuer l’exposition aux attaques de type cross-site-scripting via injection d’en-têtes. Les en-têtes contenant des caractères invalides (comme les caractères de soulignement) sont maintenant ignorés. Le document Les variables d’environnement dans Apacheprésente quelques pistes pour contourner ce problème avec les clients anciens qui nécessitent de tels en-têtes (Ceci affecte tous les modules qui utilisent ces variables d’environnement).

mod_authz_core Conteneurs de logique d’autorisation

La directive Require et les directives de conteneurs associées, comme [](https://httpd.apache.org/docs/2.4/fr/mod/mod_authz_core.html#requireall), permettent de définir une logique d'autorisation avancée.

mod_rewrite

La directive RewriteRule dispose maintenant des drapeaux [QSD] (Query String Discard) et [END] qui permettent de simplifier les scénarios de réécriture courants.

Possibilité d’utiliser des expressions booléennes complexes dans la directive RewriteCond.

Possibilité d’utiliser des requêtes SQL en tant que fonctions dans la directive RewriteMap.

mod_ldap, mod_authnz_ldap

mod_authnz_ldap ajoute le support des groupes imbriqués.

mod_ldap apporte les directives LDAPConnectionPoolTTL et LDAPTimeout, ainsi que d’autres améliorations dans le traitement des délais. Ceci s’avère utile pour les configurations où un pare-feu à mémoire d’état (stateful) rejète les connexions inactives vers le serveur LDAP.

mod_ldap propose la directive LDAPLibraryDebug qui permet de journaliser les informations de débogage fournies par la boîte à outils LDAP utilisée.

mod_info

mod_info est maintenant capable d’afficher la configuration préinterprétée sur stdout au cours du démarrage du serveur.

mod_auth_basic

Nouveau mécanisme générique permettant d’effectuer une authentification basique (disponible à partir de la version 2.4.5).

1.7. Améliorations des programmes

fcgistarter

Nouvel utilitaire pour le démarrage des démons FastCGI.

htcacheclean

Les URLs présentes dans le cache peuvent maintenant être affichées, accompagnées éventuellement de leurs métadonnées.

Possibilité de supprimer explicitement des URLs individuelles présentes dans le cache.

Les tailles de fichiers peuvent maintenant être arrondies au multiple de la taille de bloc donnée, les limites de taille collant de ce fait d’avantage à la taille réelle sur disque.

La taille du cache peut maintenant être limitée par le nombre d’inodes, en plus de la possibilité de limitation par la taille des fichiers.

rotatelogs

Possibilité de créer un lien vers le fichier journal courant.

Possibilité d’invoquer un script personnalisé après la rotation.

htpasswd, htdbm

Support de l’algorithme bcrypt (disponible à partir de la version 2.4.4).

1.8. Documentation

mod_rewrite

La documentation du module mod_rewrite a été réorganisée et presque entièrement réécrite en mettant l’accent sur les exemples et l’utilisation courante, ainsi que sur l’incitation à utiliser d’autres solutions lorsque cela s’avère plus approprié. Le document Rewrite Guide constitue maintenant une section de premier niveau ; il est mieux organisé et contient beaucoup plus de détails.

mod_ssl

La documentation du module mod_ssl a été grandement améliorée, avec plus d’exemples et un niveau “Bien démarrer” qui s’ajoutent aux détails techniques déjà présents dans la précédente documentation.

Caching Guide

Le Guide de la mise en cache a été réécrit afin de bien faire la différence entre les fonctionnalités de mise en cache de la RFC2616 HTTP/1.1 fournies par le module mod_cache, et la mise en cache générique de type clé/valeur fournie par l’interface socache, mais aussi pour couvrir la mise en cache spécialisée fournie par des mécanismes tels que ceux du module mod_file_cache.

1.9. Modifications concernant les développeurs de modules

Ajout de code pour la vérification de la configuration

Une nouvelle fonction, check_config, a été ajoutée et s’exécute entre les fonctions pre_config et open_logs. Elle s’exécute aussi avant la fonction test_config si l’option-t est passée au démon httpd. La fonction check_config permet aux modules de vérifier l’interdépendance des valeurs des directives de configuration et d’ajuster ces valeurs, alors que les messages du serveur peuvent encore être affichés sur la console. L’utilisateur est ainsi averti des erreurs de configuration avant que la fonction du noyau open_logsne redirige les sorties de la console vers le journal des erreurs.

Ajout d’un analyseur syntaxique d’expressions

Nous disposons à présent d’un analyseur générique d’expressions, dont l’API est décrite dans ap_expr.h. Il s’agit d’une adaptation de l’analyseur qu’on trouvait auparavant dans mod_ssl.

Conteneurs de logique d’autorisation

Afin de fournir une logique d’autorisation avancée via des directives telles que [](https://httpd.apache.org/docs/2.4/fr/mod/mod_authz_core.html#requireall), les modules d'autorisation s'enregistrent maintenant en tant que fournisseur par le biais de ap_register_auth_provider().

Interface de mise en cache des petits objets

Le fichier d’en-têtes ap_socache.h fournit une interface à base de fournisseur pour la mise en cache des petits objets de données, en s’inspirant de l’implémentation précédente du cache de session par mod_ssl. Sont supportés actuellement : les fournisseurs utilisant un tampon cyclique en mémoire partagée, les fichiers dbm sur disque, et les caches distribués de type memcache.

Ajout du point d’ancrage Cache Status

Le module mod_cache inclut maintenant un nouveau point d’ancrage, cache_status, qui est appelé lorsque la décision à propos de la mise en cache est connue. Il en existe une implémentation par défaut qui ajoute les en-têtes optionnels X-Cache et X-Cache-Detail à la réponse.

2. Installation

2.1. Dépôt Debian 8

Préparation du serveur

• Installation du serveur SSH, du client NTP

# apt-get update && apt-get install -y openssh-server ntpdate

Serveur de noms

• Fichier /etc/hosts
• Bind9
• via apt-get -y install bind9 bind9utils
• via Docker : https://github.com/sameersbn/docker-bind

Installation d’Apache2

• Version proposée en ce jour

# cat /etc/debian_version ; apt-cache policy apache2
8.3
apache2:
  Installé : (aucun)
  Candidat : 2.4.10-10+deb8u4
 Table de version :
     2.4.10-10+deb8u4 0
        500 http://debian.mirrors.ovh.net/debian/ jessie/main amd64 Packages
     2.4.10-10+deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages

• Installation par apt-get

# apt-get install apache2 apache2-doc apache2-utils
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
  apache2-bin apache2-data libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap liblua5.1-0 ssl-cert
Paquets suggérésc:
  apache2-suexec-pristine apache2-suexec-custom openssl-blacklist
Les NOUVEAUX paquets suivants seront installésc:
  apache2 apache2-bin apache2-data apache2-doc apache2-utils libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap liblua5.1-0
  ssl-cert
0 mis à jour, 11 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 4 666 ko dans les archives.
Après cette opération, 26,6 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] O
Réception de ...
Préconfiguration des paquets...
Sélection du paquet ...
Préparation du dépaquetage de ...
Dépaquetage...
Traitement des actions différées («triggers») pour man-db (2.7.0.2-5) ...
Traitement des actions différées («triggers») pour systemd (215-17+deb8u3) ...
Paramétrage de libapr1:amd64 (1.5.1-3) ...
Paramétrage de libaprutil1:amd64 (1.5.4-1) ...
Paramétrage de libaprutil1-dbd-sqlite3:amd64 (1.5.4-1) ...
Paramétrage de libaprutil1-ldap:amd64 (1.5.4-1) ...
Paramétrage de liblua5.1-0:amd64 (5.1.5-7.1) ...
Paramétrage de apache2-bin (2.4.10-10+deb8u4) ...
Paramétrage de apache2-utils (2.4.10-10+deb8u4) ...
Paramétrage de apache2-data (2.4.10-10+deb8u4) ...
Paramétrage de apache2 (2.4.10-10+deb8u4) ...
Enabling module mpm_event.
Enabling module authz_core.
Enabling module authz_host.
Enabling module authn_core.
Enabling module auth_basic.
Enabling module access_compat.
Enabling module authn_file.
Enabling module authz_user.
Enabling module alias.
Enabling module dir.
Enabling module autoindex.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module filter.
Enabling module deflate.
Enabling module status.
Enabling conf charset.
Enabling conf localized-error-pages.
Enabling conf other-vhosts-access-log.
Enabling conf security.
Enabling conf serve-cgi-bin.
Enabling site 000-default.
Paramétrage de apache2-doc (2.4.10-10+deb8u4) ...
apache2_invoke: Enable configuration apache2-doc
Paramétrage de ssl-cert (1.0.35) ...
Traitement des actions différées («triggers») pour libc-bin (2.19-18+deb8u2)...
Traitement des actions différées («triggers») pour systemd (215-17+deb8u3)...

• Vérification

# apachectl -V
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.122.83. Set the 'ServerName' directive globally to suppress this message
Server version: Apache/2.4.10 (Debian)
Server built:   Nov 28 2015 14:05:48
Server's Module Magic Number: 20120211:37
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

• Structure du dossier des fichiers de configuration /etc/apache2

# apt-get install tree
# tree -L 1 /etc/apache2
/etc/apache2
├── apache2.conf
├── conf-available
├── conf-enabled
├── envvars
├── magic
├── mods-available
├── mods-enabled
├── ports.conf
├── sites-available
└── sites-enabled

• Vérification du fichier apache2.conf

# grep "^[^#|^$|^ *$]" /etc/apache2/apache2.conf
Mutex file:${APACHE_LOCK_DIR} default
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf
<Directory />
	Options FollowSymLinks
	AllowOverride None
	Require all denied
</Directory>
<Directory /usr/share>
	AllowOverride None
	Require all granted
</Directory>
<Directory /var/www/>
	Options Indexes FollowSymLinks
	AllowOverride None
	Require all granted
</Directory>
AccessFileName .htaccess
<FilesMatch "^\.ht">
	Require all denied
</FilesMatch>
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

• Les fichiers inclus :

# grep "Include" /etc/apache2/apache2.conf
# Include module configuration:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
# Include list of ports to listen on
Include ports.conf
# Include of directories ignores editors' and dpkg's backup files,
# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf
# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

• Site activé : fichier site-enabled/000-default.conf

# cat /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

• Modules lancés
• Vérification par un client curl ou lynx

apt-get install curl
curl -I 127.0.0.1
HTTP/1.1 200 OK
Date: Sun, 24 Jan 2016 13:02:46 GMT
Server: Apache/2.4.10 (Debian)
Last-Modified: Sun, 24 Jan 2016 12:41:15 GMT
ETag: "2b60-52a13c4a6bc40"
Accept-Ranges: bytes
Content-Length: 11104
Vary: Accept-Encoding
Content-Type: text/html

# apt-get -y install lynx
lynx 127.0.0.1

Debian Logo Apache2 Debian Default Page
   It works!

   This is the default welcome page used to test the correct operation of the Apache2 server after installation on Debian systems. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server.

   If you are a normal user of this web site and don't know what this page is about, this probably means that the site is currently unavailable due to maintenance. If the problem persists, please contact the site's administrator.

   Configuration Overview

   Debian's Apache2 default configuration is different from the upstream default configuration, and split into several files optimized for interaction with Debian tools. The configuration system is fully documented in /usr/share/doc/apache2/README.Debian.gz. Refer to this for the full documentation. Documentation for the web server itself can be found by accessing the manual if the apache2-doc package was installed on this server.

   The configuration layout for an Apache2 web server installation on Debian systems is as follows:
/etc/apache2/
|-- apache2.conf
|       `--  ports.conf
|-- mods-enabled
|       |-- *.load
|       `-- *.conf
|-- conf-enabled
|       `-- *.conf
|-- sites-enabled
|       `-- *.conf

     * apache2.conf is the main configuration file. It puts the pieces together by including all remaining configuration files when starting up the web server.
     * ports.conf is always included from the main configuration file. It is used to determine the listening ports for incoming connections, and this file can be customized anytime.
     * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/ directories contain particular configuration snippets which manage modules, global configuration fragments, or virtual host configurations, respectively.
     * They are activated by symlinking available configuration files from their respective *-available/ counterparts. These should be managed by using our helpers a2enmod, a2dismod, a2ensite, a2dissite, and a2enconf, a2disconf . See their respective man pages for detailed information.
     * The binary is called apache2. Due to the use of environment variables, in the default configuration, apache2 needs to be started/stopped with /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not work with the default configuration.

   Document Roots

   By default, Debian does not allow access through the web browser to any file apart of those located in /var/www, public_htmldirectories (when enabled) and /usr/share (for web applications). If your site is using a web document root located elsewhere (such as in /srv) you may need to whitelist your document root directory in /etc/apache2/apache2.conf.

   The default Debian document root is /var/www/html. You can make your own virtual hosts under /var/www. This is different to previous releases which provides better security out of the box.

   Reporting Problems

   Please use the reportbug tool to report bugs in the Apache2 package with Debian. However, check existing bug reports before reporting a new bug.

   Please report bugs specific to modules (such as PHP and others) to respective packages, not to the web server itself.

Gestion du service

Source : https://wiki.debian.org/fr/systemd

# cat /run/systemd/generator.late/apache2.service
# Automatically generated by systemd-sysv-generator

[Unit]
SourcePath=/etc/init.d/apache2
Description=LSB: Apache2 web server
Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target
After=local-fs.target remote-fs.target network-online.target systemd-journald-dev-log.socket nss-lookup.target
Wants=network-online.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SysVStartPriority=2
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
ExecReload=/etc/init.d/apache2 reload

• Redémarrage du service

# systemctl reload apache2.service

• Arrêt du service

# systemctl stop apache2.service

• Démarrage du service

# systemctl start apache2.service

• Vérification

# systemctl -l status apache2
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
   Active: active (running) since dim. 2016-01-24 13:41:17 CET; 53min ago
  Process: 4116 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/apache2.service
           ├─2907 /usr/sbin/apache2 -k start
           ├─4131 /usr/sbin/apache2 -k start
           └─4132 /usr/sbin/apache2 -k start

janv. 24 13:41:16 debian8-01 apache2[2886]: Starting web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.122.83. Set the 'ServerName' directive globally to suppress this message
janv. 24 13:41:17 debian8-01 apache2[2886]: .
janv. 24 13:41:17 debian8-01 apache2[3049]: Reloading web server: apache2.
janv. 24 14:28:20 debian8-01 apache2[4116]: Reloading web server: apache2.

# journalctl -xn
-- Logs begin at dim. 2016-01-24 00:13:19 CET, end at dim. 2016-01-24 14:28:20 CET. --
janv. 24 14:03:51 debian8-01 dhclient[418]: DHCPREQUEST on eth0 to 192.168.122.1 port 67
janv. 24 14:03:51 debian8-01 dhclient[418]: DHCPACK from 192.168.122.1
janv. 24 14:03:52 debian8-01 dhclient[418]: bound to 192.168.122.83 -- renewal in 1391 seconds.
janv. 24 14:17:01 debian8-01 CRON[4048]: pam_unix(cron:session): session opened for user root by (uid=0)
janv. 24 14:17:01 debian8-01 CRON[4049]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
janv. 24 14:17:01 debian8-01 CRON[4048]: pam_unix(cron:session): session closed for user root
janv. 24 14:27:03 debian8-01 dhclient[418]: DHCPREQUEST on eth0 to 192.168.122.1 port 67
janv. 24 14:27:03 debian8-01 dhclient[418]: DHCPACK from 192.168.122.1
janv. 24 14:27:03 debian8-01 dhclient[418]: bound to 192.168.122.83 -- renewal in 1443 seconds.
janv. 24 14:28:20 debian8-01 apache2[4116]: Reloading web server: apache2.

# tail /var/log/apache2/*.log
==> /var/log/apache2/access.log <==
127.0.0.1 - - [24/Jan/2016:14:02:24 +0100] "GET / HTTP/1.1" 200 11359 "-" "curl/7.38.0"
127.0.0.1 - - [24/Jan/2016:14:02:46 +0100] "HEAD / HTTP/1.1" 200 255 "-" "curl/7.38.0"
127.0.0.1 - - [24/Jan/2016:14:03:51 +0100] "GET / HTTP/1.0" 200 3380 "-" "Lynx/2.8.9dev.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/3.3.8"
127.0.0.1 - - [24/Jan/2016:14:04:03 +0100] "GET / HTTP/1.0" 200 3380 "-" "Lynx/2.8.9dev.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/3.3.8"
127.0.0.1 - - [24/Jan/2016:14:04:22 +0100] "GET / HTTP/1.0" 200 3380 "-" "Lynx/2.8.9dev.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/3.3.8"
127.0.0.1 - - [24/Jan/2016:14:05:02 +0100] "GET / HTTP/1.0" 200 3380 "-" "Lynx/2.8.9dev.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/3.3.8"

==> /var/log/apache2/error.log <==
[Sun Jan 24 13:41:16.294464 2016] [mpm_event:notice] [pid 2907:tid 140687491151744] AH00489: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Sun Jan 24 13:41:16.294517 2016] [core:notice] [pid 2907:tid 140687491151744] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 24 13:41:17.565589 2016] [mpm_event:notice] [pid 2907:tid 140687491151744] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.122.83. Set the 'ServerName' directive globally to suppress this message
[Sun Jan 24 13:41:17.569453 2016] [mpm_event:notice] [pid 2907:tid 140687491151744] AH00489: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Sun Jan 24 13:41:17.569459 2016] [core:notice] [pid 2907:tid 140687491151744] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 24 14:28:20.123049 2016] [mpm_event:notice] [pid 2907:tid 140687491151744] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.122.83. Set the 'ServerName' directive globally to suppress this message
[Sun Jan 24 14:28:20.134024 2016] [mpm_event:notice] [pid 2907:tid 140687491151744] AH00489: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Sun Jan 24 14:28:20.134043 2016] [core:notice] [pid 2907:tid 140687491151744] AH00094: Command line: '/usr/sbin/apache2'

==> /var/log/apache2/other_vhosts_access.log <==

• Définition du ServerName global

# echo "ServerName localhost" >> /etc/apache2/apache2.conf
# systemctl reload apache2
# journalctl -xn

Installation de modules

• Liste des modules disponibles

sudo apt-cache search libapache2*

• Installation d’un module

sudo apt-get install [module-name]

Les modules sont situés dans /etc/apache2/mods-avaiable. Activation d’un module

a2enmod [module-name]

• Pour désactiver un module

a2dismod [module-name]

2.2 Installation par les sources

Objectifs

• S’affranchir des cycles de vie et des distributions
• Installation de l’unique nécessaire
• D’être toujours à jour dans les versions du logiciel

Principe

Trois étapes/commandes de compilation

• configure qui configure la compilation
• make qui compile
• make install qui installe les bianires

Environnement d’installation et de production

• /opt/prod
• /opt/src

# mkdir -p /opt/{prod,src}
# chown user /opt/*
# exit
$ cd /opt/src
$ wget http://apache.belnet.be//httpd/httpd-2.4.18.tar.gz
httpd-2.4.18.tar.gz   100% [<====>]   6,72M  16,5MB/s   ds 0,4s

$ tar xvfz httpd-2.4.18.tar.gz

Compilation

• Installation des outils de base et librairies

# apt-get install ntpdate build-essential libpcre3-dev

Configuration de la compilation

• Tout d’abord se placer dans le dossier décompressé des sources

$ cd /opt/src/httpd-2.4.18/

• Exécuter le script ./configure --help
• Il est possible d’utiliser des modèles de compilation définis dan config.layout

$ head -n35 config.layout
##
##  config.layout -- Pre-defined Installation Path Layouts
##
##  Hints:
##  - layouts can be loaded with configure's --enable-layout=ID option
##  - when no --enable-layout option is given, the default layout is `Apache'
##  - a trailing plus character (`+') on paths is replaced with a
##    `/<target>' suffix where <target> is currently hardcoded to 'apache2'.
##    (This may become a configurable parameter at some point.)
##

#   Classical Apache path layout.
<Layout Apache>
    prefix:        /usr/local/apache2
    exec_prefix:   ${prefix}
    bindir:        ${exec_prefix}/bin
    sbindir:       ${exec_prefix}/bin
    libdir:        ${exec_prefix}/lib
    libexecdir:    ${exec_prefix}/modules
    mandir:        ${prefix}/man
    sysconfdir:    ${prefix}/conf
    datadir:       ${prefix}
    installbuilddir: ${datadir}/build
    errordir:      ${datadir}/error
    iconsdir:      ${datadir}/icons
    htdocsdir:     ${datadir}/htdocs
    manualdir:     ${datadir}/manual
    cgidir:        ${datadir}/cgi-bin
    includedir:    ${prefix}/include
    localstatedir: ${prefix}
    runtimedir:    ${localstatedir}/logs
    logfiledir:    ${localstatedir}/logs
    proxycachedir: ${localstatedir}/proxy
</Layout>

• Le lancement du script utilise ce modèle “Apache” par défaut.

./configure
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... no
configure: error: APR not found.  Please read the documentation.

• Il manque les librairies APR (Apache Portable Runtime)

$ cd /opt/src
$ wget http://apache.belnet.be//apr/apr-1.5.2.tar.gz
$ tar xvfz apr-1.5.2.tar.gz
$ mv apr-1.5.2 httpd-2.4.18/srclib/apr
$ wget http://apache.belnet.be//apr/apr-util-1.5.4.tar.gz
$ tar xvfz apr-util-1.5.4.tar.gz
$ mv apr-util-1.5.4 httpd-2.4.18/srclib/apr-util
$ cd /opt/src/httpd-2.4.18/

• Le script s’exécute correctement

$ ./configure

Vérification des paramètres (modules compilés, environnement, outils systèmes, etc.) sont journalisés dans config.log

less config.log

• On peut préparer un configuration en ajoutant un modèle “Lab” dans le fichier config.layoutet lancer la configuration

<Layout Lab>
    prefix:        /opt/prod/apache24
    exec_prefix:   ${prefix}
    bindir:        ${exec_prefix}/bin
    sbindir:       ${exec_prefix}/bin
    libdir:        ${exec_prefix}/lib
    libexecdir:    ${exec_prefix}/modules
    mandir:        ${prefix}/man
    sysconfdir:    ${prefix}/conf
    datadir:       ${prefix}
    installbuilddir: ${datadir}/build
    errordir:      ${datadir}/error
    iconsdir:      ${datadir}/icons
    htdocsdir:     ${datadir}/htdocs
    manualdir:     ${datadir}/manual
    cgidir:        ${datadir}/cgi-bin
    includedir:    ${prefix}/include
    localstatedir: ${prefix}
    runtimedir:    ${localstatedir}/logs
    logfiledir:    ${localstatedir}/logs
    proxycachedir: ${localstatedir}/proxy
</Layout>

$ ./configure --enable-layout=Lab

Compilation et installation

• Tout simplement avec les droits appropriés. Cela prend quelques minutes

$ make

• Installation des binaires

$ su
# make install

• Test de démarrage

# /opt/prod/apache24/bin/httpd -k start &

# ps aux | grep httpd
root     16037  0.0  0.3  79128  4068 ?        Ss   20:22   0:00 /opt/prod/apache24/bin/httpd -k start
daemon   16038  0.0  0.3 368092  3732 ?        Sl   20:22   0:00 /opt/prod/apache24/bin/httpd -k start
daemon   16039  0.0  0.3 368092  3732 ?        Sl   20:22   0:00 /opt/prod/apache24/bin/httpd -k start
daemon   16040  0.0  0.3 368092  3732 ?        Sl   20:22   0:00 /opt/prod/apache24/bin/httpd -k start
root     16128  0.0  0.2  12748  2172 pts/1    S+   20:24   0:00 grep httpd
root     18359  0.0  0.3  79128  3992 ?        Ss   16:11   0:00 sbin/httpd -k start
daemon   18360  0.0  0.3 368092  3816 ?        Sl   16:11   0:03 sbin/httpd -k start
daemon   18361  0.0  0.3 368092  3816 ?        Sl   16:11   0:03 sbin/httpd -k start
daemon   18362  0.0  0.3 368092  3816 ?        Sl   16:11   0:03 sbin/httpd -k start

# apt-get install curl
# curl -I 127.0.0.1
HTTP/1.1 200 OK
Date: Sun, 24 Jan 2016 19:25:04 GMT
Server: Apache/2.4.18 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 45
Content-Type: text/html

Script de démarrage

• Création d’un unit systemd dans /etc/systemd/system/apache24.service

[Unit]
Description=Apache Web Server
After=network.target

[Service]
ExecStart=/opt/prod/apache24/bin/httpd -DFOREGROUND
ExecReload=/opt/prod/apache24/bin/httpd -k graceful
ExecStop=/opt/prod/apache24/bin/httpd -k graceful-stop
PrivateTmp=true

[Install]
WantedBy=multi-user.target

• Commandes de démarrage

# systemctl start apache24.service

• Diagnostic

# systemctl status apache24.service
# journalctl -xn

• Redémarrage du service

# systemctl reload apache24.service

• Arrêt du service

# systemctl stop apache24.service

• Démarrage automatique

# systemctl enable apache24.service
Created symlink from /etc/systemd/system/multi-user.target.wants/apache24.service to /etc/systemd/system/apache24.service.

Ajout des binaires dans le PATH

echo "PATH=$PATH:/opt/prod/apache24/bin" >> /etc/bash.bashrc

Dernière vérification

# apachectl -V
Server version: Apache/2.4.18 (Unix)
Server built:   Jan 24 2016 20:11:22
Server's Module Magic Number: 20120211:52
Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/opt/prod/apache24"
 -D SUEXEC_BIN="/opt/prod/apache24/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Configuration de l’utilisateur apache24

• Utilisateurs root et daemon

# ps fu -C httpd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3199  0.0  0.4  74912  4128 ?        Ss   22:03   0:00 /opt/prod/apache24/bin/httpd -DFOREGROUND
daemon    3379  0.0  0.3 363876  3728 ?        Sl   22:04   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND
daemon    3380  0.0  0.3 363876  3728 ?        Sl   22:04   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND
daemon    3381  0.0  0.3 363876  3728 ?        Sl   22:04   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND

• Création d’un groupe et d’un utlisateur apache24

# addgroup --gid 9999 apache24
Ajout du groupe «apache24» (GID 9999)...
Fait.
root@debian8-02:/home/user# adduser --uid 9999 --gid 9999 --home /opt/prod/apache24/ --no-create-home --disabled-password --disabled-login --shell /bin/false apache24
Ajout de l'utilisateur «apache24» ...
Ajout du nouvel utilisateur «apache24» (9999) avec le groupe «apache24» ...
Le répertoire personnel «/opt/prod/apache24/» n'a pas été créé.
Modification des informations relatives à l'utilisateur apache24
Entrez la nouvelle valeur ou «Entrée» pour conserver la valeur proposée
	Nom complet []: Apache 2.4
	N° de bureau []:
	Téléphone professionnel []:
	Téléphone personnel []:
	Autre []:
Cette information est-elle correcte ? [O/n]O

• Remplacement dans le fichier httpd

sed -i -e 's/daemon/apache24/g' /opt/prod/apache24/conf/httpd.conf

• Vérification

# ps fu -C httpd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      9616  0.0  0.4  79128  4516 ?        Ss   22:58   0:00 /opt/prod/apache24/bin/httpd -DFOREGROUND
apache24  9617  0.0  0.3 368092  3792 ?        Sl   22:58   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND
apache24  9618  0.0  0.3 368092  3792 ?        Sl   22:58   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND
apache24  9619  0.0  0.3 368092  3792 ?        Sl   22:58   0:00  \_ /opt/prod/apache24/bin/httpd -DFOREGROUND

3. Fichiers de configuration

3.1. Installation par dépôt de paquetage

# tree -L 1 /etc/apache2/
/etc/apache2/
├── apache2.conf
├── conf-available
├── conf-enabled
├── envvars
├── magic
├── mods-available
├── mods-enabled
├── ports.conf
├── sites-available
└── sites-enabled

6 directories, 4 files

3.2. Installation et compilation par les sources selon un modèle

# tree -L 1 /opt/prod/apache24/
/opt/prod/apache24/
├── bin
├── build
├── cgi-bin
├── conf
├── error
├── htdocs
├── icons
├── include
├── lib
├── logs
├── man
├── manual
├── modules
└── run

14 directories, 0 files

# tree -L 1 /opt/prod/apache24/conf/
/opt/prod/apache24/conf/
├── extra
├── httpd.conf
├── magic
├── mime.types
└── original

3.3. Fichier de configuration de base

• Test httpd -S ne fait que tester la configuration sans lancer l’application

# httpd -S
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
ServerRoot: "/opt/prod/apache24"
Main DocumentRoot: "/opt/prod/apache24/htdocs"
Main ErrorLog: "/opt/prod/apache24/logs/error_log"
Mutex default: dir="/opt/prod/apache24/logs/" mechanism=default
PidFile: "/opt/prod/apache24/logs/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache24" id=9999
Group: name="apache24" id=9999

• Création du fichier de configuration

# echo "User apache24" > /opt/prod/apache24/conf/httpd_1.conf
# echo "Group apache24" >> /opt/prod/apache24/conf/httpd_1.conf

• Vérification du fichier httpd -s

# httpd -S -f /opt/prod/apache24/conf/httpd_1.conf
AH00526: Syntax error on line 1 of /opt/prod/apache24/conf/httpd_1.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration

• Activation du module unixd

# echo "LoadModule unixd_module modules/mod_unixd.so" >> /opt/prod/apache24/conf/httpd_1.conf

• Vérification

# httpd -S -f /opt/prod/apache24/conf/httpd_1.conf
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
ServerRoot: "/opt/prod/apache24"
Main DocumentRoot: "/opt/prod/apache24/htdocs"
Main ErrorLog: "/opt/prod/apache24/logs/error_log"
Mutex default: dir="/opt/prod/apache24/logs/" mechanism=default
PidFile: "/opt/prod/apache24/logs/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache24" id=9999
Group: name="apache24" id=9999

• Test réel

# httpd -f /opt/prod/apache24/conf/httpd_1.conf
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message
no listening sockets available, shutting down
AH00015: Unable to open logs

• Indication port 80

# echo "Listen 80" >> /opt/prod/apache24/conf/httpd_1.conf

• Nouveau test

# httpd -f /opt/prod/apache24/conf/httpd_1.conf
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message

# ps fu -C httpd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      9822  0.0  0.3  37740  3588 ?        Ss   23:16   0:00 httpd -f /opt/prod/apache24/conf/httpd_1.conf
apache24  9823  0.0  0.3 326704  3256 ?        Sl   23:16   0:00  \_ httpd -f /opt/prod/apache24/conf/httpd_1.conf
apache24  9824  0.0  0.3 326704  3256 ?        Sl   23:16   0:00  \_ httpd -f /opt/prod/apache24/conf/httpd_1.conf
apache24  9825  0.0  0.3 326704  3256 ?        Sl   23:16   0:00  \_ httpd -f /opt/prod/apache24/conf/httpd_1.conf

• Test de connexion

# curl -I 127.0.0.1
HTTP/1.1 500 Internal Server Error
Date: Sun, 24 Jan 2016 22:39:20 GMT
Server: Apache/2.4.18 (Unix)
Connection: close
Content-Type: text/html; charset=iso-8859-1

• Erreur 500 : vérification des logs

# tail /opt/prod/apache24/logs/error_log
[Sun Jan 24 23:39:20.841456 2016] [core:crit] [pid 9823:tid 140380997609216] [client 127.0.0.1:35986] AH00025: configuration error:  couldn't check user: /
root@debian8-02:/home/user# tail -n 1 /opt/prod/apache24/logs/error_log
[Sun Jan 24 23:39:20.841456 2016] [core:crit] [pid 9823:tid 140380997609216] [client 127.0.0.1:35986] AH00025: configuration error:  couldn't check user: /

• Il est nécessaire de charger le module authz_core

# echo "loadmodule authz_core_module modules/mod_authz_core.so" >> /opt/prod/apache24/conf/httpd_1.conf

• redémarrage du service

# apachectl stop
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message
# httpd -f /opt/prod/apache24/conf/httpd_1.conf
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message

• Test de connexion

# curl -I 127.0.0.1
HTTP/1.1 404 Not Found
Date: Sun, 24 Jan 2016 22:46:40 GMT
Server: Apache/2.4.18 (Unix)
Content-Type: text/html; charset=iso-8859-1

• Erreur 404, code 200 avec index.hml

# curl -I 127.0.0.1/index.html
HTTP/1.1 200 OK
Date: Sun, 24 Jan 2016 22:51:49 GMT
Server: Apache/2.4.18 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 45

• Vérification du fichier de configuration

# cat /opt/prod/apache24/conf/httpd_1.conf
User apache24
Group apache24
LoadModule unixd_module modules/mod_unixd.so
Listen 80
loadmodule authz_core_module modules/mod_authz_core.so

• Modules chargés

# apachectl -t -D DUMP_MODULES
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.170. Set the 'ServerName' directive globally to suppress this message
Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 mpm_event_module (static)
 authn_file_module (shared)
 authn_core_module (shared)
 authz_host_module (shared)
 authz_groupfile_module (shared)
 authz_user_module (shared)
 authz_core_module (shared)
 access_compat_module (shared)
 auth_basic_module (shared)
 reqtimeout_module (shared)
 filter_module (shared)
 mime_module (shared)
 log_config_module (shared)
 env_module (shared)
 headers_module (shared)
 setenvif_module (shared)
 version_module (shared)
 unixd_module (shared)
 status_module (shared)
 autoindex_module (shared)
 dir_module (shared)
 alias_module (shared)

4. Directives globales Core

Sources :

• https://httpd.apache.org/docs/2.4/fr/mod/core.html

4.1 ServerRoot

La directive ServerRoot permet de définir le répertoire dans lequel le serveur est installé. En particulier, il contiendra les sous-répertoires conf/ et logs/. Les chemins relatifs indiqués dans les autres directives (comme Include ou LoadModule) seront définis par rapport à ce répertoire.

4.2 ServerName

Terminologie :

• Serveur virtuel, hôte virtuel, “vhost” : instance HTTP répondant à un domaine sur un même serveur physqiue
• Nom canonique : nom standard dans l’URL

La directive ServerName permet de définir les protocole, nom d’hôte et port d’une requête que le serveur utilise pour s’authentifier lui-même.

La directive ServerName permet (éventuellement en conjonction avec la directive ServerAlias) d’identifier de manière unique un serveur virtuel, lorsqu’elle est utilisée dans un contexte de serveurs virtuels à base de noms.

Cette directive est aussi utilisée lors de la création d’URLs de redirection relatives quand la directive UseCanonicalName est définie à une valeur autre que la valeur par défaut.

Par exemple, si le nom de la machine hébergeant le serveur web est simple.example.com, la machine possède l’alias DNS www.example.com, et si vous voulez que le serveur web s’identifie avec cet alias, vous devez utilisez la définition suivante :

ServerName www.example.com

Si vous définissez des serveurs virtuels à base de nom, une directive ServerName située à l’intérieur d’une section <VirtualHost> spécifiera quel nom d’hôte doit apparaître dans l’en-tête de requête Host: pour pouvoir atteindre ce serveur virtuel.

4.3 ServerAlias

La directive ServerAlias permet de définir les noms alternatifs d’un serveur utilisables pour atteindre des serveurs virtuels à base de nom. La directive ServerAlias peut contenir des caractères génériques, si nécessaire.

<VirtualHost *:80>
  ServerName server.example.com
  ServerAlias server server2.example.com server2
  ServerAlias *.example.com
  UseCanonicalName Off
  # ...
</VirtualHost>

La recherche du serveur virtuel à base de nom correspondant au plus près à la requête s’effectue selon l’ordre d’apparition des directives <virtualhost> dans le fichier de configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est choisi, sans priorité particulière si le nom contient des caractères génériques (que ce soit pour ServerName ou ServerAlias).

Tous les noms spécifiés au sein d’une section VirtualHost sont traités comme un ServerAlias (sans caractères génériques).

4.4 ServerAdmin

La directive ServerAdmin permet de définir l’adresse de contact que le serveur va inclure dans tout message d’erreur qu’il envoie au client. Si le programme httpd ne reconnait pas l’argument fourni comme une URL, il suppose que c’est une adresse électronique, et lui ajoute le préfixe mailto: dans les cibles des hyperliens. Il est cependant recommandé d’utiliser exclusivement une adresse électronique, car de nombreux scripts CGI considèrent ceci comme implicite. Si vous utilisez une URL, elle doit pointer vers un autre serveur que vous contrôlez. Dans le cas contraire, les utilisateurs seraient dans l’impossibilité de vous contacter en cas de problème.

Il peut s’avérer utile de définir une adresse dédiée à l’administration du serveur, par exemple :

ServerAdmin www-admin@foo.example.com

car les utilisateurs ne mentionnent pas systématiquement le serveur dont ils parlent !

4.5 ServerSignature

• Syntaxe: ServerSignature On|Off|EMail
• Défaut: ServerSignature Off

La directive ServerSignature permet de définir une ligne de pied de page fixe pour les documents générés par le serveur (messages d’erreur, listings de répertoires ftp de mod_proxy, sorties de mod_info, etc…). Dans le cas d’une chaîne de mandataires, l’utilisateur n’a souvent aucun moyen de déterminer lequel des mandataires chaînés a généré un message d’erreur, et c’est une des raisons pour lesquelles on peut être amené à ajouter un tel pied de page.

La valeur par défaut Off supprime la ligne de pied de page (et est ainsi compatible avec le comportement des versions 1.2 et antérieures d’Apache). la valeur On ajoute simplement une ligne contenant le numéro de version du serveur ainsi que le nom du serveur virtuel issu de la directive ServerName, alors que la valeur EMail ajoute en plus une référence “mailto:” à l’administrateur du document référencé issu la directive ServerAdmin.

4.6. ServerTokens

• Syntaxe: ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
• Défaut: ServerTokens Full

Cette directive permet de contrôler le contenu de l’en-tête Server inclus dans la réponse envoyée au client : cet en-tête peut contenir le type de système d’exploitation du serveur, ainsi que des informations à propos des modules compilés avec le serveur.

• ServerTokens Full (ou non spécifié) : Le serveur envoie par exemple : Server: Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2
• ServerTokens Prod[uctOnly] : Le serveur renvoie (par exemple): Server: Apache
• ServerTokens Major : Le serveur renvoie (par exemple): Server: Apache/2
• ServerTokens Minor : Le serveur renvoie (par exemple): Server: Apache/2.4
• ServerTokens Min[imal] : Le serveur renvoie (par exemple): Server: Apache/2.4.2
• ServerTokens OS : Le serveur renvoie (par exemple): Server: Apache/2.4.2 (Unix)

Cette définition s’applique à l’ensemble du serveur et ne peut être activée ou désactivée pour tel ou tel serveur virtuel.

4.7 LoadModule

• Syntaxe: LoadModule module nom-fichier

La directive LoadModule permet de lier le fichier objet ou la bibliothèque nom-fichier avec le serveur, et d’ajouter la structure de module nommée module à la liste des modules actifs. module est le nom de la variable externe de type module dans le fichier, et est référencé comme Identificateur de module dans la documentation des modules. Exemple :

LoadModule status_module modules/mod_status.so

charge le module spécifié depuis le sous-répertoire des modules situé à la racine du serveur.

4.8 DocumentRoot

Cette directive permet de définir le répertoire à partir duquel httpd va servir les fichiers. S’il ne correspond pas à un Alias, le chemin de l’URL sera ajouté par le serveur à la racine des documents afin de construire le chemin du document recherché. Exemple :

DocumentRoot "/usr/web"

un accès à http://my.example.com/index.html se réfère alors à /usr/web/index.html. Si chemin répertoire n’est pas un chemin absolu, il est considéré comme relatif au chemin défini par la directive ServerRoot.

Le répertoire défini par la directive DocumentRoot ne doit pas comporter de slash final.

4.9 Error

Si une erreur peut être détectée dans la configuration, souvent un module manquant, cette directive peut être utilisée pour générer un message d’erreur personnalisé, et interrompre la lecture de la configuration.

Par exemple,

# vérification du chargement de mod_include
<IfModule !include_module>
  Error "mod_include is required by mod_foo.  Load it with LoadModule."
</IfModule>

# vérification de la définition de SSL ou (exclusif) NOSSL
<IfDefine SSL>
<IfDefine NOSSL>
  Error "Both SSL and NOSSL are defined.  Define only one of them."
</IfDefine>
</IfDefine>
<IfDefine !SSL>
<IfDefine !NOSSL>
  Error "Either SSL or NOSSL must be defined."
</IfDefine>
</IfDefine>

4.10 ErrorLog

La directive ErrorLog permet de définir le nom du fichier dans lequel le serveur va journaliser toutes les erreurs qu’il rencontre. Si le chemin fichier n’est pas absolu, il est considéré comme relatif au chemin défini par la directive ServerRoot.

ErrorLog "/var/log/httpd/error_log"

ErrorLog "|/usr/local/bin/httpd_errors"

Voir les notes à propos des journaux redirigés pour plus d’informations.

L’utilisation de syslog à la place d’un nom de fichier active la journalisation via syslogd(8) si le système le supporte. Le dispositif syslog par défaut est local7, mais vous pouvez le modifier à l’aide de la syntaxe syslog:facility, où “facility” peut être remplacé par un des noms habituellement documentés dans la page de man syslog(1). Le dispositif syslog local7 est global, et si il est modifié dans un serveur virtuel, le dispositif final spécifié affecte l’ensemble du serveur

ErrorLog syslog:user

Des modules supplémentaires peuvent fournir leurs propres fournisseurs ErrorLog. La syntaxe est similaire à celle de l’exemple syslog ci-dessus.

4.11 ErrorLogFormat

La directive ErrorLogFormat permet de spécifier quelles informations supplémentaires vont être enregistrées dans le journal des erreurs en plus du message habituel.

Voir https://httpd.apache.org/docs/2.4/fr/mod/core.html#errorlogformat pour la signification des codes.

• Exemple simple

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

• Exemple (format par défaut pour les MPMs threadés)

ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

Cet exemple renverrait un message d’erreur du style :

[Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico

Notez que certains champs sont totalement supprimés s’ils n’ont pas été définis.

• Exemple (similaire au format 2.2.x)

ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

• Exemple avancé avec identifiants journal de requête/connexion

ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"

4.12 LogLevel

La directive LogLevel permet d’ajuster la verbosité des messages enregistrés dans les journaux d’erreur (voir la directive ErrorLog). Les niveaux disponibles sont présentés ci-après, par ordre de criticité décroissante :

Lorsqu’un niveau particulier est spécifié, les messages de tous les autres niveaux de criticité supérieure seront aussi enregistrés. Par exemple, si LogLevel info est spécifié, les messages de niveaux notice et warn seront aussi émis.

Il est recommandé d’utiliser un niveau crit ou inférieur.

Par exemple :

LogLevel notice

Spécifier un niveau sans nom de module va attribuer ce niveau à tous les modules. Spécifier un niveau avec nom de module va attribuer ce niveau à ce module seulement.

Il est possible de spécifier un module par le nom de son fichier source ou par son identificateur, avec ou sans le suffixe _module. Les trois spécifications suivantes sont donc équivalentes :

LogLevel info ssl:warn
LogLevel info mod_ssl.c:warn
LogLevel info ssl_module:warn

Il est aussi possible d’attribuer un niveau de journalisation par répertoire :

LogLevel info
<Directory "/usr/local/apache/htdocs/app">
  LogLevel debug
</Directory>

4.13 ErrorDocument

Apache httpd peut traiter les problèmes et les erreurs de quatre manières :

1. afficher un simple message d’erreur au contenu fixe
   • afficher un message personnalisé
   • rediriger en interne vers un chemin d’URL local pour traiter le problème ou l’erreur
   • rediriger vers une URL externe pour traiter le problème ou l’erreur

La première option constitue le comportement par défaut; pour choisir une des trois autres options, il faut configurer Apache à l’aide de la directive ErrorDocument, suivie du code de la réponse HTTP et d’une URL ou d’un message. Apache httpd fournit parfois des informations supplémentaires à propos du problème ou de l’erreur.

A partir de la version 2.4.13, il est possible d’utiliser la syntaxe des expressions dans cette directive afin de générer des chaînes et URLs dynamiques.

Exemples :

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
ErrorDocument 403 Forbidden!
ErrorDocument 403 /cgi-bin/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}

4.14 Include et IncludeOptional

• Syntaxe: Include chemin-fichier|chemin-répertoire|wildcard
• Syntaxe: IncludeOptional chemin-fichier|chemin-répertoire|wildcard

La directive ```Include`` permet l’inclusion d’autres fichiers de configuration dans un des fichiers de configuration du serveur.

Pour inclure des fichiers qui correspondent à un certain modèle, comme *.conf par exemple, nous vous recommandons d’utiliser plutôt la syntaxe avec caractères génériques comme ci-dessous.

La directive Include échouera avec un code d’erreur si une expression contenant des caractères génériques ne correspond à aucun fichier. Pour ignorer les expressions contenant des caractères génériques ne correspondant à aucun fichier, utilisez la directive IncludeOptional.

Le chemin fichier spécifié peut être soit un chemin absolu, soit un chemin relatif au répertoire défini par la directive ServerRoot.

Exemples :

Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf

ou encore, avec des chemins relatifs au répertoire défini par la directive ServerRoot :

Include conf/ssl.conf
Include conf/vhosts/*.conf

On peut aussi insérer des caractères génériques dans la partie répertoires du chemin. Dans l’exemple suivant, la directive échouera si aucun sous-répertoire de conf/vhosts ne contient au moins un fichier ``*.conf` :

Include conf/vhosts/*/*.conf

Par contre, dans l’exemple suivant, la directive sera simplement ignorée si aucun sous-répertoire de conf/vhosts ne contient au moins un fichier *.conf :

IncludeOptional conf/vhosts/*/*.conf

IncludeOptional fonctionne de manière identique à la directive Include, à l’exception du fait que si l’expression avec caractères génériques wilcard ne correspond à aucun fichier ou répertoire, elle sera ignorée silencieusement au lieu de causer une erreur.

4..15 UseCanonicalName et UseCanonicalPhysicalPort

• Syntaxe: UseCanonicalPhysicalPort On|Off
• Défaut: UseCanonicalPhysicalPort Off

UseCanonicalName permet de définir la manière dont le serveur détermine son propre port.

Dans de nombreuses situations, Apache httpd doit construire une URL auto-identifiante – c’est à dire une URL qui fait référence au serveur lui-même. Avec UseCanonicalName On, Apache httpd va utiliser le nom d’hôte et le port spécifiés par la directive ServerName pour construire le nom canonique du serveur. Ce nom est utilisé dans toutes les URLs auto-identifiantes, et affecté aux variables SERVER_NAME et SERVER_PORT dans les programmes CGI.

Avec UseCanonicalName Off, Apache httpd va construire ses URLs auto-identifiantes à l’aide du nom d’hôte et du port fournis par le client, si ce dernier en a fourni un (dans la négative, Apache utilisera le nom canonique, de la même manière que ci-dessus). Ces valeurs sont les mêmes que celles qui sont utilisées pour implémenter les serveurs virtuels à base de nom, et sont disponibles avec les mêmes clients. De même, les variables CGI SERVER_NAME et SERVER_PORT seront affectées des valeurs fournies par le client.

Cette directive peut s’avérer utile, par exemple, sur un serveur intranet auquel les utilisateurs se connectent en utilisant des noms courts tels que www. Si les utilisateurs tapent un nom court suivi d’une URL qui fait référence à un répertoire, comme http://www/splat, sans le slash terminal, vous remarquerez qu’Apache httpd va les rediriger vers http://www.example.com/splat/. Si vous avez activé l’authentification, ceci va obliger l’utilisateur à s’authentifier deux fois (une première fois pour www et une seconde fois pour www.example.com – voir la foire aux questions sur ce sujet pour plus d’informations). Par contre, si UseCanonicalName est définie à Off, Apache httpd redirigera l’utilisateur vers http://www/splat/.

Pour l’hébergement virtuel en masse à base d’adresse IP, on utilise une troisième option, UseCanonicalName DNS, pour supporter les clients anciens qui ne fournissent pas d’en-tête Host:. Apache httpd effectue alors une recherche DNS inverse sur l’adresse IP du serveur auquel le client s’est connecté afin de construire ses URLs auto-identifiantes.

4..16 TimeOut

• Description: Temps pendant lequel le serveur va attendre certains évènements avant de considérer * qu’une requête a échoué
• Syntaxe: TimeOut secondes Défaut: TimeOut 60

4.17 KeepAlive

• Description: Active les connexions HTTP persistantes
• Syntaxe: KeepAlive On|Off
• Défaut: KeepAlive On

L’extension Keep-Alive de HTTP/1.0 et l’implémentation des connexions persistantes dans HTTP/1.1 ont rendu possibles des sessions HTTP de longue durée, ce qui permet de transmettre plusieurs requêtes via la même connexion TCP. Dans certains cas, le gain en rapidité pour des documents comportant de nombreuses images peut atteindre 50%. Pour activer les connexions persistantes, définissez KeepAlive On.

Lorsqu’un client utilise une connexion persistante, elle comptera pour une seule requête pour la directive MaxConnectionsPerChild, quel que soit le nombre de requêtes transmises via cette connexion.

4.18 MaxKeepAliveRequests

• Description: Nombre de requêtes permises pour une connexion persistante
• Syntaxe: MaxKeepAliveRequests nombre
• Défaut: MaxKeepAliveRequests 100

La directive MaxKeepAliveRequests permet de limiter le nombre de requêtes autorisées par connexion lorsque KeepAlive est à “on”. Si sa valeur est 0, le nombre de requêtes autorisées est illimité. Il est recommandé de définir une valeur assez haute pour des performances du serveur maximales.

Par exemple :

MaxKeepAliveRequests 500

4.19 KeepAliveTimeout

• Syntaxe: KeepAliveTimeout nombre[ms]
• Défaut: KeepAliveTimeout 5

KeepAliveTimeout permet de définir Le nombre de secondes pendant lesquelles Apache httpd va attendre une requête avant de fermer la connexion. Le délai peut être défini en millisecondes en suffixant sa valeur par ms. La valeur du délai spécifiée par la directive Timeout s’applique dès qu’une requête a été reçue.

Donner une valeur trop élévée à KeepAliveTimeout peut induire des problèmes de performances sur les serveurs fortement chargés. Plus le délai est élévé, plus nombreux seront les processus serveur en attente de requêtes de la part de clients inactifs.

4.20 HostnameLookups

• Syntaxe: HostnameLookups On|Off|Double
• Défaut: HostnameLookups Off

Cette directive active la recherche DNS afin de pouvoir journaliser les nom d’hôtes (et les passer aux programmes CGI et aux inclusions SSI via la variable REMOTE_HOST). La valeur Double déclenche une double recherche DNS inverse. En d’autres termes, une fois la recherche inverse effectuée, on lance une recherche directe sur le résultat de cette dernière. Au moins une des adresses IP fournies par la recherche directe doit correspondre à l’adresse originale (ce que l’on nomme PARANOID dans la terminologie “tcpwrappers”).

4.21 AccessFileName

Au cours du traitement d’une requête, le serveur recherche le premier fichier de configuration existant à partir de la liste de noms dans chaque répertoire composant le chemin du document, à partir du moment où les fichiers de configuration distribués sont activés pour ce répertoire.

Par exemple :

AccessFileName .acl

avant de renvoyer le document /usr/local/web/index.html, le serveur va rechercher les fichiers /.acl, /usr/.acl, /usr/local/.acl et /usr/local/web/.acl pour y lire d’éventuelles directives, à moins quelles n’aient été désactivées avec

<Directory "/">
    AllowOverride None
</Directory>

4.22 AllowOverride

• Description: Types de directives autorisées dans les fichiers .htaccess
• Syntaxe: AllowOverride All|None|type directive [type directive] ...
• Défaut: AllowOverride None à partir de la version 2.3.9, AllowOverride All pour les versions antérieures
• Contexte: répertoire : sections <Directory>

Lorsque le serveur trouve un fichier .htaccess (dont le nom est défini par la directive AccessFileName), il doit savoir lesquelles des directives placées dans ce fichier sont autorisées à modifier la configuration préexistante.

** Valable seulement dans les sections <Directory>**

La directive AllowOverride ne peut être utilisée que dans les sections <Directory> définies sans expressions rationnelles, et non dans les sections <Location>, <DirectoryMatch> ou <Files>.

**Lorsque cette directive et la directive AllowOverrideList sont définies à None, les fichiers .htaccess sont totalement ignorés. **Dans ce cas, le serveur n’essaiera même pas de lire les fichiers .htaccess du système de fichiers.

Lorsque cette directive est définie à All, toute directive valable dans le Contexte .htaccess sera autorisée dans les fichiers .htaccess.

Pour des raisons de sécurité et de performance, ne définissez pas AllowOverride à autre chose que None dans votre bloc <Directory "/">. Recherchez plutôt (ou créez) le bloc <Directory> qui se réfère au répertoire où vous allez précisément placer un fichier .htaccess.

4.23. Options

• Syntaxe: Options [+|-]option [[+|-]option] ...
• Défaut: Options FollowSymlinks
• Contexte: configuration du serveur, serveur virtuel, répertoire, .htaccess
• AllowOverride: Options
• Compatibilité: Avec la version 2.3.11, la valeur par défaut passe de All à FollowSymlinks

La directive Options permet de définir les fonctionnalités de serveur disponibles pour un répertoire particulier.

Options peut être défini à None, auquel cas aucune fonctionnalité spécifique n’est activée, ou comprendre une ou plusieurs des options suivantes :

• All Toutes les options excepté MultiViews.
• ExecCGI L’exécution de scripts CGI à l’aide du module mod_cgi est permise.
• FollowSymLinks Le serveur va suivre les liens symboliques dans le répertoire concerné. Il s’agit de la valeur par défaut.
• Includes Les inclusions côté serveur (SSI) à l’aide du module mod_include sont autorisées.
• IncludesNOEXEC Les inclusions côté serveur (SSI) sont permises, mais #exec cmd et #exec cgi sont désactivés. L’utilisation de #include virtual pour les scripts CGI est cependant toujours possible depuis des répertoires définis par ScriptAlias.
• Indexes Si une URL requise correspond au répertoire concerné, et si aucun DirectoryIndex (par exemple index.html) n’est défini pour ce répertoire, le module mod_autoindex va renvoyer un listing formaté du répertoire.
• MultiViews Les vues multiples (“multiviews”) à contenu négocié à l’aide du module mod_negotiation sont autorisées.
• SymLinksIfOwnerMatch Le serveur ne suivra que les liens symboliques qui renvoient vers un fichier ou un répertoire dont le propriétaire est le même que celui du lien.

Mélanger des Options avec + ou - avec des Options sans + ou - constitue une erreur de syntaxe, et la vérification de la syntaxe au cours du démarrage du serveur fera échouer ce dernier.

Par exemple, sans aucun symbole + et - :

<Directory "/web/docs">
  Options Indexes FollowSymLinks
</Directory>

<Directory "/web/docs/spec">
  Options Includes
</Directory>

ici, seule l’option Includes sera prise en compte pour le répertoire /web/docs/spec. Par contre, si la seconde directive Options utilise les symboles + et - :

<Directory "/web/docs">
  Options Indexes FollowSymLinks
</Directory>

<Directory "/web/docs/spec">
  Options +Includes -Indexes
</Directory>

alors, les options FollowSymLinks et Includes seront prises en compte pour le répertoire /web/docs/spec.

5. Directives MPM

https://httpd.apache.org/docs/2.4/fr/mod/mpm_common.html

https://httpd.apache.org/docs/2.4/fr/mod/prefork.html

https://httpd.apache.org/docs/2.4/fr/mod/worker.html

• 3.1 PidFile
• 3.2 Port d’écoute et protocole
• 3.3 ServerLimit
• 3.4 ThreadLimit
• 3.5 ThreadsPerChild
• 3.6 MaxRequestWorkers (anciennement MaxClients)
• 3.7 StartServers
• 3.8 MaxSpareServers (MPM Prefork)
• 3.9 MinSpareServers (MPM Prefork)
• 3.10 MaxSpareThreads
• 3.11 MinSpareThreads

6. Sections conteneurs

Source : https://httpd.apache.org/docs/2.4/fr/sections.html

Les directives peuvent être appliquées globalement pour le serveur mais aussi pour des ressources plus spécifiques comme :

• des répertoires et des fichiers
• des URI
• à l’intérieur des Hôtes Virtuels

et aussi sous conditions

• 2.1 <Directory>
• 2.2 <DirectoryMatch>
• 2.3 <Files>
• 2.4 <FilesMatch>
• 2.5 <Location>
• 2.6 <LocationMatch>
• 2.7 <VirtualHost>
• 2.8 <If>
• 2.9 <IfDefine>
• 2.10 <IfModule>

6.1. Conditions

La plupart des conteneurs sont évalués pour chaque requête. Les directives qu’ils contiennent s’appliquent seulement aux requêtes qui sont concernées par le conteneur.

En revanche, les conteneurs <IfDefine>, <IfModule>, et sont évalués seulement au démarrage et au redémarrage du serveur. Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les directives qu'ils contiennent seront ignorées.

Le conteneur <IfDefine> contient des directives qui ne seront appliquées que si un paramètre approprié a été défini dans la ligne de commande de httpd. Par exemple, avec la configuration suivante, toutes les requêtes seront redirigées vers un autre site si le serveur est démarré en utilisant la ligne de commande : httpd -DClosedForNow:

<IfDefine ClosedForNow>
    Redirect "/" "http://otherserver.example.com/"
</IfDefine>

Le conteneur <IfModule> est similaire; les directives qu’il contient ne s’appliqueront que si un module particulier est disponible au niveau du serveur. Le module doit être soit compilé statiquement dans le serveur, soit dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître plus haut dans le fichier de configuration. Ce conteneur ne doit être utilisé que dans le cas où votre fichier de configuration doit fonctionner indépendamment de la présence ou de l’absence de certains modules. Il ne doit pas contenir de directives que vous souhaitez voir s’appliquer systématiquement, car vous pouvez perdre ainsi de précieux messages d’erreur à propos de modules manquants.

Dans l’exemple suivant, la directive MimeMagicFile ne s’appliquera que si le module mod_mime_magic est disponible.

<IfModule mod_mime_magic.c>
    MimeMagicFile "conf/magic"
</IfModule>

Le conteneur <IfVersion> est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu’il contient ne s’appliqueront que si une version particulière du serveur s’exécute. Ce conteneur a été conçu pour une utilisation dans les suites de tests et les grands réseaux qui doivent prendre en compte différentes versions et configurations de httpd.

<IfVersion >= 2.4>
    # les directives situées ici ne s'appliquent que si la version
    # est supérieure ou égale à 2.4.0.
</IfVersion>

<IfDefine>, <IfModule>, et <IfVersion> peuvent inverser leur test conditionnel en le faisant précéder d’un “!”. De plus, ces sections peuvent être imbriquées afin de définir des restrictions plus complexes.

6.2. Système de fichiers, arborescence du site web et expressions booléennes

Les conteneurs de sections de configuration les plus couramment utilisés sont ceux qui modifient la configuration de points particuliers du système de fichiers ou de l’arborescence du site web. Tout d’abord, il est important de comprendre la différence entre les deux.

Le système de fichiers est une vue de vos disques tels qu’ils sont perçus par votre système d’exploitation. Par exemple, avec une installation par défaut, Apache httpd est situé dans /usr/local/apache2 pour le système de fichiers UNIX, ou “c:/Program Files/Apache Group/Apache2” pour le système de fichiers Windows. (Notez que des slashes directs doivent toujours être utilisés comme séparateur de chemin dans les fichiers de configuration d’Apache httpd, même sous Windows.)

Quant à l’arborescence du site web, il s’agit d’une vue de votre site tel que présenté par le serveur web et perçue par le client. Ainsi le chemin /dir/ dans l’arborescence du site web correspond au chemin /usr/local/apache2/htdocs/dir/ dans le système de fichiers pour une installation d’Apache httpd par défaut sous UNIX. En outre, l’arborescence du site web n’a pas besoin de correspondre en permanence au système de fichiers, car les pages web peuvent être générées dynamiquement à partir de bases de données ou d’autres emplacements.

6.3. Conteneurs de système de fichiers

Les conteneurs <Directory> et <Files>, ainsi que leurs équivalents acceptant les expressions rationnelles, appliquent des directives à certaines parties du système de fichiers. Les directives contenues dans une section <Directory> s’appliquent au répertoire précisé, ainsi qu’à tous ses sous-répertoires et aux fichiers que ces derniers contiennent. Le même effet peut être obtenu en utilisant les fichiers .htaccess.

Par exemple, avec la configuration suivante, l’indexation sera activée pour le répertoire /var/web/dir1 et tous ses sous-répertoires.

<Directory "/var/web/dir1">
    Options +Indexes
</Directory>

Les directives contenues dans une section <Files> s’appliquent à tout fichier avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve.

Ainsi par exemple, les directives de configuration suivantes, si elles sont placées dans la section principale du fichier de configuration, vont interdire l’accès à tout fichier nommé private.html quel que soit l’endroit où il se trouve.

<Files "private.html">
    Require all denied
</Files>

Pour faire référence à des fichiers qui se trouvent en des points particuliers du système de fichiers, les sections <Files> et <Directory> peuvent être combinées.

Par exemple, la configuration suivante va interdire l’accès à /var/web/dir1/private.html, /var/web/dir1/subdir2/private.html, /var/web/dir1/subdir3/private.html, ainsi que toute instance de private.html qui se trouve dans l’arborescence /var/web/dir1/.

<Directory "/var/web/dir1">
    <Files "private.html">
        Require all denied
    </Files>
</Directory>

6.4. Conteneurs de l’arborescence du site web

Le conteneur <Location> et son équivalent acceptant les expressions rationnelles, modifient quant à eux la configuration de parties de l’arborescence du site web. Par exemple, la configuration suivante interdit l’accès à toute URL dont la partie chemin commence par /private. En particulier, l’interdiction s’appliquera aux requêtes pour : http://yoursite.example.com/private, http://yoursite.example.com/private123, et http://yoursite.example.com/private/dir/file.html ainsi qu’à toute requête commençant par la chaîne de caractères /private.

<LocationMatch "^/private">
    Require all denied
</LocationMatch>

Le conteneur <Location> n’a pas besoin de faire référence à un élément du système de fichiers. Par exemple, l’exemple suivant montre comment faire référence à une URL particulière vers un gestionnaire interne du serveur HTTP Apache fourni par le module mod_status. Il n’est pas nécessaire de trouver un fichier nommé server-status dans le système de fichiers.

<Location "/server-status">
    SetHandler server-status
</Location>

6.5. Espace web imbriqué

Pour contrôler deux URLs imbriquées, on doit tenir compte de l’ordre dans lequel certaines sections ou directives sont évaluées. Pour <Location>, on doit avoir :

<Location "/foo">
</Location>
<Location "/foo/bar">
</Location>

Les directives <Alias>, quant à elles, sont évaluées vice-versa :

Alias “/foo/bar” “/srv/www/uncommon/bar” Alias “/foo” “/srv/www/common/foo”

Ceci est aussi vrai pour les directives ProxyPass :

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On

6.6. Caractères de remplacement et expressions rationnelles

Les conteneurs <Directory>, <Files>, et <Location> peuvent utiliser des caractères de remplacement de style shell comme dans la fonction fnmatch de la bibliothèque C standard. Le caractère “*” correspond à toute séquence de caractères, “?” à un caractère seul, et “[seq]” à tout caractère contenu dans seq. Le caractère “/” ne peut pas faire l’objet d’un remplacement; il doit être spécifié explicitement.

Si une définition des critères de correspondance encore plus souple est nécessaire, chaque conteneur possède son équivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les expressions rationnelles compatibles Perl pour définir les critères de correspondance. Mais voyez plus loin la section à propos de la combinaison des sections de configuration pour comprendre comment l’utilisation de conteneurs avec des expressions rationnelles va modifier la manière dont les directives sont appliquées.

Un conteneur qui modifie la configuration de tous les répertoires utilisateurs à l’aide de caractères de remplacement mais sans utiliser les expressions rationnelles pourrait ressembler à ceci :

<Directory "/home/*/public_html">
    Options Indexes
</Directory>

Avec les conteneurs utilisant les expressions rationnelles, on peut interdire l’accès à de nombreux types de fichiers d’images simultanément :

<FilesMatch "\.(?i:gif|jpe?g|png)$">
    Require all denied
</FilesMatch>

Les expressions rationnelles contenant des groupes nommés et des références arrières sont ajoutées à l’environnement avec leur nom en majuscules. Ceci permet de référencer des éléments de chemins de fichiers et d’URLs depuis une expression et au sein de modules comme mod_rewrite.

<DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
    require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
</DirectoryMatch>

6.7. Expressions booléennes

La directive <If> permet de modifier la configuration en fonction d’une condition qui peut être définie sous la forme d’une expression booléenne. Dans l’exemple suivant, l’accès est interdit si l’en-tête HTTP Referer ne commence pas par “http://www.example.com/”.

<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
    Require all denied
</If>

6.8. Que faut-il utiliser et quand ?

Choisir entre des conteneurs de système de fichiers et des conteneurs d’arborescence du site web est vraiment très simple.

Pour appliquer des directives à des objets qui résident dans le système de fichiers, utilisez toujours un conteneur <Directory> ou <Files>.

Pour appliquer des directives à des objets qui ne résident pas dans le système de fichiers (comme une page web générée par une base de données), utilisez un conteneur <Location>.

Il ne faut jamais utiliser un conteneur <Location> pour restreindre l’accès à des objets du système de fichiers, car plusieurs localisations de l’arborescence du site web (URLs) peuvent correspondre à la même localisation du système de fichier, ce qui peut permettre de contourner vos restrictions.

Par exemple, imaginez la configuration suivante :

<Location "/dir/">
    Require all denied
</Location>

Elle fonctionne correctement si la requête appelle http://yoursite.example.com/dir/. Mais que va-t-il se passer si votre système de fichiers est insensible à la casse ?

Votre restriction va pouvoir être tout simplement contournée en envoyant une requête sur http://yoursite.example.com/DIR/.

Le conteneur <Directory>, quant à lui, s’appliquera à tout contenu servi à partir de cette localisation, sans tenir compte de la manière dont il est appelé. (Les liens du système de fichiers constituent une exception. Le même répertoire peut être placé dans plusieurs parties du système de fichiers en utilisant des liens symboliques. Le conteneur <Directory> va suivre le lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de sécurité, les liens symboliques doivent être désactivés à l’aide de la directive Options appropriée.)

Si vous pensez que vous n’êtes pas concerné par ce problème parce que vous utilisez un système de fichiers sensible à la casse, gardez à l’esprit qu’il y a de nombreuses autres manières pour faire correspondre plusieurs localisations de l’arborescence du site web à la même localisation du système de fichiers. C’est pourquoi vous devez autant que possible toujours utiliser les conteneurs de système de fichiers. Il y a cependant une exception à cette règle. Placer des restrictions de configuration dans un conteneur <Location "/"> est tout à fait sans risque car ce conteneur va s’appliquer à toutes les requêtes sans tenir compte de l’URL spécifique.

6.9. Imbrication des sections

Certains types de sections peuvent être imbriqués :

• d’une part, on peut utiliser les sections <Files> à l’intérieur des sections <Directory>,
• d’autre part, on peut utiliser les directives <If> à l’intérieur des sections <Directory>, <Location> et <Files>.

Les valeurs des expressions rationnelles correspondant aux sections nommées se comportent de manière identique.

Les sections imbriquées sont fusionnées après les sections non-imbriquées de même type.

6.10. Hôtes virtuels

Le conteneur <VirtualHost> contient des directives qui s’appliquent à des hôtes spécifiques. Ceci s’avère utile pour servir des hôtes multiples à partir de la même machine, chacun d’entre eux possédant une configuration différente. Pour de plus amples informations, voir la Documentation sur les hôtes virtuels.

6.11. Mandataire

Les conteneurs <Proxy> et <ProxyMatch> appliquent les directives de configuration qu’ils contiennent uniquement aux sites qui correspondent à l’URL spécifiée et auxquels on a accédé via le serveur mandataire du module mod_proxy. Par exemple, la configuration suivante va interdire l’utilisation du serveur proxy pour accéder au site www.example.com.

<Proxy "http://www.example.com/*">
    Require all granted
</Proxy>

6.12. Quelles sont les directives autorisées ?

Pour déterminer quelles sont les directives autorisées pour tel type de section de configuration, vérifiez le Contexte de la directive. Tout ce qui est autorisé dans les sections <Directory> l’est aussi d’un point de vue syntaxique dans les sections <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy>, et <ProxyMatch>. Il y a cependant quelques exceptions :

• La directive AllowOverride ne fonctionne que dans les sections <Directory>.
• Les Options FollowSymLinks et SymLinksIfOwnerMatch ne fonctionnent que dans les sections <Directory> ou les fichiers .htaccess.
• La directive Options ne peut pas être utilisée dans les sections <Files> et <FilesMatch>.

6.13. Comment les sections sont-elles combinées entre elles ?

Les sections de configuration sont appliquées dans un ordre très particulier. Il est important de savoir comment cet ordre est défini car il peut avoir des effets importants sur la manière dont les directives de configuration sont interprétées.

L’ordre dans lequel les sections sont combinées est :

1. Les sections <Directory> (à l’exception des expressions rationnelles) et les fichiers .htaccess sont appliqués simultanément (avec la possibilité pour .htaccess, s’il y est autorisé, de prévaloir sur <Directory>)
   • Les sections <DirectoryMatch> (et <Directory "~">)
   • Les sections <Files> et <FilesMatch> sont appliquées simultanément
   • Les sections <Location> et <LocationMatch> sont appliquées simultanément
   • Les directives <If>

Mises à part les sections <Directory>, chaque groupe est traité selon l’ordre dans lequel il apparaît dans les fichiers de configuration. Les sections <Directory> (groupe 1 ci-dessus) sont traitées dans l’ordre du répertoire le plus court vers le plus long. Par exemple, <Directory "/var/web/dir"> sera traité avant <Directory "/var/web/dir/subdir">. Si plusieurs sections <Directory> s’appliquent au même répertoire, elles sont traitées selon l’ordre dans lequel elles apparaissent dans le fichier de configuration. Les sections de configuration incluses via la directive Include sont traitées comme si elles se trouvaient réellement dans le fichier qui les inclut à la position de la directive Include.

Les sections situées à l’intérieur de sections <VirtualHost> sont appliquées après les sections correspondantes situées en dehors de la définition de l’hôte virtuel, ce qui permet à l’hôte virtuel de prévaloir sur la configuration du serveur principal.

Quand la requête est servie par le module mod_proxy, le conteneur <Proxy> prend la place du conteneur <Directory> dans l’ordre de traitement.

Les sections situées plus loin dans le fichier de configuration prévalent sur celles qui les précèdent ; cependant, chaque module est responsable de la définition de la forme que doit prendre cette prévalence. Une section de configuration ultérieure contenant des directives d’un certain module peut être à l’origine d’une fusion conceptuelle de certaines directives, de toutes les directives, ou un remplacement complet de la configuration du module par ses valeurs par défaut et les directives explicitement définies dans cette section ultérieure.

Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte de toute restriction d’accès placée dans les sections , la section sera évaluée en dernier et permettra un accès au serveur sans aucune restriction. En d'autres termes, l'ordre de la combinaison des sections est important, soyez donc prudent !

<Location "/">
    Require all granted
</Location>

# Arrghs!  Cette section <Directory> n'aura aucun effet
<Directory "/">
    <RequireAll>
        Require all granted
        Require not host badguy.example.com
    </RequireAll>
</Directory>

7. Serveurs virtuels par nom

Source : https://httpd.apache.org/docs/2.4/fr/vhosts/name-based.html

7.1. Serveurs virtuels par nom vs. par IP

Les serveurs virtuels par IP utilisent l’adresse IP de la connexion afin de déterminer quel serveur virtuel doit répondre. Par conséquent, vous devez disposer d’adresses IP différentes pour chaque serveur.

Avec un hébergement virtuel par nom, le serveur s’appuie sur les informations transmises par le client dans les en-têtes HTTP de ses requêtes. La technique présentée ici vous permet de disposer de serveurs virtuels différents partagés sur une même adresse IP.

L’hébergement virtuel par nom est habituellement plus simple, car il vous suffit de configurer votre serveur DNS pour que chaque domaine pointe sur l’adresse IP dont vous disposez, et de configurer votre serveur Apache HTTP afin qu’il reconnaisse ces domaines. Il réduit aussi la pénurie en adresses IP. Par conséquent, vous devriez utiliser l’hébergement virtuel par nom, sauf dans le cas où vous utiliseriez des équipements qui nécessitent un hébergement basé sur IP. Les raisons historiques de l’hébergement basé sur IP dans un but de support de certains clients ne s’appliquent plus à un serveur web d’usage général.

La sélection du serveur virtuel en fonction du nom s’opère en dehors de l’algorithme de sélection du serveur virtuel en fonction de l’adresse IP, ce qui signifie que les recherches du point de vue du nom du serveur ne s’effectuent que parmi le jeu de serveurs virtuels pour lesquels la correspondance avec la paire adresse IP/port est la plus exacte.

7.2. Comment le serveur sélectionne-t-il le serveur virtuel basé sur le nom approprié

Il est important de savoir que la première étape de la résolution de serveur virtuel basée sur le nom est une résolution basée sur IP. La résolution de serveur virtuel basée sur le nom ne fait que choisir le serveur virtuel basé sur le nom le plus approprié, en se limitant aux candidats qui conviennent le mieux du point de vue IP. La résolution basée sur IP est sans objet si l’on utilise un caractère générique (*) pour l’adresse IP dans toutes les directives VirtualHost.

A l’arrivée d’une requête, le serveur va rechercher l’argument de section <VirtualHost> présentant la meilleure (la plus exacte) correspondance avec la paire adresse IP/port utilisée dans la requête. Si plusieurs serveurs virtuels possèdent cette même paire adresse IP/port, Apache va ensuite comparer les valeurs des directives ServerName et ServerAlias avec le nom de serveur présent dans la requête.

Si vous ne définissez pas de directive ServerName pour un serveur virtuel à base de nom, le serveur utilisera par défaut le nom de domaine entièrement qualifié (FQDN) déduit du nom d’hôte système. Cette configuration sans nom de serveur explicite peut conduire à des erreurs de choix du serveur virtuel à utiliser et est déconseillée.

Le serveur virtuel à base de nom par défaut pour une paire adresse IP/port Si aucune directive ServerName ou ServerAlias ne correspond dans la liste de serveurs virtuels présentant la meilleure correspondance du point de vue adresse IP/port, c’est le premier serveur virtuel de cette liste qui sera utilisé.

7.3. Utilisation de serveurs virtuels par nom

• Modules Apparentés : Core
• Directives Apparentées
• DocumentRoot
• ServerAlias
• ServerName

La première étape consiste à créer une section <VirtualHost> pour chacun des serveurs à définir. Dans chaque section <VirtualHost>, vous devez définir au minimum une directive ServerName pour désigner le serveur concerné et une directive DocumentRoot pour préciser l’emplacement sur le système de fichiers du contenu de ce serveur.

Le serveur principal disparaît

Par exemple, supposez que vous hébergez le domaine www.example.com et que vous souhaitez ajouter le serveur virtuel other.example.com qui pointe sur la même adresse IP. Il vous suffit d’ajouter la configuration suivante à httpd.conf :

<VirtualHost *:80>
    # Le premier serveur virtuel de la liste est aussi le
    # serveur par défaut pour *:80
    ServerName www.example.com
    ServerAlias example.com
    DocumentRoot "/www/domain"
</VirtualHost>

<VirtualHost *:80>
    ServerName other.example.com
    DocumentRoot "/www/otherdomain"
</VirtualHost>

Autrement, vous pouvez spécifiez une adresse IP explicite à la place de * dans la directive <VirtualHost>. Par exemple, cette méthode est utile si vous souhaitez faire tourner quelques serveurs virtuels par nom sur une même adresse IP, et d’autres, soit par IP, soit basés sur un autre jeu de serveurs virtuels par nom sur une autre adresse IP.

Plusieurs serveurs sont accessibles par plus d’un nom. Il suffit de placer la directive ServerAlias dans une section <VirtualHost>. Par exemple, dans la première section <VirtualHost> ci-dessus, la directive ServerAlias indique aux utilisateurs les autres noms permis pour accéder au même site Web :

ServerAlias example.com *.example.com

ainsi, toutes les requêtes portant sur un domaine example.com seront servies par le serveur virtuel www.example.com. Les caractères joker * et ? peuvent être utilisés pour les correspondances. Bien entendu, vous ne pouvez pas inventer des noms et les placer dans une directive ServerName ou ServerAlias. Tout d’abord, votre serveur DNS doit être correctement configuré pour lier ces noms à une adresse IP associée avec votre serveur.

La recherche du serveur virtuel à base de nom qui correspond au plus près à la requête s’effectue parmi les <virtualhost> selon leur ordre d’apparition dans le fichier de configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans priorité particulière en cas de présence de caractères génériques (que ce soit pour le ServerName ou le ServerAlias).

La liste complète des noms dans la section VirtualHost sont traités comme une directive ServerAlias sans caractères génériques.

Finalement, vous pouvez affiner la configuration des serveurs virtuels en plaçant d’autres directives à l’intérieur des sections <VirtualHost>. La plupart des directives peut être placée dans ces sections en y changeant seulement la configuration du serveur virtuel associé. Pour déterminer si une directive particulière est permise, consultez le contexte de la directive. Le jeu de directives configurées dans le contexte du serveur principal (en dehors de toutes sections <VirtualHost>) sera utilisé seulement s’il n’y a pas de configuration contraire par un serveur virtuel.

7.4. Exemples de configuration VirtualHost

Source : https://httpd.apache.org/docs/2.4/fr/vhosts/examples.html Source : https://httpd.apache.org/docs/2.4/fr/vhosts/mass.html

8. Modules de base

8.1. mod_unixd (unixd_module)

Sécurité de base (nécessaire) pour les plates-formes de la famille Unix.

https://httpd.apache.org/docs/2.4/fr/mod/mod_unixd.html

• 1.1 User
• 1.2 Group
• 1.3 ChrootDir
• 1.4 Suexec

8.2. mod_authz_core (authz_core_module)

https://httpd.apache.org/docs/2.4/fr/mod/mod_authz_host.html

• 2.1 Require
• 2.2 RequireAll
• 2.3 RequireAny
• 2.4 RequireNone

Ce module fournit des fonctionnalités d’autorisation basiques permettant d’accorder ou refuser l’accès à certaines zones du site web aux utilisateurs authentifiés. mod_authz_core donne la possibilité d’enregistrer divers fournisseurs d’autorisation. Il est en général utilisé avec un module fournisseur d’authentification comme mod_authn_file, et un module d’autorisation comme mod_authz_user. Il permet aussi l’application d’une logique élaborée au déroulement du processus d’autorisation.

8.3. Les directives Require

Le module mod_authz_core met à disposition des fournisseurs d’autorisation génériques utilisables avec la directive Require.

Require env

Le fournisseur env permet de contrôler l’accès au serveur en fonction de l’existence d’une variable d’environnement. Lorsque Require env env-variable est spécifié, la requête se voit autoriser l’accès si la variable d’environnement env-variable existe. Le serveur permet de définir facilement des variables d’environnement en fonction des caractéristiques de la requête du client via les directives fournies par le module mod_setenvif. Cette directive Require env permet donc de contrôler l’accès en fonction des valeurs des en-têtes de la requête HTTP tels que User-Agent (type de navigateur), Referer, entre autres.

SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory "/docroot">
    Require env let_me_in
</Directory>

Avec cet exemple, les navigateurs dont la chaîne user-agent commence par KnockKnock/2.0 se verront autoriser l’accès, alors que tous les autres seront rejetés.

Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la recherche d’un DirectoryIndex), ou lorsqu’il génère un listing du contenu d’un répertoire via le module mod_autoindex, la sous-requête n’hérite pas des variables d’environnement spécifiques à la requête. En outre, à cause des phases de l’API auxquelles mod_setenvif prend part, les directives SetEnvIf ne sont pas évaluées séparément dans la sous-requête.

Require all

Le fournisseur all reproduit la fonctionnalité précédemment fournie par les directives ‘Allow from all’ et ‘Deny from all’. Il accepte un argument dont les deux valeurs possibles sont : ‘granted’ ou ‘denied’. Les exemples suivants autorisent ou interdisent l’accès à toutes les requêtes.

Require all granted

Require all denied

Require method

Le fournisseur method permet d’utiliser la méthode HTTP dans le processus d’autorisation. Les méthodes GET et HEAD sont ici considérées comme équivalentes. La méthode TRACE n’est pas supportée par ce fournisseur ; utilisez à la place la directive TraceEnable.

Dans l’exemple suivant, seules les méthodes GET, HEAD, POST, et OPTIONS sont autorisées :

Require method GET POST OPTIONS

Dans l’exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS sont autorisées sans authentification, alors que toutes les autres méthodes nécessitent un utilisateur valide :

<RequireAny>
     Require method GET POST OPTIONS
     Require valid-user
</RequireAny>

Require expr

Le fournisseur expr permet d’accorder l’autorisation d’accès de base en fonction d’expressions arbitraires.

Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"

<RequireAll>
    Require expr "!(%{QUERY_STRING} =~ /secret/)"
    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
</RequireAll>

Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"

La syntaxe de l’expression est décrite dans la documentation de ap_expr.

Normalement, l’expression est évaluée avant l’authentification. Cependant, si l’expression renvoie false et se réfère à la variable %{REMOTE_USER}, le processus d’authentification sera engagé et l’expression réévaluée.

8.4. Modules Authentification et autorisation

Source : https://httpd.apache.org/docs/2.4/fr/howto/auth.html

mod_authn_core (authn_core_module)

• 3.1 AuthName
• 3.2 AuthType
• 3.3 AuthnProviderAlias

mod_auth_basic (auth_basic_module)

• 4.1 AuthBasicProvider
• 4.2 AuthBasicAuthoritative
• 4.3 AuthBasicProvider
• 4.4 AuthBasicUseDigestAlgorithm

mod_authn_file (authn_file_module)

• 5.1 AuthUserFile

mod_authz_user (authz_user_module)

8.5. Modules de négociation du contenu

https://httpd.apache.org/docs/2.4/fr/content-negotiation.html

mod_mime (mime_module)

• 7.1 AddCharset
• 7.2 AddLanguage
• 7.3 AddEncoding
• 7.4 AddHandler
• 7.5 AddType
• 7.6 AddInputFilter
• 7.7 AddOutputFilter
• 7.8 DefaultLanguage
• 7.9 RemoveCharset
• 7.10 RemoveEncoding
• 7.11 RemoveHandler
• 7.12 RemoveInputFilter
• 7.13 RemoveOutputFilter
• 7.14 RemoveLanguage
• 7.15 RemoveType
• 7.16 TypesConfig

module mod_negotiation (negotiation_module)

• 8.1 ForceLanguagePriority
• 8.2 LanguagePriority

8.6. Module mod_log_config (log_config_module)

https://httpd.apache.org/docs/2.4/fr/mod/mod_log_config.html

https://httpd.apache.org/docs/2.4/fr/mod/mod_log_forensic.html

• 9.1 CustomLog
• 9.2 LogFormat
• 9.3 TransferLog

8.7. mod_dir (dir_module)

• 10.1 DirectoryIndex
• 10.2 DirectoryIndexRedirect
• 10.3 DirectorySlash
• 10.4 FallbackResource

8.8. mod_rewrite (rewrite_module)

• 11.1 RewriteBase
• 11.2 RewriteCond
• 11.3 RewriteEngine
• 11.4 RewriteMap
• 11.5 RewriteRule

https://httpd.apache.org/docs/2.4/fr/mod/mod_rewrite.html

https://httpd.apache.org/docs/2.4/fr/rewrite/

https://httpd.apache.org/docs/2.4/fr/rewrite/remapping.html

https://httpd.apache.org/docs/2.4/fr/rewrite/flags.html

https://httpd.apache.org/docs/2.4/fr/rewrite/intro.html#regex

8.9. mod_alias (alias_module)

https://httpd.apache.org/docs/2.4/fr/mod/mod_alias.html

• 12.1 Alias
• 12.2 AliasMatch
• 12.3 Redirect
• 12.4 RedirectMatch
• 12.5 RedirectPermanent
• 12.6 RedirectTemp
• 12.7 ScriptAlias
• 12.8 ScriptAliasMatc

9. Gestion des logs

Définition journaux, audit, logs, événements, debug, analytique, syslog

9.1. Discussion

• Surveillance et gestion
• Forensic
• Consommation en stockage et en bande passante

9.2. Formats

• Format
• Pertinence des informations

9.3. Horodatage

• NTP
• Localisation

9.4. Rotation

9.5. Centralisation

Syslog

Alertes

9.6 Analyses

• Google Analytics v. AwStats ?
• http://www.awstats.org/ *

9.7. Surveillance

• Nagios

10. Cas pratiques

10.1. Automatisation de la compilation d’Apache 2.4

#!/bin/bash
srcd="/opt/src"
prodd="/opt/prod"
wdir=$(pwd)

compilation(){
echo "----> Création des répertoires $srcd $prodd"
[ -d "$srcd" ] || mkdir -p $srcd
[ -d "$prodd" ] || mkdir -p $prodd

echo "----> Mise a jour"
apt-get update && apt-get -y upgrade
clear

echo "----> Installation des prérequis"
apt-get -y install build-essential make gcc libpcre3-dev lynx curl unzip dnsutils tree
clear

echo "----> Création groupe et utilisateur apache24"
addgroup --system --gid 50000 apache24
adduser --quiet --gecos "" --home ${prodd}/apache/ --shell /bin/false --uid 50000 --gid 50000 --disabled-password --disabled-login apache24

echo "----> Installation Apache 2.4.18"
[ -f "${wdir}/httpd-2.4.18.tar.gz" ] || wget -O ${wdir}/httpd-2.4.18.tar.gz https://archive.apache.org/dist/httpd/httpd-2.4.18.tar.gz
[ -f "${wdir}/apr-util-1.5.4.tar.gz" ] || wget -O ${wdir}/apr-util-1.5.4.tar.gz https://archive.apache.org/dist/apr/apr-util-1.5.4.tar.gz
[ -f "${wdir}/apr-1.5.2.tar.gz" ] || wget -O ${wdir}/apr-1.5.2.tar.gz https://archive.apache.org/dist/apr/apr-1.5.2.tar.gz

cp ${wdir}/httpd-2.4.18.tar.gz ${srcd}/
cd $srcd
tar xvzf httpd-2.4.18.tar.gz && cd httpd-2.4.18/srclib
cp ${wdir}/apr-util-1.5.4.tar.gz . && tar xvzf apr-util-1.5.4.tar.gz && mv apr-util-1.5.4 apr-util
cp ${wdir}/apr-1.5.2.tar.gz . && tar xvzf apr-1.5.2.tar.gz && mv apr-1.5.2 apr
cd ..
./configure --prefix=${prodd}/apache --enable-nonportable-atomics=yes --with-included-apr
make
make install
echo ""
}

service(){
echo "----> Création du service"
cat << EOF > /etc/systemd/system/apache24.service
[Unit]
Description=Apache Web Server
After=network.target

[Service]
ExecStart=${prodd}/apache/bin/httpd -DFOREGROUND
ExecReload=${prodd}/apache/bin/httpd -k graceful
ExecStop=${prodd}/apache/bin/httpd -k graceful-stop
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF
systemctl enable apache24
echo ""
echo "----> PATH et environnement"
echo 'PATH=$PATH:'${prodd}'/apache/bin' >> /etc/bash.bashrc
echo 'export HOSTNAME=$(hostname)' >> ${prodd}/apache/bin/envvars
echo "ServerName $HOSTNAME" >> ${prodd}/apache/conf/httpd.conf
clear
}

activation(){
systemctl start apache24
sleep 10
echo "----> Installation Apache 2.4.18 terminée"
echo "----> Statut du service"
systemctl status apache24
echo "----> Test de connexion HTTP"
curl -i 127.0.0.1
echo "----> Fichier de configuration par défaut"
grep "^[^#|^$|^ *$]" ${prodd}/apache/conf/httpd.conf
}

compilation
service
activation

10.2. hébergement d’hôtes virtuels

Commande utiles :

• apachectl testconfig
• apt-get update && apt-get -y install curl vim apache2 apache2-doc apache2-utils
• Configuration à répéter pour plusieurs sites virtuels

Objectifs

• Configuration générale
• Hébergement de plusieurs hôtes virtuels monsite01.xyz, monsite02.xyz, etc.
• Fichiers HTML dans /opt/monsite01/www
• Fichiers de logs centralisés dans /opt/prod/log/www/

Configuration d’un seul site virtuel

Création des dossiers

mkdir -p /opt/prod/log/www
mkdir -p /opt/prod/monsite01/www
mkdir -p /opt/prod/monsite02/www
...

Fichier index.html

<html>
<header></header>
<body><title>Page de test</title><h1>It Works !</h1></body>
</html>

chown -R user /opt/prod/monsite*

Configuration générale

En un seul fichier en gardant les Include par défaut :

# Configuration globale
ServerRoot "/etc/apache2"
Mutex file:${APACHE_LOCK_DIR} default
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 300
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ServerName $HOSTNAME

# Ports
Listen 80
<IfModule ssl_module>
	Listen 443
</IfModule>

# Include
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

# Tout est interdit par défaut, protection .htaccess

<Directory />
	Options FollowSymLinks
	AllowOverride None
	Require all denied
</Directory>

AccessFileName .htaccess
<FilesMatch "^\.ht">
	Require all denied
</FilesMatch>

# Logs
ErrorLog /opt/prod/log/www/error.log
LogLevel warn
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Hôtes virtuels

• Création d’un hôte virtuel monsite01.xyz dans sites-available/000_monsite01.xyz.conf

<VirtualHost *:80>
	ServerName monsite01.xyz
        ServerAlias *.monsite01.xyz
	ServerAdmin webmaster@monsite01.xyz
	DocumentRoot /opt/prod/monsite01/www
	ErrorLog /opt/prod/log/www/monsite01.xyz_error.log
	CustomLog /opt/prod/log/www/monsite01.xyz_access.log combined
        <Directory /opt/prod/monsite01/www>
		Require all granted
	</Directory>
</VirtualHost>

• Désactivation du site par défaut

a2dissite 000-default

• Activation du site 000_monsite01.xyz

a2ensite 000_monsite01.xyz

• Ajout d’entrées DNS

echo "127.0.0.1 monsite01.xyz www.monsite01.xyz" >> /etc/hosts

• test de la configuration

apachectl configtest

• Redémarrage du service

systemctl reload apache2

• Connection HTTP

curl -i monsite01.xyz
curl -i www.monsite01.xyz

10.3. Automatisation des hôtes virtuels

1. Création d’un fichier Macro /etc/apache2/macro.conf
   • Include macro.conf
   • Création des dossiers
   • Création des fichiers index.html
   • Activation de la macro
   • Configuration DNS local
   • Activation du module macro
   • Redémarrage
   • Tests de connexion

#!/bin/bash

id="\$id"
conf=/etc/apache2
echo "---> Initialisation des variables"

echo "---> Installation d'Apache2"
apt-get -y install curl apache2 apache2-doc apache2-utils

echo "--->  Création du répertoire de logs"
mkdir -p /opt/prod/log/www

echo "---> Création automatique du fichier macro.conf"
cat << EOF > $conf/macro.conf
<Macro monsite $id>
<VirtualHost *:80>
	ServerName monsite$id.xyz
    ServerAlias *.monsite$id.xyz
	ServerAdmin webmaster@monsite$id.xyz
	DocumentRoot /opt/prod/monsite$id/www
	ErrorLog /opt/prod/log/www/monsite$id.xyz_error.log
	CustomLog /opt/prod/log/www/monsite$id.xyz_access.log combined
        <Directory /opt/prod/monsite$id/www>
		Require all granted
	</Directory>
</VirtualHost>
</Macro>
EOF

echo "--->  Intégration dans /etc/apache2/apache2.conf et Entrée DNS local"
cp $conf/apache2.conf $conf/apache2.conf.$(date +%s)
echo "Include macro.conf" >> $conf/apache2.conf
for id in 01 02 03 04; do
   mkdir -p /opt/prod/monsite$id/www
   echo "<html><header></header><body><h1>It Works ! on $id</h1></body></html>" > /opt/prod/monsite$id/www/index.html
   echo "Use monsite $id" >> $conf/apache2.conf
   echo "127.0.0.1 monsite$id.xyz www.monsite$id.xyz" >> /etc/hosts
done

echo "---> Activation du module macro et redémarrage"
a2enmod macro
systemctl reload apache2

echo "---> tests de connexion sur chaque site"
for id in 01 02 03 04; do
   curl http://www.monsite$id.xyz
done

11. Configuration LAMP

11.1. Installation de MariaDB (MySQL)

apt-get -y install mariadb-server mariadb-client

Un mot de passe root peut être encodé.

11.2. Installation Apache

apt-get -y install apache2

• Veuillez noter le mode MPM “event”

apachectl -V | grep MPM
Server MPM:     event

11.3. Installation de PHP 5

apt-get -y install php5
systemctl reload apache2

Note : le paquet libapache2-mod-php5 s’installe à cette occasion.

• Veuillez noter le nouveau mode MPM “prefork”

apachectl -V | grep MPM
Server MPM:     prefork

Pour valider l’installation.

• Créer un fichier /var/www/html/info.php avec ce code

echo "<?php phpinfo(); ?>" > /var/www/html/info.php

• On peut faire un test sur http://127.0.0.1/info.php

• Selon les besoins des applications, il pourra aussi être utile de changer des paramètres de délai ou des valeurs maximales (en terme d’usage des ressources) dans le fichier /etc/php5/apache2/php.ini.

11.4. Support PHP5 pour MariaDB

apt-get -y install php5-mysqlnd
systemctl reload apache2

• On peut aussi vérifier d’autres modules PHP5 :

apt-cache search php5

11.5. Installation APC

APCu, Alternative PHP Cache est est un accélérateur PHP comme XCache ou eAccelerator.

apt-get install php5-apcu
systemctl reload apache2

• On peut vérifier les modules installés sur http://127.0.0.1/info.php

11.6. Installation phpMyAdmin

phpMyAdmin est une interface web de gestion du serveur de bases de données.

apt-get -y install phpmyadmin

et répondre aux questions

Faut-il configurer la base de données de phpmyadmin avec dbconfig-common ? Oui
Mot de passe de l'administrateur de la base de données : *****
Mot de passe de connexion MySQL pour phpmyadmin : à laisser vide (aléatoire)

• Faire un test sur http://127.0.0.1/phpmyadmin

11.7. En résumé

Cette installation peut se réaliser en une seule commande :

apt-get -y install \
mariadb-server mariadb-client \
apache2 apache2-utils \
php5 \
php5-mysqlnd \
php5-apcu \
phpmyadmin

12. Installation Drupal HTTPS

Source : http://www.davidam.com/docu/installingdrupal.html

12.1. Installation de LAMP

# apt-get -y install \
mariadb-server mariadb-client \
apache2 apache2-utils \
php5 \
php5-mysqlnd \
php5-apcu \
phpmyadmin

12.2. Drupal 7

2.1 Drupal 7 Installation par les sources

cd /var/www
wget https://ftp.drupal.org/files/projects/drupal-7.41.tar.gz
wget http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.41.fr.po
tar -xvzf drupal-7.41.tar.gz
mv drupal-7.41.fr.po drupal-7.41/profiles/standard/translations/
chown -R www-data.www-data drupal-7.41
chmod g+w -R drupal-7.41
mv drupal-7.41 monsite01

• Voici ce que propose les dépôts

# apt-cache policy drupal7
drupal7:
  Installé : (aucun)
  Candidat : 7.32-1+deb8u5
 Table de version :
     7.32-1+deb8u5 0
        500 http://debian.mirrors.ovh.net/debian/ jessie/main amd64 Packages
        500 http://security.debian.org/ jessie/updates/main amd64 Packages

• apt-cache depends drupal7 nous apprend que MySQL est préféré à MariaDB.

2.2. Configuration Apache

• Créer un fichier d’hôte virtuel /etc/apache2/sites-available/monsite01.conf

<VirtualHost *:80>

  ServerAdmin webmaster@localhost
  ServerName monsite01

  DocumentRoot /var/www/monsite01

  <Directory /var/www/monsite01>
		RewriteEngine on
		RewriteBase /
		RewriteCond %{REQUEST_FILENAME} !-f
		RewriteCond %{REQUEST_FILENAME} !-d
		RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
  </Directory>

</VirtualHost>

• Ajout de l’hôte virtuel

# a2ensite monsite01

• Chargement du module rewrite`

# a2enmod rewrite

• Redémarrage du service Apache

# systemctl reload apache2

2.3. Création de la base de données

# mysql_secure_installation

# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 51
Server version: 10.0.22-MariaDB-0+deb8u1 (Debian)

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database drupal7;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> create user 'drupal7'@'localhost' identified by 'secret';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> grant all privileges on drupal7.* to 'drupal7'@'%' with grant option;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> quit
Bye

2.4. Installation Web

• Avant tout, fixer les droits sur ce fichier :

# chmod 600 /var/www/monsite01/CHANGELOG.txt

• Accéder à l’interface web http://monsite01/install.php en quelques étapes d’installation

12.3. Utilitaire drush

Source : https://www.drupal.org/node/477684

Drush est utiliaire qui un shell à Drupal ! Il permet entre autres de mettre à jour le code, à installer des thèmes, des modules, à réaliser des backup, de créer des utilisateurs.

# apt-get install drush

Il suffit de se placer dans le dossier du site en console et commencer à utiliser l’outil :

# cd /var/www/monsite01
drush status
 Drupal version                  :  7.41
 Site URI                        :  http://default
 Database driver                 :  mysql
 Database hostname               :  localhost
 Database username               :  drupal7
 Database name                   :  drupal7
 Database                        :  Connected
 Drupal bootstrap                :  Successful
 Drupal user                     :  Anonyme
 Default theme                   :  bartik
 Administration theme            :  seven
 PHP configuration               :  /etc/php5/cli/php.ini
 Drush version                   :  5.10.0
 Drush configuration             :
 Drupal root                     :  /var/www/monsite01
 Site path                       :  sites/default
 File directory path             :  sites/default/files
 Temporary file directory path   :  /tmp

• Autre exemple de sauvegarde de la base de donnée

drush sql-dump > /tmp/var/test.sql

12.4. Activation de SSL

• Chargement du module SSL

# a2enmod ssl
# systemctl reload apache2

• Création d’un certificat et de la clé

# mkdir /etc/apache2/ssl
# openssl req \
-x509 \
-nodes \
-days 365 \-newkey rsa:2048 \
-keyout /etc/apache2/ssl/apache.key \
-out /etc/apache2/ssl/apache.crt


Generating a 2048 bit RSA private key
.......................................+++
.........................................................+++
writing new private key to '/etc/apache2/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Paris
Locality Name (eg, city) []:Paris
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Drupal7
Organizational Unit Name (eg, section) []:Drupal7
Common Name (e.g. server FQDN or YOUR name) []:monsite01
Email Address []:webmaster@monsite01

• Création d’un hôte virtuel dans le fichier /etc/apache2/sites-available/monsite01-ssl.conf

<VirtualHost *:443>

  ServerAdmin webmaster@localhost
  ServerName monsite01:443

  DocumentRoot /var/www/monsite01

  <Directory /var/www/monsite01>
		RewriteEngine on
		RewriteBase /
		RewriteCond %{REQUEST_FILENAME} !-f
		RewriteCond %{REQUEST_FILENAME} !-d
		RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
  </Directory>

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key

</VirtualHost>

• Note : site un dossier ou un fichier n’existe pas, l’utilisateur est redirigé sur index.php. Les drapeaux de réécriture L pour terminer et QSA pour reprendre toute information de requête (query) dans l’URI original.
• A vérifier dans les logs.

# a2ensite monsite01-ssl
# systemctl reload apache2

• On suggérera de modifier/ajouter la variable $base_url dans le(s) fichier(s) settings.php du répertoire site.

• Enfin, on suggère l’installation du module securelogin qui assure l’usage d’HTTPS pour les authentification login/mot de passe

cd /var/www/monsite01
drush dl securelogin
drush en securelogin

12.5. Cache Mongodb

12.6. Memcached

12.7. Nagios

13. Optimisation de la configuration

13.1. Consommation mémoire vive

• Processus

ps aux | grep www-data
www-data 11105  0.0  3.1 328740 32332 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11106  0.0  3.4 329692 35440 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11107  0.0  1.3 325840 13512 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11109  0.0  3.3 329656 33948 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11110  0.0  3.1 328568 31904 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11111  0.0  1.3 325828 13412 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11112  0.0  3.2 329368 33668 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11114  0.0  1.3 325852 13480 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11115  0.0  3.1 328572 32056 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
www-data 11186  0.0  3.1 328600 32296 ?        S    janv.27   0:00 /usr/sbin/apache2 -k start
root     11322  0.0  0.2  12748  2212 pts/0    S+   00:32   0:00 grep www-data

• Total

ps aux | grep www-data | awk '{ SUM += $6 } END { print SUM/1024 }'

• Module status

13.2. Outils Apache

• apachectl
• -t ou configtest
• -V
• -M
• fullstatus
• -V

• start *

• ab

• htpasswd

14. Configurations sécurisées

14.1. Configuration Reverse Proxy

• Activation des modules

14.2. Configuration Load Balancer

14.3. Configuration Chroot

14.4. Protection contre les attaques

Audit Web

• Vega : https://subgraph.com/vega/index.fr.html

• cms-explorer.pl
• BlindElephant.py

./cms-explorer.pl -url http://monsite01 -type drupal

• nmap

nmap --script vuln -A -P0 monsite01

• How-to : https://github.com/gfoss/attacking-drupal

• http://w3af.org/

• Nexpose
• Nessus
• Qualys

WAF Apache2

• https://github.com/SpiderLabs/owasp-modsecurity-crs
• mod_auth …
• mod_security
• mod_reqtimeout
• mod_ratelimit

14.5. SSL avec Let’s Encrypt

Il est nécessaire de maîtriser la résolution de nom entre le nom du domaine HTTPS et l’adresse IP à l’écoute sur le serveur Web.

Installation du logiciel

apt-get update
apt-get install git -y
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt --depth=1
cd /opt/letsencrypt/
git pull

Installation automatique (Apache) :

./letsencrypt-auto

Installation manuelle

./letsencrypt-auto --apache -d example.com -d www.example.com -d other.example.net

On trouvera la configuration du vhost Apache dans /etc/letsencrypt/options-ssl-apache.conf et les certificats dans /etc/letsencrypt/live/

Renouvellement du certificat (90 jours)

https://gist.githubusercontent.com/goffinet/1b12d4ca9d977c535fa8917ebe3c5b48/raw/ced2ece3b346e25a7424f4de123510fb8de1f47a/le-renew.sh

#!/bin/bash
#================================================================
# Let's Encrypt renewal script for Apache on Ubuntu/Debian
# @author Erika Heidi<erika@do.co>
# Usage: ./le-renew.sh [base-domain-name]
# More info: http://do.co/1mbVihI
#================================================================
domain=$1
le_path='/opt/letsencrypt'
le_conf='/etc/letsencrypt'
exp_limit=30;

get_domain_list(){
        certdomain=$1
        config_file="$le_conf/renewal/$certdomain.conf"

	if [ ! -f $config_file ] ; then
                echo "[ERROR] The config file for the certificate $certdomain was not found."
                exit 1;
        fi

        domains=$(grep --only-matching --perl-regex "(?<=domains \= ).*" "${config_file}")
        last_char=$(echo "${domains}" | awk '{print substr($0,length,1)}')

        if [ "${last_char}" = "," ]; then
                domains=$(echo "${domains}" |awk '{print substr($0, 1, length-1)}')
        fi

        echo $domains;
}

if [ -z "$domain" ] ; then
        echo "[ERROR] you must provide the domain name for the certificate renewal."
        exit 1;
fi

cert_file="/etc/letsencrypt/live/$domain/fullchain.pem"

if [ ! -f $cert_file ]; then
	echo "[ERROR] certificate file not found for domain $domain."
	exit 1;
fi

exp=$(date -d "`openssl x509 -in $cert_file -text -noout|grep "Not After"|cut -c 25-`" +%s)
datenow=$(date -d "now" +%s)
days_exp=$(echo \( $exp - $datenow \) / 86400 |bc)

echo "Checking expiration date for $domain..."

if [ "$days_exp" -gt "$exp_limit" ] ; then
	echo "The certificate is up to date, no need for renewal ($days_exp days left)."
	exit 0;
else
	echo "The certificate for $domain is about to expire soon. Starting renewal request..."
	domain_list=$( get_domain_list $domain )
	"$le_path"/letsencrypt-auto certonly --apache --renew-by-default --domains "${domain_list}"
	echo "Restarting Apache..."
	/usr/sbin/service apache2 reload
	echo "Renewal process finished for domain $domain"
	exit 0;
fi

# curl -L -o /usr/local/sbin/le-renew https://gist.githubusercontent.com/goffinet/1b12d4ca9d977c535fa8917ebe3c5b48/raw/ced2ece3b346e25a7424f4de123510fb8de1f47a/le-renew.sh
# chmod +x /usr/local/sbin/le-renew

# le-renew www.example.com

Exécution de la tâche toutes les semaines.

crontab -e

0 3 * * 1 /usr/local/sbin/le-renew domaine.fr >> /var/log/le-renew.log

CertBot : https://certbot.eff.org/, https://certbot.eff.org/docs/

15. RHCSA EX300 HTTP/HTTPS

-3. HTTP/HTTPS

• 3.1. Configure a virtual host.
• 3.2. Configure private directories.
• 3.3. Deploy a basic CGI application.
• 3.4. Configure group-managed content.
• 3.5. Configure TLS security.

Après une installation d’apache sous RHEL7 / Centos 7 :

yum install -y curl
yum groupinstall -y "Web Server"
echo "127.0.0.1 server.example.com" >> /etc/host
echo "ServerName server.example.com" >> /etc/httpd/conf/httpd.conf
systemctl enable httpd
systemctl start httpd
systemctl enable firewalld
systemctl start firewalld
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

15.1 Configurer un hôte virtuel

Fichier de configuration

cat /usr/share/doc/httpd*/httpd-vhosts.conf

# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:@@Port@@>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "@@ServerRoot@@/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>

<VirtualHost *:@@Port@@>
ServerAdmin webmaster@dummy-host2.example.com
DocumentRoot "@@ServerRoot@@/docs/dummy-host2.example.com"
ServerName dummy-host2.example.com
ErrorLog "/var/log/httpd/dummy-host2.example.com-error_log"
CustomLog "/var/log/httpd/dummy-host2.example.com-access_log" common
</VirtualHost>

Mise en place d’un hôte virtuel HTTP

Mise en place pour l’hôte virtuel host1.example.com.

Le principe consiste à adapter la copie de ce fichier d’exemple dans /etc/httpd/conf.d/ sous le nom host1.example.com.

Résolution de nom locale

echo "127.0.0.1 host1.example.com" >> /etc/hosts

Création du dossier et des pages Web

mkdir -p /var/www/html/host1.example.com
echo "host1.example.com test page" > /var/www/html/host1.example.com/index.html

Restauration de la policy Selinux sur le dossier créé

restorecon -Rv /var/www/html/host1.example.com

Création du dossier et des fichiers pour les logs

mkdir -p /var/log/httpd
touch /var/log/httpd/host1.example.com-error_log
touch /var/log/httpd/host1.example.com-access_log common

Configuration du vhost HTTP

cat << EOF > /etc/httpd/conf.d/host1.example.com.conf
<VirtualHost *:80>
ServerAdmin webmaster@host1.example.com
DocumentRoot /var/www/html/host1.example.com
ServerName host1.example.com
ErrorLog /var/log/httpd/host1.example.com-error_log
CustomLog /var/log/httpd/host1.example.com-access_log common
</VirtualHost>
EOF

Redémarrage du service

apachectl restart

Diganostic

curl host1.example.com

httpd -D DUMP_VHOSTS

VirtualHost configuration:
*:80                   host1.example.com (/etc/httpd/conf.d/host1.example.com.conf:1)
*:443                  192.168.122.39 (/etc/httpd/conf.d/ssl.conf:56)

Script create_vhost_httpd.sh

https://gist.github.com/goffinet/33205a18152fe3a87a5cf2d46e65dc3f

bash -x create_vhost_httpd.sh host1.example.com

#!/bin/bash
#create_vhost_httpd.sh in Centos7
#Variables
host=$1
port="80"
location="/var/www/html"
error_log="/var/log/httpd/${host}-error_log"
access_log="/var/log/httpd/${host}-access_log common"
#Résolution de nom locale
echo "127.0.0.1 ${host}" >> /etc/hosts
#Création du dossier et des pages Web
mkdir -p ${location}/${host}
echo "${host} test page" > ${location}/${host}/index.html
#Restauration de la policy Selinux sur le dossier créé
restorecon -Rv ${location}/${host}
#Création du dossier et des fichiers pour les logs
mkdir -p /var/log/httpd
touch /var/log/httpd/${host}-error_log
touch /var/log/httpd/${host}-access_log common
#Configuration du vhost
cat << EOF > /etc/httpd/conf.d/${host}.conf
<VirtualHost *:${port}>
ServerAdmin webmaster@${host}
DocumentRoot ${location}/${host}
ServerName ${host}
ErrorLog ${error_log}
CustomLog ${access_log}
</VirtualHost>
EOF
#Activation et lancement du service
systemctl enable httpd
systemctl start httpd
systemctl restart httpd
#Diganostic
curl ${host}
httpd -D DUMP_VHOSTS

15.2. Configuration d’un vhost en https

Trois possibilités pour faire fonctionner HTTPS avec des certificats x509 :

1. Générer un CSR et le soumettre à un CA (Autorité de Certification) : le plus fonctionnel et sûr, mais moins souple et le plus coûteux sur le plan financier et administratif.
2. Générer un certificat auto-signé : coût nul, mais pose un problème de sécurité qui peut devenir indépassable pour certaines applications. Utile pour des environnement de développement ou pour assurer la confidentialité simplement.
3. Let’s Encrypt : coût nul, facile à déployer, sûr.

Aussi, il s’agit de s’intéresser à la force des certificats et aux protocoles autorisés.

Différentes méthodes sont disponibles, certaines valides dans tous les cas ou uniqument sous cette distribution RHEL7/Centos7.

Force des certificats

https://cipherli.st/

“Red Hat Keypair Generation (c)” tout-en-un

L’utilitaire ``crypto-utils` crée les configurations HTTPS pour Apache.

yum install -y crypto-utils

# genkey --help
Unknown option: help
Usage: genkey [options] servername
    --test   Test mode, faster seeding, overwrite existing key
    --genreq Generate a Certificate Signing Request (CSR)
    --makeca Generate a self-signed certificate for a CA
    --days   Days until expiry of self-signed certificate (default 30)
    --renew  CSR is for cert renewal, reusing existing key pair, openssl certs only
    --cacert Renewal is for a CA certificate, needed for openssl certs only
    --nss    Use the nss database for keys and certificates
    --gdb    For package maintainers, to trace into the nss utilities

genkey host1.example.com

Génération du certificat public et de la clé auto-signée

openssl req -nodes -x509 -newkey rsa:4096 -days 365 \
-out /etc/pki/tls/certs/host1.example.com.crt \
-keyout /etc/pki/tls/private/host1.example.com.key \
-subj "/C=BE/ST=Brussels/L=Brussels/O=IT/CN=host1.example.com"

Génération d’un CSR en manuel

• Génération d’un clé sécurisée et non sécurisée
• Génération du CSR

Eventuellement, auto-signer la requête CSR avec sa propre clé.

Si plusiseurs certificats sont à gérér en interne, il est peut être nécessaire d’implémenter une autorité de certification (CA).

Fichier de configuration du vhost HTTPS par défaut

A l’installation du groupe “Web Server” sous Centos7/RHEL7, un fichier /etc/httpd/conf.d/ssl.conf active par défaut un vhost HTTPS (yum install -y mod_ssl), celui sert par défaut les pages en HTTPS.

grep -v '^$\|^\s*\#' /etc/httpd/conf.d/ssl.conf

Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

On peut le désactiver en renommant ce fichier autrement qu’en .conf.

mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak

Nouveau vhost HTTPS

Par rapport à une configuration HTTP simple, quelques directives comme SSLCertificateFile, SSLCertificateKeyFile ainsi que d’autres paramètres comme le port d’écoute TCP 443 sont à ajouter/adapter. On ajoutera cette entrée dans le fichier de configuration

cat << EOF >> /etc/httpd/conf.d/host1.example.com.conf
<VirtualHost *:443>
ServerAdmin webmaster@host1.example.com
DocumentRoot /var/www/html/host1.example.com
ServerName host1.example.com
ErrorLog /var/log/httpd/host1.example.com-error_log
CustomLog /var/log/httpd/host1.example.com-access_log common
    SSLEngine on
    # 128-bit mini anti-beast
    #SSLCipherSuite !EDH:!ADH:!DSS:!RC2:RC4-SHA:RC4-MD5:HIGH:MEDIUM:+AES128:+3DES
    # 128-bit mini PFS favorisé
    #SSLCipherSuite !EDH:!ADH:!DSS:!RC2:HIGH:MEDIUM:+3DES:+RC4
    # 128-bit securité maximale
    SSLCipherSuite !EDH:!ADH:!DSS:!RC4:HIGH:+3DES
    SSLProtocol all -SSLv2 -SSLv3
    SSLCertificateFile /etc/pki/tls/certs/host1.example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/host1.example.com.key
</VirtualHost>
EOF

Vérifier la configuration.

apachectl configtest

Redémarrer le service et adapter le pare-feu.

apachectl reload
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Vérifications

httpd -D DUMP_VHOSTS
VirtualHost configuration:
*:80                   host1.example.com (/etc/httpd/conf.d/host1.example.com.conf:1)
*:443                  is a NameVirtualHost
         default server host1.example.com (/etc/httpd/conf.d/host1.example.com.conf:9)
         port 443 namevhost host1.example.com (/etc/httpd/conf.d/host1.example.com.conf:9)
         port 443 namevhost 192.168.122.38 (/etc/httpd/conf.d/ssl.conf:56)

Vérification client/serveur HTTP.

curl http://host1.example.com
host1.example.com test page

Vérification client/serveur HTTPS.

curl -k https://host1.example.com
host1.example.com test page

Vérification du certificat.

openssl s_client -connect host1.example.com:443 -state
...

Script create_vhost_httpds.sh

https://gist.github.com/goffinet/935c79afaffb6860386880e8bbfb7287

bash -x create_vhost_httpds.sh host1.example.com

#!/bin/bash
#create_vhost_httpds.sh in Centos7
#Variables
host=$1
port="443"
location="/var/www/html"
error_log="/var/log/httpd/${host}-error_log"
access_log="/var/log/httpd/${host}-access_log common"
#Résolution de nom locale
echo "127.0.0.1 ${host}" >> /etc/hosts
#Création du dossier et des pages Web
mkdir -p ${location}/${host}
echo "${host} test page" > ${location}/${host}/index.html
#Restauration de la policy Selinux sur le dossier créé
restorecon -Rv ${location}/${host}
#Création du dossier et des fichiers pour les logs
mkdir -p /var/log/httpd
touch /var/log/httpd/${host}-error_log
touch /var/log/httpd/${host}-access_log common
#Configuration du vhost HTTPS
cat << EOF >> /etc/httpd/conf.d/${host}.conf
<VirtualHost *:${port}>
ServerAdmin webmaster@${host}
DocumentRoot ${location}/${host}
ServerName ${host}
ErrorLog ${error_log}
CustomLog ${access_log}
    SSLEngine on
    SSLCipherSuite !EDH:!ADH:!DSS:!RC4:HIGH:+3DES
    SSLProtocol all -SSLv2 -SSLv3
    SSLCertificateFile /etc/pki/tls/certs/host1.example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/host1.example.com.key
</VirtualHost>
EOF
#Génération du certificat auto-signé
openssl req -nodes -x509 -newkey rsa:4096 \
-out /etc/pki/tls/certs/host1.example.com.crt \
-keyout /etc/pki/tls/private/host1.example.com.key \
-days 365 \
-subj "/C=BE/ST=Brussels/L=Brussels/O=webteam/CN=${host}"
#Activation et lancement du service
systemctl enable httpd
systemctl start httpd
systemctl restart httpd
#Diganostic
curl ${host}
httpd -D DUMP_VHOSTS

Script vhost-creator

Pour la curiosité.

Script https://github.com/mattmezza/vhost-creator.

#!/bin/bash
# This script is used for create virtual hosts on CentOs.
# Created by alexnogard from http://alexnogard.com
# Improved by mattmezza from http://matteomerola.me
# Feel free to modify it
#   PARAMETERS
#
# $usr          - User
# $dir          - directory of web files
# $servn        - webserver address without www.
# $cname        - cname of webserver
# EXAMPLE
# Web directory = /var/www/
# ServerName    = domain.com
# cname            = devel
#
#
# Check if you execute the script as root user
#
# This will check if directory already exist then create it with path : /directory/you/choose/domain.com
# Set the ownership, permissions and create a test index.php file
# Create a vhost file domain in your /etc/httpd/conf.d/ directory.
# And add the new vhost to the hosts.
#
#
if [ "$(whoami)" != 'root' ]; then
echo "Dude, you should execute this script as root user..."
exit 1;
fi
echo "First of all, is this server an Ubuntu or is it a CentOS?"
read -p "ubuntu or centos (lowercase, please) : " osname

SERVICE_="apache2"
VHOST_PATH="/etc/apache2/sites-available"
CFG_TEST="apachectl -t"
if [ "$osname" == "centos" ]; then
  SERVICE_="httpd"
  VHOST_PATH="/etc/httpd/conf.d"
  CFG_TEST="service httpd configtest"
elif [ "$osname" != "ubuntu" ]; then
  echo "Sorry mate but I only support ubuntu or centos"
  echo " "
  echo "By the way, are you sure you have entered 'centos' or 'ubuntu' all lowercase???"
  exit 1;
fi

echo "Enter the server name you want"
read -p "e.g. mydomain.tld (without www) : " servn
echo "Enter a CNAME"
read -p "e.g. www or dev for dev.website.com : " cname
echo "Enter the path of directory you wanna use"
read -p "e.g. /var/www/, dont forget the / : " dir
echo "Enter the name of the document root folder"
read -p "e.g. htdocs : " docroot
echo "Enter the user you wanna use"
read -p "e.g. apache/www-data : " usr
echo "Enter the listened IP for the web server"
read -p "e.g. * : " listen
echo "Enter the port on which the web server should respond"
read -p "e.g. 80 : " port

if ! mkdir -p $dir$cname_$servn/$docroot; then
echo "Web directory already Exist !"
else
echo "Web directory created with success !"
fi
echo "<h1>$cname $servn</h1>" > $dir$cname_$servn/$docroot/index.html
chown -R $usr:$usr $dir$cname_$servn/$docroot
chmod -R '775' $dir$cname_$servn/$docroot
mkdir /var/log/$cname_$servn

alias=$cname.$servn
if [[ "${cname}" == "" ]]; then
alias=$servn
fi

echo "#### $cname $servn
<VirtualHost $listen:$port>
ServerName $servn
ServerAlias $alias
DocumentRoot $dir$cname_$servn/$docroot
<Directory $dir$cname_$servn/$docroot>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>" > $VHOST_PATH/$cname_$servn.conf
if ! echo -e $VHOST_PATH/$cname_$servn.conf; then
echo "Virtual host wasn't created !"
else
echo "Virtual host created !"
fi
echo "Would you like me to create ssl virtual host [y/n]? "
read q
if [[ "${q}" == "yes" ]] || [[ "${q}" == "y" ]]; then
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout $VHOST_PATH/$cname_$servn.key -out $VHOST_PATH/$cname_$servn.crt
if ! echo -e $VHOST_PATH/$cname_$servn.key; then
echo "Certificate key wasn't created !"
else
echo "Certificate key created !"
fi
if ! echo -e $VHOST_PATH/$cname_$servn.crt; then
echo "Certificate wasn't created !"
else
echo "Certificate created !"
if [ "$osname" == "ubuntu" ]; then
  echo "Enabling Virtual host..."
  sudo a2ensite $cname_$servn.conf
fi
fi

echo "#### ssl $cname $servn
<VirtualHost $listen:443>
SSLEngine on
SSLCertificateFile $VHOST_PATH/$cname_$servn.crt
SSLCertificateKeyFile $VHOST_PATH/$cname_$servn.key
ServerName $servn
ServerAlias $alias
DocumentRoot $dir$cname_$servn/$docroot
<Directory $dir$cname_$servn/$docroot>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
Satisfy Any
</Directory>
</VirtualHost>" > $VHOST_PATH/ssl.$cname_$servn.conf
if ! echo -e $VHOST_PATH/ssl.$cname_$servn.conf; then
echo "SSL Virtual host wasn't created !"
else
echo "SSL Virtual host created !"
if [ "$osname" == "ubuntu" ]; then
  echo "Enabling SSL Virtual host..."
  sudo a2ensite ssl.$cname_$servn.conf
fi
fi
fi

echo "127.0.0.1 $servn" >> /etc/hosts
if [ "$alias" != "$servn" ]; then
echo "127.0.0.1 $alias" >> /etc/hosts
fi
echo "Testing configuration"
sudo $CFG_TEST
echo "Would you like me to restart the server [y/n]? "
read q
if [[ "${q}" == "yes" ]] || [[ "${q}" == "y" ]]; then
service $SERVICE_ restart
fi
echo "======================================"
echo "All works done! You should be able to see your website at http://$servn"
echo ""
echo "Share the love! <3"
echo "======================================"
echo ""
echo "Wanna contribute to improve this script? Found a bug? https://github.com/mattmezza/vhost-creator"

15.3. Let’s Encrypt en Centos 7 pour Apache

Source : https://certbot.eff.org/all-instructions/#centos-rhel-7-apache

Installation du logiciel

yum install epel-release
yum install python-certbot-apache

Démarrage rapide

certbot --apache

certbot --apache certonly

certbot renew --dry-run