Archives pour la catégorie ‘Hébergement’

Apache : désactiver le support SSLv2

<VirtualHost 172.16.0.14:443>
   ServerName www.site.fr
   DocumentRoot /home/www/sites/site.fr/www/html
   ErrorLog /home/www/sites/site.fr/www/logs/error_log
   Customlog /home/www/sites/site.fr/www/logs/access_log combined

   SSLEngine on
   SSLProtocol -all +SSLv3 +TLSv1
   SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
   SSLCertificateFile /etc/apache2/ssl/www_site_fr.crt
   SSLCertificateKeyFile /etc/apache2/ssl/www_site_fr.key
</VirtualHost>

Nginx : désactiver le support SSLv2

server {
   listen       172.16.0.15:443;
   server_name  mon.site.fr;
   root         /usr/local/www/mon.site.fr;
   index        index.php;

   ssl                  on;
   ssl_certificate      ssl/mon_site_fr.crt;
   ssl_certificate_key  ssl/mon_site_fr.key;
   ssl_session_timeout  5m;
   ssl_protocols SSLv3 TLSv1;
   ssl_ciphers HIGH:!ADH:!MD5;
   ssl_prefer_server_ciphers   on;
}

Apache : activer la compression gzip

Après avoir compilé et activé le module mod_deflate d’Apache, la directive suivante est à ajouter au virtual host :

<IfModule mod_deflate.c>
   SetOutputFilter DEFLATE

   # disable compression for broken browsers
   BrowserMatch ^Mozilla/4 gzip-only-text/html
   BrowserMatch ^Mozilla/4\.0[678] no-gzip
   BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
   BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

   # disable compression for images
   SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
   # disable compression for PDF files
   SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
   # disable compression for binaries and archives
   SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
   # proxy cache support
   Header append Vary User-Agent env=!dont-vary

   # deflate log support
   #DeflateFilterNote Input instream
   #DeflateFilterNote Output outstream
   #DeflateFilterNote Ratio ratio
   #LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
   #Customlog /var/log/apache2/deflate_log deflate
</IfModule>

Cherokee : le serveur web qui réconcilie administrateurs et développeurs

Un serveur web rapide, léger et facilement configurable ? C’est Cherokee !

Toutes les fonctions sont présentes : TLS, FastCGI, rewrite, proxy, cache, journalisation Apache, expiration, compression, limitation du trafic … et en plus une interface web de configuration dont la simplicité est déconcertante. Cette dernière prouve son réel intérêt avec le mécanisme des règles appliquées au contenu. Des assistants sont même présents pour configurer automatiquement le support PHP, créer un hôte pour WordPress, Mailman, etc …

Niveau performances, un benchmark prouve sa supériorité face à Nginx / Lighttpd (sans compter l’autre que je ne nommerai pas), mais il manque un test avec 100/200 clients simultanés pour être certain que les performances ne s’effondre pas à forte charge (ce qui est toujours le cas, OS oblige). L’interface de configuration fonctionne dans un processus séparé, son exécution est donc indépendante et peut être arrétée à tout moment.

Voici quelques screenshots de l’interface web :

PS : non, je n’ai pas acheté le dernier Linux Mag.

Apache : empêcher l’interprétation des fichiers à extensions multiples

Pour éviter l’interprétation des fichiers à extensions multiples (par ex monimage.pl.gif) en tant que script, il est possible de forcer l’option AddHandler d’Apache à ne vérifier que la dernière extension, comme ceci :

AddHandler x-suphp-cgi   .cgi$ .pl$

La documentation ne le précise pas, mais l’extension semble bien être une regex. Ainsi le fichier monimage.pl.gif ne sera plus executé en tant que script Perl, mais affiché comme il se doit en image GIF.

Dans le cas où l’usage n’est valable que pour un seul vhost, il vaut peut être mieux se rabattre sur cette solution : http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext

Nginx : rewrite rules pour le MVC d’ezComponents

Les rewrite rules nécessaires à Nginx pour faire fonctionner le composant MVC de eZComponents sont les suivantes :

server {
    listen 80;
    server_name ezmvc.my.domain;
    root /usr/local/www/ezmvc;
    index  index.php;
    location ~ "^/[^/]*\.php$" {
        set $script "index.php";
        if ( $uri ~ "^/(.*\.php)" ) {
            set $script $1;
        }

        fastcgi_pass unix:/tmp/fcgi-php.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /usr/local/www/ezmvc/$script;
        include fastcgi_params;
    }

    location / {
        rewrite "^/(?:.[^/]+/)+(stylesheets|images|javascripts|flash?)/(.*)$" "/$1/$2" break;
        rewrite "^(.*)$" "/index.php?$1" last;
    }
}

Sphider : patch pour connexion SQL non persistante

Sphider est un indexeur et un moteur de recherche PHP, intégrable idéalement dans de petits sites Web. J’ai remarqué que l’outil utilisait une connexion SQL persistante, ce qui est problématique dans le cas d’un serveur mutualisé.

Je propose donc ce patch chargé de gérer les connexions SQL non persistantes (option de configuration SQL_PCONNECT dans le fichier settings/database.php) :

sphider-1.3.5 # cat settings/database.php
<?php
define ('SQL_DB', 'sphider');
define ('SQL_USER', 'root');
define ('SQL_PASS', '');
define ('SQL_HOST', 'localhost');
define ('SQL_TABLE_PREFIX', '');
define ('SQL_PCONNECT', 0);

$mysql_table_prefix = SQL_TABLE_PREFIX;
?>

Le patch est à appliquer sur la version 1.3.5 de Sphider :

sphider-1.3.5 # patch -p1 < patch-sphider-sql_connect.sql
patching file admin/admin.php
patching file admin/auth.php
patching file admin/install.php
patching file admin/spider.php
patching file include/commonfuncs.php
patching file include/js_suggest/suggest.php
patching file search.php
patching file settings/database.php

patch-sphider-1.3.5-sql_connect.gz

Nginx : mise en place d'un proxy

Exemple de configuration d’un serveur proxy frontal :

location /solr/ {
   proxy_pass http://julius.interact.lu:8080/apache-solr-1.4.0/;
   proxy_set_header   Host             $host;
   proxy_set_header   X-Real-IP        $remote_addr;
   proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

Nginx : configuration pour le CMS ezPublish

J’ai réussi à faire fonctionner le CMS ezPublish sous Nginx. Rien de particulier au niveau des règles de réécriture, hormis la distinction de Nginx entre break et last, qui dans le premier cas empêche l’exécution de l’interpréteur PHP-CGI. Ma configuration permet d’exécuter tous les scripts PHP existants à la racine. Dans le cas d’un fichier inexistant, la page d’erreur 404 ezPublish est affichée.

N’oubliez pas de fixer l’option ForceVirtualHost à true dans votre fichier site.ini pour bénéficier de la réécriture simplifiée des URL.

server {
   listen 80;
   server_name  ezpublish.bhuisgen.my.domain;
   root /Users/bhuisgen/Sites/ezpublish/www/html;
   index index.php;

   if (!-f $request_filename) {
       rewrite ^(.*)$ /404;
   }

   location ~ "^/[^/]*\.php$" {
      set $script "index.php";

      if ( $uri ~ "^/(.*\.php)" ) {
         set $script $1;
      }

      fastcgi_pass   unix:/opt/local/var/run/nginx/fcgi-php.sock;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME /Users/bhuisgen/Sites/ezpublish/www/html/$script;
      include        fastcgi_params;
   }

   location / {
      rewrite "^/var/storage/(.*)$" "/var/storage/$1" break;
      rewrite "^/var/([^/]+)/storage/(.*)$" "/var/$1/storage/$2" break;
      rewrite "^/var/cache/texttoimage/(.*)$" "/var/cache/texttoimage/$1" break;
      rewrite "^/var/([^/]+)/cache/texttoimage/(.*)$" "/var/$1/cache/texttoimage/$2" break;
      rewrite "^/design/([^/]+)/(stylesheets|images|javascript)/(.*)$" "/design/$1/$2/$3" break;
      rewrite "^/share/icons/(.*)$" "/share/icons/$1" break;
      rewrite "^/extension/([^/]+)/design/([^/]+)/(stylesheets|images|javascripts|javascript|flash?)/(.*)$" "/extension/$1/design/$2/$3/$4" break;
      rewrite "^/packages/styles/(.+)/(stylesheets|images|javascript)/([^/]+)/(.*)$" "/packages/styles/$1/$2/$3/$4" break;
      rewrite "^/packages/styles/(.+)/thumbnail/(.*)$" "/packages/styles/$1/thumbnail/$2" break;
      rewrite "^/favicon\.ico$" "/favicon.ico" break;
      rewrite "^/robots\.txt$" "/robots.txt" break;
      rewrite "^/var/cache/debug.html(.*)$" "/var/cache/debug.html$1" break;
      rewrite "^/var/([^/]+)/cache/public/(.*)$" "/var/$1/cache/public/$2" break;
      rewrite "^/var/([^/]+)/cache/debug\.html(.*)$" "/var/$1/cache/debug.html$2" break;
      rewrite "^/crossdomain\.xml$"  "/crossdomain.xml" break;
      rewrite "^/content/treemenu/?$" "/index_treemenu.php" last;
      rewrite "^(.*)$" "/index.php?$1" last;
   }
}

Nginx : intégration complète de Mailman

Pour utiliser Mailman avec Nginx, il n’y a aucunement besoin d’un serveur externe pour l’exécution CGI. Une configuration adaptée permet de se passer du serveur THTTPD, utilisé dans ce tutorial.

En premier lieu, lisez mon article traitant de l’exécution CGI/Perl sous Nginx et installez y le wrapper. Il reste  ensuite à configurer les deux logiciels.

Côté Nginx, toute la difficulté se situe dans le passage des arguments aux scripts CGI. Par ex :

URL : http://127.0.0.1/mailman/listinfo/my_mailing_list
URI pour Mailman : listinfo/my_mailing_list

Le script CGI listinfo est exécuté avec la variable d’environnement PATH_INFO utilisée pour passer les arguments, égale ici à /my_mailing_list. Bref, des rewrites rules bien conçues et une variable spécifique pour le module FastCGI et Mailman peut ensuite fonctionner à 100 %  grâce à Nginx.

Voici la directive de l’hôte :

server {
listen          80;
server_name     localhost;
root            /var/www/localhost/htdocs;

location /mailman/ {
 rewrite "^/mailman/$" http://$host/mailman/listinfo;

 set $script $fastcgi_script_name;
 set $args /;

 if ($request_uri ~ "^/mailman/(.[^\/]*){1}(.*)$" ) {
  set $script /$1;                             
  set $args $2;
 }

 fastcgi_pass   unix:/tmp/fcgi-perl.sock;
 fastcgi_param  SCRIPT_FILENAME /usr/lib/mailman/cgi-bin$script;
 fastcgi_param  PATH_INFO $args;
 include        fastcgi_params;
}

location /images/mailman/ {
 alias   /usr/lib/mailman/icons/;
}

eau de Mailman, les scripts CGI doivent être exécutés par l’utilisateur déclaré lors de sa compilation (option –with-cgi-gid du script configure). Si vous ne pouvez pas modifier cette valeur (ce qui est le cas avec une installation d’un package binaire), il faut modifier les droits sur la socket UNIX fcgi-perl.sock et ajouter l’utilisateur au groupe utilisé par Nginx.

Par exemple, sous Gentoo, je fixe le propriétaire de la socket à apache:nginx et j’ajoute l’utilisateur apache (mailman) au groupe nginx :

# ls -l fcgi-perl.sock
srw-rw---- 1 apache nginx 0 2009-10-06 11:53 fcgi-perl.sock

Rendez-vous ensuite sur http://127.0.0.1/mailman et cliquez sur une mailing list pour valider la configuration.

Haut de page