Informatique, logiciels libres…

Depuis quelques temps, j’avais sur mon hébergement 2 blogs, celui-ci, et mon blog de radioamateur. Je souhaite, dans un avenir proche, migrer également sur mon hébergement perso un blog actuellement hébergé chez WordPress.com. La solution de facilité consistait à héberger une troisième installation de WordPress. Cette solution présente un grand nombre d’inconvénients, parmi elles, la mobilisation inutile d’espace disque (avec des fichiers dupliqués pour chaque installation), mais surtout, elle rend fastidieuse le maintient à jour des installations de WordPress, car à chaque mise à jour, il faut faire les mises à jour unes à unes (même problématique pour les plugins). Il va sans dire que déjà avec 2 blogs, j’avais régulièrement au moins l’un d’entre eux qui avait une ou plusieurs versions de retard, avec potentiellement donc une exposition aux failles de sécurité (bien que ceci devrait s’améliorer avec WordPress 3.7, puisque désormais les mises à jour vers les versions mineures se feront de façon automatique sans intervention de l’administrateur). Bref, hors de question pour moi de garder ce système en l’état avec un blog de plus.

A savoir qu’avec le multisite, certains comportements sont modifiés dans WordPress. Lorsque l’on est dans les tableaux de bords des blogs, il n’est plus possible par exemple d’installer des plugins. L’installation doit en effet impérativement se faire via l’interface d’administration du réseau, ensuite, chaque blog active ou non les différents plugins installés en fonction des besoins.

Logo WordPress

Je me suis donc penché sur l’installation de WordPress en réseau, qui permet de gérer plusieurs blogs avec une seule installation du moteur WordPress. 2 solutions sont possibles, une installation par sous-répertoire (chaque blog est accessible par un sous-répertoire – de type http://monsite.com/nom-blog) ou une installation par sous-domaine (de type http://nom-blog.monsite.com). Pour ma part, j’avais une difficulté supplémentaire, car je souhaitait héberger plusieurs domaines avec la même installation de WP (par exemple avoir monsite1.com et monsite2.com, mais aussi blog.monsite1.com qui soient 3 sites différents gérés par la même installation de WordPress). Ce cas de figure n’est pas geré nativement par WordPress, il existe heureusement un plugin qui permet de faire ceci (Mu Domain Mapping). Je ne vais pas détailler ici la procédure, je me suis basé sur celle proposée par ce blog, assez complète.

Cependant, voici les grandes étapes pour résumer (j’ai du relire plusieurs fois la procédure sur le site lié plus haut pour qu’elle soit claire dans ma tête) :

1. Faire une installation classique de WordPress. A priori, il faut impérativement qu’elle soit à la racine du domaine pour que cela fonctionne.
2. Editer wp-config.php pour activer le multi-site
3. Installer le réseau WordPress via l’interface d’administration du site principal. Il faut bien choisir l’installation en sous-répertoires pour le multi-domaines avec le plugin Mu Domain Mapping (ça m’a paru étrange au début, mais en tout cas ça fonctionne).
4. Installer Mu Domain Mapping
5. Créer les différents blogs et configurer le domain mapping.

Importations de blogs existants

Ma seconde problématique était l’importation de blogs existants, de façon transparente (c’est à dire que leur noms de domaine ne changeaient pas…). WordPress sait importer les articles (et les médias liés), de façon automatique, mais à condition que le nouveau nom de domaine soit différent de l’ancien… En effet, pour importer les médias, WordPress recherche dans les articles les liens vers ceux-ci, puis les télécharge de l’ancienne adresse vers la nouvelle. Pour ma part, je souhaitais que les adresses restent les mêmes…

Après plusieurs essais, j’ai procédé comme suit :

1. Mettre une adresse « temporaire » à l’ancien blog (par exemple passer de blog.vermot.net à blog-old.vermot.net) :
   1. Mettre le nouveau domaine dans les réglages de WordPress (Reglages –> Général –> Adresse web de WordPress (URL) et  Adresse web du site (URL)).
   2. Ici vous allez avoir un problème car les adresses vers les médias (images notamment) sont inscrites « en dur » dans les billets. Ils continuent donc de pointer vers l’ancienne adresse (blog.vermot.net). Ici, vous pouvez intervenir directement dans la base de données, pour mettre à jour l’ensemble des informations de la table wp_posts (la fonction REPLACE est votre amie).
   3. A ce stade, vous avez normalement un blog fonctionnel, à une nouvelle adresse temporaire. Vérifiez que tout fonctionne, puis exporter les posts via la fonction d’Export de WordPress (Outils –> Exporter)
2. Créer le blog dans le réseau, avec l’ancienne adresse (blog.vermot.net). Il faut configurer intégralement les adresses du blog, sans quoi,  à l’importation, les mauvaises adresses seront utilisées et dés que vous mettrez la bonne adresse dans la config, plus rien ne fonctionnera au niveau des images.
   1. Créez le blog via l’administration principale
   2. Configurez le site : dans la page du site, indiquez
      • Dans l’onglet info, le domaine (http://blog.vermot.net)
      • Toujours dans l’onglet info, le chemin est vide (ou /)
      

      Configuration du multisite

      • Dans l’onglet reglages, vérifiez que les informations concordent (normalement elles sont mises à jour automatiquement avec les changements dans l’ongelt info).
      • Enfin, donnez les bonnes informations au plugin Mu Domain Mapping
      

      Configuration de Mu Domain Mapping

   3. Enfin, connectez vous sur le nouveau site (blog.vermot.net), puis importez via la fonction d’import de WordPress (Outils –> Importer). Si tout se passe bien, les images de l’ancien blog seront importées dans le nouveau.
   4. Il ne vous reste plus qu’à réinstaller puis réactiver les différents plugin qui étaient présents sur votre ancien site.

Voila, j’espère que ce billet pourra permettre à ceux qui sont confrontés aux mêmes problèmes que moi d’avancer un peu plus rapidement que je ne l’ai fait.

Autre astuce : comme je l’ai dit plus haut, il faut que WordPress soit installé à la racine du domaine (vermot.net dans mon cas). Hors, je voulais conserver sur vermot.net une page d’accueil en HTML. Chez la plupart des hébergeurs, si un fichier index.php et un fichier index.html sont présents dans le répertoire d’accueil, alors l’un ou l’autre sera servi en priorité (souvent le .html). Cette configuration est normalement éditable, mais certaines hébergeurs (notamment sur des serveurs mutualisés) ne permettent pas la modification. Dans mon cas, si je laissait le fichier index.html, plus rien ne fonctionnait, car tous les domaines affichaient alors ce fichier (index.html prioritaire sur index.php de WordPress). Par ailleurs, sur vermot.net, si je supprimais ce fichier, j’avais alors un blog vierge qui s’affichait. J’ai donc renommé mon fichier index.html en index.welcome, ainsi, c’est bien l’index.php qui est chargé par défaut. J’ai installé et activé sur le WordPress qui s’affichait sur vermot.net le plugin Redirection, et je fait tout simplement, grâce à ce plugin, une redirection de toutes les requettes vers vermot.net vers le fichier index.welcome. Ainsi, les autres domaines affichent bien le WordPress, et vermot.net affiche ma page HTML ! Le tour est joué !

Les sauvegardes sont des choses que trop peu de personne mettent en place… et pour cause, c’est souvent compliqué, et trouver le soft qui convienne bien est souvent une longue quête. Ensuite, il faut configurer des logiciels, et obtenir exactement ce que l’on veux est souvent une gageure…

Pour ma part, j’avais besoin de sauvegardes pour différentes choses :

• mes sauvegardes perso (de la photo numérique et des données diverses, au total plusieurs dizaines de Go), je souhaite les faire sur mon NAS et aussi sur un support distant dans le cloud afin de me prémunir du vol notamment
• des sauvegardes des données bureautiques de mes parents, pour ne pas les embêter avec des supports amovibles, la sauvegarde doit se faire à distance (quelques dizaines de Mo)
• des sauvegardes de photo numériques sur disque dur externe pour des proches, en local

J’ai testé plusieurs solutions, Cobian Backup, Duplicati…

Cobian Backup fonctionne pas mal, je l’ai utilisé sur le PC de ma maman pour des sauvegardes sur une deuxième machine du foyer, via le réseau. Sauvegarde contraignante car il fallait que cette seconde machine soit allumée heure fixe pour que le sauvegarde se fasse… la sauvegarde devait donc passer à l’as assez souvent. Puis, cette seconde machine  à fini par être supprimée, exit la sauvegarde sur le réseau local donc. Comme j’ai un NAS connecté sur net via mon Raspberry Pi chez moi, je souhaitais donc transformer cette sauvegarde réseau local en sauvegarde à distance sur mon NAS via l’Internet. Je ne voulais pas que les données transitent en clair, exit donc cette solution qui ne sais faire que via FTP (non chiffré) ou via le système de fichier. Par ailleurs, Cobian Backup ne dispose d’aucun moyen de restauration simple, et selon le mode de sauvegarde, il ne conserve pas forcément arborescence… bonjour le boulot en cas de restauration…

J’ai testé sur ma machine Duplicati, solution qui paraissait complète, mais la aussi, pas assez paramétrable à mon gout… un miroir me suffit et il ne sais pas le faire à priori… il fait des archives ZIP avec les fichiers : ça consomme du temps et de la puissance pour rien, et en cas de corruption d’une archive c’est toutes les données contenues dans l’archive (100 Mo) qui sont perdues…

Enfin, il est difficile d’utiliser ces solutions dans le cadre de sauvegardes « à la demande » : dans tous les cas, il faut plusieurs cliques pour lancer la sauvegarde… je veux quelque chose qui fonctionne en un seul clic : on branche le disque externe, on double clique sur une icone et ça sauvegarde sans poser de questions !).

Bref, je trouve ces solutions trop complexes, et elles consomment toutes je trouve beaucoup trop de RAM pour leur « agent ».

J’ai donc remis le nez dans les solutions existantes, et je me suis arrêté sur… rsync ! Simple à configurer (on indique le répertoire source, la destination, et les éventuelles quelques options que l’on souhaite), il sait faire de la sauvegarde distante et via un canal chiffré sur n’importe quel serveur SSH, il ne consomme absolument aucune RAM en dehors des phases de sauvegarde puisqu’il n’est pas lancé. Enfin, on peut soit faire de la sauvegarde automatique (via les fonctions de tâche planifiées : planificateur de tâches sous Windows, cron sous Linux like), soit de la sauvegarde manuelle (double-clique sur une icone qui lance le script).

Chez moi, ma machine est sauvegardée sur mon NAS avec rsync, puis chaque nuit, mon serveur Raspberry Pi récupère ces data sur le NAS pour les envoyer en ligne sur mon compte Hubic, toujours avec rsync. Ça fonctionne bien, même si évidement la première sauvegarde prend du temps (plusieurs jours, on envoie pas comme ça des dizaines de Go sur une ligne ADSL…).

Sous Windows, j’ai recours à cwRsync.

J’ai récemment déménagé à 800 km de ma famille, et avant mon départ, j’ai installé sur leurs machines UltraVNC pour me permettre de les dépanner (j’ai également découvert Ultra VNC Simple Clic, une version du serveur qui se connecte sur le client lorsque l’on clique dessus. L’avantage, c’est qu’il n’y a aucune config à faire côté client, pas de redirection de port dans les box notamment. L’exécutable UVNC SC contient les informations qui permettent de joindre ma machine sur laquelle s’exécute le client VNC ne mode écoute. C’est de mon côté que les redirections de ports sont paramétrées. Il suffit que je donne le lien vers mon exécutable configuré, exécutable hébergé sur mon site Web, et en un clic et aucune config du côté serveur, je peux prendre la main sur la machine distante, magique et pratique pour prendre la main sur une nouvelle machine par exemple !).

UltraVNC

Bref, sur au moins 2 machines, la prise à distance (que ça soit via VNC Server ou via VNC SC) était quasi inutilisable car l’image de la machine distante ne se rafraîchissait pas de mon côté (j’était obligé de forcer le rafraîchissement via la fonction idoine de VNC Viewer, et même via ce biais, ça ne se rafraîchissait pas rapidement). Le bug est apparu sur Windows XP et Windows 7, j’imagine donc que c’est indépendant des versions de Windows.

Le problème vient en fait du driver de capture vidéo de VNC qui gère mal l’acquisition sur des affichages paramétrés en 24 ou 32 bits. La solution est donc de modifier le paramétrage de l’affichage de la machine distante en la diminuant sur 16 bits. A partir de la, tout est fluide chez moi.