Comme l’an dernier, la mise à jour des serveurs transactionnels openSUSE nécessite de passer par une session via shell transactional-update.

Je vous propose donc aujourd’hui une version actualisée de mon article dédié à l’upgrade d’openSUSE Leap.

Pour commencer, il faut ouvrir un Shell transactional-update afin de créer un nouveau snapshot de l'OS et le patcher.

Ceci passe par la commande :

transactional-update shell

On peut ensuite rafraichir la liste des repositories:

zypper --releasever=15.5 refresh

Lancement de la mise à jour :

zypper --releasever=15.5 dup --download-in-advance

À la fin de la mise à jour, il faut fermer le Shell :

exit

Pour finir, il faut rebooter le serveur pour que le snapshoot réalisé lors de la mise à jour soit utilisé :

reboot

Quand le serveur a redémarré, on peut utiliser la commande hostnamectl. Celle-ci affichera un message similaire à ceci :

Static hostname: xxx

Icon name: computer-vm

Chassis: vm

Machine ID: xxx

Boot ID: xxx

Virtualization: microsoft

Operating System: openSUSE Leap 15.5

CPE OS Name: cpe:/o:opensuse:leap:15.5

Kernel: Linux 5.14.21-150500.53-default

Architecture: x86-64

Hardware Vendor: Microsoft Corporation

Hardware Model: Virtual Machine

Pour finir, il ne faut pas oublier de faire un peu de ménage dans la liste des repositories. Si vous tapez la commande zypper repos, vous vous rendrez compe que plusieurs repositories ont été désactivés (zypper repos -u, affichera un peu plus de détails, c’est une histoire de goûts).

On peut par exemple supprimer le repo lié à Leap 15.4 :

zypper removerepo openSUSE-Leap-15.4-1

Comme à l’habitude, Microsoft a profité de la Build pour lancer un Cloud Skill Challenge. Le principe est simple :

Vous suivez des parcours de formations gratuites sur Microsoft Learn.

• À la fin du challenge, vous obtenez le droit de passer gratuitement une certification Microsoft.
• Cette année, la date butoir pour terminer ces défis a été fixée au 20 juin 2023. Il vous reste donc tout juste une semaine pour en profiter.

La page d’enregistrement, décrivant les défis, ainsi que les règles du Cloud Skill Challenge, est disponible ici : The Microsoft Learn Cloud Skills Challenge.

Bonne chance ;)

Dans le cadre des podcasts DevDevDev.net, j’ai eu l’occasion de participer à un épisode dédié à la Build 2023. Dans celui-ci, nous avons présenté quelques sujets qui nous ont marqués. Bien évidemment, nous en avons profité pour partager nos réflexions, avis, et remarques.

Comme toujours, cela se passe sur DevDevDev.net.

Autour de cette table ronde

• Laurent Kempé, Microsoft MVP.
• Olivier Dahan, Microsoft MVP.
• Michel Perfetti, Microsoft MVP.
• Gérald Barré, Microsoft MVP.
• Notre hôte, Richard Clark, Microsoft MVP.
• et moi même.

Quand on débute avec WiX Toolset, l’une des actions les moins évidentes réside dans le référencement des fichiers à déployer. Pour cela, WiX dispose de toute une batterie de tâches MSBuild. L’une d’entre elles constitue le Saint Graal : HarvestProject.

Comme son nom l’indique, HarvestProject est destinée à récolter les informations relatives aux fichiers produits par un projet Visual Studio (je n’ai utilisé qu’avec .net et .net framework, je ne suis donc pas en mesure de confirmer le fonctionnent avec un projet C++).

Comme je l’avais déjà expliqué l’an dernier, je ne suis pas fan des scripts PowerShell signés. Ceux-ci donnent un faux sentiment de sécurité. Dernièrement, je suis tombé sur une situation qui a anéanti le peu de bien que je pouvais en penser.

Il se trouve qu’un script signé a une limitation qui n’est pas visible de premier abord. Passé la date de validité du certificat qui a servi à la signature, le script n’est plus utilisable. Oui, vous lisez bien. On ne peut plus exécuter le script. Quand on en utilise beaucoup, ce n’est pas terrible (vraiment pas).

Cela fait des années que je signe des binaires, des msi, ou du ClickOnce. Après expiration des certificats, je n’ai jamais rencontré de problème d’exécution, ou de déploiement. Les fichiers signés restent utilisables malgré l’expiration du certificat qui a servi à les signer. Je ne m’attendais donc pas à un tel comportement.

Moralité

PowerShell, c’est génial. Je ne saurais plus vivre sans. Mais la signature des scripts est un véritable enfer dans lequel il est préférable de ne pas mettre les pieds. Ou alors, il faut être vigilant sur le contenu des scripts signés. Il faut aussi faire attention au fait que la signature implique que ceux-si ont une date limite d'utilisation.

Si demain je dois à nouveau signer un script, et le distribuer, mon premier reflex sera d’ajouter dans celui-ci un commentaire indiquant la date de péremption de son certificat.

Autrement dit, je distribuerai des scripts avec une date limite de consommation.