kernel

Alexandre m'a partagé l'article "Linux : Enregistrer toutes les commandes saisies avec auditd" qui présente Linux Audit.

The Linux audit framework provides a CAPP-compliant (Controlled Access Protection Profile) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.

-- from

La norme de sécurité de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d'information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d'être compatible avec cette norme. Parmi celles-ci, l'enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

-- from

D'après ce que j'ai compris, la fonctionnalité Linux Audit est implémentée au niveau du kernel.

Linux Audit permet de surveiller les actions effectuées sur les fichiers (lecture, écriture…) et les appels syscalls.

D'après ce que je comprends, Linux Audit est conçu à des fins de sécurité. Il semble peu adapté pour documenter les opérations réalisées sur un serveur dans le cadre d'un travail collaboratif.

Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

• sudo apt upgrade -y
• ou sudo apt dist-upgrade -y (plus risqué)
• ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

• Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
• Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

• J'arrête les services sur server(n+1).servers.example.com ;
• J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
• Je relance les services sur server(n+1).servers.example.com
• Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
• Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

• Une grande sécurité ;
• L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
• Une durée de coupure limitée et maîtrisée ;
• La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
• La garantie du bon fonctionnement des scripts de déploiement automatisé ;
• La vérification de l'efficacité des scripts de restauration des sauvegardes ;
• Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.

Je suis victime du bug suivant depuis 2 ou 3 jours sous ma Fedora :

Unexpected Logouts and System Instability: The second, more critical issue I’ve been facing is unexpected system logouts. Over the past two days, my screen has suddenly gone black as if the system has shut down. After less than a second, the login screen reappears, and upon logging in, I find that all my applications have closed. Yesterday, August 11, 2024, this happened twice within a three-minute span. Today, August 12, 2024, while studying with only Firefox open, I suspended my laptop and left.

-- from

J'en apprends plus ici :

A new regression for AMD APU’s is present in kernel 6.10 that wil cause intermittent full system crashes in combination with Mesa 24.1.5. The only option is to power down and restart the machine.

Kernel 6.9 is unaffected.

Issue upstream : https://gitlab.freedesktop.org/drm/amd/-/issues/3497

Je vais donc reboot sous un kernel 6.9 🤷‍♂️.

Je suis sûr qu'Alexandre va me dire qu'il n'a aucun problème sous ArchLinux ! Mais je ne le croirai pas, c'est un bug upstream !

Voir aussi ma doctrine Linux Desktop.

---

2024-08-22 : J'ai posté ce message AMD APU regression (full halt) on kernel 6.10 - how to best report?

2024-09-12 : J'ai posté ce message How to list Mesa versions included in my flatpak applications?

2024-10-15 : J'ai posté ce message.