Config serveur Article

Validation Let’s Encrypt avec un domaine protégé

Validation Let’s Encrypt avec un domaine protégé

Je viens de perdre un peu de temps sur un problème, alors je partage ma solution ici.

J’ai un nouveau serveur sur lequel je souhaitais passer en SSL pour mes domaines protégés. Comme Let’s Encrypt propose des certificats SSL gratuits et de qualité, je me suis tourné vers cette solution. Pour l’installation, c’est facile et vous trouverez plein de tutoriel sur ce sujet.

Let’s Encrypt propose de valider le nom de domaine en allant vérifier le répertoire .well-known dans votre racine web. Comme chaque certificat émis ne dure que 3 mois, il faut créer une tâche CRON qui va permettre de valider le domaine, émettre un nouveau certificat et l’installer.

Problème, si votre accès au domaine est protégé par un .htaccess couplé à un .htpasswd alors la validation n’a pas lieu correctement puisque l’accès et refusé. Voici une solution très simple. à laquelle j’aurais dû pensé plus tôt … Du fait de son fonctionnement même htaccess fonctionne répertoire par répertoire, il suffit donc d’aller créer un .htaccess dans le répertoire .well-known et y ajouter les instructions suivantes :

Vous pouvez maintenant tester et Let’s Encrypt aura bien accès au répertoire .well-know pour sa validation. Ainsi le certificat pourra être émis de nouveau sans problème.

J’espère que ça vous aidera.

 

 

Sitemap : Erreur 404 avec WordPress sous Nginx

Sitemap : Erreur 404 avec WordPress sous Nginx

Comme je viens de passer un petit moment à trouver une solution pour ce problème, je me suis dit que je partagerais la solution ici comme mémo mais aussi pour ceux qui seraient confronté au problème.

Mon plugin WordPress pour créer un sitemap est Better WordPress Google XML Sitemaps. Mais le problème semble être le même avec Yoast SEO. Vous pourrez surement donc adapter la solution pour Yoast.

En configurant votre Nginx pour WordPress, vous devez avoir créé une ligne qui ressemble à ceci :

Comme les plugins de WordPress n’écrive pas le fichier sitemap.xml en dure sur le serveur, il génère en dynamique (avec cache) le sitemap. Il faut donc diriger sitemap.xml vers la bonne URL qui va générer le sitemap. Voici pour ma part ce que j’ai utilisé dans mon fichier nginx.conf (dans la racine de mon site, mais vous pouvez le mettre dans votre fichier de config de nginx ou de vhost directement).

ATTENTION : À ce stade, si vous souhaitez tester si ça fonctionne il faut REDÉMARRER NGINX

Soit faire la commande suivante :

Voilà, votre sitemap a retrouvé ces couleurs et est prêt à servir google et autres répertoires …

Si vous avez des questions, n’hésitez pas.

Utiliser l’éditeur VIM pour changer de vie

Voici quelques semaines que j’utilise VIM pour éditer les fichiers sur Linux et je dois dire que ça me simplifie la vie. Les puristes rigoleront d’entendre ça car pour eux il s’agit DU meilleur éditeur toute catégorie confondue. J’ai toujours préférer la simplicité de nano et toujours perçu VIM comme un outil complexe … mais c’est en fait l’inverse si l’on connait les quelques commandes de base de VIM. Attention, cet article s’adresse aux débutants Linux (comme moi) et qui veulent en apprendre un peu plus.

Je vais donc vous présenter rapidement ce qu’il faut savoir pour commencer à utiliser VIM  et j’espère convaincre les débutants de le substituer à nano.

Fonctionnement et bases de l’éditeur VIM 

Premièrement il est important de savoir qu’il existe 2 modes, le mode édition (changer les texte) et le mode lecture (on parcours le fichier). 

Lorsqu’on ouvre un fichier avec VIM (vim monfichier.txt), on ouvre le fichier en mode lecture, si on veut éditer le fichier il faudra alors taper « i » (pour insert). Revenir en mode lecture se fera grâce à touche « ESC ». 

Lorsque vous êtes en mode édition, pour sauver le fichier il faut repasser en mode lecture (appuyer sur la touche ESC) et saisir « :w » et appuyer la touche « Entrer ». Le texte  « :w » s’affichera en bas de la fenêtre de votre terminal. Il est aussi possible de sortir du document au moment de sauver le fichier, saisissez alors « :wq ».

Il est aussi simple de sortir du document en saissant « :q ».

Résumé des commandes de bases de VIM

i = passer en mode edition
esc = Passer en mode lecture
:w = ecrire (en mode lecture)
:wq = ecrire et quitter le fichier (en mode lecture)

Conclusion : 

Comme vous pouvez le voir, VIM est au final très facile à utiliser et se révèle tellement plus pratique que nano. Si vous souhaitez gagner en productivité, je vous le conseil.

 

Migrez de nom de domaine avec WordPress en 4 étapes faciles

Changer de nom de domaine dans WordPress se trouve être utile généralement lorsqu’on migre d’un environnement de développement à l’environnement de production. Par exemple vous avez construit votre blog en local sur votre ordinateur à l’aide de MAMP ou WAMP ou Easy PHP … et vous souhaitez le mettre en ligne sur votre serveur de production.

Réaliser cette migration se fait en 4 étapes faciles : 

Faire une copie de vos fichiers WordPress

Rien de plus simple, avec votre logiciel FTP, vous envoyez les fichiers sur votre serveur de production. (Généralement à la racine du serveur).

Faire un export de votre base de données

Allez dans PhpMyAdmin de votre serveur de développement et exportez la base de données. (SQL ou ZIP au choix). Allez ensuite sur PhpMyAdmin de votre serveur de production et importez les données via le fichier que vous venez de créer.

Modification sur la base de données 

La base de données WordPress contient dans certaines tables le nom de domaine de votre blog. Pour changer ces informations vous pouvez exécuter votre ces requête SQL suivante dans PphpMyAdmin : 

Changez « http://www.dev-site.com » par l’url de votre environnement de développement et « http://www.production-site.com » par votre nom de domaine de production. Attention le préfixe des tables « wp_ » pourrait être différent pour vous. Attention aux « www » aussi. Si la première requête ne donne aucun résultat, essayez sans les www.

Modifier la config de WordPress

Dans votre logiciel FTP éditez le fichier wp_config.php et remplacez les informations de bases de données par celles de production :

Conclusion

J’ai crée cette procédure pour mes besoins personnels, j’espère qu’elle vous sera utile à vous aussi, c’est pour ça que je la partage ici. Pour une migration réussie pensez à :

  • avoir au moins 1 heure devant (en cas de problème)
  • être concentré (couper le téléphone et les distractions).
  • Tester une fois la migration finie (toutes les pages, les posts si possibles, les formulaires …)

Protéger vos .svn en production

Une chose à laquelle on ne pense pas souvent lorsqu’on passe en production un projet, c’est de supprimer / bloquer l’accés aux fichiers .svn. Ces fichiers ont beau être des fichiers cachés, ils n’en sont pas moins accessibles via un navigateur. Je vous conseille de faire le test avec votre serveur, vous serez surement surpris ! Il est important de protéger ces fichiers qui peuvent contenir de l’info utile à un pirate qui voudrait s’amuser sur votre serveur.

Pour se protéger, il existe 2 façons de faire : 

Faire un svn export de votre projet

C’est interessant car en faisant cela on enlève radicalement le problème puisqu’on supprime les .svn de chaque répertoire. Cependant, ce n’est pas forcément la meilleure solution car vous ne pourrez plus interagir avec votre serveur SVN, plus de « svn up » possible. Solution efficace donc, mais pas très pratique.

Faire un fichier .htaccess qui va bloqué l’accés aux .svn

L’autre solution est donc de mettre en place un fichier .htaccess à la racine de votre projet avec les lignes suivantes : 

Cette solution vous permet de garder les avantages du svn mais empêche l’accés au .svn. J’utilise personnellement cette 2ème solution.

Conclusion

Juste faites le ! C’est toujours mieux de prévenir que de guérir en sécurité.