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

[marc marc]

Philippe je me perd dans la structure de ton message.

ma réponse si j'ai bien compris ton avis :
- la doc d'installation d'un overpass api est limpide pour un sysadmin 
(même si je ne l'ai pas encore testé). jesaispluski a fait un ansile.
il ne reste qu'à valider mais si c'est confirmé, déployer une nouvelle 
instance n'est qu'une question d'avoir un serveur pour l'héberger et des 
humains qui s'en occupent...
Passer à du propriétaire ne change rien à ces 2 besoins.
Au contraire ca implique de changer l'existant.

- la majorité des énormes site mondiaux tournent sur un socle open 
source. Tous les besoins que tu décris existent en open source et sont 
massivement utilisé.
Changer de roue (le logiciel) ne résout rien.

- avoir un opendata en logiciel propriétaire signifie que tu ne peux pas 
la répliquer pour tel ou tel projet sans devoir faire appel à du 
propriétaire... souvent payant...
Avoir une roue payante ne résout rien.

Le 23. 07. 17 à 19:00, Philippe Verdy a écrit :
> Je crois que le gros problème pour avoir plus de serveurs et donc de 
> redondance c'est toujours le même: moins un problème de bande passante 
> que de la charge énorme que représente l'installation de la base de 
> données, et le fait que très peu de progrès ont été faits pour faciliter 
> sa réplication.
> 
> Les diffs ne sont pas forcément la meilleure façon si on peut disposer 
> de réplication directe entre bases de données. Mais le choix initial de 
> Postgres ne facilite pas les choses, et là où ça marche vraiment très 
> bien c'est sur d'autres moteurs, malheureusement "propriétaires" comme 
> Oracle, mais en fait seulement commerciaux et qui pourtant ne devrait 
> pas coûter très cher en licence en comparaison des coûts nécessaires 
> pour les stockages, l'hébergement dans un datacenter et la bande 
> passante, mais surtout les couts humains que représentent la maintenance 
> sur la solution actuelle.
> 
> Passer à des moteurs SQL commerciaux plus solides est surtout un seuil 
> psychologique pour les promoteurs du projet. On craint une nouvelle 
> dépendance alors que les dépendances les plus importantes (humaines) ne 
> sont même pas résolues. On en arrive alors à figer les évolutions, et le 
> projet est soutenu par une infrastructure de plus en plus fragile, qu'un 
> rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes 
> qui mettront ensuite le projet en péril pendant des mois, avec de 
> grosses difficultés pour recapter l'audience qu'il avait).
> 
> On promeut OSM auprès des administrations, mais faute de ressources 
> humaines on n'est crédible que si à côté de nous on a de vrais 
> fournisseurs de services professionnels. Ces fournisseurs existent, on 
> les a incité à utiliser nos données mais on les a trop peu sollicité 
> pour qu'ils continuent aussi à solidifier l'infrastructure (quitte à 
> accepter qu'on y incorpore des composants propriétaires qui seraient 
> transparents pour nous et pas gênants du tout car n'affectant pas les 
> données elles-mêmes, mais juste l'infrastructure qui les supporte).
> 
> Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de 
> beaux jours devant lui et continuera à imposer ses services (mais avec 
> en revanche un comportement pas transparent du tout, affectant les 
> données directement, et avec l'accaparement des droits sur ces données, 
> leur disponibilité et les conditions de leur réutilisations, qui ne font 
> que devenir de plus en plus restrictives et chères pour tout le monde)
> 
> Demandons nous ce qui est important pour OSM: le logiciel qui le 
> supporte est-il si indispensable et non remplaçable ? Ou bien est-ce les 
> données ? Ne fermons pas la porte aux logiciels propriétaires dans 
> l'infrastructure. A la place consolidons les API, formats de données.
> 
> Là des choses sont à expérimenter, pas forcément uniquement au sein du 
> moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de 
> l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique 
> de machines virtuelles contenant une instance d'OS entière avec ses 
> logiciels et données.
> 
> Le 23 juillet 2017 à 16:28, sly (sylvain letuffe) <liste2 at letuffe.org 
> <mailto:liste2 at letuffe.org>> a écrit :
> 
>     overflorian wrote
>     > Est-ce que vous sauriez à quoi cela est dû ?
> 
>     Cette page liste l'historique des problèmes rencontrés  par les 2
>     instances
>     "principales" :
>     https://wiki.openstreetmap.org/wiki/Overpass_API/status
>     <https://wiki.openstreetmap.org/wiki/Overpass_API/status>
> 
> 
>     overflorian wrote
>     > Quelles en sont les causes profondes ?
> 
>     Je pense que ça se résume simplement :
>     - Trop de gens tirent dessus et trop peu de gens installent d'instances
>     publiques (pour répartir la charge, offrir une possibilité de
>     redondance) ou
>     participent à la maintenance.
> 
> 
> 
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>