performance

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 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

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 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.
 

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, 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.