Mots-clé : apache

Configuration Apache : « Directory » et directive « Options » : astuce pour comprendre plus vite

J’ai mis un peu de temps avant de le comprendre, mais c’est peut être parce que pour certains esprits comme le mien ça n’est pas forcément évident.

En résumé :

  • Effacer toutes les options et n’activer que FollowSymLinks :

    Options FollowSymLinks
  • Ajouter à toutes les options, l’option FollowSymLinks :

    Options +FollowSymLinks
  • Supprimer, si elle existe, l’option FollowSymLinks :

    Options -FollowSymLinks

Explication détaillée :
Lorsqu’on met en place une directive "Directory" dans le fichier de configuration d’un serveur Web Apache, on peut y ajouter la directive "Options".
Par exemple :

    <Directory "/web/htdocs/prod">
        Options Indexes
    </Directory>

Ce qu’il faut avoir en tête c’est que le fait de mettre un ordre après Options efface toutes les directives Options précédentes et n’applique que les ordres qui suivent.

Par exemple :

    <Directory "/web/htdocs/prod">
        Options FollowSymLinks
    </Directory>

Cela signifie que pour le répertoire "/web/htdocs/prod" il n’y aura que l’option FollowSymLinks d’activée.
A l’inverse si on avait ajouté un +, cela signifie « ajouter à toutes les options déjà existantes, FollowSymLinks.
De même si on avait ajouté un -, cela signifie « supprimer des options (si elle est présente) » FollowSymLinks.
Ça n’est pas du tout la même chose et même si, une fois qu’on l’a en tête, c’est très simple, ça peut paraître déroutant au début.

Cours à l’institut universitaire d’informatique (IUT) d’Aix en Provence

Voici le fichier PDF du cours sur :

  • la base des DNS ;
  • les hôtes virtuels (« virtual hosts ») ;
  • règles de réécriture (« RewriteRules ») ;
  • les 3 principes de sécurité à avoir en tête.

Pour les quelques étudiants qui voudraient récupérer et lire le cours, un petit conseil sur les question qui vont vous être posées :

  • il vous faut connaitre les directives de réécriture les plus utilisées (redirection, etc) ;
  • il vous faut impérativement réussir à installer un ou plusieurs hôtes virtuels sur un ordinateur local et vous assurer que vous vous souvenez des étapes à faire ;
  • il vous faut savoir mettre en place une ou deux règle de réécriture afin de bien comprendre le fonctionnement. Vous allez avoir un ou deux exemples de règles à expliquer, et si vous n’avez jamais essayé d’en mettre une en place vous ne pourrez jamais les expliquer ;
  • enfin… avez vous bien en tête les 3 principes de sécurité ?

Bonne chance !

Et surtout n’hésitez pas à laisser un commentaire ou poser des questions ici.
Si vous avez des commentaires à faire sur mon cours, même chose : lâchez vous !

Apache : rotation de log

J’ai trouvé un article sur la rotation des logs très intéressant, mais il y a une lacune du côté du serveur Apache qui n’est pas résolue. D’ailleurs qui ne semble résolue nulle part.

>_<

A savoir lorsqu’on utilise la gestion des hôtes virtuels, apache crée un processus de log *par* fichier log. Donc par exemple : un hôte virtuel, un fichier de access_log et un fichier error_log dédié = 2 process rotatelogs. J’ai 12 sites vhost (très peu de fréquentation heureusement), ça me fait un total de 24 process dans ma liste des process… J’ai beau chercher un moyen de n’avoir qu’un seul process, je n’ai trouvé que le module mod_log_rotate qui donne la possibilité d’avoir la rotation de log directement en interne dans Apache, mais, à cause de la gestion des erreurs telle qu’implémentée dans Apache, ce module ne peut gérer que les logs d’accès, pas les logs d’erreur. Autrement dit il me restera tout de même 12 logs différents qui correspondront aux logs d’erreur.

Je me demandais, si, éventuellement, il ne serait pas plus judicieux de faire comme le suggère ce monsieur, à savoir ne pas utiliser mod_log_rotate, ni le programme livré avec Apache, mais de se servir plutôt de l’outil système d’archivage, et, en pratique, juste avant de les archiver, de faire un « awstats » sur les logs. Ce qui me gêne, c’est l’éventualité d’un conflit d’écriture. Que se passe-t-il si jamais j’ai 30 visiteurs de connectés sur mon site en même temps (ce qui serait très bien), qu’Apache écrit dans le log concerné, et que Logrotate est lancé à ce moment là ? C’est la seule et unique chose qui me retient pour l’instant de faire le saut dans cette direction.

Windows Vista : Apache : quand php ne charge pas le fichier php.ini

Votre fichier « php.ini » n’est pas chargé au démarrage d’Apache sous Windows Vista ?

Pas de problème. C’est très simple. Éditez votre fichier Apache de configuration, habituellement httpd.conf.
Juste avant la ligne de directive qui dit de charger le module Apache, il faut ajouter la directive PHPIniDir "C:/PHP" qui précise où doit se situer le fichier php.ini.

Exemple :

PHPIniDir "C:/PHP"
LoadModule php5_module "C:/PHP/php5apache2_2.dll"

Je ne vous parle pas de l’autre méthode moins efficace : lancer Notepad en tant qu’administrateur, ouvrir le fichier php.ini puis le sauver sous le répertoire C:\Windows (c’est le répertoire de configuration par défaut de php).
Je viens de passer plus de deux heures complètes avant de réussir ce qui me prend en temps normal, sur Linux et Windows XP, 5 minutes. Décidément, Vista est vraiment de la daube sous tous les points de vue.

Zeemoz : créer un nouveau module C pour Apache

Aller dans le répertoire des sources, et taper :

/opt/httpd-2.2.4/bin/apxs -g -n modulenouveau

Il va créer un répertoire ./modulenouveau et à l’intérieur les fichiers Makefile et mod_modulenouveau.c, qui contient le squelette du code tel qu’attendu par Apache.
Ensuite il ne reste qu’à remplir.
Pour le script d’installation, il n’y a qu’à copier /usr/bin/modsearch_install.sh en modmodulenouveau_install.sh et modifier uniquement les variables $SOURCES et $MOD.

Les filtres Apache

Il existe plusieurs filtres, qui sont passés dans l’ordre lorsqu’ils arrivent au serveur, puis sont passés exactement dans l’ordre inverse lorsqu’ils repartent vers le client (un seul m’intéresse, le premier : à l’arrivé ce sont les filtre d’entrée, et lorsque cela repart ce sont les filtres de sortie) :

  1. AP_FTYPE_RESOURCE
    Pour les filtres de contenu : cela englobe tous les types de filtres qui peuvent modifier le contenu, cela va de la décomposition de pages XML qui arrivent, à la transformation d’images ou encore à l’assemblage de contenu qui arrive en plusieurs fois. Ce type de filtre peut changer complètement la nature du contenu de la requête. Par exemple, un filtre XSLT peut transformer le contenu d’une page XML en une page HTML ou en un fichier PDF ;
  2. AP_FTYPE_CONTENT_SET
    C’est la seconde étape du filtrage du contenu, qui est principalement destinée à empaqueter le contenu, par exemple le module mod_deflate (qui applique une compression de type gzip) ;
  3. AP_FTYPE_PROTOCOL
    Le troisième filtre, : le filtre habituel a pour fonction d’insérer les entêtes HTTP au début des données qui ressortent des filtres de contenu. C’est réalisé par un filtre intégré nativement à Apache : le filtre HTTP_HEADER(la fonction ap_http_header_filter exactement), donc les applications, en général, l’ignorent.
  4. AP_FTYPE_TRANSCODE
    On s’en tape, ça ne sert pratiquement jamais.
  5. AP_FTYPE_CONNECTION
    On s’en tape, ça ne sert pratiquement jamais.
  6. AP_FTYPE_NETWORK
    On s’en tape, ça ne sert pratiquement jamais.

Le redirection interne

Il est possible dans Apache, lors de la gestion de la requête, de faire une redirection interne, c’est à dire de faire croire qu’il y a eu une redirection, mais au lieu de la renvoyer au client, et que le client demande la nouvelle URL, elle est faite en interne. Pour pouvoir faire cela, deux possibilités :

  1. Location: http://olivier.pons.free.fr/apache/
  2. Location: /apache/

La première est basée sur la nature double de l’entête Location d’un script CGI : elle force à envoyer une redirection au client, alors que la seconde fait une redirection en interne, sans envoyer quelque chose au client.

Seule la seconde possibilité nous intéresse. Il est possible de le faire de deux façons dans un module :

  1. void ap_internal_redirect(
      const char *new_uri, request_rec *r)    .

    Cette forme de redirection interne est le mécanisme à utiliser dans tous les cas à de rares exceptions près. Cette fonction crée un nouvel objet requête pour l’URL passée en paramètre, et lance la nouvelle requête comme si new_uri avait été demandée en premier lieu.

  2. void ap_internal_fast_redirect(
      request_rec *new_req, request_rec *r)

    Cette fonction clone une structure existante new_req dans la requête en cours afin de pouvoir mettre en place une nouvelle requête et simuler le fait qu’on lui passe le contrôle. Ce mécanisme est parfois utilisé pour promouvoir une sous-requête en requête principale. Ce qui est important de noter c’est qu’on ne repart pas de zéro, donc on ne refait pas complètement la requête.

Authname : à quoi ça sert ?

Domaine d’autorisation à utiliser lors de l’authentification HTTP. Cette directive applique le domaine d’autorisation à utiliser pour un répertoire donné.

Le domaine d’autorisation est affiché au client pour qu’il sache quel identifiant et quel mot de passe envoyer. AuthName prend un seul argument.

Si le domaine contient des espaces il doit être entouré par des guillemets.

Pour fonctionner, il doit être obligatoirement accompagné par les directives AuthType et Require, et éventuellement d’autres directives telles que AuthUserFile et AuthGroupFile.

Par exemple:

AuthName "Top Secret"

La chaine donnée par AuthName est ce qui va apparaître dans la fenêtre demandant le mot de passe de la plupart des browsers Internet.

Attention !

Si jamais vous ne mettez pas d’espaces dans la directive AuthName, alors il ne faut pas mettre de guillemets.

Par exemple:

AuthName "Top Secret"

Et :

AuthName Secret

sont des exemples corrects.

Mais ceci ne fonctionnera pas :

AuthName "Secret"

… cela peut, comme cela me l’a fait, faire perdre des heures entières…

Zeemoz : mémo Apache

  1. Tuer les sémaphores d’Apache
    /opt/httpd/erase_semaphores.sh
  2. Fuites mémoires Apache
    Pour vérifier si Apache a des fuites mémoire, il suffit juste de le faire tourner comme n’importe quel éxécutable, via valgrind :
    valgrind --leak-check=full --log-file=./valgrind.log /opt/httpd/bin/httpd

MPM : Multi-Processing-Modules

A la fin de la phase de démarrage, après que la configuration ait été lue, le contrôle général d’Apache est passé à un module de gestion de processus, le Multi-Processing-Module.

Un MPM est une interface entre le serveur Apache qui tourne et l’OS sous-jacent. Son rôle principal est d’optimiser Apache en fonction de la plateforme sur laquelle le serveur tourne. Comme indiqué dans le titre, le MPM est lui-même un module. C’est, à l’inverse de tous les autres, modules, un module au niveau système et non pas un module au niveau applicatif.

Il exite plusieurs MPM‘s.

  • MPM Prefork : c’est un modèle non orienté thread, ressemblant fortement aux mode de fonctionnement des serveurs Apache 1.x
  • MPM Worker : modèle orienté thread. Il a une plus grande souplesse et s’adapte beaucoup mieux en fonction de la demande. Il est particulièrement plus performant que le modèle précédent, notamment avec certains types d’applications.

Tous les deux souffrent d’une limite qui affecte tous les serveurs très demandés. Alors que le HTTP Keepalive est nécéssaire pour réduite le nombre de connexions TCP et la surcharge réseau, il « ligotte » le processus ou le thread d’un serveur pendant toute la durée de la connexion, tant que le Keepalive est actif.

Le nombre de threads disponibles est une ressource critique pour la plateforme sur laquelle est le serveur. Par exemple, un serveur basé sur le module MPM Worker est réellement occupé s’il doit se charger de gérer plusieurs dizaines de milliers de demandes simultanément. L’OS sous-jacent peut parfois arriver à court de threads.

C’est pourquoi un nouveau MPM est en cours de développement. Il en est à un stade avancé, mais pas encore au stade de production, stade qu’ont atteint les deux modules cités précédemment. C’est le MPM basé sur des événements, le Event MPM. Notez bien que ce type de module ne fonctionnera pas en mode sécurisé (https). Par contre, il aura la possiblité de gérer un nombre nettement plus important de hits que les autres modules.