Lenteurs Proftpd

Note à moi-même : dans mes futures configurations, toujours inclure ceci dans mes fichiers configurations Proftpd (il s’agit du serveur FTP que j’utilise habituellement)

IdentLookups			off
UseReverseDNS			off

Les résolutions DNS sont souvent un facteur de ralentissement du serveur FTP et sont rarement utiles dans le cadre de serveur LAMP. Marre des clients qui râlent à cause de leur connexion FTP qui rame, donc basta ! 🙂

Bases de données MySQL : backup quotidien

Voici un petit script tout simple qui vous permettra de gérer une sauvegarde quotidienne de vos bases de données MySQL. Il utilise mysqldump, mais sans l’option all-databases. Il génère donc un fichier par base et par jour (plus pratique pour la restauration des backups). La date de chaque backup se trouve dans le nom du fichier et 30 jours d’historique sont conservés. Il est donc possible de récupérer l’état de chaque base de J à J-30 🙂

Mise en garde

Attention, ce script crée un dossier /home/backupsql (paramètre modifiable) dans lequel il crée et il supprime des fichiers. N’utilisez pas ce répertoire pour stocker quoi que ce soit…

Le script

#!/bin/bash

#
# PARAMETRAGE
#

PASSWORD=xxxxxxxx
CHEMINSQL=/var/lib/mysql
CHEMINBACKUPSQL=/home/backupsql

#
# SCRIPT BACKUP MYSQL
#

mkdir -p $CHEMINBACKUPSQL
find $CHEMINBACKUPSQL -mtime +30 -exec rm -f {} \;
for base in `ls $CHEMINSQL/`
do
if [ -d $CHEMINSQL/$base ]
then
mysqldump -u root --password=$PASSWORD $base > $CHEMINBACKUPSQL/`date -I`-$base.sql
fi
done

Appelez le par exemple backup.sh et n’oubliez pas de le mettre en cron (avec l’instruction “sh /chemin/que/vous/voulez/backup.sh“) , une fois par jour (de préférence la nuit lorsque le trafic sur votre serveur est faible voire nul).

Explications

Il n’y a que 3 paramètres à modifier :

PASSWORD=xxxxxxxx
CHEMINSQL=/var/lib/mysql
CHEMINBACKUPSQL=/home/backupsql

PASSWORD est votre mot de passe root MySQL (pas le pass root du serveur). CHEMINSQL est le répertoire dans lequel se trouvent vos bases (probablement /var/lib/mysql). CHEMINBACKUPSQL est évidemment le répertoire dans lequel vous voulez stocker les backups.

Le reste n’est qu’une petite boucle qui va parser le répertoire CHEMINSQL et effectuer un mysqldump sur chaque base trouvée.

Notez la ligne :

find $CHEMINBACKUPSQL -mtime +30 -exec rm -f {} \;

Elle est destinée à effacer tous les fichiers vieux de plus de 30 jours dans le répertoire CHEMINBACKUPSQL, on conserve ainsi 1 mois de sauvegardes. Si vous souhaitez modifier cette période de temps, il suffit de modifier le 30 par le nombre de jours voulu.

Offre de VPS infogéré

Bon, allez, c’est décidé, je lance une offre de VPS infogéré. Je n’arrête pas de voir de tous côtés des webmasters qui souhaitent quitter le “mutu” pour passer au serveur dédié, mais qui ne savent pas très bien par où commencer … et à qui on a raconté tout et n’importe quoi !

Voici donc officiellement l’offre Syrelis spéciale “dédié pour débutants” !

Le but est clairement d’assister les webmasters dans leur passage au serveur dédié, de leur mettre le pied à l’étrier en quelque sorte. Cette offre fait déjà le bonheur de plusieurs client (qui ont fait office de bêta-testeurs, merci à eux). Il est à présent temps de proposer officiellement le produit. Envie de passer au dédié ? On vous attend sur nos VPS. Et la liberté reste totale : une fois que vous vous sentirez à l’aise avec la bête, rien ne vous empêche de migrer votre VPS sur un votre serveur dédié à vous…

Release OVH : spamassassin et le bug de l’an 2010

Un bug connu depuis belle lurette déclenche encore pas mal de faux-positifs sur certains spamassassin. C’est dû au fait qu’une des règles utilisées fai(sai)t que tout mail qui a une date éloignée dans le futur voit sa probabilité d’être considéré comme spam augmenter fortement. Jusque là, rien que de très normal : il est louche de voir passer des mails dont la date est en avance de plusieurs années sur le date présente. Oui mais voilà, la règle en question (assez ancienne) stipulait que 2010 est une année éloignée dans le futur … suffisamment éloignée pour titiller spamassassin. Pas de bol, on y est finalement arrivés en 2010 !

Ce bug a été très vite mis à jour dès le début de cette année, à vrai dire dès qu’un grand nombre d’admin ont commencé a voir passer des cargaisons entières de faux-positifs (des mails classés abusivement comme spam par spamassassin). Le bug a été rapidement corrigé et la situation est revenue à la normale. Cela supposait cependant de faire la mise à jour qui va bien … ce qui n’a toujours pas été fait à l’heure actuelle sur la distribution phare d’OVH : la release 2.

Pour ceux qui utilisent cette distribution et qui se servent de spamassassin, il convient donc de faire le mini-patch suivant : dans le fichier /usr/share/spamassassin/72_active.cf (ligne 565), remplacer :

header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Par :

header   FH_DATE_PAST_20XX    Date =~ /20[2-9][0-9]/ [if-unset: 2006]

Votre spamassassin considérera alors comme “futur éloigné” les dates de 2020 à 2099 (et non plus 2010 à 2099).

Release 2 OVH : garder son serveur à l’heure

C’est au moins la millième fois qu’on me pose la question, alors vite vite un petit billet.

Mais comment fait-on pour garder son serveur à l’heure ? Rien de plus simple, il suffit d’installer NTP. Sous Debian, cela se limite donc à un petit :

apt-get install ntp

Et si on a un serveur en release 2 OVH ? Hein ? Fichue release 2 si complexe à gérer !

Et bien non, ce n’est pas plus compliqué, Gentoo a aussi son getionnaire de paquets. Paf :

emerge net-misc/ntp

Après, rien ne vous empêche d’aller fureter dans /etc/ntp.conf, par exemple pour ajouter le serveur de temps OVH (server 213.186.33.99). Ne pas oublier de relancer NTP par après…

/etc/init.d/ntpd restart

Ah oui, j’oubliais, il est aussi bon de lancer NTP au démarrage du serveur. Manipulation inutile sous Debian mais nécessaire sous Gentoo. Donc :

rc-update add ntpd default

Et pissétout 🙂

SSH : Somme des ressources par utilisateur

Ce n’est qu’un petit quelque chose mais je me le note ici, ça resservira sûrement plus tard…

Question : en SSH, comment savoir quelle est la somme des ressources (mémoire, CPU) consommées par un seul et même utilisateur ? Si possible sans trop se prendre la tête… On pense tout de suite à des outils comme top, htop, ps,… Oui mais ça ne fait pas la somme par utilisateur. Et bien grâce à ce petit topic sur le forum OVH (et indirectement cette page), voici une bien jolie commande à passer en SSH et qui répond à la question :

ps aux | awk 'NR != 1 {x[$1] += $4} END{ for(z in x) {print z, x[z]"%"}}'

La commande ci-dessus donne la quantité de mémoire consommée par utilisateur. On peut évidemment très facilement étendre ça au CPU :

ps aux | awk 'NR != 1 {x[$1] += $3} END{ for(z in x) {print z,  x[z]"%"}}'

Bon, les erreurs d’arrondi restent lourdingues mais c’est quand même pas mal.

Debian : Mise à jour de Bind9 fait buguer Webmin

Une récente mise à jour de Bind dans les dépôts Debian induit un léger bug dans Webmin / Virtualmin.

Ceux qui sont dans le cas (Webmin / Virtualmin installé sur une Debian Lenny) et qui mettent à jour (apt-get upgrade) apercevront sans doute que Bind “ne tourne plus”. En tout cas c’est ce que vous dira votre Webmin. Si vous essayez alors de lancer Bind via Webmin, vous obtiendrez une jolie erreur “Unknown Error”. Pas vraiment rassurant…

Heureusement, c’est en fait nettement moins grave qu’il n’y paraît : Bind tourne bel et bien (un petit passage en SSH vous le confirmera vite), c’est simplement Wembin qui ne le détecte plus. Pour fixer ça, il suffit de se rendre dans Webmin -> Servers -> BIND DNS Server -> Module Config -> System configuration et ajouter ceci dans Default PID file location(s) :

/var/run/bind/run/named/named.pid

Avec le bon chemin vers named.pid, Webmin retrouvera ses petits et il ne vous embêtera plus 🙂

Source : https://www.virtualmin.com/node/14569 (inscription nécessaire sur le site)

Attention, cela concerne aussi les nouvelles installations : pour ceux qui ont l’habitude d’installer Virtualmin sur Debian, ne soyez pas surpris de constater que Bind ne “semble” pas tourner sur une installation fraîche (la manipulation pour fixer le bug est évidemment identique).