Ca fait un bail que je suis resté silencieux à propos de mon installation Domoticz (voir ici)
Pour rappel mon Domoticz tourne sur un Raspberry Pi 3B équipé d’un adaptateur PiZiGate, et mes périphériques sont: IPX-800, divers Sonoff, et des bidules Zigbee.
Entre-temps j’ai acheté un petit SSD (32€) et un adaptateur USB2-SATA (7€). En effet je n’ai pas envie d’attendre que la carte micro-SD de 8GB me claque entre les mains en raison de sa lente et inévitable usure.
Le dernier Sonoff Basic R2 que j’ai acheté n’a pas voulu fonctionner avec ESPeasy. Du coup j’ai essayé Tasmota et je l’ai adopté.
Enfin nous avons commandé des stores, et j’ai demandé une livraison avec moteur classique commandé par fil (et non avec une télécommande propriétaire Somfy). En attendant la livraison et l’installation, j’ai déjà préparé la commande à distance.
Pour chacun il y aura un relais Wifi à 2 canaux avec relais inverseurs à contact sec, avec la ferme intention de les flasher avec Tasmota comme j’ai fait précédemment avec les derniers Sonoff. Et surprise, alors que la photo montrait clairement les petits trous dans le circuit imprimé pour y brancher un câble série, le modèle que j’ai reçu en fait défaut !
Déception ! Du coup je me suis intéressé à piloter Domoticz > IFTTT > eWelink > relais et j’y suis arrivé avec un certain succès. Sauf que… eWelink est payant si on veut l’interfacer, statut VIP 10$/an ; et IFTTT est devenu payant si on veut avoir plus que 3 scripts, statut Pro 2$/mois !
Tout ça pour avoir un relais qui s’actionne avec 5 secondes de retard, voire plus, et être à la merci d’une défaillance de l’accès internet, de IFTTT, et/ou de eWelink. Payer et devoir dépendre des autres, non merci ! C’est l’occasion de rappeler tout le mal que je pensais de l’application eWelink qui demande de se foutre (virtuellement) à poil devant son appareil.
Après d’intéressantes lectures sur internet, notamment de data sheets du PSF-B04 en chinois (identification du chip en montage surélevé), je sors mon fer à souder équipé de sa panne la plus fine, pour souder 4 fils dont deux sur des pattes de circuit de 1 mm de large. Ceci me donne accès à GND (zéro volt), Vcc (+3.3) et les classiques TX et RX. Et hop, ça y est Tasmota est flashé dans l’appareil !
Je déclare cet appareil comme un Sonoff 4CH Pro même s’il n’a que 2 sorties.
Au niveau du câblage qui est prévu pour le store électrique, le relais 1 amène le courant ou le coupe, et le relais 2 est utilisé comme inverseur pour activer un moteur ou l’autre. Il est donc impossible de commander à la fois la montée et la descente, et il ne faut pas dépendre d’une fonction “interlock” du relais.
A ce stade, on peut commander les relais au moyen de la télécommande RF433 qui est livrée avec (si on a choisi ce modèle bien sûr), ou bien avec les boutons sur l’appareil, ou bien à partir de la page Web Tasmota à l’adresse IP où il se trouve. C’est peu convivial et uniquement une solution de secours.
On va lui ouvrir l’horizon. Dans Domoticz, on déclare 2 switches on/off virtuels à partir de Setup > Hardware > Virtual Sensors, et pour ces 2 switches, on leur donne un nom à chacun et la commande HTTP qui actionne le switch (ou MQTT pour ceux qui l’ont implémenté).
[Edit: avec MQTT configuré sur Tasmota, les On et Off Actions sont superflues]
On peut maintenant créer une ou plusieurs scènes où on va actionner ces switches pour en faire ce que l’on veut.
J’ai commandé des boutons Zigbee (ici ou ici ou autre modèle ici)
et la petite notice en chinois bien sûr, ici la page qui montre comment l’ouvrir pour changer la pile
Appairage:
Ces boutons différencient le simple clic et le double-clic. Celui-ci supporte aussi le triple et quadruple-clic, tandis que d’autres modèles reconnaissent un appui long. Je vais utiliser le simple-clic pour actionner le store (en inversant le sens) et le double-clic pour un arrêt immédiat [edit 11/2023: fonctionnement modifié, voir à la fin de l’article] . J’ai essayé avec des scènes et des scripts Blockly sans y arriver. Finalement un script dzVents de quelques lignes fait le travail à merveille
return {
on = { devices = { 94 }}, -- idx of button
execute = function(dz, item )
dz.log("state of " .. item.name .. " is " .. item.state)
if item.state == "1 Click" then
dz.devices(73).toggleSwitch() -- idx of up/down switch
dz.devices(72).switchOn() -- idx of power switch
elseif item.state == "2 Click" then
dz.devices(72).switchOff() -- idx of power switch
end
end
}
Un mot d’explication:
Si le bouton idx=94 est activé, le script est exécuté. Si l’état est “1 Click” alors on inverse le switch2 (idx=73) pour monter/descendre et on allume le switch1 (idx=72) qui donne l’alimentation électrique. Lors de l’action “2 Click” (arrêt du store) le switch 1 est éteint.
En outre un timer de 17 secondes avait été mis sur le switch1, à régler quelques secondes de plus que l’ouverture ou la fermeture complète, ainsi on ne laisse jamais le store sous tension en permanence.
A remarquer que l’utilisation directe des boutons sur les relais, ou des télécommandes RF433 n’informent pas Domoticz de cette action. Une commande MQTT telle que ‘domoticz/in’ avec un payload ‘{ “idx” : 72, “nvalue” : 0}’ permet de changer l’état dans Domoticz sans que Domoticz n’envoie en écho (et possiblement en boucle infinie) un ordre d’extinction au relais.
Au niveau de Tasmota, avec les configurations MQTT et Domoticz complétées, plus aucun échange en http n’est encore nécessaire. La réactivité est bien meilleure et fiable dans les deux sens.
Edit 11/2023: j’ai décidé de changer le mode de fonctionnement des boutons Zigbee vers une solution plus simple où subsiste uniquement le simple-clic. Un appui: monter, un appui: stop, un appui: descendre.
Voici le script modifié:
-- salle a manger: bouton:94 ; on/off:72 ; up/down:73return { on = { devices = { 94 }}, -- id du bouton execute = function(dz, item) dz.log("state of " .. item.name .. " is " .. item.state) dz.log("state of idx72 is " .. dz.devices(72).state) dz.log("state of idx73 is " .. dz.devices(73).state) -- device 72 : id du switch virtuel "power" if (dz.devices(72).state == 'On' ) then dz.devices(72).switchOff() else dz.devices(73).toggleSwitch() -- changer de sens dz.devices(72).switchOn().afterSec(0.1) endend}
SSLLabs : Vérifiez si votre site SSL est bien conforme aux standards du protocole.
imirhil : permet aussi de tester SSL sur d’autres ports que 443
Wormly : Vérifiez si votre serveur SMTP est correctement configuré. Vérifiez si votre site SSL possède des certificats corrects et utilise les bonnes options TLS, et pas de SSL v2 v3, etc.
Testez la validité de votre DNS et DNSSEC via zonemaster.net
Comment StartSSL, une boîte israélienne fournissant des certificats SSL gratuits ou bon marché, a été rachetée incognito par des Chinois qui ont cru pouvoir faire n’importe quoi dans ce monde très strict des autorités de certification: article de Arstechnica.
DNSViz va analyser l’exactitude de votre zone DNS. Notamment détecter les anomalies DNSSec.
Chaque certificat émis laisse une trace. Retrouvez cela: crt.sh (depuis 2013 environ)
Dans cet article (en cours de rédaction) je vais essayer de tracer les grandes lignes qui permettent de comprendre les notions élémentaires pour faire fonctionner un site web, et ensuite un cas d’école avec OVH en hébergement mutualisé.
1. Le nom de domaine
Le nom de domaine doit être choisi avec l’extension souhaitée. Chaque extension (.COM, .BE, .FR …) est gérée par un registre (registry), et ce registre applique ses propres règles de fonctionnement, plus ou moins libérales, ainsi que sa tarification de gros. Par exemple, .EU n’est accessible qu’à des citoyens ou entités ayant un ancrage en Europe. Autre exemple, .BE va vouloir valider l’exactitude de votre adresse (avec itsme ou eID pour les citoyens belges)
Le nom de domaine ne peut pas être acquis directement chez le registre (registry), mais auprès d’un revendeur de noms de domaines (registrar). Citons en France: OVH, Netim, Gandi, etc. En Belgique: Combell, Register.be, Emakina, etc. Ces revendeurs ne se limitent pas à l’extension du pays où ils sont localisés.
Le nom de domaine choisi doit évidemment être libre, ou appartenir à quelqu’un avec qui vous avez convenu de vous le céder. Choisissez un nom de domaine sans accents. La seule ponctuation autorisée est le trait d’union “-“.
Vous paierez la redevance annuelle de votre nom de domaine auprès du revendeur.
Si vous achetez le nom de domaine pour quelqu’un d’autre, c’est son nom qui doit figurer comme titulaire/propriétaire.
Dans cet article, je cite quelques noms de sociétés et je ne suis rétribué par aucune. Le scénario le plus simple et de tout héberger auprès d’un unique partenaire. Citons: OVH (France), Infomaniak (Suisse), Microsoft365 (multinationale), Google (multinationale), etc.
2. Le système DNS
Dans Internet, tous les serveurs ont une adresse IP sous forme numérique. C’est impossible à retenir. Il convient d’avoir un annuaire global qui permet de faire la conversion du nom du site visité, vers l’adresse IP du serveur qui héberge le site. Cet annuaire, c’est un système distribué: DNS (Domain Name System)
Exemple: blog.demees.net -> 213.186.33.24 ou bien 2001:41d0:1:1b00:213:186:33:24
Pour arriver à cela, ça se passe en plusieurs temps sans que vous en soyez conscient.
– on consulte les serveurs DNS du registre ‘.net’ – le registre connaît les serveurs DNS du domaine ‘demees.net’ – il donne la réponse: serveurs ‘ns.ovh.net’ et ‘dns.ovh.net’ – on consulte à son tour un de ces serveurs ‘ns.ovh.net’ ou ‘dns.ovh.net’, qui donne la réponse à notre question: blog.demees.net -> (A) 213.186.33.24
Le serveur DNS conserve tous les enregistrements d’un domaine donné dans une “Zone DNS“. Ces enregistrements sont de divers type ou natures: – type A : à un nom, faire correspondre une adresse IP. C’est la fonction la plus basique, et notamment celle qui désigne le serveur web. – type AAAA : à un nom, faire correspondre une adress IPv6. IPv6 voit le jour comme successeur des adresses IP car toutes les adresses possibles ont été distribuées et il y a pénurie. – type TXT : à un nom, faire correspondre une chaîne de texte. C’est un fourre-tout qui peut servir à n’importe quoi, notamment à des fins d’authentification et prouver auprès d’un tiers qu’on est bien le propriétaire du domaine. – type MX : dans cet enregistrement on désigne le nom du serveur SMTP qui va accepter les nouveaux e-mails entrants pour ce domaine. Il peut y avoir plusieurs enregistrements MX pour plusieurs serveurs. – type CNAME : désigne un synonyme, la cible d’un CNAME est un nom de serveur et non une adresse IP. Un CNAME est mutuellement exclusif avec la présence de tout autre enregistrement (A, AAAA, TXT, MX ou autre). La cible d’un CNAME peut être un nom de serveur dans un autre domaine que le vôtre. Terminez son nom par un point. – types SOA, NS : si ces informations sont présentes, ne tentez pas de les modifier dans votre zone DNS. – types ANAME, ALIAS, SPF … il s’agit d’inventions de certains fournisseurs qui ne sont pas standard.
3. Le serveur web
Au minimum, le serveur web qui héberge votre site et bien d’autres, va être sollicité et fournir une réponse. Un utilisateur (au moyen de son navigateur internet) va ouvrir une connexion vers le serveur web et demander d’obtenir une page, par exemple blog.demees.net/
3.1 HTML
Les conversations entre le navigateur (Edge, Firefox, Chrome, Safari, …) se font en HTTP et HTML. Votre site est normalement composé de fichiers HTML. Voici un exemple de page HTML qui affiche “Hello World !”:
<HTML>
<HEAD>
<METAcharset=UTF-8">
</HEAD>
<BODYbgColor=#ffffff>
<DIValign=center><FONTface=Arialsize=2>Hello World !</FONT></DIV></BODY></HTML>
3.2 PHP
PHP est un langage de programmation. Dans le cas de sites web, le résultat de l’exécution du programme PHP est du code HTML, que le serveur web va envoyer au navigateur, et que le navigateur va afficher à l’écran.
Exemple de page PHP:
<?php phpinfo(); ?>
Voyez les marqueurs <?php et ?> qui identifient du langage PHP.
Grâce à de la programmation, les sites peuvent aller chercher de l’information personnalisée, par exemple vous présenter la météo du jour à votre ville, ou le contenu de votre panier de commande. Sans programmation, tout le monde verrait le même contenu de votre site, qui ne serait donc guère plus que la version électronique d’un prospectus.
3.3 SSL
Aujourd’hui (2023) plus aucun site web ne peut se permettre d’exister sans avoir un certificat SSL avec HTTPS. Un certificat a deux utilités: (1) il atteste que le site que vous visitez est bien celui dont l’adresse se trouve dans la barre d’adresse du navigateur, et (2) il met en place des communications cryptées entre votre navigateur et le serveur web (confidentialité, absence de modifications) Let’s Encrypt génère des certificats gratuits. C’est l’hébergeur du site web qui doit mettre ce certificat en place.
4. Applicatifs pour réaliser des sites web, ou “gestionnaires de contenu”
Ici on doit bien faire la distinction entre 2 marchés différents: soit vous optez pour un système entièrement géré, soit vous prenez un hébergement généraliste qui vous laisse toute la liberté de choisir vos logiciels et votre organisation de fichiers.
4.1 les systèmes clés en main
Il s’agit d’offres de fournisseurs qui incluent l’hébergement de votre site, et vous ne vous occupez que du contenu. L’hébergement est une “boîte noire” que vous utilisez telle qu’elle vous est proposée, et c’est généralement un outil convivial et performant. Le fournisseur a la responsabilité de tout faire fonctionner sans que vous soyez impliqué. Cette solution est généralement plus chère qu’un hébergement généraliste. Quelques acteurs: Wix, Jimdo, Vistaprint, etc. Une fois lié avec un de ces fournisseurs il n’existe généralement aucun moyen d’en sortir, à moins de devoir refaire votre site à partir de zéro et avec d’autres outils.
D’autres hébergeurs sont absolument orientés WordPress, et gèrent votre installation WordPress pour vous. Citons WordPress.com, Kinsta, Nexcess … Prévoir une dépense de 20 à 35 USD/mois au minimum, rien que pour l’hébergement du site.
Ces hébergeurs ne sont généralement pas intéressés dans la gestion des e-mails, et ne l’incluent pas dans leur offre, ou bien la sous-traitent.
4.2 les hébergements généralistes
Un hébergement complet contiendra dans la plupart des cas, :
– un nom de domaine (pour cela votre fournisseur doit être bureau d’enregistrement)
– un hébergement de vos adresses DNS, pour cela: . l’adresse du/des serveurs DNS est déclarée auprès du bureau d’enregistrement . une zone DNS qui contient une liste de toutes les correspondances nom – adresse IP, etc. de votre domaine, pour le site web, pour les e-mails, etc.
– un serveur web, capable d’interpréter un langage de programmation, souvent PHP . une certaine quantité d’espace disque associée, pour mettre votre site, les images, etc. . une (ou plusieurs) base(s) de données. Il faut voir une base de données SQL comme une collection de tableaux, et ces tableaux sont constitués de lignes et colonnes, un peu comme dans Excel.
– des e-mails avec un certain nombre de boîtes, qui ont chacune une certaine capacité ; et la possibilité d’émettre un certain nombre d’e-mails depuis vos boîtes mais aussi des messages automatisés à partir de vos sites web.
– certains prestataires proposent en plus des fonctions d’agendas partagés et contacts, des services VPN, de réunions en ligne, de téléphonie par internet, … mais ceci sort du cadre d’un hébergement.
Il faut bien se rendre compte que la tenue à jour de ce que vous avez décidé d’installer dans cet hébergement, avec la plus grande flexibilité, est de votre responsabilité et requiert quelques connaissances, ou tout au moins de la curiosité intellectuelle et une envie de se documenter par soi-même avec autonomie, afin de trouver des réponses à vos questions.
4.3 Les solutions mixtes
Vous décidez d’héberger votre site web (et rien que le site web) auprès d’un acteur spécialisé, citons par exemple systeme.io, Shopify, Pixpa, Wix, Odoo, alors que vous laissez les autres prestations chez un autre hébergeur.
Les solutions mixtes sont les plus compliquées à gérer.
A l’extrême vous pourriez panacher comme suit:
enregistrer le domaine chez A
héberger la zone DNS chez B
héberger le serveur web chez C
utiliser des services CDN pour une meilleure présence mondiale chez D
héberger les mails chez E
pour le mail, utiliser une solution anti-spam chez F
avoir aussi quelques boîtes mail chez G
et enfin un processeur d’e-mailing de masse (publipostage) chez H
Vous pourriez encore adjoindre des bases de données externes, du tracking, des statistiques, de la publicité, etc., la liste n’est pas limitative.
5. Et chez OVH ?
5.1 Le parcours idéal
Délimitez vos besoins. Quel nom de domaine ? Quelle taille pour l’hébergement ? Combien de boîtes mail ?
Comment allez-vous composer votre premier site web ? Pour un blog, une page de présentation, ou le site d’une association: un des incontournables s’appelle WordPress. Pour des sites plus spécialisés (photographe professionnel, webradio, …) ce n’est peut-être pas idéal. Pour un site d’e-commerce, je ne vais pas faire de recommandation. N’oubliez pas que pour vendre, vous devez accepter des moyens de paiement, cette partie de votre futur site web n’est pas à prendre à la légère.
Votre site web sera très certainement basé sur un gestionnaire de contenu (en anglais: CMS ou Content Management System). J’ai déjà cité WordPress plus haut. Il en existe plein d’autres, comme Joomla, Prestashop, Drupal, Typo3, …
L’énorme majorité des CMS requiert un hébergement web avec le langage PHP et une base de données.
Passons à la pratique.
Lors de la commande, OVH propose des modules préinstallés. Je pense que c’est une erreur de proposer cela. C’est bien pour attirer des clients néophytes en laissant croire qu’il ne faut aucune connaissance de base pour se lancer. Outre le fait que ça viole le contrat que vous devez valider par ailleurs (et qui stipule que vous devez avoir les compétences nécessaires pour gérer un site), ça met juste une couche de peinture pour masquer ce qu’il y a derrière, et un jour ou l’autre vous devrez bien mettre les mains dans le cambouis.
5.2 Le processus de commande
Je vous recommande donc d’acheter lors d’une commande unique:
le nom de domaine
un hébergement Perso (meilleure offre pour débuter et progresser)
OVH “oublie” de mentionner que l’offre perso est accompagnées de 10 boîtes mail. Peut-être pour vendre plus de Pro ?
Au départ, n’optez pas aveuglément pour les services annexes tels que:
DNS Anycast
Visibilité Pro
CDN
Certificats payants
Web Cloud Databases
Hébergement web gratuit (Start10m)
La plupart sont inutiles pour vous, et regardez bien les prix affichés: il s’agit pour la plupart de tarifications au mois et non à l’année.
N’installez aucun module.
Envoyez le bon de commande, payez par carte et non par virement, la livraison peut prendre quelques minutes à quelques heures.
A ce stade vous aurez créé un compte client chez OVH. Si vous avez activé l’authentification à 2 facteurs, arrêtez ici la lecture, et si ce n’est pas déjà fait, allez générer tout de suite une liste de 10 codes de secours, imprimez-les et placez-les dans votre coffre-fort ou ce qui en tient lieu.
5.3 Familiarisez-vous avec “l’espace client OVH”
Une fois votre nom de domaine et votre hébergement livrés, familiarisez-vous avec l’espace client OVH (ovh.com/auth), dans la section “Web Cloud”. Désactivez toute traduction automatique au niveau de votre navigateur. Cloud s’appelle Cloud et non Nuage !
Vous allez trouver :
dans “Domaines” ce qui concerne le Domaine et tout ce qui gravite autour de DNS
dans “Hébergement” tout ce qui concerne votre site web et sa base de données
dans “E-mails” tout ce qui concerne vos 10 boîtes mail
Préparons un peu votre environnement:
Dans Hébergement, FTP/SSH, changez le mot de passe FTP, et activez l’option SFTP
Notez l’adresse (par exemple ftp.cluster099.hosting.ovh.net), notez le login et le mot de passe que vous venez de mettre. Ce sont vos identifiants FTP.
Dans Hébergement, Informations générales, vérifiez de mettre une version de PHP récente et d’activer SSL.
Dans Hébergement, Multisite, pour chacun des deux domaines avec votre nom, activez SSL, mais laissez les autres options inchangées: pas de logs séparés, pas de pare-feu, et dossier racine = www. Aussitôt fait, dans Actions: regénérer le certificat SSL.
Enfin, dans Hébergement, Base de données, vous devrez créer une base de données. Une fois créée vous aurez besoin de 4 éléments pour accéder à votre base:
et le mot de passe que vous avez choisi.
Notez bien cela aussi.
Vous voilà donc avec 3 identifiants différents:
l’espace client OVH, identifiant de la forme XY12345-OVH, son mot de passe, son authentification à 2 facteurs recommandée
le FTP: un nom de serveur, un login, un mot de passe
la base de données: serveur, database, login et mot de passe. Chez OVH, database et login sont identiques.
5.4 Familiarisez-vous avec votre FTP
Maintenant il est temps de dompter votre espace FTP. Je vous recommande l’excellent logiciel FileZilla (lien de téléchargement).
Dans FileZilla, je vous recommande d’utiliser SFTP, port 22, nom de serveur: ftp.clusterXXX.hosting.ovh.net (en remplaçant XXX par ce qui vous a été attribué). Cette connexion SFTP est sécurisée.
Apprenez à copier des fichiers depuis votre PC vers votre espace web. Si vous les déposez dans le dossier /www vous pourrez vérifier leur présence avec un navigateur à l’adresse http://votredomaine.com/nomdefichier
Tant que vous êtes là, supprimez sans autre question le fichier index.html que OVH a mis dans votre espace vide, et qui affiche une page “Site en construction”.
5.5 Installation de WordPress
Ceci se passe en plusieurs étapes:
vous téléchargez WordPress depuis le site officiel (wordpress.org). Vous allez recevoir un fichier zip de 20 à 30 mégabytes.
vous dézippez cette archive. Il en résulte plusieurs milliers de fichiers.
vous copiez ces milliers de fichiers dans votre serveur FTP (depuis le répertoire “wordpress” de votre PC, vers le répertoire “www” du serveur FTP, ceci afin que wp-content, index.php, readme.html et d’autres se trouvent dans le répertoire www à la fin de la copie)
vous visitez votre site à son adresse officielle https://votresite.com , c’est-à-dire celle que vous allez diffuser sur vos cartes de visite et sur le lettrage de votre camionnette.
vous êtes prêt à fournir les 4 identifiants de la base de données pour pouvoir faire la configuration initiale, et vous vous laissez guider.
Votre WordPress est installé ! Bon succès !
6. Et les e-mails ?
Les e-mails, c’est un hébergement spécifique, qui n’est pas lié à la partie web. Cette partie est beaucoup trop longue et complexe, et sort du sujet de cet article dont l’objectif est de décrire un hébergement de site web.
Je vais juste énumérer quelques mots-clés:
serveur mail: serveur qui réceptionne les nouveaux mails qui arrivent, permet généralement de créer des dossiers et de gérer ses mails dans les différents dossiers. Gérer un serveur mail est une tâche ingrate car les utilisateurs ont toujours tendance à vouloir conserver bien plus que nécessaire, et comme le désordre est moins visible que dans la cuisine, il a de beaux jours devant lui.
client mail: c’est le logiciel que vous utilisez pour lire vos mails: citons Thunderbird, Outlook, les logiciels “Mail” sur les appareils mobiles, mais aussi les webmails comme Roundcube ou Squirrelmail par exemple.
SMTP: c’est le protocole couramment utilisé par un client mail pour expédier le courrier sortant vers son serveur mail habituel. C’est aussi le protocole utilisé entre les différents serveurs pour acheminer le mail vers sa destination.
POP3: c’est un protocole ancestral utilisé par un client mail pour aller récupérer ses nouveaux mails auprès du serveur mail. Typiquement le client récupère les mails, et puis les efface du serveur. Dans ce schéma apparenté à notre bonne vieille boîte postale, le serveur ne contient pas de dossiers de classement, et est constamment vidé.
IMAP: ce protocole entre client et serveur permet de lire ses mails, conserver ses mails sur le serveur, créer des dossiers, déplacer/copier des mails d’un dossier à un autre, etc. Plusieurs appareils peuvent utiliser la même boîte simultanément. Le statut lu/non-lu est tenu à jour de manière consistente entre tous les clients connectés. Notez que les messages envoyés ne sont stockés dans la boîte mail que si le client IMAP est configuré adéquatement, car SMTP ne s’en occupe pas.
MX: quand on possède un nom de domaine, on possède une zone DNS. Dans cette zone DNS on met un ou plusieurs enregistrements MX qui désignent les serveurs mail qui doivent réceptionner les mails pour tous les utilisateurs de ce domaine.
SPF: Enregistrement DNS de type TXT qui indique quels serveurs SMTP sont autorisés à expédier les mails de votre domaine. Si cet enregistrement n’est pas présent, c’est médiocre pour votre réputation et votre “déliverabilité”. Si cet enregistrement est présent, une clause de ce dernier indique quelle politique vous avez décidé d’appliquer lorsque le serveur n’a pas été explicitement autorisé: vous donnez instruction de ne rien faire ou rejeter le mail lors de la réception.
DKIM: tout comme SPF il s’agit de rendre vos mails sortants authentiques. La technique est totalement différente. Au lieu de lister des adresses IP de serveurs autorisés, ici on va se focaliser sur le contenu du mail lui-même et apposer une signature électronique qui est un sceau d’authenticité. Peu importe le chemin que ce mail a pris, du moment que le contenu n’a pas été altéré. La signature est apposée par le serveur d’envoi faisant partie de votre relation contractuelle.
(les photos et liens s’ouvrent toujours dans un nouvel onglet)
En décembre 2016, j’avais acheté un PC/tablette Microsoft Surface Pro 4.
Il est tombé en panne (chipset graphique) en mai 2018. Toujours couvert par la garantie, il m’a été échangé par un à l’état neuf, avec perte de toutes mes données bien sûr.
En décembre 2022, quatre ans et demi plus tard, j’ai peu à peu l’impression qu’il y a des halos de couleur dans les parties noires de l’écran dans les coins à droite.
En regardant plus attentivement, les reflets dans l’écran qui est brillant comme un miroir, sont convexes comme un rétro extérieur de voiture.
Vérifions avec une latte (belgicisme: règle pour les Français) :
C’est clair, c’est bien bombé, et sur les deux faces !
Qui dit: appareil en panne, il faut que je m’aventure à le réparer.
Microsoft et Apple sont les deux cancres de la planète pour la question de la “réparabilité” de leurs appareils, et Surface Pro ne déroge pas à la règle:
On va quand même rester optimiste. J’ai acheté quelques outils qui me manquaient, notamment un IOpener de iFixit.com (c’est une sorte de saucisse en plastique remplie de liqude, qu’on met au micro-ondes pour la chauffer à 70-80°C afin de ramollir la colle).
Vous avez vu le sachet Haribo ? Oui c’était offert par iFixit !
J’ai ressorti un thermomètre digital pour mesurer la température de ma chaufferette.
Voici la batterie achetée pour rien: https://www.amazon.com.be/dp/B07WZMD378
Documentons-nous un peu. Il faut se donner un peu de courage.
Suivez ce tutoriel pour remplacer la batterie de la Microsoft Surface Pro 4.
Si votre batterie est gonflée, prenez les précautions appropriées.
Il y a un risque non négligeable que vous cassiez l’écran, qui est fragile et non renforcé, pendant cette procédure. Assurez-vous de ne pas surchauffer et d’être extrêmement précautionneux en coupant l’adhésif. Portez des lunettes de protection au cas où le verre se brise.
Chapitre 1:
Si la vitre de votre écran est fissurée, limitez la fissure et protégez-vous des éclats pendant la réparation en scotchant la vitre.
Appliquez des couches d’adhésif se chevauchant sur l’écran de la Surface, jusqu’à ce que toute la surface soit couverte.
Cela maintiendra les éclats éventuels et renforcera la structure lorsqu’on va faire levier sur l’écran.
Suivez le reste du tutoriel de votre mieux. Cependant, une fois le verre brisé, il est probable qu’il continue de se fissurer au cours de la réparation, et vous pourriez avoir besoin d’utiliser des outils métalliques pour extraire le verre.
Portez des lunettes de sécurité pour protéger vos yeux et faites attention à ne pas endommager l’écran LCD.
L’adhésif sur la vitre et la chauffe à 75°C ça ne va pas ensemble. Mauvais conseil.
Avec beaucoup de soin ça avait bien commencé.
Puis, lors du décollage du troisième côté, crac.
Evidemment, le verre s’est cassé.
Ce verre doit faire 0,2 mm d’épaisseur, à tout casser (je choisis mes mots)
RIP Surface Pro. Même pas 5 ans d’âge et il faut le poubelliser. Impossible de mettre proprement au recyclage puisque l’électronique et la batterie sont toujours solidaires l’une de l’autre. Recupel aura du travail.
Dans un environnement Microsoft Exchange, lorsque vous changez la langue d’utilisation via Outlook Web, cette opération va changer le nom des dossiers spéciaux sur le serveur, ce qui amène à une belle fantaisie.
IMAP recommande pourtant que ces dossiers spéciaux restent en anglais sur le serveur, et que ce soit le logiciel client qui fasse la traduction au vol.
Microsoft n’en a cure, et depuis toujours (Outlook Express, Windows Mail) il va créer des nouveaux dossiers sur le serveur, quitte à perturber complètement le fonctionnement des autres appareils connectés à la même boîte mail.
Avec Exchange il y a un petit mieux. L’utilisateur la le choix de renommer ou non les dossiers spéciaux, et cette option est cochée par défaut. Peut-être n’est-ce pas le bon choix.
Voyez en images. Il s’agit d’une boîte mail chez OVH, accédée simultanément en IMAP avec Thunderbird, et via le Webmail qui est Outlook Web.
Cette boîte est configurée en anglais mais a déjà été utilisée en français dans le passé.
Voici avant le changement:
Voici comme se présente la boîte mail depuis Thunderbird
A partir du webmail OWA, changement de la langue vers le français
hé bien non c’est impossible, il reste des traces qui empêchent ce changement !
Choisissons le néerlandais alors
et voyons ce que ça donne sur Thunderbird après un refresh… mais quel bazar !!
Mais pourquoi ne voit-on pas les dossiers fantômes sur le serveur ?
J’ai pu remettre en anglais, mais Thunderbird “voit” toujours les dossiers en néerlandais ET ceux en anglais…
Dans ce tuto, nous allons installer NextCloud version 24.0.0.12 dans un hébergement mutualisé OVH de type ‘perso’.
NextCloud est un applicatif écrit en PHP et il utilise une base de données pour pouvoir fonctionner.
L’hébergement mutualisé Perso OVH dispose de 100 GB d’espace disque, dont on va utiliser ½ GB pour NextCloud lui-même, et une base de données MySQL de 200 MB dont environ 10 MB vont être utilisés dès le départ par NextCloud.
L’installation présuppose que vous êtes familier avec les hébergements OVH, et qu’il n’y a pas déjà une installation NextCloud dans cet hébergement.
Vous êtes supposé être capable de :
créer un nouveau site via la page ‘multisite’ de l’espace client,
activer un certificat SSL sur ce site
utiliser un client FTP comme FileZilla,
utiliser le protocole sftp plutôt que ftp,
créer une base de données MySQL
ou utiliser une base existante et en récupérer le mot de passe
Afin de ne pas alourdir inutilement le texte, les instructions qui y sont relatives pourront être concises.
Pour cet exemple, j’ai même utilisé l’hébergement Perso d’un autre domaine que celui qui nous intéresse:
Ce hébergement existe depuis 2008, ce qui explique la présence de fichiers portant cette date.
Voici la liste des fichiers via FTP:
On peut y voir ‘www’ et ‘drive’, qui sont les ‘dossiers racine’ des deux sites hébergés sur cet hébergement.
J’ai aussi créé ‘drivedata’ qui est destiné à contenir les fichiers utilisateur de NextCloud. Je recommande que ce répertoire ne se trouve dans aucun des dossiers racine des sites hébergés. Ainsi aucun site n’y a accès, en-dehors de NextCloud ou d’une autre application PHP hébergée.
Passons aux préparatifs sérieux.
Configurez l’hébergement avec la version la plus récente de PHP, actuellement stable64 et PHP 8.1.
Configurez le multi-site, afin que votre cloud ait une adresse unique (p.ex. drive.example.com mais pas www.drive.example.com)
N’activez pas le firewall. Activez les logs séparés ou non, selons vos désirs. Activez SSL, puis allez dans la page générale pour regénérer le certificat.
Vous allez recevoir un téléchargement du fichier ‘latest.zip’ (143 MB à la date de rédaction 15/05/2022, version 24.0.0.12).
Dézippez-le : 346 MB, 19500 fichiers et 3200 dossiers.
Il faut maintenant ‘pousser’ tout le contenu dans votre hébergement FTP, dans le répertoire /drive si vous avez suivi mon exemple. Ca prendra “un certain temps” ou “un temps certain”. A la fin vous aurez ceci :
Pendant que ça copie, vous pouvez préparer la base de données.
Vous devez être en possession de 4 paramètres (adaptez nomdelabase):
serveur: nomdelabase.mysql.db
base de données: nomdelabase
utilisateur: nomdelabase
mot de passe: vous seul le connaissez
Si cette base existe déjà (par exemple pour un site WordPress déjà présent) voyez dans les fichiers de configuration quels sont ces 4 paramètres (dans le cas de WordPress, vous pouvez consulter wp-config.php). Ne changez pas le mot de passe via l’espace client, car vous rendriez ce site inopérant.
Maintenant, lorsque la copie est terminée, vous pouvez visiter votre site en appelant son adresse définitive dans un navigateur (avec votre nom de domaine et https)
Vous devrez préciser une série d’informations ET ABSTENEZ-VOUS D’APPUYER sur ENTER ou de cliquer OK tant qu’on n’a pas rempli tous les champs:
login et mot de passe du futur admin
sélection de MySQL/MariaDB –> complétez les 4 paramètres nécessaires
sélection du répertoire data (je conseille /drivedata plutôt que /drive/data, voyez plus haut)
L’installation commence, et se termine sur un magnifique “Gateway Timeout”.
Attendre 5 minutes et se reconnecter à l’adresse du site.
Tout semble être là et parfaitement opérationnel.
Connectez-vous avec le compte admin.
Dans les réglages:
Administration > Paramètres de base, serveur e-mail: mode d’envoi “Sendmail”
Personnel > Informations personnelles > mettre une adresse mail > vous devriez recevoir un mail
Applications (depuis le menu à droite) > Pack d’applications
Eventuellement ajouter “Calendar” et “Contacts”.
Aller dans la gestion des utilisateurs ; créer un ou des groupes ordinaires et créer des utilisateurs non privilégiés dans ce groupe.
A partir de maintenant traviller exclusivement avec ces utilisateurs non privilégiés.
L’installation n’a pas été testée en profondeur dans des conditions réelles.
Considérez ceci comme une facilité à usage personnel.
N’allez jamais construire un cloud dans un tel hébergement web mutualisé, et qui deviendrait peu à peu un élément critique pour votre activité professionnelle.
Lors de mes essais, j’ai pu charger plusieurs centaines de photos et des vidéos pesant jusqu’à plus de 260 MB, alors que phpinfo() me dit: post_max_size 130M et upload_max_filesize 128M. C’est encourageant.
Bientôt la version de MySQL 5.6 proposée par OVH ne sera plus supportée par NextCloud, un jour ce sera autre chose, etc.
Sachez aussi qu’en ultime recours, vous trouverez :
les fichiers dans le répertoire ftp /drivedata
les événements Calendar sont dans la table `oc_calendarobjects`, dans le champ [blob] calendardata
de même les contacts se trouvent dans la table `oc_cards`, dans le champ [blob] carddata
Ces protocoles sont destinés à authentifier les e-mails émis par les utilisateurs de votre domaine . Ils n’empêchent pas la falsification (quelqu’un qui se fait passer pour vous ou vos collaborateurs) mais ils aident à les contrer d’une manière relativement efficace.
En fin de compte c’est le serveur en réception qui va consulter ou non vos directives (SPF, DKIM, DMARC) et éventuellement rejeter le mail falsifié si vous avez donné instruction qu’il fallait les rejeter.
OVH implémente SPF.
OVH n’implémente pas DKIM, ce qui en 2022 est assez inacceptable.
DMARC ne devrait pas être conseillé si vous n’avez pas DKIM. Chez OVH je le déconseille donc.
SPF sert à publier les adresses IP des serveurs qui sont autorisés à émettre des mails de votre domaine (typiquement ce sont les serveurs d’OVH. Si vous faites appel à une société extérieure pour des mailings, il faudra ajouter leurs serveurs)
Le SPF est publié dans votre zone DNS, dans un enregistrement TXT.
DKIM authentifie sur base d’une signature numérique dans les en-têtes SMTP, vous ne la voyez habituellement pas. A toute clé numérique il y a une partie privée (dans le cas de DKIM: détenue exclusivement par votre serveur mail d’envoi), et une partie publique, publiée dans votre zone DNS.
Le serveur en réception consulte la clé publique dans votre zone DNS pour vérifier la signature électronique du mail reçu. Si ça colle, alors le mail est authentique, quelle que soit l’adresse IP du serveur qui l’a envoyé.
Je rappelle que les serveurs d’envoi OVH n’insèrent pas de signature DKIM. Donc pas besoin de mettre une clé publique dans DNS non plus.
DMARC vous permet de donner des instructions aux serveurs en réception et comment ils doivent se comporter face à des mails qui échouent au contrôle SPF et DKIM. Le but est d’indiquer “si un mail échoue à SPF et DKIM alors il est frauduleux et il faut le refuser”.
Faire confiance à SPF tout seul est une loterie car un message qui fait l’objet d’une redirection ou via une mailing list sera considéré comme frauduleux, puisque l’adresse IP du serveur de l’émetteur n’est plus celle du domaine d’origine. (sauf si le redirecteur adhère à SRS, ce sera peut être l’objet d’un autre article !)
Annonce sur Facebook : Un appareil à 1 euro chez Media Markt ! Assurément une offre bien trop alléchante pour être vraie !
Le lien mentionne un site qui n’est nullement Media Markt. Il me donne envie de cliquer dessus, rien que pour voir ce qu’ils vont encore inventer comme arnaque cette fois-ci.
Le résultat est au-dessus de mes espérances: une fausse page “vous avez été infecté par un Trojan Spyware”. Voyez plutôt… c’est tout du bidon… sauf le numéro de téléphone auquel les racailles attendent le pigeon pour mieux l’escroquer.
Par exemple prenons le chapitre 11 sur la sécurité des sites Web. C’est d’une précision rarement atteinte dans tout ce que j’ai pu lire jusqu’à aujourd’hui.
Voici la table des matières de ce chapitre 11, capturé le 11 décembre 2020:
IndexIndex
Introduction
Methodology
Transport security
Protocol versions
Cipher suites
Certificate Authorities
Browser enforcement
HTTP Strict Transport Security
Cookies
Content inclusion
Content Security Policy
Subresource integrity
Feature policy
Iframe sandbox
Thwarting attacks
Security mechanism adoption
Preventing XSS attacks through CSP
Defending against XS-Leaks with Cross-Origin Policies
Web Cryptography API
Utilizing bot protection services
Relationship between the adoption of security headers and various factors
Country of a website's visitors
Technology stack
Co-occurrence of other security headers
Software update practices
WordPress
jQuery
nginx
Malpractices on the web
Evolution & conclusion
