Ça rame ! Petite histoire d’un problème de réseau
Depuis plusieurs jours, ça rame chez moi. Ça arrive à tout le monde, on est en Calédonie et j’ai une éligibilité à 4Mb/s, donc je ne m’attends pas à des miracles, mais je ressens cette lenteur de façon intermittente beaucoup plus souvent que d’habitude, alors j’ai décidé d’investiguer. Mon premier réflexe, parce que c’est le plus simple, c’est d’aller sur fast.com pour vérifier mon débit avec un speedtest simple qui m’indique que mon débit est de… 170kbps.
Clairement, c’est lent ! Je vérifie mon éligibilité sur le site de l’OPT en entrant juste le numéro de téléphone de ma ligne :
Avec mon éligibilité à 4Mb/s, je devrais avoir un résultat en gros à 4Mb/s, ou en tous cas au moins à 1Mb/s si c’est en période de forte utilisation du réseau le soir par exemple (mais là c’est le matin, il n’y a pas de raison que ça soit si lent !). Avant de de m’énerver contre mon fournisseur d’accès à internet et contre l’OPT, je vais essayer d’en savoir un peu plus.
Le diagnostic
Est-ce mon PC qui est lent ? Est-ce le réseau local? Est-ce le routeur, le modem, la ligne, l’OPT, mon fournisseur d’accès, le câble sous-marin, un ou des serveurs distants ? Je pars généralement du plus proche (mon PC) pour commencer mes investigations, car c’est là que j’ai le plus de possibilités, alors que de l’autre côté, je n’ai pas beaucoup de moyens de tester et d’agir sur l’OPT ou le réseau international par moi-même. Si le problème ne semble pas s’y trouver, j’avance élément par élément du plus proche vers le plus éloigné.
Mon PC
Même si le problème semble lié au réseau, je préfère toujours m’assurer que ce n’est pas simplement mon PC qui ralentit. Pour vérifier, il suffit de noter à quelle moment la lenteur se fait ressentir, si cela correspond à une utilisation du réseau ou à un logiciel, et de regarder les autres logiciels qui tournent pendant les ralentissement. Dans mon cas, c’est clairement lors de l’utilisation du réseau (avec le navigateur ou en ligne de commande SSH), alors qu’aucun autre logiciel n’est lancé. Je passe donc à la suite du diagnostic avec le réseau local.
Le réseau local
Il y a plusieurs choses à vérifier au niveau du réseau, le premier test c’est de vérifier si le problème apparaît en wifi comme en câble. Je suis câblée habituellement, mais le problème apparaît de la même façon en wifi, ça ne vient donc pas de la connexion entre mon PC et le routeur. Les autres PC du réseau subissent les mêmes ralentissements, et au même moment, ça semble donc être un problème qui affecte tout le réseau, et pas un problème au sein du réseau.
Pour valider mon hypothèse, j’ai effectué un traceroute, qui me permet de connaître la latence (le ping) entre mon PC et une IP distante, pour chacun des équipements entre les 2 . Je fais généralement le test vers le serveur DNS public de Google à l’adresse 8.8.8.8 pour avoir un hôte distant assez sûr et assez loin pour tester jusqu’en dehors de la Nouvelle-Calédonie :
mtr 8.8.8.8
On observe grâce à cette commande que le problème de lenteur est en fait un problème de latence. Les paquets mettent moins d’un millième de seconde pour accéder à mon routeur, et mettent ensuite presque 2 secondes pour arriver jusqu’à mon FAI. La suite du traceroute ne semble être qu’une conséquence de cette partie du réseau, c’est normal que tout ce qui est après soit également très lent. Et en plus, je perds entre 25 et 40% des paquets à partir de mon routeur.
Le routeur et le modem
L’hypothèse la plus probable à ce stade est une défaillance du modem. Dans mon cas, le routeur et le modem sont 2 boîtiers séparés, mais ils sont très souvent combinés en un modem-routeur.
La connexion ADSL en Nouvelle-Calédonie se fait en PPPoE, le modem n’est pas un équipement « visible » sur le réseau TCP/IP. Il peut être à l’origine des ralentissements, et c’est généralement de ce côté qu’il y a un problème. J’ai donc commencé par changer le modem, sans aucune amélioration. J’ai également changé le filtre ADSL, et le câble RJ11 reliant le modem au filtre ADSL : aucune amélioration non plus.
Le routeur est au cœur du réseau, il peut très bien être à l’origine des ralentissements, en plus c’est à partir de lui que tout se ralentit. J’ai commencé par changer le câble ethernet reliant le routeur au modem, sans amélioration. Puis j’ai fait un reset de mon routeur, que j’ai ensuite reconfiguré avec les paramètres les plus basiques pour m’assurer que ça n’est pas un problème de configuration : pas mieux. J’ai fini par changer le routeur par un autre : toujours la même chose.
La ligne ADSL et le FAI
Logiquement, je me suis tournée vers mon FAI pour lui demander des explications. Il m’a assuré qu’il n’avait aucun problème sur ses équipements, qu’il ne voyait aucun défaut sur ma ligne, et que la connexion PPPoE entre mon modem et ses équipements était stable. Je le crois volontiers, puisqu’il y a des moments où tout fonctionne parfaitement, j’ai un débit à l’international proche de mon éligibilité et où tout se passe bien, et si mon FAI avait des problèmes sur ses équipements, je ne serais pas la seule à m’en plaindre !
Le réseau international
Dans mon cas actuel, le réseau international semble être hors de cause puisque j’ai pu constater que la latence apparaît entre mon routeur et mon FAI. Cependant, quand les lenteurs ne sont pas à cet endroit du réseau, il peut être intéressant d’investiguer plus loin pour vérifier si les lenteurs ne sont pas dues au service auquel on souhaite accéder sur internet. On peut avoir une bonne idée en faisant un traceroute vers différents serveurs (et se rendre compte par la même occasion que les services en Europe sont à plus de 300ms de nous, alors que l’Australie est 10 fois moins loin en termes de latence réseau !)
Et alors, c’est quoi le problème ?
J’ai tout vérifié et rien trouvé. C’est souvent comme ça, on ne trouve pas du premier coup, mais cette première étape du diagnostic permet de passer à la suite avec déjà beaucoup plus d’informations sur le problème. Voilà ce que je sais :
- j’ai des problèmes de latence, de façon intermittente
- mon réseau local ne pose pas de problèmes
- la latence apparaît à partir de mon routeur
- mes équipements ne sont pas défaillants (tout a été changé)
- il n’y a pas de problèmes sur ma ligne et chez mon FAI
Si le problème apparaît de façon intermittente, et que ça n’est pas un problème matériel ou de configuration, alors cela ressemble à un problème lié à l’utilisation du réseau. Pour vérifier, je vais voir les graphs d’utilisation sur l’interface de mon routeur, tout en faisant un ping continu vers la première IP de mon FAI pour vérifier sur le graph à quel moment la latence apparaît :
Dans ce graph, le rose correspond au Rx (octets reçus = download), et le violet au Tx (octets transmis = envoyés = upload). Les périodes de ralentissement correspondent au moment où le routeur envoie beaucoup de données vers internet. Je remarque aussi que le débit maximum d’envoi (825kb/s) dépasse largement l’éligibilité théorique de ma ligne (512kb/s), et plutôt que de m’en réjouir, je me dis que c’est peut être une piste : ça ne devrait pas aller aussi haut !
C’est quoi ce trafic ?
Ma première interrogation, c’est tout de même de savoir ce qui est envoyé. Je n’ai rien sur mon réseau qui est censé envoyer autant de données, et mon routeur ne me dit pas d’où vient ces envois (il aurait pu me le dire si j’avais un seul équipement par port, mais j’ai un switch et tout vient du même port). Je vais donc utiliser une technique très sophistiquée pour en savoir plus : je débranche un par un les équipements du réseau dès que les ralentissements apparaissent.
En quelques minutes à peine, j’ai trouvé le coupable : un des PC du réseau, qui semble pourtant assez banal, je n’aurais pas parié dessus. Les ralentissements cessent à la seconde où je le débranche, et j’ai testé plusieurs fois pour être sûre. Reste maintenant à savoir ce qu’il envoie, et vers où. Le PC est sous Linux, je peux voir assez rapidement ce qui se passe sur le réseau grâce à la commande iftop :
sudo iftop -i interface1
whois 1e100.net Domain Name: 1E100.NET Registry Domain ID: 1570253561_DOMAIN_NET-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com Updated Date: 2010-09-15T17:45:17Z Creation Date: 2009-09-25T05:40:03Z Registry Expiry Date: 2019-09-25T05:40:03Z Registrar: MarkMonitor Inc. Registrar IANA ID: 292 Registrar Abuse Contact Email: abusecomplaints@markmonitor.com Registrar Abuse Contact Phone: +1.2083895740 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of whois database: 2017-12-25T23:07:09Z <<<
Bon, pas super clair comme réponse. Une recherche m’en apprend plus, directement chez Google :
C’est donc un serveur Google. Quelques recherches plus loin, et il apparaît que c’est Google Chrome qui envoie des données à Google. Au delà des considérations éthiques peu rassurantes sur le respect de la vie privée, ces uploads ne m’arrangent pas, mais je ne peux pas les contrôler. Et ça n’explique pas pourquoi ça ralentit autant.
Trop d’upload tue la latence ?
Bon, avec ce que je sais désormais, l’hypothèse la plus logique semble être qu’essayer d’uploader trop de données d’un coup est la cause des ralentissements de ma connexion internet. Avant d’agir, je veux m’assurer que c’est bien le cas. Je vais donc mettre en place un test d’upload où je contrôle vitesse d’upload.
Tout d’abord, je lance un ping vers la 1ère IP de mon FAI pour observer les changements de latence au fur et à mesure des tests :
ping ip1.fai 64 bytes from ip1.fai: icmp_seq=1 ttl=254 time=8.32 ms 64 bytes from ip1.fai: icmp_seq=2 ttl=254 time=8.21 ms 64 bytes from ip1.fai: icmp_seq=3 ttl=254 time=7.87 ms 64 bytes from ip1.fai: icmp_seq=4 ttl=254 time=8.31 ms
Quand il ne se passe rien d’autre sur le réseau, j’ai une latence d’environ 8ms, c’est donc ma valeur de référence.
J’ai la chance de disposer d’un serveur dédié en Nouvelle-Calédonie avec lequel je peux faire des tests, ce qui m’assure de ne pas subir les éventuelles latences vers l’international. Sur ce serveur, j’ouvre un port (au hasard le 8888) en écoute avec netcat (nc) pour recevoir n’importe quelles données, que je mets directement à la poubelle dans /dev/null (les données en elles-même ne m’intéressent pas, j’essaye juste de saturer la bande passante de ma connexion) :
nc -l -p 8888 > /dev/null
Sur mon PC dans mon réseau local, je choisis un gros fichier quelconque (ici une image Raspbian) que je vais envoyer à mon serveur avec netcat également, mais en contrôlant la vitesse d’upload avec pv. Pour le premier test, j’envoie à 20ko/s, ce qui correspond à 160kb/s. Mon éligibilité est de 512kb/s, ça devrait donc largement passer :
pv -r -L20k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
Aucun problème de latence avec ce premier test, je monte à 60ko/s = 480kb/s, soit juste en dessous de mon éligibilité :
pv -r -L60k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
Côté latence, ça augmente un peu (bon 10 fois plus qu’au repos, certes), mais ça reste très acceptable, et surtout assez peu perceptible humainement :
64 bytes from ip1.fai: icmp_seq=258 ttl=254 time=95.7 ms 64 bytes from ip1.fai: icmp_seq=259 ttl=254 time=94.8 ms 64 bytes from ip1.fai: icmp_seq=260 ttl=254 time=93.9 ms 64 bytes from ip1.fai: icmp_seq=261 ttl=254 time=92.4 ms 64 bytes from ip1.fai: icmp_seq=262 ttl=254 time=90.9 ms 64 bytes from ip1.fai: icmp_seq=263 ttl=254 time=92.8 ms
J’augmente la vitesse à 65ko/s = 520kb/s, soit juste au dessus de mon éligibilité :
pv -r -L65k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
64 bytes from ip1.fai: icmp_seq=392 ttl=254 time=8.54 ms 64 bytes from ip1.fai: icmp_seq=393 ttl=254 time=18.3 ms 64 bytes from ip1.fai: icmp_seq=394 ttl=254 time=182 ms 64 bytes from ip1.fai: icmp_seq=395 ttl=254 time=233 ms 64 bytes from ip1.fai: icmp_seq=396 ttl=254 time=197 ms 64 bytes from ip1.fai: icmp_seq=397 ttl=254 time=250 ms 64 bytes from ip1.fai: icmp_seq=398 ttl=254 time=280 ms 64 bytes from ip1.fai: icmp_seq=399 ttl=254 time=317 ms 64 bytes from ip1.fai: icmp_seq=400 ttl=254 time=348 ms 64 bytes from ip1.fai: icmp_seq=401 ttl=254 time=481 ms 64 bytes from ip1.fai: icmp_seq=402 ttl=254 time=541 ms 64 bytes from ip1.fai: icmp_seq=403 ttl=254 time=563 ms 64 bytes from ip1.fai: icmp_seq=404 ttl=254 time=724 ms 64 bytes from ip1.fai: icmp_seq=405 ttl=254 time=738 ms 64 bytes from ip1.fai: icmp_seq=406 ttl=254 time=776 ms 64 bytes from ip1.fai: icmp_seq=407 ttl=254 time=828 ms 64 bytes from ip1.fai: icmp_seq=408 ttl=254 time=858 ms 64 bytes from ip1.fai: icmp_seq=409 ttl=254 time=799 ms 64 bytes from ip1.fai: icmp_seq=410 ttl=254 time=839 ms 64 bytes from ip1.fai: icmp_seq=411 ttl=254 time=903 ms 64 bytes from ip1.fai: icmp_seq=412 ttl=254 time=960 ms 64 bytes from ip1.fai: icmp_seq=413 ttl=254 time=1054 ms 64 bytes from ip1.fai: icmp_seq=414 ttl=254 time=1186 ms 64 bytes from ip1.fai: icmp_seq=415 ttl=254 time=1227 ms 64 bytes from ip1.fai: icmp_seq=416 ttl=254 time=1316 ms 64 bytes from ip1.fai: icmp_seq=417 ttl=254 time=1409 ms 64 bytes from ip1.fai: icmp_seq=418 ttl=254 time=1491 ms 64 bytes from ip1.fai: icmp_seq=419 ttl=254 time=1545 ms 64 bytes from ip1.fai: icmp_seq=420 ttl=254 time=1597 ms 64 bytes from ip1.fai: icmp_seq=421 ttl=254 time=7.69 ms
Le résultat est sans appel, la latence augmente rapidement, se revient à sa valeur de base dès que j’arrête le transfert. À 65ko/s, ça met une vingtaine de secondes à atteindre plus d’une seconde de latence, mais si j’augmente encore la vitesse la latence augmente beaucoup plus rapidement. En testant avec 100ko/s = 800kb/s, on l’atteint en moins de 6 secondes :
pv -r -L100k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
64 bytes from ip1.fai: icmp_seq=714 ttl=254 time=8.26 ms 64 bytes from ip1.fai: icmp_seq=715 ttl=254 time=147 ms 64 bytes from ip1.fai: icmp_seq=716 ttl=254 time=554 ms 64 bytes from ip1.fai: icmp_seq=717 ttl=254 time=644 ms 64 bytes from ip1.fai: icmp_seq=718 ttl=254 time=671 ms 64 bytes from ip1.fai: icmp_seq=719 ttl=254 time=746 ms 64 bytes from ip1.fai: icmp_seq=720 ttl=254 time=1024 ms 64 bytes from ip1.fai: icmp_seq=721 ttl=254 time=1470 ms 64 bytes from ip1.fai: icmp_seq=722 ttl=254 time=1938 ms
L’hypothèse se vérifie bien : trop d’upload génère une grosse latence sur ma connexion. Je n’ai pas l’explication exacte pour comprendre le phénomène, je penche pour un buffer qui se remplit sur le routeur et qui ne lui permet plus de traiter les paquets comme il faut.
La solution : limiter la bande passante sur le routeur
L’idée est donc de limiter la bande passante réellement envoyée par le routeur sur la ligne ADSL pour que ça ne dépasse jamais l’éligibilité de la ligne. Mon routeur est un Mikrotik, je peux m’y connecter en telnet et le configurer avec cette ligne de commande :
/queue tree add name="Upload" parent=pppoe-out1 packet-mark=no-mark limit-at=480k max-limit=500k
On la retrouve dans l’interface web sous le menu « Queues » :
Pour tester que cela fonctionne, je refais le même test que pour diagnostiquer le problème : j’essaye d’uploader des données à une vitesse plus élevée que mon éligibilité, disons à 100ko/s = 800kb/s au lieu de 512kb/s, tout en effectuant un ping pour surveiller la latence :
pv -r -L100k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888 [57,8KiB/s]
L’upload reste un peu en dessous de 60ko/s = 480ko/s, soit la vitesse que j’ai demandé à mon routeur de respecter.
Côté latence, elle augmente un peu mais reste très raisonnable :
64 bytes from ip1.fai: icmp_seq=3291 ttl=254 time=204 ms 64 bytes from ip1.fai: icmp_seq=3293 ttl=254 time=171 ms 64 bytes from ip1.fai: icmp_seq=3295 ttl=254 time=117 ms 64 bytes from ip1.fai: icmp_seq=3296 ttl=254 time=190 ms 64 bytes from ip1.fai: icmp_seq=3299 ttl=254 time=162 ms 64 bytes from ip1.fai: icmp_seq=3300 ttl=254 time=186 ms 64 bytes from ip1.fai: icmp_seq=3301 ttl=254 time=215 ms 64 bytes from ip1.fai: icmp_seq=3302 ttl=254 time=198 ms 64 bytes from ip1.fai: icmp_seq=3303 ttl=254 time=195 ms 64 bytes from ip1.fai: icmp_seq=3304 ttl=254 time=240 ms 64 bytes from ip1.fai: icmp_seq=3305 ttl=254 time=185 ms
Le problème est résolu ! Même si Google Chrome continue à envoyer tout ce qu’il peut à Google, les ralentissements sur le réseau local ne devraient plus se faire sentir de façon aussi importante. Globalement, l’utilisation de l’upload ne va plus perturber toute la connexion internet, sans avoir aucun autre inconvénient puisqu’on a seulement limité la bande passante en upload a ce dont la ligne était capable de supporter.
Vous rencontrez un problème similaire ?
N’hésitez pas à me contacter si vous avez besoin d’aide pour un problème similaire, je serai ravie de vous aider à le résoudre !
le HTTPS, Let’s Encrypt, et les données personnelles
Tranquillement installé sur la place des Cocotiers ou à la terrasse d’un café, vous profitez du wifi gratuit pour surfer sur vos sites favoris. Vous pourriez même être chez vous ou au boulot que ça ne changerait pas grand chose. Internet est devenu tellement banal qu’on ne s’en rend pas forcément compte, mais surfer présente des risques.
De quels risques parle t’on?
Pour cet article, je vais me concentrer sur la divulgation de vos données personnelles, celles qu’on utilise tous les jours sur divers sites sans même y prêter attention : les identifiants et mots de passe en premier, mais aussi les recherches diverses, la liste des sites consultés, les liens cliqués… toutes ces informations, nous les distribuons tous de façon publique lorsqu’on se promène sur internet.
Lorsque vous êtes sur un réseau public, avoir accès à toutes ces informations en temps réel est relativement simple, cela ne demande pas de connaissances ou de matériel très poussé. Dans un environnement plus personnel, les techniques sont un peu différentes, mais le manque d’attention sur notre sécurité informatique est tellement important que ça ne demande pas grand chose de plus, et bien sûr sans jamais que vous ne soyez conscients que vous êtes « sur écoute ».
Le principe de base pour récupérer des informations est de se placer entre l’ordinateur (ou smartphone ou tablette) que l’on souhaite « écouter » et le site web qu’il consulte. C’est possible par exemple en remplaçant le wifi public par son propre wifi, ou en s’introduisant dans votre modem-routeur dont vous n’avez pas fait les dernières mises à jour.
Une fois que l’attaquant voit les données échangées entre vous et internet, il peut lire ce que vous envoyez et ce que vous recevez, mais il peut aussi modifier les échanges, et par exemple ajouter du code dans chacun des sites que vous visitez pour y récupérer vos informations.
Mais alors, que faire pour se protéger?
Bien sûr il faut être vigilant sur les mises à jour et sur les logiciels qu’on utilise, mais ça ne suffit pas toujours. Heureusement, des solutions existent depuis bien longtemps, et le HTTPS qui sécurise les échanges est en train de devenir un standard pour tous les sites internet. HTTP, c’est le protocole du web, c’est pour ça que les adresses des sites commencent toutes par « http:// » même si nos navigateurs le cachent la plupart du temps pour plus de lisibilité. Le HTTPS ajoute la Sécurité au protocole, grâce à un certificat SSL installé sur le serveur qui héberge le site web. Les navigateurs nous font savoir qu’on utilise le protocole HTTP sécurisé généralement avec un cadenas à côté de l’adresse qui commence par « https:// ».
Comment fonctionne le HTTPS ?
Le but du HTTPS est de s’assurer qu’on consulte bien le site web que l’on souhaite, et pas une version faite par un attaquant. Une fois que l’on s’est assuré de l’identité du serveur, le HTTPS s’occupe également de sécuriser les échanges pour que personne ne puisse les lire ou les modifier.
La connexion HTTPS se fait en plusieurs étapes :
- Le client (le navigateur de l’utilisateur) envoie un premier message (non chiffré) au serveur (le site web sécurisé) avec tout ce dont il aura besoin pour établir la connexion sécurisée, notamment les algorithmes de chiffrement qu’il connaît (les « cipher suites ») et la version de SSL qu’il est capable de supporter. Le serveur compare ces informations avec ce qu’il est lui-même capable de fournir, et fait le meilleur choix possible pour cet échange. Il envoie sa décision au client en clair (non chiffré).
- Le contact a été établi, le serveur va maintenant essayer de prouver au client qu’il est bien celui qu’il prétend être. Pour cela, il lui envoie sa « carte d’identité », qui est en fait son certificat SSL incluant le domaine correspondant, et une clé publique associée. Ce certificat a été édité par une autorité de certification, qui s’est assurée que celui qui a demandé la délivrance du certificat était bien propriétaire du domaine auquel il est attaché. Le client vérifie auprès de l’autorité que tout est en règle avant de poursuivre l’échange.
- Le client génère une clé de chiffrement aléatoire du type convenu à l’étape 1 (cipher suite), et il utilise la clé publique du certificat SSL du serveur pour la chiffrer et l’envoyer au serveur. De cette façon, seul le détendeur de la clé privée correspondante (le serveur) peut déchiffrer le message et obtenir la clé générée par le client. C’est une clé symétrique, qui sert à chiffrer et déchiffrer les messages.
A partir de là, tous les échanges seront chiffrés et déchiffrés grâce à cette clé, que seuls ce client et le serveur connaissent. Lorsque la session est terminée, la clé est détruite. S’ils doivent de nouveau communiquer, une nouvelle clé sera générée et communiquée de la même façon que la première fois.
Le gros point fort du HTTPS, c’est que même si un attaquant écoute les échanges en entier, il ne sera pas en mesure de les comprendre à partir du moment où le HTTPS les sécurise en les chiffrant !
Super, mais alors tous les sites utilisent le HTTPS ?
Malheureusement, non. Il y a plusieurs raisons à cela, la première est que jusqu’à il y a peu de temps, il fallait payer pour obtenir un certificat SSL (en moyenne 12 000F par an minimum), et passer par une procédure plutôt contraignante (du genre administrative) pour en obtenir un. La seconde est qu’il faut l’installer sur le serveur, effectuer la configuration, et la mettre à jour à chaque renouvellement du certificat, généralement tous les ans. Les éditeurs de sites web n’avaient pas toujours les moyens, le temps, et les compétences de s’en occuper malgré les bénéfices évidents.
Heureusement, depuis début 2016, un nouvel acteur est arrivé sur le marché des certificats SSL : Let’s Encrypt. C’est une autorité de certification un peu différente des autres : les certificats sont gratuits, ils ne durent pas 1 an mais 3 mois seulement (meilleure sécurité), et la procédure d’obtention est entièrement automatisée. Cela signifie que lorsqu’on a mis en place la configuration du HTTPS sur un site, il n’y a plus rien à faire, le renouvellement se fera automatiquement tous les 3 mois gratuitement !
Let’s Encrypt, c’est la révolution ?
Le concept a cartonné dès son lancement, et continue encore de convaincre de plus en plus de sites web de passer au HTTPS.
Plus de stats sur let’s Encrypt par là : https://letsencrypt.org/stats/
Le HTTPS est aujourd’hui un protocole éprouvé, on le connaît bien. Let’s Encrypt a apporté la dernière brique qui manquait pour qu’il devienne très rapidement le standard qu’on attend tous pour améliorer notre sécurité sur le web : la facilité et la gratuité. Google a déjà commencé à pénaliser les sites qui n’utilisent pas HTTPS dans ses résultats de recherche. Firefox, Chrome et d’autres navigateurs affichent désormais des messages d’alertes si un site non sécurisé vous demande vos identifiants, et vous incitent à quitter le site immédiatement.
Il n’y a donc plus d’excuse. Si vous avez un site web, vous devez à vos visiteurs de leur proposer le HTTPS !
Comment on met en place Let’s Encrypt ?
La communauté de développeurs du monde entier a bien travaillé depuis le lancement de Let’s Encrypt pour fournir à tous des solutions de déploiement simples. Il existe maintenant un outil très bien fait appelé « certbot » qui s’installe et se configure en quelques commandes. Par exemple, pour un serveur Apache sous Debian 9 :
Installation :
sudo apt install python-certbot-apache
Obtenir un certificat :
sudo certbot --apache
Le script va vous poser plusieurs questions, la procédure est très bien guidée. En quelques instants, vous avez un nouveau certificat. Pas plus compliqué !
En plus, l’installation a déjà automatiquement installé le cron qui permettra le renouvellement automatique. Il n’y a vraiment rien d’autre à faire.
Si vous n’êtes pas sous Debian 9, ou que vous utilisez un autre serveur web qu’Apache, le site certbot.eff.org propose plein d’autres tutoriels simples et bien faits.
En savoir plus
Il y aurait encore beaucoup de choses à dire sur le HTTPS, les autorités de certification, les clés symétriques et asymétriques, les autres risques qui ne sont pas pris en charge avec le HTTPS ou encore les techniques avancées de mise en place de Let’s Encrypt dans des environnements particuliers ou avec des besoins spécifiques. Si ça vous intéresse, on trouve beaucoup de ressources très intéressantes en ligne sur ces sujets, en voici quelques unes :
- Déployer Let’s Encrypt avec Certbot (en anglais)
- Un peu plus de détails sur le fonctionnement du HTTPS (en anglais)
- Explication de la cryptographie symétrique et asymétrique
- Plus d’informations sur les autorités de certification
Besoin d’aide ?
Vous avez besoin d’aide pour mettre en place Let’s Encrypt pour votre site web ? N’hésitez pas à me contacter !
Faire un site accessible uniquement en local
Lors du hackathon j’ai mis en place un environnement de développement accessible uniquement sur le réseau local utilisé par les membres de mon équipe. Les techniques que j’ai utilisées pour construire cet environnement peuvent être reproduites ou adaptées pour divers besoins, par exemple pour se créer un environnement de développement chez soi, proposer un intranet en entreprise, ou mettre à disposition un logiciel web de gestion sans risquer qu’il soit disponible sur internet.
Je vous propose dans cet article de découvrir comment mettre en place cette solution et de mieux comprendre comment elle fonctionne.
Le matériel et le réseau de base
Pour réaliser cette solution, il nous faudra au minimum :
- un routeur : il en a déjà sur la plupart des réseaux local, souvent intégré dans le modem. La plupart des routeurs (et à fortiori les modems-routeurs) proposent un serveur DHCP intégré, qui nous intéresse particulièrement pour cette config.
- un serveur : tout d’abord pour héberger le site, mais également pour un serveur DNS local. Comme dans le cas du hackathon, se serveur peut être un petit Raspberry Pi qui suffira largement pour un petit site local. Le site, la base de données et le serveur DNS peuvent aussi être répartis sur 2 ou 3 serveurs différents. Pour cet exemple, le serveur sera sous système Raspbian, qui est une distribution Linux dérivée de Debian spécifique au RaspBerry Pi, mais le principe fonctionne quel que soit le système d’exploitation. Tout au long de cet article, je pars du principe que nous avons un accès SSH root sur le serveur.
Le routeur étant déjà en place et faisant office de passerelle pour tout le réseau, il suffit de brancher le serveur sur le réseau. Pour lui assigner une adresse IP, 2 possibilités :
- soit il récupère une adresse IP grâce au DHCP, et il faut ensuite s’assurer que ce sera toujours cette IP qui lui sera attribuée. Cela se fait dans la configuration du serveur DHCP en attribuant un « bail fixe » à l’adresse mac du serveur.
- soit on configure le serveur en IP fixe, en s’assurant que l’IP choisie est bien en dehors de la plage d’IP du serveur DHCP.
Le schéma du réseau peut donc être celui-ci (les adresses IP sont là pour illustrer l’exemple) :
La configuration
Pour l’instant, tous les ordinateurs du réseau utilisent le routeur comme passerelle vers internet. Le serveur DHCP leur a distribué les serveurs DNS du fournisseur d’accès à internet ou ceux qui lui ont été spécifiés. Le serveur est connecté au réseau et a accès à internet, mais il ne propose aucun service et personne ne l’utilise.
Un serveur DNS récursif avec zone locale
La première étape est d’installer un serveur DNS pour notre réseau local. Il existe 2 types de serveurs DNS :
- les serveurs DNS maîtres (authoritative), qui sont la source d’information DNS pour un domaine donné. Ce sont eux qui détiennent la liste des enregistrements DNS et communiquent la ou les adresses IP correspondant à ce domaine ou sous-domaine à ceux qui le souhaitent.
- les serveurs DNS récursifs (resolver), qui se chargent de trouver l’adresse IP correspondant à un nom de domaine quand on leur demande. Ils sont généralement restreints à certains utilisateurs pour éviter d’avoir un nombre trop important de requêtes à gérer et d’être vulnérable aux attaques. Les serveurs DNS fournis par les FAI sont de ce type par exemple, e ne sont accessibles qu’à leurs abonnés. Google fournit par contre des serveurs DNS ouverts à tous, aux adresses facile à retenir : 8.8.8.8 et 8.8.4.4 en IPv4, 2001:4860:4860::8888 et 2001:4860:4860::8844 en IPv6. Il faut cependant garder à l’esprit qu’en utilisant les services DNS Google, ou de n’importe quel autre fournisseur d’ailleurs, vous donnez à ce fournisseur la liste complète des sites et services que vous consultez en temps réel. Ce sont des informations personnelles sensibles qui peuvent être utilisées dans d’autres buts que la résolution DNS, il faut rester prudent sur la divulgation de ces informations sur Internet.
Ce que l’on souhaite faire ici, c’est de fournir un serveur DNS récursif aux utilisateurs du réseau, mais qui soit également serveur DNS maître pour notre domaine local, qui sera « monsite.nc » pour cet exemple. Le domaine n’a pas besoin d’être enregistré, d’exister réellement, ni même de correspondre à une extension existante : on peut choisir de servir « local.monentreprise » ou « intranet.local » ou bien encore « monsite.caledonie ». Faites-vous plaisir, c’est du local, vous faites ce que vous voulez !
Installation de Bind9
Bind est le serveur DNS le plus utilisé sur internet (de loin !). Il est robuste, efficace, fiable, et existe depuis presque autant de temps qu’internet lui même : c’est un standard. On va utiliser sa dernière version stable : bind9
apt install bind9
Rien de plus, c’est fait 🙂
Configuration en serveur DNS récursif
La configuration se trouve dans /etc/bind, et on va dire à Bind de se comporter en serveur récursif dans le fichier /etc/bind/named.conf.options :
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
recursion yes; // c'est cette directive qui dit a Bind de se comporter en serveur récursif
allow-query { monreseau; }; // et celle-ci restreint son accès (voir plus bas "acl monreseau")
forwarders {
// les serveurs DNS listés ici sont ceux à qui Bind ira demander les informations qu'ils ne connaît pas encore
8.8.8.8; // indiquez ici les serveurs DNS que utilisés actuellement, ceux de votre FAI par exemple
8.8.4.4; // ceux-ci sont les serveurs DNS publics de Google, qui fonctionnent aussi
};
};
acl monreseau {
192.168.1.0/24; // indiquez ici le réseau qui est autorisé à utiliser ce serveur DNS
localhost;
localnets;
};
Enregistrez la config, et relancez bind :
rndc reload
On peut maintenant tester que Bind répond de façon récursive avec le petit utilitaire « dig »:
$ dig @192.168.1.2 1012.nc ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.1.2 1012.nc ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62272 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;1012.nc. IN A ;; ANSWER SECTION: 1012.nc. 6015 IN A 202.87.129.41 ;; Query time: 166 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Dec 10 11:49:47 +11 2017 ;; MSG SIZE rcvd: 52
C’est la présence de la réponse (« ANSWER SECTION ») qui nous indique que ca fonctionne. On aurait aussi pu avoir un réponse plus courte en indiquant l’option « +short » a dig :
$ dig @8.8.8.8 +short 1012.nc 202.87.129.41
On obtient bien une adresse IP, alors qu’il n’y aurait rien si ça ne fonctionnait pas.
Ajout d’une zone locale
Maintenant que le serveur répond aux requêtes, il faut lui indiquer qu’il est maître pour notre zone locale « monsite.nc ». Pour lui indiquer quelles zones il gère désormais, on va les spécifier dans le ficier /etc/bind/named.conf.local :
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "monsite.nc" {
type master;
file "/etc/bind/zones/db.monsite.nc"; # zone file path
};
zone "168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.168.192";
};
En plus de la zone « monsite.nc », on a ajouté une zone pour pouvoir indiquer les reverse DNS sur le réseau local. Les reverse DNS font l’inverse des DNS classiques :
- les requêtes DNS classiques donnent la correspondance nom de domaine -> adresse IP
- les reverse DNS donnent la correspondance adresse IP -> nom de domaine
Ce n’est pas indispensable, mais c’est plus propre.
On crée ensuite le dossier zones s’il n’existe pas :
mkdir /etc/bind/zones
et on va créer le fichier de zone /etc/bind/zones/db.monsite.nc :
$TTL 604800 @ IN SOA monsite.nc. admin.monsite.nc. ( 4 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns1.monsite.nc. ns1 IN A 192.168.1.2 ; l'adresse de notre serveur DNS @ IN A 192.168.1.2 ; l'adresse IP de notre futur serveur web, le même que le serveur DNS ici www IN CNAME troc-oleti.nc.
Et pour la zone reverse :
$TTL 604800 @ IN SOA monsite.nc. admin.monsite.nc. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns1.troc-oleti.nc. 2.1 IN PTR monsite.nc
On enregistre tout, et on relance bind :
rndc reload
Et voilà, la config DNS est terminée !
Distribution du serveur DNS par le serveur DHCP
Le serveur DNS est fonctionnel et configuré selon nos besoins, il ne reste plus qu’à l’utiliser. Plutôt que de le configurer à la main sur tous les appareils du réseau, on va le distribuer automatiquement grâce au DHCP. Suivant le modèle de votre routeur, la procédure sera différente, mais le principe reste le même :
- on se connecte à l’interface d’administration du routeur (généralement http://192.168.1.1/)
- on cherche la configuration du serveur DHCP
- dans cette configuration, on va pouvoir indiquer les serveurs DNS qu’on souhaite distribuer. Par défaut, il est possible que le serveur DNS soit le routeur lui-même, ou bien que l’on récupère automatiquement les serveurs DNS du FAI pour les distribuer sur le réseau. Dans tous les cas, il faudra indiquer que le seul serveur DNS à distribuer en DHCP est celui de notre serveur à l’IP 192.168.1.2
- on enregistre la configuration pour qu’elle soit bien appliquée
Les appareils sur le réseau n’auront pas immédiatement cette nouvelle configuration. Il faudra soit attendre le renouvellement du bail DHCP (le délai peut être variable suivant votre config), ou alors déconnecter puis reconnecter chaque appareil pour qu’il reprenne contact avec le serveur DHCP qui lui indiquera le nouveau serveur DNS.
Une fois que c’est fait, on dit avoir accès à internet comme avant sur chaque appareil, mais en plus, la zone locale « monsite.nc » doit exister ! On peut s’en assurer avec un dig :
dig +short 1012.nc 192.168.1.2
Installation du site web
L’étape suivant est d’installer le site web sur le serveur. Pour cet exemple, le site est sous WordPress, et a donc besoin d’un serveur web (Apache), de PHP et de MySQL (plus exactement MariaDB). Sous Debian (et donc Raspbian), Apache, PHP et MariaDB peuvent s’installer très simplement en une commande :
apt install phpmyadmin mariadb-server
En effet, cela fonctionne car le système de gestion des paquets sous Debian inclut un puissant système de dépendances. PHPMyAdmin (par ailleurs bien utile pour gérer les bases de données depuis une interface web) a les mêmes besoins que notre site web, le système de dépendance APT va donc installer et configurer tous les logiciels nécessaires et les faire fonctionner ensemble.
Une fois la commande exécutée jusqu’au bout (il faudra répondre à quelques questions de configuration simples), on peut d’ores et déjà vérifier que tout fonctionne en accédant à PHPMyAdmin à l’adresse :
http://192.168.1.2/phpmyadmin
Configuration de la base de données
Pour la suite, il va falloir créer un nouvel utilisateur dans MariaDB, avec une nouvelle base de données, qui sera utilisée par WordPress. Par défaut, il n’est pas possible de se connecter en root sans mot de passe avec PHPMyAdmin, on va donc le faire en ligne de commande :
Depuis un accès SSH, connexion à la base de données :
mysql -u root
Création de la base de données :
CREATE DATABASE mabase;
Création de l’utilisateur avec les droits en lecture et écriture sur la base :
GRANT ALL ON mabase.* TO monsite@localhost IDENTIFIED BY 'unsupermotdepasse';
On sort de la console MySQL (CTRL+D ou exit), et on teste le nouvel accès :
mysql -u monsite -punsupermotdepasse mabase
Si on peut se connecter, c’est que tout s’est bien passé ! Sinon un message d’erreur indiquera le problème.
Configuration du serveur web Apache
Apache est installé, il faut maintenant lui dire qu’il va devoir servir un nouveau site web. On va utiliser les VHOSTs pour pouvoir en héberger sur le même serveur. Pour créer un nouveau vhost, il faut écrire son fichier de configuration dans /etc/apache2/sites-available/monsite.conf :
<VirtualHost *:80> ServerAdmin contact@monsite.nc ServerName www.monsite.nc DocumentRoot /var/www/www.monsite.nc <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/www.monsite.nc> Options Indexes FollowSymLinks MultiViews AllowOverride All </Directory> ErrorLog /var/log/apache2/www.monsite.nc-error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/www.monsite.nc-access.log combined </VirtualHost>
Dans cet exemple, nous avons décidé que les fichiers se trouveraient dans /var/www/www.monsite.nc, mais on aurait très bien pu décider de les placer ailleurs, par exemple sur une partition séparée montée dans /srv. Pour qu’Apache puisse accepter cette configuration, il faut que le DocumentRoot existe, on va donc le créer et lui donner les droits appropriés pour qu’Apache puisse lire dedans :
mkdir /var/www/www.monsite.nc chown www-data:www-data /var/www.monsite.nc
Si on avait voulu que l’url http://monsite.nc corresponde au même site que http://www.monsite.nc, on aurait pu ajouter « ServerAlias monsite.nc » juste en dessous du ServerName.
Si on souhaite héberger un 2ème site sur ce serveur, on peut tout à fait copier ce fichier en modifiant au minimum le ServerName et le DocumenRoot. Il est également utile de modifier les fichiers de logs pour séparer les stats de visite et mieux debugger en cas de problème ! Attention cependant à e que les DNS sit également configurés pour ce 2ème site.
Une fois créé, il faut activer la configuration :
a2ensite monsite.conf
puis indiquer à apache de recharger sa configuration :
service apache2 reload
L’hébergement est prêt !
Installation de WordPress
On a dit a apache que les fichiers se trouvaient dans /var/www/www.monsite.nc, c’est donc à cet endroit qu’on va devoir installer WordPress. Pour télécharger l’archive d’installation en ligne de commande (remplacer l’adresse avec celle de la dernière version de WordPress que vous trouverez ici, prenez l’archive tar.gz un peu moins volumineuse que l’archive zip) :
cd /tmp # placez-vous dans le répertoire /tmp du serveur wget https://fr.wordpress.org/wordpress-4.9.1-fr_FR.tar.gz # téléchargement de l'archive WordPress tar xvzf wordpress-4.9.1-fr_FR.tar.gz # extraction de l'archive, dans /tmp mv wordpress/* /var/www/monsite.nc/. # on place les fichiers extraits là ou Apache les attend chown -R www-data:www-data /var/www.monsite.nc/* # on donne les droits à Apache
Les fichiers sont prêts, on peut désormais se rendre à l’URL du futur site pour poursuivre l’installation :
http://www.monsite.nc
Il suffit ensuite de suivre la procédure proposée par WordPress. Il faudra lui donner :
- l’adresse du serveur de base de données (« hôte ») : localhost ou 127.0.0.1 (port 3306) si elle se trouve sur le même serveur comme pour cet exemple
- l’utilisateur de la base de données et le mot de passe créé juste avant : « monsite » et « unsupermotdepasse » pour cet exemple
- le nom de la base de données créée : « mabase » pour cet exemple
- on peut garder les valeurs par défaut pour le reste
Voilà, notre WordPress local est installé et fonctionnel ! Il se trouve à l’adresse prévue :
http://www.monsite.nc
et l’interface d’administration à cette adresse :
http://www.monsite.nc/wp-admin
Les identifiants pour se connecter sont ceux que l’on a donnés lors de la procédure web d’installation de WordPress.
Comme le serveur web n’est pas ouvert sur l’extérieur, et que le domaine n’existe que sur le réseau local, le site n’est accessible que sur ce réseau. De plus, il n’est pas vulnérable aux attaques directes sur Internet, les personnes hors du réseau ne peuvent même pas savoir qu’il existe !
Pour aller plus loin
Cette configuration couvre la base de la solution, il est bien entendu possible de la rendre plus robuste ou plus adaptée à vos besoins, avec par exemple :
- l’ajout de HTTPS sur les services locaux
- l’ajout d’un second serveur DNS pour mieux tolérer les pannes
- d’autres services sur ce nom de domaine, sur le même serveur ou non
Si vous souhaitez de l’aide pour réaliser une configuration similaire ou pour d’autres solutions linux, n’hésitez pas à me contacter !
Le hackathon et le projet Oleti
Le week-end des 25 et 26 novembre 2017 s’est déroulé le 1er hackathon de Nouvelle-Calédonie, organisé à la bibliothèque universitaire de Nouville par l’Observatoire Numérique. J’ai participé avec grand plaisir à cet événement, avec un projet qui me tenait vraiment à cœur. Nous avons constitué l’équipe Oleti, composée de Ludovic de Mon Coach Webmarketing, Victor développeur à la Province des îles, et de moi-même, pour y consacrer les 30 heures de l’événement avec l’objectif de réaliser un projet fonctionnel dès la fin du week-end.
La présentation du projet Oleti lors de la soirée de lancement du Hackathon
La genèse du projet
J’avais entendu parler il y a déjà longtemps des systèmes d’échange locaux, généralement portés par des associations dans diverses villes en France métropolitaine ou ailleurs dans le monde. Le concept m’avait beaucoup plu, mais je n’étais pas très emballée par le fonctionnement : l’adhésion à une association, la gestion d’un compte sur papier, les petites annonces affichées dans un local ou sur dans un catalogue papier… je n’ai de toutes façons jamais eu l’occasion de vivre assez proche d’une de ces initiatives pour l’expérimenter moi-même.
Fonctionnement d’un système d’échange local
A Nouméa cependant, il existe de nombreuses associations qui évoluent autour de cette même idée de partage, de solidarité et de mieux-vivre. Je m’investis notamment dans le Repair Café qui propose ponctuellement à tous de venir réparer ses objets en panne ou abîmés avec l’aide de réparateurs bénévoles. Je rencontre régulièrement des personnes qui souhaitent vivement aider les autres mais ne savent pas forcément comment s’y prendre, d’autres qui pensent n’avoir que peu de choses à apporter aux autres et qui se découvrent des talents de réparateur ou un intérêt à apprendre avec les autres.
J’ai pu expérimenter les bienfaits d’aider les autres, notamment lors des moments difficiles de la vie ou le sort semble s’acharner sur nous. Aider les autres, c’est aussi s’aider soi-même, se sentir utile apporte un sentiment de fierté et une reconnaissance qu’on n’a pas toujours l’occasion d’obtenir dans nos vies. Le monde professionnel n’est pas toujours la solution, et il n’est pas non plus accessible à tous. L’argent est souvent un frein pour obtenir un service. Et pourtant les calédoniens trouvent déjà des solutions à ces contraintes : le troc fait partie de la culture locale, que ce soit de fruits et légumes, de poisson pêché ou de services, nous y avons tous recours lorsque l’occasion se présente.
Lorsque j’ai commencé à réfléchir à un projet pour ce Hackathon, ce sont toutes ces expériences qui m’ont animée : pourquoi ne pas construire une plateforme pour faciliter ces échanges ? Donner l’occasion à chacun d’apporter son aide aux autres, de se sentir utile, et d’améliorer sa qualité de vie sans dépenser d’argent ? Tout ça est déjà possible, les solutions existent déjà, il suffit d’un espace commun pour faciliter les échanges ! Grâce à l’aide et aux discussions avec Ludovic de Mon Coach Webmarketing, le projet Oleti était né dans nos têtes, quelques jours à peine avant le début de la soirée de lancement du Hackathon.
L’idée de la monnaie virtuelle est arrivée dans un second temps, comme une solution pour répondre à cette question : que faire si j’aimerais obtenir de l’aide de quelqu’un qui n’a pas besoin de mon aide ? Cette ouverture sur la monnaie a permis de pousser le concept encore plus loin, mais a également soulevé de nombreuses questions ! Que ce soit sur le fonctionnement, sur le plan économique de la gestion d’une monnaie, sur la valorisation des services, sur la possibilité d’intégrer les échanges de biens… certaines de ces questions ne sont d’ailleurs toujours pas résolues aujourd’hui :p
Les choix techniques
Une fois le projet défini, ce sont les choix techniques pour parvenir à notre objectif qui ont été prépondérants. L’objectif technique était de réaliser un site fonctionnel, j’ai donc choisi de me servir de ce qui existait déjà plutôt que de partir de zéro, dans l’idée de gagner du temps et de bénéficier de l’expérience d’autres développeurs utilisant des fonctionnalités similaires.
Bien sûr, il était hors de question d’utiliser autre chose que des outils libres pour un tel projet ! WordPress est aujourd’hui leader dans les logiciels de gestion de contenu, et propose de nombreuses fonctionnalités via des plugins. Nos besoins pour ce projet étaient similaires à un site de petites annonces, ou à un site e-commerce, bien que l’un et l’autre nécessitaient des adaptations pour correspondre aux besoins. Après avoir testé plusieurs solutions, mon choix s’est donc porté sur WordPress avec divers plugins notamment e-commerce et marketplace, de gestion de points pour la monnaie, et de gestion des utilisateurs.
Le plus gros du travail serait de sélectionner les meilleurs, de les tester, de les configurer, et de développer les adaptations et parties manquantes. C’est un travail qui demande généralement de tout casser pour tout refaire plusieurs fois, et il était donc impossible que nous puissions travailler à plusieurs sur la même installation de WordPress.
Je ne savais pas comment allait être l’accès internet fourni lors du hackathon. Notre solution reposant entièrement sur un serveur web, il me paraissait risqué de compter sur un serveur distant, même en Nouvelle-Calédonie : si l’accès internet n’était pas assez stable et rapide, nous aurions été fortement ralenti à cause de problèmes techniques. J’ai donc préféré opter pour un serveur web local, sur un petit raspberry facile à transporter. J’ai pu y installer facilement une distribution Raspbian, un serveur web Apache, une base de donnée MariaDB, et php7 pour faire tourner WordPress. J’ai également créé plusieurs environnement de travail (8 en tout), pour que chaque membre de l’équipe ait sa propre version de WordPress qu’il pourrait casser sans perturber les autres, et des versions d’intégration sur laquelle les différents développements étaient regroupés pour construire une version finale propre.
Afin de faciliter la gestion de ces environnements, j’ai créé 2 petits scripts :
- le premier pour effectuer des sauvegardes des environnements sur un disque dur externe connecté en USB au Raspberry. Ce script pouvait être lancé à la main avant une grosse modification par exemple, et également lancé automatiquement chaque heure pour tous les environnements, afin de s’assurer de perdre le moins de travail possible en cas d’erreur de manipulation ou de problème technique.
$ cat wpbackup.sh #!/bin/bash if [ "$1" == "" ]; then liste="www www1 www2 www3 www4 am bruce ludo victor" else liste=$1 fi for i in $liste; do # backup da=`date "+%F@%H:%M:%S"` mkdir -p /srv/backup/$da-$i rsync -a /var/www/$i.troc-oleti.nc /srv/backup/$da-$i mysqldump $i > /srv/backup/$da-$i/$i.sql done;
- le second pour copier un environnement sur un autre (par exemple remettre un environnement de base, ou repartir de la version finale actuelle pour poursuivre le développement). En plus de copier les fichiers et de répliquer la base MariaDB, le script se charge d’effectuer automatiquement les adaptations de chemins dans les fichiers, d’URL, de configuration des accès à la base de donnée, et d’effectuer un backup grâce au premier script, le tout en quelques secondes.
$ cat wpcopy.sh
#!/bin/bash
if [ "$1" == "" ]; then
echo "source?? (arg 1)"
exit
fi
if [ "$2" == "" ]; then
echo "destination?? (arg 2)"
exit
fi
# backup
da=`date "+%F@%H:%M:%S"`
mkdir -p /srv/backup/$da-$2
mv /var/www/$2.troc-oleti.nc /srv/backup/$da-$2/.
mysqldump $2 > /srv/backup/$da-$2/$2.sql
# sql
mysql -e "DROP DATABASE $2"
mysql -e "CREATE DATABASE $2"
mysqldump $1 |mysql $2
mysql $2 -e "UPDATE wp_options SET option_value='http://$2.troc-oleti.nc' WHERE option_name='siteurl';"
mysql $2 -e "UPDATE wp_options SET option_value='http://$2.troc-oleti.nc' WHERE option_name='home';"
# copie
mkdir /var/www/$2.troc-oleti.nc/
rsync -a /var/www/$1.troc-oleti.nc/* /var/www/$2.troc-oleti.nc/.
sed -i "s/define('DB_NAME', '$1');/define('DB_NAME', '$2');/g" /var/www/$2.troc-oleti.nc/wp-config.php
chown www-data:www-data -R /var/www/$2.troc-oleti.nc
Toujours dans l’idée de nous garantir un minimum de soucis techniques et une autonomie maximale, il m’a semblé judicieux de créer notre propre réseau local. J’ai donc mis en place :
- un routeur, pouvant se connecter au réseau du hackathon en wifi ou en ethernet et fournissant un réseau privé avec DHCP à nos ordinateurs et au Raspberry, en ethernet et en Wifi privé sur un réseau caché
- un switch pour avoir assez de prises réseau
- un serveur DNS sur le Raspberry pour accéder aux divers environnements de travail de façon totalement locale. Le serveur DNS était configuré pour servir les requêtes récursives demandées par le réseau local et également de façon autoritaire pour la zone « troc-oleti.nc » correspondant à nos environnements de travail. Ce serveur DNS était celui distribué par le serveur DHCP pour qu’il soit utilisé par défaut sans aucune configuration sur les ordinateurs de travail.
Ce choix nous procurait également plusieurs avantages :
- en cas de difficulté à capter le wifi du hackathon, nous avions notre propre accès wifi, et même un accès câblé plu stable.
- même en cas de coupure de l’accès internet nous pouvions toujours travailler en local. Il était même possible de partager une connexion 3G ou 4G via un smartphone pour servir d’accès principal au réseau local
- Tous nos outils de travail étaient protégés du réseau public derrière le routeur : aucune de nos données n’a pu être accédée par d’autres utilisateurs en dehors de notre équipe. Sur un réseau public peuplé d’informaticiens, il vaut mieux être prudent :p
C’est donc avec tout ce petit matériel que nous nous sommes rendus à la bibliothèque universitaire, et que nous avons pu mener à bien notre projet tout le week-end !
Le matériel utilisé lors du hackathon
L’organisation du projet
L’objectif étant d’avoir une plateforme fonctionnelle au minimum, j’ai commencé par liste les fonctionnalités attendues du projet et à les répartir dans différentes versions du projet. J’ai utilisé Trello pour gérer cette organisation et communiquer l’état d’avancement avec toute l’équipe durant le week-end.
L’organisation du projet avec Trello
Les fonctionnalités minimales indispensables au projet (la gestion des utilisateurs, la possibilité de créer des annonces de service, la gestion du solde d’Oletis et des échanges de monnaie contre des services) constituaient la v1, que j’espérais pouvoir réaliser pendant le hackathon.
La v2 ajoutait quelques fonctionnalités bien pratiques, et rendait l’utilisation du site plus intuitif et agréable, comme l’ajout de catégories ou la localisation des annonces et surtout la création de badges de reconnaissance basés sur l’implication des utilisateurs dans l’entraide. J’espérais pouvoir la commencer sérieusement durant le hackathon.
La v3 prévoyait des évolutions très intéressantes comme l’évaluation mutuelle des utilisateurs après un échange, la géolocalisation des utilisateurs pour proposer des annonces proches, et un système de dons d’Oletis entre utilisateurs.
La v4 allait beaucoup plus loin, avec la création d’un tiers de confiance lors d’un litige sur une transaction, une réflexion sur les façons d’échanger des Oletis hors ligne, et la transition de l’Oleti vers la crypto-monnaie pour sécuriser les échanges.
Je n’espérais pas vraiment arriver à la v3 et encore moins à la v4 lors du hackathon, mais les fonctionnalités listées font toujours partie de la feuille de route du projet à long terme.
En plein travail durant la nuit…
Le résultat
Le dimanche midi, nous avions une v1 fonctionnelle, avec quelques fonctionnalités de la v2. Certes pas aussi finie que ce que j’aurais espéré, mais tout de même utilisable ! Je l’ai mise en ligne avant la présentation du projet devant le jury, pour permettre à tous de la tester.
Le projet n’a malheureusement pas retenu l’attention du jury et n’a pas été primé, probablement car le projet était un peu en dehors des critères du hackathon : nous n’avons pas utilisé les jeux de données fournies spécialement lors de l’événement. Le public et les différentes personnes rencontrées ont cependant été séduites par l’idée et souhaitent vivement voir troc-oleti continuer son chemin !
C’est d’ailleurs notre souhait également, et depuis la fin du hackathon, une première mise à jour a permis de rendre l’interface plus simple et conviviale, conformément à ce que j’aurais souhaité pouvoir faire initialement lors du week-end !
La page d’accueil du site Troc-Oleti
Le projet suit sa route, et désormais libéré des contraintes de temps et de moyens du hackathon, plusieurs questions se posent quant aux solutions techniques choisies :
- la solution WordPress est-elle la meilleure sur le long terme ? Est-ce qu’un développement complet ne permettrait pas plus de souplesse et de simplicité de développement ?
- comment inclure d’autres développeurs ? C’est un projet qui se prête bien à un développement collaboratif, plusieurs personnes se sont déjà montrées intéressées pour apporter leur aide !
Des questions toujours en suspend qui trouveront probablement une réponse avec le temps !
Plus d’infos
Les noms de domaine en Nouvelle-Calédonie
Quand on ne connaît pas bien comment internet fonctionne, le système des noms de domaine peut paraître un peu obscur. Les définitions que l’on trouve n’aident pas vraiment à comprendre le principe, et pourtant, c’est un système relativement simple que tout le monde utilise sans même s’en rendre compte.
Un nom de domaine c’est quoi ? A quoi ça sert ?
Le nom de domaine c’est l’adresse d’un site internet. Dans votre navigateur, il apparaît dans la barre blanche en haut, qu’on appelle barre d’URL. Quand vous allez sur Google par exemple le nom de domaine c’est « www.google.fr », pour le tourisme sur les îles Loyautés ça sera « iles-loyaute.com ».
Internet fonctionne à la base avec des adresses IP, des suites de chiffres qu’on aurait du mal à retenir telles quelles. C’est comme si vous deviez retenir les coordonnées GPS des lieux pour vous y rendre plutôt que des adresses avec les numéros et le nom des rues. Pour reprendre l’exemple ci-dessus, l’adresse IP derrière « iles-loyaute.com » est « 202.22.232.132 ». A la place des adresses IP, on a donc inventé les noms de domaine, faciles à retenir, et créé un annuaire des correspondances entre les noms de domaine et les adresses IP : c’est ce qu’on appelle les DNS.
Du coup, pour accéder à un site internet, on indique son nom de domaine. C’est le navigateur et le système d’exploitation qui fait la traduction en adresse IP et va chercher le contenu du site à cette adresse : c’est transparent pour vous !
Comment choisir un nom de domaine pour mon site en Nouvelle-Calédonie ?
Choisir un nom de domaine, c’est un peu comme choisir un nom de société : il faut se poser plein de questions. D’abord, il faut qu’il soit compréhensible, lisible, qu’on n’ait pas de doutes sur la façon de l’écrire quand on va le donner à l’oral, que le nom donne une bonne idée du contenu du site… mais en plus de toutes les questions de cohérence, il va falloir faire quelques choix techniques. Le premier va être l’extension, qui est a dernière partie du nom de domaine. Pour iles-loyaute.com c’est le « .com », pour le site de la ville de Nouméa noumea.nc, c’est « .nc ». Il existe en réalité des centaines, voire des milliers d’extensions différentes, et si certaines sont censées indiquer que le site concerne un pays en particulier (comme le .nc pour la Nouvelle-Calédonie), ça n’est pas une obligation. Il peut exister des sites en .nc qui ne concernent pas la Nouvelle-Calédonie et des sites en .com, .net, .biz, .fr, ou .cequevousvoulez qui concernent la Nouvelle-Calédonie. C’est donc une indication, mais il ne faut pas s’y fier strictement!
Pour un site destiné aux calédoniens, vous pouvez évidemment choisir le .nc, ou une autre extension selon celle qui vous plaît. A titre d’exemple, l’office du tourisme de Nouvelle-Calédonie a choisi le .travel pour son site nouvellecaledonie.travel, tandis que le site Calédosphère bien connu des calédoniens a lui choisi le .com, sans que ça n’ait d’impact sur le public visé.
Un des critères indispensable pour le choix de votre nom de domaine est qu’il soit… disponible ! Si quelqu’un utilise déjà le nom de domaine que vous vouliez, il va falloir lui envoyer une demande de transfert et lui racheter s’il a envie de vous le vendre, ou alors en trouver un autre. Pour savoir si un nom de domaine est déjà réservé, on fait une requête « WHOIS » sur le nom de domaine. Vous pouvez par exemple utiliser ce site pour obtenir les informations concernant un domaine : https://www.namebay.com/whois . S’il existe un résultat, c’est que le domaine est déjà enregistré, sinon c’est qu’il est disponible et que vous pouvez l’acheter.
Comment acheter un nom de domaine pour mon site ? Combien ça coûte ?
Il faut d’abord trouver un fournisseur de nom de domaine qui propose l’extension que vous avez choisie. Pour une extension mondiale classique, je vous conseille OVH ou Gandi au choix, les 2 sont très sérieux avec des prix attractifs. Pour un domaine en .nc, il vaut mieux passer soit par un revendeur local, soit directement par l’OPT qui gère cette extension grâce à sa branche Domaine.nc. Tout se fait en ligne sur le site internet dédié : domaine.nc.
Quand on réserve un nom de domaine, on le fait au minimum pour 1 an (2 ans minimum pour un .nc), et on peut même le faire pour plusieurs années à la fois. Lorsqu’il arrivera à expiration, il faudra le renouveler, c’est pourquoi il est très important d’indiquer une adresse e-mail de contact qui sera toujours consultée régulièrement même plusieurs années après.
Le prix varie donc en fonction de la durée de réservation. Pour un .com, .fr ou .net chez OVH, on est aux alentours de 10€ par an (1200F environ), et pour un .nc cela coûte 2940F pour 2 ans, soit 1470F par an. Les prix sont assez similaires pour ces extensions, mais il en existe de beaucoup plus cher, comme par exemple le .tickets qui vaut 459€ par an (environ 55 000F) ou le .auto à 2299€ par an (environ 275 000F)…
Comment je fais pour que mon site soit accessible avec mon nom de domaine ?
Une fois propriétaire de votre nom de domaine, il faut le configurer ! Chez OVH ou Gandi, la gestion des DNS, indispensable pour utiliser votre nom de domaine, est incluse, vous pouvez donc « faire pointer » votre domaine directement vers l’adresse IP de votre hébergement. Chez domaine.nc en revanche, il n’y a pas de gestion DNS, il faut donc trouver le service ailleurs. Certains fournisseurs d’accès à internet et fournisseurs de services internet proposent cette option, généralement à des tarifs dérisoires (par exemple 105F/mois). Renseignez-vous avant l’achat du domaine pour ne pas avoir de surprises!
Pour vous tout ça c’est du charabia, vous voulez juste que ça marche sans vous préoccuper des détails techniques? Ça tombe bien, je suis là pour vous guider et vous simplifier la vie numérique ! 😉
Hébergement web en Nouvelle-Calédonie
L’hébergement web pour les calédoniens est un sujet compliqué : l’offre existe mais est difficilement lisible pour les non-initiés. Voici quelques éléments qui peuvent pour aider à faire le bon choix.
C’est quoi un hébergement web ?
Un hébergement web, c’est l’endroit où est stocké un site internet pour qu’on puisse le consulter. Concrètement, c’est un bout de disque dur dans un ordinateur connecté à internet. D’un côté, le propriétaire du site envoie des fichiers dans cet espace de stockage (via FTP généralement), et de l’autre le serveur web les met à disposition des visiteurs. Il existe plusieurs types d’hébergement avec des caractéristiques très différentes, mais le principe reste toujours le même : on met à disposition des fichiers sur internet.
Qui a besoin d’un hébergement internet, et pourquoi?
Toute personne qui souhaite avoir un site internet a besoin d’un hébergement pour son site. Parfois, l’hébergement du site est inclus dans le package de création du site internet et n’apparaît pas directement sur la facture. Parfois aussi on n’y a pas accès directement, mais il existe forcément.
Comment choisir un bon hébergeur quand on est en Nouvelle-Calédonie?
La première question à se poser, c’est de savoir ce qu’on va y mettre dedans. On choisit un hébergement internet en priorité en fonction du site qui sera hébergé et du public visé ! En Nouvelle-Calédonie, nous avons une contrainte très spécifique : nous sommes reliés au reste du monde grâce au câble sous-marin Gondwana-1 qui va de Nouméa à Sydney. C’est important de le prendre en compte, car cela a des conséquences directes sur les performances du site en fonction de l’endroit où il sera hébergé. Il existe des hébergements en Nouvelle-Calédonie, d’autres en Australie et d’autres en France métropolitaine, en Europe, et sur tous les autres continents. L’idéal est toujours d’être au plus près de vos visiteurs, car le site sera plus rapide et donnera moins l’impression de ramer, même si les visiteurs n’ont pas une connexion très performante.
Si le site est destiné aux calédoniens, le mieux est de trouver un hébergement en Nouvelle-Calédonie. Attention cependant, une entreprise calédonienne peut tout à fait proposer un hébergement en France ou ailleurs, il faut bien se renseigner. Les prix étant assez élevés pour les hébergements purement calédoniens, on peut aussi envisager de trouver un hébergement avec un bon rapport qualité prix en Australie, idéalement à Sydney pour être juste à l’autre bout du câble sous-marin.
Si par contre le site est destiné au reste du monde, il n’y a aucun intérêt à être hébergé en Nouvelle-Calédonie ! Il vaut mieux le placer soit au plus près géographiquement, ou alors dans un datacenter disposant de très bonnes connexions pour desservir rapidement le monde entier. Il en existe plusieurs, notamment ceux d’OVH en France et ailleurs dans le monde qui sont généralement de très bon choix dans ce cas là.
Combien ça coûte, et à quoi correspond ce prix ?
On trouve des hébergements gratuits et des hébergements coûtant plusieurs dizaines de milliers de francs par mois. La différence se trouve dans les ressources mises à disposition (l’espace disponible, la mémoire et le temps de processeur alloués, la vitesse de connexion réseau ou la limite d’utilisation de la bande passante…), les caractéristiques techniques de l’hébergement (le système d’exploitation, les logiciels utilisés pour fournir le service, le type de base de données s’il y en a…), et les services inclus (sauvegardes, garanties de service, support technique…).
Mais le prix dépend aussi de l’endroit où se trouve l’hébergement : en effet, un hébergeur utilise 3 matières premières principales :
- le matériel informatique : s’il est difficile ou plus cher de se fournir en matériel et en pièces de rechange, l’hébergement sera forcément plus cher. En Nouvelle-Calédonie, on ne produit pas de matériel informatique, il faut donc l’importer et payer le transport et les taxes douanières, ce qui augmente inévitablement le coût d’un serveur. De plus, les délais d’approvisionnement demandent de prévoir plus de matériel de secours que dans un endroit où on peut se faire livrer en quelques heures seulement.
- l’électricité : le serveur doit être branché à l’électricité en permanence. Aussi, un serveur informatique, comme un ordinateur personnel, génère de la chaleur, et il faut refroidir la salle dans laquelle il se trouve grâce à la climatisation 24H/24, qui consomme également beaucoup d’énergie. En Nouvelle-Calédonie, l’électricité est très chère par rapport à l’Europe par exemple, ce qui explique en grande partie la différence de coût des services informatiques.
- la connectivité : pour être disponible sur internet, il faut y être relié ! Certains gros datacenters gèrent eux-même leur connexion au réseau mondial, mais en Nouvelle-Calédonie c’est l’OPT qui gère. C’est donc à l’OPT que les fournisseurs de services internet comme les hébergeurs doivent acheter de la bande passante, et elle coûte évidemment très cher ! Ne croyez pas cependant que l’OPT applique ces tarifs élevés de façon arbitraire, ils ont à leur charge l’entretien complet du réseau téléphonique utilisé par internet, et des liaisons spécifiques pour connecter les datacenters, ainsi que le fameux câble sous-marin et toute sa maintenance.
Pour trouver l’hébergement adéquat, il faut donc prendre en compte les besoins du site, et bien étudier les différentes possibilités. C’est important de le faire avant de lancer le site, car si l’hébergement choisi au départ ne correspond pas et qu’il faut le changer, il va falloir migrer le site, et ça n’est pas toujours une chose facile.
Vous souhaitez obtenir des conseils sur le choix d’un hébergement, un support technique pour votre hébergement, ou de l’aide pour effectuer une migration? Je peux vous aider !
