performance

Ma base Clickhouse étant chargée je ne résiste pas au plaisir d'explorer les données stockées par Ntopng depuis quelques années (# 768 millions de rangs)? Ici j'ai recherché les ports les plus scannés de 2019 à 2024, ces ports sont, pour la plupart, fermés par le parefeu et ne donnent lieu à aucune réponse (OUT_BYTES = 0 dans la table). J'ai limité aux 50 ports les plus actifs sur ces 5 années.
Pour des précisions sur Clickhouse voir ICI.

                       Nombre de hits externes par port de 2019 è 2024
┌──PORT─┬──TOTAL─┬─_2019─┬──_2020─┬─_2021─┬──_2022─┬──_2023─┬──_2024─┐
│    23 │ 672462 │ 47538 │  43369 │ 69247 │ 158195 │ 171361 │ 182752 │
│    22 │ 336644 │ 24613 │  24424 │ 42784 │  72004 │  91921 │  80898 │
│  6379 │ 260763 │  3375 │   6233 │ 55849 │  92393 │  56117 │  46796 │
│   445 │ 236658 │ 89599 │  56914 │ 29198 │  24291 │  17462 │  19194 │
│   465 │ 185839 │     0 │ 122256 │ 41240 │  15681 │   3296 │   3366 │
│  8080 │ 177555 │ 16881 │  66484 │ 24526 │  16628 │  24240 │  28796 │
│  3389 │ 115291 │  8802 │   8226 │ 14746 │  22552 │  27726 │  33239 │
│    81 │  90390 │ 15670 │  16857 │ 13336 │  17868 │  14698 │  11961 │
│  1433 │  84800 │  9393 │  15401 │ 18327 │  15102 │  11562 │  15015 │
│   993 │  77752 │  2078 │   3543 │ 21718 │  16301 │  10589 │  23523 │
│  5222 │  75155 │  3596 │  63430 │   960 │   1282 │   2750 │   3137 │
│    25 │  74353 │  7201 │  30668 │   456 │   6051 │     90 │  29887 │
│  5555 │  73875 │  9498 │  12880 │  9241 │  15565 │  13166 │  13525 │
│  8728 │  71342 │   534 │   1618 │  2565 │    167 │   4135 │  62323 │
│   995 │  66375 │   844 │  56869 │  1376 │   1859 │   2372 │   3055 │
│ 23462 │  53179 │    11 │     30 │    16 │      9 │     14 │  53099 │
│  2375 │  53017 │   896 │   2727 │ 12918 │  16207 │   9132 │  11137 │
│  8443 │  49855 │  2301 │   5584 │  5655 │   8872 │  15505 │  11938 │
│  8081 │  45657 │  2476 │   5238 │  5680 │   6272 │   8041 │  17950 │
│  2323 │  45567 │  8044 │   6430 │  4265 │   8727 │   5406 │  12695 │
│  3306 │  41819 │  5209 │   3537 │  3769 │   5634 │   7383 │  16287 │
│  8088 │  40936 │  3799 │   3998 │  3372 │   4289 │   6562 │  18916 │
│  3478 │  39355 │   218 │  26653 │ 11270 │    326 │    365 │    523 │
│  3074 │  37755 │   107 │  26227 │ 10945 │    132 │    156 │    188 │
│  2376 │  36376 │   509 │   1224 │ 10899 │  14420 │   5831 │   3493 │
│  8545 │  35368 │ 13986 │  12932 │  4509 │   2131 │    486 │   1324 │
│  8888 │  34998 │  2933 │   4265 │  4411 │   5131 │   6541 │  11717 │
│   587 │  32878 │  1004 │  14676 │  5647 │   3134 │   3145 │   5272 │
│  8000 │  32639 │  2844 │   5092 │  4337 │   5560 │   5450 │   9356 │
│  3128 │  30750 │  2374 │   3051 │  2917 │   3505 │   6965 │  11938 │
│  2222 │  30082 │  2471 │   2535 │  2829 │   3389 │   5781 │  13077 │
│  5038 │  28042 │  5372 │   9082 │  5929 │   5419 │   1796 │    444 │
│  9200 │  26705 │  1913 │   3874 │  4391 │   4484 │   4681 │   7362 │
│  9000 │  25346 │  3762 │   3452 │  3842 │   4058 │   4500 │   5732 │
│  5900 │  25169 │  3269 │   3763 │  4337 │   3967 │   3800 │   6033 │
│ 27017 │  24771 │  1945 │   2887 │  2819 │   3152 │   3912 │  10056 │
│   631 │  24602 │  4598 │   9952 │  3077 │   1842 │   2278 │   2855 │
│    21 │  24006 │  2518 │   3470 │  3500 │   4318 │   4577 │   5623 │
│ 34852 │  21665 │     8 │     31 │    14 │      6 │  21588 │     18 │
│  4719 │  20882 │    54 │     83 │    49 │     39 │   8038 │  12619 │
│  5060 │  20487 │  1032 │   1899 │  2893 │   4977 │   4913 │   4773 │
│  5432 │  20292 │   872 │   2514 │  3135 │   3498 │   4185 │   6088 │
│  1080 │  20017 │  1617 │   2124 │  1834 │   2713 │   4115 │   7614 │
│  3390 │  19949 │  3702 │   4455 │  3780 │   2562 │   2438 │   3012 │
│    88 │  19742 │  1898 │   4190 │  1651 │   4812 │   3157 │   4034 │
│  3000 │  19173 │  1044 │   5812 │  2403 │   2392 │   3554 │   3968 │
│   489 │  19011 │    45 │    145 │  1479 │   8637 │   8430 │    275 │
│  8090 │  18902 │  1034 │   1650 │  2406 │   3270 │   3819 │   6723 │
│ 32942 │  18449 │    15 │     24 │    15 │      3 │     17 │  18375 │
│  5500 │  17853 │  9560 │   3828 │  1533 │   1218 │    843 │    871 │
└──PORT─┴──TOTAL─┴─_2019─┴──_2020─┴─_2021─┴──_2022─┴──_2023─┴──_2024─┘

Ci-dessous le compte-rendu de Clickhouse pour cette belle requête.

50 rows in set. Elapsed: 5.500 sec. Processed 628.24 million rows, 18.05 GB (114.22 million rows/s., 3.28 GB/s.)
Peak memory usage: 193.52 MiB.

Et pour finir l'ordre SQL lui même :

use local_ntopng;
--
select PORT,sum(CTGEN) AS TOTAL,sum(CT1) as _2019,sum(CT2) as _2020,sum(CT3) as _2021,
		sum(CT4) as _2022,sum(CT5) as _2023,sum(CT6) as _2024
from
(
select YEAR(FIRST_SWITCHED) as ANNEE,L4_DST_PORT as PORT,
	toInt32(count(*)) as CTGEN,toInt32(count(*)) as CT1,toInt32(0) as CT2,toInt32(0) as CT3,
	toInt32(0) as CT4,toInt32(0) as CT5,toInt32(0) as CT6
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2019
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443,465)
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(count(*)),
		toInt32(0),toInt32(0),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2020
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(count(*)),toInt32(0),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2021
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(count(*)),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2022
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(0),toInt32(count(*)),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2023
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(0),toInt32(0),toInt32(count(*))
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2024
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
)
where PORT < 35000
group by 1
order by 2 desc
limit 50 ;

J'ai installé une base Clickhouse sur ma machine principale et j'ai positionné l'espace disque sur la nouvelle carte et ses "disques" NVME en RAID 1.

J'ai chargé la table principale de NTOPNG (plus de 766 millions de rangs) et comme premier test j'ai effectué cette statistique sur le port 23, il y en a encore qui tentent ce port ... Comme d'habitude avec Clickhouse le résultat est presque instantané :

60 rows in set. Elapsed: 1.295 sec. Processed 545.39 million rows, 4.86 GB (421.31 million rows/s., 3.76 GB/s.)
Peak memory usage: 8.07 MiB.

Qui a dit que traiter de gros volumes de données "tait long, ici environ 540 millions de rangs sur un total de 768 millions.

J'ai généré avec Openoffice le graphe qui suit :

A titre indicatif la description de la carte utilisée est accessible ICI.

Aujourd'hui en lançant une machine virtuelle KVM qui me sert à tester différentes applications, entre autres graphiques, j'ai été surpris de l'absence d'ouverture de la fenêtre graphique ... rien n'était visible ... 
j'ai vérifié la présence de la MV, elle était bien là, l'accès SSH à la machine, c'était OK. 
J'ai donc continué à chercher et j'ai remarqué sur le serveur de MV que :
qemu-system-x86_64 --version 
retournait :
 QEMU emulator version 10.0.0 (Debian 1:10.0.0+ds-2) Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers 
Ah, une version majeure! Qu'est-ce qui a changé ? 
En farfouillant sur internet j'ai trouvé un nouveau paramètre "-display " qui a l'air de correspondre à ce que je cherche. 
Cette version 10 de QEMU apporte des nouveautés mais aussi une suprise : 
La machine se détache complètement et n'ouvre aucun écran graphique alors qu'avant il fallait utiliser l'option "-nographic" pour obtenir ce résultat, tant pis pour ceux qui voulaient utiliser des applications X.
En fait il suffit d'ajouter un paramètre "-display TYPE" au lancement de QEMU. Pour ne pas trop changer les habitudes de chacun les types "sdl" ou "gtk" sont utilisables. il est aussi possible d'utiliser "vnc=nom_display" (non testé). 
Un premier lancement avec "-display gtk" donne un message d'erreur : ... 
Display 'gtk' is not available. Perhaps you want to install qemu-system-gui package? 
Pour pouvoir utiliser les types "sdl" ou "gtk" il faut installer le paquet "qemu-system-gui", un petit coup de :
apt install qemu-system-gui
Règle le problème; ensuite l'option "gtk" marche et la fenêtre de boot apparait, puis l'écran de connextion X fonctionne. 
J'ai ensuite testé l'option "sdl" qui, elle aussi, semble fonctionner comme prévu.
Ces deux options permettent d'utiliser des applications X sans aucun problème.

Le passage du navigateur Opera sous pavillon chinois m’a interpellé, Opera est largement soutenu par les entreprises chinoises et l’on peut se poser des questions sur la pertinence de « quitter » ce navigateur. L'ancien développeur d’Opera développe actuellement un nouveau browser nommé Vivaldi ...

1. Le contexte de l'acquisition par une entreprise chinoise (Alibaba):

• L'acquisition par Alibaba a été le facteur clé. Cette acquisition a permis à Opera d'être intégré au vaste écosystème Alibaba, ce qui a entraîné plusieurs changements significatifs, et pas toujours dans le bon sens;

2. Pourquoi Vivaldi peut être perçu comme un choix plus intéressant :

Bien que Opera soit toujours utilisé par beaucoup, je l’ai remplacé par Vivaldi, voici quelques raisons qui ont amené ce choix :

• Vivaldi est souvent considéré comme étant plus axé sur le confort de l'utilisateur et l'accessibilité. Il propose des options de personnalisation plus poussées, notamment:

  • Amélioration de la lisibilité : Le design est conçu pour être plus lisible sur différents écrans et avec différentes tailles de police.

  • Options d'affichage avancées : Vivaldi offre des options pour afficher les éléments importants (comme les liens et les informations) en évidence, ce qui peut améliorer l'expérience utilisateur pour certains utilisateurs.

  • Compatibilité plus large : Vivaldi a été conçu pour fonctionner de manière optimale sur une gamme plus large d’appareils, y compris les ordinateurs portables et les appareils mobiles, que certains utilisateurs de Opera trouvent « pénibles ».

• Interface utilisateur plus intuitive : il semble que certains utilisateurs trouvent que l'interface de Vivaldi est plus intuitive, avec un système de navigation plus "direct" et facile à comprendre. Cela peut être lié à la façon dont il a été conçu pour des utilisateurs plus expérimentés avec les navigateurs web.
• Moins d’encombrement: Il semble que Vivaldi a moins de publicités intégrées par défaut, ce qui peut améliorer l'expérience utilisateur.
• Indépendance : la présence d'Alibaba n'est probablement pas neutre.

3. La perception et la popularité :

• Popularité relative : Bien que Opera ait une base d'utilisateurs plus importante, Vivaldi semble plus populaire auprès des développeurs de logiciels et des utilisateurs qui apprécient sa personnalisation et son focus sur l’accessibilité.

• Communauté : La communauté Vivaldi est plus active et a un sentiment de communauté plus fort que celui de Opera.

Conclusion provisoire, (ou définitive ?) :

Il n'y a pas une "préférence" unique, mais plutôt un ensemble de facteurs qui devraient conduire la plupart des utilisateurs à préférer Vivaldi. L'acquisition par Alibaba a été le facteur principal, mais la conception et l'approche de Vivaldi devraient attirer les utilisateurs qui recherchent un navigateur plus flexible et personnalisable, en particulier pour les utilisateurs sensibles aux aspects de lisibilité et d’accessibilité.

J'ai "repéré" cette carte avec un libellé accrocheur :
Carte contrôleur PCIe 3.0 x4 pour 4 SSD M.2 NVMe M Key SANS MODE BIFURCATION
Pour un prix "correct" (moins de 60 Euros).
Dès la livraison je me précipite et après quelques difficultés pour monter deux barettes NVME de 1To, car les vis fournies étaient "un peu" courtes, avec d'autres vis tout est rentré dans l'ordre et le montage dans la machine se fait ensuite sans problèmes.
Après un reboot la carte est repérée de suite et "lspci" donne :
05:00.0 Non-Volatile memory controller: Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03)
06:00.0 Non-Volatile memory controller: Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03)
Les "disques" sont parfaitement visibles avec "fdisk -l | grep /dev/nvme" :
Disk /dev/nvme0n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk /dev/nvme1n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors

Et après création d'une partition "raid" sur chacun de mes nouveaux disques la même commande donne :
Disk /dev/nvme0n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
/dev/nvme0n1p1  2048 1953523711 1953521664 931,5G Linux RAID
Disk /dev/nvme1n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
/dev/nvme1n1p1  2048 1953523711 1953521664 931,5G Linux RAID
Ensuite création du raid logiciel (miroir : raid 1) avec les commandes suivantes :
#!/bin/bash
P1=/dev/nvme0n1p1
P2=/dev/nvme1n1p1
MD=/dev/md200
# Only if md exists
### mdadm --zero-superbloc ${P1}
### mdadm --zero-superbloc ${P2}
mdadm --create ${MD} --level=1 --raid-disks=2 ${P1} ${P2}

mdadm --examine --scan ${MD}

Remarque : au cours de la création de mon RAID 1 (miroir) j'ai constaté de très grosses variations dans la vitesse de synchronisation des disques, au plus bas   un peu moins de 40Mo/seconde, au plus haut plus de 400Mo/sec ... mais cela dure "un bon moment", plus d'une heure ...
J'aime bien LVM et je transforme mon Raid en PV, puis j'y crée UN VG (ici VG_200) et un volume logique de 32Go pour effectuer quelques tests de vitesse.

Le tout se retrouve enfin accessible dans /dev/mapper/VG_200-TEST_200.
TEST A : un bon vieux DD depuis /dev/zero
dd if=/dev/zero of=/dev/mapper/VG_200-TEST_200 bs=65536 count=10240
10240+0 records in
10240+0 records out
671088640 bytes (671 MB, 640 MiB) copied, 1,23197 s, 545 MB/s

Tests avec  un "vrai" filesystem, ici en ext4 :
mkfs -t ext4 /dev/VG_200/TEST_200
mount /dev/VG_200/TEST_200 /mnt

dd if=/dev/urandom of=/mnt/toto bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 19,1875 s, 350 MB/s

Le même test avec /dev/zero :
dd if=/dev/zero of=/mnt/toto bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 9,72867 s, 690 MB/s

Il semble que mon "/dev/urandom" soit nettement moins rapide que "/dev/zero".

En lecture maintenant en se servant du fichier généré avec "rarndom" et après avoir droppé les caches, sans ça c'est pas correct ! ...

dd if=/mnt/toto of=/dev/null bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 8,33121 s, 806 MB/s

Un autre petit test avec "hdparm" :
hdparm -Tt /dev/mapper/VG_200-TEST_200

/dev/mapper/VG_200-TEST_200:
Timing cached reads:   36548 MB in  1.97 seconds = 18525.92 MB/sec
Timing buffered disk reads: 2194 MB in  3.00 seconds = 730.92 MB/sec

Un petit test avec "ioping" :
ioping -c 10 /mnt
--- /mnt (ext4 /dev/dm-0 31.2 GiB) ioping statistics ---
9 requests completed in 1.47 ms, 36 KiB read, 6.12 k iops, 23.9 MiB/s
generated 10 requests in 9.00 s, 40 KiB, 1 iops, 4.44 KiB/s
min/avg/max/mdev = 107.7 us / 163.5 us / 209.1 us / 36.7 us
Et sur un HDD "classique" (WDC WD20EARX-00P), lui aussi monté en RAID 1 :
--- /RAIDHOME (ext4 /dev/md0 393.4 GiB) ioping statistics ---
9 requests completed in 62.1 ms, 36 KiB read, 144 iops, 579.4 KiB/s
generated 10 requests in 9.02 s, 40 KiB, 1 iops, 4.43 KiB/s
min/avg/max/mdev = 131.4 us / 6.90 ms / 18.6 ms / 7.71 ms

Les résultats sont plutôt encourageants ...

Je vais installer une base "ClickHouse" dans ce truc rapide.
 

Plus de Xwindow avec le kernel 6.12.9, le driver "nouveau" refuse de se lancer avec des messages d'insultes sur du firmware non trouvé :

kernel: nouveau 0000:01:00.0: firmware: failed to load nouveau/nv106_fuc084 (-2)
kernel: nouveau 0000:01:00.0: firmware: failed to load nouveau/nv106_fuc084 (-2)
kernel: nouveau 0000:01:00.0: Direct firmware load for nouveau/nv106_fuc084 failed with error -2

Après recherche ce cas s'est déjà produit il y a longtemps et ma carte video est très ancienne (Nvidia GT710). La question est de trouver ce foutu firmware. Evidemment il n'est pas dans les repositories Debian ...
Heureusement une recherche me pointe vers un article sur "google groups" qui date de 2021 ! Et qui me semble prometteur :

https://groups.google.com/g/linux.debian.kernel/c/J0fFV1akNRU

On y trouve une procédure qui permet de récupérer ce fichu firmware (à effectuer en "root") à condition de posséder une version de Python2, ça tombe bien j'ai un vieux Python2.7 qui ne demande qu'à servir !
Voici la procédure à suivre :

mkdir /tmp/nouveau
cd /tmp/nouveau
wget https://raw.github.com/envytools/firmware/master/extract_firmware.py
wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86…
sh NVIDIA-Linux-x86-325.15.run --extract-only
python2 extract_firmware.py # this script is for python 2 only
mkdir /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/

On récupère ainsi plus de 170 "firmwares" dont le fameus "nouveau/nv106_fuc084" sous forme d'un lien vers "nve0_bsp".

Et, en plus, lors du reboot suivant tout s'est bien passé et le driver "nouveau" s'est bien calmé et Xwindow fonctionne normalement.
Et le 30 juin 2025 cela fonctinne toujours sans ennui avec un kernel 6.12.32 (Trixie).
 

Il s'avère que CUPS souffre de quelques vulnérabilités et qu'il n'est pas indiqué de la laisser accéder depuis Internet ...
Mais le paramétrage n'est pas évident !
Dans mon cas la machine qui supporte l'imprimante est celle qui sert de "pont" internet et est accessible de tout le réseau interne.
Les deux cartes sont "bridgées" et nommées "br0" (vers internet) et "br1" (vers réseau interne).
Il faut limiter les adresses possibles dans /etc/cups/cupsd.conf  et par défaut toutes les adresses sont permises ...

AVANT
# Allow remote access
Port 631 # Listen to all
Listen /var/run/cups/cups.sock # existing socket Listen

Il faut remplacer cette partie par :

APRES
# Allow remote access
# Port 631 # Listen to all --> NO
Listen A.B.C.D:631             # new limit 
Listen 127.0.0.1:631           # existing loopback Listen
Listen /var/run/cups/cups.sock # existing socket Listen

On peut aussi sécuriser d'autres parties (location) en limitant l'interface utilisable, ici pour moi limiter l'interface à "br1" qui est l'interface vers le réseau interne  :

AVANT
<Location />
  # Allow remote administration...
  Order allow,deny
</Location>

APRES
<Location />
  # Allow remote administration...
  Order allow,deny
  Allow @IF(br1)
</Location>

On peut aussi utiliser des ordres "Allow" avec des adresses IP, même avec jokers  telles "192.168.10.*" ou au format CIDR tellesque "192.168.10.0/24".

Normalement votre CUPS devrait être un peu plus à l'abri des vilains méchants ...

Aujourd'hui, sur une machine "cliente", cups refuse d'imprimer avec un message sibyllin : "cups pki invalid".

Après moult recherches sur Internet je ne trouve que de "vieux" trucs qui, en plus, ne résolvent pas mon problème ... et après y avoir passé quelques dizaines de minutes, sans résultat, j'ai utilisé la dernière arme.

Suppression complète de "cups" et de tous ses annexes :

• cups
• cups-browsed
• cups-client
• cups-common
• cups-daemon
• cups-filters
• cups-ipp-utils
• cups-ppdc
• cups-server-common

J'ai ensuite renommé /etc/cups en /etc/sv_cups et recréé un répertoire /etc/cups sans oublier "chgrp lp /etc/cups".
Ensuite, réinstallation du machin :

apt install cups-client cups cups-common

Et ... ça marche, l'installation a même trouvé l'imprimante disponible sur le réseau et l'a installée correctement.
Depuis on peut imprimer.

Note ; toutes ces machines sont sous Debian/trixie.

Et ça a recommencé j'ai de nouveau le message "cups pki invalid" ...
J'ai donc créé un script pour désinstaller et réinstaller CUPS :

#!/bin/bash
LISTE='    cups cups-browsed cups-client cups-common cups-daemon cups-filters  cups-ipp-utils cups-ppdc cups-server-common' 
#
apt remove --purge $LISTE

apt install $LISTE 

Cela commence à être énervant !

NtopNG conserve la trace de toutes les connexions et je dispose de l'historique depuis aout 2016 ce qui représente actuellement plus de 8 ans de connées et 750 millions de rangs dans la base de données.
J'ai voulu voir sur deux ports "typiques", 22 et 23, le nombre d'adresses IP et le nombre de hits par mois, un "petit" ordre SQL, une bonne dizaine de minutes d'attente ( la machine "Clickhouse" est HS !) et le résultat est là.

Quelques remarques :
Mise en place, en juin 2019, d'un firewall plus restrictif et d'une "mémoire" des "affreux" qui restent donc bloqués "un certain temps" et utilisation de différents sites fournissant des listes d'adresses "peu fiables" ou carrément à éviter ...

Port 23.

On remarque bien l'inflexion des courbes milieu 2019, comme quoi mémoriser les IP des "vilains" sert à quelque_chose ...
Après 2019 on ne "voit plus rien", voici le détail en changeant d'échelle.
 

Même chose pour le PORT 22.

On remarque bien l'inflexion des courbes milieu 2019, comme quoi mémoriser les IP des "vilains" sert à quelque_chose ...
Après 2019 on ne "voit plus rien", voici le détail en changeant d'échelle.
 

On remarque l'affaiblissement progressif des courbes au fur et à mesure de l'amélioration de le base de données des IP "méchantes".

Version 11.4 et +.

Attention, à partir de cette version il faut impérativement ajouter un paramètre dans votre configuration.
Ce paramètre est destiné à conserver les logs binaires (binary logs) tant que tous les "esclaves" ne les ont pas reçu, ce qui permet d'effectuer sans problèmes des mises à niveau sur les "esclaves". 

Malheureusement pour ceux qui n'ont pas cette sécurité la valeur par défaut de ce paramètre n'est pas zéro et cela empêche MariaDB
de supprimer les logs. Si vous n'avez pas de machine "esclave" il faut donc ajouter la ligne suivants dans vos fichiers de configuration :

slave_connections_needed_for_purge = 0

Et si vous avez des machines "esclaves" mettez le nombre de machines "filles" à la place du zéro ainsi Mariadb gardera les logs binaires jusqu'à ce que toutes les machines filles aient reçu les logs.