Archives pour la categorie ‘Hébergement’

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.

Gentoo : PHP + mod_suphp = Internal Server Error

Encore une petite boulette de la team Gentoo pour mod_suphp en version 0.7.1  : le port installe un fichier de configuration non valide, ce qui provoque une inexécution de tous les scripts PHP ! C’est très fâcheux pour un module qui justement  sécurise l’exécution PHP…

Il faut donc corriger le bloc suivant dans /etc/suphp.conf :

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/lib/php5/bin/php-cgi
x-httpd-php5=php:/usr/lib/php5/bin/php-cgi
x-httpd-phtml=php:/usr/lib/php5/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

par celui-ci :

[handlers]
;Handler for php-scripts
x-httpd-php="php:/usr/lib/php5/bin/php-cgi"
x-httpd-php5="php:/usr/lib/php5/bin/php-cgi"
x-httpd-phtml="php:/usr/lib/php5/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"

Vous noterez donc les doubles quotes en plus.

Nginx : astuces pour un hébergement mutualisé

Deux astuces dans le cadre d’un hébergement mutualisé de plusieurs sites avec Nginx.

En premier lieu, il est possible d’inclure des fichiers de configuration par l’option include. Ceci permet alors de créer un répertoire vhosts dédié aux fichiers de configuration de chaque site. Dans le fichier de configuration principal, il faut ajouter par ex :

http {
[...]
# virtual hosts
 include /usr/local/etc/nginx/vhosts/*.conf;
}

Tous les fichiers .conf du répertoire vhosts seront alors inclus. Si un vhost doit être temporairement désactivé, il suffit de changer l’extension de son fichier.

La deuxième astuce touche l’utilisation du module FastCGI. Dans chaque vhost, il faut déclarer le support FastCGI pour PHP, Perl, etc… Il est possible de limiter cette déclaration à ces lignes :

location ~ \.php$ {
 fastcgi_pass   unix:/tmp/fcgi-php.sock;
 fastcgi_index  index.php;
 include        fastcgi_params;
 }

en rajoutant la ligne suivante dans le fichier fastcgi_params :

# Virtual hosts support
fastcgi_param SCRIPT_FILENAME   $document_root$fastcgi_script_name;

RoundCube : module de gestion des vacations

RoundCube est un webmail dernier cri avec glisser-déposer, carnet d’adresses LDAP, vérificateur d’orthographe… en somme tout ce qu’il faut mais en vraiment plus beau que les autres. Il manque encore des plugins d’extension mais çà ne devrait pas tarder avec l’API prévue à cet effet pour la version 0.3.

En attendant, j’ai fait un petit module permettant de gérer un répondeur  automatique de message. L’interface est des plus simples : un onglet « Répondeur » est ajouté dans les paramètres de l’utilisateur, une case à cocher pour activer le répondeur, plus les zones de saisie pour le message et le sujet. Le module est configuré avec les requêtes SQL pour le serveur SMTP Postfix & son interface d’administration PostfixAdmin (elle même pouvant gérer les vacations). Les requêtes sont évidemment modifiables depuis le fichier de configuration du module config/vacation.inc.php.

Module vacation pour RoundCube version 0.2.2 : roundcube-module_vacation-20090528

roundcube_vacation01roundcube_vacation02

Haut de Page