Nginx – catch all

Tout d’abord c’est quoi un catchall ? C’est une route par défaut. Si par exemple la personne qui a tapé votre adresse mail a fait une erreur comme lngap à la place de lgnap je ne vais pas recevoir votre mail. Mais si l’adminsys a bien fait ça il devrait avoir défini une adresse mail catchall qui récupère tout ce qui n’a pas de destinataire existant et/ou adéquat.

Et bien pour les serveurs web c’est la même chose. Si vous ne spécifiez pas un host traité par le serveur dans l’url (par exemple une IP directe ou un nom de domaine pas prévu pour être utilisé sur le serveur web) on ne sait pas trop où il vous emmène. Voilà l’intérêt de ce serveur/domaine ci, le savoir et contrôler ce sur quoi ils peuvent tomber.
Read More…

Posted in Hosting at January 12th, 2012. Comments Off on Nginx – catch all.

Php fcgi memory leaks

Avec la configuration que j’avais donnée auparavant pour charger php via FCGI, les enfants n’étaient jamais “killés” et les heures passant le serveur fastCGI prenait de plus en plus de mémoire au point de sérieusement entamer dans la RAM et donc passer sur le swap comme le montre la jolie montagne rouge.
Read More…

Posted in Hosting at January 8th, 2012. Comments Off on Php fcgi memory leaks.

Apache – config optimisée – étape par étape

Je suis tombé sur un excellent article en anglais, mais tout le monde ne maitrisant pas l’anglais j’ai entrepris de le traduire pour vous.

Il explique comment choisir les valeurs les plus critiques dans apache (MaxClients, Keepalive, Timeout, MaxKeepAliveRequests, MinSpareServers, MaxSpareServers, StartServers, MaxRequestsPerChild) en suivant une procédure plutôt bien expliquée.

Je propose une version step-by-step (pour débuter) suivie d’une sorte de raisonnement mathématique (pour juste avoir les calculs).
Read More…

Posted in Hosting at January 8th, 2012. 1 Comment.

Nginx – deny .htaccess

Au cas où vous n’auriez pas supprimé les .htaccess dans l’article de comment migrer de apache à nginx il faut au moins les protéger d’une éventuelle lecture par un lecteur mal intentionné. C’est simple :

location ~*\.htaccess$ {
deny all;
}

Read More…

Posted in Hosting at January 8th, 2012. Comments Off on Nginx – deny .htaccess.

Postfix/smtp – localhost

La même chose que pour les serveurs précédents, il faut sécuriser un max.  Un serveur smtp ouvert peut être utilisé pour transférer des spams. Pour le fermer :

Editer le fichier /etc/postfix/main.cf trouver la ligne “inet_interfaces” et y mettre :

inet_interfaces = loopback-only

Sauver et relancer le serveur par un petit service postfix restart et le tour est joué

Sources :

Posted in Hosting at January 7th, 2012. Comments Off on Postfix/smtp – localhost.

Sécurisez vos backends – apache, nginx, php, memcache

Voilà, on a une config avec Varnish qui est capable d’encaisser la totalité du trafic sans broncher (ça me fait penser que je dois terminer la traduction d’un article qui explique comment bien optimiser Apache).
Évidemment seul Varnish est censé pouvoir être accessible de l’extérieur et les backends doivent ne pouvoir être accédés que depuis Varnish lui même.

Dans mon cas, tout se trouve sur la même bécane et donc tout ce qui est backend doit écouter sur localhost/127.0.0.1 uniquement.

Read More…

Posted in Hosting at January 7th, 2012. Comments Off on Sécurisez vos backends – apache, nginx, php, memcache.

Nginx – Apache htaccess

Si vous vous êtes un minimum renseigné vous savez sans doute que les .htaccess bien pratiques et typiques de apache n’existent PAS sous NGinx.

Mais heu, pourquoi ?

  • ça ralentirait de façon drastique ses performances, il devrait checker dans chaque folder si le fichier existe ou non, et si oui le parser.
  • Déjà pour apache une des propositions qui revenaient quand on parlait de l’optimiser c’était de purement et simplement désactiver la gestion de ces .htaccess.

Tout ça pourquoi ? Bah c’est simple, il faudra transposer toutes ces règles définies dans les fichiers htaccess dans la définition du host sous NGinx.

Read More…

Posted in Hosting at January 7th, 2012. 1 Comment.