[OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Jeu 20 Juil 22:07:27 UTC 2017

L'Overpass API allemande jsutement a planté aussi (à cause d'une perte
d'alimentation chez l'hébergeur pourtant sensé avoir des alimentations de
secours, ce qui a entrainé des pertes de donénes au redémarrage et
l'absence de certains secteurs de données pour des fichiers qui pourtant
étaient sensés avoir une taille supérieure: ces secteurs n'ont pas été
écrits ni même marqués comme alloués alors que la taille de fichier était à
jour, et cela a entrainé une erreur lors de la décompression remplissant un
fichier décompressé de tas de zéros, à cause d'un autre bogue dans l'outil
de décompression qui ne d'étactait pas l'erreur, puis des tonnes
d'incohérences et un plantage dans le chargement des "diffs" pour la mise à
jour de sa base, qui ensuite a planté).

En cause aussi le système de fichier qui n'a pas assuré la cohérence de
l'ordre des écritures, ou bien des anomalies dans les pilotes qui n'ont pas
assuré l'ordonnancement correct malgré le fait qu'il s'agissait d'un
système de fichiers "journalisé" parait-il. Mais aussi en cause certains
réglages d'optimisation des pilotes de disque (pour les performances au
détriment de la cohérence) pour le réglage des caches, aussi bien ceux sur
les contrôleurs des disques physiques que ceux des contrôleurs RAID ou les
caches des interfaces SATA/PCI et sans doute aussi des bogues dans la
gestion de l'énergie au sein des BIOS (ou pilotes de périphériques devant
remplacer les fonctions du BIOS), et peut-être aussi des bogues dans la
synchronisation des coeurs de processeurs récents

(il y a par exemple un bogue sérieux sur une ligne récente de CPU
multicoeurs Intel parmi les plus chers de la gamme pour serveur, pour
lequel des recherches compliquées ont été menées suite à un plantage
inexplicable d'une machine virtuelle avec certaines séquences
d'instructions générées par un compilateur JIT pourtant réputé: le
compialteur n'est pas en cause, mais on a des cas critiques avec certaines
séquences liées à certaines longueurs de "boucles" de code en fonction
causé par une mauvaise synchronisation des pipelines de code suite à des
états d'attente entre plusieurs niveaux de cache interne des processeurs:
certains de ces processeurs ont été déclassés par Intel mais pas retirés du
marché, en désactivant des coeurs et une partie des pipelines et des
caches, mais en attendant certains fabricants OEM sont restés en attente de
matériel et ont du revoir leurs livraisons ou changer de ligne de
processeur, mais des serveurs défectueux ont déjà été livrés et Intel
cherche toujours un moyen de détecter et prévenir ces bogues par un
firmware... et il n'a encore rien publié car il semble qu'il n'y ait aucune
façon simple de prévenir le problème autrement qu'en modifiant les
logiciels utilisés et notamment en désactivant certaines optimisations de
code dans les compilateurs, des optimisations pourtant éprouvées depuis
longtemps)

(il y a un autre exemple récent ces jours-ci avec l'annonce récente par
Microsoft qu'il ne supporait plus les mises à jours de Windows 10 sur
certaines gammes récentes de processeurs très courants sur les tablettes et
mobiles, à cause d'une fonctionnalité défaillante sur ces processeurs, pour
laquelle Microsoft voulait ne plus supporter la prise en charge par
logiciel via un firmware correctif)

(d'autres exemples comme ça il y en a des tas, les listes de bogues
matériels des processeurs sont impressionnantes et notamment pour les
processeurs les plus évolués devant équiper les serveurs qui en principe
devraient être immunisés des problèmes liés à l'alimentation et supporter
matériellement et par logiciel des systèmes de redondance permettant une
reprise rapide, et de détection rapide et contournable des anomalies;
certains de ces bogues existent même pour des processeurs équipant du
matériel spatial, on a eu le cas avec plusieurs satellites pour la
navigation qui sont hors d'usage du fait de graves anomalies sur leurs
horloges qui sont tombées les unes après les autres et ne sont pas
corrigeables ou réduisent considérablement leur précision au point que ces
appareils se servent plus car on ne sait même corriger certaines anomalies
de mesure en injectant des correctifs sur leur logiciel embarqué)

Conclusion: personne n'est à l'abri, des bogues il y en a partout, on doit
faire avec et surtout on doit pouvoir les détecter à tout moment et tout
niveau des traitements sans jamais faire confiance à ce qui est fait par
une couche logicielle sensée être déjà complètement testée: en pratique il
n'existe aucun système permettant de prouver qu'un code est correct et
encore moins de savoir si leur conception initiale fixait toutes les
contraintes vérifiables et on sait que certaines contraintes ne sont pas
vérifiables en temps fini par un quelconque algorithme ou raisonnement
mathématique le plus rigoureux (et il n'existe pas encore un seul langage
de programmation permettant de vérifier toutes les contraintes nécessaires,
même avec les langages dits "fonctionnels" qui ont tous des exceptions pour
les rendre réellement utilisables et capable de répondre en un temps borné;
tous les logiciels ont recours à des heuristiques pour répondre
correctement à la majorité des cas mais on tombera toujorus à un moement
donné ou un autre sur un cas supposé "rare" ou "exceptionnel" où la réponse
donnée sera fausse pour des problèmes pourtant connus et dont la bonne
réponse nous semblerait évidente, et des cas où nos supposées évidences ne
sont en fait pas prouvées du tout mais juste des conjectures basées sur
l'expérience qu'on connait car elle a été documentée quelquepart par
quelqu'un, mais on a encore des tonnes de logiciels quji ne sont pas
documentés du tout et où ceux qui l'ont écrit ne sont même plus là pour
expliquer ce qu'il signifiait ou comment l'utiliser correctement et dans
quelles limites).

Et là cela existe même en absence de tous actes de malveillance volontaire
(qui sont également nombreux mais pas toujours détectés, ou sont
malheureusement gardés secrets en supposant souvent à tord que cela évitera
leur reproduction ailleurs et que les dommages subis par les uns sont
supportables par les autres si on ne leur dit rien, à charge pour eux de
découvrir et démontrer qu'ils ont été dupés ou trahis dans leur confiance):
ce qui ressemble quand on le voit à un bogue inattendu (ou une cause
naturelle imprédictible) peut ne pas être (et souvent n'est pas) le fruit
du seul hasard et de la malchance, mais résulter d'une altération
volontaire plus ou moins masquée ou le fruit d'une négligence de
surveillance sur ce qui semblait ne pas être sensible ou important.

Le 20 juillet 2017 à 21:40, François Lacombe <fl.infosreseaux at gmail.com> a
écrit :

> Hello Florian
>
> Niveau robustesse il n'y a pas 36 solutions, il faut un cluster avec un
> loadbalancer
> Avec un bon hyperviseur, tu detruit carrement une vm qui plante pour en
> remonter une aussi sec
>
> Mais ca reste couteux alors il faut deja adresser ses requêtes a
> différentes instances, au moins de et ru je pense
>
> Ce qui est sur est que ca va vite couter un peu de monnaie pour monter une
> infra disponible
> CDN & co ne seront efficaces que pour des requetes courantes et surtout
> abondamment utilisées, ce qui n'est majoritairement pas le cas
>
> A+
>
> François
>
> Le 20 juil. 2017 9:08 PM, "Florian LAINEZ" <winnerflo at free.fr> a écrit :
>
>> Salut,
>> Aujourd'hui on a eu -encore !- une interruption de service sur l'overpass
>> API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un tas d'autres
>> services qui se basent dessus.
>> J'ai l'impression que cela se produit souvent. Je constate dans mes
>> projets que ce service reste le maillon faible technique et impose de
>> mettre en place une pénible redondance.
>>
>> Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes
>> profondes ?
>> Y aurait-il une solution que nous pourrions mettre en place pour venir en
>> soutien à nos amis les teutons qui gèrent le bouzin ?
>> Est-ce plutôt un besoin de dev ou d’hébergement ?
>> Bref, on résout le problème ? ;)
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian <http://twitter.com/overflorian>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170721/9fe33137/attachment.htm>