Archive for apache2

Rewrite rule pour un project Symfony2

Bonjour,

Je viens de galérer pour configurer apache2 pour le framework Symfony2 pour générer de belles URL. Par défaut, dans Symfony2, les URL sont de la sorte: http://www.monsite.com/monprojet/web/app.php. Mon client souhaitait que cela soit http://www.monsite.com/monprojet. J’ai pensé naïvement qu’un Alias suffirait!
Alias /monprojet “/var/www/monprojet/web/app.php”

Et bien, non, car pleins d’URL attendent le app.php (http://www.monsite.com/monprojet/web/app.php/blah). Une rewrite rule s’impose donc:

Alias /ClubVBE /var/www/monsite/monprojet/web/
<Directory /var/www/monsite/monprojet/web/>
        RewriteEngine On
        RewriteBase /monprojet
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ app.php [QSA,L]
</Directory>

La rewrite condition filtre les requêtes vers des fichiers interdisant l’execution de la règle, car on ne veut pas introduire le app.php si la requête est un fichier. La règle ajoute app.php après la base (/monprojet) et ajoute la chaîne qui correspond à la requête.
Le flag QSA permet d’ajouter les query après les URL et le flag L termine l’exécution des règles (pas très nécessaire ici).

En espérant que cela vous soit utile!

Posted in apache2 | Leave a comment

Accélerer wordpress n’est pas du luxe!

Nous savons que wordpress est devenu l’outil ultime pour créer un site web visuellement simple sans trop de fonctionnalités, car il permet d’aller vite et de monter le site sans grande compétence en développement. Formidable! Par contre, nous savons tous aussi qu’il est lent et qu’il est nécessaire en pratique d’accélérer wordpress, parfois affreusement lent pour des sites un peu chargés. Moteur de blog à l’origine, CMS de plus en plus complet aujourd’hui, c’est un outil de gestion dynamique (contenu stocké en base servi par des scripts php) qui finalement sert beaucoup à faire des sites vitrines relativement statiques d’un point de vue contenu.

Accélérer wordpress en faisant du cache

Ce mécanisme de stockage de contenu en base ralentit considérablement l’accès aux données par le serveur web, qui ouvrent les scripts, les exécutent, fait les requêtes en bases pour générer le contenu html pour finalement l’envoyer à l’explorateur de l’internaute. L’ouverture des scripts, leur exécution et les requêtes en bases redonnent quasiment systématiquement le même résultat! Pourquoi ne pas pré-générer le contenu pour le servir plus rapidement? Cela s’appelle faire du cache!

Allons-y! Nous avons deux méthodes relativement simples pour accélérer wordpress, mais qui nécessitent d’avoir la main sur le serveur, que sont php-apc (Alternative PHP Cache), un outil de mise en cache fait pour php et memcached, un logiciel serveur de cache.

Un plugin pour accélérer wordpress

Comment les utiliser sur un wordpress? Avec wordpress et grâce à la communauté, la réponse est toujours la même, il y a un plugin: “W3 total Cache”.
Ce plugin vous permet de cacher les pages, de réduire le nombre de css en ne gardant que les css utiles pour la page, à réduire les accès en base et pour chacun des ces éléments vous pouvez choisir le type de cache. Vous disposez d’un large choix, en fonction de ce qui est disponible sur votre serveur.
On peut faire du cache sur le disque, si on ne dispose ni de php-apc et memcached. Il faudrait bencher et la performance du cache sur disque doit dépendre des cas, car des accès disques sont toujours plus lent que des accès en mémoire.

Pour utiliser php-apc, il suffit d’installer le module php-apc et de redémarrer apache. Dans la configuration de W3 Total Cache, apparaîtra automatiquement php-apc pour les différents éléments que vous voulez cacher.

Pour utiliser memcached, il faut installer memcached, le serveur de cache en lui-même et php5-memcache, le module php pour y accéder. La configuration par défaut (sur debian) permet de faire tourner memcached en daemon en écoutant sur la seule interface 127.0.0.1. Dans le cas d’un serveur dédié pour le wordpress, c’est suffisant.
Memcached a cet intérêt de pouvoir être utilisé sur un autre serveur, ce qui permet aussi d’être utilisé pour stocker des sessions à utiliser sur plusieurs serveurs apache2 loadbalancé.

Les effets sur la rapidité de wordpress sont évidents et sur un site à fort traffic, ceux sur la consommation système le sont tout autant!

Sur nos machines Hostonomy, php-apc et memcached sont installés par défaut. A vous de choisir.

Posted in apache2, hostonomy | Leave a comment

Héberger un wordpress sur hostonomy!

Bonjour,

WordPress, moteur de blog à ses débuts, est devenu le CMS des CMS, avec une part de marché particulièrement importante. Avec quelques inconvénients toutefois! Notamment son faible niveau de performance. Comment héberger un bon wordpress? Il faut cumuler, selon moi, l’utilisation du plugin w3 Total Cache avec le module php-apc, ce qui n’est pas le cas partout, et la maîtrise de ce paramètre n’est pas évidente chez tous les hébergeurs.

Sur hostonomy, php-apc est présent par défaut. Il suffit alors d’installer sur le tableau de bord de votre worpdress le plugin “W3 Total Cache”, d’activer dans ses options, le cache sur les pages et la database, avec l’option php-apc.

Simple et efficace!

Posted in apache2, hostonomy | Leave a comment

hostonomy: .htaccess vs apache2 configuration

Bonjour,

Comme je le disais, Hostonomy utilise ISPConfig3 pour gérer vos sites. En tant que client de l’offre Hostonomy, vous avez par défaut un profil de revendeur, ce qui vous autorise à créer vos clients, vos sites, leurs sites, vos comptes mails. Par défaut, vous ne pouvez pas modifier manuellement la configuration de votre serveur Apache2 autrement que par un fichier htaccess. Très bien, mais si vous connaissez bien apache et le hosting en général, vous savez que l’interprétation d’un fichier htaccess, se faisant par apache à chaque accès dans le répertoire, prend un temps non négligeable et vous fait perdre un peu de performance.

Demandez au support Altern-IT, de vous passer en mode administrateur, vous aurez alors la possibilité de changer les options apache et php!

Posted in apache2, hostonomy | Leave a comment

Conseil configuration hostonomy

Utilisateur et concepteur de l’offre hostonomy, je vous donne un petit conseil pour héberger vos wordpress, drupal, et joomla.
L’offre se basant sur le projet ISPconfig, Il est plus simple d’activer l’option SuEXEC, afin qu’apache2 exécute les scripts non pas en tant que www-data mais avec votre nom d’utilisateur. Cela vous permet de gérer simplement les droits d’accès et d’exécution.

Posted in apache2 | 2 Comments

Configuration reverse proxy et apache pour garder les IP des clients

L’intérêt de l’utilisation d’un reverse proxy n’est plus à démontrer dans le domaine de l’hébergement. Chez Altern-IT, tous les serveurs web sont derrière un reverse proxy. Par contre, pour pouvoir exploiter pleinement la fonction et gérer correctement ses statistiques, par exemple, il est important de garder l’adresse IP du client dans les logs du serveur web. Par défaut, ce sont ceux du reverse proxy qui apparaitront. Dans notre cas, nous utilisons nginx, en reverse proxy et apache en serveur web. Comment faire pour garder cet IP du client?

Juste un tout petit peu de configuration de chaque côté…
Dans nginx, il faut ajouter les lignes suivantes dans la configuration du serveur:

                proxy_set_header   Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Dans apache, il faut utiliser un module supplémentaire libapache2-mod-rpaf et faire la configuration suivante dans

        RPAFenable On
        RPAFsethostname On
        RPAFproxy_ips ip_webserver1 ip_webserver2

En espérant que cela puisse vous aider.

Posted in apache2 | Leave a comment

Des soucis de disque dur

Lors de la panne d’un disque dur, il me semble que personne n’a pu éviter de penser que ce n’était vraiment pas le moment. Quand il s’agit d’un serveur sur lequel est hébergé des services (ce blog notamment), il faut réagir vite pour ne pas frustrer les innombrables lecteurs que vous êtes. La panne d’un disque a des effets différents et par chance, par moment, elle s’annonce par quelques symptômes avant-coureur, des petits bruits, des problèmes de système de fichier. Hier, ce ne sont pas des bruits qui m’ont alerté puisque ma machine se trouve à environ 250 km de mon domicile, mais l’impossibilité d’effectuer certaines commandes unix, celles qui nécessitaient notamment l’écriture dans ma partition / de mon file system.

La commande dmesg du serveur sous une distribution linux ubuntu server me renseignait alors très bien:

[1815129.630045] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[1815129.630055] hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=61642, high=0, low=61642, sector=61639
[1815129.630069] ide: failed opcode was: unknown
[1815129.630076] end_request: I/O error, dev hda, sector 61639
[1815129.630136] journal_bmap: journal block not found at offset 7180 on hda1
[1815129.630167] Aborting journal on device hda1.
[1815129.631994] journal commit I/O error
[1815129.632192] ext3_abort called.
[1815129.632211] EXT3-fs error (device hda1): ext3_journal_start_sb: Detected aborted journal
[1815129.632237] Remounting filesystem read-only

L’impossibilité d’accéder à certains secteurs avait obligé ext3 à placer la partition / en read-only. La partition /home n’est pas passée en lecture seule, enfin pas encore et il est préférable d’agir immédiatement, en prenant le temps d’aller vite et garder son calme.

La principale contrainte: faire du back-up rapide en évitant les écritures sur le disque.

Sauvegarder ce blog utilisant le moteur de blog wordpress:
Impossible de faire un dump de la base sql, puisque mysqldump a besoin d’écrire dans /tmp. Il va donc falloir faire une copie de l’arborescence. Ce n’est pas une solution à recommander, mais c’est la seule que j’ai. Je vais devoir récupérer /var/lib/mysql

Backuper /home:
La dernière version de son backup est évidemment trop ancienne.

Backup les confs:
La mauvaise gestion de mes arborescences de configuration est flagrante, elles sont toutes dans /etc, ce qui m’oblige aussi à le sauvegarder. Je ne m’y referai plus prendre, elles seront toutes, c’est décidé, dans /home/user/etc afin que la sauvegarde soit plus simple.

Bien, comment faire un backup de tout cela qui soit rapide?
-scp? Non, trop lent, pas besoin de chiffrer, d’autant que je passe déjà par un vpn, l’overhead de chiffrement de ssh ne me satisfait pas.
-L’élégant tar, tar cvf – /source-dir | ssh user@backup-server.home “cat > /backup/source-dir.tar n’est pas plus souhaitable, pour la même raison.
-Puis, toujours dans l’idée d’aller lentement pour aller vite, je parle à iMil de mes soucis. Il me glisse l’idée de passer par netcat pour effectuer un back-up rapide. Je ne connais pas et l’idée de prendre le temps d’apprendre, là maintenant, dans la panade ne me me plait pas d’emblée. Je dois prendre le temps, mais tout de même. Le principe est d’écouter sur un port d’un côté et de mettre dans stdout ce qu’on y reçoit, et d’envoyer stdin de l’autre machine sur ce port. L’intérêt est alors de l’associer à tar. L’idée fait son chemin. Quelques minutes plus tard:

$ man netcat

me donne nc – TCP/IP swiss army knife. J’aime bien l’idée.

Après quelques essais, j’obtiens sur la machine où je veux backuper:

$ netcat -l 3869 | tar xfp -

Cette commande met en écoute netcat sur le port 3869 et envoie le résultat vers le stdin (-) de tar pour l’extraire.

Sur la machine que je veux backuper:

$ tar cvfp - source-dir | netcat host 3869

où source-dir est le répertoire à sauvegarder sur la machine host.
Comme je ne sais pas si tar -z a besoin des droits d’accès en écriture, j’évite de l’utiliser. Si d’ailleurs quelqu’un a la réponse, il peut me laisser un petit comment.

La phase la plus difficile est de prioriser le backup sans rien oublier. Je pense la phrase “Tu n’as rien oublié?” complètement inutile et parfaitement stupide. Le risque d’oubli n’est pas nul, et comme je ne peux pas envisager faire un backup total de la machine qui serait beaucoup trop long et inutile, il faut se concentrer, faire le tour de l’arborescence, puis refaire un tour… et se lancer.

Se lancer, cela veut dire, ouvrir un ticket chez le hoster de mon serveur dédié. Je dois reconnaître qu’OVH, mon hoster a été très rapide pour intervenir. Deux heures plus tard, mon disque était changé, l’install d’une debian 5.0 terminée. J’abandonnai ubuntu pour debian.

Il me reste à cet instant l’install, la config de tous les services, aussi proprement que possible pour faciliter les backups.

Je vous fais une liste des opérations que j’ai effectuées pour avoir mon service up and running:

-Changement du mot de passe root
-Modification du /etc/apt/sources.list pour le faire pointer sur une debian testing ou stable, au choix. stable est plus conseillé sur une machine de prod, bien entendu.

/etc/apt/sources.list:

deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

-Je ne veux pas utiliser lilo, et préfère grub.

apt-get remove lilo
apt-get install grub
update-grub
grub-install "(hd0,0)"
grub
>root (hd0,0)
>setup (hd0)
>quit

Il faut alors installer le kernel pour ne pas utiliser le kernel monolythique proposé par le hoster.

apt-get update
apt-cache search kernel-image et choisir le bon.
apt-get install kernel-image-2.6.26-2.i686
apt-get dist-upgrade

Rebooter.
Tout s’est bien passé dans mon cas. Je peux continuer:

-Modification du hostname
-Création de mon user principal useradd -m user
-Modification du /etc/ssh/sshd_config pour interdire l’accès en ssh à root et l’accès par mot de passe:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

-Récupération du répertoire .ssh des utilisateurs qui se connectent par ssh dans lequel on a les clés autorisées.
Attention, à partir de cet instant, il ne faut plus fermer son terminal avant d’avoir tester la connexion par clé, sous peine de devoir rebooter en mode rescue avec un mot de passe root fourni par OVH, monter ses partitions à la main et changer la config de ssh. Le mode rescue d’OVH est excellent, mais il est préférable d’en éviter la lourdeur inévitable.

etc/init.d/ssh restart

Essayer de se connecter avec un autre terminal, si c’est ok, on continue.

-Installation de openvpn en tant que serveur.
Pour respecter mon engagement, je place tous mes fichiers de conf dans /home/user/etc/openvpn et rien dans /etc/openvpn et je n’utilise pas le script /etc/init.d/openvpn start pour le démarrer, mais je préfère screener l’application

cd /home/user/openvpn/
screen -S openvpn
openvpn --config server.conf

Ctrl a-d # pour détacher le screen sans le terminer
A cet instant, si vous êtes encore plus novice que moi et que nous ne connaissez pas screen, un “man screen” est obligatoire.

server.conf est mon fichier de conf server.conf, récupéré de mon backup. J’ai bien entendu modifié les chemins d’accès vers /home/user dans celui-ci.

Passons au service apache pour relancer blog et wiki.

sudo apt-get install apache2 php5 mysql-server php5-mysql libapache2-mod-gnutls

L’utilisateur www-data est créé automatiquement par l’installaton d’apache2, mais je lui crée son répertoire et mot de passe. Je déplace toutes les conf apache dans /home/www-data/ et fais un dans /etc fait un ln -s /home/www-data/etc/apache2 apache2 en modifiant /home/www-data/etc/apache2/apache2.conf

Je laisse mysql configuré comme par défaut dans /etc/mysql, celui-ci ne nécessite pas de modification dans mon cas et la sauvegarde doit se faire par mysqldump.

Je copie la base sql de mon blog dans /var/lib/mysql/bulblog, je modifie les propriétés avec chown.
J’utilise wordpress comme moteur de blog. Le nom du user utilisant la base mysql se trouve dans wp-config.php avec son mot de passe. Je crée l’utilisateur avec des droits d’accès depuis localhost seulement.

mysql -u root -p

mysql> CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'wpuserpass';
mysql>  GRANT ALL ON *.* TO 'wpuser'@'localhost';
mysql> quit

Attention, il est important de ne laisser l’accès que depuis localhost, car l’utilisateur a tous les droits.

Dans apache, il faut maintenant recopier tous les contenus des pages backupées dans les bons répertoires des config de site définis dans /home/www-data/etc/apache2/sites-available
Un test préalable du serveur apache lui-même est conseillé avec la page par défaut “it works”.
Ensuite, il faut activer les sites avec la commande:

a2ensite filename

où filename est le nom du fichier de conf du site dans /etc/apache2/sites-available qui est un lien vers /home/www-data/etc/apache2/sites-available .

On termine avec un /etc/init.d/apache2 restart

Utilisant dokuwiki pour mon wiki, la gestion par fichier plat des données simplifie grandement le backup, la simple copie avec les bons droits et bons propriétaires suffit pour remettre l’ensemble en service.

Puisque vous pouvez lire ces lignes, c’est que mon aventure s’est bien terminée et que j’ai pu reprendre le cours normal de mes opérations. Si j’étais un habitué des bonnes résolutions, je me promettrais de travailler plus proprement sur les backups.

En tout cas merci à iMil pour ses conseils, innombrables et toujours judicieux.

Posted in admin, apache2 | 8 Comments

Démarrer apache avec une passphrase et des logrotates…

Bonjour,

Vous avez peut-être constaté que www.bulot.org n’était pas accessible le dimanche. J’ai pu constater que dans mon logrotate de apache (etc/logrotate.d/apache2), j’avais cette commande:

postrotate
if [ -f /var/run/apache2.pid ]; then
/etc/init.d/apache2 restart > /dev/null
fi

Mon souci était que mon serveur apache redémarre et me demande une passphrase, et que par conséquent, ne peut pas redémarrer tout seul.

Que faire?

La solution que j’ai adoptée est la suivante:

J’ai modifié /etc/logrotate.d/apache2, comme ceci:

postrotate
if [ -f /var/run/apache2.pid ]; then
apache2ctl graceful > /dev/null
fi

apache2ctl permet de regénérer des nouveaux fichiers de log sans avoir à taper sa passphrase.

A+

Stephbul

Posted in apache2 | Leave a comment

Swedish Greys - a WordPress theme from Nordic Themepark.