Il n'y a aucune insulte dans le propos. Juste un avis. Mais peut-être que le terme “cancre” dans le titre était inadapté, vous avez raison. J'ai modifié le titre. ;-)

Si d'autres se posaient la même question, la réponse se trouve dans la “man iptables-extensions” :

LOG

Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP/IPv6 header fields) via the kernel log (where it can be read with dmesg(1) or read in the syslog).

This is a “non-terminating target”, i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).

Merci pour les fleurs. Et concernant les logs, le principe ici c'est que tout ce qui n'est pas accepté est journalisé. Après, ne pas oublier qu'il s'agit d'une introduction de prise en main qui se veut générale. Pour les détails, il vaut mieux voir la doc écrite par Oskar Andreasson, beaucoup plus assomman^^^^^complète. :o)

Le principe est très simple :

• “tu” (la machine) analyses ce qui se passe, en premier… LOG
• et, ensuite “tu” décides de l'action à émettre, souvent du DROP ou du REJECT, et parfois tu peux, en tant qu'administrateur décider de laisser passer les paquets (règles ACCEPT). Cette action très ciblée dépend du besoin…

Car non, les LOG ne servent pas qu'à journaliser ce qui doit être rejeté ou supprimé sans avis. Ils servent à analyser la situation, correspondant à un critère. Ensuite, vient l'action.

Je ne pense pas que git soit le meilleur outil pour backupper ce genre de choses par contre

C'est plus dans une otique de distribution que de backup que git est intégré : même base de mots de passe sur son ordi, tel, tablette, etc. en lecture et écriture (Password Store est, au passage, un super client android).

le versioning par défault impose de changer tous les mots de passe si on veut changer le mot de passe “master”.

Pas sûr de voir ce que tu entends par là ? Les fichiers sont chiffrés avec une (ou des) clé GPG. Dans le cas d'un changement de clé, oui, après le pass init new-gpg-id l'intégralité des fichiers sera modifié car re-chiffré, mais les mots de passe ne changent pas pour autant.

Donc pas de notion de “mot de passe master” c'est juste des fichiers textes tout bêtes, chiffrés, stockés dans un dépôt git si besoin, et un super moteur de fuzzy search pour taper dedans.

En tant qu'ancien IBMer parti il y a peu… Ca me fait assez peur pour RedHat. IBM à l'habitude d'appliquer un rouleau compresseur après un rachat pour “intégrer” le rachat, sauf que bien souvent ça à plus tendance à détruire le rachat qu'autre chose, cf le rachat de Softlayer. En plus IBM c'est un gros mastodonte avec des couches et des couches de bureaucratie et de management inutile voir pénalisante, un peu à l'opposé de ce que j'avais entendu sur redhat.

Après, si on veut être optimiste, il y a pas mal d'effort de la part d'IBM pour essayer de se renouveler, si ça pouvait être RedHat qui infusait à IBM, on est pas à l'abri de bonnes choses.

Étant donné le passé de ces deux compagnies, elles ont l'air de bien se compléter sans que l'une ne cannibalise l'autre. Pour IBM, ça va lui permettre de proposer des solutions RedHat en complément (ou remplacement ?) de son vieux Unix AIX. Étant utilisateur convaincu de Fedora, je me fais pas de souci et j'ai même espoir que ça remette un coup de fouet sur certains projets tenus par RedHat.

Je me suis dit exactement la même chose, vu que j'ai tout qui tourne sous CentOS. Dans un coin de ma tête, ça chuchote quelque chose comme “Bah, au pire y'aura toujours Debian et Slackware”.