Matériel: x86 distant Version de YunoHost: 11.0.10.1 J’ai accès à mon serveur : En SSH | Par la webadmin Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui Si oui, expliquer: Création d’un fichier durcissement.local dans /etc/fail2ban/jail.d pour (notamment) allonger les durées de ban/findtime :
Logwatch me renvoie régulièrement un soucis avec fail2ban, voir cet extrait de /var/log/fail2ban.log :
2022-10-18 07:16:09,985 fail2ban.filter [751827]: WARNING [funkwhale] Simulate NOW in operation since found time has too large deviation None ~ 1666070169.9859133 +/- 60
2022-10-18 07:16:09,986 fail2ban.filter [751827]: WARNING [funkwhale] Please check jail has possibly a timezone issue. Line with odd timestamp: 80.67.172.144 - - [18/Oct/2022:07:16:09 +0200] "GET /.well-known/ynh-diagnosis/9005a78a9e1d55ba HTTP/1.1" 200 0 "-" "Python/3.6 aiohttp/3.6.2"
L’IP en question est celle de yunohost.org et a lieu une fois par jour (vers 07H00 ou 19H00) => a priori ça vient du diagnostique automatique, mais pourquoi f2b couine comme ça ?
Il s’agit juste d’un warning, tu peux l’ignorer. J’ai le même avertissement avec Nextcloud depuis le passage sur yunohost 11, mais c’est lié à la version de F2B et ça n’a rien à voir avec yunohost.
Plus d’infos dans ce lien
Ca reste anormal. J’avais fait un peu de recherches avant d’ouvrir ce sujet, la problématique sur ton lien semble différente : il y a un délai de plusieurs minutes entre la tentative de log et le message f2b, ce qui n’est pas le cas ici (moins d’une seconde).
Je crois comprendre que d’un côté c’est l’heure locale, de l’autre l’heure UTC. C’est la 1ère ligne de log qui me fait penser à ça:
date -d @1666070169.9859133 -u +%X
05:16:09
Pour contourner, il faudrait essayer avec logtimezone=UTC. Par contre je ne sais pas pourquoi ça ne le fait qu’avec cette jail et pas les autres. Il faudrait creuser un peu pour trouver la raison.
