FR:Serveurs/Utilisation des serveurs

Totalement en vrac pour l'instant, a structurer par la suite s'il s'avère que ça sert à quelque chose. A l'heure de maintenant, il s'agit encore d'une proposition de sletuffe (talk) 16:56, 4 November 2014 (UTC) qui n'a pas encore été validé par tous les admins

blabla général pour présenter qui peut s'en servir

Si mes souvenirs sont bon, et si mes "collègues" sont d'accord avec ça (ils me corrigeront sinon) : sont acceptées sur les serveurs de osm-fr toute application étant utile au développement d'osm. Et ce, au sens large. La priorité est toutefois donnée à ce qui peut aider les mappeurs à mieux cartographier, mais la mise en avant publique d'outil utile faisant usage des données osm peut aussi trouver sa place.

En clair, si tu es bien dans ce cas, on peut tout à fait te fournir un espace d'hébergement sur un serveur ainsi qu'une url d'accès en xxx.openstreetmap.fr ce qui t'évite d'utiliser le tient, nous permet aussi de mutualiser la maintenance.

Quelques habitudes techniques à avoir

compte d'accès ssh

• clé public ssh = c'est mieux
• chacun à un compte à son nom
• chaque outil à un compte dédié, et on passe de son user à ce compte par sudo

Accès IPv4

Si vous n'avez pas l'accès IPv6 utiliser l'hôte du cluster comme proxy IPv4-IPv6.

ssh -t -A <user>@<proxy>.openstreetmap.fr ssh <user>@<target>.openstreetmap.fr

logique de l'arboresence sur chaque serveur (ou presque)

• /home/$user -> le dossier $home du user, on fait ce qu'on veut dedans, mais je (sletuffe (talk) 16:56, 4 November 2014 (UTC)) suggère de ne rien mettre en prod dedans ni de gros trucs (+30Go)
• /data -> plein d'espace là dedans
• /data/project -> sauvegardé à distance, on évite donc les trucs temporaires, le cache ou ce qui peut être facilement retéléchargé et gros re-construit (genre les tuiles, les logs, les fichier shape, les resultats de calculs)
• /data/project/<nom du projet> -> un dossier par projet avec proprio = compte du projet (code source, vhost de site, traitement cron, data de petite taille (<1Go) ou difficile à reconstruire
• /data/work/ -> non sauvegardé. Tout là dedans doit pouvoir être perdu sans crier ARRRRGGHH
• /data/work/<nom du projet> -> un dossier par projet (facultatif) avec proprio = compte du projet (logs, tuiles, données qu'on peut reconstuire, téléchargement temporaire, ...)

Accès aux bases de données "communes" (à plusieurs projets)

A définir

Comment choisir sur quel serveur mettre quel outil

Service avec accès à une des bases de donnée en commun

Comme serveur, sauf si le débit SQL à faire passer entre l'appli et la base de donnée est très élevé, je suggère fortement l'hébergement ailleurs que sur un des serveurs de base de donnée. Car :

• En cas de mise à jour de toute la distribution du serveur de BD, ça

n'impacte pas ou peu l'appli

• En cas de panne du serveur de base de donnée, on peut basculer sur celui de

redondance

Services lourds en accès base

Ceux là, ben par contre, vaut peut-être mieux les mettre au plus près des serveurs de bdd, voir sur le serveur de bdd carrément (cas des services de rendu carto)