« Équipe sysadmin » : différence entre les versions
Aucun résumé des modifications |
(→Personnes motivées : test) |
||
Ligne 4 : | Ligne 4 : | ||
* [[Utilisateur:Arathor|Arathor]] | * [[Utilisateur:Arathor|Arathor]] | ||
* [[Utilisateur:Arathor|Arathor]] ([[Discussion utilisateur:Arathor|discussion]])Arathor[[Utilisateur:Arathor|Arathor]] ([[Discussion utilisateur:Arathor|discussion]]) | |||
* (rajoutez-vous si zêtes motivés) | * (rajoutez-vous si zêtes motivés) | ||
Version du 9 septembre 2020 à 01:43
Équipe chargée de l’administration système
Personnes motivées
- Arathor
- Arathor (discussion)ArathorArathor (discussion)
- (rajoutez-vous si zêtes motivés)
Todolist
Quota sur Tuxfamily
- Lors du dernier dépassement (fin août 2020), y’avait plus de 170m occupé par des données awstats que personne regarde/utilise. Il faudrait les pruner automatiquement (à chaque instant, garder que genre les 6 mois précédents), voir même les désactiver complètement.
- Les 2/3 de notre espace est mangé par les dumps de DB.
- On a peut-être pas besoin de garder dans la DB du wiki toutes les révisions des votes à répétition, y’a plus de 10 ans, pour inverser 2 touches. On pourrait aussi enlever les comptes qui n’ont eu aucune inactivité depuis plus de 10 ans, etc.
- Sans avoir fouillé pour l’instant, j’ai un peu de mal à comprendre comment le dump d’un forum pas super actif peut dépasser les 100m ? putain de forum… au moins la ML pose pas ce problème, gniark :)
- faudrait voir comment automatiser ce nettoyage, sinon dans X années le même problème se reproduira.
MÀJ du wiki
MÀJ du forum
Archives ML
Ce vieux serpent de mer.
FAQ des sysadmins
Pourquoi TuxFamily ?
Pourquoi rester chez TF s’ils nous donnent aussi peu d’espace disque ? Parce que c’est vraiment un élément de stabilité. Avant de venir chez eux, le wiki et la ML étaient gérées comme tout le reste dans le projet, c’est-à-dire de manière anarcho-bordélique. Et c’est pas un bon souvenir.
Tuxfamily c’est pas qu’un hébergeur physique : ils s’occupent aussi de mettre à jour les briques de bases (linux, apache, php, etc). Je suis pas optimiste sur le niveau de sécurité d’un serveur directement géré par Ergodis, encore moins sur la rapidité du retour en cas de panne.