Anomalie #3460: Pouvoir définir des exceptions - eole-debsums - Ensemble Ouvert Libre Évolutif

Anomalie #3460

Pouvoir définir des exceptions

Ajouté par Emmanuel GARETTE il y a presque 14 ans. Mis à jour il y a plus de 8 ans.

Statut:

Terminé (Sprint)

Priorité:

Normal

Assigné à:

Catégorie:

Version cible:

Début:

11/05/2012

Echéance:

% réalisé:

Temps passé:

0.25 h

Distribution:

Description

Aujourd'hui les exceptions sont définis dans le postinst du paquet eole-debsums. Il n'y a pas moyen de personnalisé facilement les exceptions (sauf a forker le paquet EOLE).

Demandes liées

Révisions associées

Révision 46946685 (diff)
Ajouté par Walid Nouh il y a presque 14 ans

see #3460 Use LDAP paged results available in PHP 5.4

Historique

#1 Mis à jour par Daniel Dehennin il y a presque 14 ans

Assigné à mis à Daniel Dehennin

Il ne doit pas y avoir d’exception. ;-)

Je n’ai ajouté dans le source:debian/eole-debsums.postinst?rev=dist/ubuntu/lucid/master que des choses pour lesquels des demandes sont déjà renseignées:

#3314
#3336
#3365
#3368

Il existe une bonne pratique pour gérer des fichiers qui doivent/peuvent être modifiés par l’utilisateur, cf une note dans une autre demande.

Donne moi ton avis mais pour moi ça sera -> pas un bug

#2 Mis à jour par Daniel Dehennin il y a presque 14 ans

Statut changé de Nouveau à En attente d'informations

#3 Mis à jour par Emmanuel GARETTE il y a presque 14 ans

Je patch wordpress mais je ne veux pas forker wordpress-apps. Je n'ai donc pas de moyen de dire "oui je patch et j'assume" pour le moment (sauf à modifier le fichier dans le conteneur).

Un truc automatisable depuis un Zéphir serait bien.

#4 Mis à jour par Daniel Dehennin il y a presque 14 ans

J’espère que ce n’est pas un patch upstreamisable ;-)

Upstream dans le sens eole ;-)

Dans la mesure où le fichier /etc/debsums-ignore n’est jamais supprimé, mais géré par des echo >> et des sed //d.

Je ne pense pas qu’il soit une bonne idée de facilité les comportements déviants.

Si un admin sur un zéphir balance un .py modifié, il se rendra vite compte que ça ne passera pas inaperçu.
S’il peut facilement « cacher son caca » alors l’intérêt de mettre eole-debsums en place devient nul AMHA.

L’utilisation première c’est quand même de pouvoir facilement voir si un utilisateur qui se plaint d’un comportement étrange des outils EOLE ne serait pas la raison de dysfonctionnement.

#5 Mis à jour par Emmanuel GARETTE il y a presque 14 ans

Si l'agent est tout le temps en rouge, il n'apporte pas plus d'informations pertinentes.

Sinon : http://dev-eole.ac-dijon.fr/issues/2360

#6 Mis à jour par Daniel Dehennin il y a presque 14 ans

Si l’agent est tout le temps en rouge, c’est qu’il y a toujours des fichiers de paquets modifiés.

C’est sûrement ennuyeux pour l’administrateur que le status soit rouge, mais je dirais que c’est fait exprès.

Rendre configurable la liste des exclusions va conduire à des « .* » et cela signifiera encore moins, et surtout cachera des choses.

#7 Mis à jour par Emmanuel GARETTE il y a presque 14 ans

Pour résumé, il y a deux idées :

- informer l'utilisateur des fichiers modifiés sur le serveur ;
- ne pas alerté sur la présence d'un fichier modifié mais qui est modifié volontairement.

Une nouvelle proposition serait d'avoir une liste de fichier par conteneur ne générant pas d'alerte. Les fichiers sont donc visible dans l'interface, mais il laisse le conteneur "vert". Si un fichier modifié n'est pas présent dans cette liste, le conteneur passe alors au rouge.