Hébergements de sites web

A rédiger : les idées et concepts que nous désirons faire apparaitre dans les conventions d'hébergement.

Objectif : proposer des hébergements de qualité, modernes, stables et sécurisés, avec une plus-value : l'installation et la maintenance des logiciels de gestion (CMS)

Résultat réunion responsables régionaux 7 avril

Nous devons héberger mieux. Deux possibilités :

• Héberger moins : ce n'est pas à nous de définir ce qu'il faut héberger ou pas... On fera tout de même passer le message que les hébergements de site web sont chronophages et demandent de bonne compétences en sécurité

• Industrialiser : il faut qu'on se mette d'accord sur les modèles et procédures d'hébergement de nos sites. On doit pouvoir se mettre d'accord sur la façon d'installer un SPIP, un Moodle, un EPrints, un PMB, un Local, un Drupal, un Python/WSGI, etc.

Rappel de "Savoirs en partage" : il faut que les sites à contenu scientifiques soient "moissonnables". Savoirs en partage utilisera des techniques classiques (genre OAI) et donc il faut qu'on regarde comment installer correctement des outils tels que EPrints, Lodel, Moodle, etc... pour qu'ils exportent les données de type OAI (cf http://fr.wikipedia.org/wiki/Open_Archives_Initiative)

Volontaire pour coordonner ce projet : MoussaNombré.

mes idées en vrac (Thomas Noël)

• systèmes LAMP. Services annexes :
  • hébergement DNS (assistance)

  • hébergement mail (pré-requis => accès imaps, smtp/submission et webmail) + mailman (à étudier : virtualhost)

• ok pour les sites statiques (mais bon, ça devient rare)
• quotas de volume d'hébergement : bien difficile à gérer (quota sur base MySQL ??)

  • -- WillyManga 2010-03-25 17:46:03

    • Quota MySQL (nombre de tables et/ou taille des tables) ?
    • Autre type de quota, doit-on prendre en compte la bande passante utilisée par le serveur ?
• hébergement sans garantie, l'AUF se contente de gérer au mieux. contraintes locales fortes.
• possibilité d'hébergement montreal (hypertech) ou paris (ovh ?) : solution à mettre en place, coût ? plutôt aider à l'appropriation de solutions commerciales pré-existantes ?

• éviter les hébergements bas niveau, c'est-à-dire où le partenaire doit installer lui-même son site et le logiciel qui le gère. Il est plus pertinent de proposer des logiciels de gestion de contenus. D'une part, parce que les partenaires qui savent gérer eux mêmes leurs outils n'ont souvent pas besoin de nous pour être hébergés. D'autre part parce que cela assure une stabilité et une continuité du service. Exemple : on installe une seule fois le moteur SPIP et on met tous les sites de type SPIP dessus. Chaque site a son design et son contenu propres, et techniquement l'AUF assure une stabilité et une mise à jour. On héberge mieux et on peut héberger plus.

• dans notre offre d'applications (CMS) : uniquement des systèmes réputés stables, maintenus avec suivi de sécurité, à moteur multisites. L'AUF se reserve le droit de bloquer un site qui présente un risque de sécurité.

• la convention doit avoir une date de fin. Gratuit ou pas, l'hébergement doit être proposé pour un an (deux max). Cela permet de nettoyer les sites qui n'ont plus de convention (ceux qui n'ont pas été payés, ceux qui n'ont plus de responsable, ceux qui ont été oubliés par leur initiateurs, etc.). Cela oblige mécaniquement un inventaire à jour, on ne perd plus de vieilles conventions d'il y a 10 ans au fond d'un répertoire ou d'un tiroir.

• pas d'accès FTP : c'est un vieux protocole qui fait passer les mots de passe "en clair" sur le réseau. N'importe qui sur la chaine de transmission peut intercepter le mot de passe. C'est devenu définitivement risqué avec les réseaux sans fil.

Systèmes que l'on sait / que l'on peut héberger :

• nom	version à installer	versions supportées	référent° technique	référent° fonctionnel
  SPIP	2.0.x	2.0.x	ZAP:JC
  Lodel	0.9 (rc)	0.7
  EPrints
  PMB			ZAP:JC	ZAP:VũĐỗQuỳnh
  Greenstone
  Moodle			ZAP:JC	ZAP:NguyễnTấnĐại
  Claroline
  Scenari

Voir https://cnf.auf.org/tiki-index.php?page=Production+de+contenus+scientifiques+en+ligne

• ° Personne ayant des compétences dans ce domaine et que l'on peut contacter en cas de souci. Le référent technique a des compétences dans l'installation et la configuration technique de l'outil (côté serveur). Le référent fonctionnel a des compétences dans la configuration fonctionnelle et l'utilisation de l'outil (via son interface utilisateur).