Créer un sous-domaine avec un user spécifique

Ce billet est inspiré de ce post du forum OVH : http://forum.ovh.net/showthread.php?p=511134#post511134, merci à jicao son auteur. Il a pour but de répondre à une question récurrente parmi les utilisateurs de serveurs en release 2 OVH : comment créer un sous-domaine qui appartienne à un utilisateur spécifique (et non pas à l’utilisateur du domaine principal).

La question peut en effet se poser lorsqu’on souhaite confier la gestion d’un sous-domaine à un tiers (y compris l’accès FTP) sans pour autant lui confier le mot de passe de l’ensemble de l’hébergement du domaine en question. Ce cas de figure n’est malheureusement pas prévu dans la release OVH. En effet, la release 2 OVH (en particulier son module OVHm) permet sans problème de créer un nombre illimité de sous-domaines (sd1.domaine.com, sd2.domaine.com, etc.), mais tous appartiendront obligatoirement à l’utilisateur qui est lié à l’hébergement de domaine.com. Il faut donc se connecter avec le login et le mot de passe de l’hébergement de domaine.com pour y accéder, ce qu’on souhaite précisément éviter. Il va donc falloir ruser … et voici comment faire :

1) Créer le domaine et le sous-domaine voulus dans OVHm

Cela se fait le plus naturellement du monde, là : https://12.34.56.78:10000/?cat=ovhm (et cela se passe de commentaire)

2) Créer l’utilisateur qui sera dédié à ce sous-domaine

Il est possible de faire cela par Webmin :
Système > Utilisateurs et groupes > Créer un nouvel utilisateur
Autrement dit, là : https://12.34.56.78:10000/useradmin/edit_user.cgi

A cet endroit, il vous faudra remplir au moins les champs suivants :

  • Nom d’utilisateur : c’est arbitraire, à vous de choisir
  • Mot de passe (Mot de passe normal) : encore une fois à vous de choisir, n’oubliez pas de choisir un mot de passe fort.
  • Interpréteur de commandes : /bin/false/
Le but de mettre l’interpréteur de commandes à /bin/false/ est d’interdire à votre futur utilisateur l’accès SSH à votre serveur. C’est prudent … mais il est cependant possible que vous souhaitiez permettre à votre utilisateur de pouvoir se connecter en ligne de commande. Auquel cas il convient de mettre /bin/bash à cet endroit  mais il est alors recommandé de régler le paramètre “Groupe primaire” (un peu plus bas sur la page) à “

3) Modification du VirtualHost dans Apache

Jusqu’ici nous avons créé un sous-domaine dans OVHm (ce qui a eu pour effet de créer un répertoire /home/domaine/sd/sousdomaine/www) et nous avons créé un utilisateur système (ce qui a eu pour effet de créer un répertoire /home/utilisateur/www/). Il va à présent falloir demander au serveur web (Apache) de ne pas aller chercher le sous-domaine dans /home/domaine/sd/sousdomaine/www/, mais bien dans /home/utilisateur/www/.

Pour ce faire, rendez vous dans le module Apache :
Webmin > Serveurs > Serveur Web Apache > Configuration globale > Édition des fichiers de configuration
Autrement dit, là https://12.34.56.78:10000/apache/allmanual_form.cgi

Trouvez à cet endroit (probablement tout en bas de la zone de texte) la partie qui ressemble à ceci :

<VirtualHost 12.34.56.78:80>
ServerAdmin webmaster@domaine.com
DocumentRoot /home/domaine/sd/sousdomaine/www
SuexecUserGroup domaine users
ServerName sous.domaine.com
CustomLog logs/sous.domaine.com-access_log combined
ScriptAlias /cgi-bin/ /home/domaine/cgi-bin/
AddHandler x-httpd-php5 .php
</VirtualHost>

Et remplacez là par ceci (en adaptant, bien sûr) :

<VirtualHost 12.34.56.78:80>
ServerAdmin webmaster@domaine.com
DocumentRoot /home/utilisateur/www
SuexecUserGroup utilisateur users
ServerName sous.domaine.com
CustomLog logs/sous.domaine.com-access_log combined
AddHandler x-httpd-php5 .php
</VirtualHost>

Attention à adapter la ligne “SuexecUserGroup” si vous avez décidé de  créer un nouveau groupe du même nom que l’utilisateur (voir le point 1 concernant l’accès SSH). Dans ce cas, cette ligne doit être du genre :

SuexecUserGroup utilisateur utilisateur

Et enfin sauvegardez.

4) Relancer le bouzin

Ne pas oublier de retourner un coup dans OVHm et de cliquer sur le fameux lien “Redemarrer tous les services (pour prendre en compte les changements)”, ce qui aura pour effet de relancer Apache (et donc de prendre en compte les changements que vous avez faits).

Et si je veux une base de données pour ce sous-domaine ?

Et bien ça non plus ce n’est pas prévu dans la release OVH … mais il y a également moyen de ruser, assez simplement d’ailleurs. Il suffit de vous connecter à phpMyAdmin (https://12.34.56.78/phpMyAdmin/), puis cliquer sur “Privilèges” et ensuite “Ajouter un utilisateur”.

Sur la page suivante, il vous faudra choisir un nom d’utilisateur (il ne doit pas forcément être identique à l’utilisateur système que vous avez créé au point 1) ainsi qu’un mot de passe. Dans le champ “serveur”, choisissez “Local”. Il reste alors à choisir, un peu plus bas sur la page, l’option “Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base”. C’est tout : votre nouvel utilisateur (MySQL cette fois) aura les pleins pouvoirs sur cette base, mais sur cette base seulement.

Et si je veux supprimer le tout ?

Et bien il suffit défaire ce que vous avez fait, soit :

  1. Vous rendre dans OVHm et supprimer le sous-domaine
  2. Vous rendre dans “Webmin > Système > Utilisateurs et groupes” et supprimer l’utilisateur que vous avez créé
  3. (si vous avez créé une base de données) Supprimer la base de données dans phpMyAdmin ainsi que le user MySQL que vous avez créé pour cette base.

Enjoy 🙂

Transférer un site entre 2 serveurs release 2 OVH

Bon, je sens que ça va être long, il va falloir s’accrocher. Ca fait un bout de temps que je me suis promis d’écrire ce billet tant la question revient de manière régulière sur les forums OVH (tiens, pas plus tard qu’il n’y a pas longtemps, ici). Fainéant que je suis, j’en ai toujours différé la rédaction vu la grosse tartine que cela représente.

Cette fois, j’y vais.

Introduction

C’est parti pour la question à 1000 balles : comment déménager proprement un site d’un serveur en release 2 OVH vers un autre serveur avec cette même distribution ? Le fait de migrer un site d’un serveur à un autre est souvent vécu comme un cauchemar par les admins débutants. Je m’en vais essayer de les rassurer quelque peu en proposant ci-dessous une procédure en 10 étapes (relativement) simples et, je l’espère, décrites avec précision.

Notez bien que, dans les grandes lignes, ces 10 étapes sont valables pour le déménagement d’un site depuis et vers n’importe quel serveur dédié (pas spécialement en release 2). Seulement les détails que je fournis ci-dessous sont, eux, propre à cette distribution.

Pour la suite de ce billet, je pars du principe que :

  • Les 2 serveurs sont installés en release 2 OVH, sans modification majeure.
  • Les quelques commandes SSH décrites ci-dessous sont à passer en shell et en root.
  • J’appellerai le site à déménager monsite.com. Sur les 2 serveurs, il aura comme utilisateur “monsite” et comme répertoire “/home/monsite”.
  • monsite.com est un site type “PHP + MySQL”, du genre Prestashop, WordPress, phpBB, Joomla, etc.
  • J’appellerai ns1111.ovh.net le serveur où se trouve actuellement le site en production, et ns2222.ovh.net le serveur vers lequel on souhaite déménager le site.
  • Chaque serveur a son IP propre, pas d’utilisation d’IP failover (ce qui faciliterait considérablement la tâche … pas la peine de faire simple quand on peut faire compliqué :)).

1. Créer l’hébergement sur ns2222.ovh.net

Commençons par créer sur ns2222.ovh.net un hébergement identique à celui existant sur ns1111.ovh.net. Il faut donc aller créer un hébergement pour monsite.com dans OVHm, c’est à dire par là :

Webmin > ovhm > Ovh Virtual Hosting Management > Ajouter un domaine

Autrement dit, là : https://ns2222.ovh.net:10000/ovhm/formulaire_creer_domaine.cgi

Remplissez le formulaire en veillant à indiquer le même mot de passe que sur ns1111.ovh.net, histoire de créer 2 hébergements vraiment identiques sur les 2 serveurs.

Voilà qui devrait avoir créé tout le nécessaire … sauf les boites mails (et les alias) dont nous nous occuperons plus tard. Pas la peine d’aller se balader dans QmailAdmin (pour ceux qui connaissent), ni de s’amuser à créer manuellement les boites mails.

Sans que ce soit une obligation à ce stade (on y reviendra à la fin), vous pouvez d’ores et déjà rendre dans OVHm sur ns2222.ovh.net (Webmin > ovhm > Ovh Virtual Hosting Management) et de cliquer sur le lien “Redemarrer tous les services (pour prendre en compte les changements)”.

2. “Désactiver” le site sur ns1111.ovh.net

L’idée ici est de mettre le site “en maintenance”, ou, à tout le moins, de désactiver tous les aspects interractifs et/ou web 2.0 de monsite.com sur le serveur où il est actuellement en production. La plupart des CMS à l’heure actuelle permettent de désactiver un site si on le souhaite. L’affichage public du site est alors remplacé par un message du genre :

Notre site est temporairement indisponible pour cause de maintenance. Nous vous prions de nous excuser pour la gêne occasionnée et vous demandons de renouveler votre visite ultérieurement.

Cette étape est particulièrement importante si le site enregistre des commandes (boutique en ligne) ou bien si son contenu est fréquemment modifié (blog, forum,…). En effet, le futur déménagement du site supposera de changer les DNS du nom de domaine monsite.com. Cela aura pour effet que, pendant une période pouvant aller jusqu’à 48H après le changement de DNS (cette étape sera décrite plus loin), certains visiteurs pourront encore êtres amenés à visiter le site sur ns1111.ovh.net alors que d’autres voient déjà le site sur ns2222.ovh.net. Cette situation un peu exceptionnelle est liée à la fameuse “propagation des DNS” et peut poser de gros problèmes de pertes de données si le site fonctionne à la fois sur ns1111.ovh.net et sur ns2222.ovh.net. Il est donc prudent de désactiver le site sur ns1111.ovh.net. Il est alors possible que, pendant cette fameuse période, certains visiteurs voient le site “en maintenance” pendant quelques heures … mais c’est un moindre mal.

Notez également que cette étape est bien sûr superflue pour les sites statiques ou donc le contenu n’évolue pas : peu importe que certains visiteurs le visitent sur ns1111.ovh.net ou sur ns2222.ovh.net, ils y verront la même chose.

3. Backup de la base sur ns1111.ovh.net

Sauvegardons à présent la base de données du site sur ns1111.ovh.net. Pour ce faire, allons au plus simple, utilisons Webmin. Rendez-vous ici :

Webmin > Serveurs > Serveur de Bases de Données MySQL > monsite
Autrement dit : https://ns1111.ovh.net:10000/mysql/edit_dbase.cgi?db=monsite

Cliquez ensuite sur le bouton “Backup Database”. Dans le formulaire qui suit, il suffit de choisir un emplacement pour votre backup. Le nom du fichier est arbitraire, mais je vous conseille de placer votre backup à la racine de l’hébergement du site, soit pour moi : /home/monsite/backupmonsite.sql

Voilà qui va créer un “dump” de votre base de données que nous pourrons importer le moment venu sur ns2222.ovh.net.

4. Copier le site d’un serveur à l’autre

C’est la partie qui parait la plus complexe … en fait il n’en est rien. Nous allons nous connecter par SSH sur ns1111.ovh.net et taper la simple commande suivante :

scp -rp /home/monsite/ root@ns2222.ovh.net:/home/

Cette commande aura pour effet de copier le répertoire /home/monsite/ d’un serveur à l’autre (le mot de passe root de ns2222.ovh.net vous sera demandé au passage). Si vous vous êtes bien débrouillés, le dump de la base MySQL (qui devrait donc se trouver dans /home/monsite/ si vous avez suivi les recommandations du point 3) devrait faire partie du voyage.

5. Copier les boites mails d’un serveur à l’autre

Sur mon serveur en release 2, les boites mails de monsite.com se trouvent dans /home/vpopmail/domains/monsite.com. Je m’en vais donc repasser un coup de “scp” pour les copier d’un serveur à l’autre. Rendez-vous en SSH, toujours sur ns1111.ovh.net et tapez :

scp -rp /home/vpopmail/domains/monsite.com/ root@ns2222.ovh.net:/home/vpopmail/domains/

Notez que le pass root de ns2222.ovh.net vous est une nouvelle fois demandé.

Et hop, voilà toutes mes boites et tous mes alias transférés d’un coup. Elle est pas belle la vie ? 😉

6. Rétablir les bons propriétaires des fichiers

Cette étape est primordiale, ne la zappez pas !

Les deux copies un peu sauvages auxquelles nous venons de nous livrer ont quelque peu chamboulé les propriétaires des fichiers et dossiers sur ns2222.ovh.net. Il est indispensable de rectifier le tir, sans quoi ni le site, ni les boites mails ne fonctionneront correctement sur le nouveau serveur.

Faisons cela avec la commande “chown”, rendez-vous en SSH sur ns2222.ovh.net et tapez :

chown -R monsite:users /home/monsite
chown -R vpopmail:vchkpw /home/vpopmail/domains/monsite.com

7. Restaurer la base de données sur ns2222.ovh.net

Il est à présent temps d’importer la base de données sur ns2222.ovh.net. Pour ce faire, comme lors de la création du dump, nous utilisons Webmin … et exactement au même endroit :

Webmin > Serveurs > Serveur de Bases de Données MySQL > monsite
Autrement dit : https://ns2222.ovh.net:10000/mysql/edit_dbase.cgi?db=monsite

Cette fois, cliquez sur le bouton “Execute SQL” puis sur l’onglet “Run SQL from file”. Utilisez alors le petit formulaire pour sélectionner votre fichier “dump” (je ne vais pas vous faire l’insulte de vous rappeler encore une fois où il se trouve) et validez.

Lorsque la page se rafraichit (ça peut durer un moment, surtout si vous avez une grosse base de données), le message de confirmation n’est pas très bavard, c’est normal. Si vous souhaitez vous assurer que votre base a correctement été importée, le mieux est d’aller jeter un coup d’oeil dans PhpMyAdmin :

https://ns2222.ovh.net/phpMyAdmin/

8. “Activer” le site sur ns2222.ovh.net

Il s’agit de l’inverse du point 2 : sortir le site de son mode “maintenance”, cette fois sur ns2222.ovh.net.

Il est possible que ce point pose problème car, à ce stade, on n’a toujours pas changé des DNS du nom de domaine. Donc, lorsqu’on visite monsite.com le plus naturellement du monde, on tombe encore évidemment sur ns1111.ovh.net ! Or c’est bien sur ns2222.ovh.net qu’il convient de réactiver le site…

Pour contourner l’obstacle, la release 2 vous offre la possibilité de visiter votre site sur une adresse temporaire :

http://ns2222.ovh.net/~monsite/

Si cela ne suffit pas (problème de .htaccess par exemple), vous pouvez feinter en modifiant le fichier “host” sur votre PC et en forcant le nom de domaine monsite.com vers l’adresse IP de ns2222.ovh.net (je ne développe pas plus que ça, vous trouverez pleins d’infos sur Google à ce sujet).

9. Changer les DNS du nom de domaine

On y est presque, il ne reste plus qu’à changer les DNS de monsite.com … mais avant cela, il convient de gérer correctement le DNS secondaire. Comme vous le savez, un nom de domaine se doit d’avoir 2 serveurs DNS, le primaire et le secondaire. Le DNS primaire d’un nom de domaine hébergé sur un serveur en release 2 est en principe le nom du serveur lui-même. Donc, à ce stade, le DNS primaire de monsite.com est ns1111.ovh.net.

Comme il est obligatoire qu’un nom de domaine ait (au moins) 2 DNS, OVH met à notre disposition un serveur DNS secondaire. A l’heure où j’écris ces lignes, le DNS secondaire pour les serveurs OVH est sdns2.ovh.net (ns.kimsufi.com pour les serveurs Kimsufi).

En l’état actuel des choses les DNS de monsite.com sont donc :

ns1111.ovh.net
sdns2.ovh.net

Il va donc falloir changer cela par :

ns2222.ovh.net
sdns2.ovh.net

Si votre nom de domaine est enregistré chez OVH, vous pouvez faire cette opération dans votre manager OVH (https://www.ovh.com/managerv3) :

monsite.com > Domaine & DNS > Serveurs DNS

Si votre domaine n’est pas enregistré chez OVH, ma foi, vous trouverez certainement l’option dans le panel d’administration de votre registar.

OUI MAIS…

Si on se contente de ne faire que ça, notre ami le DNS secondaire (sdns2.ovh.net donc) ne sera pas au courant du changement et il continuera de fonctionner comme avant, c’est à dire d’envoyer le trafic (et les mails) de monsite.com vers ns1111.ovh.net !

Pour corriger cela, rendez vous dans votre manager OVH :

ns1111.ovh.net > Services > DNS secondaire

Puis supprimez le nom de domaine du DSN secondaire.

Restez alors dans votre manager OVH :

ns2222.ovh.net > Services > DNS secondaire

Et cette fois inscrivez le nom de domaine sur le DNS secondaire.

Voilà qui aura pour effet que le DNS secondaire cesse de communiquer avec ns1111.ovh.net et se mette à parler avec ns2222.ovh.net.

IMPORTANT

On approche de la fin, mais n’oubliez pas à l’issue de tout cela, de vous rendre dans OVHm sur ns2222.ovh.net (Webmin > ovhm > Ovh Virtual Hosting Management) et de cliquer sur le lien “Redemarrer tous les services (pour prendre en compte les changements)”. Faites le, même si vous l’avez déjà fait à le fin de l’étape 1.

10. Vérifier les mails pendant 48H

Et bien voilà, figurez-vous que la migration est terminée : votre site a bel et bien été déplacé d’un serveur à l’autre. Mais si, mais si ! Il est possible que cela ne saute pas aux yeux tout de suite car, victime que vous êtes de la propagation des DNS, vous continuez de voir votre site “en maintenance” car vous êtes encore dirigé vers ns1111.ovh.net. De fait, c’est à présent que commence cette période bizarre au cours de laquelle le trafic vers votre site bascule progressivement vers le nouveau serveur. Il n’y a pas grand chose à faire de votre côté, sinon peut-être tenter un ipconfig /flushdns (si vous êtes sous Windows, voir Google pour savoir ce que c’est) ou bien, comme cela a déjà été évoqué plus haut, forcer votre fichier “host”.

Il reste cependant un point quelque peu gênant auquel il faut faire attention. Pendant la propagation des DNS, au même titre que certains visiteurs arriveront encore sur ns1111.ovh.net jusqu’à 48H après le changement des DNS, certains mails eux aussi arriveront peut-être encore sur l’ancien serveur ! Si les boites mails ont une certaine importance à vos yeux et que vos utilisateurs ne peuvent en aucun cas louper de mail, il va falloir veiller au grain ! Donc, pendant les 48H qui suivent le changement des DNS, il va falloir jeter un coup d’oeil régulièrement pour voir si de nouveaux mails ne seraient pas arrivés sur ns1111.ovh.net. Le cas échéant, il est évidemment nécessaire de les copier sur ns2222.ovh.net (reportez vous aux points 5 et 6).

Pinaise, il m’a pris l’après-midi ce billet … mais ouf, ayééé 🙂

Release OVH : OVHm et les domaines avec accents

Tiens, un petit bug dans la release OVH … et du coup, hop, un petit billet 🙂

Comme le savent les utilisateurs de cette distribution, OVHm est le module Webmin qui permet de gérer les hébergements et les noms de domaines qui se trouvent sur le serveur. Ce module permet sans problème de créer un hébergement pour un nom de domaine contenant des caractères spéciaux, notamment des accents. Par exemple accentué.com <– ce nom de domaine est libre à l’heure où j’écris ces lignes, allez-y, foncez ! 😉 Il suffit simplement d’indiquer à OVHm le punycode de votre nom de domaine (dans notre exemple : xn--accentu-hya.com) et ça fonctionne très bien.

Là où ça se gâte un peu, c’est quand on souhaite créer un alias de nom de domaine : on a beau essayer accentué.com ou bien xn--accentu-hya.com, rien n’y fait, OVHm nous envoie sur les roses :

Moche hein ? Oui, mais rien de grave : OVHm refuse en fait qu’un nom de domaine contiennent deux tirets qui se suivent.

La solution est toute bête, il suffit simplement d’aller modifier le fichier /usr/libexec/webmin/ovhm/ajouter_alias.cgi

Repérez la ligne :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-[0-9a-zA-Z]+)*(\.[0-9a-zA-Z]+)+$/);

Et remplacez la par :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-+[0-9a-zA-Z\-]+)*(\.[0-9a-zA-Z]+)+$/);

Fastoche !

Partition racine pleine sur serveur en release 2 OVH

J’aimerais aborder 2 petits “bugs” (ou plutôt 2 oublis) qu’on trouve sur la distribution phare chez OVH, la fameuse release 2. Deux oublis qui font que la partition racine de certains serveurs se remplit inexorablement et on voit alors souvent leurs propriétaires débarquer sur les forum OVH en quête d’assistance. Deux oublis qui font également dire à certains que la partition racine des serveurs en release OVH est beaucoup trop petite (ce en quoi ils ont partiellement tort, vous allez comprendre pourquoi), ce qui occasionne divers débats sur les forums et, indirectement, participe à la réputation quelque peu sulfureuse de cette distribution.

Je n’aborderai pas ici le partitionnement des disques durs en général et j’en arrive tout de suite à ce qui est bien souvent proposé par défaut sur les serveurs (notamment OVH). Il s’agit d’un partitionnement qui comprend, en simplifiant un brin, 2 partitions : une “petite” (la partition racine montée sur /) et une “grosse” (la partition destinée à accueillir les données et qui est bien souvent montée sur /home).

Je le répète, ce que je viens d’écrire ci-dessus est une simplification. Il n’en demeure pas moins qu’elle colle bien souvent à la réalité, en particulier en ce qui concerne les serveurs en release OVH (dont la plupart tournent avec le partitionnement par défaut puisque les utilisateurs de ce genre de serveurs s’amusent rarement à les répartitionner). On se retrouve donc avec une partition racine de quelques Go (ce qui est théoriquement suffisant puisqu’elle n’est censée n’accueillir que le système et pas les données) et tout le reste de l’espace disque est alloué à /home.

Le piège est alors de voir sa partition racine se remplir très vite car on y retrouve des données qui devraient évidemment se retrouver sur l’autre partition. Les cas les plus fréquents (sur les serveurs en général, hors release 2 donc) sont les bases de données (/var/lib/mysql), les logs (/var/log), etc. Tout un tas de choses qui peuvent devenir envahissantes à la longue puisqu’elles ont tendance à “grossir” avec le temps. Seulement sur la release OVH, ils ont prévu le coup ! Toutes les données et tous les logs ont été volontairement déplacés sur la “grosse” partition. On retrouve ainsi les bases dans /home/mysql, les logs dans /home/log, et ainsi de suite. Bien vu.

Bien vu … oui, sauf qu’ils ont malheureusement oublié deux bidules qui, avec le temps, présentent un risque d’encombrer la partition racine. Ces deux bidules, les voici :

Un fichier de log mail

Il s’agit de /var/spool/qscan/qmail-queue.log : un fichier de log tout bête mais sur lequel ne se trouve aucun logrotate. Il a donc tendance à enfler avec le temps, d’autant plus vite que le serveur est fortement sollicité en mail.

La solution : l’inclure dans le logrotate ou le déplacer sur /home (ou les deux à la fois). Pour le déplacer, rien de plus simple :

On coupe le mail
/etc/init.d/spamd stop
/etc/init.d/clamd stop
/etc/init.d/qmail stop
On déplace ce foutu fichier sur /home et on crée le lien symbolique qui va bien
mv /var/spool/qscan/qmail-queue.log /home/log/
ln -s /home/log/qmail-queue.log /var/spool/qscan/qmail-queue.log
On redémarre le mail
/etc/init.d/spamd start
/etc/init.d/clamd start
/etc/init.d/qmail start

Les logs binaires de réplication MySQL

En deux mots, ces logs enregistrent toute l’activité de MySQL et permettent par exemple, en cas de panne, de reconstruire les bases jusqu’à l’instant du crash (voir Google, notre ami à tous, si vous souhaitez creuser la chose). Ils sont précieux pour ceux qui font une utilisation avancée de MySQL … ce qui est rarement le cas des utilisateurs de release 2 dont la plupart ignorent tout de ces logs et ne s’en serviront jamais. Pourtant ils sont bien activés sur les serveurs en release et ils peuvent vite devenir énormes, surtout si votre base de donnée est fortement utilisée.

Purger les logs

Pour purger ces logs (qui, pour information, se trouvent ici : /var/run/mysqld), connectez-vous en root à MySQL en ligne de commande :

mysql -u root -p

(entrez le pass root MySQL, attention sur les serveurs en release 2 il est différent du pass root du système)

Vous obtenez alors un prompt du genre “mysql>” signifiant que vous êtes connecté à MySQL. Tapez la commande :

reset master;

Après quoi un “exit” suffit pour sortir de MySQL.

Désactiver les logs

Purger ces les logs de réplication, c’est bien (et cela va vraisemblablement vous libérer de la place) … mais si rien d’autre n’est fait, ils vont à nouveau se remplir inexorablement. Il reste donc à les désactiver. Pour ce faire, il suffit de :

Editer le fichier de config MySQL /etc/mysql/my.cnf et commenter la ligne suivante

(donc : ajouter une dièse en début de ligne)

#log-bin

Et redémarrer MySQL

/etc/init.d/mysql restart
Et si je veux les garder, ces logs ?

J’ajoute ce petit paragraphe suite aux commentaires de Thomas (voir ci-dessous) car il est vrai que certains pourraient avoir envie de conserveur ces fameux logs. Auquel cas il vous suffit d’appliquer la méthode décrite au début de ce billet concernant les logs mails et déplacer le répertoire /var/run/mysqld dans /home, par exemple dans /home/log. Attention à prendre soin de faire cette opération en ayant coupé le serveur MySQL. Soit à titre d’exemple :

/etc/init.d/mysql stop
mv /var/run/mysqld /home/log/
ln -s /home/log/mysqld /var/run/mysqld
/etc/init.d/mysql start

Sayé, c’est fini

Voilou, après ça l’espace disque de la partition racine de votre serveur ne devrait plus bouger d’un pouce ! 🙂 Mis à part peut-être lors de l’application des patches OVH pour mettre votre serveur à jour mais cela restera marginal.

Relancer les services mail en release 2 OVH

Un petit billet en vitesse à destination des clients OVH qui administrent leur serveur en release 2 via Webmin.

Il arrive régulièrement qu’on doive relancer certains services sur un serveur dédié, ne fût-ce que quand on fait la moindre modification sur un fichier de configuration. Ceux qui ont l’habitude d’administrer leur serveur en SSH connaissent bien le répertoire /etc/init.d/ pour avoir déjà tapé au moins 100.000 fois des commandes du genre /etc/init.d/mysql restart.

Ceux qui connaissent moins bien SSH passent par Webmin pour administrer leur serveur. Là aussi il est possible de relancer les services :

  • Le bouton “Appliquer les changements” dans Bind
  • Le bouton “Stop MySQL server” (suivi bien sûr de “Start”) dans MySQL
  • L’onglet “Appliquer les changements” dans Apache
  • Le lien “Redemarrer tous les services (pour prendre en compte les changements)” dans OVHm (qui relance à la fois Bind et Apache)
  • Etc, etc.

Tous fonctionnent et permettent de relancer proprement les services … tous sauf un : QMail. Ceux qui ont eu un jour la curiosité de cliquer sur le bouton “Stop QMail Processes” (ou bien dont le serveur de mail a bêtement planté) ont probablement eu la désagréable surprise de ne pas pouvoir relancer le serveur de mail.

On a beau cliquer sur “Start QMail Processes”, ça ne redémarre pas.

Et pourquoi ça ne marche pas ? C’est tout simplement dû à l’installation du serveur de mail sur la release OVH : le trio QMail – Spamassassin – ClamAV (serveur de mail – antispam – antivirus) est une installation OVH “maison” et Webmin a un peu de mal à le prendre en charge.

Alors que faire ? Pas le choix, il faut passer en SSH (par pitié, ne cédez pas à la tentation du reboot : rebooter un serveur linux, c’est mal !) et lancer les commandes suivantes dans l’ordre :

/etc/init.d/clamd stop
/etc/init.d/spamd stop
/etc/init.d/qmail stop
/etc/init.d/qmail start
/etc/init.d/clamd start
/etc/init.d/spamd start

Voilà qui devrait faire l’affaire. Rien ne vous empêche d’ailleurs de vous faire un petit script perso qui vous permette de lancer toutes ces commandes automatiquement les unes après les autres.

Sauvegarder les données de son serveur avec rsync

Ah mais cette fois j’en ai marre … marre de lire à gauche et à droite que rsync n’est pas un outil de backup digne de ce nom. Je m’en vais vous montrer le contraire, et pas plus tard que tout de suite !

Introduction

Soit la situation suivante : j’ai un serveur dédié, par exemple en release 2 OVH (mais cela marchera tout aussi bien avec d’autres distributions Linux). Mes données se trouvent dans /home et je souhaite en faire une sauvegarde quotidienne et incrémentale sur un autre serveur (Linux lui aussi, voire pourquoi pas en release 2).

Incrémentale ? Bah oui, tant qu’à faire, je souhaite ne sauvegarder que les fichiers créés ou modifiés depuis la veille, tout en gardant évidemment un backup complet de mes données aussi récent que possible. Cela n’offre que des avantages :

  1. Économie de temps de transfert et de bande passante (puisqu’on ne transfère tous les jours que les fichiers qui ont été ajoutés / modifiés)
  2. On dispose toujours d’un backup complet qui date du matin même (les backups se faisant la plupart du temps la nuit ou au petit matin)
  3. On garde un historique des fichiers qui ont été modifiés au jour le jour. Idéal en cas de hack du serveur, au premier coup d’oeil : on voit ce qui a été ajouté / modifié et à quelle date.

Création d’un utilisateur sur le serveur de backup

On commence par créer un user dont le répertoire sera dédié au backup. Cela peut se faire en SSH via la commande adduser ou bien par Webmin :  Système > Utilisateurs et groupes > Créer un nouvel utilisateur

Dans mon exemple, mon utilisateur se nommera backupserveur1.

Mise en place des clés SSH

Il faut faire en sorte que les deux serveurs puissent dialoguer de manière cryptée et sans devoir s’échanger de mot de passe. Donc, si ce n’est pas encore fait, il convient de générer une paire de clés SSH.

Donc, sur le serveur source (le serveur à sauvegarder) :
ssh-keygen -b 1024 -t dsa

(valider par la touche “enter” les questions qui vous sont posées)

Personnellement, je dédie ces clés à la procédure de backup entre les 2 serveurs, je les stocke donc dans un répertoire différent. Par exemple :

mkdir /usr/share/keys/
mv /root/.ssh/id_dsa.pub /usr/share/keys/key-rsync.pub
mv /root/.ssh/id_dsa /usr/share/keys/key-rsync

Il convient à présent de copier la clé publique (pas de gaffe, attention) dans le fichier authorized_keys de l’utilisateur backupserveur1 sur le serveur de backup. Il s’agit donc de copier le contenu de key-rsync.pub dans /home/backupserveur1/.ssh/authorized_keys (voire authorized_keys2 selon votre configuration SSH).

Le script

C’est là que ça devient rigolo car le script lui-même tient en une seule et unique ligne que vous pouvez, par exemple créer dans un fichier /root/toto/backup.sh:

#!/bin/bash

rsync -a -e "ssh -i /usr/share/keys/key-rsync" -b --backup-dir=../home-`date -I` --delete /home/ --exclude-from=/root/toto/backup-exclude backupserveur1@11.22.33.44:home/

A mettre en cron, une fois par jour vers 5 heure du matin par exemple.

Explications

Quel sera l’effet de cette ligne de code ?

Elle va tout simplement synchroniser votre répertoire /home avec le répertoire éponyme, lui même situé dans le répertoire de backupserveur1 sur le serveur à distance (donc dans /home/backupserveur1/home). Vous aurez donc ainsi un miroir de votre /home sur le serveur de backup, mis à jour quotidiennement. Jusque là, c’est déjà pas mal … mais en plus cela aura pour effet de créer un répertoire /home/backupserveur1/home-AAAA-MM-JJ qui contiendra tous les fichiers qui ont été modifiés depuis la veille, et seulement eux !

Alors, plutôt sympa rsync, non ? 😉

Dans l’instruction ci-dessus, notez que :

  1. /usr/share/keys/key-rsync doit correspondre à l’emplacement de votre clé SSH
  2. backupserveur1 est bien sûr le nom de l’utilisateur que vous avez préalablement créé sur le serveur de backup
  3. 11.22.33.44 correspond à l’adresse IP du serveur de backup
Attention au fichier /root/toto/backup-exclude

Comme je le disais ci-dessus, ce mini-script sauvegarde l’intégralité de votre /home … ce qui n’est pas forcément souhaitable. Il est donc prévu un fichier “backup-exclude” où vous pouvez lister tous les fichiers et/ou répertoires qui se trouvent dans /home et que vous ne souhaitez pas sauvegarder.

Cette fonction est absolument essentielle sur les serveurs en release 2 OVH car les bases de données MySQL se trouvent précisément dans /home/mysql (c’est une originalité de cette distribution) et le fait de copier les fichiers qui s’y trouvent ne constitue pas un bon backup des bases. A vrai dire, il est même fortement recommandé de ne pas toucher à ces fichiers (donc de ne pas les copier) quand MySQL tourne. Et comme MySQL tourne en permanence … pas touche ! Pour savoir comment backuper proprement vos base, voyez ce billet : Bases de données MySQL : backup quotidien (que vous pouvez d’ailleurs astucieusement combiner avec le système de backup décrit ici)

A titre personnel, sur les serveurs en release OVH, je ne sauvegarde pas les logs ni les stats des sites hébergés (en plus du fameux /home/mysql). Voici donc à quoi ressemble mon “backup-exclude” :

/log
/mysql
www/stats

Je crois que c’est à peu près tout, ouf 🙂

Ah non, j’oubliais, il convient de lancer une première fois le scirpt “à la main” pour que les deux serveurs puisse se reconnaitre. Il s’agit donc simplement de taper…

sh /root/toto/backup.sh

… et de répondre par “yes” à la question qui est posée. Cette question ne sera plus posée à l’avenir et le script peut alors être mis en tâche cron, il s’exécutera sans problème. Notez aussi que ce premier backup risque d’être assez long (cela dépend évidemment quantité de données à transférer) puisque toutes vos données vont devoir être copiées une première fois. Par la suite, les backup seront nettement plus rapide dans la mesure ou seuls les nouveaux dossiers/fichiers (ainsi que ceux qui auront été modifiés) seront transférés quotidiennement.

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 🙂