Nvidia : plus de support Linux

J'utilise des cartes vidéo Nvidia depuis très longtemps mais les dernières versions des drivers ne compilent plus pour des Kernels > 6.12.48 sur mes machines Debian. J'ai donc envoyé un message au support technique. Ils m'ont répondu très gentiment qu'ils n'assuraient pas de suppport technique pour Linux ... ci dessous copie de leur courrier.

Bonjour Jean-Paul, 
  
Merci d'avoir contacté le service clientèle NVIDIA. Mon nom est Raluca et je suis ici 
pour vous porter assistance. 

Merci d'avoir porté à notre attention les difficultés que vous rencontrez, 
mais rassurez-vous, on est là pour vous aider.

Nous vous informons que nous n’assurons pas de support technique pour
 les environnements Linux. De ce fait, nous ne sommes malheureusement 
 pas en mesure de vous accompagner sur cette problématique.

Nous vous invitons à consulter le forum suivant, où vous pourrez trouver 
des informations complémentaires ainsi que des échanges avec la communauté 
susceptible de vous aider:

https://forums.developer.nvidia.com/c/gpu-graphics/linux/148

Merci pour votre compréhension et patience.  
  
Je vous souhaite une bonne journée! 

Cordialement, 
Raluca
Service Clientèle NVIDIA

Je vais, bien sûr, essayer le forum et surtout me tourner vers AMD bien qu'il ne fournissent pas de drivers pour Debain mais seulement pour RHEL et Ubuntu.

Gros scanneur

Aujourd'hui l'analyse des scans de ports m'a donné un nouveau record sur une journée :

23339 ports scannés entre 10:30 et 12:47 soit environ 170 ports par minute et plus de 1/3 des ports existants, par l'IP 45.142.193.185 basée en Hollande.

Le précédent record était d'environ 16000 seulement !

 

 

 

Redis-server blocage programme utilisateur

Janvier 2026.
J'ai rencontré un petit problème lors de l'éxécution d'un couple de programmes en Python dont l'un "passe" des données à l'autre par l'intermédiaire de "redis". Le problème était un arrêt intempestif du programme recevant les données ce qui entrainait le blocage du programme émetteur.
Après analyse des logs j'ai trouvé des messages d'erreur dans redis.log conseillant d'ajouter :

"vm.overcommit_memory = 1"

dans /etc/sysctl.d en donnant en référence : https://github.com/jemalloc/jemalloc/issues/1328 mais cette page est devenue inaccessible ...

J'ai donc ajouté "vm.overcommit_memory = 1" dans un fichier /etc/sysctl.d/redis.conf et après un petit coup de :
 "sysctl --load=redis.conf

et redémarré redis ... depuis mes deux programmes fonctionnent normalement.

Et ... cela n'a pas duré et j'ai toujours des plantages "aléatoires" lors de l'exécution, sans solution pour l'instant alors que sur une autre machine tout fonctionne normalement ... et je ne vois aucune différence entre les versions des programmes, aussi bien Python que Redis.

Mars 2026.
Après quelques temps il n'y a plus de blocage "aléatoire" et tout semble tourner rond ...

Sécurité disques RAID 1 (miroir)

Après avoir fait un petit voyage à Taïwan et en Corée pour les fêtes de fin d'année je suis quand même revenu …

Et j’ai redémarré mes machines qui ont bénéficié de plus de 3 semaines de repos, mais sur trois machines à la maison une seule a redémarré correctement, celle de madame, mais le pont vers Internet étant HS elle ne permettait pas grand-chose d’utile.
La machine qui sert de pont vers Internet, et qui héberge ce site, a refusé obstinément de démarrer.
En démarrant sur une clef USB j’ai pu constater des dégâts importants : sur 4 disques 2 étaient HS, en principe ces disques sont montés deux par deux en miroir ce qui jusqu’ici m’avait toujours permis de récupérer les données sur le disque « survivant ». Le système, lui aussi sur des disques en miroir (2 x NVME de 1To), n’avait absolument pas souffert et les volumes LVM contenant des machines virtuelles étaient accessibles.
Mais là, les disques « survivants » s’il étaient lisibles ne disposaient pas de la totalité des données, sur une base de données suivie depuis presque 10 ans je n’ai récupéré que les années de 2016 à 2018 ! Le disque qui contenait les sauvegardes était carrément illisible !
J’ai donc du monter de nouveaux disques, recréer les bases de données et les fichiers annexes mais certaines sauvegardes ne se sont pas restaurées complètement et quelques databases MariaDB étaient très incomplètes … et j’ai du les reconstituer en partie à partir de copies faites sur une autre machine pour tester Clickhouse. Cela prend beaucoup de temps mais j’ai fini par remettre le tout en état mais avec une perte d’une partie de l’historique des archives issues de Apache/modsec ou des archives de Suricata.

Au niveau de la base de données elle-même un certain nombre d’utilisateurs étaient absents ou incomplets … je n’arrive pas à comprendre ce phénomène.

J’ai tout de suite commencé la mise en place de sauvegardes des bases de données avec recopie immédiate sur un autre système afin de prendre moins de risques sur les historiques.

Une autre machine avait perdu sa configuration, suspectant un problème avec la pile de maintien j’ai laissé la machine branchée et elle a démarré gentiment le lendemain et fonctionne fort bien, c’est elle qui conservait la copie de certaines données dans une base Clickhouse.

En ce qui concerne les disques « en miroir » j’avais toujours pu récupérer les données sur le disque survivant, même en milieu professionnel. La seule différence ici que j’ai utilisé LVM, le Physical Volume est déclaré sur le miroir et les partitions ne sont pas physiques comme « autrefois » mais juste des Logical Volumes … il va falloir que je réalise quelques tests de reprise en l’absence d’un disque.

openai robot curieux

Aujourd'hui en analysant les logs de Apache j'ai trouvé un robot OpenAI marquant comme "Referer" https://community.letsencrypt.org et tentant d'accéder à l'Url "/.well-known/acme-challenge/6iKOg35diTyM8rvagvtu3dzO_i1gu75DvMF75dMoC50".

Ce robot chercherait-il à récupérer des informations sur le certificat correspondant ?

Par défaut j'ai bloqué ce type de comportement.

Subnets de bots OpenAI, mis à jour lorsque c'est nécessaire

# Microsoft/openAI subnets repérés
4.151.241.0/24
4.196.118.0/24
4.196.198.0/24
13.65.138.0/24
20.27.94.0/24
20.77.178.0/24
20.90.7.0/24
20.97.189.0/24
20.168.78.0/24
20.169.73.0/24
20.169.78.0/24
20.169.87.0/24
20.194.1.0/24
20.194.157.0/24
20.117.22.0/24
20.204.24.0/24
20.215.214.0/24
20.215.220.0/24
20.235.75.0/24
23.98.186.0/24
40.84.221.0/24
51.107.70.0/24
52.154.22.0/24
52.173.235.0/24
52.187.246.0/24
52.230.164.0/24
68.218.30.0/24
68.221.67.0/24
68.221.75.0/24
74.7.36.0/24
74.7.35.0/24
74.7.227.0/24
74.7.175.0/24
74.7.227.0/24
74.7.228.0/24
74.7.230.0/24
74.7.241.0/24
74.7.242.0/24
74.7.244.0/24
104.210.140.0/24
137.135.190.0/24
138.91.30.0/24
137.135.191.0/24
172.182.202.0/24
172.182.214.0/24
172.182.215.0/24
172.183.222.0/24
172.203.190.0/24
172.204.16.0/24
172.213.21.0/24

Cette page sera mise à jour assez souvent lors du repérage de nouvelles adresses ...

 

Subnets pirates brésiliens

A l'occasion d'un petit test sur la base de données (Clickhouse) qui contient la trace des échanges internet j'ai utilisé le script suivant :

select IPv4NumToString(toUInt32(IP_SRC_ADDR)),
       L4_DST_PORT, count(*)
from flowsv4 
where  FIRST_SWITCHED > toDateTime('2025/11/09')
  and IP_SRC_ADDR not between toString(INET_ATON('192.168.1.0')) and toString(INET_ATON('192.168.3.255'))
  and OUT_BYTES = 0
GROUP BY IP_SRC_ADDR,L4_DST_PORT
HAVING count(*) > 2
order by IP_SRC_ADDR,L4_DST_PORT;

Le résultat m'a surpris : 2599 rows in set (0,017 sec), et entre 12:13 et 12:27 les sous-résaux 45.229.52.0/24 à 45.229.55.0/24 ont totalisé 8983 hits sur le port 443. L'intégralité des adresses (de 0 à 255) de chaque sous-reseau a été utilisée soit 512 adresses, sans jamais recevoir aucune réponse car j'ai bloqué carrément ce pays au niveau du parefeu car ce site n'est pas en portugais et qu'un grand nombre d'ennuyeux personnages semblent encombrer les IP de ce pays.

 

Purge inefficace ?

Il faut purger les journaux de systemd, mais les résultats peuvent surprendre, en effet, une purge est censée supprimer des données mais, parfois, le volume augmente comme dans l'exemple suivant :

Archived and active journals take up 16M in the file system.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/62d79583138541dbb9fc328e75176ded.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Archived and active journals take up 26.4M in the file system.

Passer de 16Mo à 26,4Mo, j'hésite à appeler cela une "purge".

Le script utilisé est le suivant :

journalctl --disk-usage
journalctl --rotate
journalctl --vacuum-time=2d
journalctl --disk-usage

Qui est lancé tous les jours.

Ports scannés 2019/2024

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, je n'ai pas pris en compte l'année 2025 par encore terminéé.
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 ;

C'est toujours le port 23 qui tient la tête suivi du port 22 !
Certains ports sont visiblement des "anomalies" avec une grosse fréquentation sur une courte période puis pas grand chose le reste du temps, par exemple le port 23462 ...

Statistique Port 23 : 2020/07 à 2025/05

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 c'était long, ici environ 420 millions de rangs sur un total de 768 millions.

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

Graphe des hits sur le port 23

Note : le "Peak memory usage" est ici assez faible et "passe" très bien sur les 32Gb de la machine, mais j'ai eu quelques ordres SQL incluant de très gros count(distinct(xxx))  sur cette même base tombent car pas assez de mémoire ...

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