Auto-héberger son site PluXml

PPmarcelPPmarcel Member
octobre 2010 modifié dans Modifications
Bonjour.

Cette discussion est une copie de l'un de mes billets sur l'auto-hébergement de PluXml à partir d'un environnement Linux, mais facilement adaptable pour Unix/BSD/MacOS. Elle se base sur l'utilisation d'un serveur lighttpd et de PHP5.


Installation des composants
La machine pour cet exemple est basée sur Debian Squeeze. Il faut tout d'abord installer les composants nécessaire, à savoir le serveur web lighttpd, php5-cgi qui va gérer les requêtes, et php5-gd pour gérer la galerie d'images:
aptitude install lighttpd php5-cgi php5-gd
Configurons lighttpd
Nous allons activer l'utilisation de FastCGI, qui va nous permettre de traiter les requêtes un peu plus rapidement:
# lighty-enable-mod fastcgi
# /etc/init.d/lighttpd force-reload
En outre, nous allons indiquer à lighttpd où trouver l'exécutable php5-cgi, sous peine de voir un beau message d'erreur '403 - Forbidden' au niveau du serveur web. Editons le fichier de configuration et ajoutons ces lignes vers la fin:
# vim /etc/lighttpd/lighttpd.conf
[...]
  fastcgi.server = ( ".php" =>
    (( "socket" => "/tmp/php-fastcgi.socket",
        "bin-path" => "/usr/bin/php5-cgi"
    ))
  )
On recharge la configuration du serveur:
# /etc/init.d/lighttpd force-reload
Nous allons préparer un certificat pour l'utilisation de https. Pour cela, installons ssl-cert:
# aptitude install ssl-cert
Générons le certificat au bon endroit:
# mkdir /etc/lighttpd/certs
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/lighttpd/certs/lighttpd.pem
Et ajoutons le certificat à lighttpd.conf
# vim /etc/lighttpd/lighttpd.conf
[...]
$SERVER["socket"] == ":443" {
  ssl.engine = "enable" 
  ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem" 
}
Profitons-en pour décommenter mod_redirect dans la première section:
server.modules = (
	"mod_access",
	"mod_alias",
	"mod_compress",
#	"mod_rewrite",
	"mod_redirect",
A la fin du fichier, ajoutons ces lignes, qui forceront l'usage de https dans les pages d'administration:
$SERVER["socket"] == ":80" {
  $HTTP["host"] =~ "(.*)" {
      url.redirect = ( "^/(core/admin/.*)" => "https://%1/$1" )
      }
}
Maintenant nous allons verouiller l'accès aux fichiers de configuration, aux articles, ainsi que la navigation dans les fichiers du site.

Dans le fichier de conf, changeons le paramètre "server.dir-listing" pour interdire la navigation dans le contenu du site:
server.dir-listing          = "disable"
Maintenant, nous empêcher les clients de regarder les fichiers de configuration, le code source de nos articles et des commentaires. Nous n'autoriseront que l'accès aux images, pour qu'elles s'affichent correctement sur le site.
Ajoutons ces directives tout à la fin du fichier de configuration:
$HTTP["url"] =~ "^/data/((?!images).*)" {
	  url.access-deny = ( "" )
}
Puis redémarrons lighttpd:
# /etc/init.d/lighttpd restart
Installation de PluXml
Récuperons la dernière version de PluXml sur le site du projet.
Nous allons la décompresser dans le répertoire /var/www:
$ unzip pluxml-latest.zip
# mv pluxml/* /var/www
Puis nous allons modifier les droits des fichiers du site:
# chown -R www-data:www-data /var/www/*
Maintenant, il ne suffira plus que de se connecter à son site via un navigateur web. Comme vous pourrez le constater, tout devrait marcher sans message d'erreur:

pluxml_home_install.png

Il ne reste plus qu'à renseigner un nom de rédacteur et un couple login/mot de passe.

EDIT: Suppression de la modification du thème. Ajout du forçage de https depuis lighttpd.
EDIT: Ajout de la protection des fichiers.

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Salut,

    Une petite question: est-ce que les fichiers .htaccess sont bien traités par le serveur lighttpd ?

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Stéphane a écrit:
    Salut,

    Une petite question: est-ce que les fichiers .htaccess sont bien traités par le serveur lighttpd ?
    Apparemment non :
    il ne supporte pas les fichiers htaccess ou encore htpasswd. Ces 2 problèmes sont contournables si vous avez accès à la configuration de votre serveur.
    je croit que l'authentification est géré par "lighttpd-mod_auth"
  • PPmarcelPPmarcel Member
    octobre 2010 modifié
    z0rg> a écrit:
    Stéphane a écrit:
    Salut,

    Une petite question: est-ce que les fichiers .htaccess sont bien traités par le serveur lighttpd ?
    Apparemment non
    je croit que l'authentification est géré par "lighttpd-mod_auth"
    En effet, tout s'effectue avec le fichier de conf de lighttpd, et le chargement des modules nécéssaires. Je suis en train de voir comment automatiser l'activation de https dans les pages admin sans avoir besoin de modifier le thème.

    EDIT: C'est fait, plus besoin de toucher aux thèmes.

    Stéphane: est-ce que tu pourrais formuler la finalité de ta question? Est-ce vis-à vis de la fonctionnalité de l'url rewriting?
  • StéphaneStéphane Member, Former PluXml Project Manager
    1) pour la sécurité: interdire l'accès à certains répertoires comme celui contant les données de configuration
    2) pour l'url rewriting

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • PPmarcelPPmarcel Member
    octobre 2010 modifié
    Tu as raison, cette solution est poreuse! Je regarde la protection des données tout de suite.
    Je pense me pencher sur l'url rewriting un peu plus tard.

    EDIT: Voila, la protection des fichiers à été ajoutée.
  • znkznk Member
    octobre 2010 modifié
    @Stéphane : Ces 2 problèmes majeurs peuvent être contourner par des alternatives :
    Stéphane a écrit:
    1) pour la sécurité: interdire l'accès à certains répertoires comme celui contant les données de configuration
    Voici, pour la sécurité :
    - http://mdvmondelinux.tuxfamily.org/Une-alternative-au-serveur-apache?lang=fr&calendrier_mois=7&calendrier_annee=2009#outil_sommaire_6
    Pas d'htaccess comme z0rg> l'a dit, mais un réglage dans le "lighttpd.conf"
    Stéphane a écrit:
    2) pour l'url rewriting
    Et voici pour l'URL Rewrite sous Lighttpd:
    - http://redmine.lighttpd.net/wiki/1/Docs:ModRewrite
    - http://www.bordel-de-nerd.net/2009/12/url-rewriting-reecriture-durl-avec-lighttpd/

    D'après ce que j'en ai compris, il existe un ModRewrite mais qui est propre à Lighttpd et qui est pas compliqué à mettre en place.
  • znkznk Member
    octobre 2010 modifié
    PPmarcel a écrit:
    Bonjour.

    Cette discussion est une copie de l'un de mes billets sur l'auto-hébergement de PluXml à partir d'un environnement Linux, mais facilement adaptable pour Unix/BSD/MacOS. Elle se base sur l'utilisation d'un serveur lighttpd et de PHP5.
    @PPmarcel: C'est une bonne idée, je vois que c'est de plus en plus fait.
    Mais autant prendre la meilleur alternative à Apache, non ?

    Pourquoi pas Nginx ?
    Niveau performance et ressource, il a l'air bon. Même au niveau simplicité, il est dans "l'esprit de PluXML"

    Je te conseille de bien lire cette comparaison entre Apache et Nginx.
    [EN] http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/

    Et aussi cette autre comparaison entre Apache, Lighttpd et Nginx:
    [Fr] http://www.first-world.info/apache-vs-lighttpd-vs-nginx.html

    Ce dernier est intéressant, vu que c'est dans le cadre d'un hébergement local.
    Popularity

    According to the August 2010 Netcraft survey, nginx hosted about 5.49% of total number of domains while lighttpd hosted about 0.85% only.
    Source : [EN] http://www.wikivs.com/wiki/Lighttpd_vs_nginx#Popularity
  • Azrielo: En effet, Ngynx semble posséder une façon atypique de répondre aux requêtes, probablement efficace.

    Mais si j'ai choisi Lighttpd, c'est uniquement par affinité, n'ayant jamais utilisé Nginx ou Cherokee par exemple.

    Maintenant je n'irais pas dire que l'un est meilleur que l'autre, il ne s'agit là que d'une solution possible avec lighttpd. Une alternative avec Nginx serait probablement la bienvenue sur ce forum.
    Après tout, le logiciel libre, ça passe aussi par la diversité. :)
  • Ne pas oublier qu'on n'installe pas toujours un serveur web seulement pour un logiciel. D'autres logiciels sont souvent installés, et Apache reste le serveur web le plus courant pour du dynamique, donc compatible avec le plus de logiciels. Lighttpd par exemple est souvent cité pour un serveur web statique (bien qu'il sache faire du dynamique).
  • novembre 2011 modifié
    Salut, je rajoute ma pierre :

    Dans lighttpd.conf OU votre vhosts, vous pouvez'add l'option :
    url.access-deny = ( ".xml", "version" )
    
    Pour l'utilisation de la réécriture d'url de PluXml :
    url.rewrite-once = (
    		"\/feed\/([a-z\/]+)$" => "feed.php?$1",
    		"\/([a-z0-9]+\/[a-z0-9-]+)$" => "index.php?$1"
    	)
    
    Ma configuration (simple vhosts) :
    $HTTP["host"] =~ "(^|www\.)loup-des-neiges\.com$" {
    	server.document-root = "/home/loup-des-neiges/htdocs/www"
    	accesslog.filename = "/home/loup-des-neiges/logs/www.loup-des-neiges.com_access.log"
    	url.rewrite-once = (
    		"\/feed\/([a-z\/]+)$" => "feed.php?$1",
    		"\/([a-z0-9]+\/[a-z0-9-]+)$" => "index.php?$1"
    	)
    	url.access-deny = ( ".xml", "version" )
    	$HTTP["url"] =~ "^/data/((?!images).*)" {
    		url.access-deny = ( "" )
    	}
    	$HTTP["url"] =~ "^/plugins/" {
    		url.access-deny = ( "" )
    	}
    	$HTTP["remoteip"] !~ "MON ADRESSE IP" {
    		$HTTP["url"] =~ "^/core/" {
    			url.access-deny = ( "" )
    
    Il reste juste un petit problème !
    Je ne trouve pas la syntaxe afin d'add l'accès au dossier "documents" conjointement au dossier "images" sur la même ligne :
    $HTTP["url"] =~ "^/data/((?!images).*)" {
    		url.access-deny = ( "" )
    
Connectez-vous ou Inscrivez-vous pour répondre.