… et on peut même copier ce fichier depuis un backup, et zou ça repart avec l'historique. Pareil pour les contacts/appels avec /data/data/com.android.providers.contacts/databases/contacts2.db

J'avais denyhosts depuis le début sur mon serveur @home mais ça a été supprimé de jessie. Je me suis dit que je m'en fichais pas mal au final, c'est pas de la sécurité ou quoi c'est surtout pour pas se faire pourrir les logs.
Là j'ai dû plonger dans /var/log/auth.log au boulot et… ouah du spam en continu, c'est bien casse-pieds pour suivre. Le moment de se plonger dans fail2ban donc !
Bah c'est tout bête comme dit dans l'article cité, et ça a l'air plus évolué.
Exemple, on peut afficher le statut actuel du ban sur SSH :
$ sudo fail2ban-client status ssh
Status for the jail: ssh
|- filter
| |- File list: /var/log/auth.log
| |- Currently failed: 1
| - Total failed: 219 - action
|- Currently banned: 1
| - IP list: 45.114.11.50 - Total banned: 1

Pour ajouter des plages IP à ne pas bannir, on peut copier le jail.conf dans jail.local comme suggéré et juste laisser "ignoreip", pour override. Ensuite :
fail2ban-client reload ssh
et vérif :
fail2ban-client get ssh ignoreip

Pas mal le reload sélectif et la verif en CLI ! :)

Pour set le MTU d'un bridge, il suffit que toutes les interfaces qu'il comprend le supporte. Il prend le plus haut.
De la page citée, Il faut utiliser la version post-up, car le man (bridge-utils-interfaces) dit : "These ports are the interfaces that are part of the bridge, and they shouldn't have any stanzas defining them on the interfaces file."
Donc en gros :
post-up ip link set mtu 9000 dev eth-10G-1