Pour un projet, j’ai besoin d’envoyer des SMS lorsque certaines conditions sont réunies. Les tutoriels sur l’envoi de SMS par Raspberry Pi prévoient l’utilisation d’une clé 3G et une carte SD d’un opérateur mobile pour que le Pi dispose d’un numéro de téléphone mobile et puisse envoyer des SMS.
J’ai finalement trouvé 3 solutions :
lorsque le destinataire du SMS dispose d’un abonnement FREE, on utilise l’API de notification SMS FREE. C’est la solution la plus simple.
Sinon, on peut utiliser IFTTT pour envoyer des SMS lorsque certains événements se produisent. Je l’ai fait pendant longtemps. Le gros inconvénient est que IFTTT n’est pas fiable. Il arrive qu’on ne reçoive le SMS que le lendemain. Cà n’est pas acceptable lorsqu’on veut pouvoir alerter.
Enfin, on peut utiliser un agenda google, y créer un événement dès que les conditions prévues sont réunies. Si on a correctement paramétré l’agenda, il enverra un SMS à un destinataire.
Je présente ici les 3 solutions, avec un script PHP placé sur un Raspberry Pi.
Avant de commencer : installer PHP sur le Raspberry Pi
Cette solution très simple ne fonctionne que pour envoyer un SMS à un téléphone FREE.
Obtenir les identifiants de l’API Free
On suit les instructions de « Nouvelle option « Notifications par SMS » chez Free Mobile » pour activer l’option (gratuite) et obtenir une clé d’identification au service. On note aussi notre identifiant d’utilisateur Free Mobile. On obtient les informations suivantes (fausses évidemment mais ressemblantes) :
Utilisateur
12345678
Clé d’Identification
KZuaj37069LOSn
Tester l’envoi de SMS via un navigateur
Mettre l’url suivante dans un navigateur internet :
Pour que les recettes IFTTT fonctionnent, il faut les créer : bouton « create recipe » puis :
cliquer sur « THIS »
Choose trigger channel : ‘maker’ (noter la clé de maker)
Cliquer sur receive a web request
event name = ‘Pi_Manquant’ puis “create trigger”.
cliquer sur “THAT”
Channel ‘Android SMS’ puis cliquer sur “send an SMS” et indiquer le numéro de mobile (avec le code 33 pour la france avant, sans le 0, 33611111111) puis définir les paramètres, en particulier comment utiliser value1, value2 et value3.
Ensuite il « suffit » d’envoyer la requête sous la forme suivante pour que l’événement soit déclenché et la recette IFTTT se réalise !
Noter aussi qu’IFTTT permet de faire plein de choses, comme nous prévenir qu’il va pleuvoir demain ou, plus utile, envoyer un mail lorsque notre mobile reçoit un SMS.
Sur ifttt.com, on peut voir le log de chaque « recette ». Par exemple j’ai vu que l’événement Maker Event « pi_missing » s’est bien déclenché. Mais le SMS arrivera quand IFTTT voudra bien… (c’est gratuit, on ne doit pas se plaindre).
Je trouve par contre que IFTTT fonctionne très bien avec la chaîne GMAIL et envoie des mails immédiatement. Mais si on doit envoyer un message à quelqu’un qui n’a pas de forfait de données sur son téléphone, IFTTT peut quand même être utile, même s’il n’est pas fiable.
La solution avec un agenda Google
Créer un calendrier « spécial Pi » sur google agenda
Dans mon agenda Google, dans la barre latérale de gauche, cliquer sur la flèche à droite de « Mes agendas » et choisir « créer un agenda ». Donner un nom à l’agenda (par exemple « Pi Nautilus ») puis « Créer ». L’agenda est maintenant visible sur le côté gauche, dans la liste des agendas.
Modifier les notifications
Cliquer sur la flèche à droite de l’agenda « Pi Nautilus » et choisir « paramètres » puis aller dans l’onglet « modifier les notifications ».
Si on veut définir un autre numéro de téléphone comme destinataire du SMS, on clique sur le lien « configuration du mobile ».
A ce stade, si quelqu’un crée ou modifie un événement, le téléphone défini reçoit un SMS.
On peut créer des événements automatiquement par un programme. Cette solution, dans laquelle un Pi crée un événement, lorsque certaines conditions sont réunies, est expliquée dans l’article Interagir avec L’agenda Google via l’API (OAuth 2.0) .
Et maintenant ?
Vivement que tous les opérateurs de téléphonie mobile fassent comme Free et proposent une API d’envoi de SMS !
J’hébergeais sur OVH un site assez simple, qui suit le bon fonctionnement de mes Raspberry Pi. Comme j’ai migré l’hébergement OVH sur un VPS OVH avec Plesk, j’ai également dû déplacer ce site.
J’explique donc ici comment installer un site composé de fichiers php et css dans un hébergement Plesk. Ce site n’a pas de base de données et n’utilise pas de gestionnaire de contenus type WordPress.
Créer un sous-domaine et y transférer les fichiers
J’ai ajouté un sous-domaine dans mon compte Plesk, par exemple domicile.mon-domaine.com.
J’y ai transféré les fichiers de l’hébergement initial en ftp. J’ai placé les fichiers dans un répertoire temporaire ‘temp-al’.
Placer les fichiers au bon endroit
Dans Plesk, tel qu’il est paramétré, les fichiers doivent être rangés comme suit :
css dans le répertoire domicile.mon-domaine.com/css
php ou html directement dans domicile.mon-domaine.com/
favicon.ico à la racine (image 256x256px)
NOTA : mon VPS Plesk étant sous linux, les fichiers doivent tous être avec des fins de ligne en mode linux, et pas windows. Sinon ça ne fonctionne pas.
Donner l’accès au site
Lorsque le sous-domaine a été créé, Plesk y a placé un fichier index.html. Pour que ce soit index.php qui soit exécuté, il suffit de supprimer le fichier index.html.
Et maintenant, dans un navigateur, http://domicile.mon-domaine.com ouvre bien sur un site défini par le contenu de index.php.
Afficher les erreurs
En tant qu’administrateur, on peut modifier les paramètres PHP du sous-domaine et régler « display_error » sur « on ».
Nous allons voir ici comment se connecter en FTP à un hébergement Plesk, avec des outils comme net2ftp ou filezilla. La documentation Plesk (Accès FTP au site Web) est complète, j’indique juste ici quels sont les paramètres de connexion dans net2ftp ou Filezilla.
Utiliser net2ftp
Attention, il ne faut utiliser que des net2ftp sécurisés et fiables, comme ceux qui sont proposés par les hébergements OVH (ou aussi par un hébergement Plesk si on actionne le service).
Les identifiants et mots de passe FTP des hébergements Plesk sont définis comme indiqué dans ce document Plesk. Le serveur est simplement le nom de domaine concerné sans rien devant (domaine1.com par exemple)
Utiliser Filezilla
Voici le paramétrage (plesk-id et le mot de passe ont été définis dans comptes FTP du domaine mon-domaine.com) :
Comme sur un hébergement OVH, il faut sauvegarder régulièrement les bases de données et les fichiers des sites hébergés. Avec un VPS équipé de « Plesk-resellers », il faut également sauvegarder les paramètres liés aux clients, abonnements, packs de service. Nous allons voir comment.
Sauvegarder tout ou partie des données Plesk
Cette partie n’est accessible qu’aux administrateurs du compte Plesk resellers.
Dans « outils et utilitaires » > « Gestionnaire de sauvegardes », on peut définir les paramètres de sauvagarde, faire des sauvegardes unitaires ou des sauvegardes planifiées.
Paramètres et configuration du compte client, sites, bases de données, boîtes mails, listes de diffusion
Certificats SSL
Informations sur les DNS
Configuration et contenu du revendeur
Toutes les options ci-dessus, plus :
Contenu des sites Web
Contenu des mails
Contenu des listes de diffusion
Contenu des bases de données
Logs et statistiques
Pages d’erreurs personnalisées
Définir les paramètres de sauvegarde
On peut définir un hébérgement OVH (pro ou perso) comme destination des sauvegardes.
Les paramètres sont définis comme suit (on obtient le nom d’hôte, le nom d’utilisateur FTP et son mot de passe dans le compte OVH de l’hébergement cible) :
Plesk : paramétrage du stockage FTP
Attention, la seule difficulté (que je n’ai résolue qu’après plusieurs échanges avec des techniciens OVH), est que Plesk doit pouvoir écrire sur la « racine » de la cible pour vérifier le bon fonctionnement avant de transférer la sauvegarde.
Donc le champ « répertoire » doit obligatoirement contenir quelque chose et le répertoire défini doit déjà exister dans le compte FTP cible.
Pour une sauvegarde unitaire :
Dans « stocker sous »,
le stockage FTP proposé est celui qui a été défini dans les paramètres de sauvegarde.
Je ne me souviens pas si j’ai défini le lieu de stockage du serveur.
Plesk : sauvegarder pour le « revendeur »
Planifier des sauvegardes
Voici les réglages que j’ai fait.
Plesk : planifier des sauvegardes
Sauvegarder le compte et les sites web (client)
Le client a accès à un menu « compte » dans lequel on trouve les boutons « Sauvegarder le compte et les sites Web » et « Sauvegarder les sites Web ».
Cette option « copier du site web » est accessible aux clients, selon les réglages de leur abonnement. Attention, cette option ne copie pas la base de données.
Lorsque le client clique sur « copie du site web », il peut choisir ses options :
Plesk : copie de site web
On peut utiliser cette fonction pour copier un site vers un autre (le cloner), mais cet autre est OBLIGATOIREMENT un élément du même domaine. Par exemple si je copie « knowledge.parcours-performance.com , je ne peux le copier que vers parcours-performance.com ou un de ses sous-domaines.
Et maintenant ?
Il reste à vérifier que je parviens à restaurer les données sauvagardées si nécessaire.
A la création d’un site, il est indispensable de vérifier la sécurité et l’indexabilité du site WordPress. C’est également indispensable après le transfert d’un site vers un nouvel hébergement. Cette check_list contient des éléments applicables à tout site WordPress et des actions spécifiques au transfert vers un hébergement d’un VPS Plesk. Cet article fait partie de la série Démarrer avec un hébergement VPS Plesk d’OVH.
Vérification de la sécurité
(1) sécuriser tout ce qui peut l’être avec WordPress Toolkit.
Sécuriser un site avec le WordPress Toolkit de Plesk
Après avoir cliqué sur « analyser la sécurité », je donne l’autorisation de sécuriser tout ce qui ne l’est pas.
Nota : selon cet article sur Devblog.Plesk, les changements ne sont pas faits en modifiant .htaccess (et n’en lit même pas le contenu pour définir le statut de sécurité). C’est la configuration du serveur web qui est modifiée. Toute modification du .htaccess va remplacer la configuration serveur correspondante.
Exécuter tous les « hardening » proposés sauf « website firewall protection » (pas dans la version gratuite de sucuri) et « error logs » qui « can not be determined ». Attention, je n’ai jamais essayé de voir si Sucuri peut changer correctement le préfixe de base de données. J’ai procédé comme indiqué dans l’article Changer le préfixe de base de données WordPress.
Dans Settings / Général (ou par une console d’erreur comme Query Monitor), j’ai eu une erreur indiquant que Sucuri n’a plus l’autorisation de stocker les données de Sucuri dans /home/parcoursz/www/wp-content/uploads/sucuri. Au final pour corriger le problème, il suffit de désactiver Sucuri, supprimer les fichiers stockés dans wp-content/uploads/sucuri puis réactiver Sucuri.
(3) Modifier wp-config.php
Vérifier que Sucuri a ajouté define( ‘DISALLOW_FILE_EDIT’, true ); pour interdire la modification de fichiers à partir du tableau de bord WordPress ;
En profiter pour ajouter une instruction pour limiter le nombre de versions stockées pour un article ou une page : define( ‘WP_POST_REVISIONS’, 5 );
(4) Ajuster .hataccess
Normalement c’est inutile pour un site monosite. Pour un site multisite, il faudra l’ajuster, mais ce sera l’objet d’un autre article.
Vérification pour le SEO
Après la création d’un site ou son transfert, il faut vérifier quelques points essentiels pour que le site reste correctement indexé par les moteurs de recherche :
(5) Google analytics
Vérifier que l’identifiant google analytics du site est toujours correctement défini. Pour moi c’est dans le menu « Insight » puisque j’utilise l’extension « Google Analytics par MonsterInsights«
Vérifier que Google Analytics et Google for Webmasters nous considèrent toujours comme propriétaire du site : j’ai laissé un enregistrement TXT contenant un code de vérification Google dans les enregistrements DNS sur OVH (cf l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH). En principe il n’y a pas de problème mais il vaut mieux vérifier car on peut avoir oublié de transférer un fichier html de vérification ou ne pas avoir défini l’enregistrement TXT.
(6) Yoast SEO
Vérifier que les réglages de l’extension sont correctement faits ;
Vérifier que la connexion à la search console est faite correctement ;
Si les sitemaps dans google for webmasters ne sont pas récents, les soumettre à nouveau ;
Dans Google for Webmasters, regarder les erreurs d’exploration et les corriger (redirection) ;
Dans un site nouvellement créé, on vérifiera aussi que l’on a correctement rempli les extraits SEO pour l’ensemble des contenus.
(7) vitesse du site
Tester le site avec Google Test My Site puis corriger les défauts éventuels. Ce site teste l’ergonomie sur appareil mobile, la vitesse sur mobile et la vitesse sur ordinateur.
Avec WordPress, une bonne pratique de sécurité est d’utiliser un préfixe de base de données différent du préfixe par défaut. Celà complique en effet la tâche d’éventuels pirates.
Le préfixe par défaut de WordPress est « wp_ ». On peut le changer lors de l’installation de WordPress ou plus tard. Nous allons voir dans cet article comment changer le préfixe d’un site existant.
Attention, ce changement nécessite une bonne compréhension du fonctionnement d’une base de données pour WordPress. On peut casser un site internet si on le fait mal.
Il faut sauvegarder la base de données avant tout changement.
Ce tutoriel s’applique aux installation WordPress classiques. Pour une installation multisite, suivre les instructions de cet article de WPmuDev.
Changer le préfixe des tables
Quel préfixe choisir ?
L’idéal est d’utiliser 6 à 10 caractères composés de lettres minuscules ou majuscules et de chiffres, tel que p7fQ25Hg_ ou i9s5c0Fu1P_. Pour le créer, l’idéal est d’utiliser lastpass password generator, en n’oubliant pas d’ajouter « _ » à la fin du préfixe généré.
Avec phpMyAdmin :
Sauvegarder la base de données ;
Remplacer le préfixe de table : en sélectionnant toutes les tables (tout cocher) puis « remplacer le préfixe de table ».
WordPress : changer le préfixe de base de données (2)
Et voilà, le préfixe des tables de notre base de données est devenu « newprefix_ ». A ce stade, notre site ne fonctionne plus du tout ! En effet, on n’a pas encore « dit » à WordPress que le préfixe de tables a changé.
Modifier wp-config.php
On édite wp-config.php pour que la ligne :
$table_prefix = 'wp_';
devienne
$table_prefix = 'newprefix_';
Après enregistrement du fichier modifié, les internautes peuvent de nouveau accéder au site. Mais l’accès au tableau de bord reste bloqué.
Changer le préfixe de certains contenus des tables
Le préfixe de table est également utilisé à l’intérieur de certaines tables. C’est le cas de certains contenus du champ option_name de la table « newprefix_options », et du champ meta_key dans la table « newprefix_usermeta ».
Modifier les « option_name » avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_options » est :
SELECT * FROM `newprefix_options` WHERE `option_name` LIKE '%wp_%'
On peut aussi le faire dans l’interface graphique de phpMyAdmin.
On obtient une liste d’éléments de la table qui contiennent wp_. Mais attention, bon nombre de lignes ne doivent pas être modifiées. Pour le site dont je réalise la modification en écrivant ce tutoriel, j’ai obtenu 78 lignes dans lesquelles ‘option_name’ est « LIKE » ‘wp_’. En fait, la seule à modifier (à la main) est wp_user_roles qui devient newprefix_user_roles .
Modifier les meta_key avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_usermeta » est :
SELECT * FROM `newprefix_usermeta` WHERE `meta_key` LIKE '%wp_%'
Pour s’y retrouver, on ordonne la colonne « meta_key » puis on modifie, à la main, toutes les entrées pour lesquelles la valeur de « meta_key » commence par wp_. En général on trouve les valeurs suivantes, autant de fois qu’il y a d’utilisateurs enregistrés pour le site :
wp_capabilities
wp_dashboard_quick_press_last_post_id
wp_media_library_mode
wp_user-settings
wp_user-settings-time
wp_user_level
A ce stade, on vérifie que tout va bien en se connectant au tableau de bord du site modifié. Si tout va bien, on arrive à se connecter et on a terminé.
En cas de problèmes
Cet article de WPmuDev, donne quelques pistes si on observe des dysfonctionnements après le changement de préfixe.
Problème n° 1 : pas d’accès au site
Lorsqu’on met l’adresse du site dans un navigateur, on arrive à un écran nous proposant d’installer WordPress !
La solution est de modifier wp-config.php pour que la ligne $table_prefix = ‘newprefix_’; contienne la bonne valeur du nouveau préfixe.
Problème n°2 : les utilisateurs n’ont plus la permission de se connecter au site
Dans ce cas, on a omis de modifier une ou plusieurs entrées de la table « newprefix_usermeta » et certaines valeurs de « meta_key » contiennent toujours le préfixe « wp_ ». Il faut donc vérifier ce que l’on a fait.
Notre problème n’est pas résolu ?
Voir l’article How to Fix “Error Establishing Database Connection” for WordPress. Il arrive en particulier que des extensions mal codées utilisent uniquement le préfixe par défaut « wp_ ». Dans ce cas, elles ne peuvent plus fonctionner une fois le préfixe changé. Pour les identifier, on désactive toutes les extensions puis on les réactive une à une jusqu’à ce que le site casse. Une fois l’extension problématique identifiée, on la supprime. On peut aussi revenir à la copie de la base de données réalisée avant le changement.
Dans les enregistrements DNS du domaine, deux enregistrements (MX et TXT renseignant spf) définissent que Plesk doit gérer la messagerie. Voir l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH pour plus de précisions.
On pourra définir des adresses et leurs redirections éventuelles. On peut également définir des alias de messagerie. Si quelqu’un envoie un mail à cet alias, elle est automatiquement redirigée vers l’adresse principale. C’est pratique comme adresse « jetable ». Si elle est trop spammée, on la supprime.
J’utilise RoundCube comme messagerie web. Dans ce cas, l’utilisateur peut y accéder par l’url http://webmail.mon-domaine.com/roundcube/ .
le service Plesk doit être désactivé en décochant « activer le service de messagerie » dans les paramètres de messagerie du domaine.
Cas 3 : un script php envoie des mails à partir d’un sous-domaine
J’ai un sous-domaine qui contient une page web servie par un fichier php. Lorsqu’on ouvre cette page, ça déclenche une vérification. Si il y a une anomalie, un mail m’est envoyé. Une tâche planifiée (cron) fait la même chose régulièrement.
Le problème c’est que le domaine principal est réglé pour que G Suite gère la messagerie. Dans ce cas, un mail émis par un script php est bien expédié mais je reçois un message (en spam) me disant que le mail est peut-être un spam.
La solution :
Il faut modifier l’enregistrement DNS suivant, dans Plesk :
Dans ce quatrième article de la série Démarrer avec un hébergement VPS Plesk d’OVH, nous allons parler d’une fonctionnalité très utile de l’interface Plesk. Il s’agit de la possibilité de visualiser, et même de modifier, un site internet alors même qu’il n’est « officiellement » pas hébergé (il pointe vers un autre hébergement).
Le cas d’utilisation type est le transfert d’un site, d’un hébergement vers un autre, équipé de Plesk.
Vérifier que la page d’accueil paraît OK
Si vous voulez simplement vérifier le site avant de pointer l’enregistrement DNS de type « A » vers l’IP du serveur Plesk, vous utilisez la fonction « aperçu » (cf documentation Plesk).
On voit alors un site dont l’adresse du type http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/
Les liens, et donc les menus, ne fonctionnent pas puisque notre site est réglé avec des liens de type https://knowledge.parcours-performance.com . Mais on voit ainsi facilement si le site a l’aspect qu’il devrait avoir.
Faire des modifications avant de pointer vers cet hébergement
Lorsqu’on pointe le nom de domaine vers le nouvel hébergement, il peut s’écouler jusqu’à 24 heures avant que l’ensemble des ordinateurs du monde aient cette information. Si l’ancien hébergement fonctionne toujours (préférable pour éviter une erreur 404 en attendant la propagation des DNS), on ne sait pas si le site qu’on voit est l’ancien ou le nouveau. Il faut donc qu’il y ait une petite modification quelque part pour le savoir.
Modifier dans la base de données du nouvel hébergement
C’est ce que j’ai fait jusqu’à présent. Dans la table prefixe_options, j’ai ajouté un « . » ou un « ! » dans la description du site. Comme ça je vois d’un coup d’œil si je regarde l’ancienne ou la nouvelle version.
Modifier le site « virtuel »
Nous avons vu tout à l’heure qu’on peut prévisualiser le site avec la fonction aperçu de Plesk.
Si son adresse est http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/ , on peut se connecter à son tableau de bord avec l’url http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/wp-login.php .
Il suffit ensuite de modifier l’adresse du site dans le menu « Réglages » > « Général » de WordPress :
Plesk modifier les permaliens en mode aperçu
Après avoir enregistré ce réglage, on va dans le menu « Réglages » > « Permaliens » et on clique sur « enregistrer les modifications », sans faire aucune modification. Maintenant tous nos liens fonctionnent, sauf s’ils ont été créés avec une référence absolue, par exemple dans un widget texte. On peut donc faire toutes les modifications qu’on veut dans un site que personne d’autre ne voit.
Evidemment, avant de pointer les DNS sur ce site, il faut aller remettre les réglages du site comme ils étaient et enregistrer les nouveaux permaliens.
L’ensemble de ce qui suit a été mis à jour le 30/10/2016 une fois que j’ai mieux compris ce qu’il fallait faire.
Les enregistrements DNS sont un sujet très compliqué (que je comprends encore mal). Dans cet article j’indique des réglages qui fonctionnent pour des noms de domaines gérés par OVH avec un hébergement tiers.
J’ai créé cet article dans le cadre de ma série Démarrer avec un hébergement VPS Plesk d’OVH. Il est cependant fort probable qu’il s’appliquerait à un hébergement tiers équipé de Plesk même s’il n’était pas hébergé chez OVH.
Attention : j’apprends en faisant. Il est très probable que mes explications seront erronées. Si vous lisez ce billet, n’hésitez pas à faire des commentaires pour faire des corrections ou compléter les explications.
A quoi ça sert ?
Les enregistrements DNS servent à dire aux ordinateurs du monde entier comment transformer un nom de domaine en adresse IP. La valeur définie est alors connue de tous les serveurs DNS qui doivent « router » des url. On voit par exemple sur whatsmydns.net quelle IP gère l’hébergement du site parcours-performance.com (ses enregistrements « A »), qui gère ses DNS (enregistrements « NS ») ou qui gère ses mails (enregistrements « MX »). C’est une information publique.
Avant de modifier les DNS
« Mémoriser » les réglages avant tout changement
Faire les captures d’écran (ou un copier-coller) des valeurs indiquées dans l’onglet « Zone DNS » d’OVH et le menu « paramètres DNS » sur le VPS. Je colle ces captures dans un fichier Word que je sauvegarde avant de commencer. Et je note dans ce même fichier les modifications réalisées ainsi que l’heure de modification. Sinon je suis vite perdue si tout ne fonctionne pas correctement.
Vérifier soigneusement le site sur Plesk
Avant de transférer tous les internautes sur le site hébergé sur Plesk, il faut bien vérifier les réglages :
le préfixe de bdd doit être le bon et repris dans wp-config.php
dans la base de données, l’adresse du site et son home sont les bonnes.
Dans les paramètres d’hébergement, on doit avoir défini le domaine préféré ( www.domaine1.com / domaine.com / Aucun(e) )
Un réglage de DNS qui fonctionne
Le domaine est géré par OVH, avec ses serveurs de noms de domaine. En effet, comme indiqué par un technicien d’OVH, le serveur VPS Classic ne gère pas les DNS secondaires. [je ne sais pas ce que c’est, mais ça a l’air important…], il faut donc laisser OVH gérer les DNS.
si on a des doutes sur le lieu où héberger ses serveurs de nom :
https://christophegx.ovh/faut-il-heberger-vos-propres-serveurs-de-noms-de-domaine-dns/
Les réglages sur OVH
Le site « mon-domaine.com » n’est plus hébergé sur OVH. Seul son nom de domaine y est resté. L’hébergement est réalisé sur un serveur VPS Classic de chez OVH, avec Plesk 12.5.
Dans l’espace client OVH les onglets « redirection » et « gestion DNS » sont mis à jour automatiquement en fonction de ce qui figure dans « zones DNS ». On n’y touche donc pas. Toutes les modifications qui suivent concernent donc l’onglet « zones DNS » de l’espace OVH.
Le réglage des serveurs de nom de domaine
On commence par visiter l’onglet Gestion DNS et on relève les identifiants (ici ns20.ovh.net et dns20.ovh.net)
OVH onglet « gestion DNS »
Dans l’onglet Zone DNS on doit alors avoir ces deux lignes :
Domaine
TTL
Type
Cible
domaine1.com.
0
NS
dns20.ovh.net.
domaine1.com.
0
NS
ns20.ovh.net.
Le réglage des hébergements web (domaines et sous-domaines)
Les enregistrements A servent tous à dire à un ordinateur distant que si ils cherchent quelque chose relatif au domaine ou sous-domaine demandé, il doit aller voir le serveur dont l’adresse IP est 149.202.166.57 (pour moi) pour obtenir une réponse.
Pour chaque domaine ou sous-domaine hébergé ailleurs, je dois créer une entrée A vers l’IP du serveur. Dans ce cas, j’ai un domaine principal et deux sous-domaines. J’ajoute donc 3 enregistrements A.
Enfin, si je souhaite que www.domaine1.com redirige vers domaine1.com, j’ajoute un enregistrement CNAME. Mais attention, la redirection ne fonctionne que si on a défini aussi, dans Plesk, les paramètres d’hébergement sur domaine1.com comme domaine préféré.
Au final, j’ajoute donc ces 4 lignes :
Domaine
TTL
Type
Cible
domaine1.com.
0
A
149.202.166.57
sub1.domaine1.com.
0
A
149.202.166.57
sub2.domaine1.com.
0
A
149.202.166.57
www.domaine1.com.
0
CNAME
domaine1.com.
Le réglage des mails
Cas 1 : gestion par Google Apps (G Suite) des mails
Dans ce cas, conformément aux instructions de Google, j’ajoute les 5 enregistrements MX suivants.
Et comme il faut que le gestionnaire de mail en valide l’origine lorsque j’expédie des mails, j’ajoute le champ TXT suivant.
Domaine
TTL
Type
Cible
domaine1.com.
0
MX
5 alt1.aspmx.l.google.com.
domaine1.com.
0
MX
5 alt2.aspmx.l.google.com.
domaine1.com.
0
MX
1 aspmx.l.google.com.
domaine1.com.
0
MX
10 aspmx2.googlemail.com.
domaine1.com.
0
MX
10 aspmx3.googlemail.com.
domaine1.com.
0
TXT
« v=spf1 include:_spf.google.com ~all »
Si on prévoit d’utiliser des scripts sur Plesk qui enverront des mails, le réglage TXT « v=spf1 … » n’est pas satisfaisant (soft fail dans les mails émis par le serveur Plesk). Il faut utiliser :
Il faut au minimum régler le ftp, avec un enregistrement CNAME.
Si l’un des domaines ou sous-domaines est vérifié par Google for Webmasters ou Google Analytics avec un champ TXT, je l’ajoute également.
ftp.domaine1.com.
0
CNAME
ftp.domaine1.com.
domaine2.com.
0
TXT
« google-site-verification= je…d4 »
On pourra consulter la documentation plesk sur les DNS, mais elle me semble très cryptique comme tout ce qu’on peut lire sur le sujet.
Les réglages sur le serveur (Plesk)
Mode « maître » ou « esclave » ?
La logique voudrait qu’on règle le serveur Plesk en mode esclave puisqu’en principe aucun des enregistrements DNS qui y figurent ne servent. MAIS, ça n’est pas vrai.
J’ai réglé pendant un temps les DNS du domaine parcours-peformance.com en mode esclave sur Plesk. Mais dans ce cas, on ne peut plus ajouter de sous-domaine car les serveurs ne le trouvent pas, même si on a bien défini un enregistrement A dans OVH (et laissé au moins 24h pour leur propagation).
Finalement je suis revenue au mode « maître » après avoir lu ce document Plesk : Utiliser des serveurs DNS externes et tout fonctionne à la perfection. Ma recommandation est donc de laisser la zone DNS de Plesk en mode maître. Dans la réalité ce sera bien le serveur OVH qui sera maître.
Les réglages DNS Plesk se sont générés automatiquement (selon un template qui a probablement été défini par OVH) :
Hôte
Type
Valeur
domaine1.com.
TXT
« v=spf1 include:_spf.google.com ~all »
sub1.domaine1.com.
A
149.202.166.57
sub2.domaine1.com.
A
149.202.166.57
ftp.domaine1.com.
CNAME
domaine1.com.
ipv4.domaine1.com.
A
149.202.166.57
ns2.domaine1.com.
A
149.202.166.57
domaine1.com.
NS
ns2.domaine1.com.
ns1.domaine1.com.
A
149.202.166.57
domaine1.com.
A
149.202.166.57
webmail.domaine1.com.
A
149.202.166.57
mail.domaine1.com.
A
149.202.166.57
domaine1.com.
MX (10)
mail.domaine1.com.
domaine1.com.
NS
ns1.domaine1.com.
On notera qu’il y a des enregistrements (TXT ou MX) différents de ceux d’OVH. Pourtant, une recherche sur WhatsmyDNS.net indique que ce sont bien les enregistrements OVH qui sont pris en compte.
En cas de problème…
J’ai rencontré des difficultés réelles lorsque j’ai transféré ce site d’un hébergement OVH mutualisé à ce nouvel hébergement sur un VPS OVH. Je ne suis toujours pas trop sûre de ce qui a posé problème, probablement le choix d’un mode esclave.
Le temps de propagation, jusqu’à 24 heures !
Lorsqu’on modifie un enregistrement DNS, il peut falloir 24h (voire plus) pour que tous les serveurs du monde soient au courant. Donc si on fait une modification, on attend au moins 4 à 6 heures avant de considérer qu’elle a été prise en compte.
Il ne sert à rien de faire plein de modifications coup sur coup sans attendre d’en connaître le résultat.
Les outils à notre disposition
Si on a des extensions qui affiche des informations système , comme Sucuri (onglets « site information » puis « config. variables ») ou Query Monitor (menu environment), on peut voir quel est l’hôte de base de données.
Impératif : On peut aller regarder sur « whatsmydns.net » (lien dans la barre latérale, à droite) pour voir si la propagation s’est faite, et où. On voit ainsi progressivement les serveurs du monde entier prendre en compte les modifications faites.
Le plus simple pour savoir ce qui se passe à partir de son ordinateur est de faire un « ping » : dans l’invite de commande Windows, taper ping knowledge.parcours-performance.com . La réponse devrait être avec l’IP du VPS Plesk :
Envoi d’une requête 'ping' sur knowledge.parcours-performance.com [149.202.166.57] avec 32 octets de données :
Réponse de 149.202.166.57 : octets=32 temps=58 ms TTL=56
Réponse de 149.202.166.57 : octets=32 temps=58 ms TTL=56
Réponse de 149.202.166.57 : octets=32 temps=58 ms TTL=56
Réponse de 149.202.166.57 : octets=32 temps=59 ms TTL=56
Statistiques Ping pour 149.202.166.57:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 58ms, Maximum = 59ms, Moyenne = 58ms
On peut aussi utiliser tracecert (Windows) ou traceroute (Linux ou MacOS) pour voir le chemin à parcourir de l’ordinateur qui émet la commande à ce domaine.
Par exemple pour ce site, je tape la ligne suivante dans l’invite de commande
Détermination de l’itinéraire vers knowledge.parcours-performance.com [149.202.166.57]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.1
2 56 ms 57 ms 56 ms par-1-rdb.fr.eu [178.32.37.3]
3 57 ms 56 ms 56 ms be99-11.th2-1-a9.fr.eu [178.32.37.134]
4 61 ms 60 ms 63 ms be10-1191.gra-g2-a9.fr.eu [94.23.122.86]
5 60 ms 60 ms 61 ms po7.gra-z1g1-a70.fr.eu [37.187.232.79]
6 61 ms 61 ms 61 ms 10.97.155.4
7 61 ms 60 ms 60 ms 51.255.252.133
8 60 ms 61 ms 61 ms 149.202.255.41
9 61 ms 60 ms 60 ms hr-da00000-1.reseller.mis.ovh.net [149.202.166.57]
Itinéraire déterminé.
Windows a d’abord déterminé l’IP du serveur correspondant au domaine [149.202.166.57] puis en envoyé un « paquet » jusqu’au dit serveur. Pour cela, il a dû contacter 8 routeurs avant d’arriver au serveur final. Toutes ces demandes ont nécessité pratiquement une demie seconde en tout, juste pour arriver au serveur.
Les réinitialisations
Si on est vraiment perdu, il peut être utile de procéder à une réinitialisation des zones DNS :
Dans OVH, en cliquant sur le bouton « Réinitialiser la configuration ». On a ensuite deux options :
« Oui, je veux réinitialiser ma zone DNS avec les entrées minimales. » : si on veut réinitialiser a minima ;
« Non, mais je veux réinitialiser ma zone DNS. » si on veut réinitialiser avec plus d’éléments (ça n’est pas du tout clair…)
Dans Plesk, en cliquant sur le bouton « Rétablir le paramètrage initial ».
Mon expérience est que les paramètres initiaux sont une bonne base. Mais attention, on perd les informations spécifiques (par exemple si on a un abonnement téléphone sur IP chez OVH). Il faut impérativement copier-coller les lignes existantes avant la réinitialisation.
Et maintenant
On attend que la propagation soit réalisée et ça y est. Le site est dans un nouvel hébergement. Ses mails et son accès FTP fonctionnent.
Les enregistrements DNS me semblent toujours très obscurs. J’espère que vous serez nombreux à nous faire part d’améliorations / corrections ou clarifications.
Dans ce troisième article de la série Démarrer avec un hébergement VPS Plesk d’OVH, nous allons voir comment déplacer le contenu d’un hébergement OVH Pro dans un hébergement créé sur le VPS Plesk. Nous allons transférer un site internet sous WordPress et les adresses mails du compte. La gestion du domaine restera sur OVH.
La situation initiale
La propriétaire du site a déjà un compte client dans l’interface Plesk de mon VPS Classic 1. Je lui ai affecté un abonnement Clea-Pro, qui correspond à Cléa-perso (tel que paramétré dans l’article précédent de cette série), avec 4 bases de données et plus d’adresses mail.
Sur son hébergement OVH Pro, le site est à jour (WordPress et extensions) et fonctionne. Son adresse est http://parcours-performance.com.
A ce stade, je ne change rien dans l’espace client OVH. C’est seulement à la fin des opérations de transfert que je ferai la bascule.
Lorsque j’ai créé le domaine parcours-performance.com sur Plesk, il y eu l’affichage d’un warning et d’un OK :
C’est normal puisqu’OVH pointe toujours le domaine vers le site web actuel. Mais nous verrons que Plesk nous permet de visualiser le site que l’on veut déplacer avant même d’avoir dit au monde entier qu’il est déplacé. C’est génial car nous pourrons éliminer les erreurs éventuelles avant de montrer les résultats aux tiers !
Pour déplacer le site, il y aura plusieurs étapes :
sauvegarde du site actuel ;
Créer un site WordPress générique
transférer les contenus spécifiques du site à l’hébergement Plesk
vérifier, corriger
Pointer le domaine vers le nouveau site
Faire les autres transferts tels que les adresses mail
supprimer l’ancien site et résilier l’abonnement correspondant
sauvegarder fichiers et base du site actuel
Avec Filezilla pour les fichiers et phpmyadmin pour la base de données.
Nota du 23/11/216 : pour des raisons que j’ignore, l’export via PHPMyAdmin provoque parfois une erreur : les index et auto-incrémentations ne sont pas transférés. Dans ce cas, il faut aller dans l’interface client de l’hébergement OVH original et demander une sauvegarde de la base de données (un dump) que l’on reçoit quelques minutes plus tard par mail. Cette sauvegarde s’importe ensuite sans souci dans la base Plesk.
Dans l’hébergement Plesk, créer un site WordPress
ajouter une base de données
Dans le menu « base de données », cliquer sur le bouton « ajouter une base de données ».
Voici les réglages que j’ai fait (évidemment j’ai changé le nom de la base et son nom d’utilisateur après la capture d’écran) :
La base de données est créée mais elle est vide à ce stade.
installer WordPress
On installe WordPress en mode « installer (personnaliser) :
Les paramètres sont les suivants :
Noter que j’ai pris le parti d’installer tout de suite en https (le site sur OVH est en http). C’est totalement idiot car la base de données que je vais importer ne contient que des liens en http. Heureusement ça n’a pas créé de problème…
Il faut également noter que je n’ai pas indiqué de préfixe de table. Mais WordPress en a généré automatiquement quand même.
J’ai mis un administrateur du site temporaire ‘temp’ que je supprime dès que j’ai l’accès à mon tableau de bord WordPress.
Une fois l’installation faite (il peut s’écouler un certain temps), Plesk nous affiche un écran de succès :
Attention, le site n’existe pas puisque le domaine pointe toujours sur un hébergement OVH Pro.
Mais Plesk a un magnifique outil, « aperçu », qui permet de voir le site alors qu’il n’existe pas pour le reste du monde. On en reparlera tout à l’heure.
Modifier le contenu de la base de données
Je vais devoir réaliser plusieurs opérations :
supprimer les tables actuelles de la base de données ;
importer les tables du site parcours-performance.com ;
modifier wp-config.php pour utiliser le préfixe des tables transférées ;
Si votre site a toujours un préfixe de tables en wp_, ce sera l’occasion d’en changer !
Changer les tables de la base de données
Avec phpMyAdmin, je supprime toutes les tables que WordPress vient d’installer puis j’importe le contenu de la sauvegarde du site en ligne sur l’hébergement OVH Pro.
Le site ne fonctionne plus pour l’instant. Il nous reste deux opérations à mener.
modifier wp-config.php
Dans wp_config.php, je change la ligne qui contient le préfixe de table. Pour l’instant j’y indique
$table_prefix = 'wp_';
Il faudra ensuite que je modifie ce préfixe.
transferer wp-content
Avec le gestionnaire de fichiers, je supprime le répertoire wp-content actuel et je charge le wp-content (zippé) du site de l’hébergement OVH Pro.
Pour celà, je me suis connectée en ftp avec filezilla. Comme le domaine parcours-performance.com pointe toujours sur l’hébergement OVH, j’utilise l’adresse IP du serveur VPS et pas le nom de domaine :
hote : l’adresse IP du VPS (par exemple 111.222.333.44), sans port défini
protocole FTP
Chiffrement Connexion FTP explicite sur TLS si disponible
nom d’utilisateur : défini dans « accès FTP »
mot de passe : défini dans « accès FTP »
authentification normale
Voir le site
Plesk dispose d’un magnifique outil qui permet de pré-visualiser le site, alors même que le monde entier pointe toujours sur le site tel qu’il est hébergé par OVH.
Il suffit de cliquer sur « aperçu » et on voit le site tel qu’il est actuellement sur Plesk.
Les liens sont cassés. C’est normal puisqu’en mode aperçu le site croit que son adresse est http://149.202.166.57/plesk-site-preview/parcours-performance.com/149.202.166.57/ tandis que la base de données contient des liens commençant par http://parcours-performance.com/.
Ajustements
Régler pour que le site soit avec ou sans www
Pour ma part, je choisis toujours sans www. Cette action crée un enregistrement CNAME dans les DNS pointant www.parcours-performance.com vers parcours-performance.com
Pointer le domaine sur l’hébergement Plesk
C’est la phase qui permet au monde entier de savoir que le domaine (ici parcours-performance.com) est hébergé par l’IP 149.202.166.57.
Notre site a été transféré. Une fois qu’on est sûr de son bon fonctionnement, on peut résilier son ancien hébergement.
Cet article fait partie de la série Démarrer avec un hébergement VPS Plesk d’OVH. Elle continue jusqu’à ce que j’ai l’impression d’avoir bien compris le fonctionnement de Plesk.
Commentaires récents