# uname -a - Mot-clé - apache

Conflict between broken Apache packages makes FCGI angry (mod_fcgid: can't lock process table)

Mathieu — Sat, 08 Feb 2014 17:37:00 +0100

Here is is a quick note on the fix I made today for a messed up Apache server.

The environment

Apache2 + Debian + mod_suexec + mod_fcgi

The problem

The server was down only for PHP-running websites. It triggered a connexion reset when trying to run PHP scripts. Static content and reverse proxies were working correctly, as if nothing was happening.

In the server logs, the following error was present :

mod_fcgid: can't lock process table

The suexec log was showing no anomaly.

The server wasn’t gracefully stopping anymore, and I had to kill him with the -9 signal to stop it.

The cause

Searching around the web was giving me very few clues on the problem. I couldn’t find why the CGI subprocess was broken, it is spawned by Apache and so it should not be missing permissions (there is no CGI daemon listening in Apache setup, contrary to Nginx)

What causes the Apache subprocesses to get spawned ? Either the Apache mpm-workers, or mpm-prefork, or mpm-event or mpm-itk. I knew I was using workers, but a glance in APT installed packages showed me broken packages on workers and ITK. Wait… ITK ?

Actually, I run Puppet, and Puppet was configured to keep Apache ot its latest version from repositories. With the release of a newer version of Apache, it had updated the apache2 package … and installed apache2-mpm-itk while apache2-mpm-workers was still present !

The result was a conflict while trying to spawn CGI processes, and a crash of the subprocess.

The fix

Doing a remove apache2-mpm-itk, and force-reinstall apache2-mpm-workers did the job.

GetSimple: URL index/something returns 404

Mathieu — Mon, 03 Feb 2014 11:25:00 +0100

Problem

While using GetSimple with FancyURLs (Apache Rewrite), every menu item nested under the home page returned a 404.

The (rewritted) URL of the home page is /index

The sub-pages URLs are rendered as index/something, and triggered a 404 error.

Solution

Disable MultiViews.

MultiViews is an Apache mechanism for automatically switching wich document is sent to the user, based on the Accept header. Because the front controller is named index.php, MultiViews was trying to reach index.php/something instead of (as specified in RewriteRules) index.php?id=index/something.

How to do it

Open the GetSimple .htaccess file, and locate :

Options -Indexes

Change to :

Options -Indexes -MultiViews

Un serveur au régime : faites tourner un serveur complet dans un mouchoir de poche

Mathieu — Mon, 25 Nov 2013 07:15:00 +0100

Introduction

Ce n’est pas la période pour les régimes et pourtant aujourd’hui, dans un billet volontairement cryptique aux non-initiés, je vais vous dévoiler les quelques secrets qui permettent à des nerds invétérés de donner vie à des machines ridiculement pauvres en RAM. Pour la beauté du geste, mais pas que.

Je me souviens que l’on s’est souvent moqué de moi quand je disais qu’avec 512 mégas de RAM on pouvait faire tourner un serveur complet mail+ftp+web+sql. En remplaçant quelques programmes, vous pouvez parfaitement faire tourner votre application web standalone, un noeud de CDN performant, un miroir FTP, ou un relais mail.

Cet article va simplement vous présenter des alternatives, et terminer avec quelques astuces plus générales. Le but est de remplacer notre célèbre LAMP par des solutions moins gourmandes en mémoire.

Remplacer Apache

Pour remplacer Apache, nous avons le choix entre Nginx et Lighttpd (Lighty).

Lighttpd est le serveur le plus léger au monde. Sa structure est très simple, et l’impact d’une connexion en mémoire est très faible.

Nginx est un serveur qui consomme un peu plus au démarrage, mais qui utilise une gestion intelligente de ses connexions ouvertes pour optimiser son impact mémoire.

Inconvénients : oubliez les .htaccess, préparez-vous à faire un peu de configuration pour remplacer votre “a2enmod php5”, et changez vos habitudes pour redémarrer les services.

Remplacer MySQL

Ce n’est pas facile de remplacer MySQL, tellement le nombre de programme qui en dépendent est conséquent. Cependant, si c’est possible, n’hésitez pas une seconde, voici les deux alternatives “lowcost” possibles :

SQLite : une base SQLite est simplement un fichier qui est chargé en mémoire au moment où l’on veut lire dedans. Pas de démon résident, pas d’impact lorsque la base est inactive. Par contre, préparez vous à attendre un peu si votre base est conséquente : lire des données en n’utilisant que le cache disque, ça peut prendre du temps.

PostgreSQL : PostgreSQL est un peu le nouveau MySQL, mais en mieux. de faible impact mémoire au démarrage, doté de plus de fonctionnalités que MySQL et proposant de meilleures performances, il reste encore marginal mais a tout pour concurrencer les équivalents propriétaires comme Oracle. On peut l’utiliser dans un environnement limité, en configurant correctement les limites dans sa configuration.

Remplacer ProFTPd

Si vous proposez un hébergement, vous proposerez certainement un serveur FTP.

Si les utilisateurs du serveur sont des utilisateurs “de confiance” (ie : que vous connaissez), vous pouvez leur laisser utiliser le serveur SFTP fourni par le serveur SSH (à activer dans la configuration). De très faible impact mémoire, pour une meilleure sécurité et moins de configuration, le protocole SFTP est supporté par la majorité des clients FTP. C’est LA solution des flemmards pour mettre en place un serveur FTP.

Sinon, vous pouvez vous rabattre sur un VSFTPd, qui en plus de vous combler au niveau impact mémoire, vous comblera au niveau rapidité. Il gère aussi le FTPS.

Remplacer Postfix

Si vous n’utilisez pas la réception des mails et que vous ne faites que de l’envoi (avec ou sans smarthost), Exim vous comblera au moins autant que Postfix, vous proposant même sous Debian une interface de configuration “pour les nuls” : dpkg-reconfigure exim4-config.

Éviter la catastrophe

En cas de gonflement inattendu de la mémoire, et lorsque celle-ci commence à manquer, le système d’exploitation commence à sacrifier des programmes pour libérer de la RAM. C’est dommage, on aimerait éviter d’en arriver à de telles extrémités sur un serveur de production.

La solution est assez simple, bien qu’imparfaite : il suffit de rajouter de la SWAP. La SWAP est un fichier d’échange placé sur le disque dur, lorsque il n’y a plus de mémoire en RAM, une partie de la RAM est déchargée (ie copiée) sur la SWAP, pour laisser de la place aux programmes “actifs”. Bien entendu, cette mémoire déchargée devra être rechargée dès lors qu’un programme a besoin d’un bloc mémoire qui a été placé en SWAP, ralentissant le traitement à la vitesse des temps d’accès disque (pas cool).

Faire dormir tout le monde

Ce qui est pénible avec les serveurs, c’est la quantité de RAM qui est là, utilisée en permanence, pour finalement un seul pic d’utilisation. Si on pouvait récupérer la RAM des programmes qui n’interagissent pas avec l’extérieur, et ne les lancer que quand on en a besoin ? Inetd est fait pour ça !

Inetd c’est un “super démon” qui va écouter sur les ports demandés à la place des programmes, et qui va lancer les programmes pour traiter l’événement, dès lors qu’une connexion est ouverte sur un de ses ports d’écoute. On peut donc imaginer avoir un Lighttpd non lancé qui se fait réveiller lorsque Inetd reçoit une connexion sur le port 80. Lighttpd traite alors la requête et s’arrête immédiatement après, laissant la place pour d’autres programmes.

L’inconvénient ici vient des temps de traitement forcément plus longs qu’avec des démons résidents (démarrer le programme prend du temps).

Conclusion

Voilà, c’est à peu près tout, j’espère qu’avec ces petits changements dans votre configuration, vous aurez quelques pistes pour alléger votre serveur, si jamais l’expérience vous tente.

Apache : globally configure HTTPS for all VirtualHosts

Mathieu — Sat, 16 Mar 2013 19:16:00 +0100

You want to configure “once and for all” HTTPs for all domains and sub-domains handled by your webserver, and you don’t want to redeclare the certificate in each VirtualHost. Here is the trick.

I run Debian. In a default Apache installation, the directory /etc/sites-enabled contains a file named 000-default which declares a default VirtualHost for HTTP.

You have to know that when Apache loads an entire directory of configuration files, the files are read in alphabetical order. So if you want to declare something before something else, you can cheat on its name in the loaded configuration. It is exactly what 000-default does.

In /etc/apache2/sites-available, you have a file named default-ssl. Edit this file to fit your needs (path to certificate, etc). Note that this certificate will be the same for all the domains hosted on your server. It’s what we want : only one configuration. If you are hosting multiple domains on the same server, the certificate will probably be invalid for at least one of your domains, and you should use mod_macro instead of a global HTTPs configuration.

Now, enable the website the common way : a2ensite default-ssl. Don’t restart Apache yet.

Rename the file default-ssl created in /etc/apache2/sites-enabled/ to 000-default-ssl.

Configure your other VirtualHost with a *:80 section and a *:443 section, as usual but without specifying certificate and SSL informations for VirtualHosts on *:443.

If you restart Apache, you will notice something like this :

_default_ virtualhost overlap on port 443

To get rid of these warnings, just add to your ports.conf, in the right section :

NameVirtualHost *:443
Listen 443 http

When you finally restart Apache, every VirtualHost declared as *:443 will use the certificate defined in 000-default-ssl without mentioning it.