Chapril:201609 chaton ou non
De April MediaWiki
Aller à la navigationAller à la recherche
Backlinks:
http://pad.april.org/p/aprilcamp201612
https://pad.april.org/p/20161210_chaton
https://pad.april.org/p/chaton_ou_non
http://pad.april.org/p/20170516_materiel_chaton
Pad afin d'aider à se poser les questions sur la question de "chaton ou non"
Réunion lors de l'april camp : https://pad.april.org/p/20161210_chaton
Quels services proposer dans un premier temps ?
Liste qui peut aider à la réfléxion : https://degooglisons-internet.org/list
Framapad, Framacalc, Framaforms, Framagenda, Framadate, Framaboard,
Framindmap, Framavectoriel, Framabee, Framasphère, Framateam, Framalistes,
Framatalk, Framavox, Framemo, Framanotes, Framabag, Framanews,
Framacarte, Framagames, Framinetest, Framadrop, Framabin, Framapic,
Framalink, Framadrive, Framagit, MyFrama.
madix: commencer peut-être par installer des services qui sont
* relativement simples à installer et à gérer
* pas trop sensibles en terme de disponibilité, données
* usage assez répandu
* edausq: un besoin pour les membres de l'april (comme le pad, typiquement)
* Par exemple : pad, raccourcisseur d'url, gestionnaire de dates de réunion et de sondage, partage de presse-papier
* Pad (déjà existant sur pad.april.org)
* edausq : +1. déjà en place, migration à étudier. service assez utilisé dans l'april
* Hebergement de fichiers, d'images, de pièces de code
* Organisation de rendez-vous
* Partage de presse-papier
* email + webmail
* edausq : -1. Compliqué de gérer toutes les contraintes liées au émails. Beaucoup de responsabilité niveau disponibilité du service
* madix: pas d'hébergement d'email, c'est un outil trop sensible à gérer
* PoluX: pas pour le moment, en tout cas.
* Vx : le webmail peut-être décoréllé du mail, on peut proposer un webmail qui se connecte en IMAP à Googel ou autre
* Salons Jitsi (framatalk)
* + enjeu majeur car incite à ne pas utiliser Skype !
* + faible stockable de données car tout salon vide est purgé
* - utilise de la bande passante
* - c'est un peu plus qu'installer un site en PHP note de guerby : jitsi ya juste un echo > ...source.list; apt-get install et rien d'autre https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
* Agrégateur RSS évolué (genre https://github.com/samuelclay/NewsBlur/)
* Listes de diffusion (sympa) (note de guerby : le mail ca prends du temps, mode pompier sur les mailing list plutot recurrent quand un gros change sa politique MX)
* forums genre discuss
* Url shortener
* Galeries photos (certes ça bouffe mais si d'autres chatons le font on a intêret à distribuer la charge)
* Vidéos (certes ça bouffe mais si d'autres chatons le font on a intêret à distribuer la charge) note de guerby : on a la capa systeme (disque + reseau) a tetaneutral.net mais pas d'admin/dev avec une solution libre pour heberger, collaboration possible :)
* Forge (note de guerby : echos positifs sur https://pagure.io/pagure le dev principal pingou est a Toulouse, va etre utilisé par Fedora
* Piwik
* Spamotron^w gestionnaire de pétitions
* client web IRC note de guerby : kiwiirc tres bien
Qui s'occuperait de l'installation/documentation/maintenance ?
* uniquement les admins de l'April
* un ensemble d'admin chaton
madix : un ensemble d'admin chaton avec participation d'au moins 1 admin sys du SI de l'April
madix : l'admin sys en chef de l'April doit pouvoir valider les décisions prises par l'équipe admin chaton
madix : il vaut mieux commencer avec un petit groupe de personnes de confiance pour l'admin chaton
madix : l'ajout d'un admin chaton doit pouvoir être validée par l'admin sys en chef ?
madix : le SI chaton doit être sur des machines physiques distinctes du SI April (pour la partie production au moins); à avoir pour les backups et pour le monitoring
madix : il serait bien que le SI chaton suive au plus près les règles d'organisation du SI April
PoluX: perso je trouve qu'en terme de méthode, l'adminsys april a mis au point une orga de bonne qualité, adapté aux ambitions et contraintes du groupe. Je pense que tant que rien ne poussera à l'inverse, les méthodes chatons devraient s'inspirer des méthodes adminsys april. Dans le futur, le cas échant, une évolution des méthodes chatons devraient interroger une évolution des méthodes adminsys april.
Cpm : le SI de l'April ne doit jamais être impacté par le chaton => deux équipes distinctes, mais rien n'empêche à un admin-sys d'être aussi chaton-sys
Gestion des accès ?
1. bastion de l'April
* - - non respect de la séparation des plateformes
1. bastion dédié
* - lourd en configuration
* - utilité ?
1. pas de bastion, accès direct
* + gestion légère (juste du routage sur l'hôte)
* - chaque machine doit être « blindée » (mais bon
edausq : bastion de l'April, cela me semble correcte
Cpm : le SI de l'April ne doit jamais être impacté par le chaton => non usage du bastion de l'April <= Idem (PoluX) <= idem guerby
Cpm : utilité d'un bastion pour le chaton ?
* PoluX: perso je trouve ça utile. Pas nécessairement pour l'aspect sécurité, mais parce que ça fait un point d'entrée unique, donc simple.
madix : les admins sys de l'April doivent-ils avoir accès au SI chaton ?
* PoluX: perso je répondrait « pas automatiquement ». Mais j'ai l'impression que aucun adminsys actif de l'équipe actuelle regarde chatons sans intérêt. :-)
Quelle infrastructure pour les services ?
1. intégré au SI de l'April
1. isolée complétement
* edausq : limite les risque qu'un service chaton impacte sur la stabilité du SI de l'April
madix : voir ci-dessus
Cpm : le SI de l'April ne doit jamais être impacté par le chaton => non intégré au SI de l'April <= idem (PoluX)
Quelle infrastructure pour les sauvegardes ?
1. identique aux sauvegardes du SI de l'april
1. sur le même serveur que le SI de l'april, mais séparé au niveau du backupcc
1. isolée complétement
edausq : option 2 : peut-être un bon compromis, mais risque qu'un chaton fasse exploser le serveur de backup du SI
Cpm : le SI de l'April ne doit jamais être impacté par le chaton => non intégrée au SI de l'April
PoluX: Perso l'option 2 (service séparée sur machine mutualisée avec l'April) me convient mais l'option 3 (machine dédiée) se défend. Le stress disque ou les quotas disques peuvent imposer l'option 3. note de guerby : tetaneutral.net peut aider la dessus
Quelle infrastructure pour le monitoring ?
1. inciga de l'april
* edausq : pourquoi pas ?
1. sur le même serveur que le SI de l'april, mais séparé au niveau du Icinga
1. isolé complétement
Cpm : le SI de l'April ne doit jamais être impacté par le chaton => non intégrée au SI de l'April
PoluX: Perso l'option 2 (service séparée sur machine mutualisée avec l'April) me convient mais l'option 3 (machine dédiée) se défend. Le stress CPU peut imposer l'option 3. guerby :idem ci dessus
Quel besoin en ressources matériel ?
* combien de serveurs ?
* 1 serveur
* edausq : plutôt de cet avis. lequel ?
* 2 serveurs pour un système de haute disponibilité
PoluX: s'il est facile de passer de 1 à 2 avec DRDB, je ne suis pas contre commencer à 1. Sinon je préfère partir sur deux srv avec DRDB.
* quelle quantité de ressources ?
* PoluX: il faut un srv avec un proc capable de supervision. L'entrée de gamme en la matière est avec 32Go de ram et 1 To de disque raid. Amha ça suffit pour commencer tant qu'on n'héberge pas de la vidéo.
Domaine ou sous-domaine dédié ? Exemple pour service "pad"
1. pad.april.org (sous domaine direct)
* - pas assez chaton
* trop lié au SI de l'April
1. pad.chaton.april.org (sous domaine de l'ensemble chaton.april.org)
* - trop long
* - dépendance au SI de l'April
* + économique
* + pratique en admin-sys
1. pad.chaton-april.org (sous domaine d'un domaine dédié chaton)
* + indépendance au SI de l'April
* + économique (un seul domaine à payer)
* + pratique en admin-sys
1. pad.apr1.org (sous domaine de notre domaine existant pour les url courtes)
* - pas assez chaton
* - trop lié au SI de l'April
1. pad-april.org (domaine dédié par service chaton)
* edausq : intêret ?
* edausq : là où je travail, on a eu des soucis sur un service d'hébergement de fichier qui était sur un sous-domaine du site principal, cela avait des impacts niveau moteurs de recherches (un site qui héberge du phishing/virus perd au niveau de son classement)
* - pas économique (si 20 services alors 20 x 15 €)
1. prefixpad.org (choix d'un préfixe puis ajout d'un nom, comme chez Framasoft)
* super parlant (voir l'exemple de Framasoft)
* - pas économique (si 20 services alors 20 x 15 €)
1. pad.aprilibre.org
* + indépendance au SI de l'April
* + économique (un seul domaine à payer)
* + pratique
* + domaine chatonique et apriliant
1. april.xxx (comme april.org mais en remplaçant .org par une autre extension)
* april.io
* april.cat (déjà pris)
* april.chat
Cpm : c'est quoi la différence entre 3 et 7 ?
Cpm : les 3 et 6 semblent sortir du lot
madix: 2, 3 (trouver éventuellement un autre nom que chaton-april, mais ça pourrait faire l'affaire) ou 6. A voir. Le service de raccourcisseur d'url devra peut-être avoir un nom court (vu le but du service)
PoluX: idem que madix
guerby : 3 cool
Suivi des incidents
La charte indique : "le CHATON s’engage à publier un journal des incidents techniques des services"
Quel outil pour ce besoin ?
1. Twitter
1. Diaspora
1. Mantis
1. Redmine
1. Bugzilla
1. un site dédié
benj: Un bugotron quelconque ? Mantis, redmine ?
PoluX : faudra un canal unique et fiable (indépendant de l'infra) de remontée d'info (ack du problème, annonces de suivi).
PoluX : j'aimerais à titre perso que ce ne soit pas Twitter qui fournisse ce service.
Cpm : du libre, que du libre donc pas Twitter.
Madix : si c'est pour informer les utilisateurs, il faut utiliser les canaux d'information de l'April (identi.ca, twitter, irc...). Si c'est pour les remontées d'incidents à destination des admins, c'est à l'outil de supervision de gérér ça
PoluX: La page du gdt devrait indiquer l'état des services et la timeline des incidents et interventions ; genre comme chez gandi : https://status.gandi.net/ Cette page devrait être buildé et hébergée sur le SI de l'April.
PoluX: d'autres points sur un pad à part : https://pad.april.org/p/chaton_suivi_incident
Technologie de séparation des services (containers, vm)
* kvm (idem que pour le SI de l'April)
* + proche de l'infra du SI de l'April
* + nombre limité de VM
* + pas besoin de formation spéciales pour les admin-sys
* + c'est une machine entière
* + interface de gestion simple à distance
* docker
* + permet d'héberger plus de containers
benj: au plus proche de l'infra actuelle pour éviter d'avoir a dupliquer les compétences
madix: pareil que benj, le SI chaton doit être au plus proche de l'infra du SI April
polux: idem
Cpm : kvm parce que simple et suffisant
Nommage
a) Quel va être le nom « public » du chaton ?
b) Utilisation d'un préfixe sur le modèle de Frama* ?
c) Le CA validera-t-il le nom ?
Critères important :
* être chatonesque
* être aprilesque
Collecte de suggestions :
* alapril.org
* adapril.org
* appril.org
* aprilesque
* évocation de applications
* aprilibre.org
* + apriliant
* + d'esprit chatonique
* - confusion possible avec aprixlibre
* => acheter aussi aprixlibre.org et rediriger
* aprilien.org
* apriliens.org
* aprilmia.org
* aprilmiaou.org
* aprilapp.org
* aprilapps.org
* aprilesque
* évocation de applications
* aproil.org
* bolapril.org
* catapril
* + catapril.org disponible
* + cat => chat en anglais, cat => catalogue, cat => commande pour concaténer
* + april dans le nom
* - ce nom, ça pourrait être la cata
* cetapril.org
* 7april.org
* chadapril
* chaton
* + parce qu'il n'y en aura qu'un
* chapardil
* car les chats sont chapardeurs
* chapril
* + chapril.org disponible
* + april dans le nom
* + chat dans le nom
* => acheter aussi chatpril et rediriger
* Centre d'Hébergement Aprilien Pour le Respect d'une Informatique Libre (+++)
* CHaton Aprilien Pour le Respect de votre Informatique et de vos Libertés
* Chaton Aprilien Pour le Respect d'une Informatique Libre
* charpil
* chaton-april
* + chaton-april.org disponible
* + april dans le nom
* + chat dans le nom
* coapril.org
* colapril.org
* corapril.org
* elgoog ;-)
* lirchap
* mayo
* le mois juste après april
* miaou
* - miaou.org non disponible
* - pas april dans le nom
* miapril.org
* misstach, moustache au féminin!
* monapril.org
* parapril.org
* parlich
* pirchal
* ronron
* + ronron.org disponible
* - pas april dans le nom
* schrodapril, on ne sait pas s'il est allumé ou éteint
* Siamapril
* votre jumeau informatique (pour siamois).
* soapril.org
* tachons.org
* tonchabril
* vivapril.org
* yakapril.org
* zetalapril.org
* zetapril.org
Choix du tld
* contrainte de choisir un tld géré perénnement
* attention au frein d'accès pour l'utilisateur si tld exotique => .org serait plus sûr
* propositions :
* bio
* cat
* org : +++++
=> privilégier le tld .org
Groupe de travail
a) Un groupe de travail va-t-il être créé ?
b) Quel va être le nom du groupe de travail ?
c) Qui sera l'animateur du groupe de travail ?
Cpm : pour un groupe de travail dédié, différent du groupe de travail admin-sys, même si des membres sont dans les deux.
madix : on peut appeler ça un groupe de travail, un bidule, un machin, c'est avant tout un projet :) Avec donc un animateur et des membres
PoluX: pour lancer une procédure de création de groupe https://wiki.april.org/w/Charte_des_groupes en attendant, discussion sur admins@
Nature des machines physiques
Quelle sera la nature des machines physiques ?
a) achetées,
b) louées,
c) cloudée (exemple : Gandi)
PoluX : Cloud Gandi incompatible car stack propriétaire
PoluX : Cloud OVH a des problèmes de fiabilité en ce moment
PoluX : le nouveau SI de l'April s'appuie sur de la location de serveurs dédiés, ça le fait donc ça peut le faire pour le chaton
Cpm : la location de serveurs dédiés a des avantages en termes de flexibilité, rapport qualité/prix et fiabilité
Madix : même chose que pour le SI de l'April : location de serveurs dédiés, nous ne pouvons pas gérer de l'intervention humaine en datacenter en mode bénévole
PoluX: idem
Hébergement des machines physiques
Où seront hébergées les machines physiques ?
a) acteur majeur (OVH, Online.net, Gandi…),
b) prêt de baie,
c) alternatif (FDN, FAI Maison, TuxFamily…), tetaneutral.net au moins pour backup:)
PoluX : les choix qui ont été fait pour l'April (location Online) reposent sur des prémisses qui sont valides pour l'infra à venir.
Cpm : l'alternatif est tentant mais implique un coût supérieur (bande passante, etc.)
Cpm : Online/OVH sont des solutions éprouvées
Cpm : entre chatons, essayer de choisir des centres différents
Madix: les choix faits pour le Si de l'April restent valables pour le SI chaton
PoluX: avoir en particulier à l'esprit que en tant que bénévole, on ne peut pas facilement courrir dans les datacenters, ni courir après les pièces en priant pour leur compatibilité en cas de remplacement. Donc à moins de monter un cœur de réseau à l'intérieur d'une sympathique maison du libre ou nous serions chez nous avec un pool de machines homogène, ya peu de possibilités mieux que la location.
Stratégie d'équipe (poly vs mono vs anar ?)
a) approche « poly » : tous les admin-sys s'occupent de tous les
services et de toutes les machines ; en général cette approche fait fuir
car les responsabilités sont trop grandes,
b) approche « mono » : des équipes de binômes sont créées pour s'occuper
spécifiquement d'un service chacune ; l'avantage serait un recrutement
plus facile d'admin-sys qui verraient leur charge minimisée et
maîtrisable, en échange d'une implication réactive et concrète,
PoluX : on est libre dans notre implication
Cpm : mono pour tester l'approche et voir si ça pourrait être viable pour d'autres domaines
madix : peu m'importe
Vx: Auto-gestion
Délai d'intervention
Le chaton reposant sur des bénévoles, en cas d'incident, quel délai
d'intervention serait annoncé aux utilisateurs ?
PoluX : sur le délais, best effort.
PoluX : utile d'être clair sur les infos de service (état, incidents, maintenances/interventions).
madix : on ne peut pas s'engager sur un rétablissement de services en un temps donné. Le projet Chaton April sera avant tout bénévole, donc on fera au mieux
Limite budgétaire
À la louche, en se basant sur les prix Online.net et OVH et en perspectivant une architecture banale, on peut imaginer qu'il y aura
environ 3 serveurs pour 90 € par mois et peut-être une dizaine de noms de domaine par an. Ça ferait dans les 90*12+15*10 = 1230 € / an. En cas
d'hébergement alternatif, ça sera plus cher (guerby : pas forcement). Du coup, quelles limites budgétaires annuelle est donnée au projet chaton April ? 500 € ? 1000 € ? 2000 € ? 3000 € ?
Cela sera-il un critère important dans le choix de l'architecture de la plateforme ?
PoluX : ça sera un critère de choix, oui. Par exemple, nos budgets excluent une location de baie dans laquelle on viendrait placer nos propres serveurs.
Madix : on reste dans la logique choisie pour le SI de l'April
PoluX: on pourrait aussi collecter des dons fléchés. On pourrait par exemple mettre un discret baromètre en suraffichage dans un coin de chaque appli (sous réserve que ça ne neutralise pas de boutons) appelant au don et montrant nos capacité à financer les serveurs et autres dépenses à prévoir. Un peu comme le faisait dogmazic à la grande époque ( https://web.archive.org/web/20080311004710/http://www.dogmazic.net/index.php?op=edito ).
IPV4 vs IPV6
À terme, blabla, faudra y passer :
* ipv4 seulement
* ipv4 pour l'instant + ipv6 dès que possible
* ipv6 seulement
* - n'a pas de sens car tout le monde n'est pas en ipv6
* ipv4 + ipv6
Cpm : si on pouvait prévoir dès le début ipv4 + ipv6, ça serait bien, il s'agit juste de « routage » des ports 80 et 443
PoluX: perso ça me va de maintenir du IPv6 par contre je ne suis pas compétent aujourd'hui pour le déployer. Ceci étant ça me semble d'une utilité limitée pour dans le cas d'une infra (essentiellement) d'hébergement web qui passe par un unique bastion en entrée. (idem pour le mail si c'est avec un bastion d'entrée)
Cpm : va bien falloir mettre fin à l'ipv4 un jour…
guerby: sur un projet citoyen je dirai obligatoire dual stack :)
HTTP vs HTTPS
Le HTTPS-Only Standard prône de n'utiliser que du HTTPS pour toutes les pages de tous les sites.
Voir : https://https.cio.gov/
1. HTTP seulement
* - n'a pas de sens car transit de mots de passe…
1. HTTP + HTTPS
* - problème des mix-content
* - lourd à gérer du point de vue admin-sys
1. HTTPS seulement
* - n'a pas de sens car ignorer les requêtes HTTP met une barrière aux utilisateurs
* - simple de rediriger les requêtes HTTP systématiquement vers le HTTPS
1. HTTPS + redirection de HTTP vers HTTPS systématiquement
* aujourd'hui, gestion des certificats facile (Let's Encrypt)
* + flux sécurisé
* + pas de risque de voir un mot de passe transiter en clair
* + simple à gérer en admin-sys
* + simple à gérer côté webmaster
* + quoique l'utilisateur requête alors bonne réponse donnée
Cpm : la 4) parce que simple et efficace
PoluX : la 2) n'est pas spécialement lourde à gérer. La 4) me va mais tu n'échappera pas pour autant si facilement aux mixed contents, notamment pour les liens de médias externes (c:
Cpm : configuration doublée, fichiers de logs doublés, etc. Pour les mixed-contents, à voir quels services seront incompatibles et c'est à eux de fournir une solution, pas à nous de baisser notre niveau de qualité. :o)
guerby: 4 aussi
Faut-il migrer PAD du SI April vers le SI Chaton ?
* oui : doublon
* non : garantir le fonctionnement de service utiles à l'April
=> non
Qui va gérer les contacts (contact@) ?
* les membres du groupe admin-chaton
Où mettre les listes de diffusion admin-chaton sur le SI ?
* gestionnaire liste de diffusion du SI de l'April
* possible, facile, pratique
* gestionnaire liste de diffusion du SI Chaton
* lourd à installer ?
* gestion manuel de redirection
* bof pour les spams
=> installer un Sympa pour deux listes privées est suffisament simple pour mettre un gestionnaire de liste de diffusion dans le SI Chaton
