osm-fr / infrastructure Goto Github PK

Bonjour,
depuis ce matin, Nextcloud ne se synchronise plus sur mon poste ou trés lentement (c'est pas clair, il semble tenter la synchro puis planter). L'interface web est trés longue à obtenir puis tout est trés trés long !!!

liste des modifs faites ou à faire dont certaines sont à transformer en ansible :)

Stats avant modif : munin-update 240sec + munin-limits 2sec + munin-graph 80sec + munin-html 60sec = 382sec toutes les 300sec :(
Stats après modif : munin-update 150sec + munin-limits 2sec + munin-graph 0sec + munin-html 57sec = 209sec toutes les 300sec

• ajout des moniteurs munin_stats et munin_update sur osm127
• suppression du doublon localhost <> osm127 (entrée localhost commentée dans /etc/munin/munin.conf)
• rattacher osm127 au bon hosteur (osm26 au lieu de osm22)
• erreur dans /var/log/munin/munin-node.log sur osm127
  LWP::UserAgent not found at /etc/munin/plugins/apache_accesses line 86.
  -> libwww-perl installé sur osm127
• désactivation des serveurs éteints qui ralentissent le processus : osm14 osm16 osm17 osm18 osm22 (gain d'environ 70sec)
• suppression osm131 (doublon osm25-bzh202)
• désactivation des crawler dans /var/cache/munin/www/robots.txt
• patcher l'absence de log du temps munin-graph pour pouvoir comparer avec la solution suivante (fait dans /etc/cron.d/munin-cron)
• passer en mode graph_strategy cgi (gain d'environ 80sec)
• passer en mode html_strategy cgi si ce mode n'est plus bugé (nécessite modif apache)
• passer éventuellement en mode RRDCached
• passer éventuellement la partition en commit=300 : droit refusé dans la vm
• passer en mode asynchrone
• installer libwww-perl sur tous les serveurs apache pour que le moniteur fonctionne
• augmenter la ram pour osm127 car oom
• virer moniteur munin@osm11 (il n'y a pas de munin master sur ce host)
• suppression osm5/osm6
• osm23 osm111 ne répond pas : ajout ip public osm127 dans munin-node.conf
• voir pq osm111 ne répond pas (serrait peut-être coupé)
• rajouter les moniteurs renderd et mod_tile pour osm25-osmfr osm25-bzh202
• installer les moniteurs smart sur tous les hosteurs
• installer bc sur tous les hosteurs pour le graphe acpi température
• config firewall pour laisser passer les icmp destination inatteignable afin qu'un serveur éteint ne ralentisse pas le processus (ou voir s'il option pour attendre max X sec)
• analyser les erreurs dans les différents /var/log/munin/munin-node.log
• voir si cela a du sens d'exécuter les moniteurs d'une vm lorsqu'ils donnent l'info du hosteur (ex à vérifier: cpu & io température)
• avoir les ip réelles dans les logs pour les requêtes http
• virer les moniteurs apache quand il n'y a pas d'apache : ex osm24
• les moniteurs fw_conntrack et fw_forwarded_local nécessite le packet contrack qui ne semble pas fonctionner sur les vm. ex osm103
• des serveurs sans postfix ont un moniteur postfix. ex osm147 osm148
• les moniteurs fans et voltage ne fonctionnent sur aucun serveur. a voir si on corrige ou supprime.
• sur osm148 quelqu'un (Rodolphe ?) a utiliser "log_file Sys::Syslog" dans /etc/munin/munin.conf afin de migrer /var/log/munin/munin-node.log en syslog. a faire de même sur les autres serveurs.
• ajout osm154
• maj debian 8.10 -> 9.4 (gain d'environ 23sec)
• osm200/201/202/205/206/207 (backend osmose) : absent du dns + ip privée non accessible
• osm13 : munin Nginx presque vide (création d'un vhost localhost pour redirection explicite de /ngnix_status vers ngnix et mod_tile vers apache)
• osm13 : smart sda vide (raid, fonctionne sur osm12)
• inclure les modifs ci-dessus dans les rôles ansible correspondants

Visualisation avec Leaflet des couches produites par OSM-FR

@cquest tjs d'actualité ? il y avait des bras prêt à aider.
https://pad.tetaneutral.net/p/osm

Bonjour,

J'ai accès à osm202 depuis octobre mais comme je ne suis pas sudo je ne peux pas faire grand chose ;)

ci-dessous ma liste au père-noël (c'est bientôt la période…) :

• compte user
• compte -> sudousers
• nginx frontal sur osm25 : router *openstreetmap.bzh -> 10.1.0.202 , http + https
• postgresql : créer rôle osmbr pour USAGE et SELECT
• postgresql : autoriser accès depuis machine osm202
• certificat ssl pour tile.osm.bzh
• Real IP pour les stats

le certificat https du forum et de taginfo ont expiré (et sans doute les autres aussi)
@jocelynj tu avais mis un script en place il y a quelques mois pour les renouveler chaque mois mais d'après la date du certificat, il ne semble pas s'exécuter.

Let's encrypt est aussi supposé envoyer un email d'alerte. ce serrait probablement utile de changer l'email d'alerte au profit de celle de la ml technique.

exemple hier sur https://munin.openstreetmap.fr/osm11.openstreetmap.fr/osm117.openstreetmap.fr/cpu.html
idle max > 10 millions
iowait max > 11 millions

il me semble qu'aucune valeur ne peux être supérieur a 2400 % vu que la vm a 24 coeurs cpu.
cela se produit aussi sur 101 qui est sur le même hosteur
mais sur le hosteur lui même, pas vu d'anomalie.

Pour voir les moments oü se produisent ces anomalies, il suffit de demander le graphe des valeur >2400%
https://munin.openstreetmap.fr/static/dynazoom.html?plugin_name=osm11.openstreetmap.fr%2Fosm117.openstreetmap.fr%2Fcpu&start_iso8601=2017-11-04T12%3A23%3A58%2B0100&stop_iso8601=2017-11-05T18%3A23%3A58%2B0100&start_epoch=1509794638&stop_epoch=1509902638&lower_limit=2400&upper_limit=2500&size_x=800&size_y=400&cgiurl_graph=%2Fmunin-cgi%2Fmunin-cgi-graph

@jocelynj The certificate is only valid for the following names: beta.osmose.openstreetmap.fr, osmose.openstreetmap.fr, osmose.openstreetmap.lu

Bonjour @jocelynj

J'aurais besoin que tu me fasses 2 redirections vers bzh202 :

• kosmtik = port 6789
• monit = port 2812

Merci d'avance.

Suite au problème récent d'un oom qui a killé monit et cron, bloquant par la même les taches automatique
Il serrait utile d'avoir un check lancé par exemple le serveur de monitoring ou par le serveur de backup (ou autre serveur qui a accès partout) qui teste simplement que les crons sont lancés et/ou qui test que monit tourne.
l'autre solution est de faire l'inverse : chaque serveur envois régulièrement une info qu'il est up (un wget vers un serveur de monitoring par ex).
cela permet de déclencher une alerte lorsqu'un cron ne tourne pas.
A voir si cela peux-être intégré dans le monitoring qu'est entrain de mettre en place Rodolphe.

La 2ieme solution a ma préférence (mode push)

runtime error: open64: 0 Success /ssd/overpass/database/areas.bin.idx File_Blocks_Index: bad pos in index file
info venant de Stereo sur irc.
je supose qu'il a fait une requête sur une aire
j'ai reproduis le cas pour l'ajouter dans le moniteur script ~marc_marc/test_area.sh (il reste à comprendre pq il ne veux pas l'exécuter sur localhost

Salut
L'url http://export.openstreetmap.fr/contours-administratifs/communes/ ne répond plus.
Cheers.

Bonjour,

Je bute sur un problème pour la mise en prod de la carte en breton.
J'ai trouvé d'où vient le problème : aucune requête contenant un ST_SIMPLIFY n'aboutit.
Cela touche bien évidemment toutes les couches dédiées aux petites échelles.

2 exemples ci-dessous qui aboutissent très bien et assez vite sur ma base Bretagne en local mais qui ne rend rien ou un truc bizarre dans la console psql quand on les joues sur la base monde.

SELECT osm_id, ST_Simplify(way, 20) AS way, way_area AS area, COALESCE(landuse, leisure, "natural", highway, amenity, tourism) AS type  FROM planet_osm_polygon  WHERE way_area > 100000
AND way && ST_SetSRID('BOX3D(-205462.7320305551 6095394.383573093,-146759.0943075371 6154098.02129611)'::box3d, 3857);

SELECT osm_id, ST_Simplify(way, 10) AS way, COALESCE(railway) AS type, tags->'usage'::text AS usage, tunnel, bridge FROM planet_osm_line  WHERE railway IN ('rail') AND tags->'usage'::text IN ('main', 'branch')
AND way && ST_SetSRID('BOX3D(-607072.89 6105178.323193599,-469629.1017841224 6590288.74)'::box3d, 3857) ;

Une idée de la cause @cquest ?

mettre/activer un antispam sur Sympa
https://www.sympa.org/manual/antispam
attention c'est gandi qui forwarde les emails à liste... faudra donc configurer correctement le smart_host

Lorsque je lance une vidéo sur peertube, j'ai régulièrement l'erreur suivante

On veut migrer uMap sur les nouvelles machines, et en profiter pour passer sur python 3.
Un fabfile existe pour le déploiement, mais il faudra sûrement un peu de boulot manuel pour la migration des fichiers d'une part, et la mise en place d'un backup d'autre part.

• installer la VM
• faire pointer un domaine provisoire dessus
• installer la 1.0.0-rc.x
• rsync les fichiers de /data/work/umap/var/uploads (machine actuelle) vers /srv/umap/media_root (nouvelle machine); il faut migrer seulement les .geojson, pas les fichiers de cache .geojson.gz
• dumper la DB et la restorer sur la nouvelle machine (warning, on va passer de 9.6 à 10, j'ai souvenir que les dump/restore avec un upgrade de majeure PLUS PostGIS au milieu, c'était galère)
• mettre en place un rsync hourly des fichiers (/etc/cron.hourly/umap-sync)
• tester tester tester
• mettre en place un backup des données sur la nouvelle machine (DB et FS)
• mettre l'ancien uMap en mode readonly
• migrer la DB for real

sudo -u postgres -i
dropdb umap
createdb umap -O umap
psql umap < /srv/umap/dump.sql
# En user umap
sudo -u umap -i
psql umap
# appliquer la migration SQL cf https://github.com/umap-project/umap/blob/master/docs/changelog.md
source venv/bin/activate
umap migrate --fake-initial
# En user sudoer
sudo systemctl restart uwsgi nginx

• supprimer le rsync hourly

• lancer un dernier rsync des fichiers

  $ /etc/cron.hourly/umap-sync
  

• changer le SITE_URL dans la config (/etc/umap/umap.conf)

• basculer le DNS

@jocelynj @cquest quelqu'un peut me rappeler l'IP de la VM de destination? :)

Le but : que le serveur apache 2.4 sur osm202 reçoive bien les vraies IP des clients.

user ---> frontal nginx (osm25) ---> apache24 (osm202)

Docs :

• https://buzut.fr/apache2-recuperer-ip-derriere-reverse-proxy/
• https://gist.github.com/patrocle/43f688e8cfef1a48c66f22825e9e0678

Fait sur osm202 :

a2enmod remoteip
service apache2 restart

# pour vérifier
apachectl -M

nano /etc/apache2/conf-available/remoteip.conf
…
a2enconf remoteip
service apache2 restart

Contenu de remoteip.conf

#RemoteIPHeader X-Forwarded-For
RemoteIPHeader X-Real-IP

# ici les adresse distantes auxquelles on fait confiance pour présenter une valeur RemoteIPHeader
RemoteIPTrustedProxy 10.0.0.25

N'a pas marché : j'ai tjs 10.0.0.25 en IP d'origine dans les logs. Que ce soit en RemoteIPHeader X-Real-IP ou en RemoteIPHeader X-Forwarded-For.

@jocelynj peux-tu remettre ici la config du nginx STP ?

tache a probablement diviser en sous-tache :

• créer un rôle ansible pour chacune des vm
• la partie migration en elle-même entre les anciennes vm et les nouvelles (en même temps que le passage sur les nouvelles vm ou migrer indépendamment les vm si c'est portable entre openvz et proxmox)

erreur 500 sur l'interface web
sans doute causé par :
2018-07-25 07:00:01 status installed sympa:amd64 6.1.23~dfsg-2+deb8u2

solution : récupérer l'ancien /etc/sympa/wwsympa.conf écrasé par la maj si c'est le même soucis que celui signalé sur https://listes.renater.fr/sympa/arc/sympa-fr/2018-07/msg00042.html

demande d'une vm pour Fred pour un docker osmose frontend

nettoyer la page wiki pour

• archiver les serveurs eol
• rajouter les os pour se faire une idée de ce qu'il faudrait mettre à jour
• localisation du serveur rendu fr (de mémoire a disparu de la page)

demande de Rodolphe
idéalement en accès direct au moins pour http/https (histoire que le service soie accessible si le reverse proxy)

• ajout dns d'un host genre https://status.openstreetmap.fr

Hello,
La nouvelle ortho de Toulouse est disponible ici:
https://data.toulouse-metropole.fr/explore/dataset/orthophotoplan-2017/

Est-ce que quelqu'un peut la mettre à dispo sur http://wms.openstreetmap.fr/tms/1.0.0/toulouse_2017 ?

• alerte récurrente de plantage d'un processus
• 4k email en attente https://munin.openstreetmap.fr/osm27.openstreetmap.fr/osm138.openstreetmap.fr/postfix_mailqueue.html
• en passant optimiser la conf apache qui fork trop de process inutile
• installer un antispam en entrée
• éviter que les emails from @LISTES provoquent un bounce
• effacement /var/log/syslog.1.gz qui bloquait le logrotate
• /etc/resolv.conf dit qu'il y un serveur dns local mais il ne tourne pas
• voir les erreurs audit a propos de named

Signalé sur la liste de discussion umap, il semble que cela concerne le rendu 👍 http://tile.openstreetmap.fr/?q=f%C3%A9nelon%20lyc%C3%A9e%20paris#

l'affichage des rues se fait parfois de manière erronée, par exemple ici Saint-André des Arts, qui s'affiche correctement à gauche et droite, mais s'affiche « Rue Sairé des Arts » au centre au croisement de la « rue des Grands Augustins » verticale, qui elle aussi s'affiche de manière erronée (« Rue des Graes Grands Augustins ». À d'autres niveaux d'agrandissement, l'affichage ne pose pas de souci.

https://lists.openstreetmap.org/pipermail/umap/2018-July/000277.html

plante régulièrement par saturation ram. plusieurs pistes :
soupçon de surallocation mémoire dans la vn :

• diminuer le nombre de thread apache (on est a max 19 sur la semaine) /etc/apache2/mods-enabled/mpm_worker.conf
• augmenter la ram attribuée à la vm (par exemple la moitié de ce qu'on peux récupérer sur l'ancien overpass api)
• diminuer MaxRequestWorkers à 1 ou 2 fois le nombre de coeur cpu

soupçon de fuite mémoire applicative :

• diminuer MaxConnectionsPerChild à 100 voir moins.
• mettre un check&restart en cron

Je m'étonne de la grande différence entre le serveur de rendu osm-fr et ceux osm.org
le critère le plus frappant est le nombre de metatuile/second org ~11 fr ~1
https://munin.openstreetmap.org/openstreetmap/scorch.openstreetmap/renderd_processed.html
https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/renderd_processed.html

la db a aussi régulièrement des pics de 2h de lag
https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/index.html#osm

pistes :

• il y a nginx visiblement inutilisé qui tourne et qui pourrait être arrêté.
• trop de processus en // ? 12 cœurs physique <> processus jusqu'à ~16
  https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/cpu.html
• osm.fr ne semble pas utiliser les mêmes versions que osm.org (cfr les nombreuses différences dans les moniteurs postgress sur munin)
  faudrait chercher la version postgress pour comparer
• le style osm.org a peut-être eu des améliorations d'efficacité, cfr le graphe qui semble indiquer un gain~50% sur un an
  https://munin.openstreetmap.org/openstreetmap/scorch.openstreetmap/renderd_zoom.html
  A voir si cela serrait pertinent ou pas de faire un rebase de l'upstream tout en y appliquant les spécifs osm-fr
• voir la cause du lag de réplication
• optimisation paramètre postgress ?
• pour éviter de ne rien faire pendant la nuit, il est possible d'augmenter la taille de la file dirty afin de traiter les modifs de la journée (dont actuellement une partie sont dropée) en différé au lieux d'attendre que quelqu'un redemande la tuile. on pourrait augmenter de +1000 par semaine jusqu'à avoir "de quoi travailler toute la nuit"
  openstreetmap/mod_tile#152

Bonjour,

La machine osm202 qui abrite le service teol.openstreetmap.bzh est injoignable ce matin.

Ni par HTTP ni SSH.

Qqn pourrait regarder ? @jocelynj @cquest

http://munin.openstreetmap.fr/osm27.openstreetmap.fr/osm27.openstreetmap.fr/smart_sdc.html
depuis mai 2017 smartctl_exit_status 64
Bit 6: The device error log contains records of errors.

C'est peut-être les travaux sur les serveurs, dans ce cas désolé pour ce signalement !!!
Sinon si ce n'est pas les travaux, nous avons actuellement : 502 Bad Gateway
nginx/1.6.2

Bonjour @cquest

Je te sollicite pour disposer de ton script d'expiration des tuiles.
On en avait parlé en décembre mais c'était trop tôt. Maintenant c'est OK.

J'ai bien vu que les listes des tuiles sont dans /data/osm2pgsql/expire_list/
et j'ai lu https://wiki.openstreetmap.org/wiki/Tile_expire_methods

Et je vois bien que le souci du script c'est de gérer la liste des listes sur un pas de temps donné.
Inutile donc de refaire ce qui marche bien ^_^

Je te remercie donc d'avance de me le faire parvenir par n'importe quel moyen.

Pour pouvoir utiliser le fond de carte BDOrtho depuis iD via http://preview.ideditor.com/release et http://preview.ideditor.com/master

Hello,
J'aimerais avoir temporairement une petite VM pour valider la mise à jour du serveur JOSM vers Ubuntu 18.04.1:
https://josm.openstreetmap.de/ticket/16231
La mise à jour étant dispo le 26 juillet, serait-il possible d'avoir une VM un mois environ (par exemple du 19 juillet au 19 août) avec les caractéristiques suivantes:

• 1 coeur
• 8 GB RAM
• 200 GB de disque
• Ubuntu 16.04 LTS
• droits root pour valider l'upgrade vers 18.04
• domaine à configurer sur le proxy http? Je n'ai pas compris cette question, quels sont les choix possibles ?

Merci,
Vincent

un restart en cron l'élimine, mais bon, c'est pas propre dixit @cquest

l'overpass api sur osm103 n'est plus en prod
mais il reste probablement d'autre chose à migrer de cette vm
dici là on pourrait diminuer la ram qui lui est allouée (+ utile temporairement pour le problème osmose frontend)

Hello,
L'ortho de Toulouse hébergée sur osm.fr est KO depuis septembre 2017:

http://wms.openstreetmap.fr/tms/1.0.0/toulouse_2015/22/2113645/1530320

An error occurred: msDrawWMSLayerLow(): WMS server error. WMS GetMap request failed for layer 'toulouse_2015' (Status -6: Couldn't resolve host 'data1.cugt.org').
msHTTPExecuteRequests(): HTTP request error. HTTP: request failed with curl error code 6 (Couldn't resolve host 'data1.cugt.org') for http://data1.cugt.org/geocache/wms/?LAYERS=ortho2015&REQUEST=GetMap&SERVICE=WMS&FORMAT=image/jpeg&STYLES=&HEIGHT=256&VERSION=1.1.1&SRS=EPSG:3943&WIDTH=256&BBOX=1572247.61790015,2276607.00260077,1572254.66780911,2276614.0286607&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_inimage
  File "/usr/lib/pymodules/python2.7/TileCache/Service.py", line 256, in modPythonHandler
    host )
  File "/usr/lib/pymodules/python2.7/TileCache/Service.py", line 208, in dispatchRequest
    return self.renderTile(tile, params.has_key('FORCE'))
  File "/usr/lib/pymodules/python2.7/TileCache/Service.py", line 138, in renderTile
    data = layer.render(tile, force=force)
  File "/usr/lib/pymodules/python2.7/TileCache/Layer.py", line 444, in render
    return self.renderTile(tile)
  File "/usr/lib/pymodules/python2.7/TileCache/Layers/MapServer.py", line 51, in renderTile
    mapImage = wms.draw()
  File "/usr/lib/python2.7/dist-packages/mapscript.py", line 1574, in draw
    def draw(*args): return _mapscript.mapObj_draw(*args)

Solution: il faut remplacer dans la conf du serveur le host 'data1.cugt.org' par 'wms.plan.toulouse.fr'.

Il n'y a pas de certif valide sur tms.cadastre.openstreetmap.fr et wms.openstreetmap.fr

Rézopole renumérote les IP des VM.

Les nouvelles IP étaient déjà configurées, j'ai juste mis à jour le DNS (Gandi).

Issue créée juste pour avoir une trace de la manip ;)

If you need the issue in english, just ask.

Bonjour,
Sur l'osmecum "Intégrer les adresses" (https://wiki.openstreetmap.org/w/images/8/86/Osmecum_integration_adresses_v1.odt) indiqué sur la page https://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum, le site http://addr.openstreetmap.fr est utilisé comme outil de base. Or j'ai bien une résolution du nom mais pas de réponse du serveur.

ces 3 orthophoto sont ko (celle de Bordeaux 2016 fonctionne par contre)
est-ce un problème sur wms.openstreetmap.fr ou est-ce c'est un reverse proxy vers une source externe qui est ko temporairement ou définitivement ?

Quand une VM est réinstallée, la clé du serveur ssh change. Du coup, le serveur de backup ne fait plus de backup sur cette VM là, à moins de modifier la clé manuellement.

Par ailleurs, ajouter une VM sur le serveur de backup nécessite aussi de rajouté la clé publique manuellement sur le serveur backuppc.

L'optimisation des valeurs d'apache pour éviter la surconsommation de ram n'a probablement pas été mise dans le rôle ansible, le nouveau serveur ne l'avait plus, je l'ai fait à la main
fichier /etc/apache2/mods-enabled/mpm_event.conf
le plus important :

• MaxConnectionsPerChild 100 (pour limiter l'effet fuite mémoire)
• MaxRequestWorkers 40 (pour éviter que le serveur s'écroule en cas de pic de requête)

moins important :

• ServerLimit 40 (nécessaire pour éviter la réservation par défaut de 256)
• MaxSpareThreads 7 (après un micro pic, cela sert a rien de garder + de thread que ce qu'on consomme 99% du temps)
• ThreadsPerChild 8 (on a tellement peu de thread simultanés actifs)

par ailleurs il n'y a pas de www-browser nécessaire pour apachectl2 status
j'ai regardé sur osm117, c'était le paquet firefox-esr qui fournissait la dépendance
ne sachant pas si c'était voulu d'avoir si lourd pour si peu, j'ai installé temporairement links pour tester, cela suffit.
je te laisse le soin de choisir lequel des 2 tu souhaites :-)

Hello,

Je souhaite maintenir l'application petiteReine initialement écrite par Emmanuel Dewaele https://github.com/Cyrille37/petiteReine

• clé ssh: déjà sur cgiquello@osm101 et cgiquello@osm102
• language : Php
• database : Postgis
• volume : petit
  • files : 1 ou 2 Go
  • db : quelques milliers de poi (parkings vélo) segmentés par commune, mais pour commencer il n'y aura pas beaucoup de communes
• nom de domaine : petiteReine.openstreetmap.fr

Copie d'écran: https://image.slidesharecdn.com/sotmfr2018politiquedelavillecartographieparticipative-180603094058/95/sotmfr2018-politique-de-la-ville-cartographie-participative-8-638.jpg?cb=1528018986

related: edewaele/petiteReine#6

Bonjour,

Serait-il possible d’ajouter le Luxembourg a la liste des pays sur http://download.openstreetmap.fr/replication/europe/?

Merci
David

Histoire de partager les efforts et ne pas avoir le monde entier qui tape sur l'instance maintenue par Komoot, on pourrait peut-être avoir notre propre instance de Photon:

https://github.com/komoot/photon

C'est en gros un ElasticSearch, dont il faut télécharger l'index une fois par semaine (53 Go de données compressées).

https://openstreetmap.fr/piwik/

Sur la page d’osm-fr, rajouter le projet infrastructure aux projets épinglés.

@frodrigo @jocelynj

• comment accèdent-on aux vm osm200/201/202/205/206/207 ? elles ne sont pas dans le dns.
  elles répondent à d'autres hosts ou utilisation de l'ip "en dur" ?
• les hosteurs swappent chaque jour un peu + : > 4Go aujourd'hui
  http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/osm20.openstreetmap.fr/osm20.openstreetmap.fr/memory-year.png
  à cause d'une accumulation de processus
  http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/osm20.openstreetmap.fr/osm20.openstreetmap.fr/processes-year.png
  En regardant d'un peu plus près, il y a :
• plus de 3000 processus sshd en cours d'exécution depuis 2016. les 2/3 sont liés à backuppc. 1/3 est lié à jenkins
• un grand nombre lié à une exécution de nc pour tester le port ssh (une partie semble être lancé par backuppc). un killall nc est probablement un bon début :)
• les serveurs n'ont pas redémarré depuis 2 ans. ce qui veux dire que des patchs de sécurités et de performance ne sont pas effectifs.
• ce serrait peut-être aussi l'occasion de voir pour une maj de l'os (des vm et des hosteurs) et de proxmox

Choses à faire par moi-même sur osm202

Étape 1

• maj OS
• vhost http
• vhost https
• rotate http logs
• PostgreSQL 9.5
• PostGIS 2.2

Étape 2

• test chargement DB
• vues pour style osm_br
• config renderd
• test rendu
• test traitement complet

Étape 3

• upgrade PostreSQL 10 / PostGIS 2.4
• test rendu
• test traitement complet
• install piwik / matomo
• install monit
• install moniteur munin pour renderd mod_tile

Étape 4

• branchement sur base monde
• test rendu
• test traitement complet

Étape 5

• migration stats piwik
• bascule DNS tile.osm.bzh

vérifier s'il y a des choses à importer depuis http://trac.openstreetmap.fr