Le plus petit SaaS ?

C’est “L’adpresse IP publique” : lip.ovh !

A voir tous les sites qui propose de vous révéler votre adresse IP publique, c’est un service très demandé. Mais lip.ovh se distingue de ses analogues à plus d’un titre :

  1. son nom est le plus court
  2. c’est le service le plus concis,
  3. il n’a aucune pub,
  4. c’est le moins cher.

On accède à lip.ovh en 7 caractères seulement ; on pourrait faire plus court sur un TLD de 2 lettres qui accepte des noms de domaine à moins de 3 lettres mais se serait plus cher.

Ce SaaS (Software as a Service) affiche uniquement l’adresse IP publique de celui qui l’utilise, et rien d’autre. Difficile d’en faire moins.

lip.ovh est hébergé sur un hébergement mutualisé gratuit ; son prix de revient est donc de 0.0825 € HT par mois. Qui dit mieux ?

A ce prix là, ce service est royalement offert par l’EURL Barme qui en profite pour illustrer l’approche minimaliste et économique qu’elle propose à ses clients.

L’EURL Barme entame sont 10ème exercice

Depuis le 1er juin 2017 l’EURL Barme est entrée dans sa 10ème année. Et 10 est un chiffre exceptionnel qu’il est courant de célébrer. C’est encore plus opportun pour un informaticien.

Un informaticien jongle forcément avec les bases binaire, décimale et hexadécimale. La base 2 est celle des ordinateurs et des circuits logiques. Elle utilise 2 chiffres, le 0 et le 1. 10, qui vaut 2 en binaire est donc un nombre particulier à plus d’un titre puisque les bases binaires et décimales y convergent.

A cette occasion, l’EURL Barme lance une nouvelle activité :
numerunique.art.

Au premier abord c’est une activité dont le modèle économique cumule les handicaps : les charges considérables de conception et l’absence d’économie d’échelle qu’apporte la production en masse.

Pourtant, c’est justement ce qui est au cœur de l’activité principale de l’EURL Barme : l’application de l’outil informatique pour un usage spécifique. C’est donc une niche à l’écart de laquelle se tiennent les sociétés dont l’objectif exclusif est la rentabilité mais c’est l’écosystème dans lequel l’EURL Barme d’épanoui depuis bientôt 10 ans, pour la plus grande satisfactions de ses clients.

Consommation électrique

A l’instar du système mis en œuvre pour visualiser la consommation d’eau, l’installation d’un capteur équivalent permet d’accéder à celle de l’électricité.

capteur_elec

Amélioration du tableau électrique

Légende :

  1. le capteur de consommation électrique avec une sortie numérique,
  2. la sortie numérique du capteur reliée au Raspberry Pi (tout comme pour le capteur de consommation d’eau),
  3. une alimentation 5V DC 2.4A,
  4. le branchement de l’alimentation sur le Raspberry Pi.

Attention, si en théorie l’ajout du capteur au tableau électrique est simple, en pratique il est nécessaire de la confier à un professionnel.

L’ajout d’une alimentation installée sur le rail DIN est optionnel mais tant qu’à faire déplacer un électricien pour l’installation du capteur de consommation électrique, autant en profiter !

Le captage des impulsions est identique à celui fait pour l’eau. La conversion en watt est différente et dépend (un peu) du capteur mais l’affichage est similaire :

ConsommationElectrique

La consommation instantanée

C’est vraiment pédagogique de voir sa consommation d’énergie en temps réel ! En vidéo, c’est plus démonstratif : https://youtu.be/WDUL1vy2zWc

Il ne reste plus qu’à exploiter l’information pour faire des économies et contribuer à lutter contre le réchauffement climatique.

Pour l’exemple du café de la vidéo, on a consommé environ 10 W/h pour faire le café, soit 1 cent TTC pour l’électricité. Il faudrait estimer les coûts d’eau et de grains de café pour avoir un prix de revient mais on peut raisonnablement penser que ce n’est pas en limitant le nombre d’expresso que l’on sauvera la planète. Ouf !

La spirale infernale des mises à jour

C’est désormais bien entré dans les mœurs : les matériels, systèmes et logiciels doivent être régulièrement mis à jour. Au point qu’il est fréquent d’entendre que tel ou tel logiciel ne vaut plus rien puisqu’il n’est plus mis à jour ! Ce genre de principe érigé en dogme est le plus souvent colporté par ceux qui cherchent désespérément à palier leur incompétence par des règles faciles à comprendre.

Le problème avec les mises à jour est qu’elles sont la plupart du temps (mais pas toujours) inutiles voire préjudiciables : certaines apportent davantage de bugs ou de failles de sécurité qu’elles n’en corrigent.

Le plus pénible avec les mises à jour de système d’exploitation est qu’elle impliquent en général la nécessité d’un changement d’ordinateur. Le plus horripilant est d’avoir à redécouvrir le nouvel accès à une commande, un service ou une fonctionnalité par ailleurs identique ou même dégradée…

Et si un programme qui n’est plus mis à jour était tout simplement arrivé à maturité ?

C’est encore pire pour les équipements.

Acheté il y a 2526 jours à la date ce cette photo, ce téléphone (un HTC desire 2010) suppliait d’être remplacé.
HTCdesire

Aujourd’hui on a un choix incroyablement riche pour un téléphone :

  1. Android
  2. iOS

Dans le premier cas, on confie toutes ses données personnelles à google, dans le second à Apple. Et en plus, on paye (cher) pour le faire, c’est quand même génial tout ça.

En l’occurrence, c’est le choix 2 qui a été fait. Il en résulte un problème intéressant pour un informaticien : transférer 419 contacts d’un téléphone Android vers un iPhone.

Pour pimenter un peu la chose, on veut éviter de passer par iCloud. A priori il n’y a rien d’ultra secret dans ces contacts mais c’est une question de principe, alors si c’est une question de principe…

L’extraction des contacts depuis un Android de 2010 est simple, en quelques touch on a un .vcf standard sur la carte SD que l’on peut même récupérer par Bluetooth.

L’import sur l’iPhone se présente moins bien : le modèle choisi n’est pas “résistant aux éclaboussures et à l’eau” mais il est parfaitement étanche à toute forme d’échanges de données, quel qu’elles soient, sauf à passer par iCloud ou iTunes, bien sûr.

Va pour iTunes, officiellement cela reste local. D’ailleurs, il faut même utiliser une connexion par câble pour une synchronisation avec iTunes. Les fonctionnalité Bluetooth supportées entre un Mac et un iPhone sont très économes… seule une connexion réseau est possible. Quelle valeur ajoutée !

Hélas, le MacBook air du propriétaire du vieux HTC et du nouvel iPhone réclame une mise à jour d’iTune en préalable à toute tentative de synchronisation. iTune étant à jour, il faudrait commencer par faire une mise à jour du MacOS. L’opération est risquée, le MacBook air en question est d’une autre époque (i.e. vieux de quelques années).

Alors on passe par un autre mac plus récent, sur lequel on crée un compte temporaire. Il faut quand même y faire une mise à jour d’iTunes. Et là ? On découvre que la synchronisation des contacts ne peut se faire désormais que par iCloud :-((

Moralité, lorsqu’on change de téléphone, il faut aussi changer d’ordinateur. Ils devraient proposer un lot.

Heureusement, il y a un moyen de contourner le blocage : un simple mail (d’une messagerie étrangère à Apple ou google) avec le .vcf en pièce jointe et hop, on récupère ces 419 contacts sur l’iPhone, sans passer par iCloud, comme promis.

PS : c’est impressionnant comme la touche i s’use plus vite lorsqu’on parle de Mac.

Comment perdre 2 ans de confiance en 2 heures

Les faits

08:44

Un client de l’EURL Barme signale l’indisponibilité d’un service.

08:55 Création d’un ticket incident :

Bonjour,

Que ce soit depuis l’extérieur (ping barme.fr 195.154.60.32) ou par le RPN (ping 10.x.x.x), le serveur ne répond pas.

Est-ce un problème réseau ?

Merci.

08:58 réponse du support :

Bonjour,

Je fais quelque vérifications et reviens vers vous dans les plus brefs délais.

Cordialement,

09:01 (support) :

Bonjour,

Je vois des logs sur le kvm qui peuvent indiquer une Kernel Panic.

M’autorisez-vous à passer le serveur en mode secours afin de faire quelques tests? Je reviendrai vers vous dès les tests finis.

Cordialement,

09:08 (EURL Barme) :

Oui, passez en mode rescue.

A noter, j’ai basculé mon IP failover sur mon serveur de secours.

09:36 (support) :

Bonjour,

Après les tests que j’ai effectué, il apparaît que le serveur est fonctionnel et n’a pas de souci matériel.

Je vous invite à regarder du côté Software/OS et installation ou configuration.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:40 (EURL Barme) :

ping x.x.x.x: 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C

Vous appelez ça fonctionnel ?

09:43 (support) :

Bonjour,

J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:45 (EURL Barme) :

Merci, je sais ce que c’est le mode secours.

Ne touchez donc plus à rien ; je vais investiguer par moi-même.

09:47 (EURL Barme) :

A noter le “Monitoring” :

Monitoring

Service Statut

Ping du serveur Disponible il y a 1 année historique

!!

09:54 (support) :

Bonjour,

Très bien.

Cordialement,

10:00 (EURL Barme) :

Mon serveur sd-x est à nouveau opérationnel, directement sans _aucune_ modification de sa configuration…

Un simple reboot aura donc suffit à le remettre en service ; c’est habituel de mettre en cause la configuration du client mais comment pouvez-vous le justifier ?

10:16 (support) :

Bonjour,

Je vois que le souci sur ce serveur est résolu après un simple reboot.

Je vous invite à clore le ticket et à le noter en laissant un commentaire.

Bonne journée,

10:20 (EURL Barme) :

Dans syslog, j’ai :

Apr 11 21:17:01 ol1 /USR/SBIN/CRON[46128]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
Apr 12 09:40:42 ol1 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Donc mon serveur est down depuis hier 21:17:01 et à nouveau opérationnel depuis 09:40:42 ce matin.

Et pourtant votre monitoring ne m’a pas alerté et prétend qu’il est disponible depuis 30/09/2015 09:52:18 ! ?

N’y aurait-il pas un problème de votre coté ?

10:44 (support) :

Bonjour,

Je transmet votre demande au service concerné et nous reviendrons vers vous dans les plus brefs délais.

Cordialement,

10:53 (EURL Barme) :

Cela vous amuse de passez mon serveur en mode rescue sans prévenir ?

11:03 (EURL Barme) :

Vos techniciens mettent mon site HS alors que je leur ai demandé de ne plus y toucher à 12/04/2017 09:45:53.

C’est pourtant pas un jouet ce serveur !

11:09 (support) :

J’ai prévenu mes collègues en charge

— —

Cordialement,

11:30 (support) :

Bonjour,

je reprends la suite du ticket au vu du signalement de celui-ci.

Un quiproquo et un échange trop rapide lors de la remonté a en effet entraîné un autre passage en secours.

Je confirme que le serveur est bien opérationnel de mon côté

Il ping bien en mode normal.

J’ai remis à jour le monitoring sur le serveur en espérant que vous soyez allertez la prochaine fois.

Rien ne vous empêche de mettre en place votre propre monitoring.

Cordialement – Technicien Premium

Commentaires

C’est toujours dans un contexte défavorable qu’un incident survient, en l’occurrence lors d’un déplacement, avec un contexte technique d’intervention et une disponibilité réduits.

Evidemment, c’est un client qui découvre et indique le problème ; en temps normal il aurait été découvert bien plus tôt et l’investigation de l’EURL Barme aurait été faite directement par une connexion sur la console du serveur, avant de faire intervenir le support.

Le support a été très réactif : réponse au ticket en 3 minutes. Son diagnostique initial (Kernel Panic) a été confirmé par le technicien Premium intervenu après escalade du problème.

Erreur du support : retour sans vérifier que le serveur est opérationnel après sortie du mode rescue. Il aurait été préférable d’attendre la fin du redémarrage.

Dérapage du support : mise en cause arbitraire du client (“J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.”)

C’est un grand classique de tous les supports de mettre systématiquement le client en cause. C’est évident que la plupart des remontées faites aux supports le sont par des personnes aux compétences informatiques modestes et de surcroît sans doute agressives car le problème pour lequel elles appellent est mal vécu. Mais ce n’est pas une raison pour mettre tout le monde dans le même panier et considérer, a priori, que l’origine du problème est du coté du client. La bonne approche devrait être de vérifier en premier s’il n’y a pas un souci du coté du prestataire et rien n’empêche, ensuite, de mettre le client face à ses responsabilités.

Erreur gravissime du support : passer un serveur de production (qui fonctionne !) en mode rescue sans autorisation du client. Là c’est le summum de l’inconséquence et totalement inadmissible de la part d’un service professionnel.

Ensuite c’est l’escalade et le problème atterri sur le dos d’un technicien “Premium” qui n’y est pour rien et ne peut plus rien y faire. Le terme “Premium” fait sourire avec sa connotation de “compétence supérieure”. Techniquement c’est sans doute vrai mais dans le contexte, ce sont davantage des compétences en communication qui sont requises.

Ce technicien “Premium” prendra la peine d’appeler pour signaler le retour au mode normal du serveur, ce qui est très bien et courageux de sa part mais son ton condescendant face à un interlocuteur avec 36 années d’expériences en informatique dans un tel contexte sera la cerise sur le gâteaux… Une formation de base à la communication lui serait bien utile.

Et pour la suite…

Les serveurs sous linux sont très fiables mais pas infaillibles. C’est justement la raison pour laquelle un serveur dédié utilisé pour un service critique  ou non doit être doublé par un clone synchronisé automatiquement et en permanence avec le serveur en fonction. Un kernel panic isolé est un aléa potentiel qui ne remet pas en cause le serveur ni sa configuration.

De même un incident isolé mal géré ne remet pas en cause un prestataire ni son professionnalisme.

L’EURL Barme ne changera donc pas ses serveurs impliqués dans cet incident et ne souhaite finalement qu’une chose : que cesse cette habitude des supports de mettre systématiquement en cause le client.

Epilogue

A l’occasion d’un autre souci technique (mineur celui-là) sur mes serveurs chez Online, j’ai eu affaire à un service de qualité, tant en compétences techniques qu’en communication.
Comme quoi cela dépend beaucoup des interlocuteurs ; il y en a des décevant mais aussi des très bons.
Ouf, mes serveurs sont décidément bien gérés et mes fournisseurs bien choisis 🙂

Why frameworks suck?

ol1

OPEN LOOK, once it was a must, now it’s but a mug – a nice and dear one though.

ol2

This is just an example of a wonderful framework: in 1990, it allowed building homogeneous UX for applications on top-of-the-moment desktop workstations.

As all really powerful frameworks, it required a long and tedious learning time – often with a steep initial learning curve – but with a beautiful result. The problem is that all the knowledge acquired to master it is now lost and this is the fate that doom all frameworks, thousands of framework since 1990.

The core of the problem is that frameworks provide high-level functionalities that don’t last more than the underlying fashion. As a programmer, one should look after learning how to build complex tools with low-level instructions: that will last forever.

Of course it is worst to reinvent the wheel; except for very special cases, nowadays nothing useful can be achieved with machine language. Using a higher-level language – whatever – is better. And while working within a team, frameworks provide a strong common context.

So yes, frameworks are useful somehow. But then use them scarcely, staying aware that you will soon need to forget all about them and learn the next one.

Beside, there is another drawback to the use of frameworks: they constrain what you can do with them. If your specifications is close to what a framework is meant for, you will probably benefit of its use. If not, then the challenge to adapt the framework to your need is so expensive that you end in adapting your specification to what the framework allows.

Framework are definitely incompatible with specific developments.

Comptage d’impulsion – vue d’ensemble

Que ce soit pour la visualisation de la consommation d’eau en temps réel ou celle de la puissance électrique instantanée, le principe de base est le même :

archi

  1. Il y a d’abord un capteur qui fournit l’information recherchée sous forme d’impulsions électroniques.
  2. Un processus activé par interruption logicielle relève ces impulsions aussi vite que possible.
  3. Un autre processus stock tranquillement ces relevés d’impulsion dans une base de données.
  4. Un serveur web anime un mini site internet qui récupère les données et les transforme en informations présentées dans un navigateur.

Les impulsions sont fugitives ; il est important de ne pas les rater et de pouvoir mémoriser l’instant de leur occurrence aussi précisément que possible.

Naturellement, comme dans l’exemple indiquée dans un commentaire sur l’exemple de code pour l’étape 2, une solution simpliste consiste à enregistrer dans un fichier le nombre total d’impulsions comptées et la date et l’ heure de la dernière impulsion.

Cependant, c’est long, relativement à la brièveté d’une impulsion. Il faut en effet : ouvrir le fichier, lire la dernière valeur du compteur, recréer une nouvelle version du fichier avec la nouvelle valeur du compteur et la date et l’heure de la dernière impulsion. Si les impulsions sont trop rapprochées, on pourrait en rater. Par ailleurs, un décalage, d’une valeur plus ou moins aléatoire, s’introduit entre l’impulsion qui déclenche le traitement et le moment où l’heure est relevée.

En plus c’est pauvre : on ne conserve que le nombre total d’impulsions et la date de la dernière occurrence.

C’est pour cela qu’il est préférable de faire le traitement des impulsions en deux étapes : une lecture aussi rapide que possible (étape 2) puis, indépendamment et  sans contrainte de temps d’exécution, le stockage de chaque impulsion dans une base de données (étape 3). Ce traitement est fait à l’initiative de l’étape 4 et, en parallèle, il est aussi fait à intervalles réguliers. Ce qui permet d’avoir l’information la plus récente possible à afficher et éviter qu’un trop grand nombre d’impulsions ne s’accumulent avant d’être stockées en base de données si l’affichage n’est pas sollicité suffisamment souvent.

De plus, le stockage de toutes les impulsions dans une base de données ouvre la voie à de nombreux traitements et analyses.

Mais pourquoi 10 kΩ ?

Pourquoi 10 kΩ ? C’est la question posée par Giome dans son commentaire sur le “module additionnel”. C’est sans doute une question que tout le monde se pose et que personne n’ose poser. Comme d’habitude, c’est une évidence pour ceux qui savent et un mystère pour les autres. Si la réponse apportée ici est satisfaisante, Giome aura rendu un grand service en posant cette question.

Schématiquement, la connexion électronique à un GPIO (General Purpose Input Output c’est à dire port d’entrée sortie d’usage général) est le suivant :

GPIO

A gauche de ce schéma on a le symbole d’un bouton poussoir qui correspond au fonctionnement des capteurs “à impulsion”.  Pour le capteur utilisé sur le compteur d’eau du système de visualisation en temps réel de la consommation d’eau, c’est juste ça. Pour les compteurs utilisés pour le suivi de la consommation d’électricité c’est l’équivalent en version électronique. Dans les deux cas, une impulsion correspond à ce qui ce passerait si on appuyait brièvement sur le bouton poussoir : un court-circuit entre l’entrée GPIO et la masse.

Au niveau de l’entrée GPIO, on veut la traduction de cette impulsion sous forme binaire : un bref passage de 1 à 0, c’est à dire la passage de la tension Ub de 3.3 V à 0 V, puis un retour à 1 (3.3 V).

Si on ne branchait que le bouton poussoir, la valeur lue par le GPIO serait indéterminée (on dit “flottante”). Pour la maintenir à 3.3 V, on la relie à une sortie 3.3 V. C’est ce qu’on appelle un “pull-up” car cela tire la valeur lue par le GPIO vers le haut.

Si on reliait directement le 3.3 V au GPIO, sans résistance intermédiaire, on aurait, lors d’une impulsion, un cour-circuit du 3.3 V vers la masse !

La résistance de pull-up sert donc à protéger la sortie 3.3 V pour éviter de griller le circuit. L’intensité est alors limité à Ua/R. Avec une résistance de 10 kΩ l’intensité est donc de 0.33 mA, largement en dessous de la limite des 16 mA recommandée pour la limite du courant tiré d’un des GPIO. On aurait pu mettre moins que 10 kΩ mais c’est une valeur couramment admise pour une résistance de pull-up. C’est celle utilisée pour la version 1 du capteur de consommation électrique.

Par ailleurs, il est aussi possible d’activer, par une instruction logicielle, une résistance de pull-up interne, une par GPIO, d’une valeur annoncée de 50 kΩ.

Si on active cette résistance de pull-up interne, on peut donc se passer de rajouter une résistance de pull-up externe. C’est le choix fait pour la version 2 du capteur de consommation électrique.

Ce qui simplifie efficacement le montage.

Consommation électrique version 0.2

Chouette c’est le weekend ! Un peu de détente de geek, ça fait du bien…

Améliorations du capteur

Version 1 :el1La version 1 utilise un Raspberry Pi 1, une connexion avec des borniers, des résistances de pull-up de 10 kΩ, un compteur à 1000 imp./kWh. On note que tout ne tient pas dans le cadre de l’objectif tellement c’est encombrant. On cachera les détails, ils ne valent pas la peine d’être montrés.

Version 2 :el2

La version 2 a un bien meilleur WAF. Elle utilise un Raspberry Pi zero, une connexion sans bornier ni pull-up, un compteur à 2000 imp./kWh. L’intérieur est nettement plus élégant.

el2_details

Améliorations du traitement

Techniquement, le plus important est le passage à 2 impulsions par Wattheure : deux fois plus précis et deux fois plus réactif, surtout pour les consommations “faibles”.

Pour la peine, on passe pour le relevé des impulsions du Python au C (invisible à l’œil nu) et on améliore l’UX, nettement plus visible : el2_UX

Le fait que la consommation soit passée de 179 à 247 W est inopiné. C’est juste qu’il y a un ordinateur  portable en charge en plus au moment de la capture d’écran ; ah oui, 68 W pour charger le portable.

Consommation électrique version 0.1

Le commentaire de Mikael BERTHO à propos de l’article sur la consommation d’eau a fourni une piste pour un capteur permettant de suivre également la consommation électrique.

Affichage

Un poste de travail avec deux grands écrans

Le résultat attendu est un peu différent. Là il s’agit de connaître la consommation instantanée pour se rendre compte de la puissance électrique utilisée. Pour l’eau, c’était la quantité cumulée utilisée pour une action donnée mais le principe de base reste le même.

Pour explorer cette possibilité, on installe le capteur sur une vieille rallonge électrique recyclée pour l’occasion :

capteur

ATTENTION : c’est du 220 V ! Ne pas faire ce montage sans parfaitement comprendre et maîtriser les risques qu’il implique.

Et puis on monte un banc de tests :

banc2test

Tout l’intérêt du capteur réside dans sa sortie numérique :

testoutput

Cette sortie est reliée à l’entrée du banc de tests :

testInput

Ici elle est en parallèle avec une entrée manuelle ; un simple bouton permettant de simuler une impulsion et d’en valider la lecture par le Raspberry Pi.

Pour visualiser l’impulsion fournie par le capteur, on installe un oscilloscope digital, version geek :

bitscope

Ce qui permet de capturer une magnifique impulsion :

Impulsion

L’entrée digitale du Raspberry Pi maintenue à l’état “haut” de 3.1 V par une résistance de pull-up passe brutalement à un état bas de 1 V pendant 76 ms lorsque le capteur annonce la consommation d’un wattheure.

Il reste à faire installer par un électricien professionnel le montage du capteur sur le tableau électrique pour avoir une visibilité sur la consommation électrique générale. En attendant, ce simple dispositif permet déjà de prendre conscience de la consommation d’un poste informatique.

En veille, les mêmes équipements consomment nettement moins :

veille

Et en veille encore plus prolongée, encore moins :

veille2

Tiens, cela permettrait donc aussi de donner des indications objectives sur les temps et horaires de travail effectif d’un informaticien…

Oh !