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 ... Lire la suite]]> 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 serveurt.

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, 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ééé

Seulement voilà, comme je suis un esprit retors, je me suis mis au défi de créer un thème vert et qui me plaise. J’y ai mis quelques jours, mais je suis arrivé à un petit quelque chose dont je suis assez content. Et, pour vous, cela donne un chouette template WordPress gratuit à télécharger goulument :

Sympa, non ? Moi j’aime bien (malgré le vert ) En ... Lire la suite]]> Bon, que les choses soient claires : je n’aime pas trop le vert. Enfin, quand je dis que je n’aime pas le vert, je ne parle pas de la forêt, des paysages, des prairies et des petites fleurs (ça j’aime bien). Je parle de la couleur verte pour le design web.  Un site vert … je ne sais pas, j’ai toujours eu un peu de mal.

Seulement voilà, comme je suis un esprit retors, je me suis mis au défi de créer un thème vert et qui me plaise. J’y ai mis quelques jours, mais je suis arrivé à un petit quelque chose dont je suis assez content. Et, pour vous, cela donne un chouette template WordPress gratuit à télécharger goulument :

Sympa, non ? Moi j’aime bien (malgré le vert ) En tout cas je pense qu’il conviendra à merveille pour les sites ou blogs qui concernent la nature, l’écologie, les énergies renouvelables, etc.

Il est un peu tard pour dire que cela constitue un cadeau de Noël mais bon, on dira que ça sera une manière sympa de démarrer 2012. A propos, excellente année à tous !

Comme d’habitude, il peut être modifié ou adapté à d’autres CMS (Joomla, Drupal,…). N’hésitez pas à prendre contact si cela vous intéresse.

En bref, il semble que PHP cesse d’interpréter correctement la valeur de la variable post_max_size si celle-ci est de 2G. Le résultat est que plus aucun formulaire web ne fonctionne sur aucun des sites concernés par le php.ini dans lequel se trouve cette valeur. Lorsque le formulaire est validé, la page est simplement rafraichie sans que rien d’autre ne se passe.

J’ignore quelles sont les versions de PHP qui sont affectées (pas eu le temps de creuser, désolé) mais j’ai remarqué que la personne qui a rapporté ce bug sur le forum OVH a un serveur dont la configuration est assez semblable à celle de nombreux serveurs dont je m’occupe : Debian (Lenny) + Virtualmin. Une raison de plus pour que je me note ça ... Lire la suite]]> Il faut que je me note ça quelque part, ce sera donc ici. Ce billet fait écho à ce topic sur le forum OVH : http://forum.ovh.net/showthread.php?t=72560.

En bref, il semble que PHP cesse d’interpréter correctement la valeur de la variable post_max_size si celle-ci est de 2G. Le résultat est que plus aucun formulaire web ne fonctionne sur aucun des sites concernés par le php.ini dans lequel se trouve cette valeur. Lorsque le formulaire est validé, la page est simplement rafraichie sans que rien d’autre ne se passe.

J’ignore quelles sont les versions de PHP qui sont affectées (pas eu le temps de creuser, désolé) mais j’ai remarqué que la personne qui a rapporté ce bug sur le forum OVH a un serveur dont la configuration est assez semblable à celle de nombreux serveurs dont je m’occupe : Debian (Lenny) + Virtualmin. Une raison de plus pour que je me note ça en vitesse … et à plus forte raison si la solution est toute simple : il suffit de remplacer la valeur 2G par 2000M

Enfin bref, voici donc le truc bizarre du jour (sur un serveur installé en Debian Lenny + Virtualmin) : un client me dit que Usermin (le webmail qui vient avec Virtualmin et qui se trouve sur le port 20000 – au contraire de Webmin qui se trouve sur le port 10000) n’est plus accessible suite à un reboot de son serveur. Vérification faite, Usermin n’était tout simplement pas lancé. Il a suffit donc de :

Citation non affichée dans ce résumé, voir l'article complet

Et tout est rentré dans l’ordre. Seulement voilà, c’est bien … mais pas suffisant : au prochain reboot, Usermin risque fort de ne plus être lancé. On a beau ne pas rebooter tous les ... Lire la suite]]> A tous les coups c’est pareil : il suffit que je prenne quelques jours de congé pour qu’il se passe un truc bizarre qui m’oblige à bosser. Ca doit être la loi de Murphy…

Enfin bref, voici donc le truc bizarre du jour (sur un serveur installé en Debian Lenny + Virtualmin) : un client me dit que Usermin (le webmail qui vient avec Virtualmin et qui se trouve sur le port 20000 – au contraire de Webmin qui se trouve sur le port 10000) n’est plus accessible suite à un reboot de son serveur. Vérification faite, Usermin n’était tout simplement pas lancé. Il a suffit donc de :

/etc/init.d/usermin start

Et tout est rentré dans l’ordre. Seulement voilà, c’est bien … mais pas suffisant : au prochain reboot, Usermin risque fort de ne plus être lancé. On a beau ne pas rebooter tous les jours, il faut tout de même que cela tienne le reboot ! Je m’empresse donc de vérifier sur un serveur de test et j’arrive à reproduire le problème : Usermin ne se lance effectivement plus au démarrage. Cela doit probablement dater d’une des dernières mises à jour de Usermin (peut-être la version 1.480 datant du 5 aout dernier mais j’ignore précisément laquelle car je reboote fort heureusement assez rarement).

Après une petite recherche Google, il semble que la solution n’est pas bien compliquée (mais pas forcément facile à trouver, d’où ce billet). Elle se trouve ici : http://readlist.com/lists/lists.sourceforge.net/webadmin-list/2/13638.html. Il suffit donc de :

insserv usermin

Et le script d’init est à nouveau correctement activé (au besoin, installer le paquet insserv par apt-get install). Testé et approuvé : ça tient à présent le reboot.

Voilou, ce n’est pas très fouillé et je n’ai pas testé à fond … mais bon, n’oublions pas que je suis en vacances

(prévisualisation et téléchargement, cliquez sur l’image)

C’est un template WordPress, il est téléchargeable gratuitement. Il est tout à fait possible d’ y apporter des modifications ou bien l’adapter à d’autres CMS (Joomla, Drupal,…). N’hésitez pas à prendre contact.

Les utilisateurs assidus de Virtualmin savent que l’installation de la bête est d’une simplicité à faire ricaner un enfant de 3 ans. Pour installer Virtualmin sur une Debian, il suffit de :

Citation non affichée dans ce résumé, voir l'article complet

Et il ne reste plus qu’à laisser tourner le bouzin. Glop glop glop

Sauf que voilà, depuis quelques jours … pas glop.

En lançant l’installateur « comme d’habitude », on se retrouve avec une belle erreur : E: Package postfix-tls has no installation candidate Et, quelques lignes plus loin : FATAL – Cannot continue installation.

En version longue, ça donne ça :

Citation non affichée dans ce résumé, voir l'article complet

Pan dans les dents !

On comprend bien que le ... Lire la suite]]> Tiens, depuis la récente mise à jour de Postfix dans les dépots Debian Lenny, il me semble qu’il y a comme un souci avec l’installateur automatique de Virtualmin.

Les utilisateurs assidus de Virtualmin savent que l’installation de la bête est d’une simplicité à faire ricaner un enfant de 3 ans. Pour installer Virtualmin sur une Debian, il suffit de :

wget http://software.virtualmin.com/gpl/scripts/install.sh
chmod +x install.sh
./install.sh

Et il ne reste plus qu’à laisser tourner le bouzin. Glop glop glop

Sauf que voilà, depuis quelques jours … pas glop.

En lançant l’installateur « comme d’habitude », on se retrouve avec une belle erreur :
E: Package postfix-tls has no installation candidate
Et, quelques lignes plus loin :
FATAL – Cannot continue installation.

En version longue, ça donne ça :

/E: Package postfix-tls has no installation candidate                                                                                                                                 /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install postfix postfix-pcre webmin usermin ruby libapache2-mod-ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libgd2-xpm libapache2-mod-php5 php5-mysql postfix-tls failed.  Error (if any): 0

Displaying the last 15 lines of /root/virtualmin-install.log to help troubleshoot this problem:
INFO - 2011-05-18 20:17:58 - OK
INFO - 2011-05-18 20:18:03 - Hit
INFO - 2011-05-18 20:18:03 - Removing Debian standard Webmin package, if they exist...
INFO - 2011-05-18 20:18:03 - Removing Debian apache packages...
DEBUG - 2011-05-18 20:18:04 - Reading
INFO - 2011-05-18 20:18:04 - Installing dependencies using command: /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install postfix postfix-pcre webmin usermin ruby libapache2-mod-ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libgd2-xpm libapache2-mod-php5 php5-mysql postfix-tls
Reading package lists...
Building dependency tree...
Reading state information...
bind9 is already the newest version.
iptables is already the newest version.
libsasl2-2 is already the newest version.
Package postfix-tls is a virtual package provided by:
postfix 2.5.5-1.1+lenny1
You should explicitly select one to install.

FATAL - Fatal Error Occurred: Something went wrong during installation: 0
FATAL - Cannot continue installation.
FATAL - Attempting to remove virtualmin repository configuration, so the installation can be
FATAL - re-attempted after any problems have been resolved.
FATAL - Removing temporary directory and files.
FATAL - If you are unsure of what went wrong, you may wish to review the log
FATAL - in /root/virtualmin-install.log

Pan dans les dents !

On comprend bien que le paquet postfix-tls pose problème, mais que faire ? La solution existe, elle est un poil difficile à trouver (d’où ce billet) et elle se trouve sur le forum Virtualmin :  http://www.virtualmin.com/node/18213

En bref, il suffit d’éditer l’installateur (install.sh donc) et de commenter les lignes 97, 98 et 99 :

if [ "$?" != 0 ]; then
       debdeps="$debdeps postfix-tls"
fi

On relance le bouzin et (soulagement, volupté), ça remarche.

(prévisualisation et téléchargement, cliquez sur l’image)

Il s’agit d’un template WordPress, il est téléchargeable gratuitement.Il est tout à fait possible d’ y apporter des ... Lire la suite]]> ‘pas grand chose à raconter ces derniers temps (et un peu la flemme), je vais donc donner dans la facilité et sortir de mes cartons un template que j’ai pondu il y a de cela quelques mois. Voici donc « Piteau », un thème WordPress sur fond sombre. Il est plutôt élégant et du genre passe-partout car il vous sera assez facile de replacer l’image du chat par à peu près n’importe quoi, pour peu que l’image ait un fond noir. A propos, ceux qui trouvent le jeu de mot complètement moisi qui se trouve derrière « Piteau » auront le plaisir de gagner … toute ma sympathie

(prévisualisation et téléchargement, cliquez sur l’image)

Il s’agit d’un template WordPress, il est téléchargeable gratuitement.Il est tout à fait possible d’ y apporter des modifications ou bien l’adapter à d’autres CMS (Joomla, Drupal,…). N’hésitez pas à prendre contact.

(contenu de /var/lib/bind/syrelis.com.hosts)

Citation non affichée dans ce résumé, voir l'article complet

A première vue, ça a une bonne tête, mis à part peut-être le numéro de série (ici : 1299337556) qui devrait plutôt être au format « année-mois-jour-chiffre-chiffre », soit 2011030501 à l’heure où j’écris ces lignes) mais passons, ce n’est pas le but de ce billet…

Il manque en tout cas quelque chose d’important, vous ne trouvez pas ?

Il s’agit bien sûr d’un champ NS, car savez sûrement que l’usage veut qu’un nom de domaine doit avoir 2 ... Lire la suite]]> Si vous installez Virtualmin sur un serveur dédié et que vous vous empressez de créer un hébergement (un « Virtual Server » en langage Virtualmin), voici le genre de zone Bind que vous allez obtenir pour votre nom de domaine. Elle sera automatiquement créée par Virtualmin  et, pour l’exemple, je prends ici syrelis.com comme nom de domaine, 11.22.33.44 comme adresse IP et ns1234.ovh.net comme nom de serveur :

(contenu de /var/lib/bind/syrelis.com.hosts)

$ttl 38400
@    IN    SOA    ns1234.ovh.net. root.ns1234.ovh.net. (
1299337556
10800
3600
604800
38400 )
@    IN    NS    ns1234.ovh.net.
syrelis.com.    IN    A    11.22.33.44
www.syrelis.com.    IN    A    11.22.33.44
ftp.syrelis.com.    IN    A    11.22.33.44
m.syrelis.com.    IN    A    11.22.33.44
localhost.syrelis.com.    IN    A    127.0.0.1
webmail.syrelis.com.    IN    A    11.22.33.44
admin.syrelis.com.    IN    A    11.22.33.44
mail.syrelis.com.    IN    A    11.22.33.44
syrelis.com.    IN    MX    5 mail.syrelis.com.
syrelis.com.    IN    TXT    "v=spf1 a mx a:syrelis.com ip4:11.22.33.44 ?all"

A première vue, ça a une bonne tête, mis à part peut-être le numéro de série (ici : 1299337556) qui devrait plutôt être au format « année-mois-jour-chiffre-chiffre », soit 2011030501 à l’heure où j’écris ces lignes) mais passons, ce n’est pas le but de ce billet…

Il manque en tout cas quelque chose d’important, vous ne trouvez pas ?

Il s’agit bien sûr d’un champ NS, car savez sûrement que l’usage veut qu’un nom de domaine doit avoir 2 serveurs DNS. Il est donc logique que sa zone Bind ait 2 champs NS !

Toujours en suivant notre exemple, syrelis.com doit donc avoir 2 serveurs DNS : (1) le primaire qui correspond au serveur sur lequel est installé le site (en l’occurrence ns1234.ovh.net) et (2) le secondaire, qui dépend d’OVH. Chez OVH, quand vous installez un nom de domaine sur un serveur dédié, ils est d’ailleurs nécessaire d’inscrire vous-même le nom de domaine sur le DNS secondaire. Cela se passe dans le manager, plus précisément là (ns1234.ovh.net > Services) :

Inscrire votre nom de domaine dans le DNS secondaire (sdns2.ovh.net – ou bien ns.kimsufi.com si votre serveur est un Kimsufi), c’est bien. Mais faire en sorte que votre serveur communique avec le DNS secondaire, c’est bien mieux ! Pour cela, retournons à votre serveur et ajoutons une ligne dans la zone Bind du nom de domaine :

@    IN    NS    sdns2.ovh.net.

Simple, non ? Oui, mais le problème c’est qu’il va falloir le faire à chaque fois que vous créez un hébergement sur le serveur via Virtualmin. Là, c’est tout de suite moins cool…

Heureusement, il y a une parade simple : juste un petit paramètre à ajouter dans Virtualmin. Commencez donc par cliquer sur System Settings > Server Templates :

Puis sur Default Settings :

Et enfin choisissez BIND DNS Domain :

Ajoutez alors sdns2.ovh.net (ou bien ns.kimsufi.com si votre serveur est un Kimsufi) dans le formulaire, là  :

Et sauvez.

C’est tout. Dorénavant, tous les « Virtual Server » que vous allez créer auront les bons champs NS dans leur zone Bind et, cerise sur le gâteau, toutes les modifications que vous allez faire sur votre serveur (ajout/suppression de sous-domaines par exemple) seront automatiquement transmises au DNS secondaire

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 ... Lire la suite]]> 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 !

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 ... Lire la suite]]> 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’il 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. Pour désactiver ces logs (qui, pour information, se trouvent ici : /var/run/mysqld), 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

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.