Bunch of files that still refer to deleted domains

[LeoBoudet]

Bonjour ! Au fur et à mesure de mes promenades en ssh sur mon serveur je constate par-ci par-là des éléments liés à d’anciennes installations, particulièrement d’anciens noms de domaine et qui n’ont pas été supprimés en même temps que les ndd auxquels ils se rapportent. Par exemple, avec le nom de domaine gnomgnom.fr, j’obtiens :

root@serveur-leo:/# locate "gnomgnom"
/etc/dkim/gnomgnom.fr.mail.key
/etc/dkim/gnomgnom.fr.mail.txt
/etc/yunohost/certs/gnomgnom.fr-history
/etc/yunohost/certs/gnomgnom.fr-history/20190804.135455-selfsigned
/etc/yunohost/certs/gnomgnom.fr-history/20190804.135455-selfsigned/ca.pem
/etc/yunohost/certs/gnomgnom.fr-history/20190804.135455-selfsigned/crt.pem
/etc/yunohost/certs/gnomgnom.fr-history/20190804.135455-selfsigned/key.pem
/etc/yunohost/certs/gnomgnom.fr-history/20190804.135455-selfsigned/openssl.cnf
/home/yunohost.conf/backup/etc/dnsmasq.d/gnomgnom.fr-20190804.135716
/home/yunohost.conf/backup/etc/metronome/conf.d/gnomgnom.fr.cfg.lua-20190804.135716
/home/yunohost.conf/backup/etc/nginx/conf.d/gnomgnom.fr.conf-20190804.135716
/home/yunohost.conf/backup/var/www/.well-known/gnomgnom.fr
/home/yunohost.conf/backup/var/www/.well-known/gnomgnom.fr/autoconfig
/home/yunohost.conf/backup/var/www/.well-known/gnomgnom.fr/autoconfig/mail
/home/yunohost.conf/backup/var/www/.well-known/gnomgnom.fr/autoconfig/mail/config-v1.1.xml-20190804.135716
/var/lib/metronome/gnomgnom%2efr
/var/lib/metronome/gnomgnom%2efr/pep
/var/log/nginx/gnomgnom.fr-access.log
/var/log/nginx/gnomgnom.fr-error.log
/var/log/yunohost/categories/operation/20190804-135455-domain_add-gnomgnom.fr.log
/var/log/yunohost/categories/operation/20190804-135455-domain_add-gnomgnom.fr.yml
/var/log/yunohost/categories/operation/20190804-135455-selfsigned_cert_install-gnomgnom.fr.log
/var/log/yunohost/categories/operation/20190804-135455-selfsigned_cert_install-gnomgnom.fr.yml
/var/log/yunohost/categories/operation/20190804-135655-domain_remove-gnomgnom.fr.log
/var/log/yunohost/categories/operation/20190804-135655-domain_remove-gnomgnom.fr.yml
/var/www/.well-known/gnomgnom.fr
/var/www/.well-known/gnomgnom.fr/autoconfig
/var/www/.well-known/gnomgnom.fr/autoconfig/mail

Au vu de la réponse de @zamentur sur le forum, il semble qu'une amélioration du mécanisme de suppression de nom de domaine soit possible (je pense qu'il serait aussi bon de faire un point au niveau de la suppression des applications Yunohost, car ça m'arrive d'en retrouver des traces également).

Merci pour votre implication,

Léo

[Jaxom99]

Je rajoute un commentaire car ce "souci" m'a causé des erreurs d'upgrade de certaines applis :

• il restait une configuration Nginx d'un domaine, mais pas les fichiers/certifs, du coup le service était en erreur (mais marchait pour les autres sites).
• Du coup, lors du check post-upgrade, les applis pensent qu'elles ont planté nginx et se dé-upgrade en renvoyant une erreur.

J'ai dû nettoyer à la main le fichier pour permettre au reste de repartir comme prévu.

[zamentur]

Apparement ça peut arriver si un fichier nginx est considéré comme manuellement modifié.

[alexAubin]

The thing about manually modified conf file got fixed by https://github.com/YunoHost/yunohost/pull/946

However it's only fixed for the nginx conf (not stuff like e.g. mail autoconf) and there's still this thing that the regen-conf (or domain_add/remove) won't automatically clean up empty folders. But that's really more of a cosmetic thing than a real issue..

[alexAubin]

Duplicate / related to https://github.com/YunoHost/issues/issues/1629

[npalix]

About the mail autoconf, yunohost tools regen-conf nginx --dry-run --with-diff is useless.

I have manually deleted the obsolete config-v1.1.xml files. rm /var/www/.well-known/[domain]/autoconfig/mail/config-v1.1.xml

And then clean up the hierarchy, find /var/www/.well-known/ -type d -empty -delete

Why is the checker noticing an issue while the regen-conf doesn't report anything ?

[alexAubin]

i don't know, you're not explaining the entire context ... what did the "checker" report exactly ...

[npalix]

In Issues found by automatic diagnosis on [domain]

=================================
System configurations (regenconf)
=================================

[WARNING] Configuration file /var/www/.well-known/[domain]/autoconfig/mail/config-v1.1.xml appears to have been manually modified.
  - This is probably OK if you know what you're doing! YunoHost will stop updating this file automatically... But beware that YunoHost upgrades could contain important recommended changes. If you want to, you can inspect the differences with 'yunohost tools regen-conf nginx --dry-run --with-diff' and force the reset to the recommended configuration with 'yunohost tools regen-conf nginx --force'

Despite the fact I haven't edited the file ...

[alexAubin]

Yeah idk, many things can happen that lead to this kind of boring situation, such as Ctrl+C during a command or whatever ...

[npalix]

The weird point is that yunohost tools regen-conf nginx --dry-run --with-diff doesn't report any change. It was for a domain for which I disabled the email support. Could it be the update script that should remove the file ?

[alexAubin]

I don't know, I can't magically guess everything you did on the machine ... Usually what helps in pinpointing a bug is having a step-by-step to reproduce the issue on other systems

[npalix]

With YunoHost 11.1.6.2: 1) Create a new domain 2) Disable emails (which are enabled by default in both ways) for that new domain -> Got a warning about '/var/www/.well-known/[domain]/autoconfig/mail/config-v1.1.xml' manually modified !

Then the diagnosis system reports this each time it runs, mentionning the nginx regen-conf command.

[Ddataa]

see https://github.com/YunoHost/issues/issues/2143

[alexAubin]

Closing, the only remaining issue is https://github.com/YunoHost/issues/issues/2143