Suite au
crash du serveur de LinuxFR le lundi 8 Octobre 2007 autant revenir sur les différents besoins qu'il peut y avoir en terme de fonctionnement journalier et comment il serait possible de sécuriser un peu tout cela.
Vous pouvez aussi consulter
SuggestionsLecteurLinuxFR et
SuggestionsRelecteurLinuxFR
Besoins
- le site principal https://linuxfr.org
- un svn pour le code (actuellement il n'y a pas de ML développement ? hormis le https://linuxfr.org/tracker/)
- des sauvegardes régulières
- des statistiques de consultation web
- la possibilité d'informer quand le serveur est indisponible et d'avoir un canal d'informations
- l'utilisation du blog de Fabien a permis de laisser des messages
- cela a induit une certaine surcharge, non ? (il était indisponible le lundi après-midi)
- une mailing-list pour les modérateurs (et relecteurs ?) https://linuxfr.org/tracker/151.html
- la question se posait de l'ouvrir aux relecteurs
- éventuellement avoir des archives (plutôt protégées par mot de passe a priori)
- nouveau besoin : un wiki admodérolecteur voire pour la doc' de LinuxFR
- une tribune pour les moules https://linuxfr.org/board/ cf. SuggestionsTribuneLinuxFR privées de leur bouchot préféré lors d'un crash
- ne sont pas identifiés les autres besoins tels que http://uucpssh.org/ et les autres vservers et mailing-lists de LUG hébergées sur le serveur (qui pourraient être hébergées par ailleurs)
- redondance des DNS, l'IP 212.27.33.221 en dur dans /etc/hosts n'étant pas suffisante lorsque son proxy réinterroge les DNS...
- actuellement seulement 2 DNS sont configurés (via whois linuxfr.org : NS0.XNAME.ORG NS1.XNAME.ORG)
- utile pour les cas où xname.org est indisponible
Solutions techniques
- Actuellement, LinuxFR tient sur un seul serveur (templeet + base MySQL), le serveur de backup étant en rade (les sauvegardes sont effectuées sur les PC persos des admins)
- si templeet le supporte, déporter la base MySQL sur un serveur "back-office" permettrait de répartir la charge (pas si importante que cela grâce au mécanisme de cache de templeet, visiblement efficace, éventuellement pour les sauvegardes qui pénalisent le site de 3h à 4h du mat' généralement)
- remettre en service le serveur de backup (et prévoir la bascule avec le site principal) semble le plus viable pour avoir une bonne continuité de services (en cas de pépin matériel, mise à jour de debian, autre...)
- https://gna.org et http://tuxfamily.org permettraient de gérer les mailing-list et le svn de manière déportée (et en utilisant les services proposés en standard)
- les ML chez gna peuvent être archivées et protégées par mot de passe IIRC (ou réservées aux inscrits)
- TuxFamily propose des services web en supplément de gna qui ne propose qu'un site statique mis à jour en décalé (via cvs), il y a aussi les mailing-lists (archivées ou non)
- pour gna j'avais proposé à une époque un plan de reprise d'activité
- L'hébergement d'un wiki pour LinuxFR sur TuxFamily permettrait d'avoir :
- un espace utile pour d'autres besoins que le site principal (discussion admodérolecteurs, docs publiques LinuxFR...)
- un espace de communication lorsque le web principal est indisponible
- la rédaction de dépêches à plusieurs (sous réserve de trouver un langage wiki compatible avec celui de templeet, au besoin en modifiant celui de templeet un peu)
- pour la redondance des DNS
- le plus simple est de configurer un bind sur le serveur linuxfr (nécessite un peu d'administration et gestion des mises à jours), en secondaire pour une mise à jour automatique
- possibilité d'utiliser les DNS de TuxFamily.org http://faq.tuxfamily.org/DNS/Fr en déclarant un groupe linuxfr
- en configurant ns1.tuxfamily.net ns2.tuxfamily.net auprès du registrar
- dupliquer la configuration via le https://panel.tuxfamily.org (à garder en cohérence avec xname)
Solutions organisationnelles
- structurellement, les associations du libre manquent de financement (c'est un constat, pas une critique)
- néanmoins, les soutiens ne manquent pas forcément
- les constructeurs sont souvent prêts à donner du matériel
- les hébergeurs fournissent gracieusement la bande passante
- peut-être avoir une page identifiant les besoins concrets (type de matériel, type d'hébergement, bande passante / charge relevée tous les 6 mois)
- il serait peut-être possible d'avoir une mailing-list des administrateurs des différentes infrastructures afin d'échanger ponctuellement
- j'avais fait ce genre de suggestion sur http://faq.tuxfamily.org/EventRMLL2007/Fr sans prendre le temps de le mettre en oeuvre
- àmha déjà une mailing-list permettrait de s'organiser
- la connaissance de l'architecture de chaque service du libre permettrait de susciter des idées et des vocations d'administrateurs, en fonction des besoins de chaque association
- cela pourrait dynamiser le recrutement
- au besoin cela permet de faire appel à de l'aide ponctuel, en cas de besoin (déplacement sur site, alertes internes sur intrusion...)
j'ai ouvert http://adminlibre.tuxfamily.org (non lié à tuxfamily en tant que tel) voir http://adminlibre.tuxfamily.org/wiki/Presentation/Fr et envoyer un mail à info-request at adminlibre.tuxfamily.org avec subscribe dans le sujet pour s'inscrire à http://listengine.tuxfamily.org/adminlibre.tuxfamily.org/info/