C’est simple, en voici une liste :

Mon site web utilise WordPress comme « moteur » pour construire un site efficace et facile à tenir à jour. Parmi ses nombreux atouts, WordPress s’appuie sur des « thèmes » qui permettent la mise en forme du contenu (c’est ce qui distingue visuellement n’importe quel site WP de tous les autres). Cette aptitude appréciable a mené à la création d’une communauté de développeurs de thèmes. Certains sont gratuits, d’autres payants.

Le principal problème est que les thèmes sont – comme tout logiciel – susceptibles de bugs et de failles de sécurité. J’ai donc récemment remarqué que le thème que j’utilisais (précédemment) était un poil obsolète (deux ans sans mise à jour) et contenait des failles de sécurité connues qui le laissait exposé à des risques que je n’étais pas prêt à prendre.

Retour d’Expérience : Ne jamais utiliser de logiciel qui n’est pas activement maintenu par son auteur (y compris un thème WordPress).

Application : J’ai renoncé à utiliser le thème gratuit (mais risqué) sur lequel je m’appuyais jusque là. Je me tourne maintenant vers les thèmes « officiels » de WordPress.org. Et j’apprends à les configurer au mieux. D’où les changements que vous pouvez actuellement observer ici.

J’ai donc décidé de créer une sorte de portfolio en ligne pour ne présenter qu’un petit nombre d’images – mais choisies avec soin pour ne garder que celles que je préfère. Elles sont ainsi beaucoup plus facilement accessibles.

Mais c’est également l’occasion pour moi de partager les intentions derrière certaines images. Je ne déclenche (pas que) par hasard. J’ai des envies, des projets en tête. Cela donne des portfolios rassemblés par une certaine unité de ton qui m’attire. Ces portfolios choisis sont donc maintenant accessibles sur :

Wild focus (photo.roumazeilles.net)

Les mises à jour sont plus rares, mais vous y trouverez ma personnalité photographique davantage à découvert.

Je possède un nom de domaine (Roumazeilles.net) mais depuis ma migration vers une FreeBox, il semble plus comfortable d’émettre mes mails via le serveur SMTP de Free. Sauf que, pour se protéger du SPAM, la plupart des opérateurs de courrier électronique vérifient l’origine du mail pour s’assurer qu’il arrive bien d’une origine autorisée (ce qui permet de distinguer beaucoup de SPAM et de mails de phishing).

SPF record – Tentative #1

L’idée de base (la plus évidente) consistait à créer un SPF record de la forme suivante :

…qui ressemble à la valeur par défaut recommandée par OVH (mon hébergeur et le gestionnaire de mon DNS).

Mais cela pose à vrai problème : Free n’a rien déclaré ni pour free.fr, ni pour smtp.free.fr, ce qui mène à une erreur d’interprétation du record SPF par la plupart des opérateurs de courrier électronique. Un SPF record invalide garantit presque que le mail ne sera pas diffusé correctement.

SPF record – Tentative #2

Comme les serveurs de mail de Free (et ils sont nombreux) sont de la forme :

Il est possible de passer plutôt par une déclaration d’adresse IP. C’est moins élégant, mais on peut faire.

De fait, la déclaration s’allonge singulièrement. Au point que le record devient invalide parce que comportant trop d’entrées. Il faut donc sérieusement optimiser.

SPF record final

La solution a finalement été de créer un SPF record taillé sur mesure.

Il donne une tranche d’adresses IPv4 pour les serveurs STMP de Free, et une autre tranche de 16 adresses IPv6 pour les mêmes serveurs. Compact et efficace.

Conclusion

Le principal inconvénient (mais il n’y a guère de contournement tant que Free n’aura pas fait son travail pour décrire correctement son propre SPF record dans son DNS) est que les adresses de Free sont « en dur ». Au moindre changement chez eux, je serai pris par surprise et je risque de perdre quelques mails.

Au delà, je recommande l’excellent site de test de courriers électroniques mail-tester.com qui permet de vérifier quasi-instantanément (c’est plaisant pour des modifs de DNS) les essais de configuration et qui donne un excellent rapport de test, très lisible.

Sources d’information

Merci à ces sites/auteurs qui m’ont aidé à m’y retrouver :

• Nicolass sur ForumNews
• Julien Falconnet

Et merci à Vincent Rubiolo pour avoir détecté l’erreur de copier-coller dans la version originale de l’article.

Mon expérience récente m’a amené à trouver un peu d’information utile que je veux donc partager ici. Des checklists pour trouver l’origine et réparer le site WordPress concerné. Bonne lecture !

• WordPress erreur 500 (par Kyodev, qui m’a été très utile sur les forums OVH)
• How to clean a WordPress Hack (par Sucuri, en anglais)
• How ot fix the 500 internal server error on your WordPress website (par Lyn Wildwood, en anglais)
• Damm you WordPress 500 Internal Server Error (en anglais)

• Worried about WordPress and GDPR? Start Here
• GDPR: What Does the New Data Regulation Mean for Your Website, Business and Data?
• How to make a WordPress website compliant to GDPR
• Automattic and the General Data Protection Regulation (GDPR)
• GDPR Compliance and WordPress Forms: Everything You Need to Know

Bonne lecture !

A noter : je ne suis pas un avocat ou un juriste, mais tout cela résulte de mes lectures et de ma compréhension du sujet.

Déploiement

Cookies

Première étape (normalement cela devrait être fait depuis longtemps puisque c’est antérieur) : ajouter le message d’information aux nouveaux visiteurs pour les prévenir de la présence de cookies.

J’ai utilisé un plug-in tout simple (il y en a d’autres, bien sûr) : Cookie Notice par dFactory.

Avantages: il génère un message en français (et en anglais), il a été testé sur plus de 500.000 sites avant le mien, il s’installe en moins d’une minute.

Formulaire de contact

Pour un bon nombre de raisons, vous avez besoin d’avoir un formulaire de contact qui permette de transmettre des demandes diverses (dont les demandes liées à la RGPD). Je recommande d’utiliser un éditeur de formulaires très simple (et gratuit) comme Ninja Forms.

En deux minutes, il est possible d’avoir un formulaire de contact. Ne pas oublier d’ajouter la case à cocher  « En utilisant ce formulaire, vous acceptez que nous stockions vos données sur ce site web » (cela reviendra sur chaque formulaire).

Ensuite, il suffit de créer une page « Contact » dans WordPress. Il faudra y intégrer le code spécifique pour afficher le formulaire de contact créé par Ninja Forms avec le shortcode suivant :

Seule contrainte : plusieurs messages sont prévus en anglais, il faudra les traduire au mieux. Mais ce n’est pas trop compliqué.

Petite aide pour RGPD : les formulaires Ninja permettent aussi de préciser que l’on ne souhaite pas stocker les informations, ce qui permet de ne pas trop se préoccuper de cet aspect pour la plupart des formulaires les plus simples.

Mais à l’opposé, il faut faire attention à bien valider l’envoi du message de confirmation à l’auteur du commentaire (d’autant que l’envoi de ce message est signalé dans la réponse par défaut à la suite du formulaire).

En complément, si vous avez un système de commentaires sur votre site WordPress, je recommande d’installer le plugin WP GDPR Compliance par Van Ons. Bonus : il fait des recommandations (en anglais) sur divers aspects liés à la RGPD.

Délégué à la protection des données

Désigner une personne (et son adresse email) qui sera l’interface interne pour tous les sujets de protection des données. Ce n’est pas toujours obligatoire (surtout pour les petits sites), mais il est recommandé d’avoir un nom et un contact qui permettent aux visiteurs de savoir à qui s’adresser, surtout si le site n’est pas simplement personnel (dans ce cas, le délégué est évident, c’est vous).

Prévoir que cette personne soit joignable par le formulaire de contact global ou par un formulaire spécifique.

Charte de respect de la vie privée

Avant tout, vous devez vous préoccuper de comment présenter clairement vos intentions en matière de respect de la vie privée de vos visiteurs et de respect de la loi. Pour cela, il vous faut une page qui dit tout.

Tâchez de la rédiger à peu près bien du premier coup, parce que vous devrez informer vos utilisateurs à chaque mise à jour…

C’est une page WordPress, plutôt qu’un article (elle doit rester très accessible même après plusieurs années).

Je vous recommande de suivre à peu près les thèmes de la Loi RGPD :

• L’existence (ou non) d’un Délégué à la Protection des données, chargé de piloter le dispositif de protection des données
• La définition des processus de collecte, de traitement, de stockage, de transfert et de suppression des données
• La création d’un processus de notification des violations de données
• Le consentement explicite du client lors de la collecte de données
• Le droit d’accès et de suppression des données personnelles

Accès aux données personnelles

La loi vous impose de donner accès aux données personnelles d’un utilisateur telles qu’elles sont stockées sur le site. C’est faisable relativement simplement à l’aide d’un plugin (GDPR compliance par Scribit) et d’une page dans laquelle vous allez inscrire le seul shortcode :

[gdpruserdata]

Evidemment, il est facile d’ajouter des détails en se référant à la documentation du plugin pour être plus complet ou plus précis.

Il suffira de diriger les demandeurs sur cette page pour que s’affiche l’ensemble de leurs données personnelles. Comme ce n’est guère agréable à lire, je recommande de garder cela sur une page « masquée » (inutile d’apporter plus de confusion aux utilisateurs mais il faut pouvoir les diriger là-dessus sur simple demande).

Message d’annonce

Peut-être pas le plus compliqué, mais j’ai finalement ajouté un petit message sur le site lui-même pour annoncer le déploiement et la mise à disposition (c’est toujours mieux d’expliquer à ses visiteurs – surtout les habitués).

Là où tout est documenté quand vous avez accès à un serveur dédié (sur lequel vous pouvez tout faire), il reste beaucoup de limitations sur un serveur mutualisé. Cela allait-il fonctionner ? La réponse est oui, mais voici comment je m’y suis pris (et certaines solutions adoptées ici « manquent d’élégance »).

Installation

L’installation est complètement transparente (téléchargement du package sur le site NextCloud.org, installation par copie FTP dans un répertoire de mon serveur web (cela cohabite bien dans un sous-répertoire), lancement de la procédure de configuration automatique (avec la création du premier utilisateur admin).

Après cela, j’ai dû résoudre quelques problèmes. Pas invraisemblables, certains sont même parfaitement documents, d’autres ont été plus ennuyeux.

Résolution des problèmes rencontrés

A noter : un certain nombre de sujets ont été corrigés avec l’aide du site Open-Freak qui est très clair sur le sujet.

Erreurs de headers HTML

Les premiers sujets sont clairement documentés en se rendant sur la page d’administration : en haut de la page apparaissent les messages d’erreur en orange/rouge. Ils sont assez explicites, mais il faut savoir où aller ensuite.

Rendez-vous dans le fichier .htaccess à la racine du répertoire contenant Nextcloud et repérez le pavé qui mentionne des headers décrits dans les messages d’erreur (ils sont tous bien groupés).

Modifiez chaque ligne commençant par Header set en Header always set, et ajoutez la ligne suivante au bloc en question :

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

Warning sur la gestion du cache

Vient ensuite un message de warning sur la gestion du cache (uniquement une quesiton de performance sans grande importance pour un tout petit cloud comme le mien). Il faut se rendre dans le fichier config/config.php (fichier dans le répertoire config).

Comme indiqué par le message de warning, on peut rajouter la ligne.

'memcache.local' => '\\OC\\Memcache\\ArrayCache',

Je l’ai mise à la fin (mais avant la toute dernière ligne qui ferme l’array.

Difficultés d’accés par le web

Dans le même fichier config/config.php, il y a une modification supplémentaire à appliquer pour tenir compte des habitudes courantes d’accès à un site web. Selon les cas, les utilisateurs ajoutent ou pas les www. devant une adresse web (indépendamment de ce que vous direz).

Pour éviter toute confusion et quelle que soit l’adresse que vous avez indiquée pour l’accès web de votre cloud, assurez-vous que l’accès est possible avec ou sans le www.  en modifiant l’entrée trusted_domains du fichier config/config.php :

'trusted_domains' =>
array (
0 => 'mondomaine.fr',
1 => 'www.mondomaine.fr',
2 => 'next.mondomaine.fr',
),

Dans mon cas, vous pouvez constater que j’ai prévu l’accès avec ou sans le www.  mais aussi un raccourci pratique et assez habituel. (bien sûr, vous remplacerez mondomaine.fr par votre propre nom de domaine).

Login impossible pour les utilisateurs non-administrateurs

J’ai ensuite rencontré un problème beaucoup plus désagréable. Je pouvais me connecter avec le compte d’administrateur créé à l’installation, mais aucun autre utilisateur, créé ultérieurement depuis l’interface d’administration, ne semblait pouvoir le faire. D’après ce que j’ai lu ici ou là sur Internet (principalement les échanges sur le forum OwnCloud), il semble qu’un moyen de contournement (pas joli joli, il faut dire) consiste à créer manuellement les répertoires du nom de chaque utilisateur dans le répertoire data de l’installation NextCloud. Certainement un problème de droits d’accès, mais je n’ai pas su le résoudre encore (peut-être une correction ici-même quand j’aurai trouvé).

Mise à jour : il me faut être plus précis. La solution véritable ne consistait évidemment pas à créer manuellement des répertoires, mais à bien gérer les droits d’accès. En fait, le répertoire data de l’installation NextCloud n’avait pas les bons droits d’accès (comme tous les répertoires, il aurait dû avoir un code chmod de 705). Cela a été assez facile à corriger avec FileZilla. Il a seulement fallu re-créer tous les utilisateurs (sauf l’administrateur initial, bien sûr).

Ce point-là était le plus complexe pour moi parce qu’il bloquait tous les essais par un autre utilisateur quelque soit l’outil employé (accès par le web, par WebDav, par le client Windows).

Par sécurité, j’ai aussi complété le fichier config/config.php (fichier dans le répertoire config) avec quelques mentions utiles pour le futur :

'maintenance' => false,
'singleuser' => false,

Autres difficultés de login

Enfin, je l’avoue, à force de faire des essais de connexion, je me suis retrouvé incapable de me connecter (tout court). C’est un effet de la portection contre les attaques de force brute qui génèrent des erreurs à répétition (comme je l’ai fait dans mes essais).

La méthode pour s’en sortir à consister à venir me connecter sur un autre ordinateur et à passer dans le menu Administration > Sécurité > Brute-Force Whitelist et à y ajouter l’adresse IP de mon ordinateur (sous la forme 100.100.100.100/32). Cela protège contre cette détection (mais cela autorise les attaques par ce biais : attention à ne pas faire d’erreur de sécurité par ce biais).

Conclusion (temporaire ?)

L’installation de NextCloud est prévue dans certaines configurations de serveurs dédiés de OVH. Dans ce cas, pas de gros problème, je suppose. Mais pour une toute petite application (moins de 10 utilisateurs, pas très actifs), un serveur mutualisé est largement suffisant. Dans ce cas, l’installation semble un peu plus compliquée mais il n’y a pas de raison d’abandonner. Les problèmes de configuration sont minimaux et certains d’entre eux sont à la fois bien documentés par NextCloud et identiques aux sujets de configuration de tout serveur cloud de type NextCloud.

J’avais bien remarqué le paramètre de configuration trusted_domains ; j’avais aussi noté que celui-ci était lié à des échecs d’accès sur le cloud depuis un lieu différent de mon ordinateur perso. Mais je ne comprenais pas bien.

De fait, grâce à un article très clair (mais en anglais) de Lukas Reschke, A tale about trusted_domains, j’ai rapidement compris les (petites) erreurs que je faisais.

L’installation par défaut de ownCloud m’avait permis de rajouter www.mondomaine.com dans la liste des trusted domains (la liste des domaines qui sont utilisés pour publier l’information de ce cloud). Je pensais que j’avais du mal à me connecter depuis ailleurs que mondomaine.com. En fait, il fallait que la liste des trusted_domains contienne simultanément www.mondomaine.com et mondomaine.com.

C’est assez bête mais je n’utilisais pas la même adresse selon où et quand je me connectais et j’en étais venu à croire que c’était le lieu qui comptait.

Donc, j’ai remplacé

'trusted_domains' =>
array (
0 => 'www.mondomaine.com',
),

par

'trusted_domains' =>
array (
0 => 'www.mondomaine.com',
1 => 'mondomaine.com',
),

Problème résolu !

L’intérêt de ce paramètre de connexion est d’éviter un risque de sécurité (bien expliqué dans l’article mentionné plus haut) et de permettre aussi d’avoir un accès à une adresse différente selon que les utilisateurs sont à l’intérieur d’un réseau d’entreprise (accès par internalcloud.local) ou à l’extérieur (accès par mondomaine.com). Cela peut mener à créer les paramètres de configuration comme :

'trusted_domains' =>
array (
0 => 'www.mondomaine.com',
1 => 'mondomaine.com',
2 => 'internalcloud.local',
),

Allez ! un problème de réglé.

ownCloud reste un excellent produit pour remplacer DropBox par un outil plus personnalisé et plus sécurisé (au moins, ce n’est pas hébergé n’importe où comme DropBox).

Depuis des années, j’utilisait Google authenticator pour iOS. Je me doutais que ce serait assez douloureux si mon téléphone s’arrêtait de fonctionner (ou si je devais le remplacer). La seule raison qui rendait cela acceptable était que j’avais installé Google authenticator simultanément sur deux téléphones (Il se trouve que je fais partie de ces rares olibrius qui ont un téléphone pro et un autre perso – ne me demandez pas pourquoi…)

A l’occasion d’un changement de smartphone, j’ai décidé de tester Authy comme remplaçant de Google. Et j’aurais dû le faire plus tôt ! Je ne reviendrai en arrière pour rien au monde.

Authy , c’est :

• Une interface utilisateur facile et agréable
• Des comptes partagés entre plusieurs téléphones (et un moyen simple de basculer ainsi d’un vieux téléphone à un nouveau)
• Tout ce qui est nécessaire pour une A2F (compatible avec la norme TOTP)

En trente/quarante minutes, j’ai recréé tous les facteurs pour tous mes comptes (par exemple, Google, Outlook, Evernote, Dropbox, ou même Ubisoft). Et cela était nécessaire simplement parce que Google ne me permettait pas de transférer cette information depuis l’ancien téléphone (où elle reste perdue même si j’avais bien les deux téléphones parfaitement opérationnel sous mes yeux). Mais, il ne m’a fallu que trois/quatre minutes pour étendre tout ça à un deuxième téléphone et une sauvegarde sur le cloud protégée par un mot de passe fort. La prochaine fois que je dois changer de téléphone, il ne me faudra que quelques minutes pour retransférer tout indépendamment du nombre de site web concernés. Merci Authy.

Je me sens mieux protégé. Qu’est-ce qui me serait arrivé si j’avais perdu mon téléphone avec tous ces codes indispensables coincés dans Google Authenticator ? (plsu de risque de perdre soudainement accès à tous ces sites web qui me sont indispensables, à cause d’une seule défaillance).

Je me sens libéré pour étendre cette pratique à autant de sites web que je peux le souhaiter, grâce à la facilité d’utilisation.

De plus, Authy est disponible pour ces Systèmes d’Exploitation:

• iOS
• Android
• Windows
• Google Chrome

Allez y! Installez Authy !

J’utilise une connexion en fibre optique (elle ne limite pas, de loin), et je synchronise depuis un Synology DS413j qui n’a pas une grosse CPU (un ARM mono-cœur). C’est donc sans une petite sous-estimation du maximum que l’on peut atteindre. Et pourtant, je suis bien aux alentours de 60 Go par jour depuis plusieurs jours. A voir sur un total de quelques centaines de giga-octets, pour bien juger :

Complément :

Vous noterez que la vitesse de transfert a fluctué (j’utilisais le serveur de manière réelle pendant la synchronisation, y compris en ajoutant et retirant des fichiers en nombre significatif). Le plus intéressant est qu’un paramètre a semblé vouloir influencer fortement sur le débit de synchronisation : le nombre de threads/fils ou de fichiers synchronisés simultanément (pas étonnant, bien sûr). La valeur par défaut de 3 n’est restée que quelques heures avant que je ne monte à 6. Le débit s’est rapidement établi aux alentours de 60 Go/jour. Quand je suis monté à 9 fichiers simultanés, le débit a grimpé à presque 90 Go/jour (un peu avant que la courbe jaune ne s’arrête), mais le passage à 12 fichiers simultanés n’a plus apporté de progrès perceptible (en dehors du graphe). A vous de choisir votre propre valeur (sans doute fonction de la puissance CPU du serveur Synology et de la bande passante disponible pour rejoindre ACD).

1. Sauvegardes
2. Synchronisation entre plusieurs machines (plusieurs PC et plusieurs iPhone)

CrashPlan fournissait bien la fonction de backup malgré un volume important de photo (plus de 2 To à ce jour), mais n’offrait que peu de possibilités en synchronisation. Il était donc temps de me consacrer à mieux définir le besoin et à trouver une vraie solution.

Besoin

Pour la sauvegarde, j’ai depuis longtemps quelques attentes complémentaires :

1. Au moins trois sauvegardes
2. Au moins deux technologies différentes (ne pas reposer uniquement sur des disques durs, par exemple)
3. Au moins un sites extérieur (pour se protéger contre les vols, les incendies, etc., off-site, cloud ou coffre-fort extérieur)

Pour la synchronisation, l’emploi de DropBox et d’Evernote (sur des petits volumes) m’a permis d’identifier mes besoins plus précisément :

1. Partages en temps réel de certains fichiers critiques mais mis à jour très quotidiennement (comme les notes d’Evernote, la base de données de mon gestionnaire de mots de passe, etc.)
2. Sécurisation et encryptage (je ne veux pas voir se promener ni mes mots de passe, ni mes données bancaires).

Solution

Il est clair que j’ai été influencé par plusieurs facteurs dans mon choix, et je vais essayer de les expliciter (votre solution ne sera peut-être pas la même que pour moi). Mais commençons par ce que je mets en place.

Un petit serveur de fichier (un Synology DS413j) à mon domicile. Il héberge 4 disques durs de 3 To (au départ, des Western Digital RED) en mode SHR/RAID 5 pour une capacité totale de 6 To.

La capacité importante était dictée par le souhait d’héberger un serveur multimédia conséquent et des quantités de photos (nous avons aujourd’hui sensiblement plus 100 000 images sur ce serveur).

Le choix de RAID 5 s’est très tôt imposé à moi parce que c’est un optimum pour apporter de la redondance mais on perd beaucoup moins d’espace que dans les autres modes RAID souvent proposés (à deux disques seulement). La solution SHR de Synology est encore plus intéressante parce qu’elle tolère très bien des disques de taille différente (les deux plus petits disques déterminent la capacité maximale. Il faut donc éviter d’avoir un seul disque de 500 Go avec trois disques de 4 To ; ce serait du gaspillage) et elle accepte comme tous les RAID de remplacer un disque en panne par un nouveau (pendant la reconstitution du RAID/SHR, la protection n’existe plus mais cela n’est que temporaire – et vous pouvez continuer à travailler sur les fichiers pendant ce temps).

Le choix de Synology est encore plus justifié par un point rarement souligné quand on compare les serveurs RAID du marché : l’offre logiciel est particulièrement alléchante. DSM (l’OS de Synology) héberge des « packages » pour plein d’applications. Les compléments que je vais décrire plus bas arrivent tout prêts et sont ridiculement faciles à installer et configurer même par un amateur.

Ainsi, j’ai pu déployer une solution à plusieurs étages :

1. synchronisation entre PC (trois PC) et serveur Synology (via le Cloud Station Server)
2. synchronisation entre serveur Synology et Amazon Cloud Drive (via le Cloud Sync)

Cloud Station Server et Cloud Sync sont deux applications de Synology qui sont installées en à peu près 5-6 minutes (téléchargement compris) à partir du « Centre de Paquets » de Synology DSM.

Si l’on s’intéresse d’abord à la partie synchronisation entre PC (ou iPhone) et Synology, l’ouverture de Cloud Station Server dans la liste ci-dessus (dans l’interface de gestion de mon serveur DSM sur Synology DS413j) amène directement à un menu qui permet de télécharger l’application Windows (ou iPhone) à installer pour lancer les synchronisations entre PC et serveur cloud sur Synology.

Quelques clics et c’est fait. On ne peut faire plus simple. En quelques minutes à peine, la synchronisation du ou des PC est lancée. Elle a lieu en arrière-plan (ne perturbe pas le fonctionnement du PC) et la seule chose à remarquer est la modification de l’icone de chaque fichier qui signale s’il est sauvegardé sur le cloud (voir exemples ci-dessous) ou s’il est encore en attente de synchronisation (marque bleue).

A cette étape, les PC sont synchronisés entre eux, via le serveur de Synology. On peut considérer qu’il s’agit d’une sauvegarde parce que j’ai choisi de garder 32 versions successives de chaque modification de fichier et de ne pas laisser Synology effacer les fichiers (ils sont mis dans une corbeille à papier/fichiers). Donc, j’ai la fonctionnalité de Time Machine en plus d’un backup transparent.

Important : la synchronisation entre PC et Synology cloud server est très rapide et ne consomme pas beaucoup de ressources même sur un petit PC (contrairement à certains programmes de backup que je ne nommerait pas, comme Cobian Backup). C’est rassurant : les utilisateurs peuvent oublier la sauvegarde en arrière-plan qui ne les dérange pas, s’arrête si le PC s’endort, repart silencieusement quand il se réveille et ne ralentit pas le PC de manière observable.

De la même manière, les iPhone et iPad ont accès à la synchronisation (de certains fichiers, je ne veux pas les déborder) depuis n’importe où.

La seconde fonctionnalité est de répliquer ces informations sur un autre site (en l’occurrence, j’ai choisi de synchroniser avec Amazon Cloud Drive ou ACD parce que le coût de 70€/an me paraissait très raisonnable). J’ai bien compris que la vitesse de transfert serait limitée par mon serveur RAID (le DS413j est assez ancien, est une entrée de gamme avec un petit processeur ARM, mais il ne m’a pas coûté cher) plutôt que par ma bande passante (une fibre optique chez SFR) ou par Amazon (ça dépote chez tous les utilisateurs).

Synology Cloud Sync offre cette fonction en quelques clics. Il suffit de donner les coordonnées d’Amazon pour que Synology s’occupe de tout et que la mise en synchronisation commence après moins d’une minute (j’avais fait l’essai avec Google Drive, c’est tout aussi facile et tout aussi rapide – le débit est logiquement aussi élevé, ce qui est plus que rassurant ; j’avais envisagé de travailler avec hubic de OVH, mais les commentaires sur Internet et des discussions personnelles que j’ai eues semblent indiquer un produit qui n’offre pas la performance et la fiabilité que l’on peut souhaiter ici).

Observations

Seules remarques à faire après un peu d’utilisation :

• • Le DS413j a une petite CPU de chez ARM. La charge de CPU reste très élevée (~100%) en permanence pendant la phase de synchronisation.
  • La première synchronisation est longue (plusieurs jours ou plusieurs semaines selon le volume de données à synchroniser). Je recommande d’y aller par étapes et de ne pas tout synchroniser d’un coup.
  • Les synchronisations suivantes sont généralement presqu’instantanées.
  • Les fichiers modifiés récemment sont généralement les premiers mis en synchronisation.
  • J’ai utilisé Cloud Sync pour relier le serveur à Amazon, mais il existe aussi une solution qui permet de synchroniser de Synology à Synology : cloud Station Share Sync. Je n’ai pas essayé mais cela peut valoir la peine si vous avez deux sites (une résidence secondaire ? une entreprise avec deux bureaux ?) et deux serveurs Synology. Cela semble devoir être aussi facile.

• Pour la fiabilité du serveur RAID, il vaut mieux choisir des disques durs qui sont conçus pour une utilisation 24 heures sur 24 et 7 jours sur 7. Je mentionne ainsi les Western Digital RED (spécialement conçus pour les serveurs RAID) ou les Hitachi UltraStar (version 24/7 des DeskStar). Si vous pouvez éviter d’avoir 4 ou 5 disques identiques, vous éviterez de voir tous les disques tomber en panne quasi-simultanément. Voir les statistiques de BackBlaze sur la fiabilité des disques durs.
• Vous vous demandez peut-être encore où sont passées les « trois copies » auxquesles je faisais référence plus haut. Il y a :
  • Le fichier original sur un PC maître
  • Une copie manuelle sur un disque dur séparé (parfois deux ou trois disques)
  • Une synchro sur le serveur Synology
  • Une synchro sur Amazon Cloud Drive
• Comme le Synology DS413j n’est plus au catalogue, vous pouvez encore trouver le DS416j ou le DS418j.
• Sur le NAS Synology, j’ai refusé de laisser le répertoire synchronisé visible à Windows : un ransomware ne peut donc pas le voir, il faudrait passer par le soft de Synology. Ca me protège contre un ransomware qui essayerait d’encrypter toutes les données normalement visibles sur le réseau. (Je vois quand-même les données par l’interface web de DSM pour les contrôles).
• Si un ransomware veut m’encrypter les fichiers, ils risquent d’être synchronisés (et perdus). J’ai donc pris la peine de valider les versions, le versioning sur le serveur NAS de Synology (comme ça, je peux remonter le temps avec l’attaque et éviter de « payer la raçon »).

A partir d’aujourd’hui, Roumazeilles.net vous aide en ajoutant un accès complètement transparent aux deux adresses :

https://www.Roumazeilles.net/

http://www.Roumazeilles.net/

Pour la plupart, cela ne change rien. Pour ceux qui cherchent à préserver chaque brin de leur vie privée, cela peut aider (un peu).

Lecture complémentaire (traduction Google) : HTTPS Everywhere | Electronic Frontier Foundation

Pour les plus techniques de mes lecteurs, je signale que cela a été rendu possible (facile) par mon hébergeur (OVH) qui fournit gratuitement un certificat SSL que je n’ai eu qu’à activer sur mon interface d’administration.

Mais la situation est peut-être beaucoup moins rose que cela. Et beaucoup plus compliquée d’après Mike Hearn, un des concepteurs de Bitcoin.

A lire, un article (en anglais et assez technique mais clairement construit) intitulé « The resolution of the Bitcoin experiment« .

Recommandé.

Cette fois-ci, il s’agit d’un site pour partager la passion pour le froid, la glace, la neige et l’altitude de Marion Jonchères. Ici, il n’est question que de sport extrême, de sommets en haute altitude et de pôle nord ou pôle sud. Vous y trouverez des récits comme des photos spectaculaires.

Je vous recommande un détour par Ice-Altitude.com (et n’hésitez pas à aussi vous inscrire pour recevoir sa lettre d’information).

Si, il y a quelques années, ce prestataire faisait un travail assez convenable, les utilisateurs semblent en être de moins en moins satisfaits (apparition de pub, contraintes diverses pour l’administrateur, changements presqu’intempestifs d’interface d’administration qui se traduisent par la perte de certaines fonctionnalités, etc.) Marion fait partie de cette catégorie et m’a demandé de l’aider.

Il s’est donc agi de prendre un blog chez Overblog et de le passer sur WordPress (ici, sur un WordPress hébergé chez OVH, mais cela aurait aussi bien pu être avec wordpress.com).

L’opération n’est pas totalement transparente (elle prend du temps) mais je recommande chaleureusement l’article superbement écrit (hormis les fautes de frappe) par Sandra dans Le Coin des Blogueurs sur cuisine-addict.com. Très complet, bien détaillé, clair. Tout ce qu’il faut. Merci Sandra !

Honnêtement, il n’y a pas mieux : Migration OverBlog vers WordPress.

J’ai une connexion Internet Fibre chez Numéricable qui utilise obligatoirement une adresse IP dynamique (pas d’adresse IP fixe chez Numéricable qui sont un peu gentiment arriérés). Ce n’est pas bien grave sauf que j’ai un serveur RAID provenant de chez Synology (une DiskStation DS413j à 4 disques en mode redondant RAID-5) qui me procure quelques services que je souhaite partager avec Internet (quand je suis en déplacement avec un mobile ou un PC portable, j’aimerais accéder à mon serveur FTP, à mon serveur de mail).

J’ai donc décidé de m’organiser pour permettre de retrouver facilement le Synology DiskStation depuis un sous-domaine (par exemple mail.roumazeilles.net).

La solution que j’ai adoptée :

Adresse IP dynamique :

Comme mon adresse IP est dynamique, pas moyen de faire grand chose avant d’avoir résolu ce point. J’ai opté pour le service DDNS de Synology. Comme j’utilise DSM 5.0 (la version la plus récente du soft de Synology), il est accessible dans le panneau de configuration au menu « Accès extérieur ». Il suffit d’ajouter un DDNS en choisissant Synology comme prestataire et j’ai enregistré un nom qui me convient (disons ds). A partir de là, malgré les changements d’adresse IP, ma DiskStation reste accessible à ds.synology.me.

Sous-domaine du DNS :

Il faut ensuite faire pointer mail.roumazeilles.net vers ds.synology.me. Le sujet est un peu plus compliqué parce que j’ai déjà réservé le nom de domaine roumazeilles.net chez Gandi et qu’il pointe vers un serveur mutualisé chez OVH. C’est le serveur d’hébergement (loué chez OVH) qui comporte toute l’information relative à roumazeilles.net. J’ai donc du aller sur mon serveur et dans sa configuration DNS modifer (dans votre cas, il s’agira peut-être d’ajouter) un enregistrement de type CNAME.

mail 10800 IN CNAME ds.synology.me. (N’oubliez pas le point final dans votre entrée CNAME, ou elle ne fonctionnera pas !)
Comme j’ai de la chance, mon panneau de contrôle OVH me permet de ne pas me rater avec la syntaxe exacte, mais l’affaire est identique : je lui dit que le sous-domaine mail est décrit pas un enregistrement CNAME qui pointe directement sur ds.synology.me (un peu abscons mais pas très méchant).

Ensuite, il reste à attendre que l’information DNS « se propage » (quelques minutes à quelques heures, parfois 24-48h). Et un petit contrôle se fait avec ping mail.roumazeilles.net qui doit répondre correctement avec mon adresse IP chez Numéricable.

Comment un couple se débrouille avec les contraintes quotidiennes que constitue une intolérance au gluten pour l’un des deux.

Si le sujet vous intéresse, il ne reste plus qu’à aller vous promener sur www.200gluten.fr (« A deux sans gluten » ou « à 200 gluten »). Le site est encore expérimental, il va beaucoup évoluer dans les semaines à venir mais il est déjà visitable.

De fait, il n’y a pas grande différence pour le visiteur normal. J’ai seulement vérifié le bon fonctionnement de mon environnement de production du site web (vous vous en moquez sans doute complètement) et j’ai modifié les coordonnées géographiques du site (latitude et longitude) que vous ne voyez sans doute pas mais qui permettent à Google et autres services de me situer sur Google Maps (dès que cela sera pris en compte par Google, bien sûr) dans la ville de Courbevoie où je viens d’emménager.

Vous êtes curieux de savoir comment ? J’ai simplement ajouté (ou plutôt mis à jour le code HTML suivant dans les en-têtes de page :

La copie d’écran de Google Analytics :

Comme vous pouvez le voir, en fait, le million de visites n’a été franchi que parce que, la semaine dernière, il y a eu un pic de plus de 80,000 visites en une seule journée (j’oscillais entre 900,000 et 1,000,000 visites mais sans arriver à franchir cette limite symbolique). Cela s’accompagne de presque 1,5 millions de pages vues (un autre chiffre symbolique à atteindre).

Ce qui parait amusant est que cette pointe de charge (très bien gérée par le serveur OVH) est arrivée seulement quelques jours après les expérimentations dont je parlais pour optimiser la performance de Roumazeilles.net et de YLovePhoto.com. De fait, les actions qui ont aidé étaient très représentatives de ce qu’il faut pour avoir un site web qui aille au delà de la carte de visite web :

• Un petit serveur dédié (bien meilleur que les hébergements mutualisés qui ne coutent vraiment pas cher, mais sont limités en cas de pointe de trafic) ;
• WordPress en version récente (en l’occurrence la version 3.0.1) ;
• Le plugin W3 Total Cache pour optimiser le cache et la performance du site WordPress (mon analyse de W3 Total Cache) ;
• La limitation des opérations peu utiles par la recherche des sources de basse performance à l’aide des outils d’analyse de la vitesse du site web ;

Mais au delà des aspects techniques de l’affaire, je ne suis pas peu fier d’avoir franchi le million de visites.