Forum

Reprise du message précédent

Cool ! Bonne nouvelle pour Mageia

Bonsoir à toutes et tous
La persévérance est essentielle pour surmonter les épreuves. Les équipes de bénévoles qui gravitent autour de cette superbe distribution Mageia ont fait preuve de beaucoup de persévérance pour cette malheureuse panne.
Je les remercie et je leur dis un grand bravo pour cette épreuve.
Merci encore à toutes les équipes qui font de Mageia la plus magique des distributions GNU/Linux.
Gilles

Édité par Gillux33 Le 08/10/2025 à 21h26

Bonjour à tous,
Je me suis posé au fil du temps (de l'indisponibilité des serveurs Mageia) les questions :
1- est-ce que ça coute cher un switch/(routeur ?) et donc en cas de panne, du matériel disponible immédiatement permettrait de remplacer le matériel défectueux très rapidement ? (c'est ce que je fais à mon niveai, avoir plusieurs ordis disponibles en cas de panne)
2- ne serait-il pas possible d'avoir une réplique de secours sur laquelle basculer comme sur la plupart des serveurs configurés en "haute-disponibilité" ?

Je pose ces questions naivement.
Je n'ai aucune idée des moyens necessaires pour les mettre en oeuvre.

zwykx :

1- est-ce que ça coute cher un switch/(routeur ?) et donc en cas de panne, du matériel disponible immédiatement permettrait de remplacer le matériel défectueux très rapidement ? (c'est ce que je fais à mon niveai, avoir plusieurs ordis disponibles en cas de panne)

Ceci est du ressort de notre hébergeur, pas de Mageia.

zwykx :

2- ne serait-il pas possible d'avoir une réplique de secours sur laquelle basculer comme sur la plupart des serveurs configurés en "haute-disponibilité" ?

Notre hébergeur, à titre gratuit, ne nous fournit qu'un seul hébergement. Tous nos serveurs sont derrière le même switch. Ils sont bien sûr sauvegardés, mais quand le composant réseau est en panne, ils sont inaccessibles. Notre blog est hébergé ailleurs et c'est pour ça qu'il a fonctionné. On peut aussi noter qu'il y a un bug dans urpmi. La valeur de $MIRORLIST est codée en dur. Il était donc impossible d'aller chercher cette liste alors que les miroirs étaient fonctionnels. Cela aurait ainsi été plus transparent pour l'utilisateur.

Yuusha :

On peut aussi noter qu'il y a un bug dans urpmi. La valeur de $MIRORLIST est codée en dur.

En quoi c'est un bug et comment faire autrement ?
Il y a l'option --mirrorlist pour redéfinir. Mais il faut un point d'entré...

Jybz :

Yuusha :

On peut aussi noter qu'il y a un bug dans urpmi. La valeur de $MIRORLIST est codée en dur.

En quoi c'est un bug et comment faire autrement ?
Il y a l'option --mirrorlist pour redéfinir. Mais il faut un point d'entré...

Je ne parlerais pas de bogue, mais de point de vulnérabilité.
On pourrait prévoir une liste de miroirs de secours, en "fallback", qui serait sur un autre serveur tel que neru.

Ou en cas d'erreur sur $MIRORLIST, drakrpm pourrait proposer une liste de serveurs qu'il garderait en cache un certain temps et rafraichirait régulièrement.

Yuusha :

Ou en cas d'erreur sur $MIRORLIST, drakrpm pourrait proposer une liste de serveurs qu'il garderait en cache un certain temps et rafraichirait régulièrement.

C'est déjà le cas, mais rpmdrake rafraîchit la liste de toute façon après 5 jours, de mémoire.

Papoteur :

C'est déjà le cas, mais rpmdrake rafraîchit la liste de toute façon après 5 jours, de mémoire.

Je confirme les 5 jours. Si le cache est plus vieux, le rafraîchissement de la liste est lancé.
C'est la variable days-between-mirrorlist-update qui définit le délai
https://gitweb.mageia.org/software/rpm/urpmi/tree/urpm.pm#n53
Elle est utilisée par urpmi pour déterminer si la liste cachée a expiré :
https://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/mirrors.pm#n175

Il faudrait modifier le code pour qu'en cas de liste non accessible, le cache soit tout de même utilisé.

Papoteur :

Il faudrait modifier le code pour qu'en cas de liste non accessible, le cache soit tout de même utilisé.

J'ai ouvert un rapport de bogue : https://bugs.mageia.org/show_bug.cgi?id=34661

Yuusha :

scroll44 :

Des décisions ont-elles été prises : distribution conservatrice, progressiste (cf autre discussion) ?

Aucune décision n'a été prise. Mais on est bien parti sur une sortie Q1 2026. Pour l'instant pas de changement dans l'ADN de la distribution.

...

Y a-t-il des nouvelles ?

Il y a une réunion des dev ce soir.