Et pas de problème d’identifiants du côté de l’application ? (autrement dit, ces actions n’avaient pas de raison d’être bannies ?)
Pas de problème côté identifiants.
En fait il me semble qu’à chaque suppression d’un article l’action est exécutée et génère une entrée dans fail2ban.
Du coup avec les règles de fail2ban, au bout de 5 articles supprimés je suis banni du serveur pendant la durée paramétrée.
Il faudrait voir, si cette situation peut être reproduite, si ça vient de l’application en elle-même ou de son intégration dans YunoHost.
ppr
Ce qui m’étonne, c’est qu’en faisant la même chose, je n’ai pas de problème, et que personne n’ai signalé le problème. Si c’est une question de configuration de fail2ban dans Yunohost, j’imagine que ça aurait été remarqué par plus de monde 
Tu n’a pas modifié la configuration de fail2ban je suppose ?
Alors côté de la configuration de fail2ban j’ai :
- un port ssh exotique ;
- un bantime et findtime supérieurs à la configuration par défaut ;
- une action plus complète en cas de bannissement (mwl) ;
- une adresse mail spécifique et le sender aussi.
Je vais laisser Wallabag tranquille 24h et je verrai pour ajouter et supprimer un article depuis l’interface web pour voir si j’ai des entrées fail2ban dans Logwatch. Et du coup si c’estppropre à l’application Android ou pas.
ppr
2 Likes
Bonjour,
Alors aucune entrée fail2ban dans mon Logwatch.
Je vais utiliser la panel web et non l’application Android, afin de voir si à l’ajout ou à la suppression j’ai des entrées fail2ban dans mon Logwatch.
Je vous tiens au courant 
ppr
Bonjour,
Il semble que le souci vienne de l’application Android.
Sauf erreur, les ajouts/suppressions faits via le panel web ne génèrent pas d’entrée fail2ban dans le rapport Logwatch.
Par contre, toujours sauf erreur, les ajouts/suppressions faits via l’application Android génèrent quant à eux des entrées fail2ban dans le rapport Logwatch.
Je vais voir pour désinstaller l’application Android, regarder dans le panel web s’il n’y a pas un truc à supprimer vis-à-vis de ça (autorisation, token, ID quelconque), la réinstaller et re-tester le truc.
ppr
De l’application, ou de l’usage de l’API
Faudrait que je re-regarde comment on a configuré fail2ban, pour voir si l’usage des logs de Wallabag n’aurait pas tendance à créer des alertes dans fail2ban…
Bonsoir,
Effectivement, peut-être voir du côté de la configuration de fail2ban, au-delà de l’identification, voir comment se comporte l’API à ce sujet car j’ai encore été banni en utilisant l’application.
ppr
Ok, merci de l’info.
Il faudrait que je fasse plus de tests, d’autant que je ne peux pas reproduire le problème.
Vu la règle qu’on avait ajouté (https://github.com/YunoHost-Apps/wallabag2_ynh/blob/testing/scripts/install#L155) ça semble très surprenant qu’une authentification correcte fasse réagir fail2ban.
Tu as un exemple de message du journal de fail2ban suite à une action via l’application ?
Bonsoir,
Alors je viens de faire un ajout suivi d’une suppression d’un article dans Wallabag depuis l’application Android.
Voici ce que j’ai dans /var/log/fail2ban.log à l’ajout de l’article car quelques minutes après rien à la suppression :
2020-04-16 21:20:41,720 fail2ban.filter [27952]: INFO [wallabag2] Found ip.public.du.smartphone (celle de ma box car en WiFi lors du test)
[edit] : je viens d’archiver un article, et j’ai la même entrée dans le log.
2020-04-16 22:30:32,506 fail2ban.filter [27952]: INFO [wallabag2] Found ip.public.du.smartphone
ppr
Je viens d’essayer, même chose. Pourtant, je ne me suis jamais fait bannir… peut-être que je n’ai pas fait plus de 5 actions via l’API sur le temps imparti, mais ça me surprend…
Et en effet via l’interface web il n’y a rien.
Je ne comprends pas d’où vient le problème.
J’ai trouvé d’où vient le problème.
J’ai ouvert un ticket avec les détails : https://github.com/YunoHost-Apps/wallabag2_ynh/issues/81
Il va falloir qu’on adapte la syntaxe qui filtre les erreurs de connexion.
Je te tiens au jus 
1 Like
@Maniack_Crudelis the changelog in your first message is outdated, maybe it’s better to remove it ? (except if you want to update it, but I guess it’s quite some work)
The first post is all yours
Oh, ok 
Well, I don’t think I’ll have the time to regularly update it, so I’ll remove the changelog part.
Another flawless update, here on my 3.8 VPS. Big up maintainers 
1 Like
Installation looks broken on a 3.8.4.9 instance.
I have tried online and CLI installation. Also tried the testing branch.
There is a mess with fail2ban. Any idea ? Thanks !
184336 DEBUG + ynh_handle_getopts_args --service_name=fail2ban --action=reload ‘–line_match=(Started|Reloaded) Fail2Ban Service’ --log_path=systemd
184336 DEBUG + set +o xtrace
184437 DEBUG + service_name=fail2ban
184437 DEBUG + action=reload
184437 DEBUG + line_match=‘(Started|Reloaded) Fail2Ban Service’
184437 DEBUG + length=20
184438 DEBUG + log_path=systemd
184438 DEBUG + timeout=300
184438 DEBUG + [[ -n (Started|Reloaded) Fail2Ban Service ]]
184438 DEBUG ++ mktemp
184438 DEBUG + local templog=/tmp/tmp.fF0V9WPSTE
184438 DEBUG + ‘[’ systemd == systemd ‘]’
184439 DEBUG + local pid_tail=12588
184439 DEBUG + ‘[’ reload == reload ‘]’
184439 DEBUG + action=reload-or-restart
184439 DEBUG + systemctl reload-or-restart fail2ban
184440 DEBUG + journalctl --unit=fail2ban --follow --since=-0 --quiet
274606 WARNING Job for fail2ban.service failed.
274612 DEBUG + ynh_exec_err journalctl --quiet --no-hostname --no-pager --lines=20 --unit=fail2ban
274612 WARNING See “systemctl status fail2ban.service” and “journalctl -xe” for details.
274713 DEBUG ++ eval journalctl --quiet --no-hostname --no-pager --lines=20 --unit=fail2ban
274714 WARNING [Error] Jul 14 17:20:47 systemd[1]: Starting Fail2Ban Service…
274714 DEBUG +++ journalctl --quiet --no-hostname --no-pager --lines=20 --unit=fail2ban
274714 WARNING Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,670 fail2ban.server [1275]: INFO Starting Fail2ban v0.9.6
274715 DEBUG + ynh_print_err 'Jul 14 17:20:47 systemd[1]: Starting Fail2Ban Service…
274715 WARNING Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,678 fail2ban.server [1275]: INFO Starting in daemon mode
274715 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,670 fail2ban.server [1275]: INFO Starting Fail2ban v0.9.6
274715 WARNING Jul 14 17:20:51 systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.
274716 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,678 fail2ban.server [1275]: INFO Starting in daemon mode
274716 WARNING Jul 14 17:23:31 systemd[1]: Reloading Fail2Ban Service.
274716 DEBUG Jul 14 17:20:51 systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.
274716 WARNING Jul 14 17:24:49 systemd[1]: Reloaded Fail2Ban Service.
274717 DEBUG Jul 14 17:23:31 systemd[1]: Reloading Fail2Ban Service.
274717 WARNING Jul 14 17:28:56 systemd[1]: Reloading Fail2Ban Service.
274717 DEBUG Jul 14 17:24:49 systemd[1]: Reloaded Fail2Ban Service.
274717 WARNING Jul 14 17:30:26 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.
274717 DEBUG Jul 14 17:28:56 systemd[1]: Reloading Fail2Ban Service.
274717 WARNING Jul 14 17:30:26 systemd[1]: Reload failed for Fail2Ban Service.
274718 DEBUG Jul 14 17:30:26 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.
274718 WARNING /usr/share/yunohost/helpers.d/logging: line 20: message: unbound variable
274718 DEBUG Jul 14 17:30:26 systemd[1]: Reload failed for Fail2Ban Service.’
274718 DEBUG + local legacy_args=m
274719 DEBUG + args_array=([m]=message=)
274719 DEBUG + local -A args_array
274719 DEBUG + local message
274720 DEBUG + ynh_handle_getopts_args 'Jul 14 17:20:47 systemd[1]: Starting Fail2Ban Service…
274720 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,670 fail2ban.server [1275]: INFO Starting Fail2ban v0.9.6
274720 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,678 fail2ban.server [1275]: INFO Starting in daemon mode
274721 DEBUG Jul 14 17:20:51 systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.
274721 DEBUG Jul 14 17:23:31 systemd[1]: Reloading Fail2Ban Service.
274721 DEBUG Jul 14 17:24:49 systemd[1]: Reloaded Fail2Ban Service.
274721 DEBUG Jul 14 17:28:56 systemd[1]: Reloading Fail2Ban Service.
274722 DEBUG Jul 14 17:30:26 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.
274722 DEBUG Jul 14 17:30:26 systemd[1]: Reload failed for Fail2Ban Service.’
274722 DEBUG + set +o xtrace
274723 DEBUG + echo ‘! Helper used in legacy mode !’
274723 DEBUG + set +x
274723 DEBUG + ynh_print_log '[Error] Jul 14 17:20:47 systemd[1]: Starting Fail2Ban Service…
274723 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,670 fail2ban.server [1275]: INFO Starting Fail2ban v0.9.6
274724 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,678 fail2ban.server [1275]: INFO Starting in daemon mode
274724 DEBUG Jul 14 17:20:51 systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.
274724 DEBUG Jul 14 17:23:31 systemd[1]: Reloading Fail2Ban Service.
274725 DEBUG Jul 14 17:24:49 systemd[1]: Reloaded Fail2Ban Service.
274725 DEBUG Jul 14 17:28:56 systemd[1]: Reloading Fail2Ban Service.
274725 DEBUG Jul 14 17:30:26 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.
274728 DEBUG Jul 14 17:30:26 systemd[1]: Reload failed for Fail2Ban Service.’
274728 DEBUG + echo -e '[Error] Jul 14 17:20:47 systemd[1]: Starting Fail2Ban Service…
274729 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,670 fail2ban.server [1275]: INFO Starting Fail2ban v0.9.6
274729 DEBUG Jul 14 17:20:50 fail2ban-client[1018]: 2020-07-14 17:20:50,678 fail2ban.server [1275]: INFO Starting in daemon mode
274729 DEBUG Jul 14 17:20:51 systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.
274729 DEBUG Jul 14 17:23:31 systemd[1]: Reloading Fail2Ban Service.
274730 DEBUG Jul 14 17:24:49 systemd[1]: Reloaded Fail2Ban Service.
274730 DEBUG Jul 14 17:28:56 systemd[1]: Reloading Fail2Ban Service.
274730 DEBUG Jul 14 17:30:26 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.
274734 DEBUG Jul 14 17:30:26 systemd[1]: Reload failed for Fail2Ban Service.’
274735 DEBUG + ‘[’ -e systemd ‘]’
274735 DEBUG + ynh_die
274735 DEBUG + local legacy_args=mc
274735 DEBUG + args_array=([m]=message= [c]=ret_code=)
274736 DEBUG + local -A args_array
274736 DEBUG + local message
274736 DEBUG + local ret_code
274736 DEBUG + ynh_handle_getopts_args
274736 DEBUG + set +o xtrace
274737 DEBUG + ret_code=1
274737 DEBUG ++ ynh_exit_properly
274737 DEBUG ++ local exit_code=1
274737 DEBUG ++ ‘[’ 1 -eq 0 ‘]’
274737 DEBUG ++ trap ‘’ EXIT
274738 DEBUG ++ set +o errexit
274738 DEBUG ++ set +o nounset
274738 DEBUG ++ sleep 0.5
275140 DEBUG ++ type -t ynh_clean_setup
275140 DEBUG ++ exit 1
Hello,
Sorry for answering very late. If you still have this issue, could you provide more detailed log for that fail2ban service ?
Thank you for the app!
User tried to move to Ynh-Wallabag from another instance. He have his 744 entries in All articles export file. But Ynh-Wallabag imports only top 400 (tried couple times). The export file does look complete (and takes 44 MB). The import process doesn’t really finish but more like ends with a blank screen. Then you reload the page and find partial import.
How it can be finished properly?
Sorry for answering so late… I hope you found a solution.
My guess would be that it takes too much time and the process is stopped, or maybe there is an issue with the import tool… are you using redis ?