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 :
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.
Comme vous avez pu remarquer j’ai switché à plusieurs reprises depuis un serveur vers l’autre et comme tous les serveurs devaient encore tourner je n’avais comme choix que d’en changer les ports.
Pour Apache il faut aller tout d’abord modifier le fichier ports.conf à la main et puis utiliser la commande suivante dans le dossier /etc/apache2/sites-enabled comme j’aurai pu le faire dans mon article Varnish (expliquant où il faut changer les ports dans Apache)
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 ?
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.
Ajout d’un petit swap à une machine étant un peu limitée en RAM et swap.
Création d’un disque/une partition via gandi, elle est ensuite attachée au serveur.
UUID=xxxxx-xxxx-xxx-xxx swap sw 0 0
Un tit mémo pour que j’oublie pas comment faire un tit backup des données servies par ce serveur.
Alors tout d’abord commencer par se connecter en SSH sur la machine.
Se rendre dans le dossier où se trouvent les fichiers ‘web’ (souvent /var/www mais pas tjrs)
Lancer la commande tar avec les paramètres suivants :
Read the rest of this entry »
Je viens d’en parler pour apache (il suffisait d’installer un mod et de relancer le serveur). Mais comme je l’ai dit un peu avant, Nginx tourne aussi sur ce serveur.
Il me faut donc un moyen de récupérer la véritable adresse derrière la requête http.
A placer dans votre nginx.conf principal
http{
…
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;
…
}
Attention vous remarquez dans ce snippet des ‘…’ représentant le reste de votre configuration, et c’est à placer dans la partie http{ } du fichier de config ;)
Source : http://www.go2linux.org/linux/2011/04/nginx-behind-varnish-or-squid-real-ip-module-940 Merci à lui ;)
Toute personne trainant sur ce blog ou un des blogs hébergés par ce serveur a sans doute eu l’occasion de remarquer ses plantages à répétition complétement imprévisibles.
C’est Varnish qui est chaque fois en cause, qui plante pour une raison X ou Y. Alors comment faire pour le tenir un minimum en laisse ?
Read the rest of this entry »
La petite LED bicolore en façade du Dockstar nous signifiant qu’il est allumé c’est bien. Mais si on pouvait la manipuler nous même ça serait mieux ne pensez vous pas ?!
Ce qui est chouette c’est qu’en fait on peut. Paraitrait qu’il faille installer un noyau spécial pour avoir le contrôle de ces LEDS mais je dois vous avouer que j’ai fait beaucoup de bidouillages et que je ne me souviens plus trop de ce que je lui ai fait subir. Je vous invite a googler ou a jeffDozzaner pour trouver ce qu’il vous manque pour ça.
Après avoir trouvé comment supporter ces leds je me suis fait : oh que c’est complexe, ça va être pénible d’appeler les bonnes commandes aux bons moments et dans le bon ordre. C’est pourquoi je me suis facilité la vie en écrivant un premier script.