Si vous voulez accéder à votre application via un contexte spécifique, il faut ajouter cette ligne dans votre virtual host apache :

Alias /mon-contexte /chemin/vers/mon_appli/web

Si votre virtual host répond au nom de domaine www.mon-site.com par exemple, votre site sera maintenant accessible via l'URL www.mon-site.com/mon-contexte.

Installation

Lancez simplement la commande suivante :

sudo apt-get install apache2

Configuration générale

Modification du charset

• Éditez le fichier de configuration du charset :

sudo nano /etc/apache2/conf-available/charset.conf

• Décommentez la ligne :

AddDefaultCharset UTF-8

Utilisateur Apache

Pour éviter des problèmes de droits, vous pouvez modifier l'utilisateur et le groupe unix utilisés par Apache.

Par défaut avec Debian, il s'agit de www-data:www-data.

Pour en changer, modifiez le fichier /etc/apache2/envvars avec les droits administrateur :

export APACHE_RUN_USER=phpuser 
export APACHE_RUN_GROUP=phpuser

Activation du module de réécriture d'URL

Pour activer le module rewrite d'Apache et redémarrez Apache, utilisez ces commandes :

sudo a2enmod rewrite
sudo service apache2 restart

Configuration propre à votre site

Initialisation de votre site

• Créez le répertoire racine pour votre site :

cd /var/www
sudo mkdir mon-site
sudo chown -R phpuser:phpuser mon-site

• Créez un fichier index.html à l'intérieur, contenant par exemple <h1>Hello world !</h1>

Configuration du virtual host

Si vous souhaitez accéder à votre site via un nom de domaine spécifique (plutôt que par son IP), ou si vous en avez besoin de plusieurs pour accéder à votre application, il vous faut configurer un virtual host.

Créez un nouveau fichier .conf dans le répertoire des sites disponibles d'Apache /etc/apache2/sites-available/. (Ex: /etc/apache2/sites-available/mon-site.conf).

<VirtualHost *:80>
    ServerAdmin admin@mon-site.com
    ServerName www.mon-site.com
    ServerAlias *.mon-site.com
    DocumentRoot /var/www/mon-site/
    <Directory /var/www/mon-site/>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/mon-site.log
    ServerSignature Off
</VirtualHost>

Explications :

• ServerAdmin : Adresse email de la personne à prévenir en cas de problème côté Apache.
• ServerName : Nom de domaine que vous souhaitez associer au serveur. Il doit être dans les DNS du serveur (ou si vous êtes en mode dev, dans votre fichier /etc/hosts).
• ServerAlias : Autres domaines ou sous domaines qui prendront en compte le même fichier vHost.
• DocumentRoot : Répertoire vers lequel Apache redirigera les adresses IP et ports spécifiés plus haut (*:80).
• Directory : Cette instruction permet d'ajouter des options et règles au répertoire web :
  • FollowSymLinks : Active le suivi des liens symboliques dans ce répertoire.

Activez votre virtual host, désactivez éventuellement celui par défaut puis redémarrez Apache :

sudo a2ensite mon-site
sudo a2dissite default
sudo service apache2 restart

Vérification

Appelez la page d'accueil de votre site via un navigateur ou wget depuis votre répertoire utilisateur :

cd ~
wget mon-site.com
cat index.html

Vous devez retrouver le contenu de votre fichier index.html :

<h1>Hello world !</h1>

Il est parfois utile de choisir avec quel utilisateur système Apache est exécuté.

Pour le modifier, éditez le fichier /etc/apache2/envvars et modifiez les lignes suivantes :

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

www-data est la valeur par défaut. Il suffit de mettre l'utilisateur et le groupe que vous souhaitez.

Lorsque vous lancez les services de WampServer, il arrive qu'Apache n'arrive pas à démarrer à cause d'une erreur de syntaxe dans sa configuration.

Pour savoir quel fichier (httpd.conf, httpd-vhosts.conf, ...) et quelle ligne pose problème, vous pouvez lancer Apache en ligne de commande :

cd D:\Dev\wamp\bin\apache\apache2.2.22\bin
httpd

Remarque : Adaptez le chemin en fonction d'où est installé WampServer et la version d'Apache que vous utilisez.

Exemple :

Pour restreindre l'accès à un répertoire ou à un site entier, vous pouvez le protéger par un mot de passe :

Prérequis

Modules Apache

Pour pouvoir utiliser cette fonctionnalité d'Apache, vous aurez besoin des modules suivants : mod_auth_basic, mod_authn_file et mod_authz_user.

Génération du fichier de mots de passe

Vous devez également générer un fichier de mots passe, via l'utilitaire htpasswd fourni avec Apache. Il se trouve probablement dans le répertoire bin/ de votre installation apache.

Pour cela, lancez la commande suivante :

htpasswd -c /chemin/vers/un/repertoire/protege/passwords nom_utilisateur

Remarques :

• Vous par exemple créer le fichier passwords dans /usr/local/apache/passwd/.
• Pour ajouter un autre utilisateur, utilisez la même commande sans l'option -c.

Le fichier généré pourra ressembler à a ça :

user1:.G.h/4RfP93fd
user2:RlPRITNDHefEpl 

Configuration de base

Cette configuration peut se faire au niveau de votre virtualhost :

<VirtualHost *:80>
    DocumentRoot /var/www/mon_site
    ServerName mon-site.com

    <Directory /var/www/mon_site>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>

    <Directory /var/www/mon_site/protected>
        Order allow,deny
        Allow from all
        AllowOverride None

        AuthType Basic
        # Intitulé de la mire de connexion
        AuthName "Acces restreint"
        # Type de provider
        AuthBasicProvider file
        # Fichier contenant les utilisateurs et leur mots de passe cryptés
        AuthUserFile /chemin/vers/mon/fichier/passwords
        Require valid-user
    </Directory>
</VirtualHost>

Explications :

• Ce virtualhost définit des règles différentes selon les dossiers du site :
  • La racine du site (mon_site/) et ses sous-répertoires sont accessibles à tous
  • Le répertoire protected/ lui, est protégé par un mot de passe
• L'authentification basique est utilisée.
• On indique le fichier contenant les utilisateurs et leurs mots de passe cryptés, autorisés à accéder au répertoire.

Remarque :

Pour plus de sécurité, il est également judicieux de passer le site en HTTPS.

Des groupes d'utilisateurs

Si vous voulez gérer des accès avec plusieurs utilisateurs, il est possible de les organiser par groupe.

Vous pourrez ainsi définir que tel utilisateur appartient à tel ou tel groupe, et que tel ou tel groupe à accès à tel ou tel répertoire.

Le virtualhost est alors un peu modifié :

<VirtualHost *:80>
    DocumentRoot /var/www/mon_site
    ServerName mon-site.com

    <Directory /var/www/mon_site>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>

    <Directory /var/www/mon_site/protected>
        Order allow,deny
        Allow from all
        AllowOverride None

        AuthType Basic
        # Intitulé de la mire de connexion
        AuthName "Acces restreint"
        # Type de provider
        AuthBasicProvider file
        # Fichier contenant les utilisateurs et leur mots de passe cryptés
        AuthUserFile /chemin/vers/mon/fichier/passwords
        # Fichier contenant les groupes et leurs utilisateurs
        AuthGroupFile /chemin/vers/mon/fichier/groups
        Require group_name
    </Directory>
</VirtualHost>

Explication :

La propriété AuthUserFile a été ajoutée, pour définir où se trouve le fichier contenant la liste des groupes. La règle de restriction a également changé, elle définit maintenant le nom du groupe ayant accès au répertoire.

Remarques :

• Pour utiliser ce système de groupes, vous aurez besoin du module mod_authz_groupfile d'Apache.

• Le fichier groups contient quelque chose comme ça :

  group1: user1 user2
  group2: user2 user3

• Contrairement au fichier passwords, il n'est pas crypté et peut donc être créé via un éditeur de texte classique.

Si vous avez deux versions de votre site, une desktop et une autre mobile, vous voudrez probablement qu'un utilisateur sur mobile soit automatiquement redirigé vers la version adaptée.

Cette configuration peut être définie au niveau de vos virtualhost.

Cas basique

Imaginons que vous ayez deux virtualhost basiques, un pour chaque version.

Site desktop

<VirtualHost *:80>
    DocumentRoot /var/www/site_desktop
    ServerName www.mon-site.com

    <Directory /var/www/site_desktop>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Site mobile

<VirtualHost *:80>
    DocumentRoot /var/www/site_mobile
    ServerName m.mon-site.com

    <Directory /var/www/site_mobile>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Si vous voulez rediriger un utilisateur qui accède au site desktop via son mobile, vers le site mobile, le premier virtualhost deviendra :

<VirtualHost *:80>
    DocumentRoot /var/www/site_desktop
    ServerName www.mon-site.com

    <IfModule mod_rewrite.c>
        RewriteEngine on

        # Si le client est un navigateur mobile
        RewriteCond %{HTTP_USER_AGENT} mobi [NC]

        # Redirection vers le site mobile
        RewriteRule ^(.*)$ http://m.mon-site.com [R=301,L]
    </IfModule>

    <Directory /var/www/site_desktop>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Explications :

• Si le module de réécriture d'Apache est présent, on l'active
• Si le nom du navigateur (HTTP_USER_AGENT) contient la chaîne mobi, on applique la règle de redirection, vers le site mobile

Remarque :

Vous pouvez bien sûr faire l'inverse (mobile vers desktop), en ajoutant un ! :

<VirtualHost *:80>
    DocumentRoot /var/www/site_mobile
    ServerName m.mon-site.com

    <IfModule mod_rewrite.c>
        RewriteEngine on

        # Si le client n'est pas un navigateur mobile
        RewriteCond %{HTTP_USER_AGENT} !mobi [NC]

        # Redirection vers le site desktop
        RewriteRule ^(.*)$ http://www.mon-site.com [R=301,L]
    </IfModule>

    <Directory /var/www/site_mobile>
        Options FollowSymLinks
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Règles supplémentaires

Selon votre architecture ou vos besoins, vous serez sans doute amené à ajouter d'autres conditions (RewriteCond) avant la règle de réécriture (RewriteRule) :

# 1. Si le client n'est pas sur iPad
RewriteCond %{HTTP_USER_AGENT} !ipad [NC]

# 2. Si le nom de domaine appelé ne commence pas par "m."
RewriteCond %{HTTP_HOST} !^m\..*

# 3. Si l'URL demandée ne commence pas par "/api/mobile/"
RewriteCond %{REQUEST_URI} !(/api/mobile/)

Explications :

1. Les iPad ayant une résolution importante, il peut être préférable de conserver la version desktop pour leurs utilisateurs. Vous pouvez également ajouter d'autres tablettes : !ipad|tablet [NC]. Plus d'informations sur le site Mozilla.
2. Si vous avez un serveur apache en frontal, qui gère les deux noms de domaine (mon-site.com et m.mon-site.com) dans un seul virtualhost, vous aurez besoin de cette ligne pour éviter une boucle de redirection infinie.
3. Si votre site desktop fournit des webservices à votre site mobile qui les consomme en AJAX, il ne faut pas que les requêtes en question soient redirigées.

Laisser le choix à l'utilisateur

En général, un site mobile ne propose pas toutes les fonctionnalités du site desktop. De plus, en fonction de la taille de l'appareil de l'utilisateur, ce dernier peut préférer utiliser le site desktop.

L'idéal est de proposer un lien vers la version desktop sur le site mobile (éventuellement l'inverse).

Le problème, c'est qu'avec les règles de redirection définies précédemment, l'utilisateur sera automatiquement redirigé en cliquant sur le lien.

Une solution est d'ajouter un paramètre à l'url, et de stocker l'information en cookie. Le lien depuis le site mobile vers le site desktop aura par exemple pour URL http://www.mon-site?mobile=0.

Pour cela, la règle concernant la redirection doit être améliorée :

<IfModule mod_rewrite.c>
    RewriteEngine on

    # Si l'URL contient le paramètre 'mobile', égal à 1
    RewriteCond %{QUERY_STRING} (^|&)mobile=1(&|$)
    # On ajoute un cookie
    RewriteRule ^ - [CO=mobile:1:%{HTTP_HOST}]

    # Si l'URL contient le paramètre 'mobile', égale à 0
    RewriteCond %{QUERY_STRING} (^|&)mobile=0(&|$)
    # On ajoute un cookie
    RewriteRule ^ - [CO=mobile:0:%{HTTP_HOST}]

    # Si l'URL contient le paramètre 'mobile', égale à 1
    RewriteCond %{QUERY_STRING} (^|&)mobile=0(&|$)
    # On saute la prochaine RewriteRule
    RewriteRule ^ - [S=1]

    # Si le client est un navigateur mobile
    RewriteCond %{HTTP_USER_AGENT} mobi [NC]

    # Si le cookie n'est pas égal à 0
    RewriteCond %{HTTP:Cookie} !\mobile=0(;|$)

    # Redirection vers le site desktop
    RewriteRule ^(.*)$ http://m.mon-site.com [R=301,L]
</IfModule>

Prérequis

Pour pouvoir utiliser le SSL/TLS et passer votre site en HTTPS, les paquets suivants doivent être installés sur votre serveur :

• openssl : API de chiffrement
• mod_ssl : Module apache

De plus, vous aurez besoin d'un certificat pour effectuer le chiffrement.

Celui-ci doit être obtenu auprès d'une autorité de certification et stocké dans un endroit sécurisé de votre serveur.

À des fins de test, ou pour un site privé, il est possible de générer son propre certificat et de l'auto-signer.

Générer un certificat auto-signé

Pour cela vous devez probablement être connecté en root sur votre serveur (ou sudo) :

# Génération d'une clé privée
openssl genrsa -out my_certif.key 2048
# Génération d'un fichier CSR
openssl req -new -key my_certif.key -out my_certif.csr
# Génération de la clé auto-signée
openssl x509 -req -days 365 -in my_certif.csr -signkey my_certif.key -out my_certif.crt

Vous avez maintenant deux fichiers particuliers :

• my_certif.crt
• my_certif.key

Configuration Apache

httpd.conf

Voici les paramètres standards d'Apache pour utiliser le HTTPS :

##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##

LoadModule ssl_module modules/mod_ssl.so

#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443

# Necessary if you have several virtual hosts on 443 port
NameVirtualHost *:443 

# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program ('builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin

# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300

# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex default

# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512

#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

Très souvent, apache propose un fichier de configuration dédié à ce paramétrage (ex: ssl.conf). Vérifiez qu'il est bien inclus par le httpd.conf, ou créez-le.

Virtualhost

Il faut ensuite configurer un virtualhost pour le port 443 (celui par défaut pour le HTTPS) :

<VirtualHost *:443>
DocumentRoot /var/www/mon_site
ServerName mon-site.com

# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on

# SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect. Disable SSLv2 access by default:
SSLProtocol all -SSLv2

# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /chemin/vers/certifs/my_certif.crt

# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /chemin/vers/certifs/my_certif.key

# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

<Directory /var/www/mon_site>
    #Options FollowSymLinks
    #AllowOverride None
    Order allow,deny
    allow from all
</Directory>
</VirtualHost>

Explication :

Le virtualhost contient les informations habituelles (nom de domaine, répertoire racine, ...) mais également des configurations propres au SSL/TLS et les chemins vers les certificats que vous avez générés ou obtenus auprès d'une Autorité de certification.

De plus, il répond sur le port 443 et non le 80 habituel.

Forcer le HTTPS

Pour éviter que les utilisateurs du site n'aient aucune réponse lorsqu'ils tapent (http://)mon-site.com dans leur navigateur, il est judicieux de rediriger les accès en HTTP vers l'URL en HTTPS.

Pour cela, ajoutez un second virtualhost gérant la redirection :

<VirtualHost *:80>
    DocumentRoot /var/www/mon_site
    ServerName mon-site.com
    Redirect permanent / https://mon-site.com:443/
</VirtualHost>

Par défaut, le pare-feu bloque les ports utilisés par Apache, à savoir 80 et 443.

Pour autoriser une machine distante à se connecter à Apache, ajoutez les lignes suivantes au début du fichier /etc/sysconfig/iptables :

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

Redémarrez maintenant le pare-feu pour qu'il prenne en compte la modification :

service iptables restart

Sous Linux, pour connaitre les modules chargés par Apache, utilisez la commande :

/usr/local/apache/bin/httpd -M

Remarque :

Selon votre distribution, remplacez httpd par apache ou apachectl.

Lorsque vous lancez Apache sous Linux, via une commande du type :

/sbin/service apache start

Vous pouvez obtenir l'erreur suivante :

Syntax error on line xxx of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: cannot restore segment prot after reloc: Permission denied

Pour corriger l'erreur, exécutez la commande suivante :

chcon -t textrel_shlib_t /usr/local/apache2/modules/libphp5.so