Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Si vous utilisez un cluster Kubernetes installé sur OpenSuse, il est possible que celui-ci ait des petits loupés :

• Impossible de démarrer certains pods.
• La liste des évènements contient un message "CreateContainerConfigError: failed to prepare subPath for volumeMount"

Ce problème est provoqué par une régression dans util-linux en version 2.41.

Toutes les versions openSUSE ne sont pas concernées. Ce sont principalement les versions MicroOs, et Tumbleweed qui rencontrent ce problème, car elles obtiennent plus rapidement les nouveaux paquets que les autres. Il n'est pas impossible que d'autres distributions rencontrent le problème dans les prochains jours.

Pour savoir si vous êtes concernée, il suffit de lancer la commande :

rpm -q util-linux

Si elle retourne util-linux-2.41-1.1.x86_64, vous êtes concernés.

Si elle retourne util-linux-2.40.4-4.2.x86_64, ou une version précédente, tout va bien.

Concernant openSUSE, l'incident a été rapporté ici : 1244251 – util-linux 2.41 regression with kubernetes. Un correctif devrait être proposé rapidement.

Pour les utilisateurs de MicroOs, la solution la plus simple en attendant le correctif consiste à faire un rollback :

transactional-update rollback

Si celui-ci retourne un message d'erreur indiquant ERROR: `snapper rollback X` returned with error code 1., il suffit de demander un rollback sur la version X-1.

Exemple : pour l'erreur ERROR: `snapper rollback 33` returned with error code 1., il faut lancer la commande :

transactional-update rollback 32

Ensuite, il faut penser à relancer la commande rpm -q util-linux pour s'assurer de la version util-linux installée.

Derrière ce titre alarmant se cache en fait un mail envoyé aux utilisateurs de services Azure dépendants de .net 9.

Pour les personnes qui n'auraient pas reçu ce mail, voici un lien vers une conversation Reddit : Is .NET 10 finally out? : r/dotnet. Cette conversation reprend le mail dans son intégralité.

Ce mail est malheureux à deux niveaux :

• .net 10, n'est toujours pas en RTM. Passer un projet en production avec .net 10 avant novembre 2025 serait de la pure folie.
• Tout le monde n'a pas reçu ce mail. Ce qui crée un petit jeu du téléphone arabe. Il en résulte quelques frayeurs, et beaucoup d'interrogations.

Conclusion

• Non, il ne faut pas migrer de suite à .net 10.
• Oui, .net 9 est toujours supporté (correctifs jusqu'à novembre 2025, patch de sécurité jusqu'à mai 2026)
• Oui, Microsoft est peut-être allée un peu vite dans sa communication. Il y a peut-être un juste milieu à trouver entre le fait de prévenir les utilisateurs un an avant l'échéance, et prévenir à deux ou trois mois de celle-ci comme on peut le voir chez certains concurrents (non je ne vise pas G…..). Surtout que la durée du support de .net est connue des années en avance, contrairement à d'autres (non, je ne vis toujours pas G…..).

Voici la remédiation à un problème que j'ai récemment constaté sur un serveur hébergeant Azure DevOps.

Le disque système n'avait plus le poindre espace libre.

Après un petit diagnostique, j'ai constaté que le dossier "C:\inetpub\logs\LogFiles" contenait de gigaoctets de logs. S'agissant d'un dossier de IIS, la solution consistait donc, à reconfigurer lIS afin qu'il gère différemment ses logs.

Cela se fait en ouvrant la console IIS, en sélectionnant le site Azure DevOps, puis "Journalisation". Ici, il est possible de modifier la manière dont IIS gère les logs (planifications, tailles de fichiers, etc. ). Personnellement, je déteste explorer les logs pour identifier un problème, je préfère utiliser l'observateur d'évènements.

J'ai donc choisi de désactiver les logs au format fichier.

Ce qui donne la configuration suivante :

Depuis TFS 2008, c'est bien la première fois que je vois IIS configuré de la sorte. Je présume qu'il s'agit donc d'un cas isolé. Mais au cas où je préférais partager la remédiation ici.

Si vous utilisez Duende.IdentityModel.OidcClient, ou toute autre librairie .net permettant de s'authentifier avec Entra Id, vous souhaitez peut-être utiliser son SSO. Par chance, la solution ne se cache pas dans une librairie tierce, mais dans le rutime WebView2 lui-même.

Ceci passe par l'utilisation d'une option lors de l'initialisation du runtime de WebView2. il s'agit de l'option AllowSingleSignOnUsingOSPrimaryAccount. Celle-ci peut s'utiliser de la manière suivante :

var options = new CoreWebView2EnvironmentOptions() {
  AllowSingleSignOnUsingOSPrimaryAccount = true
};

var environment = await CoreWebView2Environment.CreateAsync(options: options);
await _browser.EnsureCoreWebView2Async(environment);

Voici un warning rencontré lors de l'utilisation d'un flux nuget privé :

Error occurred while getting package vulnerability data: Unable to load the service index for source http://.../tfs/.../_packaging/.../nuget/v3/index.json.

Je l'ai constaté avec Azure DevOps Server, mais il peut être observé avec d'autres fournisseurs n'hébergeant pas d'index des vulnérabilités.

Heureusement, le client nuget peut être configuré pour utiliser une liste de sources propre aux audits de sécurité. Cette configuration est extrêmement simple. Exemple : pour n'utiliser que nuget.org :

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

Ceci est documenté ici : Auditing package dependencies for security vulnerabilities | Microsoft Learn