« Équipe sysadmin » : différence entre les versions
(Page créée avec « Équipe chargée de l’administration système ==Personnes motivées== * Arathor ==Todolist== ===Quota sur Tuxfamily=== * Lors du dernier dépassement (fin août 202... ») |
Aucun résumé des modifications |
||
| Ligne 3 : | Ligne 3 : | ||
==Personnes motivées== | ==Personnes motivées== | ||
* Arathor | * [[Utilisateur:Arathor|Arathor]] | ||
* (rajoutez-vous si zêtes motivés) | |||
==Todolist== | ==Todolist== | ||
| Ligne 9 : | Ligne 10 : | ||
===Quota sur Tuxfamily=== | ===Quota sur Tuxfamily=== | ||
* Lors du dernier dépassement (fin août 2020), y’avait plus de 170m occupé des données awstats que personne regarde/utilise. Il faudrait | * 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 pruner automatiquement (à chaque instant, garder que 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. | * Les 2/3 de notre espace est mangé par les dumps de DB. | ||
| Ligne 16 : | Ligne 16 : | ||
** 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 :) | ** 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. | ** 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=== | ===Archives ML=== | ||
| Ligne 21 : | Ligne 25 : | ||
Ce vieux serpent de mer. | Ce vieux serpent de mer. | ||
==FAQ== | ==FAQ des sysadmins== | ||
===Pourquoi TuxFamily ?=== | ===Pourquoi TuxFamily ?=== | ||
| Ligne 28 : | Ligne 32 : | ||
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. | 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. | ||
===On a des sauvegardes ?=== | |||
Version du 8 septembre 2020 à 21:16
Équipe chargée de l’administration système
Personnes motivées
- Arathor
- (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.