En cherchant "relay" dans la conf de postfix pour trouver comment faire un smarthost (obligé car port 25 bloqué), je suis tombé sur "smtp_fallback_relay". En gros, comme un smarthost, mais en cas d'erreur auparavant.
Du coup, en v6 (pas bloqué) je parle directement aux serveurs mails, en v4 je passe par un relais.
Un petit coup d'iptables en passant pour REJECT le port 25 au lieu de DROP par le FAI pour éviter les timeout, c'est tout bon (enfin autant que cela puisse être avec un port 25 bloqué…).

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

Alternative potentiellement intéressante aux drivers de bonding d'interface réseau de Linux. À suivre, apparemment il y a des tentatives de support dans systemd-networkd donc c'est plus ou moins en train de prendre de l'essort.

Pas super intuitif d'aller sur un host pour faire un graph qui regroupe des métriques de plusieurs machines mais y'a de la bonne doc donc on va pas se plaindre :)

Les fameux tunnels HE pour se connecter au monde IPv6 quand on est chez un FAI qui n'en fournit pas.
Sauf que là on vient de tester en mode BGP, bah ça juste marche direct du premier coup avec bird et leur conf d'exemple. Même pas drôle.
La seule "contraite" c'est d'écrire un mail pour prouver que c'est une demande legit et que t'opères bien les AS/préfixes pour lesquels la demande a été faite.

Quand on crée une dummy (ip link add type dummy), il charge automatiquement le module qui va bien. Sauf que le module créée de base dummy0. Et si la commande doit créer dummy0 elle aussi ? Eh bien, elle passe pas. Parce que dummy0 existe déjà ! Donc avant la commande, dummy0 existe pas et… la commande se plaint que dummy0 existe déjà :)

Bon alors moi naïvement je croyais que hosts.{deny, allow} c'était un truc global au système, utilisé par la libc par exemple (comme resolv.conf quoi). Hé bin non. Uniquement par la libwrap des TCP wrappers.
Au moins apparemment sur RH-like, on a droit à un commentaire bien explicite au début de ces fichiers, sur du Debian j'ai rien vu d'évident, y compris dans le man hosts_access.
un mythe s'effondre