performance

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 mé 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, pui 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 bon ! ...

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

Les résultats sont plutôt encourageants ...
Bientôt la suite des tests ...

Plus de Xwindow avec 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 firmaware. 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.
 

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-core_drivers
• cups-daemon
• cups-filters
• cups-filter-core-drivers
• 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.

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, malheureusement pour ceux qui n'ont pas cette sécurité la baleur 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.

L'installation est des plus simples puisqu'il existe un paquet Debian, au moins dans "Trixie" qui est la version installée ici.
apt-get install fgallery
Qui installe les quelques dépendances nécessaires au traitement des images ...

Petite préparation pour faciliter la suite ...
Dans le répertoire /usr/share/fgallery/view il existe deux liens :
- mootools-core-1.4.js
- mootools-more-1.4.js
Qu'il vaut mieux remplacer par les originaux afin de faciliter le déplacement des répertoires par la suite.

cd /usr/share/fgallery/view
rm mootools-core-1.4.js
cp ../../javascript/mootools/mootools-core.min.js mootools-core-1.4.js
rm mootools-more-1.4.js
cp ../../javascript/mootools/mootools-more.min.js mootools-more-1.4.js

J'ai du aussi effectuer une petite modif dans le fichier index.js, sans cela rien ne s'affichait :

Aux environs de la ligne 876 :
Avant :
onSuccess: initGallery,
onFailure: initFailure
}).get();

Après :
    onSuccess: initGallery,
   onFailure: initGallery
 }).get();

Je vais signaler ce bug aux auteurs.

L'installation de Carbonio s'est bien terminée, l'interface Web fonctionne et l'accès depuis Evolution ou Thunderbird fonctionne parfaitement, la première chose qui nous manque est le paramétrage des sites "antispam", oui cela sert ! 
Or l'interface Web d'administration ne donne pas accès, au moins pas encore, à ce type de données, il faut passer par le CLI et des commandes de paramétrages "un peu" ésotériques.
Le mini-script suivant permet d'installer 4 sites antispam d'un coup :

1.  Abuseat.org (division de Spamhaus)
2. Spamcop.net
3. Spamhaus.org
4. barracudecentral.org

Cet ensemble doit permettre de "purifier" un peu les mails reçus, voici le petit script qui réalise ce miracle.

carbonio prov mcf \ 
zimbraMtaRestriction reject_invalid_helo_hostname \ 
zimbraMtaRestriction reject_unknown_helo_hostname \ 
zimbraMtaRestriction reject_unknown_client_hostname \ 
zimbraMtaRestriction reject_unknown_reverse_client_hostname \ 
zimbraMtaRestriction reject_non_fqdn_sender \ 
zimbraMtaRestriction reject_unknown_sender_domain \ 
zimbraMtaRestriction reject_invalid_hostname  \ 
zimbraMtaRestriction "reject_rbl_client cbl.abuseat.org" \ 
zimbraMtaRestriction "reject_rbl_client bl.spamcop.net" \ 
zimbraMtaRestriction "reject_rbl_client sbl.spamhaus.org" \ 
zimbraMtaRestriction "reject_rbl_client b.barracudacentral.org"

Et on vérifie avec la commande :

carbonio prov gcf zimbraMtaRestriction 
qui retourne : 

zimbraMtaRestriction: reject_invalid_helo_hostname zimbraMtaRestriction: reject_unknown_helo_hostname zimbraMtaRestriction: reject_unknown_client_hostname zimbraMtaRestriction: reject_unknown_reverse_client_hostname zimbraMtaRestriction: reject_non_fqdn_sender zimbraMtaRestriction: reject_unknown_sender_domain zimbraMtaRestriction: reject_invalid_hostname zimbraMtaRestriction: reject_rbl_client cbl.abuseat.org zimbraMtaRestriction: reject_rbl_client bl.spamcop.net zimbraMtaRestriction: reject_rbl_client sbl.spamhaus.org zimbraMtaRestriction: reject_rbl_client b.barracudacentral.org 

Et c'est tout pour aujourd'hui.

Attention.

Il semble que certaines mises à jour "écrasent" ces données, il faut donc vérifier périodiquement ?
Cete dernière remarque reste à confirmer, la dernière mise à jour 24.12.3 a bien conservé ces données. 

Zimbra ayant annoncé que la version "opensource" serait abandonnée, je me suis mis à la recherche d'un logiciel "remplaçant" et j'ai trouvé "Carbonio" de "Zextras" qui semble être un "fork" de Zimbra et présente le même genre de fonctionnalités qui sont suffisantes pour mon usage.

Je ne vais pas m'étendre sur l'installation, une seule consigne : il faut suivre "à la lettre" la procédure, et, même si un message semble vous demander de faire autrement (cela m'est arrivé) il ne faut pas dévier de la procédure.
Il est toutefois "conseillé" d'installer le logiciel dans une machine virtuelle avec la "bonne" version de Ubuntu (ici 20.04), prendre de préférence une "LTM" car on ne change pas de logiciel de messagerie tous les jours ....
Une fois la MV "vierge" installée il est conseillé d'en faire une bonne sauvegarde "au cas ou" !
Pour le reste rien de très compliqué, les notices de Zextras sont bien faites.

ClickHouse est la base la plus récente du lot (publiée en juin 2016), elle a été prévue pour traiter de grandes quantités de données à une grande vitesse, c'est une base "orientée colonnes" et qui est disponible en Open Source.
Il est possible "d'étaler" (sharding) la base sur plusieurs systèmes avec duplication afin d'assurer la sécurité des données et la résistance aux pannes.
Après quelques essais (en "mono-système") j'ai constaté des performances époustouflantes par rapport aux bases relationnelles "classiques", parfois jusqu'à 100 fois plus rapide sur des requêtes sur de très grosses tables (> 700 millions de rangs) lors de mes tests.